MsgID 100 "RoomRemoteOverrideFunction" is not always set to 0 when Thermostat resumes program

[ajongen]

While trying to enhance the iphone.html remote control for my thermostat such that it would also accept TC commands and have a "Resume Program" button, I noticed that the RoomRemoteOverrideFunction-data value (MsgID 100) in the OTGW is not updated correctly in all cases. It is set correctly to 0 when sending a TT=0 or TC=0 command to the OTGW. But if the program is resumed by the thermostat itself, MsgID 100 is not set to 0 in all cases.

As far as I now have tested this is the case either due to the clock passing a program set time when having set a TT temperature, or due to a manual push of the "resume program" button on the thermostat. But the TrOverride / MsgID 9 is set to 0 in both cases as expected. See the summary from otmonitor.

I double checked using the REST API:

I guess it would be possible to use MsgID 9 as an extra check that when this is set to 0, MsgID should also be set to 0?

Cheers, Armand

[rvdbreemen]

Hi @ajongen

Thanks for reporting this issue. I will look into this.

Robert

[rvdbreemen]

Can you provide logging from both OTmonitor and the OTGW firmware. So I can investigate what the Data-Id values are that are sent by your boiler and how the firmware translates them.

Thanks Robert

[ajongen]

Hi Robert,

See the logging from the OTmonitor in the attached txt-file. I am not sure which logging I can get directly from the OTGW firmware but I attached 2 screenshots from the OTGW firmware page.

The starting point for the logging was the thermostat running it's program (ID100=0). At 21:59:38.418731 I issued the Command (via websocket): TC=19.5. This set ID100 to 00000001 and the Remote override Temp to 19.5. At about 22:02:40 I pushed the hardware "Start Program" button on the thermostat. This set the Remote override Temp (MsgID=9) back to 0.0. But the Remote override function stays 00000001. Note: Sending TT=0 or TC=0 via command resets MsgID 100 to 0 (not in logging but tested).

Hope this helps.

Cheers, Armand otlog-20220124.txt

[rvdbreemen]

Just use a tool like putty to connect to port 23 to find debug information.

Read here more about debug: https://github.com/rvdbreemen/OTGW-firmware/wiki/How-to-debug-the-OTGW-firmware

The debug log and the OTmonitor log at the same time would be most helpful.

[rvdbreemen]

I also noticed in your screenshot that you are not using the MQTT integration option. Is that on purpose?

[rvdbreemen]

The OTmonitor program that you use communicates with PIC and thus my firmware on the ESP does nothing more than just send all serial data over the network.

That why I ask if you could share both logs of the OTmonitor and the ESP firmware, as both decode indepently the OT message and translate it to output.

If you use a home automation like home assistant or Domoticz or OpenHAB than you would benefit from MQTT as that streams the data to the broker. When using the REST API you get access to the latest data values seen by the ESP firmware.

So to investigate more I would like to see the two data logs side by side.

Thanks Robert

[ajongen]

Will try that (debug via putty) tomorrow.

And no, ommiting the MQTT integration is not on purpose. I am not familiar with MQTT and thought I would need something extra when turning it on. But you say I can select the MQTT OT msg enable button without changing anything else?

[rvdbreemen]

No, you would need a MQTT broker. The easiest would be Home Assistant with an MQTT Addon.

The option you point out is explained I. The wiki too, it enables full OT message logging to MQTT. You do not need that at this time.

btw MQTT is not needed for debug logging purposes. You will see once you use putty to telnet into the ESP. It has a lot of debug info even without MQTT.

[ajongen]

Oeps... I accidently closed this one....

[ajongen]

I am not using Domoticz with the OTGW since it was broken with the 0.92 release ;-) which let me start using the OTmonitor. This now nicely gives me the possibility to use a light weight website for remote control. I have Domoticz running on the same RPI as the OTmonitor and might try that one later this week using it with MQTT after upgrade to 0.93.

[rvdbreemen]

The version 0.9.3 fixes the issue with native legacy integrations like Domoticz / Home Assistant. There was a serial handling bug in release 0.9.2.

I look forward to the logging of the ESP firmware to actually see what’s going on.

[ajongen]

Hereby the logging from the ESP firmware and OTmonitor in the attached txt-files.

The starting point for the logging was again the thermostat running it's program (ID100=0). After some time I issued the Command (via websocket): TT=19.5. This set ID100 to 00000011 and the Remote override Temp to 19.5. At about 08:07:30 (timestamp in ESP logfile differs 1 hour from OTmonitor logfile) I pushed the hardware "Start Program" button on the thermostat. This set the Remote override Temp (MsgID=9) back to 0.0. But the Remote override function stays 00000011.

otlog-20220125.txt OTWG putty.log .

[rvdbreemen]

The ESP timestamp is UTC... so yeah, it's one hour behind.

[rvdbreemen]

Looked at both logs, see exactly the same results. That's a good thing btw. As you can see in the logs, we are looking at the gateway behaviour. You say you expected the ID100 to go back to 0, but in the documentation of the gateway it says this:

Read-Data SetPointOverride (ID=9) The gateway sends a Read-Ack message with the last configured override setpoint value. Initially the override room setpoint is 0.0, meaning "no override". The gateway will continue to send a setpoint override value until it detects that the thermostat no longer honors the change (probably because it was canceled by a manual action or by the thermostat schedule). When that happens the override room setpoint resets itself to 0.0.

And this: Read-Data FunctionOverride (ID=100) The gateway sends a Read-Ack message with a value depending on the type of the last override setpoint configuration command. If a continuous temperature change was specified the returned value will be 0. For a temporary temperature change the value is 2 (enable overruling remote setpoint by program setpoint change).

So both are read values, meaning they are created by the gateway, seen by the 'A' messages. You can see that in the ESP log there are markings to show which values are used and when a value is 'overridden' by the gateway it clearly says that in the log too.

From what I read from you, you expected the MsgID=100 to goto 0, but if you read the documentation it says the TT change causes the overrule remote setpoint to goto value 2 (bit 2 set to '1'). It does not say it will change the value back if the thermostat is set back to program. What you already said, the msgid=9 will go back to 0, once it's overridden by the thermostat.

To me it sounds like it's as designed and intended according to the documentation. Now it could still be behaviour you did not expect or think it's wrong, then you can ask Schelte Bron himself on his forum.

[ajongen]

I think you are right. All together I might be looking for information that is not available. For the remote control I want to know the status the thermostat is in, independently of how it got there, i.e. independent of the used input (manual or remote). But I noticed that when I manually put the thermostat e.g. in Continue-mode, a command call TT=0 or TC=0 will not set it back to program mode. So it is probably not possible within the OT protocol to get the information I was looking for.

Thanks for your help and effort in this!

[rvdbreemen]

No problem. I will close the issue for now.