We have moved at community.getvera.com

Author Topic: how-to: mirroring select openLuup devices/variables on real Vera  (Read 7181 times)

Offline rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1749
  • Karma: +101/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #45 on: December 01, 2017, 02:42:56 pm »
Just to be clear, you were referring to a global variable in the Lua context, rather than just a device variable that could be the same on both?

Could you clarify the functionality of your scenes?  I?m not sure, now, that I?m clear on your use case.

@akbooer.

The global variable is indeed in the Lua context. I am using it as a status flag.
The specific application is this:
I have scenes which turn on my home theatre depending on what other devices are playing. For example if I play music on the SONOS all house group, I want my home theatre to turn on and play it there too. The problem is, I also have TTS announcements through the house for which case I do not want the home theatre to turn on so I created a global variable in the vera to report the TTS status. If the SONOS is running a TTS, then the flag is on, after some delay, specific to that particular TTS, the scene turns the flag off. I then have the scene turning on the home theatre check the flag.

Now I am starting to split my automation with Openluup and I want this flag to be synchronized between the openluup and the vera. Most TTS are still triggered by the vera while the home theatre is controlled by Openluup.

I have other similar examples where I used a global variable as a status flag.
Right now, I am using Luup code with scenes to call a scene on the other device to toggle the flag which works fine but I was wondering if there is more elegant ways to do this.

One other thought, and you may have some input on it:
The reason for me to split the logic is response lag from triggers: All my Zwave triggered automation is still on the vera because there is a lag between when a variable is changed on the vera and when it is reported on openluup as it appears due to polling frequency and response delay. If the vera was actively pushing all the device states to openluup then maybe I would move all my scenes to openluup but I am wondering if this would be too much of a load for the vera to watch this many variables.






« Last Edit: December 01, 2017, 02:44:36 pm by rafale77 »
openLuup (79 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #46 on: December 01, 2017, 04:55:05 pm »
One other thought, and you may have some input on it:
The reason for me to split the logic is response lag from triggers: All my Zwave triggered automation is still on the vera because there is a lag between when a variable is changed on the vera and when it is reported on openluup as it appears due to polling frequency and response delay. If the vera was actively pushing all the device states to openluup then maybe I would move all my scenes to openluup but I am wondering if this would be too much of a load for the vera to watch this many variables.

If I thought that pushing data from Vera was a good idea, I would have written the bridge to do that!  You're right, of course, about the lag due to polling, but this did meet my original design criteria of no code required to be run on the Vera.  You have to realise that even if you push something to openLuup, it might be doing something else (running somebody's plugin code doing I/O, for example) which may take some time.  In the end, it is all single-threaded.

The transition of logic between Vera and openLuup is certainly an interesting topic.  Race conditions are a potential issue, but then, if your logic is timing critical, there's either something wrong with your design, or you simply shouldn't be doing it like that.

I have a long-held (and long-term) plan to rewrite the bridge using asynchronous I/O which would mitigate this problem, but it seems like an awful lot of effort for little gain.

You can certainly write code which sends specific variable changes immediately to the remote machine (be it Vera or openLuup) but there will always be some delay.  My favorite handshake-free protocol for this is UDP, which is what DataYours uses to push data around its modular, and possibly multi-processor, architecture in a much, much more efficient manner than a TCP or, heaven forfend, HTML protocol stack.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1749
  • Karma: +101/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #47 on: July 04, 2018, 05:41:08 am »
Old discussion but just wanted to post that I ended up testing this idea.
My openLuup instance is currently installed on a VM running on a single thread along with a number of other things (ha bridge, sonos API, airsonos and homekit bridge) of an Core i7 6700K. The single thread is actually quite fast.
Having moved all the scenes I could move from the vera to openLuup, I am indeed seeing a lag from the polling rate of openLuup to the vera. There is only one type of variable I want "instantly" mirror from the vera to openLuup and it is currently the "Tripped" variable from all of my door and motion sensors.

I added the following code to my vera startup lua and it seems to have eliminated the lag. I will report if I see other issues but so far so good. Eventually I will be replacing the vera at least as a zwave bridge with zway but I thought it is an interesting experiment.

Code: [Select]
function updatetrip(lul_device, lul_service, lul_variable, lul_value_old, lul_value_new)
     local tgt = tonumber(lul_device) + 10000
     local message = string.format("http://**openLuup_ip**:3480/data_request?id=variableset&DeviceNum=%s&serviceId=urn:micasaverde-com:serviceId:SecuritySensor1&Variable=Tripped&Value=%s",tgt,lul_value_new)
     luup.inet.wget(message)
end

for k, v in pairs(luup.devices) do
   if v.category_num == 4 and (v.subcategory_num == 1 or v.subcategory_num == 3) then
      luup.variable_watch("updatetrip", "urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", k)
   end
end
openLuup (79 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #48 on: July 04, 2018, 06:36:55 am »
Yes, you can certainly do that.

The central tenet of openLuup was that NO code should be required on Vera, and I did the best I could with that.  If it's not fast enough you could certainly make the polling faster, but you won't beat the 'instant status' approach here.

Horses for courses.

_______________________

Edit:  You could, in fact, make it even faster by sending a UDP datagram to a UDP listener on openLuup, which would then set the necessary variable, overcoming the HTTP handshake lag inherent in that protocol.
« Last Edit: July 04, 2018, 06:39:36 am by akbooer »
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1749
  • Karma: +101/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #49 on: July 04, 2018, 02:58:08 pm »
AK: don't get me wrong. It is working awesomely well. I am just a bit picky and found the response lag a bit longer than I wanted. It is amazingly fast now. It is even faster than when I had all the logic on the vera itself which goes to validate if it was needed that the vera is inefficient and overloaded!

zwave trigger -> Vera variable change -> wget to openLuup -> openLuup scene logic -> wget to vera -> zwave action

is much faster and more reliable than

zwave trigger -> Vera variable change -> vera scene logic -> zwave action.
openLuup (79 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #50 on: July 04, 2018, 03:24:04 pm »
No, that's all good.

It's actually surprising that the bridge works as well as it does.  Its design was a prototype "proof of concept" that was originally written to run on Vera to get around the native bridging problems that they had.

It doesn't run on Vera now, but the basic architecture hasn't changed.  A properly written bridge could be about as fast as your work-around, receiving a Vera HTTP response pretty much as soon as a variable changes.  It requires an asynchronous HTTP GET implementation, which I have never got around to doing, but one day, perhaps...

More urgently, the native digest authentication is in hand, but you have another work-around for that already.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1749
  • Karma: +101/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: how-to: mirroring select openLuup devices/variables on real Vera
« Reply #51 on: July 04, 2018, 05:02:38 pm »

More urgently, the native digest authentication is in hand, but you have another work-around for that already.

indeed  8)
I am doing what I can to make this whole setup work. I just made a discovery on the vera which appears to fix almost all the problems I have had with it. I posted it in the general thread. It seems like the event sync calls to the mios server is the main culprit for the slowness and instability of the vera. I have always felt that the mios cloud was one of the source of the random luup reloads along with the number of devices which is what drove me to try to firewall the vera. I will verify in the next few days but so far it looks promising.
openLuup (79 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.