Simple Z-Wave Custom App or Driver for Command in Log

[mikage.kun]

I'm trying to get a Z-wave contact sensor with relays to properly monitor an LED indicator on a "dumb" device. More details on that project in this thread:

Driveway Sensor + Contact Sensor with External Switch Contacts

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 bec…

My issue is that the contact sensor appears to pick up changes in the LED indicator, but doesn't reliably change the status of the sensor in response. I enabled debug logging and isolated the following line from the log, which shows up each time the monitored LED blinks on or off:

parsed 'zw device: 19, command: 3003, payload: 00 , isMulticast: false' to null

If I'm interpreting the above correctly, my contact sensor, which has a device ID of 19, received a command of 3003 and a payload of 00. In response, it did nothing (null).

I am completely new to coding any sort of driver or app for Hubitat. I see examples, but they appear to be a bit more involved that what I'm trying to do. I envision the app working like this:

"When device 19 receives a command of 3003, with a payload of 00, set a switch to on."

I could replace "set a switch to on" to "set a variable to" as well. My goal is to in response to the command the log shows, give me something I can use as a trigger for a rule. Think of it as:

LED flashes on/off -> Device 19 receives command 3003 with payload of 00 -> Custom App/Driver Sets Switch -> Switch turning on is a trigger for Rule

[bertabcd1234]

The easiest option would probably be to find a driver that just works-as is. If the specific contact sensor you're using is on the list of compatible devices with a recommended driver, try that driver; otherwise, you could try a few other Z-Wave contact sensor drivers to see if any interpret the data the way you need it for this sensor. You could also look at the device manual to see if there are parameters you could set that might affect device behavior/reporting. If you're using "external" sensors (hooked up to inputs the device provides for this purpose), some have different options you can set that affect how they work — and then maybe they'd work with the current driver.

Otherwise, your interpretation of that log is basically correct (19 is the Z-Wave node ID; 30 is the command class, sensor binary; 03 is a report, so a sensor binary report; and 00 is the value). However, apps do not have access to driver logs, so you won't be able to write a rule (or a custom app) that works directly with this information — it's the role of the driver to "translate" this into events as needed. It's certainly possible to make a Z-Wave driver (see: Building a Z-Wave Driver | Hubitat Documentation), but I'd be surprised if there weren't already one that could handle this, or least something out there that could be easily modified to.

However, if it's the Schlage contact sensor mentioned in the other post, I don't have one, so can't be of any specific help with testing the device, driver, or external contact scenario.

[velvetfoot]

I'm not sure what you're doing, but I believe there is a z-wave sensor that will monitor led status, and colors too I believe. I even have one, but it's still in the box.

Homeseer wd200.

[mikage.kun]

@bertabcd1234

The easiest option would probably be to find a driver that just works-as is.

I've been trying this by swapping out the driver for the device with various generic Z-wave device drivers, but with no luck so far. The primary issue I believe is that I'm trying to do something that most driver's likely try to AVOID, which is over triggering of the sensor.

The LED I'm trying to monitor with the Z-wave sensor has it's own quirks. When the receiver initially detects a vehicle, the LED flashes a few times (on and off) before going solid. The receiver is intended to be manually reset, by pressing a reset button. If it's not reset, the LED stays lit. However, when the sensor is triggered again, even without a manual reset, the LED flashes a few times. From what I can tell playing around with it, the Z-wave sensor will trigger properly when the LED goes from fully off to fully on, as in, from a receiver manual reset to the next activity. The sensor is picking up the flashing, as evident in that snippet from the log, but it doesn't trigger the sensor to change states. Likely this is intentional, since quick blips in power to the Z-wave sensor's relay aren't something you'd typically want to trigger if used as a contact sensor, for fear of false alarms.

The generic Z-wave Contact Sensor driver has a setting that can be switched on to avoid over triggering, but I've found having it off or on doesn't resolve the issue.

However, apps do not have access to driver logs, so you won't be able to write a rule (or a custom app) that works directly with this information — it's the role of the driver to "translate" this into events as needed. It's certainly possible to make a Z-Wave driver (see: Building a Z-Wave Driver | Hubitat Documentation), but I'd be surprised if there weren't already one that could handle this, or least something out there that could be easily modified to.

OK, so that eliminates one rabbit warren: it's a driver I need, not an app. I guess what I really need is, as you stated, something that already handles this or could be easily modified.

However, if it's the Schlage contact sensor mentioned in the other post, I don't have one, so can't be of any specific help with testing the device, driver, or external contact scenario.

I'm happy to test out anything anyone can recommend. Not saying it's something everyone would or should have, but I found this sensor appears to be something various companies either nearly identically copy or simply license under their brands. I've seen what appears to be the same sensor under 4 different brandings. Also, I really have no intended use for the sensor except to report when the LED changes states, even if it's just a quick flash on and off. If what I'm doing ruins this sensor for anything else, it's no loss to me.

[mikage.kun]

It looks like this is a switch that would be permanently installed in a wall. I'm not sure that's ideal for this purpose.

I did see some rather low-tech workarounds people have used. It appears there are some wifi-based noise sensors that are intended to be placed next to an otherwise "dumb" smoke alarm. That might work, but other than seeing these products talked about in some older Youtube vids, I can't locate them.