In some rules I have, the trigger is a sensor state change (open/closed/changed), then within the rule I test the trigger again after a delay (and maybe a device refresh.) In other cases I set a hub variable to true or false to determine the first time through a rule. The trigger is sensor state and firsttime=true. Then I set/reset firsttime in the rule.
Though this makes sense to me, it unfortunately won't resolve the issue. Looking at the device activity events, the rule doesn't trigger because the state of the sensor never changes, whether the trigger is active, inactive, or simply changed.
I think this is related in some way to the manner in which the activity LED on the receiver functions. If activity on the receiver is sensed for the first time, the activity LED blinks briefly, then turns on solid. It stays lit until a user pushes the physical reset button on the receiver, but it will flash on and off if activity is detected from the Mighty Mule sensor, even if the reset button isn't pressed. Monitoring the Z-wave sensor activity closely, I see it will go to active when the LED lights up for the first time, then goes inactive upon the LED flashing, then stays inactive until I push the reset button. I could push the reset button, but it sort of defeats my purposes to have to physically reset the receiver each time.
I enabled logging again for the Z-wave sensor, and monitored it closely. I know logs can be hard to decipher, and often they include traffic that is just routine. However, I see this one line that keeps coming up:
parsed 'zw device: 19, command: 3003, payload: 00 , isMulticast: false' to []
This line only appears to show in the log when the receiver notes activity (LED blinks), even though it does nothing to change the state of the Z-wave sensor.
Is there a way to use that activity, noted by the log, as a rule trigger? Checking Rule Machine and the standard rule interface, I don't see anything giving that granular an option.
