MSR if you have only one system
-
My vote is yes. I was/am running Vera, which we all know is slow and gets bogged down at times. Moving my Reactor for Vera off to its own docker was a huge performance lift in the Vera. I continued to move all of my scenes off next. I now have a Hubitat and Vera, but each are only there for control of the device itself. All my scenes, schedules, modes, etc. are all managed and run by MSR.
-
I just noticed your signature line. That's funny. I realize you don't have Vera. For me though, getting all the routines and everything vendor neutral has made it super simple for me to move/migrate devices between hubs. And the family doesn't know. My only hold up right now is an easy to use and easy to configure dashboard. But I've got a plan for that. Just need to do a bulk migration one day of a group of sensors. I look forward to the day that MSR has its Dashboard running.
-
If you are using openLuup as a single system, that resolves many of the performance issues of the Vera itself (it makes an acceptable radio for the devices it can support, as we all know). There are pros and cons to moving to MSR in this kind of scenario.
You are bridged, meaning there is a socket-based tunnel between the Vera and openLuup to get the Vera devices into openLuup. If you introduce MSR into the equation, then there are three possibilities: (1) you configure MSR to talk to the Vera directly, in which case MSR brings the Vera devices in and lets you run the rules, etc., but it can't see the openLuup devices (only relevant if there are other plugins/devices on openLuup that you need access to from MSR); (2) you configure MSR to talk to openLuup, in which case you have all of your Vera and openLuup devices available in MSR, but MSR is talking to the Vera devices over a bridge to openLuup that is talking to the Vera devices over the bridge to Vera (bridge to a bridge, not very efficient); (3) you connect MSR to both, in which case you have all the devices from both like #2, with the option of talking to the Vera devices more directly, but confusion may set in because all of the Vera devices will appear as both the native Vera entities and bridged openLuup entities -- every Vera device is listed in MSR once for its appearance on Vera and again for its appearance in openLuup.
The biggest con to staying on the Reactor plugin (for Vera/openLuup) is that I have no further development planned for it. As new features go into MSR, I have no plans to "back port" them into R4V. As Vera is "walking dead", so is every Vera plugin, including R4V.
-
I just noticed your signature line. That's funny. I realize you don't have Vera. For me though, getting all the routines and everything vendor neutral has made it super simple for me to move/migrate devices between hubs. And the family doesn't know. My only hold up right now is an easy to use and easy to configure dashboard. But I've got a plan for that. Just need to do a bulk migration one day of a group of sensors. I look forward to the day that MSR has its Dashboard running.
@3rdstng I have walked the HA route instead of Openluup. Vera for the devices that are supported by it and HA for the ones that are not supported by Vera. I have connected MSR directly to Vera and the same for HA to Vera which means I see them twice in MSR as described above which could sometimes lead to some confusion. However, I use MSR for all the rules and HA for its very flexible dashboards and support to devices that are not (and will not be) supported by Vera.
-
If you are using openLuup as a single system, that resolves many of the performance issues of the Vera itself (it makes an acceptable radio for the devices it can support, as we all know). There are pros and cons to moving to MSR in this kind of scenario.
You are bridged, meaning there is a socket-based tunnel between the Vera and openLuup to get the Vera devices into openLuup. If you introduce MSR into the equation, then there are three possibilities: (1) you configure MSR to talk to the Vera directly, in which case MSR brings the Vera devices in and lets you run the rules, etc., but it can't see the openLuup devices (only relevant if there are other plugins/devices on openLuup that you need access to from MSR); (2) you configure MSR to talk to openLuup, in which case you have all of your Vera and openLuup devices available in MSR, but MSR is talking to the Vera devices over a bridge to openLuup that is talking to the Vera devices over the bridge to Vera (bridge to a bridge, not very efficient); (3) you connect MSR to both, in which case you have all the devices from both like #2, with the option of talking to the Vera devices more directly, but confusion may set in because all of the Vera devices will appear as both the native Vera entities and bridged openLuup entities -- every Vera device is listed in MSR once for its appearance on Vera and again for its appearance in openLuup.
The biggest con to staying on the Reactor plugin (for Vera/openLuup) is that I have no further development planned for it. As new features go into MSR, I have no plans to "back port" them into R4V. As Vera is "walking dead", so is every Vera plugin, including R4V.
@toggledbits said in MSR if you have only one system:
If you are using openLuup as a single system, that resolves many of the performance issues of the Vera itself (it makes an acceptable radio for the devices it can support, as we all know). There are pros and cons to moving to MSR in this kind of scenario.
You are bridged, meaning there is a socket-based tunnel between the Vera and openLuup to get the Vera devices into openLuup. If you introduce MSR into the equation, then there are three possibilities: (1) you configure MSR to talk to the Vera directly, in which case MSR brings the Vera devices in and lets you run the rules, etc., but it can't see the openLuup devices (only relevant if there are other plugins/devices on openLuup that you need access to from MSR); (2) you configure MSR to talk to openLuup, in which case you have all of your Vera and openLuup devices available in MSR, but MSR is talking to the Vera devices over a bridge to openLuup that is talking to the Vera devices over the bridge to Vera (bridge to a bridge, not very efficient); (3) you connect MSR to both, in which case you have all the devices from both like #2, with the option of talking to the Vera devices more directly, but confusion may set in because all of the Vera devices will appear as both the native Vera entities and bridged openLuup entities -- every Vera device is listed in MSR once for its appearance on Vera and again for its appearance in openLuup.
The biggest con to staying on the Reactor plugin (for Vera/openLuup) is that I have no further development planned for it. As new features go into MSR, I have no plans to "back port" them into R4V. As Vera is "walking dead", so is every Vera plugin, including R4V.
Thanks. That last paragraph is the only one that seems to apply, unless for 'Vera', I read Z-Way-Server?
The last paragraph is compelling. I assume there's not conflict runnin MSR and Reactor together?
C
The Ex-Vera abuser know as CatmanV2.....
-
@toggledbits said in MSR if you have only one system:
If you are using openLuup as a single system, that resolves many of the performance issues of the Vera itself (it makes an acceptable radio for the devices it can support, as we all know). There are pros and cons to moving to MSR in this kind of scenario.
You are bridged, meaning there is a socket-based tunnel between the Vera and openLuup to get the Vera devices into openLuup. If you introduce MSR into the equation, then there are three possibilities: (1) you configure MSR to talk to the Vera directly, in which case MSR brings the Vera devices in and lets you run the rules, etc., but it can't see the openLuup devices (only relevant if there are other plugins/devices on openLuup that you need access to from MSR); (2) you configure MSR to talk to openLuup, in which case you have all of your Vera and openLuup devices available in MSR, but MSR is talking to the Vera devices over a bridge to openLuup that is talking to the Vera devices over the bridge to Vera (bridge to a bridge, not very efficient); (3) you connect MSR to both, in which case you have all the devices from both like #2, with the option of talking to the Vera devices more directly, but confusion may set in because all of the Vera devices will appear as both the native Vera entities and bridged openLuup entities -- every Vera device is listed in MSR once for its appearance on Vera and again for its appearance in openLuup.
The biggest con to staying on the Reactor plugin (for Vera/openLuup) is that I have no further development planned for it. As new features go into MSR, I have no plans to "back port" them into R4V. As Vera is "walking dead", so is every Vera plugin, including R4V.
Thanks. That last paragraph is the only one that seems to apply, unless for 'Vera', I read Z-Way-Server?
The last paragraph is compelling. I assume there's not conflict runnin MSR and Reactor together?
C
@catmanv2 said in MSR if you have only one system:
unless for 'Vera', I read Z-Way-Server?
Not sure what you mean here.
There is no problem running the Reactor for Vera plugin on a Vera or openLuup and running MSR in parallel with it.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@catmanv2 said in MSR if you have only one system:
unless for 'Vera', I read Z-Way-Server?
Not sure what you mean here.
There is no problem running the Reactor for Vera plugin on a Vera or openLuup and running MSR in parallel with it.
Typed earlier:
'You are bridged, meaning there is a socket-based tunnel between the Vera and openLuup to get the Vera devices into openLuup.'
Should I read z-way-server for Vera as I don't have a Vera any more?
C
-
I don't know how the openLuup ZWay integration works, I don't use it, but if it communicates via a socket with openLuup, then yes, tunnel-to-tunnel. At least its within the same system, though.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
I don't know how the openLuup ZWay integration works, I don't use it, but if it communicates via a socket with openLuup, then yes, tunnel-to-tunnel. At least its within the same system, though.
@toggledbits said in MSR if you have only one system:
I don't know how the openLuup ZWay integration works
It's using polling via HTTP.
-
T toggledbits locked this topic on
