Home Automation Domotica Forum Europe, Bwired Forum

The OTGW is connected to a Remeha Elga Ace heat pump and Remeha iSense RF thermostat. At random intervals, the room temperature reads -40.0 °C (see log at the bottom). The system seems to be working correctly, but it's still bothering me; I want to understand why this is happening. Here are some possible causes I came up with, though I don't know much about OT and heating systems so I could be way off.

• I didn't have a proper thermostat cable, so I used an audio cable, which is quite thick, compared to a thermostat cable. I think the OT signals are analog, so I assume an improper cable could cause issues, though I'd expect to see a range of weird values, not just -40. All other readings seem to be fine, as far as I can tell, which is weird.
• The thermostat sends its readings over RF to the receiver. Perhaps something goes wrong in the communication sometimes, and the receiver sends -40.0 as a special value to indicate this, allowing the boiler to ignore them. However, I wasn't able to find anything about this online. It would also be more logical just to ignore a faulty reading, instead of sending a weird value.
• Remeha's OT implementation could be incorrect and sometimes sends data that the OTGW can't handle. This seems unlikely.
• There could be a malfunction in the OTGW hardware. This seems highly improbable since the error is so specific to this reading; everything else seems to be working fine.

And I have a few questions:

1. What could be going on here? And how do I solve this?
2. Will this issue affect the heating system? I assume that if the -40.0 readings aren't ignored, the heating system will turn on needlessly.
3. If I can't solve this issue, is it possible to have the OTGW ignore these faulty readings?
   

   Code: Select all

   07:59:08.602200 (  14536|  9968) processOT   (1693): Thermostat        T9018D800 (9)[MsgID= 24][WRITE_DATA      ]>Tr = -40.00 °C
   07:59:09.491955 (  15208|  9968) processOT   (1693): Boiler            B5018D800 (9)[MsgID= 24][WRITE_ACK       ] Tr = -40.00 °C
   

I'm pretty certain your receiver actually sends -40 when it's not sure about the actual room temperature. I have seen similar behavior from a C-Mix, although that device was nice enough to classify the message as Inv-Data rather than Write-Data.

If the cable was a problem you would sooner see lots of error messages than one particular bad value for one particular message.

All Opentherm messages consist of 32 bits. The OTGW will just report these 32 bits exactly as it receives them. It does not perform any checks on the bits, other than a parity check. If there is a parity mismatch, the OTGW still reports the 32 bits, but tags them with an E. Additionally it reports Error 04.

To answer your questions:

1. Your thermostat is sending these messages. Solving it would have to be done in the thermostat, or by replacing the thermostat.
2. This will not affect the heating system. The boiler does the heating based on MsgID 0 (Status), MsgID 1 (Control setpoint), and MsgID 14 (Max relative modulation). It doesn't care at all about the Room setpoint and Room temperature. In fact, you can block those messages in the OTGW (using UI=16 and UI=24) without consequences to how your house gets heated.(*)
3. As indicated before, the OTGW PIC reports exactly what it receives. This allows it to handle new additions to the Opentherm specifications, as well as OEM specific messages (128..255) without the need to update the firmware. Any filtering you may want to do is left to the external equipment that processes the messages from the OTGW. I also consider the NodeMCU or Wemos that can be plugged into the Nodo shop boards "external equipment".

(*) I know there is some buggy equipment that will refuse to heat if the Room setpoint is lower than the Room temperature. But that is in conflict with the Opentherm specs and it is plain wrong. Maybe the thermostat wants to start heating in anticipation of an upcoming scheduled Room setpoint change. The boiler should not block that. However, I am not aware of any Remeha boilers that behave this way.

Thanks for your detailed answer. I find this very interesting! It's good to know that this 'issue' isn't affecting the heating system, just my room temperature plots in Home Assistant. I'm filtering out the -40.0 values there to solve that issue.

I have another question. According to the thermostat equipment matrix, the iSense RF should support "MSG 9: Remote override room setpoint". However, when I send "TC=21", I don't see this setting reflected anywhere; the "Remote override room setpoint" remains empty in OTmonitor. Is this value instead converted to appropriate 0, 1, and 14 messages, as you mentioned? In that case, heating would happen based on the value I sent, but it wouldn't be visible anywhere. I was expecting the thermostat to store the override setting and display it somehow. I've also tried setting "FT=I" before sending a "TC" or "TT" command.

EDIT: I found this post that mentions that remote override is disabled by default. I've found this setting on the thermostat and enabled it. It doesn't seem it changed anything, but I'll wait a bit longer.

EDIT 2: I wanted to check the version of the iSense, which reads v27. When the iSense restarted, it showed the room setpoint of 25 I had sent to the OTGW as a test! I've set it to 24 now, and I'll wait patiently for it to appear on the iSense.

EDIT 3: The value came through! Seems like this is working as expected now.

The equipment matrix shows that, according to one log, the iSense RF requests ID9 around once every 5 minutes (message rate of 292.56s).

I made a few edits to my last post. After enabling the remote override on the thermostat, it's now finally working The only thing I'm not sure about is whether I need to send "FT=I" or if the iSense RF is automatically detected as an iSense thermostat.

I had no idea that the equipment details were publicly available. That's super neat! I've uploaded my log earlier today.

You can put detection back to automatic (FT=A) , then check later with PR=R what the OTGW thinks the thermostat is. It makes this determination based on MsgID 2, which isn't reported very frequently. So you may need to wait 10 minutes.

The OTGW only needs to know it is dealing with an iSense for switching from one remote override setpoint to another. Overriding the normal program of the thermostat works the same either way.

Taipou wrote: ↑Fri Oct 21, 2022 2:43 pm I've uploaded my log earlier today.

The most recent iSense RF log indeed shows that MsgID 9 and 100 are not requested (because you hadn't found the menu setting yet). And also MsgID 99 appears to depend on that setting. Good to know.

And the battery of your room temperature controller is running low

hvxl wrote: ↑Fri Oct 21, 2022 3:06 pm

Taipou wrote: ↑Fri Oct 21, 2022 2:43 pm I've uploaded my log earlier today.

The most recent iSense RF log indeed shows that MsgID 9 and 100 are not requested (because you hadn't found the menu setting yet). And also MsgID 99 appears to depend on that setting. Good to know.

And the battery of your room temperature controller is running low

Thanks! I'll change those batteries

I've just uploaded a new log with the remote override enabled on the thermostat, if that is of any value.

Look mom, no cloud! So nice... Thanks again for your help!

Interestingly your new log does not contain any Room setpoint messages (in over half an hour). Possibly the iSense RF only sends that when it changes? Again, an interesting detail.

Batteries are fine again.

hvxl wrote: ↑Fri Oct 21, 2022 5:57 pm Interestingly your new log does not contain any Room setpoint messages (in over half an hour). Possibly the iSense RF only sends that when it changes?

That seems right. I noticed that the room setpoint had an empty history in Home Assistant until I changed it on the thermostat. I suppose they're trying to save some energy on the battery-powered iSense RF.