Using a whole bunch (maybe 12) of Moes BRT-100-TRV’s with HA and Z2M. The coordinator is a ZZH CC2652R. I use Node-Red to provide the automation.
I have an automation that reduces particular TRV setpoints to 10° when a user leaves the network and returns it to 20° when they return. Most of the time it works fine but occasionally one (no particular one, just one at random) of the TRV’s will refuse to take the setpoint temp change. In fact it will refuse to take any changes, even from the Z2M UI.
I can see the commands are being executed by Z2M as they show in the log so I can only assume its The TRV itself refusing to listen ? That said, if I query the device using Node-Red it returns the device settings as expected.
If I disconnect the it from the radiator (keeping it powered) and take it back to the coordinator then it will go back to normal operation. Same applies if I remove and reconnect the battery.
It made me think it could be a signal issue but I’m well covered with repeaters and have made sure each TRV has a repeater nearby. Typically I have a LQI of 110.
The TRVs are battery powered and in order to save battery they might go into sleep for a period of time and you just happens to hit the start of such period.
Good thought but I can leave an unresponsive TRV for many hours, even days and it will not respond to any POST commands. It will respond to all GET commands throughout.
I’m beginning to think it’s fault of the Moe’s device (or it’s firmware) ? - and am hoping there is a TRV firmware guru out there that might pick up on this. I’ve heard there was an issue with firmware on these devices but can’t find any relevant info on that front.
I use these devices via zha and have had an issue once where one TRV seemed unresponsive despite being on the network. I had to power cycle it to restore functionality.
However, that seemed to be a one off. How regularly are you seeing these drop outs. 110 LQI seems low but ok.
Hmmm, thanks for the reply, that last bit has really got me thinking ! You say an LQI of 110 is ok but not great. I’ve had a look on the z2m UI and the majority of my devices have LQI’s of around 70 to 80. The worst is a lamp which has an LQI of 18 (but it seems to work fine). The absolute best on the network is 116 and that’s not the closest to the co-ordinator by a long way, the two closest to the coordinator manage 94 and 83.
Just starting to think my whole issue here might be down to LQI generally ?
The network consists of:
Endpoints:
17 x Moes TRV’s
2 x Sonoff Motion Detectors
2 x Sonoff Temp/Humidity Sensors
Repeaters:
3 x TuYa 4 Relay Switches
12 x Linkind Lamps
2 EcoDim Lamps
9 x eWelink Sockets
3 x IKEA Zigbee Repeaters
1 x TuYa Garage Door Controller
What sort of LQI do you get on average - is it substantially higher than mine ?
Thanks
I might have a couple of advantages that contribute to that:-
I live in a detached home, so little wifi interference with neighbours
Its a new build, so the internal walls aren’t brick (except for one).
I have about 30 devices in my home, with about a third of them being smart plugs (and therefore signal repeaters).
Of that 30, around a third are LQI 120-160, the second third are 160-200 and the remaining third are maxed at 255.
My worst RSSI is -66 and the best is -32
I would check wifi signal interference… use something like InSSider on your phone or pc to see what channels are in your home. Its not straightforward to move the zigbee channel once you’ve set it up, but you can easily change your wifi channels via your router.
See this article:-
Also consider a USB extension cable to get your coordinator away from other electrical devices.
I think there is a mix up of the understanding of the values here.
RSSI is measuring the signal strength to the next hop and it is normally a negative value.
With RSSI a higher value means better signal, but since it is negative values, then -10 is better than -100.
LQI is a value for signal quality.
It is a multihop value, which means that each hop will add each value and the final presented will be the sum og all hops.
These values are often positive and then a lower value is better than a higher value.
If the values are instead negative, which can also occur, then the higher values are better.
Or for both RSSI and LQI the closer to zero you get the better.
With RSSI the general rule is that lower than -90 is really bad.
With LQI the values are harder to dechiffer because a value of 270 over 3 hops might be caused by 3 hops of each 90, but it could also be 2 hops of 60 and one hop of 150.
Thank both,
I’ve downloaded InsSider and have the results but I don’t think there is anything bad showing up in there.
I can confirm my Zigbee is on Channel 11 and my Wi-Fi is on Channel 11. This, I think, is good as Zigbee 11 and Wi-Fi 11 are at opposite ends of the transmission band.
I live in a rural location so I can’t even see anyone else’s wi-fi on my network. House is old and has some decent brick walls but I have loads of repeaters so don’t think that is a likely cause. The coordinator is on a 5M extension cable and set at ceiling level, loads of distance between it and any other electrical items.
Something else I have noticed, I can’t make sense of the HA Z2M UI.
The map screen will show an LQI of (say) 170 for a device but on the devices screen it will show as (say) 92
Also some devices will have no connection to any other node on the map screen and thus no LQI is shown but on the devices screen an LQI of (say) 112 will show ? - surely the map screen and devices screen are getting their data from the same source ?
5m is actually max length for a USB2 cable and require that the cable is of good quality.
USB3 does not have an official max length,but cable length over 3m is not recommended.
I don’t think this is correct.
Both want to be as high a value as you can get, albeit that RSSI is expressed as a negative number, and iirc,can’t actually get above zero.
LQI wants to be as high as you can get and is a positive number, maxing out at 255
Seems like you are somewhat correct.
RSSI can be written from 0-255 (or a smaller value if RSSI_max is set) and the higher a value the better.
If there is used negative values then RSSI is noted in DBm and then the closer to zero the better.
I have actually never seen a RSSI value with the positive values, so when the values of LQI was accumulated then I assumed it was based on those negative RSSI values, which does not seem to be the case.
LQI use the positive numbers, which and accumulate them on the route it takes, but since vendors can choose their own scale, then I have a hard time seeing these values as trustworthy.
Three devices in a line all reporting 60LQI gives a accumulated value of 180LQI, which is the same as three other devices in another line and therefore they should be equal.
But one line is from a vendor with RSSI_max set to 60 and the other one is from a vendor with RSSI_max set to 100.
Now the line with the vendor devices with RSSI_max set to 60 is suddenly way better than the other line.
It’s been a few days as I’ve had to order stuff to implement the changes that were advised in this thread.
The upshot is; the network is much stronger, LQI’s hitting 170 and everything responding nicely !
Except… The BRT-100-TRV’s are still playing up as before. That is, randomly one of them will just refuse to accept any POST commands. They will still respond to GET requests but until it is either picked up and moved or has a battery reset it stays stuck !
I’m hoping a BRT-100-TRV guru will spot this post as I’m starting to believe this is a issue with the units rather than one of config etc.
Not sure this helps, but I noticed the other day that one of my (same) TRV’s hadn’t changed temperature. I checked the automation trace and it definitely should have, but it just didn’t.
I’ve now got another automation running on an hourly schedule to check the TRV’s are set to what they should be.
That’s a bit spooky as I went down the exactly the same line of thought as you.
I too traced the automation and found exactly the same - It should have, but it didn’t !
I also created an automation to check the TRV’s once every hour (I use Node-Red).
Since I improved my Zigbee LQI’s I have had definitely had less problems but it’s not entirely gone away. My monitoring automation has caught a couple of issues for me - with the only solution being to drop the batteries out of the TRV and put them back in.
I’m starting to think this is definitely a TRV issue and not anything we are doing (or not doing)
Perhaps you could report back here if you continue to have issues ?
Now I have the automation to correct the TRV state, I never notice. I’ve only had to take the batteries out of one of the TRVs once (I have three), so its pretty stable for me generally.
@nick4275 having the same issues with the BRT-100-TRV. Moved from ZHA to Zigbee2MQTT 2 years ago hoping it would fix my issues and it looked better but then the summer ended. I had to use the heating again and again randomly my TRV’s would stop responding to my posts.
Most of the time removing the batteries wil fix the issue but I use eco mode to turn them off for separate room heating and when the valve doesn’t open the heater keeps heating.
Sometimes after posting to the trv’s a couple of times it changes to eco mode.
So no solution here just another user with the same issues.
Sad to say, even this many months after my original post I’m still experiencing this issue. It’s not as bad as it was but it’s far from fit it and forget it ! Dropping the batteries out is still the only way I can get a rouge unit back online.
I’ve written a Node-Red flow that checks each TRV once an hour to make sure it is set where it should be and sends a notification to my phone if it’s not. This at least alerts me to a problem but its far from ideal.
I’m thinking this is an issue we might lodge with Moes ? - I’m not sure it will prove successful but we can but try. Deep down I think this is a firmware issue on these particular units but I’ve no way of proving it. - Well, except for the fact I’ve got approaching 100 Zigbee devices and it’s only these TRV’s that intermittently don’t respond !
I wanna join in here because I am in the same boat…
I have 4 such TRV´s and when i set new temp values to all 4, most of the time there will be 1 that does not accept them and freezes…always another one…usually they start to respond again after a few hours (or if i swap the batteries).
Those MOES TRV are the most problematic devices I have. The batteries connection plate often do not make a good connection, the plastic element to connect to the heater broke very easily (6 out of 8 I have broke in the first months, I had to 3D print myself the spare parts), sometimes they go crazy and you have to remove the batteries and as said in this topic sometimes they do not get commands.
This make them quite useless as I cannot trust them to heat the way I want.
On top of this ZHA only expose few antities so I had to use a quirk which exposes more entities but most of those doesn’t seem to work to me. Zigbee2Mqtt exposes much more entities and those seem to all work but I don’t want to migrate my ZHA network just for those Moes.
Just to save you any work…
I don’t think changing to Zigbee2MQTT will help you as I use it and the problems we are having is the same on this platform as well. You’re right you do get more entities exposed but they still lock up as you’ve described. Which to my mind suggests the issue is with the devices and not the software platform.
