I have a work around in place with a virtual switch. If you had an SLA, you'd be killing it. 2 Minute response time from a lead developer (I know just one of the hats your wear) is unheard of! Thank you for all the hard work you put in.
4 Likes
With the Rule Machine global variable, I used to use capability.sensor (and its currentVariable attribute) to get at my Time connector variable. That doesn't work with the DateTime Hub Variable. What capability should I be using for DateTime connectors?
A quick inspection of the device shows that it implements the "Sensor", "Actuator", and "DateTime" capabilities (that last one is undocumented and news to me, so I'd probably stay away 
). So, if you're using "capability.sensor" to select, it should still work. I just tested and it does for me. If you wanted to very specifically only choose devices with the "Connector DateTime" driver (as you might if you depend on specific attributes or commands), you could use "device.ConnectorDateTime" instead.
That being said, currentVariable will not work on this device (regardless of how you select it, which does not matter--you have access to all attributes and commands once you get a reference to the device). If you are not familiar, that is equivalent to currentValue("variable") and means that an attribute called variable must exist. You can see under "Current States" for a device like this that it does not--only an attribute called dateTime:
So, you need to access the value of this attribute by using currentValue("dateTime") or currentDateTime. Note that this attribute gets returned as a string. If you need a Date object back out of this, you'll have to use something like Hubitat's built in toDateTime() method or something available from Java/Groovy.
OK, using currentDateTime works! Thanks for your help.
[Interestingly, with the Rule Machine global variable currentVariable used to return a string with the time].
Just to confirm, what you're seeing is time being rendered incorrectly but showing up correctly in app settings, right?
And under app settings (small cog link at the top right of app screen):
Hi @bravenel quick question regarding global variables in RM4.1 and transition to legacy. You mentioned in the release notes that all existing rules can be used without modifications. However, I think i found an edge case which stops working after I have updated to 2.2.8:
The removal of setGlobalVariable from the Rule Machine API means that rules which rely on that functionality stop working after this upgrade. Shouldn't that functionality still be available for rules which are executed in RuleMachine-Legacy? Or is the intent to completely move away from global variables even in older rules created in 4.1? In which case the release note need a little tweaking...
The old API docs clearly mentioned the feature, but it is missing in the new API docs...
Would you regard that as a "bug" or "bugger off" and use the new functionality? 
Background: I like the TTS capabilities of Hubitat and I'm using them across various use cases around the house standalone and in combination with the great FollowMe driver. I wanted a little API that allows me to trigger the speech from other devices as well to have consistent voice announcements no matter what triggered it.
I tried two approaches. One with a custom driver and a second just using standard functionality (to be more future proof... 
) namely global variables. It worked all great until the 2.2.8 update.
Here is what the rule looks like:
and it could conveniently be trigger it via a get request: http://hubitatIP/apps/api/899/trigger/setGlobalVariable=saybath:say%20something?access_token=XXXXXX
now it just throws an error:
Thanks for your help/clarification in advance.
Cheers,
Thor
Yes Victor, that’s correct
This functionality was not removed for Rule Machine Legacy. This is a documentation glitch.
I think "Change Color Temperature over time" is not working in rule 5.0
Maybe I missing something...
In rule 4.1 it does
I will look into this. If it's throwing an error, there's definitely a bug somewhere. Thanks.
1 Like
I think this is fixed in a soon to be released hotfix (2.2.8.137). Would you check again, and let me know by tagging me if not.
2 Likes
This bug has been found and fixed. The fix won't be in the next hotfix (2.2.8.137), as it missed the cutoff. Will be in the one after that.
Thanks for bringing this to my attention.
4 Likes
I don't seem to be able to add Button 5.0 buttons to my Dashboard, is that another late arrival?
You can't add apps to Dashboards. If you mean the button device itself you add that to the Dashboard, select Button tile, and pick which button number.
Sorry, I didn't explain that very well. The devices created in Button 5.0, are not appearing in the Dashboard App interface where I would add the button to an individual Dashboard. My buttons from RM4 appear there, no new ones.
Button 5.0 does not create any devices. It acts on existing button devices. RM4 does not create devices either.
This Change Color Temperature over Time bug has been fixed in latest release, 2.2.8.138. However, you will have to edit the action and reenter its parameters due to the fix wiping them out.
3 Likes
@bravenel I'm trying to get my head round using new rule 5
Summer is here and we are leaving doors open, so wanted a rule which would send us a notification when the motion zone is active when we are upstairs. I had a virtual switch which we can toggle on when we want monitoring, I sketched this up in old rules but struggling in the new
I hadn't tested it yet in old
Maybe a little bug:
After you create a new Rule with a predicate condition and click Done, it takes you back to the Apps page. There is no display of the (Predicate False) next to the rule. However, if you click on the rule and then go back to the Apps page, the Predicate False shows up.
Waw, already implemented, 
