Devices seem to be "losing sync" in Vera

I’ve posted before about my GE Links and their groups not being in sync with their status with Wink Connect, which isn’t that big of a deal but I recently purchased a bunch of Trippers at Home Depot on clearance and they also seem to be losing sync with Vera. After a certain amount of time their status no longer updates in my Vera but if I do a resync on the plugin they start working again.

Link to log:

I found a bug that prevented the status for members of a group from being updated…

The update is posted in the “LATEST VERSION” thread.

I haven’t yet found any indication in the logs of what is going wrong with the trippers… I’m Still searching through the log…

I just noticed that my Wink Relay has disappeared again in Vera with the newest update. The switches are still showing up but the Relay itself is gone. Any update on my original issue with devices not updating?

My Relay has not disappeared…

If yours has, it must be something to do with the data sent from the Wink API…

Please enable debug mode and post the logs from a restart or resync…

The original issue was the groups not syncing… The potential fix was posted…

My Relay has not disappeared…

If yours has, it must be something to do with the data sent from the Wink API…

Please enable debug mode and post the logs from a restart or resync…

The original issue was the groups not syncing… The potential fix was posted…[/quote]

Sorry, I was referring to my issue with devices not updating their status. I’m using several Trippers to trigger lights and they work for a few minutes after a re-sync but then stop working.

Here’s the log: Dropbox - WinkLUUP1.txt - Simplify your life

So… You actually have 3 issues:

  1. Group devices lose sync over time.
  2. Trippers loses sync over time.
  3. Wink Relay Device disappears.

Issue 1 should be resolved with v0.20.13 or later… Are you still seeing the devices lose sync?

Issue 2 and 3 have not been addressed… I’ve been sidetracked by RGBW device support…

For issue 2, I do not have trippers, so I will need to rely on logs…

For Issue 3, Neither my Wink Relay device, nor any of the related devices, has disappeared…

I’ll look at the last provided logs to see if anything looks wrong…

[quote=“cybrmage, post:6, topic:189845”]So… You actually have 3 issues:

  1. Group devices lose sync over time.
  2. Trippers loses sync over time.
  3. Wink Relay Device disappears.

Issue 1 should be resolved with v0.20.13 or later… Are you still seeing the devices lose sync?

Issue 2 and 3 have not been addressed… I’ve been sidetracked by RGBW device support…

For issue 2, I do not have trippers, so I will need to rely on logs…

For Issue 3, Neither my Wink Relay device, nor any of the related devices, has disappeared…

I’ll look at the last provided logs to see if anything looks wrong…[/quote]

Well, the first thing I noticed losing sync was the trippers because I’m using the Smart Switch Plugin to turn on lights using the trippers. It seems like it’s all of my Wink devices that aren’t updating. I just logged into my Vera and noticed all my GE Link lights still show they’re on but they were turned off via a scene last night. To test this theory I watched the UI this morning when Smart Switch turned off my lights after the set time the lights never updated (the group device or individual lights) in Vera. If I refresh my browser, nothing changes, only performing a re-sync will the devices get the correct status.

Same thing with the Wink Relay, I only noticed it was gone because the lights weren’t turning on when it was triggered so I checked the Smart Switch plugin settings and noticed the Wink Relay had completely disappeared from my Vera.

So while v0.20.13 does fix the group issues after the first few minutes of doing a re-sync, everything eventually loses sync no matter what device type it is.

Try to capture the LuaUPnP log from when the smart switch plugin commands the lights off and continuing for at least five minutes… I suspect that it is an issue with notifications… When the subscription expires, the pubnub servers are supposed to send a notification, and the plugin renews the subscription… If the notification is not received, further status updates will not be received… I may need to rework the subscription mechanism to automatically do periodic renewals…

Try to capture the LuaUPnP log from when the smart switch plugin commands the lights off and continuing for at least five minutes… I suspect that it is an issue with notifications… When the subscription expires, the pubnub servers are supposed to send a notification, and the plugin renews the subscription… If the notification is not received, further status updates will not be received… I may need to rework the subscription mechanism to automatically do periodic renewals…[/quote]

Ok, smart switch turned on my Upstairs Hallway lights at 9:48am and turned them off at 9:56am. I see what looks like errors in updating the status, it states that it “Recieved update data for unconfigured group device” several times at the time the lights are turned off.

Newest log:

[quote=“dubbedout, post:9, topic:189845”]Ok, smart switch turned on my Upstairs Hallway lights at 9:48am and turned them off at 9:56am. I see what looks like errors in updating the status, it states that it “Recieved update data for unconfigured group device” several times at the time the lights are turned off.

Newest log:

I’ll have a look at the logs later today…

The “Recieved update data for unconfigured group device” can be caused by a number of issues:

  1. You have groups on your Wink account that have unsupported devices in them.
  2. You have groups on your Wink account that do not have any devices in them (Strangely, the Wink servers will still send occassional notifications for empty groups).
  3. You have groups on your Wink account but have not enabled Group support in the plugin.

