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.
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.
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.
Question:
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?
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!
The technical details both of you can access and interpret are way past my capacity, but I'm grateful for your having posted them because I'm getting set to replace my ecobee. Your posts go a long way toward reducing my jitters.
Nah, this is the easy stuff. It is when things DON'T do what they are supposed to/follow standards that you need experts like mike & co. I'm just a rank amateur.
Side note, I'm sending Mike one of my extra devices, so hopefully someday in the future it will get an official in-box driver. He always has a healthy backlog of devices, so it may be a while. But as it seems pretty well behaved from a standards standpoint, it might not take him long to crank it out when he does get around to it.
That said, many will still want to use the user driver so they can bias/set the battery voltage range, battery replacement date log, and humidity offset (two things Hubitat hasn't ever put in their in-box drivers that I can see).
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.
