No update of PS=1 response when in monitor mode

[FransO]

I started this week with the OpenTherm Gateway from NoDoShop connected to my 12 year old Bosch central heating (TA30 thermostat en 42 HRC boiler). I connect the gateway via the onboard NodeMCU (with Tasmota installed using MQTT) to my Home assistant server. I don't want to use the standard ESPEasy Ser2Net connection as that necessitates the OpenTherm monitor and also because I use Tasmota on all other devices in my home. I had to cut a couple of unused pins from the NodeMCU to solve spontaneous reboots ever 10 seconds or so, but it is running stable now.

The easiest way to transfer the Opentherm data seemed to me to use the response to the PS=1 command. That provides all the relevant data in one response. A rule on the NodeMCU issues a PS=1 command every minute and the Tasmota software automatically sends this response out via MQTT. The response is then decoded within Home Assistant and a sensor is populated with the data (see attached).

OpenTherm Gateway Sensor.jpg (26.04 KiB) Viewed 2755 times

On boot I intended to set the OpenTherm Gateway to monitor mode so as to minimize interference with the normal operation of the thermostat. I would only switch to gateway mode when I want to change a setting. However, in monitor mode the PS=1 command always gives the same response: the response at the time the GW=0 command was issued. After switching back to gateway mode by issuing the GW=1 command, the PS=1 command again gives the actual data.

I would like to know whether this is by design or if I'm doing something wrong or if this is a bug in the OpenTherm firmware.

[hvxl]

Big fat bug.

However, I'm questioning your strategy to "only switch to gateway mode when I want to change a setting". Just switching to gateway mode, changing a setting, and then changing back to monitor mode won't work. A setting change doesn't happen instantaneously, and the OTGW needs to be able to modify messages sent by the thermostat on a permanent basis to maintain the change.

[FransO]

While your at it, you might also change the representation of the lower bound of the DHW and CH setpoint boundaries. These values are specified as signed 8 bit integers in the OpenTherm protocol. My boiler (Bosch 42 HRC) reports both as 0x80 or -0. While a bit strange, this is a valid representation of zero for a signed 8 bit integer value. In the response I now see 59/128 and 57/128 for the CH and DHW boundaries.

I agree with you that my strategy of operating in monitor mode and only switching to back-to-back mode when I need to change a setpoint is wrong. I failed to take in account that both thermostat and boiler are fairly autonomous systems and that when I change a setpoint on the boiler, this does not reflect in the settings of the thermostat.

I think I may have found the cause of the spontaneous reboots every 20 seconds or so before I cut of some of the unused pins from the NodeMCU. On the PCB that I bought from nodo-shop.nl (https://www.nodo-shop.nl/nl/opentherm-g ... teway.html) there is a trace running between the solder pads for the pins S0 and SC of the NodeMCU with only a very small distance between the trace and the solder pads. It looks like I used just a little but too much solder and it shorted the trace to one of the pads. This trace runs to the reset header of the PIC, so whenever this pin on the NodeMCU was used, it would reset the PIC, which would reset the NodeMCU. This might also explain why the reboots did not occur when the NodeMCU was loaded with EspEasy and not with Tasmota, Tasmota toggled the pin and EspEasy did not..

[hvxl]

I'm not at it. It's way too hot for that.

But I have to disagree with your signed 8 bit integer story. The OpenTherm spec defines s8 as: "signed 8-bit integer -128 .. 127 (two’s compliment)". That means that 0x80 is -128, not 0. Furthermore it specifies the valid range for the DHW- and max CH setpoint bounds as 0..127. So your boiler sending 0x80 is a violation of the protocol. If I would fix anything, you would end up with 59/-128 and 57/-128. Not much better, I think. Or maybe it should even be two times 0/0 because the messages are invalid. Strange upper bounds too, by the way.

[FransO]

You are right again. My boiler seems to use 1's complement instead of 2's complement.
The settings of the upper bound is determined by two dials on the boiler. The hot water upper bound is the eco setting of the boiler.

[hvxl]

In 1's complement, 0x80 is -127. -0 would be 0xFF. The manufacturer of your boiler probably used 0x80 to indicate that it doesn't define a low bound. Unfortunately that's not in line with the specs.