That is the same issue that I (thought I had) fixed… Obviously… still issues…
Try uploading the attached version to your Vera… It does not try to refresh state login tokens… It will obtain new tokens instead…
Were you still getting it with 0.13??
That is the same issue that I (thought I had) fixed… Obviously… still issues…
Try uploading the attached version to your Vera… It does not try to refresh state login tokens… It will obtain new tokens instead…[/quote]
Sorry, but I can’t see any attachment…
Sorry… It’s one of those days… it’s attached now…
Sorry… It’s one of those days… it’s attached now…[/quote]
Installed the new .lua. Here is what I get:
Status:Logged In
Plugin Version:0.13b8 Wink
When I click ReSync I get: Device Not Ready
I did manage to figure out how to look at the log file. I copied this section:
01 01/28/15 23:03:26.923 LuaInterface::CallFunction_Startup‐1 device 15 function Wink_Hub_Startup failed [string “‐‐ Wink_Hub…”]:2727: attempt to concatenate 01 01/28/15 23:03:26.924 LuImplementation::StartLua running startup code for 15 I_Wink_Hub1.xml failed <0x2b633680>
I don’t know if that helps any… Like I said, I really have no clue what I am doing.
wink version 0.55
Vera UI5
Plugin Version:0.13b8
So… I did a minor rework of the login/refresh/resync process… and hardened the device parsing process… Hopefully, no more crashing with unsupported devices…
Attached is a test version to try out, before an update to the version in the App Marketplace…
Do you have a list of what you are calling unsupported devices?
An unsupported device would be any device that does not report as a binary switch, light bulb, thermostat, lock or garage door (MYQ only and UI5 only) in the device list provided by the Wink API server.
Most of the failures that have been reported appear to be caused by what are referred to as “linked services”, such as the philips hue or nest thermostats or MYQ garage controllers… The data provided for these services was different from the devices that are locally connected to the Wink Hub, and that was causing the processing routines to fail. I have hardened the processing routine so that this non-conformant data should not cause a failure, and the devices will be ignored…
Also, currently, the Philips Hue/Lux/Bloom/Iris lights are ignored (on purpose), because the Wink API does not allow control of these devices. The Wink App allows control of the Philips products only when it is connected to the local network and can send commands directly to the Hue Hub.
MYQ devices are only supported when running UI5, until I can determine why they can not be controlled under UI7.
zolakk provided me with the device data for the nest thermostats, and I used this data to help figure out better ways to determine unique devices, so they should be supported as a thermostat-like device (Thermostat-like because the native thermostat device files embed Z-Wave device controls with cause problems with non Z-Wave devices… As a bonus, the “Wink Thermostat” device files included with the plugin actually display the current temperature)…
Other devices, such as motion sensors, door sensors, spotters, porkfolio, propane tanks, air conditioners, etc are unsupported, as I do not have any of these devices and do not have any sample data from them… They could be supported, if someone with one of these devices provides the device data (output to the LuaUPnP log when debug mode is turned on)… So far, the only data I have received is from the “Nest Thermostat”… SO… I know some of you have these devices… Don’t be shy!!! Post the device data!!!
I’d be happy to try and help you get the Tripper working and get a Tripper in your hot little hands. Tell me what you need from me and some steps or point me to a how-to.
I don’t know what you did, but that last version of L_Wink_Hub1.lua fixed my problem! I can now see my two lamps in the Vera UI5 interface. Thank you!!!
I am pretty new to both the vera and wink … if you can point me to how to get the log like zolakk for the nest, I can get you the log for the propane tank, philips hue and the TCP connected bulbs. I was poking around a little but can’t find log like zolakk provided. Was that log from Vera or WinK?
Search the app store for the InfoViewer plugin. It has links to lots of logs and Vera statuses.
All I need is the device parsing output from the LuaUPnP.log… Hints are listed below… Thanks.
I’m glad it’s (finally) working for you
I used the logs provided by zolakk and the local_api.php on my rooted wink hub to create a dummy device so that I could improve the device parsing routines. Oh, and I fixed a bug in the OAUTH2 token handling routines.
Here is a post I made in another thread that could be of help with logging:
- Use Putty, or another SSH client to log into your Vera… issue “tail -f /var/log/cmh/LuaUPnP.log” command… copy the output into a forum reply.
- Use the Vera UI… In a browser, go to "http://(your Vera IP Address)/cgi-bin/cmh/log.sh?Device=LuaUPnP (This is NOT a good method!)
- Install the InfoViewer plugin… It has amazing log capture powers… (instructions here → [url=http://forum.micasaverde.com/index.php/topic,13477.msg100381.html#msg100381]http://forum.micasaverde.com/index.php/topic,13477.msg100381.html#msg100381[/url] latest version here → [url=http://forum.micasaverde.com/index.php/topic,13477.msg199289.html#msg199289]http://forum.micasaverde.com/index.php/topic,13477.msg199289.html#msg199289[/url])
See the WIKI [url=http://wiki.micasaverde.com/index.php/Logs]http://wiki.micasaverde.com/index.php/Logs[/url] for details on logging.[/quote]
The Philips Hue is explicitly unsupported… The Wink API does not support control of the bulbs… (and I have hue lights, so don’t need the logs).
The Connected By TCPi lights should already work with the last version, as they report as light bulbs (and I have TCPi lights, but they are still in a moving box, so can’t physically test)…
The propane tank sounds like a neat little device… Please provide the log data if you can…
The log is from the Vera… The Wink Hub does no usable logging (it logs cryptic internal action messages of actions performed by the control processes) and the logs are only accessible on rooted hubs…
The log on Vera that we are interested in is “/var/log/cmh/LuaUPnP.log”. The infoViewer plugin is probably the easiest (yet, I still haven’t found time to try it 8-{ )
UPDATE: Ok… I tried the InfoViewer plugin… and it IS awesome!!!.. Makes getting the logs SIMPLE!!
Install the InfoViewer plugin by following the instructions, the go to the InfoViewer setup page… Click on the “info viewer page” link… Click on “View logs: Vera log file” and you get a webpage with the LuaUPnP.log file… Click on thelight bulb to pause the log and then you can scroll through the log and select/copy the section of the log you want to post…
Awesome!! just freakin’ awesome!!!
Great plugin!
I can provide more but I got this (see attached)
[quote=“FOCGreeN, post:94, topic:185289”]Great plugin!
I can provide more but I got this (see attached)[/quote]
I appreciate the effort… BUT… You need to turn on debug mode in the plugin 8-}
With debug mode turned off, the plugin only provides basic startup and operational information… With debug mode turned on, it provides much more detailed information on all of its operations and the data it sends and receives… From the logs you provided, all I can tell is that the plugin is installed, has created two dimmable light devices and has not crashed.
To get the information needed for adding device support, turn on debug mode and wait for the plugin to fetch the device list (at least the time you have set for the Poll interval)… Once the plugin has received the device list from the Wink Server API, then you can turn off debug mode and grab the log…
[quote=“cybrmage, post:95, topic:185289”]I appreciate the effort… BUT… You need to turn on debug mode in the plugin 8-}
With debug mode turned off, the plugin only provides basic startup and operational information… With debug mode turned on, it provides much more detailed information on all of its operations and the data it sends and receives… From the logs you provided, all I can tell is that the plugin is installed, has created two dimmable light devices and has not crashed.
To get the information needed for adding device support, turn on debug mode and wait for the plugin to fetch the device list (at least the time you have set for the Poll interval)… Once the plugin has received the device list from the Wink Server API, then you can turn off debug mode and grab the log…[/quote]
This better? I saw the two sensors in this output.
Now that the plugin is running and I can see my lights, I have noticed that whenever I turn a light off the plugin immediately (within the next polling period) turns them on. It does not matter if I turn them on via the Wink app or thru Vera - when the Wink Hub is polled again they are turned back on. I have attached a portion of the log that I think may show this. Help?
The log you provided shows the data received from the Wink API Server…
model_name: GE light bulb
desired_state: [
brightness: 0
powered: FALSE
]
last_reading: [
desired_powered: FALSE
desired_brightness: 0
powered: TRUE
brightness: 1
]So… It is saying that the last command it received was to set the power to off and the brightness to 0… And the state of the bulb is powered on and brightness 1… So either there is a problem with the Wink API server interpreting the command or the bulb interreting the command from the hub…
The only time the plugin sends commands to the hub is when you trigger a state change (click the on/off button, change the brightness slider - either manually or through a scene… All the PollWinkdevices routine does is read the device data from the Wink API server and update the Vera device states to reflect that data…
So… Does the light get physically turned back on or just the icon in Vera???
Testing on my Wink Hub with a GE Link BR30 bulb… shows the off command being sent… the wink hub responding with the command being received but the bulb still on… the bulb physically turning off… the poll showing off command received and bulb still on (although the light is physically off)… the second poll showing off command received and bulb off…
Unless your light is physically turning back on, I believe this is an anomaly caused by the Wink API servers not updating the device status properly…
Seemingly unrelated question… What thermostat do you have… The log shows that a refresh command (which asks the Wink API server to refresh the information it has for a device from the Wink Hub) get a “500 Internal Server Error” from the Wink API server… I don’t see this for my thermostat…
Not quite what I was hoping for (my faults… the unknown devices aren’t logged in detail in the pollWinkDevices routine)… BUT… you have few enough devices that I got what is needed (the log truncated the raw data)…
Working on support now…
The log you provided shows the data received from the Wink API Server…
model_name: GE light bulb
desired_state: [
brightness: 0
powered: FALSE
]
last_reading: [
desired_powered: FALSE
desired_brightness: 0
powered: TRUE
brightness: 1
]So… It is saying that the last command it received was to set the power to off and the brightness to 0… And the state of the bulb is powered on and brightness 1… So either there is a problem with the Wink API server interpreting the command or the bulb interreting the command from the hub…
The only time the plugin sends commands to the hub is when you trigger a state change (click the on/off button, change the brightness slider - either manually or through a scene… All the PollWinkdevices routine does is read the device data from the Wink API server and update the Vera device states to reflect that data…
So… Does the light get physically turned back on or just the icon in Vera???
Testing on my Wink Hub with a GE Link BR30 bulb… shows the off command being sent… the wink hub responding with the command being received but the bulb still on… the bulb physically turning off… the poll showing off command received and bulb still on (although the light is physically off)… the second poll showing off command received and bulb off…
Unless your light is physically turning back on, I believe this is an anomaly caused by the Wink API servers not updating the device status properly…
Seemingly unrelated question… What thermostat do you have… The log shows that a refresh command (which asks the Wink API server to refresh the information it has for a device from the Wink Hub) get a “500 Internal Server Error” from the Wink API server… I don’t see this for my thermostat…[/quote]
The lights actually turn back on…
Before the Vera plugin was installed, the Lights operated fine via the Wink app, so I don’t think that it is an issue of the bulbs interpreting the Wink commands correctly.
Thermostat is Honeywell model number TH9320WF5003