Weird subscribe() behavior?

For better or worse, all of my LIGHTIFY bulbs are on Z-wave switches. I wrote an app that subscribes to the switch and turns the Osrams on when the switch turns on, and off when the switch is off. Physically, this does nothing, but the ST Hub stays in better sync with the state of the bulbs.

This app has worked great for months, but then today I noticed that the app was working great for switch.on subscriptions, but did not recognize switch.off. I did extra logging and verified this extensively. After numerous uninstall, reinstalls, I did get it to work.

One thought I had was perhaps the Z-wave switch was not reporting the off (it was definitely executing), but the on() was just fine.

Anyone have any ideas? Are there limits on the number of subscriptions?

Not that I can tell. I have an app with 30 or 40 subscriptions, no problem.

One thing you might mess around with would be to subscribe(x, "switch", y) instead of switch.off. Then in the handler add the logic (and log.debug) to discriminate between on and off. That might shed some light on what’s happening, or not happening.

1 Like

Hi Bruce,

That is exactly what ibam doing. I will dig more today. I think I’m approaching a few hundred subscriptions globally

Kristopher

For posterity – It seems I am indeed having a z-wave problem. The on() and off() must hit the parser before getting updated via the event. In short, my Hub was sending the signal fine, the device was receiving it, but the round trip confirmation was not making it back for all commands.

I confirmed this by spending way too much time trying to repair the network. @bravenel your other posts were very helpful in this coincidentally. I was able to trace down a single misbehaving switch, but unfortunately orphaned it and now my z-wave radio is completely hosed. Fingers crossed that ST can fix that for me…