I have a Minoston dual plug that has a bad habit of turning itself on or off on its own. I use it to control out pool pump, and have a rule that is supposed to run when the plug goes rogue and returns it to the desired state. Last night it went off, but the fix rule did not execute:
Hub log shows the plug turned off event.
The device events show it triggered the rule.
Nothing in the log for the rule execution, even though all logging for the rule is enabled
The rule did execute last week when the event happened, and appears in the log as normal.
Also, have not made any changes to my hub recently (in weeks) that could have affected it.
Your trigger is "physical switch," whereas I don't see an evidence from your log entries that the "switch" event was registered as the "physical" type. Further, many devices/drivers do not distinguish these events at all. Are you sure you want "physical switch" as your trigger? Perhaps this is a pattern you noticed when you set the rule up, but it's not consistent with what seems to be happening now based on your logs (though you should really check "Events" for the switch to be sure; there's a "Type" column there that will say "physical," "digital," or, quite likely, nothing).
Of course, the underlying issue here is that the plug keeps turning on or off on its own. Have you looked into that at all? While there could be a hardware issue or perhaps Z-Wave parameter or other setting on the device (I am not familiar with it), you could at least rule out a command from the hub by also checking "Events" and looking for Type of "command", or things like "command-on" as the event name to show if/when the hub sent an "On" command — this is an authoritative source, whereas logging depends on your options and the driver).
Yeah, I did set that up as a Physical event, as that is what it showed initially. However, the recent event where the rule did run, did not log as physical, either. Also, per the device event log, it said it triggered the rule. So it does not appear that the switch type is the issue.
As for the plug itself, I did some testing when I first got it and encountered the problem, and ruled out hub commands . Reported the issue to Minoston, who sent me a 2nd unit, which exhibited the same problem. I have one of the units now just controlling a lamp, which is not as important as the pool pump, but have applied the same "fix" logic to that. Guessing it might be time to move on to another plug, but still concerned with the Hubitat behavior. The device event log says the rule was triggered, but it does not appear to have executed.
Also, the errant switching events with the Minoston plugs are very random. Usually occurring only 2 or 3 times a month, and at very random times. Anytime of the day or night. That makes it hard to debug, waiting for the issue to occur.
Device events will not show whether the rule was "triggered." I do see some possible confusion here in that the table column in the app says "triggered," but that's not in the Rule Machine sense but in the general platform sense that the app "woke up" because it has an event subscription. What, if anything, the app does in response is up to that app but not anything you can see from that entry on this page.
What will show this is is app logs from the Rule Machine rule in question if you have (at least) "Trigger" logging enabled.
Thanks for the additional info. However, the device event specifically states it triggered the PP_Fix rule. I also, have all logging options enabled for the rule (Events, Triggers, Actions). The log snippet shows no execution entries for the rule. Previous trigger and execution had full logging for the execution. Hence, it still looks like the rule was triggered, but never actually executed.
And because from the rule (app) logs you see that:
then you know that your rule did not actually trigger. It seems from the above that this is because your trigger is for a "physical" event type, which your device is not actually producing, at least not consistently. That is the root cause of your problem.
In other words, don't let the "triggered" terminology on the device "Events" page confuse you; perhaps "subscribed apps" or "waked apps" would be a more suitable term (aside from the fact that speakers of different English varieties might argue over whether it should be "woken," and they both sound weird ).
But in the PP_Fix rule logs it does show the previous successful execution triggered as physical.
However, the preceding event description (on 5/28) is identical to the one on 6/3.
It appears the Hub has stopped appending the "physical" description to the On/Off event logs?
Although the device event log for both events notes it as digital?
So the best I can guess at this point is either:
event log descriptions are not as complete as they used to be, so I can't differentiate the physical and digital events, or
the rule still is not executing when triggered.
Finally, either way this is all to try to fix a mis-behaving device. I have some other plugs and will try one of them. Still concerned about the event/triggering behavior consistency Does not look like the digital/physical descriptions are being applied properly in the logs.
it is a dual switch.. i have a simliar problem with my ev logic (similiar looking to the minostron) i think they are made by same manuf.. it incorrectly turns one of the switches off randomly about 1-2 a month when the other one turns off.
The difference between a 'physical switch' trigger and a 'switch' trigger is that the RM physical event handler checks the event type. If it is not "physical" the rule simply exits. If it is "physical" rule proceeds exactly as if it were a 'switch' trigger. In both cases, the event has fired the rule app to run, but in only the case of the event type being "physical", is the rule actually triggered.
Both of my dual plugs exhibit the problem. However, the problem occurs on each channel independent of what is happening on the other. Usually it happens when no change occurs on the other channel. Also, it can go On or Off. Odd thing is the errant event can occur on either child device, or the parent. Thought I had it worked around, but not reliably enough.
bravenel - thanks for the clarification, but figured that was the case. Just from the logging it does not appear to consistent. This log entry is tagged as "physical", but the rule did not execute.
However, it is also labeled as being on the parent device, which is probably why the rule did not run.
The rarity and randomness of occurrences has made this too tough to debug. I've replaced the device with a more reliable plug.
).
