New ongoing development of the superautomation MultihubReactor from Patrick Rigney. Same RuleEditor for different brands of hubs..... Watch the video he made
ping @dJOS
So is this cloud based or a local app? Does it read from the HE database? not a whole lot of info
1 Like
I didnt understand that to... but I have asked him about it on the Vera Forum...
Its it confirmed Local! 
1 Like
Neat, I might take a look.
Very cool, one question, what does it run on? Does it need a Vera hub or can it be run on something like a RPi or maybe even natively on HE 
1 Like
That's cool but one thing im not clear on. I get that the config gets saved the the app on phone/tablet and the app interprets the xaml file. What im not clear on is what goes on the hubitat side? Is there an app that gets installed?
Ouch, that seems worse than Rule Machine.
I miss Stringify, I really do.
And don't talk to me about Node-RED. i use it. It's good. But it ain't exactly easy enough to provide a platform to really extend capable Home Automation to the masses.
3 Likes
Rule Machine is good but difficult to understand and almost impossible to edit. Reactor is easy to understand and super easy to setup and realtimeinfo on devices..
You can follow for more info on The Ezlo forum
Agreed, but nothing is or it would already be dominating the market...
3 Likes
Eh, we'll see I guess. I'm not super excited based on the you tube video, but it is early. Maybe it will end up useful (?).
I've looked at reactor at least 5 times, and I just don't think it is all that.
1 Like
For sure. But I wouldn't call this a solution to anything. Ah, maybe I should have finished the video and as usual I'm being overly critical. But it leaves me cold. It's obviously created by an engineer. Which is fine. I'm an engineer too. But I want a nice to use, sexy, graphical interface please.
I dont see anything in the marketplace so much better than node-red that I'll be switching in the next year or two.
3 Likes
Exactly correct.
This is a RM pain point for me as well...so many clicks/digging required.
The Event Engine app has been a great option that sits between Simple Automations and RM, and handles a lot of my automation needs.
This does look interesting...
2 Likes
With rm I long for a cli with auto-complete to build up the rules from.
But back on topic, when this is released in a fully Hubitat compatible way I'll probably check it out. Always interested in seeing new ways of doing things.
2 Likes
Yup...new toys are new toys, and must be tried out!
1 Like
not very pretty to look at a rule and quickly see what it does.. the fact that it span devices on multiple hubs/devices is nice.. however, that means i assume you have to have a server that it runs on independent of whatever is running on the hubs.
Patrick Wrote this on the ezlo forum to explain more of why hes putting it together ...
Here’s how I think about it. Let’s take the unmentioned first…
Why make MSR when there’s Node-Red? For starters, I love Node-Red, but the fact that I love it may be something of a red flag. It’s a technical product and requires some pretty technical thinking. In a sense, it’s really like the difference between Reactor and PLEG. PLEG is a great and capable tool, but not everybody gets it, and for those that do, the learning curve can be pretty daunting. I’ve always tried to keep Reactor approachable, although it has clearly grown from simpler, nascent beginning. But still, I think most people get it. So I think there’s room in the HA ecosystem for another logic/rules engine.
Second, the most consistent thing I see in the HA marketplace is that each manufacturer’s rules engines are a disappointment to their users at some level. Vera, of course, never evolved a serious rules engine, probably because PLEG came early enough to take the real pressure off the engineering (or marketing) team to get it done. As promising as Hubitat seems, and as much as many people like its Rules Engine, their forums are like this one in that there are lots of posts of bugs, confusion, etc., and even the lead of that subsystem regularly admits is not everything they wish it could be. HomeAssistant… well, writing automations in YAML should, in my non-serious opinion, be considered a human-rights violation. Their GUI, Automation Editor, isn’t nearly up to snuff. So again, I think there’s room for a system that’s not just cross-platform, because maybe you don’t need it to be, but it presents a friendlier and more approachable environment in which to write automations than that which is native to the platform you’re using, be that many or just one. Choices. More choices.
Third, I think cross-platform is not everyone’s concern, but can be an issue for many people because no hub natively supports everything well – another consistent inconsistency in the HA marketplace. To that end, I’d rather have the option of using the best tool for the job, rather than accepting a compromise of 60% performance on thermostats because the platform otherwise satisfies 95% of my device compatibility needs. That’s a horrible trade-off. If eZLO becomes as awesome at ZWave as Melih touts, then let eZLO be the go-to hub for ZWave, but that should not stop you from using Shelly or Tasmota or ESPHome or Tuya devices just because the available (or not) eZLO plugins for those APIs aren’t up to par.
Finally, it’s not going to be least-common denominator. That may be the default view to keep things simple and for the majority of what users routinely use, but it is my unwavering goal to preserve access to as much as possible of the source environment. What you don’t see much of in the video is that any device from the Vera, for example, can be marked for “full data”. That means that device would bring over all of the Vera state variables defined on it, whether those map into a defined MSR capability or not, and you can use them in automations. That works today. I didn’t take the time to cover it in the video, it was already getting too long, but the way I’ve done Sonos plugin devices so far is a good example: there are six predefined capabilities it uses: av_transport, media_navigation, muting, volume and av_repeat. Clearly not everything you can do with Sonos, or the Sonos plugin enables you to do, is covered by these six, but they represent the majority. The rest are accessible just by tagging the device for full data, and you can do that for all devices, or devices of a certain class/criteria, or just a single device for which you have a specific need. It is also possible (today), entirely through configuration, for a user to define a new capability and add it to an existing entity (so you can make “site-specific” capabilities), and even create custom mappings of devices to entities. For example, at the moment there is no device mapping for the DSC Alarm Panel plugin, but you could sit down and create it in your local config, without writing any code or waiting for code support from me, and make the system publish entities sourced from that device so you can see states and perform actions.
So, that’s a bunch of words that basically come down to this: more choice, more approachable.
2 Likes
