I've been getting some very weird non-actions lately. Here is just the most recent one. I double pushed the off button on an Inovelli Red dimmer and while the Hub saw it, per the below log, nothing happened (i.e. it didn't fire the rule that should have turned my lights off). Here is the log on it:
BTW, I tried it a 2nd time. This time it shut off everything but the ceiling fan light (called the Den Light in the rule), which I don't see any command sent to it in the below log:
It's not clear from the logs that any button event is getting generated for button 2 held on this device. That "raw" Z-Wave debug log from dev:350 is indeed a double tap down, but the real question is if/how the driver parses this into an event. Leaving info/descriptionText logging enabled will conventionally show this in Logs, though Inovelli's custom drivers don't exactly follow convention; but the authoritative source anyway would be the "Events" tab/button on the device detail page for this device. Do you see a "button 2 held" event there when you expect to see one?
This is all to rule out a device versus app problem. If the device still looks good, I'd hit Done in the grandchild (the button 2 held "button rule" itself) and child (this Button Controller instance) apps to re-initialize things, and check the App Status page on both for subscriptions (really only one, I just forget which one it's in ) and post those here if you aren't sure. You could also just remove and re-create this Button Controller instance if that sounds easier than all of this, just in case you ran into an old bug that has been fixed.
I had this one and another light that was turning on but not turning off (this 2nd one with a 1 Held (i.e. a single down tap).) I did all of the steps above and the one that seemed to work was hitting the "Done" button again inside those rules.
BTW, under Button Controllers I'm only seeing children being created for newly created ones, which also have the much appreciated "Run Actions" button inside them. Is there any way to easily upgrade the existing Button Controller rules? I was hoping that when I hit the Done button with these 2 it might upgrade them, but that didn't happen.
No, there is no import/upgrade path besides manually re-creating (like Rule Machine, which Button Controller is largely based on). However, there is no need to unless you want to use any new/changed feature, as the existing instances will continue to work as-is.
As long as they work I'm happy, but the problem is that certain switches are more problematic than others for some reason and virtually all the rules seem to slow down, stop at some time or another. Being able to test a rule from right inside the rule is a tremendous help. So I'm very glad to see it has been added going forward.
So one last thing: The reboot really helped some other devices speed up. Is that something I should be doing periodically, or just wait until I see this dramatic slow down? And when I do reboot, is it OK to just reboot or should I do a (graceful) shutdown first as well?
If you're on a C-5 or C-7 (the newest hub models) with relatively new firmware (though I'd really recommend the current one), most people no longer find a need to reboot on a regular basis. Those of us who had C-3 or C-4 hubs with early firmware, or even newer hubs with older firmware, may remember things a bit differently.
But if there are problems, like significant memory drop over time on any model, a reboot can still help with that. There are various unofficial options to help schedule one if you feel like it would be a good idea in your setup (a search should pull up a few). However, it may be worthwhile to see if you can pinpoint a cause and just eliminate that instead. A poorly written app or driver could be the culprit, or possibly even just a really chatty "normal" device, but there are more tools now to help figure this out than before: the "App Stats" and "Device Stats" tabs on the "Logs" page. There are no hard and fast rules for what's bad, though I normally look for anything using a high percent of total. Large state size might also be suspect.
Also along those lines, if your default event or state history size on the "Device Stats" page is really large (I think the default used to be 1000 for one; something like 50 or even less may suffice for most people), that could make your database large, and large databases may contribute to slowness. Just a few things I can think of!
) and post those here if you aren't sure. You could also just remove and re-create this Button Controller instance if that sounds easier than all of this, just in case you ran into an old bug that has been fixed.
