State values are not beeing aknowledged after successful change in ems-esp or km200 by the adapter

[tglynx]

Hi Thomas, when changing a state value in ioBroker, the adapter does not acknowledge the new value in ioBroker when the change was successful in ems-esp or km200. As far as i can see this happens for all states.

Example: When changing ems-esp.0.dhwCircuits.dhw1.singleChargeSetpoint (for km200) or ems-esp.0.dhwCircuits.dhw1.wwseltemp (for ems-esp) the value gets changed in ems-esp or km200 successfully! However, the adapter does not aknowledge the value. The value is displayed in 'red' in ioBroker. When hovering over the value with the mouse it is displayed as Aknowledged: false, From: Admin.0

Expected behaviour: When changing a value in ioBroker without the 'aknowledged' checkbox set, the value needs to be aknowledged by the adapter after successfully sending it to km200 or ems-esp. The value will be displayed in 'green', then in 'white' after the adapter has aknowledged the value. When hovering over the value it should be displayed as Aknowledged: true, From: ems-esp.0 (instance ID of the adapter beeing 0)

Best Regards, Michael

[tp1de]

Expected behaviour: When changing a value in ioBroker without the 'aknowledged' checkbox set, the value needs to be aknowledged by the adapter after successfully sending it to km200 or ems-esp. The value will be displayed in 'green', then in 'white' after the adapter has aknowledged the value. When hovering over the value it should be displayed as Aknowledged: true, From: ems-esp.0 (instance ID of the adapter beeing 0)

The adapter just react on any state-change done. The change can be initiated by VIS, the object-browser or a script / node-red. The acknowledged flag is set from there. The adapter does not change it. Only state-changes which are not acknowledged are passed to km200 /ems-esp.

When polling ems-esp or km200 only changes in state-value are written back to ioBroker. So the behavior is intended and I do not know if I should change it. Why do you think it should be done? It's nice anyhow to see the changes done in the object-browser in a different color.

btw: I want to avoid unnecessary updates by re-writing state values if not changed. (minimize write activities)

[tp1de]

@tglynx I checked again. For km200 the values are overwritten and acknowledge is true. I will implement for ems-esp as well.

Version 1.25 was just released and should work as expected. V 1.23 and 1.24 had errors - do not use.

[tglynx]

@tp1de i did update to 1.25 from 1.21 now.

The behaviour has changed as follows:

When changing ems-esp.0.dhwCircuits.dhw1.wwseltemp without ack (which is, as you said, the correct way to change a value to be picked up by an adapter), the value does no longer getting changed in ems-esp but is shown as follows: Aknowledged: False From: Admin.,0

After some seconds the old value from ems-esp is written back and aknowledged by the adapter (from: ems-esp.0) Aknowledged: True From: ems-esp.0

Expected behaviour would be: When changing ems-esp.0.dhwCircuits.dhw1.wwseltemp without ack the adapter would pick up the changed value and change it in ems-esp as the adapter will only pick up changes without ack. After successfully changing the value in ems-esp (successful webservice call) the adapter will update the value with ack.

[tglynx]

Update: my fault… I think it is working now… I think I had browser caching issues… I will check this in more detail tomorrow and let you know! Thanks!!!

[tp1de]

After successfully changing the value in ems-esp (successful webservice call) the adapter will update the value with ack.

I disagree. Ack is set when ems-esp or km200 confirms the changes. So after next poll.

[tglynx]

I see, that is how it is implemented and how it is working right now in version 1.25. Also I am fine with it for my current use case, so thank you very much!

However, it takes a while for the ack to come … I understand that this is because we are waiting for the poll. I was just thinking if it would be a good improvement if the adapter would read back the value directly after it has been set to have the ack as fast as possible - i also understand that this may be lots of effort and could rise other issues (maybe timing related)… :)

so I agree, maybe it is the best to wait for the next poll to get the ack for the value.

thanks again!

[tp1de]

Please note that since the adapter uses polling for both ems-esp and km200 and state changes are just sent using http api posts, it could happen that next poll still delivers "old" values and changes are only recognized by next poll read.

The adapter just waits for a successful http post and it could take some seconds (km200 up to 30 secs) until changes are really done and included in next poll. It's the same for mqtt discovery mode in homeassistant.

[tglynx]

I noticed that in V 1.25 not all values are included in dhw1 compared to V 1.21. All values are still coming in from ems-esp/api/boiler

Comparison:

V 1.21

V1.25

I noticed that, as wwcylmiddletemp was not getting updates anymore...

[tp1de]

where is this state wwcylmiddletemp? Are other states missing?

