API: Post/Put does not change http Get values immediately for thermostat/dhw entities - just on next telegram read

[tp1de]

Within my ioBroker adapter I use the API interface.
Changes are send with a http post request.

This works as expected, but for some entities (thermostat/dhw) next telegram read might be only after 60 seconds.
Until next telegram read the old (unchanged) value is returned when polling values with http get.
tp1de/ioBroker.ems-esp#103

This results in irritating results when using small polling cycles and should be changed.

[tp1de]

I tested other thermostat entities. The hc1/hc2 entities change API get values immediately.
It seems to be a problem just for thermostat/dhw.

[MichaelDvP]

The commands write to the bus and queue a readback(validate) for the values. So the value is set afer the readback is executed on the bus. This is for all vales the same precedure. This happens within a few secondes. Plese make a log of a value that is validated a minute later.

Only hc/mode sets the value inside emsesp in advance (not validated) to allow mode-dependend commands like seltemp to work in the desired mode.

[tp1de]

Michael I can confirm the readback within short time, but for the tested entity thermostat/dhw/circmode (enum) it does not change the next api response. Type 2F5.
For me it looks like the next regular full telegram (every minute) just does the job.
Raw hex telegrams out of syslog analysis:

8/18/2024, 3:40:16 PM | 10 0B FF 00 01 F5 01 FF 04 00 00 00 04 06 00 08 01 00 00 00 00 00 00 00 00 00 01 61
8/18/2024, 3:39:24 PM | 10 00 FF 03 01 F5 00 FC
8/18/2024, 3:39:21 PM | 10 0B FF 03 01 F5 00 85
8/18/2024, 3:39:20 PM | 0B 10 FF 03 01 F5 00 58 <-- setting value 0 (offset 3)
8/18/2024, 3:39:07 PM | 10 0B FF 00 01 F5 01 FF 04 01 00 00 04 06 00 08 01 00 00 00 00 00 00 00 00 00 01 D1
8/18/2024, 3:39:02 PM | Start

Could you please check again.

[MichaelDvP]

Yes, you're right, there is a check for dhw circuit stored in offset 0, but the response is only offset 3, so it is not processed. I'll make a fix.

[MichaelDvP]

Could you try the testbuild. https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test
I've included a fix and you can try:
http://ems-esp.local/api/thermostat/hc1/switchtime1
http://ems-esp.local/api/thermostat/hc1/switchtime1/value
also dhw/switchtime and dhw/circswitchtime
mode/temp json depends on switchprogmode.

writing is untested early stage and only a single point with id (or first datapoint), value:{"id":0, "time":"05:00", "mode":"on"} I think i still missed somehing...

I've also resort the different RC3xx/R3000/BC400/UI800 models, hopefully all with the right mode enum_selections.

[tp1de]

The timing on dhw changes is working now. I will continue testing.
The switchtimes do not deliver any values / results yet.

I am using "switchtimes" as well but within Bosch/buderus they are named "switchPrograms". The "switchTimes" are the time entries within the programs. Maybe we should consider this as well.

Btw: I was quite confused to recognize that no api post was working anymore from ioBroker and I was looking within my adapter.
The reason I found at the end where 6 switchPrograms I set as custom entities for test.
The entities where read correctly but no api post was possible anymore. Just deleting them was not helping. I needed to reboot after deletion.

[MichaelDvP]

Ok, made a PR for the dhw fix, plese close this if ok.
For switchtime/testbuild continue discussion in #1594.