Iris Motion V3 iL07_1 humidity reporting frequency , errant device?

Thanks ALL.

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 :exploding_head:

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.

1 Like

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 they do that by some decree of Zigbee and Z-wave standardization.

Short answer is 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.

1 Like

Ah, perfect.

Thank you!

1 Like

Mike -

after upgrade,
changing this setting,
SAVEing Preferences,
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 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. :slight_smile:

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.

1 Like

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.

The jury is still out on battery life but the new HE features allowing setting less frequent reporting bode well for stretching out the battery life. So far these sensors have worked well for me indoor and in protected outdoor set ups.

This guy is where many have bought Iris surplus:

Myself as well. Out of the 20 or so devices I purchased, only 1 had an issue, and they promptly replaced it, zero hassle, and he will accept some lower offers

I realize this is an old thread. Is there any chance that the developers would include the ability to adjust humidity offset on the generic Zigbee motion/humidity driver?

I know there is a community driver out there for the Iris v3 motion sensors that allows this functionality, but the polling period for the humidity isn't quick enough to turn my bathroom fan on.

The generic motion/humidity driver does great for catching the humidity increase rapidly, but if the sensor's humidity reading is off there isn't a built in way to adjust that.

I know I could setup a virtual humidity sensor for the adjustment, but I wondered if life could be made easier by including the functionality in the generic driver?

Thanks in advance for reviewing!

Actually, this brings up an interesting point. Maybe somewhere we should have a big honkin table where we keep a list of all devices (beyond the HE Compatibility list) and some star/grade system on various common features.

I guess the problem with that is managing the consistency of ranking and keeping up with all the versions...but it would be helpful not to have to search the depth of threads & posts to discover what the "community experience" is with ABC Device with respect to it's:

a) radio (staying paired),
b) parameter #1 accuracy & responsiveness (and/or reporting)
c) parameter #2 accuracy & responsiveness (and/or reporting)
d) parameter x......etc.
e) battery life

I know some of this "depends on where, what, and how" these devices are used/placed and maybe the driver being used...but I think coming to some common ground to tallying the experiences on would offer a slightly better perspective than the time weighing some # of posts.

Download the Hubitat app