Is it in boiler? please post http://ems-esp/api/boiler

[tglynx]

it is in boiler...

{ "wwsettemp": 11, "wwseltemp": 40, "wwtype": "layered buffer", "wwcomfort": "eco", "wwflowtempoffset": 40, "wwmaxpower": 100, "wwcircpump": "off", "wwchargetype": "3-way valve", "wwhyston": -6, "wwhystoff": 0, "wwdisinfectiontemp": 69, "wwcircmode": "2x3min", "wwcirc": "off", "wwcurtemp": 18.5, "wwcurtemp2": 9.4, "wwcurflow": 0.0, "wwstoragetemp1": 18.5, "wwstoragetemp2": 9.4, "wwactivated": "on", "wwonetime": "off", "wwdisinfecting": "off", "wwcharging": "off", "wwrecharging": "off", "wwtempok": "off", "wwactive": "off", "ww3wayvalve": "off", "wwmixertemp": 46.8, "wwcylmiddletemp": 49.7, "wwstarts": 1105, "wwworkm": 11657, "heatingactive": "off", "tapwateractive": "off", "selflowtemp": 45, "selburnpow": 100, "heatingpumpmod": 10, "outdoortemp": -1.0, "curflowtemp": 47.5, "rettemp": 40.3, "switchtemp": 47.5, "syspress": 1.5, "burngas": "off", "burngas2": "off", "flamecurr": 0.0, "heatingpump": "on", "fanwork": "off", "ignwork": "off", "oilpreheat": "off", "heatingactivated": "on", "heatingtemp": 75, "pumpmodmax": 100, "pumpmodmin": 10, "pumpdelay": 3, "burnminperiod": 10, "burnminpower": 0, "burnmaxpower": 100, "boilhyston": -6, "boilhystoff": 6, "boil2hyston": 0, "boil2hystoff": 0, "curburnpow": 0, "burnstarts": 3092, "burnworkmin": 150234, "burn2workmin": 0, "heatworkmin": 138577, "heatstarts": 1987, "ubauptime": 762172, "servicecode": "0Y", "servicecodenumber": 204, "maintenancemessage": "H00", "maintenance": "date", "maintenancetime": 6000, "maintenancedate": "04.01.2024" }

Please check the first screenshot of my last post, i would say everything between wwactive and wwdisinfecting is missing currently.

[tp1de]

I will have a look. But this will be my last change on the adapter. More than 600 users and some with exotic constellations which they want to be implemented. I do not use ioBroker anymore, since I moved to home assistant. To keep it maintained eats a lot of time - even that I am retired.

I think that this error is related to the translation to km200 like structure for ems-esp. Could you please install a second instance and run ems-esp without km200 structure. I think, that then the states should be in.

[tp1de]

I restarted my ioBroker instance to test myself. Could you please test the latest Github Version. This version works fine for me.

[tglynx]

Hi Thomas, sad to hear that ... i was hoping to get around moving to home assistant as i already put so much effort in my iobroker config. i understand that all this is lots of effort for you - i am a software developer myself but my native language is c# so i have not much js experience - maybe this would be a good project to get into it? 🥇

I tested the newest github release and it is working again! Thank you so much!

[tp1de]

I was using ioBroker since the start of the project. There are a lot of pro's using ioBroker. I am not a software engineer but I learned JS during the past years since retired. Compared to the time I did programming - during studying electrical engineering more then 40 years ago - in Perl / C++ I felt not comfortable with JS and the ioBroker adapter logic and setup. Debugging is a mess. OK I learned it as from an engineering point of view it is interesting, interpreter based and quite flexible on different hardware.

I started with HA 3 months ago. HA is not so flexible in sense of implementing own logic like this adapter. But I found a way to implement my own logic with node-red (JS) without writing integrations.

HA is much faster and the dashboards are much easier to create with responsive UI. I do not like VIS which is not responsive to different screen resolutions on mobile, tablet and desktop. I decided to stay there. The ems-esp integration is done by mqtt discovery. For the km200 I migrated the adapter code to node-red within ha. For my other hardware there are good integrations available within HA. While using the HA VM installation the whole staff is easy to install, maintain and migrate to different hardware.

Same as on ems-esp where the 2 developers have a big job to maintain and support the different heating systems, it's the same for the Bosch systems with km200 / ip-inside. Not all hardware is actually supported there. And Bosch wants to close the local api access and move to cloud api with limited functionality or paid one for installers. To keep track with all this requires a lot f time. The 1st km200 adapter was not developed further since 3 years. I believe a similar reason.

[tp1de]

I released 1.26 now. I hope that this version is stable for everybody.