Rule condition shows TRUE in UI but Rule never transitions to SET — survives full restart

[LibraSun]

Q: Is it fair/accurate to say that MSR cannot directly set the "LoadLevelLast" attribute of a Z-Wave light switch (paired with Vera)?

Reason I'm asking is that I routinely use Luup-based Reactor to set that value (e.g. to "60") whenever the switch is turned OFF, which causes future ON commands to automatically dim the light to that value (in this case, "60"). Kind of a built-in brightness limiter.

Granted, insofar as "LoadLevelLast" is intended as a read-only, derived value -- not meant to be set directly by Reactor in the first place -- I know this sounds like a trick question. And admittedly, the manner in which Reactor has done this for me in the past was by executing a snippet of Luup code containing a [variable_set] command. But it has worked (in most cases I've applied it to).

Is there any way to replicate this functionality -- however ill-advised in the grand scheme of things -- with MSR?

[toggledbits]

There's an action in x_vera_device that will allow you to set a state variable on a device.

[LibraSun]

@toggledbits now that I have a Hubitat up and running (took some doing... phew!), I'm back to ask the same question about it, namely, "Is it possible to set LoadLevelLast - or the equivalent in the Hubitat environment - so that a dimmer will come on at the desired preset level (say 60%) next time?"

I've been using this technique with great success back on Vera, but do not see the matching action for Hubitat-attached devices in MSR.

Thoughts? Might this involve setting up virtual devices on Hubitat whose sole purpose is to mirror/pass LoadLevelLast values, perhaps? Trying to think inside the (new) box.

THANKS! - Libra

NOTES FOR THE CASUAL READER
◘ I don't want to establish a Basic Rule such as IF deviceX turns on THEN set deviceX to 60%, because that would override occasions when I instructed Alexa to "Dim Device X to 20%"

◘ I am currently unable to get my first (and so far, only) wall dimmer switch in Hubitat to "Dim Device X to (any) percent". Alexa simply replies with, "Sorry, Device X is not responding." and nothing further happens. Whereas simple, "Turn on" and "Turn off" verbal commands work as expected, and back on the Hubitat itself all of Device X's array of test actions (on, off, dim, etc.) also work perfectly.

[toggledbits]

@librasun said in Setting Other State Variables on Vera / Hubitat:

I've been using this technique with great success back on Vera, but do not see the matching action for Hubitat-attached devices in MSR.

Setting state is not something Hubitat supports. Each hub has its own quirks, of course, and the quirky things we're used to doing for Vera aren't necessary, and often aren't even possible, on the other platforms.

[LibraSun]

Thanks, I kinda figured that's where things stood. I'm actually glad to think I may be leaving the old Vera hammer-over-head ways and entering a new realm. Speaking of which, I've had to start a couple of threads over on the Hubitat community regarding my Intermatic HA20C's reluctance to be dimmed (via Alexa) while under the Hubitat umbrella. That hub only responds to Turn On and Turn Off commands, whereas if I ask Alexa to "Dim to __%" she tells me "Device isn't responding."

Mercifully, some of the community members over there have taken this as a personal challenge and are trying to rectify. Will advise. I just doubt that such an old (2009) dimmer will be well-received by such a newfangled hub as the Hubitat.

[toggledbits]

Yup. But you have options. I'll probably keep the deepest of my legacy devices on Vera until they are ready for replacement, but that's only a handful at this point (will probably make maintaining a good mesh more challenging than I've had to deal with in a while). Bringing up HA on a Pi with a Z-stick is also an option, but I have my issues with HA's ZWave support that haven't changed (despite their change from OZW to ZWave-JS... it's not the library at fault, it's HA... stories for another thread).

[LibraSun]

I know you'd want to hear what the recommended solution (to the non-dimming on verbal command issue) was: Create a virtual dimmer, mirror its behavior (yes, Hubitat has an app for that, too!) back onto the physical switch, expose the new VS to Echo app, and voila! WORKS!! (Another member had blanket recommended introducing Z-Wave Poller -- yep, another app! -- for this single switch, which he suggests I keep in place.)

Of course, this doesn't directly address the original 'LoadLevelLast' aspect, but now thinking I'll just fiddle with their Basic Rules app to mimic that behavior. Amazing all the things you can accomplish on a Hubitat in 2 minutes that would take all day back in the Vera ecosystem.

UPDATE AND MEA CULPA: Oops, the whole "Device not responding" glitch was my fault. I had accidentally left the old copy of "Dining Room Light" in the list of Alexa's Smart Home > Devices. After removing it and re-running discovery (sans all the mirrored virtual switch rigging on Hubitat), the switch now behaves as expected thru voice commands, including Dim. How embarrassing!

[RogerO]

Quick question. I am in process of moving from Vera to HA. I want to do something similar so I can keep my Homewave dashboard on the wall mounted ipad mini in the kitchen. Have created a virtual dimmer in switchboard and can capture the dimming level into a expression. How do I pass that to the physical dimmer switch I want to control? Have tried set_load_level_target to expression name but that doesn't work. Any hints?

[toggledbits]

@rogero said in Setting Other State Variables on Vera / Hubitat:

Have tried set_load_level_target to expression name but that doesn't work.

"I tried X and it didn't work."

This needs to be a new topic, with a proper explanation of what you are trying to do, and showing the work of what you attempted. The problem likely is in the way to tried to solve the problem, but if you don't show your work, there's no way to figure that out.

[gwp1]

@librasun said in Setting Other State Variables on Vera / Hubitat:

UPDATE AND MEA CULPA: Oops, the whole "Device not responding" glitch was my fault. I had accidentally left the old copy of "Dining Room Light" in the list of Alexa's Smart Home > Devices. After removing it and re-running discovery (sans all the mirrored virtual switch rigging on Hubitat), the switch now behaves as expected thru voice commands, including Dim. How embarrassing!

If I had a nickel for every time I've done this or had conflicting rulesets...

Something you'll need to learn as you move away from Vera/Reactor and into Hubitat/MSR is that some of your base approaches to creating automations will change/need to change. I went thru it with my HVAC stuff as well as a few others.

It helps to literally grab a pencil (you remember those?) and map out your logic.

[RogerO]

Found the answer. ${{variablename}}

[LibraSun]

@gwp1 Do you happen to know whether MSR can "see" values of Global variables contained on the Hubitat hub? I haven't set any up yet (that's my next self-imposed exercise), but thinking ahead, it would be neat if MSR could react to changes in those.

[SweetGenius]

@LibraSun Yes, Just add the Hub Variables to the Makers API app and restart MSR and they will be visible.

[LibraSun]

@sweetgenius Okay, that's the part I was mentally unclear about... the variables appear as "Devices" then (I even watched @bravenel assign a virtual device type to one in a tutorial video), which we can include with Maker? That opens things up very nicely, indeed.

UPDATE: Oops, I think I oversimplified things with that conjecture. I went and created a (thought it was Global - wrong!) variable in Rule Machine but see no reference to it anywhere in the Hubitat UI. So will await further education... Then went and rewound the same tutorial video and realized Bruce was working in a thing called Settings > Hub Variables. I'll go kick its tires and see what's what. <10 seconds later> Yep, that's the ticket. After creating a variable connector (which can then be made any subtype of connector), it appears in Devices, ready to ship to Maker API. NEAT!

[SweetGenius]

@librasun They changed from global variable in Rule Machine to Hub Variables. I glossed right over the naming when you asked and assumed you meant Hub Variables. Glad you got it working.