If it helps any, generation 1 Xiaomi motion sensors (Mijia) don't like channel 25.
FYI - I couldn't connect the sensors on channels 17 or 18. They connected fine on 15 and 20 - so it does seem like 15, 20, 25 are required to use the devices.
Sorry for the delay. Just got around to looking at their reliability to measure Relative Humidity.
Where there's decent air-flow, they seem to be within 5% of a consistent Fluke digital psychrometer. I would call that pretty good. However, as with anything that measures relative humidity, they're off in rooms that don't have circulation. Takes them about 30 minutes to equilibrate once a fan is turned on.
I'm calling the Fluke consistent because I've been using it measure/adjust humidity in anaerobic chambers for ~5 years, and our experimental outcomes at preset relative humidities have been very reproducible.
Thanks. I agree, Fluke is the standard I trust, no matter the measurement.
With the requirement to switch Zigbee channels (not keen on changing what is not broken for a single device), I’m leaning toward a Centralite since they’re available still. But oddly the Xiaomi has not dropped since I first inquired about the Konke. I moved one of the Xiaomi plugs back to its first location for a completely unrelated reason and since then the Xiaomi temp/humidity/barometric sensor has been stable. Might have been the issue for me.
Time will tell. Much appreciated effort on you part though
Also, I checked the Xiaomi sensors I have. They're just as reliable as the Konke's. Konke's respond a little quicker. Yeah, the restriction in channels is just a bizarre design decision.
So how often are you guys seeing the battery % update?
Next to never.
Same here. I have one that has never reported. lol.
Temperature and humidity accuracy, and sensitivity to change, seems as good as the Xiaomi Aqara though. I have 3 Konke I put about 2 inches away from the existing Xiaomis in their respective rooms, so it is easy to compare.
@muxa One issue with the driver. Is there a way to get more resolution on the battery reporting? It seems it only reports to the tenth of a volt, and that isn't enough to measure actual battery % as the different of 0.1 volt is almost 50% difference on battery reporting... We really need it to go to the hundreth place.
Unfortunately the device reports voltage with 0.1V resolution. In fact this is per ZigBee HA specs:
184.108.40.206.3.1 BatteryVoltage Attribute
The BatteryVoltage attribute is 8 bits in length and specifies the current actual (measured) battery voltage, in units of 100mV.
Yuck. Ok, well that's pretty useless then. Thanks for checking though!
That is one negative versus the Xiaomi - they report to 10mV (or maybe 50mV.... I forget).
That makes sense... If it only reports in 0.1v increments, then the battery will have to go down 20-30% before it reports a new value again (depending on where it started). So if the battery life is 2 years, that could be months between reports.
I did change my copy of the driver to make all battery reports state changes.. So if it is reporting in periodically, and the duplicates are getting dropped, I'll see that soon.
Just FYI - when paired correctly/fully the Konke temp/humidity sensors report battery voltage every 2 hours. Seems excessive, but that's what they do (not sure if it could be changed via the zigbee reporting command).
If it isn't reporting at all (not even once initially) it probably didn't pair 100% correctly, and you might try repairing it.
If it reported at all but then stopped, it is probably fine and is just reporting the same value over and over which gets dropped as a duplicate. Since it only reports in 0.1v increments, I wouldn't expect the battery # to change often... Well, unless you modify the driver and make every battery event a State Change like I did.
I just got two of these to see how they work. They apparently matched the fingerprint of my custom Spruce Sensor driver, but I changed one to the Xiaomi temp/humidity driver (saw someone try that, possibly in another thread) and changed the other to the Generic Zigbee Motion/Humidity sensors since that's the closest thing I think Hubitat has to something like this. Both are working fine. Are there any oddities that the custom driver solves like it does for the way Xiaomi devices send some messages?
Also, I'm on channel 20 so can't test pairing to others, but my Konke motion sensor didn't like most channels. It also doesn't report "inactive," as mentioned above, unless it just needs the right configuration sent to it to do so (that part of Zigbee is over my head). I'm slightly more impressed with this sensor so far.
I've been tinkering with the user driver a bunch the past few days... I don't really see anything special in it that would be an advantage over the generic driver, other than the ability to log battery changes (which is nice), and customizable battery range and humidity offsets.
These devices seem to be a lot more standard in terms of zigbee clusters and responses than the Xiaomi (no custom byte swappers or length cheaters needed). I've been re-writing it from scratch (for learning reasons, not because there is anything wrong with this user driver!), and so far haven't used any custom parsing.
If I get my tweaks working, I'll publish them at some point. Messing with making the reporting interval and delta configurable right now, adding configure command back in to do re-binding if device gets lost, etc.
Not sure if I'll get it working though - I'm not as good with zigbee drivers. For instance, my battery hasn't reported at all since I changed the reporting interval. But I noticed that when you change reporting on battery, it doesn't report anything for like a day anyway before starting regular reports, so I might not have waited long enough yet.
I paired one of these things, and immediately put it in my freezer.
I haven't had a report since 9:00am this morning (12 hours ago).
Is it dead?
Might not be dead, might just not have enough signal to get out... Don't know, never tried putting one in the freezer.
As an aside, I'm going to guess that, unlike the Xiaomi devices, the Konke temp/humidity sensors do respond to Zigbee reporting configuration. Here's one where I'm using the Xiaomi driver, which I'm guessing sends nothing to the device for reporting intervals:
And here's one where I'm using Hubitat's Generic Zigbee Motion/Humidity sensor driver:
These reporting intervals are farther apart and consistent with what I'd expect from most Hubitat-configured devices like the Iris motion sensors. The difference is even more stark with humidity, which seems to get reported even more often on the former. I can't really compare since they're in different locations, but a quick look at the resolution of the curves on these graphs suggests that the unconfigured/default-configuration one is reporting a lot more frequently than the other. I happen to like that behavior and wish we could configure more devices in Hubitat like that. But that's another story...
In any case, I guess just another data point for the fact that these behave differently from the Xiaomi sensors. Unfortunately, the channel issue remains. Win some, lose some, I guess.
I confirmed today that it does indeed honor the zigbee configure report commands (at least on battery) - which is cool. Based on your data collection, I feel it is pretty likely it supports temp/humidity reporting configuration too. So I'll keep fiddling around and see if it makes sense to make a more feature rich user driver or not.
Other than the weird channel restrictions, this device seems pretty standard compliant. Very nice!