Can you try to set up an automation to react to the aforementioned message with a heating setpoint publish to the TRV?
Just a blind guess, but this seems to be really suspicious to me…
It seems a reasonable blind guess. WiserHeatUserRejoin consistently appears in the logs about 12 seconds before the TRV reports a new setpoint of 20°C.
Do you know of a way to get the automation to trigger only when the payload includes that string? The following automation trigger triggers on every message but the condition also seems to block every message, and obviously I want to react only to messages that include WiserHeatUserRejoin:
- platform: mqtt
topic: zigbee2mqtt/0x50325ffffxxxxxxx
condition:
- condition: template
value_template: "{{ \"WiserHeatUserRejoin\" in trigger.payload }}"
Incidentally, the ‘hack’ I wrote above held successfully for five days, until I reset the TRV to continue experimenting.
You need to write an external converter to get that wiserDeviceInfo published as well. As I see that data does not get published. It is actually only in the log.
But you can write the converter that way, if the Rejoin message received, then publish the target temperature.
By the way, do the other devices have the same Rejoin messages?
This is pushing my knowledge a little so, to be clear, is it the case that Zigbee messages are sent directly from the device to Z2M but Z2M-to-device are buffered via the MQ broker? In which case, that means the WiserHeatUserRejoin message is definitely coming from the TRV.
They do not. Looking at the log files in ~/config/zigbee2mqtt/log, the string WiserHeatUserRejoin only appears yesterday (after I’d reset the TRV) and five days prior (when it was last reset). The other two TRVs have never had that message, and the TRV I’m working on did not have it after the ‘hack’ was implemented.
FWIW, with the bindings missing I disabled the TRV overnight to see if it would reset to 20°C: it did reset. That could be because disabling it didn’t block the very first message, or because the bindings are essential to the ‘hack’. TBC.
Z2M is a gateway software. As the name suggests Zigbee to MQTT. The device communicates through the Zigbee protocol with Z2M. Z2M translates the Zigbee messages (or not, it depends that is it implemented or not). And then it publishes the MQTT topics as separate devices/entities what HA handles. ZHA does the same thing, but without the MQTT step.
What you see in your log, is what Z2M decodes from the Zigbee protocol. And where you see the MQTT Publish, that is the place where it publishes the results to the MQTT broker.
Those rejoins are coming from the device itself. It is not Z2M which causes it, or actually something is missing and that’s probably the reason why the device rejoins and resets the setpoint.
1 Like
I’ve looked around, but I’m not sure how to scrape the Z2M log for the WiserHeatUserRejoin string. It’s possible to scrape the system log but logs for add-on seems more difficult.
But let’s just take a step back here: what are we trying to do / prove?
Demonstrate a link between WiserHeatUserRejoin and resetting to 20°C
I think we’ve done that. Here are the logs from the past eight days. Remember that the TRV had the ‘hack’ in place between the first and second entries (five days) and was working normally. As soon as it was reset, the messages appeared again and the setpoint kept changing back to 20°C:
[core-ssh ~]$ cd config/zigbee2mqtt/log/
[core-ssh log]$ grep "WiserHeatUser" * -r -h
debug 2022-12-01 16:56:50: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,23162940,4240"}' from endpoint 1 with groupID null
debug 2022-12-06 10:32:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,30936,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 13:01:38: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,39517,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 13:02:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserJoin,25110,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 15:14:21: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3874,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 17:25:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 19:37:03: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3875,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 21:48:22: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3870,9063"}' from endpoint 1 with groupID null
debug 2022-12-06 23:59:43: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 02:11:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 04:22:28: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 06:33:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 08:45:07: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 10:56:30: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 13:07:51: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3873,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 15:19:13: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 19:41:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-07 21:53:13: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 02:15:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 04:27:18: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3878,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 06:38:37: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3872,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 08:49:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3876,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 11:01:20: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3877,9063"}' from endpoint 1 with groupID null
debug 2022-12-08 13:12:43: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3873,9063"}' from endpoint 1 with groupID null
I haven’t always changed the temperature from 20°C every time, but when I have it has always changed back around the time that WiserHeatUserRejoin is logged.
(Incidentally, I’ve also noticed that the TRV motor has been running around that time - even when the setpoint was still 20° and no change was necessary)
We want to find a workaround
So far we have two:
- @madbobmcjim’s workaround, which maintains the desired setpoint by repeatedly setting it
- The hack I put together with your help, @GSzabados, which seems reliable but doesn’t explain the behaviour
It will help with further research into the underlying cause
In which case I’m happy to keep going, although I’m not sure how to proceed from here
Hello. My firmware is abe98a2 and I’ve followed your guide, but after enabling device I can’t set temperature anymore. It just keeps jumping between 16C and 18C
Empty block in chart is when I’ve disabled device in HA.
bind and reporting has all the entries as per guide so I assume it has paired correctly.Also my TRV always flashes 8 times while I hold dial turned to
minus - should I release dial after 5 flashes instead?
I’ve given it another go yesterday, but this time TRV dropped from MQTT network completely before midnight and doesn’t appear in dashboard anymore.
Hi…
From my experience it seems that there is a polling issue when ZHA or Z2M are used which causes the iTRV to fall back to a default mode I.e resets to 20deg.
I have 8 iTRV’s and some of them hold the occupied_heating_setpoint and others that reset to 20deg after several hours.
I think that there is some merit in the “20deg hack” but it doesn’t always work.
I have noticed that the iTRV’s which reset to 20deg show their leds as disconnected, I.e when the head is twisted, the led flashes. Which means the iTRV is not connected.
Maybe the ZHA, Z2M protocol isn’t polling the iTRV as it is expecting therefore It falls back to its default mode of 20deg.
I now have a wiser hub and I’ll try and trace some logs re the polling…
As far as I’ve found from testing, it seems that iTRV “listening interval” gets shorter and shorter until it is impossible to update occupied_heating_setpoint. I have schedule which is increasing temperature by 1 degree every hour and iTRV seems to stop responding after about 4 hours or so.
It could be that iTRV need acknowledgment within some intervals or maybe even after each message it publishes - I’ve noticed that “ADC” and “ALG” changes though there is no change to other parameters.
In my experience (firmware f60f643), repeating the initial reset until it flashes red 5 times is important. Once you’ve started the pairing process and are repeating Step 2 (restart / reset / re-pair), the number of reset flashes doesn’t matter.
FWIW, I’ve just had to rebuild my entire Zigbee network and had to go through the hack again x 3. I tried doing them in parallel but that definitely doesn’t work! Do them one-by-one. But they are all working again.
The disclaimer is that I have no special insight: those steps have been defined through trial and error until they were reproduceable so it’s possible different firmware behaves differently…
…because this, for instance, does not match what I’ve been seeing. I’m not aware of reading about that anywhere else either.
Your chart where the TRV came online at around 14:20 looks good. It’s possible it was reconnected five minutes early but I think what you’re saying is that it had already reset to 20°C even before reconnection?
This would seem to be a logical explanation.
I have my Drayton Wiser TRV connected to a Sonoff Zigbee wifi hub with Tasmota flashed, and I am simply trying to do two things:
- read the current temperature (no issues here)
- be able to set the target temperature (OMG - what a hassle)
(Bonus: just control the stupid motor directly!)
I’m actually wanting to control it from Node-RED not HA, and through Sonoff Zigbee bridge not Zigbee2MQTT but I’m having the same problems as everyone else above. I gather from these many posts above that my aims are not actually that easy to do!
Thanks to the excellent @10100011 for all the testing you did.
That’s absolute nuts. I’m going to give it a try.
1 Like
Ive been using the wiser hub for a few weeks now and the integration to HA is flawless so far.
I don’t think home assistant will be able to mimic the operating modes and energy saving functions in the near future directly with the valves…
I highly recommend investing in the hub, at approx the price of a couple of valves it’s worth it.
This, honestly, is the best advice. Thank you, @christatt, for suggesting it. On the back of this random stranger’s advice on the Internet, I got myself a few more second-hand TRVs and the Wiser Hub. Most of the house is now zonally controlled and it works better than I could either have hoped or created myself. The HA integration too is just superb.
Why did I not do this in the first place? Probably because I didn’t think buying hardware from the same provider would or should provide any benefits. Anything the Wiser software can do would surely be replicable within Home Assistant, right? Well, no. There’s some clever energy-saving intelligence which seems to do well at using the minimum amount of energy for just the right amount of heat.
It’s not 100% ideal. I’d just finished investing in a solid Zigbee network based on Z2A, which is incompatible with the Wiser kit. I now have two Zigbee networks, each with their own extenders, and that feels like a waste. The Hub itself requires WiFi, which is patchy in that area of the house and seemingly prone to radio noise from the boiler itself. And at the back of my mind is a suspicion that, if Drayton / Schneider had really wanted to, they could have made the Hub and TRVs properly Zigbee compliant instead of extending the standard for their own requirements.
But these are minor niggles. Do yourself a favour: listen to @christatt.
2 Likes
Everybody does that. That’s how you can differentiate your product from others.
There is a bug in the Hub’s firmware, it looses WiFi connection and cannot reconnect for about 2 hours. Wiser is working on a fix.
Wait until you will invest in a Hue Bridge, and use Hue bulbs with a sync box. Then you will have three…
2 Likes
Well - I couldn’t agree more. As the original OP, I actually lost sight of the thread as no-one seemed to be making progress with the iTRVs, so I bought the Hub in June '21 and haven’t looked back. I even submitted a feature-request to the Wiser HA developer to include a Scheduling card/integration - they did and it’s basically completed the setup of using HA and Wiser together as a solution.
1 Like
Hi, I have a Schneider WISER TRV which is not recognised by Z2M correctly.
I get the messag “Received message from unsupported device with Zigbee model ‘CCTFR6100’ and manufacturer name ‘Schneider Electric’”
Manufacturer unsupported and I cannot use the unit.
Does anyone have similar problems?
Hi all, I’ve had four wiser TRVs for a while now and found that they misbehave frequently with Z2M. Often they won’t respond to a new heating setpoint, and I’ve also had the problem where some of them keep reverting to 20c.
Recently I’ve been using two of them to heat a room in my house using a timer automation in HA, on at 5am, off at 5pm. I noticed a while back that if I restart the Z2M addon in HA then immediately set a new heating setpoint, 99% of the time they will respond straight away. So, I changed my automations to restart Z2M a few minutes before 5am, and before 5pm, and now they are working pretty much perfectly. No reverting to 20c either.
Thought this was interesting as I guess there’s something that changes/gets sent when Z2M restarts that is making them more responsive? I’m absolutely not an expert with this but is that a possibility?
I am running HAOS on RPi4, with a zzh! usb coordinator. Think it’s the source routing firmware as I recall.
I was having issues with my TRV constantly changing between 9.5 and 21.5 on the occupied heating set point. No matter what i did it continued to do this. I got a little frustrated and ended up resetting it 6 times in a row without pairing it any one of the times. Re Calibrating it each time. This seems to have solved this however i will come back and confirm later on today. My TRV is running the firmware version f60f643. I think for the rest of the house i will be purchasing different ones as it is very frustrating with these ones not working correctly all the time even though that is almost a given that that may happen with these kind of things.
I almost immediately regretted posting this as after i did post it it has now started constantly putting itself down to 7.5 or 7