sorry debug was off, here it is again.
I looked at both logs… They are two different types of crashes… and both occurred at different points in the plugins startup sequence… So… very puzzling…
Is there anything else you have installed/added/changed recently??
Try this… Go into the Wink Hub settings… go to Advanced… Click on the checkbox for “disabled” and then save the changes… the monitor the log and see if the Vera is still in the crash loop… (with the disabled flag set, the plugin will start and almost immediately exit)
What does the Wink Hub device display on the dashboard??? You’re on UI6, and I haven’t programmed any json specifically for UI6… It may be a crash loop caused by incompatible json in the device files…
When I disable the plugin there is no crash. Re-enable and it starts the crash loop again. 
I took another log file to see if you see anything different. Do you think its a Vera problem, or Wink? I actually tried to default the wink hub today, but it seems the account retains the HUE information because it comes back! I could try defaulting it and creating a new wink account if you think that will help!
I have stayed away from the UI7 firmware as I tried it when it first came out and nothing much worked? Do you think upgrading would fix? I found so many plugins didn’t work before.
Anyway, really hope to get this working — Wink is the outcast in my system right now!!!
Thanks
Bill
The Hue devices being still visible then disappearing is normal… The devices were created by the earlier version of the plugin… the new version excludes them, and they are orphaned and marked for deletion by the system… the LuaUPnP engine then restarts (multiple times) and deletes them…
The same thing happens when you add devices to the Wink Hub… The new devices are detected when you do a resync… they are discovered and added as new Vera devices… and the LuaUPnP engine restarts (multiple times) to configure the new devices… Not every LuaUPnP crash is a LuaUPnP CRASH…
From what I can tell, there were changes system between UI5 and UI6, and more changes between UI6 on UI7… It looks like the crash loop you are experiencing may be related to the similar issue experienced with UI7 when it first came out, which was due to the UI5 json forcing a UI7 restart…
When I started making plugins, it was after UI6 was released and UI7 started beta… With all the issue with UI6 and UI7 being targeted for general release, I choose to forgo UI6… So… I don’t have a Vera system with UI6, and have no way to make and test changes targeted at UI6… The most I can do is to add a variable to let you force UI5 or UI7 mode for you to test to see if either will work for you - see the bottom of this post for instructions…
I have the latest UI7 on my VeraEdge development system and find that it is quite usable… Most of the major plugins have been updated to work with UI7 (Vista alarm panels, DSC alarm panels, TCP lighting plugin, Hue lighting plugin, MYQ plugin, PLEG, etc - there is a huge list in one of the forums)
The lua file attached implements the variable to force UI5 or UI7 mode…
First, go into the Wink Hub device, go to the advanced page and add a new variable with the following parameters:
New Service: urn:micasaverde-com:serviceId:Wink_Hub1
New Variable: UI6mode
New value: (either “UI5” or “UI7”, depending on which mode you wish to test)
then go to apps/develop apps/luup files, and upload the attached file to your Vera… Once it has uploaded the LuaUPnP engine will restart… once it has finished restarting, force it to restart again… then watch the logs to see what is happening…
Well… yes and no.
The Wink Hub can connect to and control Z-Wave, Zigbee, Casetta and Kidde devices and to devices linked to your Wink account. If you plan on using any Casetta devices (in-wall dimmer/switch, plug-in dimmer/switch, Pico remote) or Kidde smoke/CO detectors, you need the Wink Hub.
The Wink Relay combines a (cut down) Wink Hub and a touchscreen. It can connect to Zigbee devices control devices connected to your Wink account. If you only plan on using Zigbee devices (Cree bulbs, GE Link bulbs, Zigbee sensors (IE: Quirky Tripper), etc) then you do not need the Wink Hub.
The Plugin connects to the Wink servers and makes the devices that are attached to your Wink Account (including devices attached to the Wink Hub and the Wink Relay) available to Vera for control and monitoring… It does NOT make Vera devices controllable by the Wink Hub or the Wink Relay.
There is currently no way to make “phantom” devices in the Wink account that would allow a virtual link to Vera devices to allow control of Vera devices by the Wink Relay. You can, however, configure your Vera to respond to the “Smart Buttons” on the Wink Hub, so you could trigger a scene on the Vera by pressing the Smart Button on the Wink Relay.
You could also configure the Wink Hub so that it is a secondary Z-Wave controller with your Vera as the master… The Z-Wave devices on the Vera should appear on the Wink Hub and be controllable with the Wink Relay… But, the Vera will then have two devices for every Z-Wave device attached to it (The native Z-Wave device, and the Z-Wave device that appears is created by the plugin)… NOTE I have not yet tried or tested this configuration… The Z-Wave device support on the Wink Hub is extremely limited, and it may not be able to control or monitor many of the common Z-Wave devices that Vera does support.
So, your Vera can see and control all your devices… The Wink Relay can only see and control the Wink devices…
Yes, the Wink Relay connects through the Wink API, and the Plugin receives notifications of device status changes from the Wink API… But, instant update it is not… When you change the state of a device connected to the Wink Hub/Wink Relay, there is still a delay… I have a GE Link bulb connected to my Wink Hub and when it is controlled with the Wink Relay, there is a two second delay from command to action… As soon as the Wink API server processes the command, the device state notification is triggered, so as soon as the bulb switches on, the Vera is notified and the state of the bulb is reflected in Vera almost immediately.
The design IS nice… Unfortuantely, the Wink Relay is a rather mediocre device… I find that the touchscreen is a bit insensitive and the UI is sometimes counter-intuitive. The build quality is good, but the device does not sit completely flush with the wall (The manual says that this is normal) and the entire device moves slightly when touched… It also REQUIRES a neutral wire, so make sure that the location you wish to place it has a neutral.
It has two switches built in, so it can be used in a 2-gang wall box and will control both circuits, but if one of the circuits is a dimmer, you will lose the dimming function. If the box is a 3-gang or 4-gang box, you will not be able to use the Wink Relay - even when installed to the left or right position on the power box (of the left, center or right positions) the device overhangs the adjacent device footprint, and even though it does not sit flush, it does not leave enough space for a coverplate to be installed on the adjacent device.
On the plus side, it is nice to have the display showing time and weather conditions… but at $330(Canadian)… it a very expensive toy. If it was less expensive (maybe $150) I would probably get a few more… but, as it is, I can’t justify the expense.
I have published a new version (v0.16) to the App Marketplace… It incorporates all the previous bugfixes and new device support… and a few minor tweaks to better handle devices that have been hidden or deleted in the Wink account.
I sweared that I got the 15b153 worked before. Today I update to .016 and got stuck like other at the configuring device … no matter how many time I reloads and refresh browser … even reboot vera… I do had Hue connected but removed them from Wink a few months back.
Now I put .15b153 back and no longer work. It stucks at configuring devices. I updated backward 1 build at a time from b153 and the last version that worked for me now is 0.15b75. I am clueless how I got the 0.15b153 work the last time… I poked around so much and no idea what I did that made it works.
I’ve recently installed my VeraEdge and today received a WinkHub and the plugin is working as expected, delays due to no local API (I updated my Wink when the app said I had to, not realizing I’d lose the ability to root…DUH). Anyways, my question…Is there anyway to group the GE Link bulbs? I’m able to control them individually but would like to group lights together. Thanks for this plugin!
[quote=“bigmonkey70, post:207, topic:185289”]I sweared that I got the 15b153 worked before. Today I update to .016 and got stuck like other at the configuring device … no matter how many time I reloads and refresh browser … even reboot vera… I do had Hue connected but removed them from Wink a few months back.
Now I put .15b153 back and no longer work. It stucks at configuring devices. I updated backward 1 build at a time from b153 and the last version that worked for me now is 0.15b75. I am clueless how I got the 0.15b153 work the last time… I poked around so much and no idea what I did that made it works.[/quote]
It was working, on both UI5 and UI7, before I published v0.16 to the App Marketplace…
I retested on UI5 and UI7 from a clean install… and UI5 work, UI7 doesn’t… It is getting stuck on the initial subscription request to Pubnub… Something has changed… but I can’t tell for sure what it is… It looks like it may be a difference in how UI5 and UI7 handle timeouts on the IO thread…
Version 0.15b75 is the last version that does not use the Pubnub subscription notification method… that’s why it still works…
So, I have rewritten the subscription request function so that it does not depend on the timeout…
The attached update should fix the problem…
Groups are not yet supported… it is on my to-do list…
Groups are not yet supported... it is on my to-do list...
Ok cool. I went ahead and purchased another Wink hub so I could root it and try out the local api, hoping the delay is decreased when issuing commands. I’m pretty sure I setup the Wink for the local api use because it detects my Link bulb, but when issuing commands nothing happens. Here’s my Vera log of what I believe is the command I just sent. I left the name of the bulb alone, just as what the plugin imported into Vera.
02 03/06/15 0:56:20.849 e[33;1mluup_log:20: (Wink_Hub::HUB_DEVICES::getDeviceListLocal): Received http response [200] [HTTP/1.1 200 OK] [{"data":[{"hub_id":"192.168.5.189","name":"hub","hub_ip":"192.168.5.189","hub_mac":"34:23:ba:f0:45:b2\n","update_needed":false,"last_reading":{"firmware_version":"00.56","hub_version":"00.01","ip_address":"192.168.5.189","mac_address":"34:23:ba:f0:45:b2","connection":true,"update_needed":false}},{"light_bulb_id":"8999639012789769659","name":"","device_manufacturer":"ZIGBEE","model_name":"New HA Dimmable Light","hub_id":"192.168.5.189","local_id":"1","radio_type":"ZIGBEE","desired_state":{"powered":"TRUE","brightness":1},"last_reading":{"connection":true,"powered":"TRUE","brightness":1}}]}].e[0m <0x77a9f000> 50 03/06/15 0:56:20.863 luup_log:20: (Wink_Hub::HUB_DEVICES::getDeviceListLocal): HTTP status code = 200. <0x77a9f000> 02 03/06/15 0:56:20.867 e[33;1mluup_log:20: (Wink_Hub::HUB_DEVICES::getDeviceListLocal): Completed. Returning device status data.e[0m <0x77a9f000> 50 03/06/15 0:56:20.868 luup_log:20: (Wink_Hub::pollWinkDevices): Retrieved Wink Hub device list. <0x77a9f000> 02 03/06/15 0:56:20.868 e[33;1mluup_log:20: (Wink_Hub::processDeviceState): Processing Device State update .e[0m <0x77a9f000> 02 03/06/15 0:56:20.868 e[33;1mluup_log:20: (Wink_Hub::processHubState): Processing Hub State update .e[0m <0x77a9f000> 02 03/06/15 0:56:20.868 e[33;1mluup_log:20: (Wink_Hub::processDeviceState): Processing Device State update .e[0m <0x77a9f000> 50 03/06/15 0:56:20.869 luup_log:20: (Wink_Hub::HUB_DEVICES::findVeraDeviceByWinkId): Searching for device with Wink ID [8999639012789769659]. <0x77a9f000> 50 03/06/15 0:56:20.869 luup_log:20: (Wink_Hub::HUB_DEVICES::findVeraDeviceByWinkId): found device [1]. <0x77a9f000> 50 03/06/15 0:56:20.870 luup_log:20: (Wink_Hub::processDeviceState): updating light_bulb device [1] data [hub_id: 192.168.5.189 radio_type: ZIGBEE device_manufacturer: ZIGBEE light_bulb_id: 8999639012789769659 name: last_reading: [ connection: TRUE powered: TRUE brightness: 1 ] desired_state: [ brightness: 1 powered: TRUE ] local_id: 1 model_name: New HA Dimmable Light ]. <0x77a9f000> 50 03/06/15 0:56:20.870 luup_log:20: (Wink_Hub::processDeviceState): updating light_bulb device [1] vera [30] hub [192.168.5.189] connected [TRUE]. <0x77a9f000> 50 03/06/15 0:56:20.871 luup_log:20: (Wink_Hub::processDeviceState): updating light_bulb dimmer device [30] name [_Dimmable Light] target [100] status [100] hub [192.168.5.189] connected [TRUE]. <0x77a9f000> 50 03/06/15 0:56:20.871 luup_log:20: (Wink_Hub::setChildVariable) Device [30] SID [urn:upnp-org:serviceId:Dimming1] variable [LoadLevelTarget] current [100] new [100]. <0x77a9f000> 50 03/06/15 0:56:20.871 luup_log:20: (Wink_Hub::setChildVariable) Device [30] SID [urn:upnp-org:serviceId:Dimming1] variable [LoadLevelStatus] current [100] new [100]. <0x77a9f000> 50 03/06/15 0:56:20.872 luup_log:20: (Wink_Hub::updateDeviceName): raw name in Vera [_Dimmable Light] name in hub []. <0x77a9f000> 50 03/06/15 0:56:20.872 luup_log:20: (Wink_Hub::updateDeviceName): Unable to update Vera name: current_name [_Dimmable Light] new name []. <0x77a9f000> 02 03/06/15 0:56:20.872 e[33;1mluup_log:20: (Wink_Hub::processDeviceState): Completed processing device state update.e[0m <0x77a9f000> 02 03/06/15 0:56:20.872 e[33;1mluup_log:20: (Wink_Hub::pollWinkDevices) Completed Wink Hub device poll job.e[0m <0x77a9f000>
I’m clicking the off button in the Vera WebUI, and looking at the logs it looks like it’s telling the Wink hub to change the bulb from 100 to 100, which I’m assuming is why the light isn’t turning off. I’ve also tried using the slider to change the brightness from 100 to 0 with the same results.
With all the updates for non-local devices, and the implimentation of the Pubnub notifications, the local API script has become out-of-sync with the plugin… As you appear to be the only person (other than myself) that uses the local api, it has seems to have been relegated to development purposes…
The section of log you posted is actually part of the device poll process, not the command processing… but it does verify that the rooted hub is set up correctly (The getDeviceListLocal function is only used when communicating with the Wink Hub using the local API)…
Attached is an updated local_api.php script… Please note - with all the changes to the plugin, a resync is no longer sufficient when changing from “REMOTE” to “LOCAL”… You must reload the LuaUPNP engine…
With all the updates for non-local devices, and the implimentation of the Pubnub notifications, the local API script has become out-of-sync with the plugin... As you appear to be the only person (other than myself) that uses the local api, it has seems to have been relegated to development purposes...The section of log you posted is actually part of the device poll process, not the command processing… but it does verify that the rooted hub is set up correctly (The getDeviceListLocal function is only used when communicating with the Wink Hub using the local API)…
Attached is an updated local_api.php script… Please note - with all the changes to the plugin, a resync is no longer sufficient when changing from “REMOTE” to “LOCAL”… You must reload the LuaUPNP engine…
After updating the local_api.php on the Wink hub everything is working. MUCH faster than the remote API! Only thing is, in the Vera webUI I get an error when saving any changes to the bulbs. For example, when I change the default name to something else Vera reports that the changes were successful, then I get an error at the top of the page saying “Wink_Hub : WINK HUB DEVICE UPDATE ERROR: Device could not be updated…” The new name stays in the Vera webUI for a few minutes and then they’ve all reverted back to “New HA Dimmable Light”. Not sure what’s going on there.
I have a 2nh wink hub thats rooted. I can help test, but I have no idea how to add deceives too it.
I used this post to root it Abdul Rahuman's blog: How to root your WINK hub - Step by Step tutorial
I ran into problems attempting the root this way [url=http://www.dinnovative.com/?p=348]Daniels’Innovative
Anyway, long story short… I have a rooted wink I cant seem to add device to (From the GUI). Is there a way to do this?
[quote=“bazzly, post:214, topic:185289”]I have a 2nh wink hub thats rooted. I can help test, but I have no idea how to add deceives too it.
I used this post to root it Abdul Rahuman's blog: How to root your WINK hub - Step by Step tutorial
I ran into problems attempting the root this way [url=http://www.dinnovative.com/?p=348]Daniels’Innovative
Anyway, long story short… I have a rooted wink I cant seem to add device to (From the GUI). Is there a way to do this?[/quote]
You can’t add devices to the Wink from the app? I know when I rooted mine I had to go through manually updating it to 0.56 to keep root. Without updating the Wink app wouldn’t let me add any devices until it was updated. With this plugin, you still add the devices to the Wink hub using the app and then they automatically populate into the Vera hub.
I followed this guide to update and keep root: http://www.rootwink.com/viewtopic.php?f=6&t=4
Hmm… Thanks, I’ll have to give that a go when I have a moment. Looks like I’ll have to see if I can undo what I did, and try those instructions.
Thanks
Keeping my fingers crossed!!
I have a rooted Wink as well running 0.56 with blink app. I ssh into it and copied the latest local_api to var/www … When change to local I got message no usable wink api found … Did I copied to the correct location?
[quote=“bazzly, post:216, topic:185289”]Hmm… Thanks, I’ll have to give that a go when I have a moment. Looks like I’ll have to see if I can undo what I did, and try those instructions.
Thanks
Keeping my fingers crossed!![/quote]
You shouldn’t have to “undo” anything… just follow the instructions at the rootwink.com site and you should be fine… When adding the lines to the /etc/hosts file, leave out the “hub-api.winkapp.com” line - so that the hub can communicate with the API server…
Did you rename the “local_api.php.txt” file to “local_api.php” on the Wink Hub… the “no usable local hubs” message means that the Wink Hub was found, but there was no response from the “local_api.php” script…
As previously mentioned… the local api script is not yet fully updated to the latest version of the plugin (just some quick changes to regain basic functionality)… The “name” logic had to be heavily modified for the Wink API… I have not yet updated the local api to mimic the Wink API for name changes… It’s on the to-do list…
I have just published a new version (v0.17) of the plugin… This version fixes subscription process in the last published version…
It also add the option to support Wink API Groups, exclusion of individual devices that are included in one or more groups and exclusion of Z-Eave devices attached to the Wink Account (So that you can eliminate duplicate devices if your Wink Hub is a secondary controller to your Vera).
It is attached to the first post in the thread, and is pending approval in the App Marketplace.
As previously mentioned... the local api script is not yet fully updated to the latest version of the plugin (just some quick changes to regain basic functionality)... The "name" logic had to be heavily modified for the Wink API... I have not yet updated the local api to mimic the Wink API for name changes... It's on the to-do list...Sounds good. I went ahead and renamed all my devices using the aprontest command manually. Thanks again for all your work on this plugin.