Bugfix stmApp.cpp : double idx++ skips half of 1-Wire sensors

[hubertciebiada]

Problem

In software_esp32/src/stmApp.cpp the parsers that read the 1-Wire sensor ID lists from STM32 increment the loop index twice per iteration — once in the for clause and once in the body:

for (uint8_t idx=0; idx<tempsPrivCount; idx++) {
    if ((cmdptr=strchr(ps,','))!=NULL) *cmdptr='\0';
    strncpy(tempsId[idx].id, ps, sizeof(tempsId[idx].id));
    ps = cmdptr+1;
    idx++;   // ← extra increment
}

Same pattern in the volts parser around line 728.

For tempsPrivCount = N, the loop terminates after N/2 iterations and writes only odd-indexed slots:

• N=3 → fills tempsId[0] and tempsId[2], drops the third sensor entirely
• N=8 → fills 4 slots out of 8

Why it matters

Anyone using more than one DS18B20 on X18 (e.g. for hydraulischer Abgleich — flow/return temperature per manifold loop) sees only half of the sensors. The other half stays empty and the WebUI / MQTT gets no data for them.

The bug is silent — no error, just missing values. Easy to miss until you count sensors and realise.

Verification

• tempsId[] struct holds a single field char id[25] (software_esp32/include/stmApp.h:70-71) — one ID per slot, no pairing
• STM32 response format on gonec 255 is <count> id1,id2,id3,... with one ID per comma-separated token (software_stm32/src/communication.cpp:416-443)
• tempsPrivCount is set from the count field, equals the number of IDs
• Therefore one idx++ per element is correct

Existed since the initial commit of this function (5e497f33, 2022-01-25). The volts parser was added later as a copy of the temps parser and inherited the same bug.

Fix

Remove the redundant idx++ from both loop bodies. No other change. The for loop's own increment now correctly advances by one per element.