I've experimented a lot with Rule Machine 4.0 over the last couple weeks after making the transition from SmartThings.
One thing I've noticed is that the configuration persists old conditions, triggers, and actions. In other words the delete function seems to be completely useless for Rule Machine 4.0.
I'm pretty sure it just deletes the frontend UI config and labels while persisting the actual logic still on the rule itself. In other words I've found that the delete is a lie.
I'm not sure how to paste the actual state variables for the rule in here as it's a table. Suffice to say just create a simple RM4 rule with 2 triggers, and 2 actions. Then delete one of each, save or Update Rule, then finally look at the state variables and not the fancier layout/label view of the rule. You'll see that the action and trigger deleted still persist.
So as said, the delete in RM4 is a lie. I want cake for finding this
Wow. There's a sweeping statement.
Could you possibly be more specific in where they are remaining.
If you mean in the box at the bottom when editing actions then yes they do remain there but they don't do anything unless they are configured in the trigger or action sections.
Maybe a screenshot.
Notice specifically how there's an "8 AM" atTime2 and also a Kitchen "flashSwitchMain.2" setting when those are not being shown or set. 8 AM was the trigger I deleted and "Flash Kitchen" was the action I deleted.
Obviously you can assume I added those things and took the settings screenshot after and the primary view before that, however I can assure you I did not. This is why I was suggesting just reproduce it yourself with those simple rules.
I also thought maybe 2.16.x would solve it as I was on 2.15.x but I tested with the latest firmware and the issue is still there.
Just a suggestion, based on a hunch, go back in 24 hours and check again - may be cleaned up - or maybe not. In any case to me this seems like nothing, unless your deleted times/actions are actually executing.
The fact that a given setting isn't cleared out when a given rule has been changed doesn't imply that any part of the old rule is still operational, a given UI field may continue to have an old value, and that's OK as the final executable logic of the rule will only use the particular settings relevant to the final rule configuration.
Also, time based events generally set them selves up in the schedule jobs section of the app details, this section of the app isn't normally updated until after done is selected in the app and the app is closed.
And, the app status page isn't updated in real time, to fetch the latest values the browser needs to be refreshed.
Well it's been executing the same deleted trigger and action multiple days in a row. I already tested the 24 hours situation, not the problem.
The part that's odd is how I discovered this issue. A deleted action and trigger both ran but never got logged. That's the odd part. I had logging on the rule for everything and it logged when I manually triggered the rule via a switch turning on, but then it also ran via a stale trigger at 1 AM and ran a stale action (turned on my TV). This was odd because the device itself said the command came from Hubitat, but Hubitat's RM4 rule didn't log itself as being triggered, it just did all of the same actions as if it was including the deleted/stale actions.
The only work around so far that I've seen is just deleting the entire rule and starting over. Not ideal but it beats having all these stale actions and what not going on in the background.
Did you hit Done in the rule, or Update Rule, after making these deletions? That is a necessary step.
Without logging how can you prove that they ran? If you have logging on, and there is no log entry, then they didn't run. Your discussion above reflects a misunderstanding of what happens when you delete something in Rule Machine. Sometimes, depending on how you do it, settings and/or state objects will persist after a deletion. That does not mean that they are active. For example, if you want to see the active Trigger Events for a rule after removing one, first hit Done or Update Rule, then look at the Event Subscriptions on the App Status page. You won't see any event subscriptions for the deleted trigger event. Also, on the same App Status page you can see the Scheduled Jobs for a rule. Match both Event Subscriptions and Scheduled Events back to your rule, and see if there is some discrepancy. As a further step, look at the App Events from the App Status page. Every time a rule does something, it posts an event to that log.
There are thousands upon thousands of rules running on Hubitat, and no one has ever reported that a deleted trigger event keeps on running. There is a simple reason for this: they don't.
I must admit that in the past for any bugs I have found is that the HE team take them very seriously.
I suppose from your perspective it's there but the HE team cannot reproduce it. Thats always going to make things difficult.
I hope you get things sorted.
Thanks bobbles, I agree that they'll take things seriously if it's obvious. This is sort of an obvious one if you just look at actions and settings, not the logs. The logs are hiding the action run by the rule in RM 4.0 from my testing, but the actions still run! The devices themselves will actually report the state changes as if the rule was executed.
That said I created another example so maybe that will help. I really really don't want to go back to ST because I like the local aspect of Hubitat, but it may not be up to me if the wife decides she's had enough.
For this rule, can you show the Application State (Settings Cog (top right of screen) > Application State > actionListMain and actionsMain)? I honestly do not believe this is a bug so much as a misunderstanding of what's going on behind the scenes in RM.
[Edit]: Sorry, need the Application State, not event subscriptions.
Unfortunately you have not provided enough information for us to tell if there is a bug or if this is a mistake you made that you are unaware of. We need to see logs of everything relevant and sometimes other information as well. Answering the question I raised 4 days later and then complaining that we aren't taking "this bug more seriously" is not a fair statement.
We'd be happy to work closely with you to discover what is going on.
You would really need to show us some complete logs before this could be accepted as a fact. As the author of Rule Machine, I know for a fact that the logs are intimately tied to the running of an action. You can choose to ignore this, and misevaluate the situation, but that doesn't get you any closer to a real answer.
Show the logs. Show the application state. We're happy to help. Leaping to unfound conclusions isn't the way to start. Let's start with hard observable facts.
These are the objects that matter: actionListMain and actionsMain. actionListMain is a list of the actions that rule will run. In this case, it will run action 2. actionsMain provides detail about the actions. We can see that action 2 is a Set Volume action (see actSubTypeMain.2 above in Settings). The setting for onSwitchMain.1 is completely irrelevant, and is a vestige of having deleted that action. Its existence does not make the rule capable of taking that action.
You are correct, it's not as easy as I thought it would be and now I'm a bit embarrassed.
I just ran a simple test and it didn't execute both actions as I thought it would despite being referenced in the "in use by", the switch I removed the action for did not trigger as I thought.
So now I'm unable to reproduce. I'm now thinking maybe it has something to do with the Roku TV User Driver that I used. Since when it comes down to it, the real cause of this all was that thing turning on in the middle of the night at 1 AM which was originally in my RM 4.0 rule that I've since deleted (the rule not the device or driver code).
So here's the logs at least of events that I can get for the TV but I didn't think it that useful since I can't see what triggers it and I've since removed the original rule that had the 1 AM time set (it was supposed to turn off the TV only at that time but instead it turns it on).
switch
off
DEVICE
2019-11-04 01:05:53.632 AM PST
switch
on
DEVICE
2019-11-04 01:00:53.603 AM PST
application
Roku
DEVICE
2019-11-03 10:20:53.623 PM PST
switch
off
DEVICE
2019-11-03 10:20:53.602 PM PST
application
Prime Video
DEVICE
2019-11-03 09:20:53.630 PM PST
switch
on
DEVICE
2019-11-03 09:20:53.610 PM PST
switch
off
DEVICE
2019-11-03 01:15:53.612 AM PST
switch
on
DEVICE
2019-11-03 01:00:53.649 AM PST
application
Roku
DEVICE
2019-11-03 12:50:53.615 AM PDT
switch
off
DEVICE
2019-11-03 12:50:53.612 AM PDT
From the looks of the log however, you can see it's not just 1 AM now, it decides to turn on at all sorts of times that make no sense when we're fast asleep. It just sometimes wakes us up.
So I think suffice to say we should let the author of the Roku TV driver know that there's something a bit off. I had that hunch before but went after rule engine first just because of the 1 AM thing.
No reason to be embarrassed at all. Trust me, we have ALL made our share of mistakes when it comes to RM.
As for the Roku driver, I've used it and didn't experience anything odd with it. What you may want to do is go through your rules (and drivers/apps code) and see if anything is doing something wonky. I've got a rule from awhile ago that I just noticed was turning on my carport lights at noon (it was a test rule I wrote to demonstrate something, but I don't remember what lol). It's been running for weeks now.