This is not an error message, but a debugging message…

Ok… first… The plugin is crashing… BUT… it is because the Wink API server is not sending data for the group device… (this bug will be corrected in the next release)

As part of setting the state of the group device, The plugin sends the command, and because the Wink API does not return the state of the member devices in the command response, it retrieves the group device list which should contain the current status of the member devices… The response the plugin is receiving does not contain this information…

The reason that a reload (restart the LuaUPnP engine) or resync (erase the maintained device list and recreate it from scratch) will update the individual devices first, then update the main group device, then update the group members… the update routine used in the creation/initialization of devices is seperate from the routine used to process device changes/updates (and does not have the bug). The status of the group members is updated by the individual device status reported in the global device list.

I check the data returned for the scenes on my VeraEdge… There is no data returned by the Wink API for the individual member devices… So this is (ultimately) a Wink API issue, not a plugin issue… However, I should be able to program a workaround… which may take a little while…

Also… I do not see any subscription activity in the logs. I do not see why that is… Will need a restart log to see what is happening with the subscription mechanism… but lets get the group issue fixed first…

I just posted a new version in the “LATEST VERSION” thread.

During testing, I noticed several issues:

  1. The Wink API response to the get group list and device activation command, sometimes does not contain status data for the member devices.
  2. The PubNub notification server is sometimes sending a notification with new status data, then immediately sending a notification with old status data.
  3. The status of the member devices are sometimes not updated for several seconds after the physical state of the device changes.

I have worked around these issue and the new version will (hopefully) make the status displayed in the Vera UI much more accurate.

Give it a try and let me know the results…

[quote=“cybrmage, post:12, topic:189845”]I just posted a new version in the “LATEST VERSION” thread.

During testing, I noticed several issues:

  1. The Wink API response to the get group list and device activation command, sometimes does not contain status data for the member devices.
  2. The PubNub notification server is sometimes sending a notification with new status data, then immediately sending a notification with old status data.
  3. The status of the member devices are sometimes not updated for several seconds after the physical state of the device changes.

I have worked around these issue and the new version will (hopefully) make the status displayed in the Vera UI much more accurate.

Give it a try and let me know the results…[/quote]

Doesn’t look like the individual devices in the groups are updating, the group device itself is updating but not the single devices that are in the group. Also, my trippers aren’t registering their status either.

I opened the door of my back door tripper and saw nothing in the log, this was around 13:20. I had my Wink app opened at the time and they are updating with Wink.

When you activated the group, the processing of the response data resulted in the group device status updating, then the processing thread crashed… and the subscription of the device data was not renewed… and the plugin never received the update data for the member devices…

The tripper are actually reporting their status… and the plugin is correctly updating the status…

02	12/05/15 11:23:41.134	luup_log:16: (Wink_Connect::processDeviceState): Processing Device State update . <0x76b88520>
50	12/05/15 11:23:41.134	luup_log:16: (Wink_Connect::processDeviceState): deviceProcessed [FALSE]. <0x76b88520>
50	12/05/15 11:23:41.135	luup_log:16: (Wink_Connect::HUB_DEVICES::findVeraDeviceByWinkId): Searching for device with Wink ID [126520]. <0x76b88520>
50	12/05/15 11:23:41.136	luup_log:16: (Wink_Connect::HUB_DEVICES::findVeraDeviceByWinkId): found device [15]. <0x76b88520>
50	12/05/15 11:23:41.136	luup_log:16: (Wink_Connect::processDeviceState): updating sensor_pod Tripper device [15] vera [83] hub [204721] connected [TRUE]. <0x76b88520>
50	12/05/15 11:23:41.137	luup_log:16: (Wink_Connect::processDeviceState): updating sensor_pod Tripper device [83] name [Back Door Tripper] status [TRUE] hub [204721] connected [TRUE]. <0x76b88520>
50	12/05/15 11:23:41.137	luup_log:16: (Wink_Connect::setChildVariable) Device [83] SID [urn:micasaverde-com:serviceId:HaDevice1] variable [BatteryLevel] current [100] new [100]. <0x76b88520>
50	12/05/15 11:23:41.138	luup_log:16: (Wink_Connect::setChildVariable) Device [83] SID [urn:micasaverde-com:serviceId:SecuritySensor1] variable [Tripped] current [0] new [1]. <0x76b88520>
50	12/05/15 11:23:41.138	luup_log:16: (Wink_Connect::setChildVariable) Setting urn:micasaverde-com:serviceId:SecuritySensor1::Tripped [1]. <0x76b88520>
06	12/05/15 11:23:41.139	Device_Variable::m_szValue_set device: 83 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1449253862 now: 1449339821 #hooks: 0 upnp: 0 skip: 0 v:0x996c70/NONE duplicate:0 <0x76b88520>
06	12/05/15 11:23:41.154	Device_Variable::m_szValue_set device: 83 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 1 upnp: 0 skip: 0 v:0x996b38/NONE duplicate:0 <0x76b88520>

