Toggle HomeAssistant groups from Wink Relay buttons!

Ah ok, thank you! I thought you had to pull it down on the relay itself.

Also what do people use the screen for - a homeassistant page of their web UI?

is it just the wink-handler.c file that needs pushing (that feels a little too easy)
EDIT:
So i’ve connected and pushed the wink-handler file (from release 3 on the fork) - however i think i’m missing something - does it not need to be made an apk or app of some kind. Apologies, not really up on my Android usage.
Presumably then in HA, i need to set up switches and sensors matching the MQTT topics in your readme?

Thanks for building this by the way! would be interesting to see if this will allow things like ring door bell answering to function on the screen as well (so when someone pushes the door bell you can just answer on a wink relay ;))

You’re almost there. The wink handler is an application itself, it doesn’t need to be wrapped in an apk. Read through the readme here: https://github.com/marthoc/wink-relay-handler and you’ll get a step by step installation process of getting the wink-relay-handler up and running. Pay careful attention to the mqtt.ini file. That’s where you setup things up for your environment. Follow the instructions and your Relay will be publishing MQTT messages to the following topics:

  • Relay1/sensors/temperature
  • Relay1/sensors/humidity
  • Relay1/motion
  • Relay1/switches/upper
  • Relay1/switches/lower
  • Relay1/relays/upper_state
  • Relay1/relays/lower_state

and listening up these topics:

  • Relay1/relays/upper
  • Relay1/relays/lower
  • Relay1/screen

Now you’ll need to setup HA to listen to/publish to these same topics and trigger events based on them. If you’re not already familiar with MQTT, you should do a little reading on the subject so you understand the mechanics of it (the publish/subscribe model in particular). Then you’ll get a sense of what you can do with all of this stuff and how to tie the pieces together.

1 Like

Thank you for the reply - undocumented territory for me here! i thought i had to do something additional here:

You’ll need the Android NDK installed. Run ANDROID_NDK=/path/to/android/Ndk make

Ok, so just the release file - got it
got the mqtt.ini up there as well. MQTT is running (using Tasmota SONOFF switches)
Will test later on - thank you again

ok, so wink-handler is there, mqtt.ini file is there (i feel i have overcomplicated things by using NGINX) - but reading up on it looks like I should just use a different listener port.

there is an app now on the nova launcher on the relay called ‘edisonplayer’ - although the data (temp/humidity) changes to zero when I launch it.

Seemingly the buttons do nothing on the app (i was hoping there would be a good way to test if anything is working visually)… only way i can think of is:
mosquitto_sub - other than that the relay doesnt seem to show signs of success / failure

Let me wade in here and give you a run down of how I install wink-handler on my Relay.

  1. Download the release from GitHub, extract (will give you a file called wink-handler).
  2. adb connect [ip of relay]
  3. adb push wink-handler /sdcard
  4. adb shell
  5. su
  6. mount -o remount,rw /system
  7. rm /system/bin/edisonwink
  8. cp /sdcard/wink-handler /system/bin/edisonwink
  9. chmod 755 /system/bin/edisonwink
  10. reboot

You’ll hear the physical relays click off when sending the reboot command, and then click on when wink-handler starts. The program runs itself, you don’t need to launch it from the Android front-end or anything.

Then, you need to make HA mqtt sensors for the temp/humidity topics, etc. as @arth33 described above.

You won’t get any onscreen feedback from wink-handler at all. Pushing the physical buttons will generate mqtt messages however, as long as you haven’t set send_switch=false in mqtt.ini.

1 Like

Well done all, especially @marthocoo! I thought this initiative was dead, but clearly not the case with @jimpastos’s vision. I attempted multi-tap automations in HA a while back but found it was was too unreliable on the server side to justify the benefit.

It will be a bit before I get a chance to upgrade, but one thing I noticed regarding MQTT reliability is that even the local toggle fails to work when the relay is booted without a wifi connection. I have quite a few processes running, so perhaps the service is timing out when idle for a period and android needs resources? I haven’t had any luck with adjusting my mosquito config.

Also, as a time-saver for those setting their proximity threshold calibration, I would do so conservatively so you don’t have to revisit it. Last summer I noticed my (stock) relay triggering every time the AC turned on/off.

Stay tuned! I’ve improved the MQTT connection by using an async client.
wink-handler does not monitor anything until a successful MQTT connection is made, which is probably why you were seeing reliability issues with wifi.

Im nearly there with my implementation, just need to make it worthy of github :slight_smile:

Here is a question, should we have a built in gesture for simulating a home button press?
I don’t think the cover Sensor and hold bottom button works after the latest upgrade, so I was thinking maybe having a pattern (tripple click + hold) that will just send a HOME key event.

In addition, I’ve added a config setting to hide the Status bar on top, giving more screen real estate if you are using non fullscreen apps.
Was also thinking of having MQTT topics for maybe rebooting/change DPI …

1 Like

yes, i noticed the cover and hold didnt work until i did a factory reset - so a triple click would be a great idea :slight_smile:

thanks for your efforts on this!

@jimpastos - looking forward to this!

My 2 cents:

  • “Home button press simulator” would be useful, though I think it’s standard practice when rooting the Relay to install an alternative launcher like fullscreen or Nova Launcher that includes a virtual home button. Some button combination would however be useful to simulate a home button press if something crashes or as a last resort.
  • Same goes for hiding the status bar - there are apps that do this, but would be useful generally.
  • An “MQTT API” would be useful, but I could take or leave it.

