Homebridge-wink version 2

[pdlove]

This has compatibility with the new dynamic plugin types used by home bridge. Compatible with Wink version 2 key (required). Default Key is included until you can get your own. Uses PubNub for instant status updates. Removes support for the Quirky strip for the time being because of difficulty with how to add it back. Will reset accessory to room association because this uses Wink's UUID for devices. Passes the actual manufacturer and model of the device. Be aware that MyQ works differently now in the entire Wink platform. The included default key is the quirky key that can control the doors but custom keys can't control them.

[thechrisreese]

If you can't get this working come over to WinkV2 and we can make it all work out. I know that using V2 API causes timeouts, how is hat going with these edits?

[pdlove]

@thechrisreese are you on Slack? I'd like to discuss what you mean by the timeouts. I've heard from 9 people using my latest rewrite and the only reports of timeouts/direct issues are from @JimBobSD who posted here.

[sreknob]

I am having timeout issues as well.... often get entries in my log and devices stop responding: [5/11/2017, 11:53:44 PM] [Wink2 Bridge] Command Sent To Cloud: Ikea Night Light.{"powered":false} [5/11/2017, 11:55:43 PM] [Wink2 Bridge] Error occurred communicating with 192.168.20.112: socket hang up [5/12/2017, 9:44:58 PM] [Wink2 Bridge] Error occurred communicating with api.wink.com: socket hang up This means that I need to restart the service everyday to get it to respond again....

[mriksman]

@pdlove What is the best way to contact you?

I have Z-Wave blinds (Somfy controller), and they don't work on your new plugin. I managed to get it working on the old plugin by removing the code;

    } else if (this.device.desired_state[sProperty] == undefined) {
        callback(Error("Unsupported"));
        return;
    }

This is because on my Z-Wave blinds, desired_state.position seems to go null after some time of inactivity. So when I went to make a desired_state.position request, the code above would prevent the request from being sent. When it is sent, the desired_state.position is changed properly, and the blinds respond and desired_state.position holds the value for a few minutes before going back to null/undefined.

When I look at the data.data sent in your code (just before the PUT), for the local call I get;

{ hub_device_id: '20',
  object_type: 'hub_device',
  discovered_at: 1494380041.04,
  last_reading: { connection: true, powered: true, brightness: 1 },
  desired_state: {},
  local_id: 20,
  created_at: 1494380036.584,
  name: 'New CLASS_A_MOTOR_CONTROL',
  updated_at: 1494753762.07 }

This shows some issue with desired_state.poisition being undefined. For the cloud call, data.data shows;

{ object_type: 'shade',
  object_id: '6084',
  uuid: '8b2f2bd2-84bd-40fe-978f-dfa680f58b28',
  icon_id: null,
  icon_code: null,
  desired_state:
   { position: 1,
     position_updated_at: 1494758520.29218,
     position_changed_at: 1494758520.29218 },
  last_reading:
   { connection: true,
     connection_updated_at: 1494754611.1709554,
     position: null,
     position_updated_at: 1494754611.1709554,
     desired_position: undefined,
     desired_position_updated_at: undefined,
     desired_position_changed_at: undefined },

Which does show desired_state.position. Still no movement though...

Ahhhh! I disabled direct_access and it now works. I then reenabled it, and commented out this piece of code (line 156 of winkapi.js);

        //Since we sent this locally, we need to make sure the API knows that.
        data.locally_activated_objects = [{
            "object_type": device.object_type,
            "object_id": device.object_id
        }];

From what I understand, this data.locally_activate_objects is then sent to the cloud API on line 163, which ensures that the command isn't sent twice (it ensures the cloud doesn't send the command). So, somehow we need error checking in the locally sent part to see if the command was successful, and if not, allow the cloud to try...? Or some other method...

For now I have enclosed this code in an ifstatement that checks if the object_type is a shade, then do not set this data.locally_activate_objects object.

[mriksman]

@pdlove I also have code modifications to index.js to add leakSMART valve (to binary_switch) and added switch_ids and outlet_ids to the config.json to allow users to force binary_switches to appear as either switch or outlets (similar to how fan_ids works).

Added leak detection to sensor_pods. You have it listed in the comments, but there is no code there.

Humidity Detection (line 770) needs to be multiplied by 100. At least for the Wink Relay it does.

[thechrisreese]

@mriksman come to Homebridge-wink3 where many of these I believe are resolved.

[mriksman]

I've gone to homebridge-wink2; same features (I think) and written by pdlove who has been quite active on smartthings and wink. Few issues/features i've added.

It'd be interesting to know the difference between homebridge-wink2 and homebridge-wink3.

[thechrisreese]

@mriksman Homebridge-wink3 is using V2 API credentials and the push service to stop timeouts. I like what he has done and left my own Homebridge-winkV2 because it's better.

[mriksman]

I meant homebridge-wink2, not your homebridge-winkv2 (which has a 'v'). The homebridge-wink2 plugin by pdlove also has v2 API, and subscriptions. I find the code easier to understand than homebridge-wink3.

[pdlove]

I think there is confusion here. it supports the true version 2 credentials, but Wink has now totally redone how API credentials work for new people into what I'm calling the version 3 api. sibartlett has done some excellent work in this area of consuming the new API and his code is a bit harder to get used to because it uses more modern coding practices that are easier to refactor. I will put out there that I've finally purchased a lutron hub for my last wink-based components and am no longer using wink, so I've more or less left the development. the release of the wink plug in merged here was my last work on the wink plugin.

[AppleTechy]

@pdlove Your not using my dubbed V2.5???😜 API calls stayed the same they just redid how you gain API keys, and the access those keys give you

[jack-hub]

@pdlove >> lutron hub for my last wink-based components

I'm confused. You can move wink-based components to a lutron hub?