Am I doing this in the root of the home directory or in the root of my pi user? I’m ready to give this a shot and wanted to make sure. In other words, when I execute step 2, should I be in /home or /home/pi ?
/home/pi the command in step two is an alias that takes you to the current users home directory.
I’m at the config step but I’m a bit hesitant to proceed. I’m running split configs with some configs in subdirectories. Would I be better off just running a basic config and adding only the Wink stuff for testing purposes?
That would work, or you could copy the entire config directory to the new config directory.
Well, tried copying all the YAML and conf files into hasstest/config along with the subdirectories:
pi@raspi1:~/hasstest/config$ cd ..
pi@raspi1:~/hasstest$ source bin/activate
(hasstest) pi@raspi1:~/hasstest$ cd config
(hasstest) pi@raspi1:~/hasstest/config$ hass -c
usage: hass [-h] [--version] [-c path_to_config_dir] [--demo-mode] [--debug]
[--open-ui] [--skip-pip] [-v] [--pid-file path_to_pid_file]
[--log-rotate-days LOG_ROTATE_DAYS] [--runner] [--script ...]
[--daemon]
hass: error: argument -c/--config: expected one argument
(hasstest) pi@raspi1:~/hasstest/config$
Then I ran again without the -c option and it looks like it is running and installing dependencies. I’ll let it run for a bit and then check if I can get to the UI.
Okay, if youbrun without the -c it will run the default config so that will probably work. If you use the -c you have to provide the path to the config dir, that is what the . means, “use the directory I am in”
I missed the dot after the -c thinking it was the period at the end of your sentence. But when I ran it again, it appears that everything I copied over was deleted so I think I’m going to have to continue along with a basic config and just run the wink stuff. Not sure why my copied configs were deleted though.
OK, so here’s what I see so far:
1 - Let’s get this out of the way immediately; the loop error is gone. GONE! I’m sure you’re even happier than I am. I tested this multiple times to make sure.
2 - States seem to react quickly and accurately. Stuff is getting logged properly as well. Did have one oddity but I’m not sure if this is unique to me. I had one hue lightstrip show as on when it wasn’t physically on. I waited a few moments to see if it would update but it didn’t. Now on occasion, this lightstrip shows on in the Wink app and then after the app refreshes, it shows the proper state. So I checked the app and this was the case. But in HA it still didn’t change state. I toggled the switch and it stayed off. On my second reboot, the state was properly reflected. BTW, at all times, the other Hue lights showed proper state.
I’m not worried about this one but I thought I’d mention it to be thorough.
3 - I ended up putting all the binary sensors and sensors into separate groups because I wanted to make it easier to test, as well as to read the full entity names. The binary sensor naming threw me off a bit even though you gave me a heads up but I got quickly used to the naming convention. It’s actually more logical if the state is going to be on/off because “opening” is what it’s really detecting here.
I like seeing the new sensors, especially the proximity on the relay! I like that while the sensor shows on/off, the attribute in the dev panel shows a numerical value - this will allow you to do automations based on a trigger level. Seems like my troublesome sensors in the back room are behaving better under this version as well.
I did notice though that the two relay sensors:
binary_sensor.wink_relays_bottom_button
binary_sensor.wink_relays_top_button
Don’t seem to be recording their state changes to the timeline in the card. At first I thought they weren’t changing state, but I went to the relay with a tablet and watched the sensors in the group change as I pressed them. They show in Logbook too, but for some reason not in the detail card. But I noticed that besides the binary sensor, there are attributes for pressed and long pressed so this may be the reason why; when a single sensor with multiple attributes is displayed on a card, the timeline always shows off. I had the same issue with the ecobee’s climate card; while it should have shown the operating state as the timeline, it doesn’t. I ended up having to create a template sensor to show the operating state. I think this is the same thing; if I create a template sensor for the button attribute, I’ll see a proper history timeline in the card.
As I said, I think this is in HA and not your code; maybe it’s something you can discuss with one of the core devs.
I’m still having issues with the state of that lightstrip. Wierd.
I opened the WInk App again, and it was showing on yet again (while being physically off). Changed it there but didn’t reflect in HA.
So then I went to Wink@Home and damned if it wasn’t showing on there as well!! Finally turned it off on Wink@Home and now it’s showing properly everywhere. Must have been stuck in state there and that was affecting everything else.
I noticed my front door lock now states as Locked/Unlocked instead of on/off, which is really nice.
I wonder if you can answer a question for me that’s related; if the class of a binary sensor is “opening”, then why is the reported state on/off instead of open/closed? According to my interpretation of sensor_class: from this document:
I thought that was the purpose of
sensor_class: to show the appropriate state based on the class. So shouldn’t the binary sensors you created as ‘opened’ be showing open/close since they are listed as opening class?
Let me know what else you need me to test. Everything seems pretty stable and working the way it should.
Wow, great feedback. Thanks!
Very glad to hear about the loop error, that was driving me crazy.
I have noticed some state delays in the last couple days and some issues where they aren’t reported correctly ever. Very rare that this happens but I think it may be due to a delay in pubnubs responses. In every case I have seen, it was also wrong in the Wink app. The Wink app polls their API on occasion which we don’t do. If you want, you can run the Wink service “refresh state from api” (or something like that) that will poll the API to correct the state, if Wink does have the correct state on their end.
I have not been able to figure out the proximity on the relay, it is very strange/doesn’t seem to change when you would expect.
The buttons on the relay report a long_pressed attribute but I have not been able to make them change state and Wink has no mention of them in the app. This may be a new feature coming soon?
I’ll look into the opening class, could be that I don’t have it setup correctly.
If there isn’t anything else you need at the moment, I’d like to shut down and go back to my standard setup. (But now that I’m set up, I can go back to testing if you need me to.)
I’ll wait to hear back from you.
Go for it. I’ll wait to see if anyone else is able to test and open a home assistant pull request hopefully by the end if the week. Doubt we will make it into the next release coming this weekend.
1 Like
Sorry I’ve been trying to get some time to test but I have a email server issue that needs attention. I’ll try as soon as I can.
1 Like
Maybe, if we can get more testers! (HINT HINT!!) 
If not, perhaps @balloob would consider a point release for this - it’s certainly worth it, given the fixes and the added features and support.
I’ve installed and it’s working just fine. I pulled most stuff out of Wink unless there was no other choice. So I only have Lutron Caseta stuff, a few Connected remotes, some GE link bulbs, some Ecosmart RGBW bulbs, a Leviton switch and plug and a Schalge lock. Everything is working fine. Log is full of errors but that’s mostly because of my config. I’ve got a few components that never play nice (Pioneer AVR for one). Zwave seems to be out too.
On the Wink side everything is accounted for and working fine. I was not getting the loop error for a while so tough to comment on that. I can say I’m not seeing it.
I do see the change in in binary (door/window) sensors. That’s nice.
Remotes are reporting properly it seems. Gotta stop pushing buttons though. Someone is not happy.
I’ll fix my config and get everything working as I have it in PR. I can add a Nest Protect, a Dropcam Pro and Hue hub if you think it’s necessary. Would rather not if you don’t need feedback on those.
Do you have a Relay? If so, press whatever buttons you have actually connected to a load (light switch) and see if you get the loop error in your logs.
If it isn’t too much trouble I would like to see the JSON for the drop cam, and the states you are able to set in the wink app. I mentioned above I added support for the canary camera. That only supports the canary because there is no documentation on cameras and mode selection in the JSON of the canary doesn’t match what actually gets set. So… I hard coded python-wink to only support canary until I can get JSON for the other supported cameras.
Oh, also glad to hear everything is working.
PMed to you.
1 Like
Man, I hope this gets pushed soon; now I’m getting the loop error on restart. Fortunately, it doesn’t seem to be taking out pubnub completely though.
Can’t wait!