Bug or feature in REST GET API?

[ajongen]

Hi Rob,

I was trying to get some OTGW info (flame status, dhwmode, chmode, faultindicator etc.) into my domoticz using the REST GET API provided by your OTGW-firmware. I wanted to do this by processing the status information on bit level. It all seemed to work fine but in the end I found some strange / unexpected behaviour in polling the STATUS ID=0 information. When calling:

http://192.168.178.32/api/v1/otgw/id/0

I normally get as expected:

{ "label": "Status", "value": 512, "unit": "" }

But when I make subsequent calls I sometimes get:

{ "label": "Status", "value": 0, "unit": "" }

Is this on purpose? I would expect the same status value as long as nothing changes.

Thanks for your reaction!

Cheers, Armand

[rvdbreemen]

That must be either a bug or the data is really 0.

[hvxl]

Maybe something changed that you don't realize. The 512 corresponds to the DHW enable bit, which is controlled by the thermostat. Many programmable thermostats will set this bit during the times someone is expected to be at home and awake (the "opstaan" and "thuiskomen" intervals on a Honeywell thermostat), and clear it otherwise (the "vertrekken" and "slapen" time blocks). Simple thermostats may base it on the setpoint (e.g. on when the setpoint is above 16).

[ajongen]

In the meantime I have adjusted my dzVents LUA script in Domoticz to use the content of

http://192.168.178.32/api/v1/otgw/telegraf

instead, and extract the different status information from that output using something like

local searchstr = {'flamestatus' , 'chmodus' , 'dhwmode', 'faultindicator'}

This gives very stable and correct information over time. Since the subsequent calls I made with http://192.168.178.32/api/v1/otgw/id/0 are done without any changes to program status (I have the thermostat set at CONTinous temperature at the moment) I do not think it is related to switches in the programme status.

[hvxl]

While experimenting, I discovered that the api call reports the bit as it is returned by the boiler, not as it was sent by the thermostat. Apparently your boiler sometimes changes the bit in its response.

The high byte of ID0 is the master status. In my opinion it should reflect the information provided by the thermostat, while the low byte, the slave status, should be taken from the response from the boiler. (That is what OTmonitor does.)

[rvdbreemen]

Thanks @hvxl for pointing that out. I thought I fixed that completely. It works for MQTT. But I missed doing the data object like that, so the REST API still contains the older code.

This will get fixed in next release.

[rvdbreemen]

@ajongen would you like to validate the fix for me?

[ajongen]

@rvdbreemen I have not yet updated the firmware since initial installation so that would be a first timer. Is it possible to do while keeping all settings? If you sent me the instructions I will give it a try.

[rvdbreemen]

@ajongen well, indeed you migt wanna update. Anything before the 0.9.x series had bad OpenTherm decoding issues. I solved that last December, eversince I had a good fix.

If you like I can share some binaries with you, you could validate them. The easiest way is to save your settings.ini from your firmware, to you machine, and upload it after upgrading. That way your setting should work again after a reboot.

[ajongen]

I have got 0.9.2+e9c35e9 running very stable (only installed the OTGW in februari I think). Binaries are the easiest I think. I am running the older PIC but I read in github that the code is now working for both PIC models.

Op di 7 jun. 2022 om 23:58 schreef Robert van den Breemen < @.***>:

@ajongen https://github.com/ajongen well, indeed you migt wanna update. Anything before the 0.9.x series had bad OpenTherm decoding issues. I solved that last December, eversince I had a good fix.

If you like I can share some binaries with you, you could validate them. The easiest way is to save your settings.ini from your firmware, to you machine, and upload it after upgrading. That way your setting should work again after a reboot.

— Reply to this email directly, view it on GitHub https://github.com/rvdbreemen/OTGW-firmware/issues/126#issuecomment-1149212314, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXNMJ7EFZWVVCGKC3LVJYI3VN7AZBANCNFSM5VULE4KQ . You are receiving this because you were mentioned.Message ID: @.***>

[ajongen]

Hi Robert,

As described previously I have recoded my stuff to use the telegraf call instead of a single messageID call. It seemed to give correct information at the beginning but now (having some weeks of data) I also see some incorrect information using that call. Does the telegraf call also use the print_status method that you have updated?

Cheers, Armand

Op wo 8 jun. 2022 om 08:14 schreef Armand Jongen @.***>:

I have got 0.9.2+e9c35e9 running very stable (only installed the OTGW in februari I think). Binaries are the easiest I think. I am running the older PIC but I read in github that the code is now working for both PIC models.

Op di 7 jun. 2022 om 23:58 schreef Robert van den Breemen < @.***>:

@ajongen https://github.com/ajongen well, indeed you migt wanna update. Anything before the 0.9.x series had bad OpenTherm decoding issues. I solved that last December, eversince I had a good fix.

If you like I can share some binaries with you, you could validate them. The easiest way is to save your settings.ini from your firmware, to you machine, and upload it after upgrading. That way your setting should work again after a reboot.

— Reply to this email directly, view it on GitHub https://github.com/rvdbreemen/OTGW-firmware/issues/126#issuecomment-1149212314, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXNMJ7EFZWVVCGKC3LVJYI3VN7AZBANCNFSM5VULE4KQ . You are receiving this because you were mentioned.Message ID: @.***>

[ajongen]

@rvdbreemen : any progress on this issue? Do you want me to test something or are you planning to merge the changes into a next release?

[rvdbreemen]

@ajongen issue has been fixed in dev-branch. Not released yet.

[rvdbreemen]

@ajongen v0.10.0 has finally been release, this should fix your issue. Sorry it toke way longer than I ever thought back when I fixed it.