ROOM2: INDR_T 0.6-0.7 °C above d50 never applied -> indoor sensor alarm
- Detta ämne har 6 svar, 2 deltagare, och uppdaterades senast för 2 timmar, 35 minuter sedan av
.
-
Inlägg
-
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…
New question: ”safe set” / revert-to-reference on loss of the controlling host?
Hi Anders,
I control my Diplomat G3 through ROOM2 (fw 2.70) from a Raspberry Pi over MQTT: heating curve (d52), curve corrections (d55–d57), min/max supply (d53/d54), heat stop (d58) and the integral/hysteresis/max-return group (d73–d75). Every write goes through my own journalled path with readback, and the Pi resets everything to my reference values on a controlled stop, reboot or rollback, plus a watchdog for a hung Pi.
What the Pi cannot cover is a power cut or a crash: then the last written values stay in the heat pump. So I wonder whether ROOM2 could do this itself:
1. A ”safe set” of register values (e.g. d52, d53–d58, d73–d75) that the host writes once via an MQTT topic. ROOM2 stores it in NVS so it survives a ROOM2 restart, and it can be read back on a status topic.
2. Trigger: no message on a keepalive topic for N minutes (configurable, say 15–240). A keepalive rather than the TCP/MQTT connection, so a hung host with a running broker is also covered. This should also apply if ROOM2 starts without a broker.
3. On trigger: write the safe set once through ROOM2’s normal write path, verify it in the following frames, and publish an event with the result when the connection is back. No repeated writes, because of EEPROM wear.
4. Never touch INDR_T or the room setpoint (d50), and never send a reset to the heat pump.
5. Enable/disable switch, and report the firmware version.Two questions:
– Does 2.70 already have anything like this?
– What does ROOM2 do with INDR_T when MQTT is lost?Thanks for ThermIQ — it works very well for me.
Daniel
- Du måste vara inloggad för att svara på detta ämne.