The SmartSwitch plugin is then responding to the status change…

02	12/05/15 11:23:41.155	luup_log:63: SmartSwitch INFO(sensorTripped@L_SmartSwitch_core.lua:578)) - Sensor tripped: sensorId = 83 (number) <0x76b88520>
02	12/05/15 11:23:41.156	luup_log:63: SmartSwitch INFO(setSwitchLevel@L_SmartSwitch_core.lua:172)) - Setting Switch Level: switchId = 6 (number), level = 0 (number) <0x76b88520>
06	12/05/15 11:23:41.157	Device_Variable::m_szValue_set device: 77 service: urn:hugheaves-com:serviceId:SmartSwitchController1 variable: Level was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0xb3a960/NONE duplicate:1 <0x76b88520>
08	12/05/15 11:23:41.157	JobHandler_LuaUPnP::HandleActionRequest device: 6 service: urn:upnp-org:serviceId:SwitchPower1 action: SetTarget <0x76b88520>
08	12/05/15 11:23:41.158	JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=0 <0x76b88520>
06	12/05/15 11:23:41.158	Device_Variable::m_szValue_set device: 6 service: urn:upnp-org:serviceId:SwitchPower1 variable: Target was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x986bf8/NONE duplicate:1 <0x76b88520>
06	12/05/15 11:23:41.160	Device_Variable::m_szValue_set device: 77 service: urn:hugheaves-com:serviceId:SmartSwitchController1 variable: Mode was: Off now: Auto #hooks: 0 upnp: 0 skip: 0 v:0xb39c78/NONE duplicate:0 <0x76b88520>
06	12/05/15 11:23:41.160	Device_Variable::m_szValue_set device: 77 service: urn:hugheaves-com:serviceId:SmartSwitchController1 variable: Timeout was: 2147483647 now: 2147483647 #hooks: 0 upnp: 0 skip: 0 v:0xb39f50/NONE duplicate:1 <0x76b88520>

The reason you are not seeing anything around 13:20 is that the plugin has not renewed the subscription to notifications (due to the crash) and never receives the status updates…

Attached is a quick update to correct the crash… (you only need to upload the L_Wink_Hub1.lua file to your Vera)…

Ok, so with this update I noticed trippers were updating fine, groups were being weird though. When I turn on the group lights manually in VeraUI it turns on all the individual lights but then the group device still shows off…then everything stops updating.

I walked through my house with my laptop and tested my trippers and they worked fine, as soon as I do anything with a group of lights it seems like the plugin crashes because nothing updates any longer.

Yep… still issues… Getting closer though…

Here is another incremental fix…

And… I think I found why your Wink Relay device has disappeared… I’m trying to figure out a solution…

Also… before you post the next set of logs ( if needed 8-} )… unless you ABSOLUTELY, POSITIVELY need to have your Vera doing verbose logging, could you turn it off (uncheck Settings/Logs/Verbose logging)… The plugin debug mode is all that is needed, and the extensive system logging make it much more difficult to sort through the logs.

Ok, my last reply must’ve not gone through so here it is again.

After monitoring the Wink connect plugin over the past few weeks, everything seems to be working correctly! One weird thing though, my Relay re-appeared the other morning! I received a push notification stating that my Wink Relay sensed motion and I was very surprised, but there it was. Not sure if Wink changed something on their end, or you somehow fixed it from your end…but it works!

The issue you had with the Wink Relay was that the API servers was that the API servers were not returning data for it’s sensor pod… No sensor pod equals no relay device…

I assume that it was a glitch in the API servers that they have since fixed, as the API servers were returning sensor pod data for you Ring Video Doorbell.

The issue you had with the Wink Relay was that the API servers was that the API servers were not returning data for it’s sensor pod… No sensor pod equals no relay device…

I assume that it was a glitch in the API servers that they have since fixed, as the API servers were returning sensor pod data for you Ring Video Doorbell.[/quote]
Ooh, does that mean we could possibly use the motion sensor in the Ring Doorbell in Vera? That’d be awesome!

Actually… when I saw that the doorbell was included in the Wink API data, I added a device entry into the plugin… I have not yet added the code to create a device or process the status…

So… Yes… It is possible…

As I do not have a Ring Doorbell, a brief description of what it adds to the the Wink app would be of help.

From the Api data, It looks like it will report motion (so we would add a motion sensor device) and button presses (so we would add a scene controller)…

The device status also appears in the sensor pod data… So I’m not sure if the status data would be retrieved from the device or from the sensor_pod or can be retrieved from both…

If your willing to do the testing (and provide logs)… I’m willing to make the additions.