Oops… passing the dial_config as an array is mangled by the luup engine…
So… I have had to change the way the dial parameters are passed…
The updated parameters and example are HERE
[ATTACHMENT SUPERCEDED]
Oops… passing the dial_config as an array is mangled by the luup engine…
So… I have had to change the way the dial parameters are passed…
The updated parameters and example are HERE[/quote]
Still no effect. Changes in Version 19dev13 looks to have broken the existing functionality. My existing scene that sets the Garage Status stopped working. When I reverted back to version 19dev12 it worked once again.
Here is the Lua I used:
local Wink_Connect_Device_ID = 142
local Nimbus_ID = 13997
local Dial_Index = 3 – can be 0, 1, 2 or 3
local Action_Parameters = {
[“cloud_clock_id”] = Nimbus_ID, – this parameter is REQUIRED
[“dial_index”] = Dial_Index, – this parameter is REQUIRED
[“Label1”] = “test1”, – this parameter is REQUIRED
[“Label2”] = “test2”, – this parameter is OPTIONAL
[“dial_rotation”] = “cw”,
[“dial_scale_type”] = “linear”,
[“dial_min_value”] = 0,
[“dial_max_value”] = 100,
[“dial_min_position”] = 0,
[“dial_max_position”] = 360,
[“dial_num_ticks”] = 12,
[“value”] = 50, – this parameter is OPTIONAL
[“position”] = 180, – this parameter is OPTIONAL
[“brightness”] = 55 – this parameter is OPTIONAL
}
luup.call_action(“urn:micasaverde-com:serviceId:Wink_Hub1”,“UpdateNimbusDial”,Action_Parameters,Wink_Connect_Device_ID)
Here is the latest log:
08 08/28/15 23:28:37.457 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunScene <0x31119680>
08 08/28/15 23:28:37.457 JobHandler_LuaUPnP::HandleActionRequest argument SceneNum=146 <0x31119680>
08 08/28/15 23:28:37.457 Scene::RunScene running 146 Nimbus Test <0x31119680>
08 08/28/15 23:28:37.459 JobHandler_LuaUPnP::HandleActionRequest device: 142 service: urn:micasaverde-com:serviceId:Wink_Hub1 action: UpdateNimbusDial <0x31119680>
08 08/28/15 23:28:37.459 JobHandler_LuaUPnP::HandleActionRequest argument dial_min_value=0 <0x31119680>
08 08/28/15 23:28:37.459 JobHandler_LuaUPnP::HandleActionRequest argument dial_index=3 <0x31119680>
08 08/28/15 23:28:37.460 JobHandler_LuaUPnP::HandleActionRequest argument brightness=55 <0x31119680>
08 08/28/15 23:28:37.460 JobHandler_LuaUPnP::HandleActionRequest argument dial_min_position=0 <0x31119680>
08 08/28/15 23:28:37.460 JobHandler_LuaUPnP::HandleActionRequest argument value=50 <0x31119680>
08 08/28/15 23:28:37.460 JobHandler_LuaUPnP::HandleActionRequest argument dial_rotation=cw <0x31119680>
08 08/28/15 23:28:37.460 JobHandler_LuaUPnP::HandleActionRequest argument dial_num_ticks=12 <0x31119680>
08 08/28/15 23:28:37.461 JobHandler_LuaUPnP::HandleActionRequest argument dial_scale_type=linear <0x31119680>
08 08/28/15 23:28:37.461 JobHandler_LuaUPnP::HandleActionRequest argument Label2=test2 <0x31119680>
08 08/28/15 23:28:37.461 JobHandler_LuaUPnP::HandleActionRequest argument position=180 <0x31119680>
08 08/28/15 23:28:37.461 JobHandler_LuaUPnP::HandleActionRequest argument Label1=test1 <0x31119680>
08 08/28/15 23:28:37.461 JobHandler_LuaUPnP::HandleActionRequest argument dial_max_position=360 <0x31119680>
08 08/28/15 23:28:37.462 JobHandler_LuaUPnP::HandleActionRequest argument cloud_clock_id=13997 <0x31119680>
08 08/28/15 23:28:37.462 JobHandler_LuaUPnP::HandleActionRequest argument dial_max_value=100 <0x31119680>
01 08/28/15 23:28:38.665 lu_io_connected 0x16ff160 args 0 0xbfabe8 <0x2f919680>
06 08/28/15 23:28:39.384 Device_Variable::m_szValue_set device: 41 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: KWH was: 54.7270 now: 54.7270 #hooks: 0 upnp: 0 v:0xc33278/NONE duplicate:1 <0x2bae3680>
06 08/28/15 23:28:39.385 Device_Variable::m_szValue_set device: 41 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: KWHReading was: 1440829659 now: 1440829719 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2bae3680>
02 08/28/15 23:28:42.104 ZW_Send_Data node 9 NO ROUTE (nil) <0x2bee3680>
04 08/28/15 23:28:42.255 <0x2bae3680>
Your log excerpt shows the action being fired, but does not show the plugin actions…
Did you disable debug mode?
Please enable debug mode, run the test scene, and post the log showing the event processing and the response from the Wink API server…
Here is the output:
model_name: Nimbus
name: Nimbus
location:
locale: en_us
cloud_clock_id: 13997
cloud_clock_triggers: [
]
] cmd [{"channel_configuration":{"channel_id":10},"dial_configuration":{"rotation":"linear","max_position":360,"min_value":0,"min_position":0,"scale_type":"linear","max_value":100,"num_ticks":12},"labels":["test1","test2"],"dial_id":"56437","dial_index":3,"value":50,"position":180,"brightness":55}]. <0x30a72680>
02 08/28/15 23:54:16.371 luup_log:142: (Wink_Connect::HUB_DEVICES::updateDevice): REMOTE API URL [https://winkapi.quirky.com/dials/56437]. <0x30a72680>
02 08/28/15 23:54:16.371 luup_log:142: (Wink_Connect::HUB_DEVICES::updateDevice): Sending http request [PUT] [https://winkapi.quirky.com/dials/56437]. json [{"channel_configuration":{"channel_id":10},"dial_configuration":{"rotation":"linear","max_position":360,"min_value":0,"min_position":0,"scale_type":"linear","max_value":100,"num_ticks":12},"labels":["test1","test2"],"dial_id":"56437","dial_index":3,"value":50,"position":180,"brightness":55}] <0x30a72680>
08 08/28/15 23:54:16.769 JobHandler_LuaUPnP::HandleActionRequest device: 138 service: urn:futzle-com:serviceId:WeMo1 action: notifyBinaryState <0x31673680>
08 08/28/15 23:54:16.770 JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=138 <0x31673680>
08 08/28/15 23:54:16.770 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:futzle-com:serviceId:WeMo1 <0x31673680>
08 08/28/15 23:54:16.770 JobHandler_LuaUPnP::HandleActionRequest argument action=notifyBinaryState <0x31673680>
08 08/28/15 23:54:16.770 JobHandler_LuaUPnP::HandleActionRequest argument binaryState=0 <0x31673680>
08 08/28/15 23:54:16.771 JobHandler_LuaUPnP::HandleActionRequest argument sid=uuid:d521ff10-1dd1-11b2-965a-dae11ff4ee26 <0x31673680>
06 08/28/15 23:54:16.771 Device_Variable::m_szValue_set device: 138 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #hooks: 0 upnp: 0 v:0x11a7368/NONE duplicate:0 <0x31673680>
02 08/28/15 23:54:18.912 luup_log:142: (Wink_Connect::HUB_DEVICES::updateDevice): Received http response [422] [HTTP/1.1 422 Unprocessable Entity] [{"data":null,"errors":["Dial configuration Not a valid rotation: linear"],"pagination":{}}]. <0x30a72680>
50 08/28/15 23:54:18.913 luup_log:142: (Wink_Connect::task) WINK HUB DEVICE UPDATE ERROR: Device could not be updated.. <0x30a72680>Here are the errors that look important:
02 08/28/15 23:54:18.912 luup_log:142: (Wink_Connect::HUB_DEVICES::updateDevice): Received http response [422] [HTTP/1.1 422 Unprocessable Entity] [{“data”:null,“errors”:[“Dial configuration Not a valid rotation: linear”],“pagination”:{}}]. <0x30a72680>
50 08/28/15 23:54:18.913 luup_log:142: (Wink_Connect::task) WINK HUB DEVICE UPDATE ERROR: Device could not be updated… <0x30a72680>
And here is the fix (I hope)…
[*** ATTACHMENT MOVED TO FIRST POST ***]
And here is the fix (I hope)…[/quote]
Good news, that one worked! Way to stay persistent. I updated my original scenes and those are working as well. It points the Dial up when the garage is open and down when the garage is closed. Pretty sweet. Thanks!
Garage Open
local Wink_Connect_Device_ID = 142
local Nimbus_ID = 13997
local Dial_Index = 3 -- can be 0, 1, 2 or 3
local Action_Parameters = {
["cloud_clock_id"] = Nimbus_ID,
["dial_index"] = Dial_Index,
["Label1"] = "OPEN GARAGE",
["Label2"] = "GARAGE STATUS",
["dial_rotation"] = "cw",
["dial_scale_type"] = "linear",
["dial_min_value"] = 0,
["dial_max_value"] = 360,
["dial_min_position"] = 0,
["dial_max_position"] = 360,
["dial_num_ticks"] = 12,
["value"] = 1, -- this parameter is OPTIONAL
["position"] = 359, -- 180 this parameter is OPTIONAL
["brightness"] = 25 -- this parameter is OPTIONAL
}
luup.call_action("urn:micasaverde-com:serviceId:Wink_Hub1", "UpdateNimbusDial", Action_Parameters, Wink_Connect_Device_ID)
Garage Closed
local Wink_Connect_Device_ID = 142
local Nimbus_ID = 13997
local Dial_Index = 3 -- can be 0, 1, 2 or 3
local Action_Parameters = {
["cloud_clock_id"] = Nimbus_ID,
["dial_index"] = Dial_Index,
["Label1"] = "CLOSED GARAGE",
["Label2"] = "GARAGE STATUS",
["dial_rotation"] = "cw",
["dial_scale_type"] = "linear",
["dial_min_value"] = 0,
["dial_max_value"] = 100,
["dial_min_position"] = 0,
["dial_max_position"] = 360,
["dial_num_ticks"] = 12,
["value"] = 50, -- this parameter is OPTIONAL
["position"] = 45, -- 180 this parameter is OPTIONAL
["brightness"] = 25 -- this parameter is OPTIONAL
}
luup.call_action("urn:micasaverde-com:serviceId:Wink_Hub1", "UpdateNimbusDial", Action_Parameters, Wink_Connect_Device_ID)
I was thinking about picking up a pico remote. Can I use the pico remote by itself even if I don’t have Lutron Caseta dimmer?
Does your plugin make it so that all buttons can trigger events. (No worries if not, just trying to understand the functionality before I buy one).
Thanks man!
[quote=“kenray536, post:587, topic:185289”]I was thinking about picking up a pico remote. Can I use the pico remote by itself even if I don’t have Lutron Caseta dimmer?
Does your plugin make it so that all buttons can trigger events. (No worries if not, just trying to understand the functionality before I buy one).
Thanks man![/quote]
If your Wink Hub is rooted, you can install the local_api and use the Pico remote as a 5-button scene controller.
If your hub is not rooted, you can only use the Pico with Casetta switches and dimmers.
If you do not have Casetta switches and dimmers, you may wish to wait… Lutron is in the process of releaseing the “Lutron Connected Bulb Remote”… A Pico-sized remote (can use the Pico wall and desk mounts) that uses zigbee, and will act as a primary zigbee controller (and can control zigbee bulbs such as Cree, GE Link, Ecosmart and Philips Hue) or as a secondary controller… It started to sell at Home Depot last week (as someone messed up and shipped then early) but they were schedules for a September release… The Wink app and firmware is supported to be updated to support it, and it may be usable as a scene controller.
BTW… Home depot also started marketing it’s own line of zigbee smart bulbs under the EcoSmart brand name… They work well, are brighter than the Cree and GE bulbs (even though the Cree bulbs have a higher lumen output) are cheaper (a 2-pack of A19 bulbs retails for $33CDN) and are available in four style (A19, PAR20, BR30 and GU10) and three color temperatures (2700K, 3000K and 5000K)…
As always, thanks for the info.
I actually have Wink Hub Brand new in the box that is the WH01 version. I picked it up on Craigslist after I picked up the Wink hub that I’m using now just in case I wanted to root later.
I’m hoping it’s one of the older versions from prior to the Curl root exploit being patched.
Any recommendations on a site I can go to that will show me how to root it and update to the latest firmware?
Are you able to be rooted, and yet still have the most current Wink updates?
TEST VERSION - EXPERIMENTAL - Preliminary Rheem Water Heater support
v0.19dev15 - September 1, 2015 (Manual update only - EXPERIMENTAL)
- add status/control for Rheem Econet Water Heaters
- fixed error in UI5 json file for thermostats
CHANGED FILES
L_Wink_Hub1.lua
D_Wink_ZoneThermostat1_UI5.json
NEW FILES
D_Wink_WaterHeater1.xml
D_Wink_WaterHeater1.json
S_Wink_WaterHeater1.xml
So the initial test results were somewhat successful. To set the stage, I had installed the wink plugin on my spare Vera 3 UI5 last night. This evening, I updated the plugin with the select files you mentioned from the .zip file and restarted luup.
When restarting luup, the wink plugin correctly found my water heater and displayed information about it! Yea!!!
Next, I tried the following:
Pushed the “Up” Button - No Implementation Error on dashboard and inside plugin
Pushed the “Down” Button - No Implementation Error on dashboard and inside plugin
Set Vacation Mode to “off” - No error message displayed
NOTE: UI doesn’t show changes as they are made. Assuming these would be updated based on the polling frequency.
Eventually when accessing things through my Rheem App, I started getting a water heater offline error. I then reset the wi-fi module and tried these tests:
Pushed the “Up” Button - No Implementation Error on dashboard and inside plugin
Pushed the “Down” Button - No Implementation Error on dashboard and inside plugin
Set Vacation Mode to “off” - No error message displayed
Turn Water heater “off” - No error message displayed
NOTE: After I made these settings changes, I shut down my Rheem App, started it back up, and then checked to see if any changes were made. None appeared to be made.
Some time later from the “Rheem App” I get an error “Sorry, Connection was lost from Rheem App on water heater.”
I then open the Wink app and it says “This water heater is offline”
I wait ten minutes and try again. Requests on all apps still time out. I unplug the unit for one minute and restart. I’m still having problems connecting with even the Rheem app.
But this gets even more strange. On the Rheem app I’m not able to adjust temperature. It times out, but I am able to enter vacation mode where it starts right away.
Next, I force a refresh in Vera
However when I look at the vera even after a refresh this vacation mode does not seem to be updated. I do see some of the info in the log files toward the end.
Next I updated then Rheem app to the Aug 4th release and this aspect seems to be fixed. The Wink app is still showing my water heater is offline. Here’s hoping there is hot water tomorrow or the WAF will be low!
I’ll send some log info via PM.
If you installed the APP MARKETPLACE version, the changed files list is NOT valid… The changed files list notes the files change from the PREVIOUS dev release.
A new version is available in the first post of the thread…
v0.19dev19 - September 8, 2015 (Manual update only)
- added - icon for Rheem Econet Water Heaters
- added - option to create Vera devices for Temperature and Humidity devices on Wink Relay and Quirky Spotter
- added - support for Quirky+GE Tapt Smart Switch (see HERE for details)
Updated files:
L_Wink_Hub1.lua
D_Wink_Hub1_UI7.json
D_Wink_Hub1_UI5.json
D_Wink_WaterHeater1.json
New Option - “Create Vera device for sensors”
Enabling this option will cause the plugin to create standalone sensor devices for the sensors (currently, Temperature and Humidity) in a sensor_pod device (currently, Wink Relay and Quirky Spotter). These new devices are in addition to the sensor support incorporated into the Vera Device created for the main device. As these additional devices are standard Vera device types, they will (should) allow them to appear in any Vera compatible mobile app and other Vera Apps that alow input from a Temperature or Humidity sensor (IE: PLEG).
New Device Support - Quirky+GE Tapt
If you have a Quirky+GE Tapt Smart Switch, the plugin will create either one or two Vera devices for each Tapt Smart Switch - depending on how the Tapt is configured in the Wink API.
For all configurations, a scene controller is create, which allows you to map the buttons on the Tapt switch to scenes that are configured on your Vera.
If the “Light Load Settings” on the Tapt Smart Switch is configured to “Default Configuration” or “Smart Configuration”, a binary switch device is created. This switch allows you to control the circuit that is attached to the Tapt Smart Switch. If the “Light Load Settings” is set to “None”, the switch is not controllable and a binary switch device is not created.
Tapt Smart Switch - Scene Controller Buttom definitions
If the “FiresOffEvents” variable is set to “0” in the scene controller device (The default setting):
Button #1 = Top Button short press
Button #2 = Top Button long press
Button #3 = Bottom Button short press
Button #4 = Bottom Button long press
If the “FiresOffEvents” variable is set to “1” in the scene controller device:
Button #1 = Top Button
Button #2 = Bottom Button
A short press of a button fires a sl_SceneActivated event, a long press fires a sl_SceneDeactivated event.
NOTE: Any scenes that are run on the Vera are IN ADDITION TO the on/off events that are assigned to the buttons in the Wink API (via the Wink APP).
For the quirky spotter, are the motion sensor sound sensors also supported? Will Vera automatically make devices for this? Thanks cybrmage!
The spotter is supported and the readings from the sensors, which are displayed on the Spotter’s UI rendering, can be used for notifications and as scene triggers.
As far as individual devices for the sensors, only the humidity and temperature sensors are supported at the moment.
BTW… The Spotter does not have a motion sensor… It has a vibration sensor… subtle but distinct difference.
Couldnt seem to find the answer in this thread. If I change the name of a device that is setup in Wink after I already synced and Vera created the devices, does the name change transfer over to Vera?
And on a similar note, I assume it is safe to change the room associated with a wink device inside vera ?
thanks
No.
Once the devices in Vera are created, the Vera Names take precedence over the Wink names. If you change the name with the Wink App, it will not change on the Vera device… If you change the name of the Vera device, it will change the name of the device in the Wink App.
The “name in wink” and “name in vera” processing that is shown in the debug logs is for two reasons:
- the plugin will change the name of the Vera device based on certain states of the Wink device (IE: add [OFFLINE] or [FIRMWARE] status messages)
- to detect when the base name (without the status messages) in Vera has changed, so that the name in Wink can be updated.
The only exception to this precedence is when the name of the Vera device starts with an underscore… In Vera, this (usually) means that the device has just been created. (IE: a new switch will get the name “_Binary Switch”). When the Vera name start with an underscore, the name in Vera will be changed to the name that exists in the Wink.
Note that the name processing is only performed:
- during plugin startup (all devices are updated)
- during a resync (all devices are updated)
- when a device status update is received (just the specific device is update when in notification mode, all devices when in polled mode)
Yes. The Wink API does not have the concept of “rooms” associated with any devices, so the “room” assignment on Vera devices is not communicated to (or from) the Wink API. The “room” assignment is for a Vera device is not set/updated/modified in any way by the Wink Connect plugin.
thanks for the response.
So if i want to start from scratch now that I know better, can I simply delete all the items in Vera, then re-sync, and everything will get created again. Or bad idea 
thanks
[quote=“mpovolo, post:598, topic:185289”]thanks for the response.
So if i want to start from scratch now that I know better, can I simply delete all the items in Vera, then re-sync, and everything will get created again. Or bad idea
thanks[/quote]
Easier… change the name of all your Wink devices (in Vera) so that they start with an underscore, then resync.
NEW FIRMWARE WARNING FOR USERS OF ROOTED WINK HUBS
Wink has released Firmware version 2.19 for the Wink Hub.
This firmware removes the original webserver that was used in the original rooting process. This webserver provided the means to allow creation of the local_api scripts that allow a rooted Wink Hub to work with the Wink Connect plugin in “LOCAL” API mode.
This webserver has been replaced with a “local control” server that will provide similar functionality BUT all of the local control functions have been disabled for this firmware release.
The Wink Connect plugin has already been updated so that it will work with the local_control server, once it is enabled.
At this point in time, IF you upgrade your rooted Wink Hub to firmware 2.19, it will no longer be able to operate in “LOCAL” API mode.
I am looking at ways to re-install the local_api webserver, or to enable the local_control server, but do not have a solution at the moment.