Driveway Sensor + Contact Sensor with External Switch Contacts

[mikage.kun]

I've done my best to implement this DIY solution myself:
https://www.youtube.com/watch?v=8Mszg0qecgk

How to connect a Mighty Mule Driveway Alarm sensor into your smart home system

Some differences to note from what the video shows:

• Contact sensor is branded as Schlage. It appears to be identical to the one in the video though. I assume it's a model that licensed under multiple brands. The enclosed instructions also list branding of Nexia and Ingersoll Rand.
• Hubitat! - Of course. The video uses Smart things. I think this might be where I’m running into my issue.

I have everything wired up as seen on the video and, for the first few hours, it worked like a charm. Any time the receiver had the activity LED blink (on or off), the status of the sensor would also change. I used the status change as a trigger for a rule to send a notification to my phone, and to several speakers in the home. Speakers and notification worked. In fact, it all seemed to work, until the next day.

A day later, and it seems the rule fails to trigger. I see the Schlage sensor light up due to a change in power flow from the LED on the Mighty Mule receiver. However, the status of the sensor per Hubitat hasn't changed. This is where it gets odd. Sometimes, triggering the Mighty Mule receiver will change the sensor to active, sometimes inactive, and sometimes…no change. I'm assuming this is due to the "delay" the video author references, but I'm unsure how to set that up. Clearly the LED flashing at various times is changing the sensor state, but maybe it changes so fast the sensor doesn't report it to Hubitat as a status change?

I turned on debugging and noticed even when the sensor's status doesn't change, I get some activity in the log from the sensor, as follows, seemingly in response to the LED flashing due to the receiver being triggered:

Is there a way to use any of the activity in the log as a trigger for a rule? Any advice is appreciated.

[FiveNines]

I am unsure about the log activity – maybe it’s the contact sensor periodically checking in.

Can you post your rule?

I use the Ecolink DWZWAVE2.5-ECO contact sensor for similar uses (but not your particular application), so it should work.

A thought, if you connected the sensor to a hot circuit (the MM LED circuit), that’s incorrect. The contact sensor sends current over the external contacts and a switch (like a float or magnetic switch) would close to complete the circuit. You might need a relay - Zooz ZAC98.

[mikage.kun]

I used Rule Machine:

I don't think it's the rule itself though. The issue is the trigger. My only options with the sensor as a trigger are Active, Inactive, or Changed.

A thought, if you connected the sensor to a hot circuit (the MM LED circuit), that’s incorrect. The contact sensor sends current over the external contacts and a switch (like a float or magnetic switch) would close to complete the circuit. You might need a relay - Zooz ZAC98.

Is that what the author of the video did? I wired mine the same way.

[FiveNines]

Changed will trigger notification with every change. Try active (closed?) or inactive (open?) My Ecolonk sensors are open or closed.

Per the video, the contact switch is wired to the LED circuit. For the LED to light, it must have power (voltage and current.) Both the MM and the contact sensor are providing power. It is possible the MM is overloading the sensor.

The LED is connected to a relay (thus it flashes when the relay is cycled.) If the contact sensor can handle the power, then the relay will also cycle the sensor. It is possible the relay cycle speed is too fast for the sensor.

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.

I am surprised MM has not included dry contact terminals. That would solve all issues.

[mikage.kun]

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.

[mikage.kun]

Today, I stumbled upon the most...stupid solution?

As I mentioned before, the Z-wave sensor acts rather inconsistently after the initial detection of a vehicle. The reason for this is the LED for activity comes on and stays on, only with some brief flashing, unless someone presses the big reset switch on the receiver. The flashing isn't enough to cause the Z-wave sensor to reliably report changes in states, and resetting the receiver every time manually is far from ideal.

I was surprised to pull out of my driveway today and receive an alert through Hubitat, as though the sensor was working properly. I was puzzled on what had caused it to suddenly work, until I recalled one thing: I experienced a power failure today. Checking the receiver, I confirmed, unplugging the receiver, even briefly, is as good as hitting the reset button. Even when powered back on, the activity light is off, ready to come on when the receiver gets an activity signal from the Mighty Mule device in the yard.

I've installed a zigbee power outlet on the receiver now, and the sequence of events will work like this:

1. Activity indicator light is off, and thus the Z-wave sensor reflects a closed status.
2. A vehicle triggers the receiver, causing the activity light to turn on and thus the sensor switches to an open status.
3. The open status triggers my rule in rule machine.
4. My rule causes my alerts to fire AND instructs the Zigbee outlet to power cycle the receiver.
5. Upon losing power, the receiver's activity LED turns off, and the Z-wave sensor reads a closed status again.
6. The receiver resets due to the power cycle, and the LED for activity remains off. The Z-wave sensor thus remains in a closed status.
7. When the receiver is triggered again, the activity light comes on and the process repeats.

It seems silly, but this solution works. I knew it would be a hacky solution as it is, but as long as it works reliably, I can live with it. I still wish I could figure out my own custom driver, but this will do for now.