What's going on for me is some release version confusion. We've been running two releases in parallel, something we don't usually do. So apparently I'm mistaken about what release the fix is in for the Variable trigger bug, or there was more to the bug than I thought. I rolled back to 2.4.0.151, and got your result. I'm sorry to waste your time!
I used the same rule as above on 2.4.1., and that's how I got the Event Subscriptions I showed above. So, the bug is fixed in 2.4.1, now in beta. You can join beta if you want to get that.
I can’t speak to the timing of the beta build going into production, but there are typically issues with Beta that the Hubitat team will typically fix pretty quickly. Sometimes it takes a few hours, sometimes a few days, sometimes a few weeks. It is difficult to say if they will impact you - some people are highly impacted by them where others aren’t. It all depends on what you use and how.
As an example, I am on the latest beta, and there are a few things that aren’t working as they should. I expected that this would be the case when I decided to install the beta builds, so I’m ok with it. These things are very noticeable to me, but as it happens, to no one else in the family, so no issues here overall.
If you do join beta, you always have the option to roll back to the latest production version.
If beta turns out not to be an option for you, a crude band-aid would be to use e.g. basic rules to mirror your variable(s) to virtual switch(es) and change your one rule to use those instead.
I can't provide a time frame for 2.4.1 production release.
Another work-around would be to use a Conditional Trigger instead of a Required Expression. The Condition you now have as Required Expression would be the Condition of the Conditional Trigger, and there would be no Required. Expression at all.
Well, that sounds reasonable, then. I've requested to join the Beta group; I assume that if I am approved, I will have access to instructions on how to install a beta version, and how to roll back to production versions.
There are no special update/roll-back procedures unique to the beta -- those two processes are the same for beta and regular hub versions.
ETA - I strongly recommend reading through all the release notes (and at least glance through the beta community posts) pertaining to the current beta before deciding whether or not you want to try it right now.
To roll back, you will need to use your hub’s ID on port 8081 (Ex.: 192.168.100.100:8081). This will bring up the diagnostic tool that has an option to « Restore previous version »:
If you decide to become a beta-tester, I'd strongly recommend getting a Hub Protect subscription. In the unlikely event something goes drastically wrong during a beta-test, those cloud backups make it SO EASY to restore a fully working configuration.
Cloud backups include the zigbee and z-wave radio DBs, which are not included in a local backup.
With Hub Protect, in addition to an easy restore option, you get an extended warranty. If a warrantied hub dies, you get a replacement for just the price of shipping.
Thanks for all the advice. I've bought Hub Protect and taken an initial cloud backup (and left in the "weekly" default schedule for cloud backups), I've taken a quick look at the Diagnostics Tools page on my hub, I've read the topic "Beta Release 2.4.1 Available" (and set myself to "watching" it), and I've read the documentation section on "Hubitat Diagnostic Tool".
I don't fully understand "Download latest version" and "Restore previous version". What is the "latest version" that is downloaded? Is it the latest production, the latest beta? Is there any way I can select a specific version? How many software versions can I store on the hub? When I restore a previous version, is it selecting from versions available on the cloud, or versions stored locally? Do locally stored versions stick around forever?
I've been searching around for answers to those questions and have found snippets that suggest that a limited number of versions is stored locally, and that there are special urls (/hub/advanced/downloadXXX) that one can use to make the hub download a specific version (though not a particular sub-version I think), and that when we restore, it's from a version stored locally. It would be nice if all this were documented authoritatively on the "Documentation" site - or is it these and I missed it?
I think I'll just watch the discussion go by for a few days before I decide to take the leap...
With respect to the bug under discussion here, is the bug fix expected to be backported to 2.4.0.x, or not?
Generally speaking, fixes are not backported. There have been a few exceptions - bugs for which there are no workarounds. I anticipate that 2.4.1.x will be released within 45 days. There are many changes in this version, so the beta-test cycle is likely to be longer than usual.
So is it the case then that this bug was not introduced recently, as I had assumed, but rather has been present for some time in 2.4.0.x, and I've encountered it only now because I started using variables in required expressions in Rule Machine?
I'll weigh the proposed workarounds (replacing the variable with a virtual switch, or replacing the required expression with a conditional trigger) against Fear of Beta.
Download latest version will download the latest version, it will be the latest Beta if one is available. Otherwise, it will be the latest production version.
Restore previous version, as you found, allows you to restore one of 3 past versions. They could be beta or production versions.
I installed 2.4.1.118, and the problem didn't go away. So then I checked the event subscriptions, and they were unchanged from what I showed above. I even changed the required condition (I made the variable check for false instead of true), updated the rule, then changed it back and updated again - still the same, just the one event subscription instead of two.
I can work around this by using a virtual switch instead of a variable if necessary, but that rule isn't crucial, so I'm willing to keep testing stuff if there's something else I need to do to bring it to its senses. I'm puzzled that a similar rule works for you; what am I doing differently? Is there additional information I can provide?
Whoops, one difference: handler is now "stHandler" instead of "stHandlerA". But subscription is still for "variable:Environment_need_lights", the required condition, with no mention of the trigger, the variable "Presence_somebody".
This is strange as I cannot get this to fail the way yours is failing. Would you be so kind as to remove this rule completely and create it again from scratch. After installing the rule, check the Event Subscriptions -- there should be two. One for 'variable:Environment_need_lights' to stHandler, and one for 'variable:Presence_somebody:true' to allHandler.
Done. I renamed the old one, made a new one identical to the old one (by manually entering it, not by copying), then disabled the old one. Here are the two rules in the list of rules on the Apps page:
Oh, here's something interesting (maybe). Also from the information page, here are excerpts that show a difference in format between the names of the "1" and "2" items of the rule, corresponding to trigger and condition - I have no idea if it's significant, but it strikes me as inconsistent, and therefore possibly incorrect:
When I created the rule this time, I entered the trigger first (so xVar1, and, I would assume, tCapab1, tstate1, and RelrDev1, no underscores), then the Required Condition (so xVar_2, rCapab2, state_2, and RelrDev_2, with underscores). This may of course be totally irrelevant...
