Well done! 
Local on Vera or and Hubitat for example?
Wow!! I had a look at your Rumble video and this is really very impresive Patrick. 
. This is smart 2.0! Combining your Dashboard and the Reactor indeed offers a good solution to become less dependent on one single home controller hub (allthough if a hub satisfies all the needs it is also okay).
Patrick - you truely are the Einstein and the wizard of home automation. 
I have only just begun the Home Assistent journey, combined with my Veras. In HA I’ve only added devices so far. The main reason I haven’t started with automations within the HA, is because I have missed the Reactor and the learning curve is long. All my active automations are being handled by reactor right now. But that means I can’t use the full potential and all the entitys in HA. This MSR is a total game changer! I haven’t donated anything before, but now I’m so greatfull for your work, 
so I think it’s time!
Thank you and have a great year!! Over and out,
/Fanan
4 Likes
Interesting. Does it run on Vera or also on other platforms? Dashboard runs in browser?
Hey Patrick, FYI, I have been working on a HomeKit bridge for Ezlo where I too abstracted out the concept of individual hubs and perhaps some of it may be of interest or even direct use to Multi-System Reactor. In particular, I have implemented an interface to Ezlo hubs that discovers and proxies ezlo hubs over secure websockets. The API will discover all ezlo hubs on the local network and establish a “local” connection to each, using either “live-credentials” from the MIOS portal, or static credentials in a local configuration file, and provides an API used by my homebridge-ezlo plugin to expose ezlo devices as HomeKit accessories. As a result, it too is extremely responsive and fast - accessory changes are instantaneous.
If you look at the diagram below, the “Ezlo API” side of the diagram could also be used to power an Ezlo Controller for MultiSystem Reactor. For my purposes, I needed something that could run in a homebridge nodejs instance so I wrote it in typescript because I haven’t implemented much javascript in the past and felt that the type-safety would help. My plan is to publish it all to GitHub when it is ready but I need a bit more time on the Homebridge side of the equation.
There is also Rene’s ezlo-bridge that might be an easier fit but I thought I would toss it out anyway.
What language are you using for the ReactorMS Controllers and ReactorMS back-end? Any thoughts/interest?
1 Like
It runs under pretty much any of the major Linux distributions at the moment. I will be looking to have it run under Windows and MacOS as well. My goal is to have docker containers for the most common NAS systems as well. It should run on a Raspberry Pi.
2 Likes
I’m also under nodejs. If you wanted to write the eZLO interface, I’d be happy to have you do that once I’ve gotten enough docs together to support others doing it.
Sounds good.
It might also be interesting to bridge HomeKit accessories to ReactorMS! 
It’s not really built to run on the controller as much as it is to run with it. My goal is make a Raspberry Pi an acceptable platform for a modest-sized system. The latest model is quite robust. A lot of HA users seem to also use home or small-office NAS systems, and most of those systems support docker containers (as does RPi), which makes an easy, trouble-free install without a lot of admin know-how. So those are my initial target user groups. The folks using Linux VMs or dedicated hardware will have it easy, as they’ll be able to choose docker or an install archive.
That said, I do have a successful build environment for the version of OpenWrt currently underpinning the Vera firmware, so it remains for me to test if I can get a version of nodejs up and running there. If that’s the case, it could be installed side-by-side with the Vera firmware. Another similar option for later consideration (at/after Vera EOL) is to build a stock-but-current OpenWrt image for the Vera hardware, so that you’d be able to extend the life of that hardware.
Of course, at the moment I have more options in front of me than time/hands, and most importantly, I’m going to let the community guide my priorities. Right now, it’s all about fit-and-finish for this first version. I can’t learn anything until somebody other than me uses it.
6 Likes
Sounds fantastic…
I have also started down the HA road. I hope that reactor will end up working on the hassOS, as I went down the RPI4 road, with hassOS on an SSD drive.
But as I said, can’t wait to try this
Yeah, I’ll offer my help to support both Shelly and Tasmota, since they’re two popular options for people here. I know they’re supported by Home Assistant as well, but I’m thinking of people wanting to integrate them in a straightforward way into scenarios via Reactor. Looking at your video, it should be easy to add sensors to the equation as well. Great job!
1 Like
Well, I guess now I know where to focus my documentation efforts! 
I have a couple of questions if I may.
-
Will it support Z-Wave and Zigbee devices paired to an Ezlo Plus hub at some point?
-
If I ditched PLEG on my Vera Plus and started using Multi-System Reactor instead, say on a Raspberry Pi, for use with the devices paired to my Vera Plus, at a later date how difficult would it be to migrate to another controller hub as far as Reactor is concerned?
From a Vera Plus to Ezlo Plus or from a Vera Plus to Hubitat hub or whatever.
Presumably all the devices moved to the new controller would be seen by Reactor as new devices on a different controller than what they were originally located on.
How easy to keep all your existing Reactor rules / automations / logic / scenes? Sorry I don’t know what they are called in Reactor.
- Sounds like Multi-System Reactor will be for a Raspberry Pi or a system running Docker. Rather than actually being installed as a plugin on the Z-Wave controller hub itself.
What are the benefits of this? Other than enabling cross platform support for various Home Automation controllers.
Thanks.
Wow! That’s one of the things missing for me to move more devices to Ezlo. HomeKit integration. Sign me up if you need any help with beta testing when you’re there!
1 Like
Yes, that’s how it’s intended to work. Someone (me, @blacey if he’s willing, or someone else) will need to write an eZLO interface, but MSR is designed to work this way. It uses an object to interface with a system or API, and that object publishes the objects it sees/finds/knows into the Reactor environment. Currently, there is an object called VeraController that you can configure with the IP address of your Vera or openLuup system, and it publishes all devices, rooms, and scenes into MSR’s environment. There is a HassController, and HubitatController, as well. There is a CameraController, for which you provide via configuration the IP address, URL, and auth info for your cameras, and it publishes camera objects into the MSR environment. A WeatherController is configured with your location and account information and draws data from weather APIs to populate weather objects. The future will surely include an eZLO interface object, and as @therealdb offered, objects for direct interface to Shelly and Tasmota (so you could see and control these devices directly, without having to go through an extension on Vera/Hass/HE/other). There is no reason the future could not include a ZWay and/or OpenZWave interface object as well.
The current Vera Reactor has a device replacement tool that appears on the Tools tab when a device specified in conditions or activities is no longer available. This will “grow up” into a more general utility for system-wide device replacements. I am also playing with an idea for temporary replacement of a device (“when this device is referred to, use this one instead for now”), so you can trial-run replacement devices or just quickly patch past a device that has failed (e.g. if a bedroom temperature sensor fails but the thermostat reading is good enough until you get it fixed/replaced).
For current Reactor users, my plan before first public release is to have an import tool that takes the configuration of a Vera-based ReactorSensor and transforms it into MSR’s form with devices mapped to MSR entities. The formats of the configuration data between the two systems are, as you might imagine, very similar, mostly just changes in field names and some light cleanup of the structure to simplify the code in both the UI and Core. It will probably take more time to make the UI for that feature than the feature itself.
That’s right, since devices don’t really identify themselves uniquely in a portable way. That is, Vera has its device IDs, and UDNs (the rarely-used UIDs associated with a device), but if you exclude a Vera device and include it on a C7, none of that data follows the device, so there’s no way to know it’s the same physical unit just moved between controllers. Rather than trying to shoe-horn some kind of unique identifier overlay on both systems, it just seems easier and cleaner to provide a migration tool (“that device is now this device”) that you run once for the device and have done with it. I don’t want people to have to think about UIDs, and really as much as possible, any kind of IDs at all.
ReactorSensors, and yes, as I said above, it will be easy to bring it in, if you wish. There’s also no reason not to leave an automation on the Vera, if that’s what you want to do. Any system is going to come with certain steps that have to be taken to be functional, but I’m trying to minimize these as much as possible, so that any and all migrations are done on the user’s terms and at their leisure. I hate having software force me to change a working environment when I’m new to it and trying to learn how it works, or if I even want to use it. My goal is to make MSR something you can put to work immediately, but if it’s not for you, it hasn’t completely borged your existing setup. So with respect to the importing of ReactorSensors, for example, you might just import your RS into MSR, but disable, not delete, the ReactorSensor, and let MSR take over. If you later decide not to use MSR for that function or at all, you just disable MSR’s rule and re-enable the ReactorSensor. No fuss. No backup/restore or anything that angst-inducing.
Docker anywhere, not just Pi, and that gives it a lot of systems to go it. But it will runnable on systems that aren’t docker-friendly, either. Really the key requirement is nodejs. I’m trying to keep the other dependencies to a minimum. So as I said elsewhere, Windows and MacOS will be good, too.
The issue for the hubs is what’s allowed to run, and that each hub is a completely different architecture, even within the brand (as Vera shows with Edge vs Plus vs Secure, and eZLO with Atom, PlugHub, and the rest). Again, I mentioned above that I’m toying with building a package for Edge/Plus/Secure if I can get nodejs and the dependencies resolved, both so that it’s an easy install/run for any existing Vera user, but also as a way of giving the hardware a second life (long after you migrate off Vera, it could still be sitting there chugging away as your MSR box and be just fine). But nodejs runs in a lot of environments, so there will be lots of choices. The docker containers will be the fast way for the most common, but the ZIP archive is always the swiss-army knife of installers.
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.
6 Likes
MQTT is another good candidate for a platform integration. In a multi system environment I’m finding it invaluable to push data from sensors to my luup system. If the logic is in reactor, I think it’ll be very useful to integrate things (miflora, lgtv2mqtt, tasmota, esphome, hue emulator and even zigbee via zigbee2mqtt).
3 Likes
Yes! Very high on my list!
1 Like
Would this run on an Nvidia shield TV running nodejs?