Indigo very slow to receive updates from Vera devices

Posted on
Wed Feb 11, 2015 7:16 pm
Juggler offline
Posts: 95
Joined: Dec 17, 2014

Indigo very slow to receive updates from Vera devices

I have a Vera Lite with 3 z-wave devices connected: a Yale doorlock, Leviton 4-button zone controller and Leviton 2-button scene controller. I've migrated the rest of my z-wave devices to Indigo where they work very well.

The problem I'm finding is that Indigo is very slow to update the status of any of the Vera devices via the Vera Bridge plugin. I've seen comments that it was a little slow, but I'm finding it often takes several minutes before I see that a Vera-linked device has been turned on/off. I'm curious how this has been implemented... is the plugin using the http://veraIP/data_request?id=lu_sdata& ... mumdelay=0 URL? This seems to be the best way from the developer notes on MiOS.

I've previously written a very basic NodeJS that provides updates of my Vera's device's status. I found that it did provide quite good status updates... Here is my script:

Code: Select all
var defaultMinimumDelay = 2000;

function mios_getData(poll, loadTime, dataVersion, timeOut, minimumDelay) {   
   var options = {
         host: veraIP,
         port: 80,
         path: '/data_request?id=lu_sdata&loadtime=' + loadTime + '&dataversion=' + dataVersion + "&timeout=" + timeOut + "&minimumdelay=" + minimumDelay
      };
      console.log('MiOS: requesting update from MiOS');   
      http.get(options, function(res) {
         var body = '';
         res.on('data', function (chunk) {
            // large responses come in chunks, stitch them together
            body += chunk;
         });
         res.on('end', function () {
            //console.log('MiOS BODY: ' + body);
            var mios_bodyJSON = JSON.parse(body);
            loadTime = mios_bodyJSON.loadtime;
            dataVersion = mios_bodyJSON.dataversion;         
            minimumDelay = defaultMinimumDelay;
            if (mios_bodyJSON.hasOwnProperty('devices'))
               mios_sendData(mios_bodyJSON);                           // fuction to send the updated devices
            if (poll)
               mios_getData(true, loadTime, dataVersion, timeOut, minimumDelay);
         });   
      }).on('error', function(e) {
         console.log('ERROR, MiOS: ' + e.message);
         setTimeout(function() {
            mios_getData(receivers, poll, 0, 0, 60, 0);
         }, 10000);         
      });
}

Posted on
Thu Feb 12, 2015 5:42 am
eme jota ce offline
Posts: 618
Joined: Jul 09, 2009
Location: SW Florida

Re: Indigo very slow to receive updates from Vera devices

The Vera plugin for my locks can be slow. Worst case is around 30 seconds.

Recently saw improvements in the Vera devices / Indigo after a Vera Repair. Log into Vera: Setup -> Z-Wave Settings -> Repair -> Go.

Takes a while to run. I ran twice and the report showed better communications the second time.

In my case, I had moved / added / remove some devices on the Vera network.

Posted on
Thu Feb 12, 2015 10:31 am
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

That is the URL used by the plugin. I normally experience about a 3 second delay on updates, though every once in a while it'll be longer, sometimes much longer. I only use it for a lock so maybe I'm just not seeing it as much as others. I don't believe it's anything Indigo is doing/not doing, rather I think the Vera, particularly the Lite, it quite underpowered and sometimes it's just busy and the API doesn't get the time it needs to run.

In your case, I suspect something else is going on with the Vera but that's just a guess. eme jota ce's idea is definitely something you might want to try.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Thu Feb 12, 2015 11:52 am
Juggler offline
Posts: 95
Joined: Dec 17, 2014

Re: Indigo very slow to receive updates from Vera devices

I've done the repair on my Vera, but that didn't help.

I have just tried turning on debugging, and am now seeing lots of action in the Event Log, but nothing seems to actually update the Device in Indigo. For the following log, I turned the switch on from the MiOS webinterface. It looks like the Vera Bridge plugin sees the action, but something is missed. Can anyone smarter interpret this?

