Installing my third of these devices bought from our familiar EBay source.
I woke today to see a log full of humidity reports every 5 minutes from this latest installed unit with many being the same 51% back to back. Do tenths of % changes cause reporting or is reporting a timed frequency occurance?
Coincidentally I have an HSM Alert on a custom humidity app where I have two of these units being checked for humidity over 80%.
A previously installed unit WAS validly 84% this morning but it was the newly installed 51% reading unit that got posted in red on the HSM app. The HE notification correctly conveyed the 84% unit. I just noticed a new alert after resetting that posted on the HSM app banner from the now 85% unit so why the 51% showed in the first place is a head scratcher.
from my log it appears to report when there is a change of 1% or more, as I see updates 4 mins apart when there is a change of 1%
platform 2.2.4 will have new humidity reporting options for this device when using the Generic Zigbee Motion/Humidity Sensor driver:
Great, looking forward to it. That'll clean up several things with my use of the Iris Motion V3 iL07_1 to drive bathroom fans.
And that bathroom fan idea is good.
This latest one I put in was to monitor temperature & humidity for plumbing breaks/leaks in a confined crawl space where traditional water sensors would have to be placed in too many locations. The humidity stays very constant and I had set the trigger at 80% but these % deltas Mike showed would be EVEN BETTER.
A 10% change in a short amount of time would for sure indicate a problem.
P.S. Why in the heck am I using the Iris Motion? 1) cheap, 2) seemed reliable so far, 3) multi-function, 4) the damn squirrel I also want to be alerted to
Mike.....Please put a 10% delta in there too.
In hind sight this is just a reporting thing...I can still use my 80% constant setpoint for triggering....although if the space had creeped up from 50% to say 60% ambient humidity...and then in less than a half hour jumped to 70%, my setpoint of 80% would let a lot more water under the house before I got alerted. Of course this is a backup indicator...but still.
OK, I'll add 5 and 10% too
Excuse the need for clarification of the obvious but...
Can HE's "configuration upon discovery" always set the terms (what and how often) that a device communicates what it is sensing ...AND so in programming a "generic" configuration/driver you are dependent on a collection of similar devices to abide by a similar standard of behavior to be so commanded. And if so...do they do that by some decree of Zigbee and Z-wave standardization.
Short answer is fine...no need for a full blown short-course.
Thanks in advance.
One of the main differences between Zigbee and Z-Wave being the Zigbee HA spec defines the interface and parameters for reporting of any given attribute, so this is completly portable across devices supporting the same clusters (think features).
While many Z-Wave devices have configurable reporting, the interface and parameters for this are left to the manufacturer to determine and implement.
So yes, these parameters are set to reasonable defaults upon inclusion, but are configurable after the fact as well.
Another Zigbee difference is that with few exceptions all battery devices wake up every 7 seconds or faster to check for pending commands.
changing this setting,
the device would need to be re-CONFIGURE-d ???
In order to get the new reporting frequency/threshold setting right?
I do this whenever I driver changes (or I change the driver) just out of habit. I think that is the suggested thing to do in this case.
I did it when I switched to this new driver on the V3 iL07.
Makes sense. It is a modified driver. Wonder how often folks get new driver features with an update , select some of the new options, Save Preferences and never realize to Configure the device. Like you said....yah just learn to do it.
I don't see anything in the Device Details that would confirm the Configuration state or version.
One could go along unwittingly "out of sync" w/ the most current driver which would be impactful if there were bug fixes instead of visible feature adds. No?
This is likely talked about elsewhere.
When changing from one driver to a different driver, it's generally required to click configure.
When changing preferences of a given driver, save preferences is all that one needs to do.
Clicking configure after saving preferences may reset and or remove some of the preferences that were saved, this is down to how the driver was written, and therefore should not be executed as standard practice after saving preferences.
So in this case, where I was hoping to force a reduction in the "reporting chatter" from the device, and thus maybe battery consumption on a fairly hard to access device, does Save Preferences get communicated to the device to inact that?
And this got me changing the temperature reporting on some various contact sensors....and I got to wondering...do all these different devices accept being told to report at a different temp differential. Do I understand the effect of that setting correctly, is it the device that changes behavior or just HE reporting?
Yes, most battery zigbee devices check for commands from the hub within a few seconds.
Yes, these are device reporting commands.
Disabling or decreasing the reporting of specific attributes will increase battery life.
I was hoping for a Humidity Offset setting. None of mine report even close to the same.
Thanks for your time ,
appreciate the tutelage.
I've kinda been impressed that mine are frequently within 3% of each other... and those that aren't usually have an environmental reason for not being so. I've never seen any specs that state what we should be seeing +/-1%, 2%, 5% ?
Wonder if it is worth the effort to maintain a table of devices and experiences along these lines.
I've been looking for a good humidity sensor to control my home humidifier. It sounds like the repeatability of these has been acceptable in your experience? What about battery life? And what is this eBay source you mention? I prefer to use devices and vendors that come with some "endorsement" from other users.