websocket

[rafale77]

A brainfart or maybe wishful thinking here but besides MQTT, it would be a really nice addition for openLuup to provide a websocket server which would "lock" the messages tighter than MQTT and then give allow MSR to connect to it through this protocol rather than the vera style http API.
This came to me as I was observing MSR connection to openLuup through polling adding 0.3-0.4% of CPU load while not doing much of anything to Home-assistant. Just putting it out there. z-way-server also provides a websocket server through an app which could be used instead of the current fixed interval polling of the z-way bridge. MQTT would provide the same benefit but likely require a lot more user intervention to setup the MQTT topics and messages though it would lose the distributed clients/servers aspect.

[toggledbits]

I think part of the issue on openLuup is that it sends updates/deltas for things that aren't changing. You pointed out yesterday that scenes were green-lighting frequently on the Entities list in MSR, and this is a symptom of that condition. I've also observed it my dashboard for some time, and also in my automated test tool. On my house Vera Plus, with 200 devices, I'll only get occasional delta returns with 1-2 devices, usually from polling activity, when things are otherwise quiet. In openLuup, my test system will routinely respond with dozens of devices, and the same devices over and over again even when they do not appear to be changing. So not only is the traffic higher, but the response size is also larger and takes more time to process, for no benefit. Still, that hasn't been much of an impact on anything, so I haven't bothered to report it, except perhaps once in passing on another subject.

I think if some attention is paid to this area in openLuup and those issues are run down and fixed, the impact on performance would be markedly improved. Really, the long polling works very well, and while I agree that websockets would be better as a long-term objective, it's probably low hanging fruit to fix the long polling now and leave WS as "tomorrow" project.

[akbooer]

@toggledbits said in websocket:

think part of the issue on openLuup is that it sends updates/deltas for things that aren't changing.

This, of course, could be fixed. It's just laziness on my part, in the original implementation, that this isn't done properly.

Well, perhaps not just laziness, but also the ever-present difficulty of finding out exactly what and when Vera chooses to do things.

Is there anything other than scenes causing particular grief at the moment? You mention devices. These should be correctly treated and not sent in responses to status requests (which, I assume, is what you're talking about?). The whole thing hinges on when the internal variables dataversion and userdata_dataversion are updated. I had taken a fairly conservative approach to this in the past, so as not to miss any updates, but perhaps this is causing you issues now.

The one thing it is probably not, is "low hanging fruit". This one's going to be a bit of a nightmare.

[akbooer]

Just checking that status code for scenes and, as I thought, there's a line with a relevant comment:

  for id, s in pairs (luup.scenes) do    -- TODO: actually, should only return changed ones

[rafale77]

Scenes and rooms seem to be updating constantly.

[toggledbits]

Every update seems to contain all of the scenes. It also looks like whenever a state variable on a device is updated, all the state variables are sent, not just the updated ones, which is different from Vera. It just seems to pop off and randomly report a device has changed, sometimes multiple, when there's no evidence that any change has occurred at all, and since the data contains all the states, and timestamps for the states aren't (normally) part of the response, there's no way to tell what it thinks has changed about it.

[akbooer]

@toggledbits said in websocket:

Every update seems to contain all of the scenes

Yes, that’s what my commented line shows.

Do you have any insight at all as to what changes triggers a scene to report its status? Presumably when it runs?? Unlike devices, the scenes data doesn’t contain a userdata_dataversion.

[rafale77]

Would be nice to get this fixed as it is quite distracting on MSR but could also be some wasted CPU clock when using ALTUI. For sure the scenes seem to update without running at all and so are the rooms.