Thanks again for your efforts and looking forward to testing this out!

Likewise, I use Nova Launcher and Assistive Touch. It overlays a small widget that can be configured with home/back/apps/recent apps. It might be easier to just package a stable version of this and start a HASS Wink repo and focus on MQTT. Better yet, build a custom ROM with Android that could be flashed with something like TWRP, if possible with the Wink bootloader.

I’ve explored quite a few APKs for HASS specific functions and have been disappointed overall. I imagine most of the community has similar use cases for the wink, so while we’re brainstorming I’ll share a few findings:

  • No easy TTS for notifications. LANnouncer requires Lollipop and Kodi is a bit heavy for the little relay.
  • Likewise for audio/video. The screen is too small for anything more than a few controls, so a lightweight way of emulating a Chromecast (initiated from a HASS automation) would be ideal. But given such an old Android distro, Kodi remains the best solution I’ve seen. Pandora runs well, but is just well Pandora…
  • For example, at one point I had an automation set to announce the weather, drive/train time to work, and Uber/Lyft prices when it detected motion in the morning. Can’t remember if I used Kodi or MPD or something similar
  • On a positive note, the “Home Assist” and “(MQTT) Alarm Panel” projects are coming along and are made for older devices by having a light and simple UI that can actually be used - I doubt we’ll find anything better. I’d be willing to bet though that hold/double/triple tap MQTT paired with appropriate automations will end up being more useful than a GUI grid of controls (although not as sexy, which is why many of us were initially drawn to the wink). A year later, I think we can all agree that we’d rather have it do 2-3 things right than 8 shiny things that work 50% of the time.
    TL;DR - you won’t realistically stop and use the touch screen very often. It’s better to have buttons for quick controls and leave automations for triggering updates/notifications/shiny features on the screen. Short of chromecast-like functionality, perhaps opening/closing weather/news/etc apps via MQTT is the next best thing.
  • A while back I had a wink configured as a digital photo frame linked to a network share with photos, which then runs as a screen saver for a set amount of time after the screen wakes and idles before timing out. It worked well, but I removed due to conflicts with Android/MQTT stability that may or may not have been related.

That’s all I can recall at the momement. Keep in mind the reason we were able to buy a 2-load bearing, multi-switch, 3 sensor, smart device with wall mounted tablet, speaker, microphone, and Bluetooth for only $60. Wink priced these over $200 initially and credits the failure to poor design/UI - perhaps we can learn from their mistakes.

Not to be a contrarian but I actually use my screen more than the buttons - I’m using WallPanel to display a dashboard from HADashboard that displays a couple of temperature readings, has a couple of light controls, and displays the lock status of my front door. I’m also using the mqtt screen control functionality I added so Motion in the room turns the Relay screen on, so from a decent way away I get an overview of temperatures and whether my front door is locked. The buttons just trigger automations to turn the room’s lights on and off (boring :wink: ).

agree - i’ve got a page pinned to the launcher (in case it reboots) autologged in to a specific page on my custom panel that is optimized for the room the wink is in and the things around it

thanks for this! Finally nailed it (well needs a reboot to get all the devices showing hopefully correctly, but sending MQTT topics and payloads in the HA UI worked :slight_smile:

curious to what others think - but my initial plan to use these was to provide constant power to hue light bulbs and then control via a ‘smart switch’

There dont seem to be any other solutions to this except putting a Z-wave switch in a wall, having the hue wired permanently and then the z-wave switch actually controlling the hue lights group in HA (not the power)

This is exactly what I’m doing!

1 Like

I didn’t mean to suggest that onscreen controls is useless, just that it has to be minimal and simple and is better suited for displaying information. Opening an app and going through 3 screens to change a state isn’t realistic, however, a few relevant controls is. Ideally the UI would be tailored to the situation in HASS (such as media/volume controls only showing when media is playing, etc).

totally - i use chrome loaded with the full!screen app running a specific page of my custom-tiles-UI (as i know the room its in I made a page useful for that relay) - then pinned it to my home screen if for any reason it didnt stay up.

Also i notice one issue that could catch some folks out
Relays send payload ‘on’ lower case but they need to receive payload ‘ON’ or ‘OFF’ upper case (just figured that out, didnt think it made a difference)

any desire to have the wink relay ring when the ring doorbell rings? possible intercom / lazy sunday

just a thought?

I don’t have a wink doorbell, but made a “smart doorbell” using a ~$3 Amazon Dash WiFi button. My router reports to HASS when the dash comes online and is set to block all WAN traffic (otherwise I’d have as much dish soap as I have friends). HASS then pushes TTS audio to all capable devices of a pleasant sounding lady letting me know that I have a guest at the front door. Responding “unlock” to the notification I push to my phone will open the door. Details are in my post about it here.

1 Like

hi folks, i can NOT stop my bedroom relay coming on by itself. Its essentially by the door entry facing a wall and i have a sneaking suspicion that the light from the relay comes on, bounces off the wall, and triggers the motion sensor with enough of a delay that it gets into a cycle - super annoying at night. I’ve increased the prox_delta to 1.5 but still have the same issue.

Any ideas? does the screen off MQTT command override local PIR? so if i had a rule that shut the screen off, should it wait for an on command, or will it wait for next PIR?