ROOM2: INDR_T 0.6-0.7 °C above d50 never applied -> indoor sensor alarm
- This topic has 4 replies, 2 voices, and was last updated 2 weeks, 1 day ago by
.
-
Posts
-
Thermia Diplomat G3, ThermIQ-ROOM2, sending INDR_T from a Shelly sensor via MQTT set (about every 5-30 min).
Out of 35 sets since 15 Oct, all 4 with INDR_T – d50 = +0.6/+0.7 (23.6/23.7 with d50 = 23) were echoed by ROOM2 (INDR_T in /data), but never applied in the pump (r01/r02 unchanged). Exactly ~4.5 min later the pump raises the indoor sensor alarm (r14 bit 4) and falls back to 20.0 °C. All 31 other sets (from -2.4 to +0.4 and from +0.8 to +1.7 relative to d50) were applied within ~30 s.
Only a ROOM2 power cycle clears the alarm (it then starts at 20.5 as documented); a new set does not. The old Thermia Online module is disconnected from EXT.
1) Is this a known limitation of the room unit protocol (values just above the setpoint)?
2) What does the MQTT command “reset” do: reboot or configuration reset?
3) Is there a safe way to restart ROOM2 remotely?Thanks!
The indoor unit does not have any reporting in reference to d50, it will always transmit a new value and not a delta value.
That said, the fact that you get indoor sensor alarm means that communication btw ThermIQ and the heatpump is lost. Can You see if ThermIQ reboots (announce message in mqtt or uptime)?
1) Not seen this before
2) reset will do a full restart of ThermIQ, reseting ThermIQ target indoor temperature and EVU status. No other settings should change
3) Yes, sending resetHi Anders,
Thanks for the reply, and sorry for the slow follow-up. We have been logging a lot more since, so here is what we found.
You suggested the alarm means ThermIQ lost contact with the pump. I don’t think that is the case here. We kept receiving full register frames from ThermIQ during every alarm. We logged around 450 frames with the indoor sensor alarm bit set (r14 bit 4) on 17-18 Oct. In those frames d1/d2 drop to 20.0, while the ROOM2 echo still shows the value we sent. So the link to the pump looked alive the whole time, it just seemed to reject the room value.
The pattern was very consistent: every alarm we logged came right after we sent an INDR_T ending in .6 or .7. Around 60 other values went through fine and were applied within about 30 seconds.
What we changed on our side:
– Since 18 Oct around 13:15 we never send values ending in .6 or .7. We round to the nearest allowed value instead.
– Result so far: about 150 INDR_T updates over three days and zero alarms.
– As a fallback we power cycle ROOM2 via a smart plug if the alarm persists. That is the only thing that has ever cleared it for us.
– We have not used the MQTT “reset” command.A few questions:
1. Just to confirm: the safe way to restart ROOM2 remotely is to send the MQTT “reset” command, and it only resets the target indoor temperature and EVU status?
2. Our ROOM2 is on firmware 2.70. Is there a newer version, and do you have release notes, especially anything about the room sensor link?
3. Do you know of anything in the room unit protocol that could make the pump reject specific decimal values like .6/.7?Happy to share logs or frame dumps if that helps.
Thanks,
DanielThanks for thorough debugging, I will look into it and see if I can find the issue.
Yes, sending reset will just restart the thermiq, equal a power off/on, and the only loss would (should…) be the loss off evu atate and Indoor temp setting
The indoor temperature is using a different interface (the indoor interface) compared to all other reading/writing to the heatpump and is thus “independent”. If the interface is not connected/lost the heatpump will report 20 degrees as the “actuall”. When ThermIQ-room2 is reset it will use 20.5 as it’s default and as a way to distinguish that a connection is made.
The interface is very thermia specific and there is no obvious connection to the decimal values 0.6 / 0.7
I have verified on my pump that the following range of indoor temperature works with indoor wanted set to 22:
ThermIQ/ThermIQ-room2-jas/set
{“INDR_T”: 20.0 } – {“INDR_T”: 23.8 }and fails for 22.7, 23.6 and 23.7 with indoor target set to 23. It does work for 22.6
I do not see that the interface hangs, I can transmitt a new value and it is received properly. An hung ThermIQ should always return to working state by sending reset to it.
I will look deeper into this, it is not a bug in the calculation of values since 22.6 is transferred correctly but some interference between values or in transmission of values. It could also be a bug in the heatpump but that would be unexpected…
- You must be logged in to reply to this topic.
