Before I unleash the dragon, is this the correct command format? (Answer: YES)

luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='24',Data='x70 4 8 1 3'},1)

I ran that exact command in Vera's APPS > DEVELOP APPS > Test Luup Code (Lua) window -- immediately after waking up the battery-powered remote by tapping one of its buttons -- and it worked perfectly!

LED does what it's supposed to do now. THANK YOU ALL!

Having spent years as a professional portrait photographer, I came by many tricks of the trade involving readily available materials. One such trick is known as an "Oil Spot Photometer", which can help you equalize the brightness of two or more light sources.

For simple setup instructions, visit:

Oct 2, 2020

Oil Spot Photometer

When an oil spot on a card is illuminated equally from both sides, it mysteriously disappears. This allows you to compare the brightness of the light sources on either side of the card.

The implications for Home Automation, of course, is knowing the preset dim levels needed to balance a room's lighting, without guessing. Just bear in mind that dimmer levels and bulb output are rarely linear, so you may have to take photometer readings at various brightness levels to create a lookup table (for use in MSR, etc.).

I'm enjoying this thread as it develops, but will stand by until someone wraps MSR into a Docker package that I can install/run on my Docker-enabled Synology NAS.

Like everyone else, "I'm at full candy corn" (so the Stewie Griffith saying goes) on this project and can't wait to give it a whirl!

• LS

Sorry this happened. None of us deserved being kicked out. Especially after twelve dedicated years in my case! The forum was fun and helpful until the moment a certain someone began posting, sadly.

Such is my life. I proofread 1000-page reports for the Army Corps of Engineers and book authors all the time. Nothing gets past me.

It's moments like this that I'm grateful for online Forums where the open exchange of ideas and experience works to everyone's advantage, without fear of reprisal from those "in charge".

It's been a pleasure watching the evolution of MSR. In fact, it's my primary reason for becoming active on this Forum.

For the record, I'm using "Hyper Backup" - a native Synology NAS app - to backup my entire /REACTOR folder structure to a folder in my Google Drive cloud account. Suggest other MSR users consider doing something similar, in the event of a local NAS drive malfunction.

@crille said in My newbie questions:

Thank you all.
I'll manage my use case either with scenes or MSR, just think Veras approach gives a good overview of what happens when I change House mode.

You're right in saying Vera got that particular facility right. Funny, I only discovered that "House Modes options" page very late in the game (i.e. around 2013?) and never bothered to use it beyond un-Arm'ing everything then forgetting about it. (I don't use any physical sensors, anyway.)

But I will say +1 to moving everything to MSR (or at least Reactor for the time being) and away from Scenes and naked Lua. Main reasons: Editability and Portability.

Of course, all your Lua code snippets can be run by Reactor, if that's your thing. I found that every Scene I ever created on Vera could be accomplished more succinctly by Reactor, with the added luxury of Expressions and its powerful runtime logic.

Literally the only Scene I have left on Vera is one which resets Reactor whenever it "trips" (throttles due to too much activity in a short time span). Period. Done. Buh-bye.

ezlo is sinking or swimming (mostly the former) without the benefit of many highly knowledgeable beta testers due to Forum banning. I would not let my dog's dog submit Feedback reports at this stage. At least their employees are (by necessity!) being a lot more responsive, seeing as all the "free labor" has been evicted.

There is (edit: WAS) a guy on the ezlo Forums who said he was looking for a Vera unit to replace his Plus. I'll drum up the link to his post: Nope, it vanished, along with the Message I sent him on that Forum. Wonder if he got booted for talking about equipment failure, lol.

@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!

@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.

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!

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 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.

I feel I ought to know what <controller-id> comes from, in the instructions above, but nothing pops into my head.

@3rdstng said in Finding Missing Devices & Migrating Devices:

Maybe just a stupid simple GUI to a fgrep cli command with collected variables

I think Hubitat handles it by adding a reference - complete with hyperlink - for every Rule containing a specific device or virtual device. One click to jump over to the Rule. Kinda neat.

As someone mentioned above, I think the idea place for MSR to have this (if it were to become a feature) is under Entities. Truly it could spare me many hours of hunting and pecking - and never being entirely certain - that I sadly do not have most days.

@3rdstng said in How To: Send TCP packet in Reaction:

took my R4V backup file and imported it in

I would have loved to do the same, but with Docker running on a Synology NAS, I recall there being some [command line or required packages] limitation that made the import impossible.

That's why I laboriously re-created all of my old R4V reactions, which turned out to be the best way to learn Reactor for me!!

I was just eager to hear that [uncertain] limitation had been circumvented during the intervening year or so.

[SOLVED - OK to remove this]

SOLUTION: I had mistakenly assigned the NAS folder /REACTOR instead of REACTOR/DATA to the '/var/reactor' volume when setting up the Docker Container for MSR. Once rectified, all Rulesets reappeared like magic.

Speaking of finding missing items, I've consulted the Docs under "Installation" and come up empty on solving a mini-crisis I got myself into tonight after rebuilding my RAID volume. On my Synology NAS > Docker > MSR setup, I had taken pains to backup the entirety of the shared REACTOR folder contents. That went well.

After successfully building my new RAID array (with larger, more reliable HDDs), I restored all the REACTOR folder contents in the same (top-level) location on my NAS. It was time to reinstall Docker, download the Reactor 'latest' image, then get the Container going. Again, all went smoothly.

Here's my problem: MSR latest-21307-1746e27 is running fine, and although it lives among all the restored folders and subfolders - full of my existing Rulesets, etc. - the UI shows none of them. Instead, I get the classic, "This rule set is empty. Click "Add Rule" to add a rule to it."

Q: How can I force a fresh MSR installation to 'see' my existing settings?

THANKS for any guidance! I'm a little scared now, and all sphincters still unclenching from the NAS HDD replacement surgery.