Toggle HomeAssistant groups from Wink Relay buttons!

Share your Projects!
121

Awesome
Thanks - will give that a try :slight_smile:

122

so built and deployed with the username and password.

The buttons trigger the relay (the one that is connected) but i cant seem to send any MQTT commands (or see any). using moquitto_sub -d -u -P -t /Bedroom_Relay/buttons/1/

I get nothing. I also cant send Bedroom_Relay/relays/1 ‘ON’ either

any other way to debug?

1 Like
123

Can you paste your ini file? (Without credentials)

Single Clicks for the first button are sent to
Bedroom_Relay/buttons/0/click/1

Double click to:
Bedroom_Relay/buttons/0/click/2

Second button single click…
Bedroom_Relay/buttons/1/click/1

Same with relays. First is 0 second is 1
Bedroom_Relay/relays/0 with payload ON

124 
mqtt_username=<user>
mqtt_password=<password>
mqtt_clientid=Wink_Relay1
mqtt_topic_prefix=Bedroom_Relay
mqtt_address=tcp://<IP>:1883
screen_timeout=5
proximity_threshold=5000
hide_status_bar=true
relay_upper_flags=2
relay_lower_flags=3
125

thanks for the extra help - i’m struggling to troubleshoot beyond subscribing to the topic it should be sending to

126

I think there is a race condition that is not handled correctly when the wink is booting/connecting to wifi and the manager runs. (also status bar doesn’t hide at startup).

The MQTT library im using has a couple of issues (fixed in their latest commits) where user/pass is not copied correctly and reconnect logic doesn’t work when network is down.
I’ll debug/test over the w/e and post an update.

In the meantime, try this. adb shell on the device:

  1. su
  2. ps | grep edison (get the PID)
  3. kill
    This will cause the edisonwink process to be restarted, and since network connectivity is up it should connect/work
1 Like
127

Also make sure there is no “/” at the start of your topics when subscribing on your MQTT server.
Bedroom_Relay/… not /Bedroom_Relay/…

128

You are correct on the network race condition. I went through the MQTT logs and found that MQTT will attempt to connect using version 4, get a network unreachable error, then attempt a connection with version 3, and again get an error, then stop attempting connections. It does call the onConnectFailure callback but passes it either a null response or a 0 code, I can’t remember which and not useful either way.

I forked your github repo and added some network test logic and settings to wait for the network to be available before continuing. I’m not sure if this is the “best” approach but it does seem to be working for me.

I also uncommented a number of the printf calls and changed them to use android’s logging framework so you can call adb logcat wink-relay-manager:V *:S and see the app output in real time.

129

Nice,

Im was planning on adding real logging in a tmp folder and updating the MQTT library. Maybe i should just use the logcat instead but a separate file might be easier to track in general :slight_smile:
https://github.com/eclipse/paho.mqtt.c/issues shows a bunch of things fixed which should directly affect things.

I’ll debug more when i get a chance.

130

Ok latest push has logging (and optional debug) written to /data/local/tmp/wink_manager.log.
In addition, I update to the latest (develop branch) paho library which fixes the reconnect issue so everything is handled correctly on startup now.

I also added a delay before attempting to hide the status bar. Chose 30 seconds for now, but didn’t really test properly. We might need to increase/decrease depending on how long the relay takes to initialize on average

131

Next update ill enable logcat logging too

1 Like
132

thanks for continuing to work on this - wish I could be some help!

133

New update, logs now default to logcat, but can be changed to a file in the config file

134

ok so new build i’m getting the commands - and so far everything is working :slight_smile:

will run it on the Bedroom_Relay for a few days and see how it fairs - awesome work thanks @jimpastos

EDIT: retain state is AN AMAZING addition! bonus points

1 Like
135

just out of curiosity do people have:

A) an automation that on click toggles a hue light/group

or

B) an automation that turns_on a hue group if condition hue group is OFF (and visa versa)

(with option A i noticed some of the hue bulbs get out of sync, so toggle doesnt seem to work all the time)

136

I have these, which check current state but I believe newer versions of HA have light groups where we can simply toggle the entire group. I am planning on migrating to these soon.

The automation could simply call the service light.toggle and the group as an entity. If you want to set 100% brightness though, you’ll probably have to have a condition to check the groups on state first

1 Like
137

so i think the issue is when toggling something that doesnt have fixed state implicitly called out. (i could be losing my mind, so bare with me…)

a switch when toggled actually has a turn_off mode and a turn_on mode - thus when you toggle a switch to off with multiple switches it sends turn_off to all the entities in the list. using a switch template like this:

- platform: template
  switches:
    bathroom_lights:
      value_template: "{{ is_state('switch.bedroom_lights', 'on') }}"
      turn_on:
        service: light.turn_on
        entity_id:
          - light.jamie_mirror_1
          - light.jamie_mirror_2
          - light.jamie_mirror_3
      turn_off:
        service: light.turn_off
        entity_id:
          - light.jamie_mirror_1
          - light.jamie_mirror_2
          - light.jamie_mirror_3

however when you toggle a light group (essentially a group of lights) - it sends the toggle to all the lights (not the implicit turn_on or turn_off) so if 1 is out of sync, it will stay that way. IE when you toggle again that 1 will remain in the opposite state to the others.

138

i see.
lets assume we have a light group with 2 lights with an inconsistent state (one on the other off).
What will be the state of the group when we query it?

can we simply have 2 triggers with actions like:

action:
  - condition: state
    entity_id: <light_group_id>
    state: 'on'
  - service: light_turn_off
    entity_id: <light_group_id>

and another with ‘off’ and turn_on

139

it seems as if 1 light it on in the group - the group is ‘on’ (then using a tile on the dashboard to toggle) toggle will send off command.

it seems the only way to do it without the chance of sync issues is with a condition as you say

140

I guess thats acceptable. Basically getting everything in sync.

Another option is to use the double click, tripple, 4, 5, 6 clicks :slight_smile:
Single click -> ON
Double click -> OFF

Assuming a light group called “light.groupA”

automation:
  - trigger:
    platform: mqtt
    topic: "Relay/buttons/1/click/1"
    payload: "ON"
    action:
    - service: light_turn_on
      entity_id: "light.groupA"

- trigger:
    platform: mqtt
    topic: "Relay/buttons/1/click/2"
    payload: "ON"
    action:
    - service: light_turn_off
      entity_id: "light.groupA"