Has anyone tried using these? They are all over eBay and for crazy cheap (~$4 a sensor). They seem to be compatible with Z2M, but they don’t do anything fancy like temp, humidity, or lux. For that price though, I won’t hold that against them if they are fast on reporting open and closed.
I am trying to find something to replace my iris gen 1 sensors and am not trying to break the bank. One thing that I liked about the iris sensors is that the cross section is basically a square so it becomes a lot more adaptable for odd use cases.
The gen 1 iris sensors had a weird not so zigbee aspect to it that requires additional programming. I’d guess as long as they’re not in that realm, they’d be a steal depending on use case. Given things are shifting to Zigbee 3.0, though, are you sure you want to make that leap? Do your research before you buy so that they don’t end up in the drawer of shame.
What is the real difference between Zigbee H.A. 1.2 and 3.0? Looking online it looks like it is backwards compatible but who knows with the world of Matter looming over us. It also looks like it has temperature sensing, but just not via Z2M for some reason?
About to replace my Zen thermostat (Zigbee 1.2) with a LUX Konoz (Zigbee 3.0). Since the switch to z2m, the Zen has been a nightmare. Responds to published set commands < 10% of the time, doesn’t obey my preferences for reporting intervals, yet the link quality is good and the connection to my Sonoff stick is direct. C-wire is connected, so it’s not using battery power. Still, it behaves like a sleepy end device and refuses to collect and process values that are set with persistence.
My conclusion: Zigbee 1.2 doesn’t play all that well with z2m, at least as far as thermostats go. I’ll know for sure once I get the Konoz installed. Have been holding off on the replacement until my Inovelli Blues get here, for no real reason.
May just need an update to the converter, if it is there, it can be used.
There may be a configuration command which needs to be sent which the converter in z2m isn’t sending, have you looked for any tickets in the z2m repo regarding this device?
So back to the OP, @markus does anything jump out at you when looking at those contact sensors as far as compatibility. Response time is basically impossible to judge without first hand experience, but the lack of the temperature reporting tells me that not a lot of people are using this device in the Z2M community.
As long as they truly are HA1.2, which they seem to be, they should be fine, and at that price they’d be hard to beat. I’ve never had a slow zigbee contact sensor, so it’d be a strange thing to find.
Got 2 lots coming, been burned before with these lots of devices going away fast (Iris motion sensors and plugs), so 20 should be plenty for the foreseeable future, and I will report back (probably only once I take delivery of my new Inovelli Blue’s).
If anyone else has first hand experience of these, please feel free to chime in.
I also bought 10 last year, wound up using 1 on a C7. It reports fine, temp included. Battery is still 100% after a year with a very active door.
PS-They’re cheap for a reason, they take CR2450 batteries = expensive, at least double Cr2032
I have tons of the older model MCT-310 and they are super reliable on HE. Surprised the one you listed doesn’t have temperature. The MCT-310 does have temp and use cr2032. Very slim sensor
Just took delivery of all 20 sensors and they came in the original box with the batteries which was great. They paired almost instantly and to my surprise the temperature reports even though their docs say it shouldn’t.
Response time doesn’t seem amazing but it is less than half a second so that is plenty good for me.
Overall I am very impressed especially given the pricetag.
Being two hours in, I wonder if you could keep us up on how these do in your mesh. Especially when you get several fired up and placed. I remember that the peanut plugs and Cree bulbs were ok up to a magic number. At which time the
So I’m curious and hopeful that these will make that cut. I’m a bit surprised that they would have that much latency. I’ve never known zigbee to be really “slow”.
Will do, currently just in a testing phase with core as I am waiting for innovelli blues to jump in fully. Currently I just have my software hosted fully on core, but hardware wise basically only 3210-L plugs.
Currently I have replaced all of my Iris Gen 1 contact sensors with these and so far so good. I know I know, for a good mesh you should do all powered devices first, but signal quality looks okay so far and zigbee heals over time right so as long as I do not go crazy, it should be fine .
Side note: Who in their right mind thought that a minimum report time for temperature of 10 seconds would be a good idea. One of my sensors is now down to 25% before I figured it out. I have since changed them all to 10 minute minimum report time so hopefully the others will stay at 100% for a bit longer…
So I have been having a lot of battery issues with nothing staying at 100% for more than a day and dropping as low as 8% after 24 hours. Do you think it could be due to my small mesh or do you think it is more likely the reporting settings?
These are the two reporting settings that come by default:
The z2m reporting model for battery is an algorithm that is overly pessimistic. I changed mine to report minimum of 12 hours maximum of 24. Wake them up before you update them. Like physically go and trip them. then hit send or update. I’ve had devices showing 8% for months. It’s voltage. And it’s like .5 on the scale from new to dead. Not overly accurate.
End devices must be woken up before issuing changes to those settings or they will not actually be taken into effect . Also not all devices respect the proper way to issue that information.
I am not positive but I believe I recall reading that the xfinity sensors use their own custom zigbee commands that have NOT been figured out and ported to Z2M, so anything beyond basic reporting is basically a no go with them. They respond that they receive the command, but nothing actually changes.
Also as april mentioned the way the power levels on these devices are determined is by available voltage not remaining current capacity so they are not very accurate. You will see vastly different numbers between Z2M and HE etc because the hubs tend to implement their own scale for the batteries remaining life to make it more realistic.
This is something I have mentioned to markus and april, and is something that will likely be implemented in the future once Core has a UI. However Z2M will likely always have wonky looking reports unless koenk implements a power level adjustment curve
That being said, the combo of type of battery and device used can make a vast difference in what is reported as well.
I have some batteries that put out a good voltage and read 100% until about 3 days before they die when they start reading 80%. They die still reading at 80%.
On the other end of the spectrum I have some drop to reading ~64% after 2 days, 20% after 5, and report 5% after a week, but will last for 9-12 months reporting 5%.
The only real way to gauge your battery life is making a note when you change a battery and comparing when it dies, or using device history (grafana etc) to see when the battery was last replaced (when the voltage went up) and comparing to the next.
Can this can be the case even if the z2m UI shows the change is present? If so that is kinda sketchy. How are we supposed to know if the change went through?
If you reload the Z2M interface after you clear your cache/do a hard refresh of the page (ctrl-f5) and it shows the new setting then I believe it is actually set on the device. I got rid of all my devices that didn’t respect commands so I no longer have one to check and know for sure :./
If the device respects the get commands then using the appropriate ones should return the actual setting on device.
.