Code: Select all
Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'status': u'1', u'comment': u'_2 button scene controller (switch): Transmit was ok', u'room': u'0', u'parent': u'1', u'altid': u'23', u'state': u'4', u'id': u'19', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'status': u'0', u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'3', u'state': u'-1', u'id': u'4', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: ending at 12:43:42
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'status': u'1', u'comment': u'_2 button scene controller (switch): Transmit was ok', u'room': u'0', u'parent': u'1', u'altid': u'23', u'state': u'4', u'id': u'19', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               processUpdate: found device (livingroom scene button) updating: {u'status': u'1', u'comment': u'_2 button scene controller (switch): Transmit was ok', u'room': u'0', u'parent': u'1', u'altid': u'23', u'state': u'4', u'id': u'19', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: starting at 12:43:45
  Vera Bridge Debug               vera thread: _update: url: http://192.168.2.7:3480//data_request?id=lu_sdata&output_format=json&loadtime=1423760880&dataversion=760880129
  Vera Bridge Debug               vera thread: _update: ending at 12:43:45
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'status': u'0', u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'3', u'state': u'-1', u'id': u'4', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               vera thread: _update: starting at 12:43:48
  Vera Bridge Debug               vera thread: _update: url: http://192.168.2.7:3480//data_request?id=lu_sdata&output_format=json&loadtime=1423760880&dataversion=760880129

Posted on
Sun Jun 07, 2015 1:26 pm
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

Hey guys,

I've noticed the same issue and it seems to me like there is a bug in the Vera Bridge plugin somewhere. Note the logs below. I've turned a light on via a zwave switch. At the next update Vera reports the state in its JSON response. The Vera Bridge plugin seems to get this information (note in the log it reports "Hall Light", staus "1"), but the state of the light is never updated in Vera (the interface still reports off, actions are not triggered etc.)

Later, when I turn the light off, the same thing happens (see the second log snippet). The plugin seem to see the update fine, but nothing is triggered.

I have noticed that if I request a status update ("Send Status Request"), that when the plugin requests the full update, it seems to catch the changes at that point.

One shot in the dark... Is the plugin looking at the "state" variable or the "status" variable? From reading through the Vera wiki, it looks like it should be looking at status, but it seems like maybe the plugin is using state instead?

Is the code for the plugin available somewhere? I'd be happy to do some debugging if it is...

Thanks


After light turned on:
Code: Select all
Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503210
  Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'19', u'state': u'-1', u'id': u'83', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'comment': u'', u'status': u'1', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: ending at 12:10:33
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'19', u'state': u'-1', u'id': u'83', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               vera thread: _update: starting at 12:10:36
  Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503228
  Vera Bridge Debug               vera thread: _update: ending at 12:10:37
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'comment': u'', u'status': u'1', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               processUpdate: found device (Hall Light) updating: {u'comment': u'', u'status': u'1', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: starting at 12:10:40
  Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503228
  Vera Bridge Debug               vera thread: _update: ending at 12:10:40
  Vera Bridge Debug               vera thread: _update: starting at 12:10:43
  Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503228
  Vera Bridge Debug               vera thread: _update: ending at 12:10:43




After light turned off:
Code: Select all
 Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503251
  Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'19', u'state': u'-1', u'id': u'83', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: partial deviceInfo:
{u'status': u'0', u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: ending at 12:14:54
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'19', u'state': u'-1', u'id': u'83', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               vera thread: _update: starting at 12:14:57
  Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503269
  Vera Bridge Debug               vera thread: _update: ending at 12:14:57
  Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'status': u'0', u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               processUpdate: found device (Hall Light) updating: {u'status': u'0', u'comment': u'', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}
  Vera Bridge Debug               vera thread: _update: starting at 12:15:00
  Vera Bridge Debug               vera thread: _update: url: http://10.0.0.13:3480//data_request?id=lu_sdata&output_format=json&loadtime=1433142032&dataversion=143503269
  Vera Bridge Debug               vera thread: _update: ending at 12:15:00



From full status request
Code: Select all
 Vera Bridge Debug               runConcurrentThread: processing update: {'device': {u'category': 3, u'status': u'1', u'room': 0, u'parent': 1, u'altid': u'20', u'comment': u'Hall Light: Transmit was ok', u'name': u'Hall Light', u'state': 4, u'id': 81, u'subcategory': 0}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called
  Vera Bridge Debug               processUpdate: found device (Hall Light) updating: {u'category': 3, u'status': u'1', u'room': 0, u'parent': 1, u'altid': u'20', u'comment': u'Hall Light: Transmit was ok', u'name': u'Hall Light', u'state': 4, u'id': 81, u'subcategory': 0}
  Trigger                         Hall Lights Come On
  Sent INSTEON                    "Bathroom Hall KPL" keypad button 3 on

Posted on
Tue Jun 09, 2015 10:18 am
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

We're definitely looking at status - from the processUpdate method:

Code: Select all
elif "status" in deviceInfo and devType != 5 and devType != -1:    # thermostats have no on off state
  dev.updateStateOnServer(key="onOffState", value=bool(int(deviceInfo["status"])))


So, after that update, the device state in Indigo should have been on - that happens immediately when dev.updateStateOnServer executes. When the Indigo server sees the state change, then it will update the device state which will automatically cause triggers to fire. I'm pretty sure that something else outside of the plugin is the problem.

The code is inside the plugin itself - feel free to dig into it if you like.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Jun 09, 2015 10:53 pm
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

Thanks Jay,

I'm looking for the code in the plugin folder (Library/Application Support/Perceptive Automation/Indigo 6/Plugins/Vera Bridge.indigoPlugin/Contents/Server Plugin) I see a few XML files (which do not appear to have the code) and then two additional files: plugin.so and veralib.so. These appear to be Mach-O object files... Am I looking in the wrong spot? Or do I possible have the wrong version of the Vera Bridge?

Thanks

Posted on
Wed Jun 10, 2015 9:16 am
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

Doh - sorry, I forgot we were compiling that plugin.

I'm not sure that looking at the code is going to help you though. When Indigo processes a request, it immediately updates the state on the server. I'd recommend doing some more testing and closely watching the debug log for the bride plugin and the device states. I'm pretty positive that there is no delay once the update gets processed (processUpdate called) to when the device state gets changed in Indigo.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jun 10, 2015 9:42 am
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

Thanks Jay,

I'm not sure what's going on, but there has to be a reason the state isn't being updated. Looking at the logs, I can see the plugin making the request, it sees the change, identifies the device, prints the correct status, but the state doesn't change in Indigo. I can visit the same API call (on Vera) that's being reported in the debug logs and and see that the status field is being reflected as updated correctly in the API response--and Vera updates the device state properly in the UI as well.

If you look at the logs I posted earlier, it seems pretty clear that during the normal recurring updates, processUpdate is being called, but actions aren't being triggered and the state isn't changed, compare that to the manual full update and immediately after processUpdate the trigger/actions occurs.

Are you compiling this plugin because you don't want to share the code or for another reason? I'd still like to try to debug this because the state are not at all reliable, and everything else I've integrated with Vera doesn't have this type of issue. I've moved everything I can off the Vera but still have a couple of the Leviton scene controllers and a Z-wave lock that Indigo doesn't support, so unfortunately I can't just dump it yet.

Thanks

Posted on
Wed Jun 10, 2015 10:14 am
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

Looking more at your log - it looks like either there is no device defined in Indigo that has the Vera ID (address in Indigo) of 83 OR the device is not enabled. If it were, then the next line after "processUpdate called" would be "processUpdate: found device (NAME HERE) updating: UPDATEDICTHERE". Since that's not in the log, then it means that either there isn't an Vera Bridge device defined in Indigo with an address of 83 or the device isn't enabled.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jun 10, 2015 10:34 am
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

That's true, but device 83 isn't a device I care about. I'm actually not ever sure what that is, I'd have to check when I get home. Since it looks like it changes in tandem with device 81, I'd guess maybe it represents the light on the scene controller?

Device id 81, however is what I'm interested in, and you'll notice the update for device 81 also appears in all three logs, it does have the "found device (Hall Light)" line. This is the device that, while I can see the plugin noticing the updates in the logs, the state isn't updated.

Posted on
Wed Jun 10, 2015 2:15 pm
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

Ah ha - apparently, the Vera API has changed or more likely has a bug - what UI version are you using? In UI5 (at least the version developed against), all the update calls contained a "category" dictionary entry that specifies the device type (light, thermostat, lock, etc).

If you notice, the update we're getting from your Vera:

Code: Select all
{'device': {u'comment': u'', u'status': u'1', u'room': u'0', u'parent': u'1', u'altid': u'20', u'state': u'-1', u'id': u'81', u'subcategory': u'0'}, 'updateType': 'updateDevice'}
  Vera Bridge Debug               processUpdate called


only contains "subcategory". I'm interested to hear what firmware you're using on your Vera because this sure sounds like a bug to me. You might want to check to see if what you're running is the latest for that major revision (be it UI5 or UI7) and if it's not update.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jun 10, 2015 3:24 pm
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

Ahh, interesting. This appears to be my version info:

Code: Select all
VeraFirmwareVersion=1.5.622
VeraUI=5


Which according to their release notes (http://wiki.micasaverde.com/index.php/Release_Notes), appears to be the latest version of UI5... Unless the wiki page is out of date, which wouldn't shock me.

I can confirm it doesn't look like category is being included with the minor updates (as seen below)--which could certainly explain why the minors fail but full updates work if the plugin code is relying on that.

That said, I'm not sure why it would/should include category (or for that matter some of the other data is actually is including, like subcategory) given an application using the minor updates should already know the category of the device. It seems category, subcategory, room etc., should only be included if the value changes for some reason. The API details they have on the wiki don't seem to indicate one way or another whether category should be sent for all requests or only full requests. Sample response below:

Code: Select all
{
full: 0,
loadtime: 1433968744,
dataversion: 968744289,
devices: [
{
altid: "19",
id: "83",
subcategory: "0",
room: "0",
parent: "1",
state: "-1",
comment: ""
},
{
altid: "20",
id: "81",
subcategory: "0",
room: "0",
parent: "1",
status: "1",
state: "-1",
comment: ""
}
]
}


Indigo obviously knows what the device is. Can it be fixed to update the state without requiring that value in the JSON response? I'd be more than happy to attempt to make this update if you guys can make the source available.

Thanks!

Posted on
Wed Jun 10, 2015 4:42 pm
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo very slow to receive updates from Vera devices

It was just a convenient way of determining some things at runtime - like when they send erroneous data that's not valid for some device types. Most importantly, though, it shows how tricky doing APIs right is and how rigorous you have to be when making changes to them. Most vendors exposing APIs do a really poor job of that.

I'll look at removing that dependency in the next release.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jun 10, 2015 4:58 pm
nanobots offline
Posts: 43
Joined: Apr 28, 2015

Re: Indigo very slow to receive updates from Vera devices

jay (support) wrote:
Most importantly, though, it shows how tricky doing APIs right is and how rigorous you have to be when making changes to them. Most vendors exposing APIs do a really poor job of that.


Agreed.

I'll look at removing that dependency in the next release.


Great, thanks!

Who is online

Users browsing this forum: No registered users and 1 guest