To make things more confusing, there's also motion blind time, but I've only seen a couple devices that expose it.
Motion Blind time determines how long after a motion event you can keep moving without it resetting the motion clear counter.
For example, if blind time is 0, motion clear time is 10 seconds, and you move in front of the sensor for 3 seconds, the inactive event should occur 13 seconds after the initial motion event because that 10 second timer would have kept getting reset during the 3 seconds of movement.
If blind time was 5 it would have ignored those first 3 seconds of motion and the inactive event should have occurred 10 seconds after the initial motion event.
I wrote all of the drivers I'm using for my GE devices, so I'm pretty sure I know what messages the hub is getting from the device.
And you are right, I don't log duplicate events. I only log the notification report (typically). So to your point, those devices ARE sending more than one event too in most cases (there are a few weird ones, but that is another story).
So that was a long way of saying, I agree with Kevin. lol
A lot of drivers probably only log messages when the value changes which makes things look clean in the logs, but a device could be flooding your mesh with reports and you'd never know it...
Update: It turns out this assumption was incorrect and most of the built-in drivers do not suppress duplicate logging messages.
Actually, there's very few drivers that include this sort of code, and it's there to deal specifically with devices where we have no other way of shutting them up...
I did some testing and watched the traffic with a z-wave sniffer and my 3 statements above are correct.
I also noticed that when you keep moving your hand in front of the sensor it doesn't just send motion active reports every 6-8 seconds, it also flashes the LED at that interval.
It all depends on which logging we are referring to, and whether the new value is a state change or not. I believe Mike that debug logging isn't normally suppressed - that certainly matches what I've seen - but repeat events that aren't state changes will have hub side event log and descriptive logging suppressed.
The platform suppresses duplicate events so unless the driver is overriding that behavior you'll only see unique events on the Events screen, but the descriptionText logging is handled by the driver and for most drivers those don't get suppressed.
Yes, the driver does the descriptive (and debug for that matter) logging, but I thought most of the in box drivers chose to only make a descriptive text log when a new event was created.
But I'm not in a place to test it, So I'll take your word for it.
I was under the same impression, but I did some testing and the generic z-wave contact sensor appears to be one of the only drivers suppressing duplicate description log messages.
That's really not a big deal because it still shows duplicate debug log messages which will allow you to see if a problem device is sending too many reports.
duplicate attribute values, unless sent with isStateChange: true (which must be done for button controllers obviously), are dropped before being committed to the event system...
UNLESS, the subscribing app has a subscription with filterEvents: false...
textDescription logging in probably 90+ percent of the drivers does not check existing attribute values prior to dumping to the live logs...
In cases where the device can't be configured to send one report per event we may check the relevant attribute value prior to sending the description log and or the actual event, this is nothing more than a diaper to deal with what I consider to be a sub-par device...
It's more than likely that there are driver/device combinations out there that do generate duplicate live log entries, but when drivers are tested with the fingerprints we support, the goal is to report what is received, and to not need to dink with the events ect...
In fact I feel so strongly about a device reporting properly, that a vender submitted some new versions of their existing switch and dimmers for inclusion with the platform driver set.
Both off these devices submitted two separate zwave class reports for on and off, and the dimmer sent multi level reports whilst transitioning from one level to the next.
None of these reports could be configured via association groups or parameter settings..
I refused to support these two devices until this issue was resolved by the supplier.
Supplier has since made these changes in firmware, and we have now agreed to support these.
I 100% agree Mike, I personally have been known to watch logs occasionally when I get bored, just to verify everything is operating as it should (quality control for justification purposes) I also use this to "fine tune" rules for example what temp in this room is best
It is very irritating that if you're trying to monitor a specific device, the logs scroll it off the screen before you even see it from other devices that literally are not providing any "new" information.
So I picked up 3 of these as a way to replace my present household temp monitoring. The interesting thing so far is that when I first pared them, I didn't get any dups. Right after I set my configs, it started.
