Since I got the system up and running last night, I have not had any issues with it dropping off either.
Im running the master branch of the wink-relay-handler, and wanted to know if your branch is in parity with his branch, short of the addition you made for the motion sensor?
Im interested because it seems since Ive moved to this the prox sensor on the Relay has become incredibly weak, like within 4 inches weak. Using an external motion sensor seems like a good fix, as I already have something similar setup with Tasker and a wall mounted Nexus 7 in my living room.
Hey again Woodsmith, while I like the tiled nature of the HomeAssistant android app, it doesn’t really allow for much freedom in design or layout.
Have you taken a look at Home Remote?
While the stock interface is a little nicer than the app you posted, thats not really where this app shines.
The really nice part is found on the official website for the app, where they also provide a windows based UI editor. You can pretty much do whatever you want in terms of UI. Learning curve is a bit steep, but nothing too crazy.
Now that I have the Playstore up and running on my Wink Relay creating a completely custom UI is on my to-do list for after I get migrated over from Smartthings.
HASS can connect to it directly to Home Remote through MQTT.
I just took a look at GitHub and it looks like I’m one significant commit behind the original author - the commit where he added local control of the relays (ie the buttons directly control the relays rather than needing an mqtt message to control them). If that’s not important for you then my fork otherwise is fine to use.
I’ll try at some point this weekend to merge in that commit and also cut a binary release.
I’ve looked at Home Remote but was hoping for something a bit more “out of the box”. I try to channel everything though HA and avoid controlling devices directly, but I suppose it could be done with Home Remote via MQTT. You can launch Home Assist and it just works - the tiles are formatted based on the domain/configuration of the underlying HA entity. Spend 15 minutes customizing your dashboard and you’ll have a solid UI for HA. If I were to invest the time to configure something fancy, I’d turn to either HADashboard through AppDaemon or a custom HA Floorplan and run it in a kiosk mode browser. Some users have posted quite extravagant floor plans. Low priority though, since most of my controls are now going through Alexa/Google.
The proximity sensor does become nearly useless without the native Wink apo. It appears that Wink implemented something fancier to extend the distance, perhaps leveraging the light sensor and microphone as well to trigger the screen.
Lastly, I won’t be of any help regarding Macs, sorry. But if useful, below is my eventghost configuration that publishes when my computer is either active or idle for 2.5 minutes (window’s 1 minute “idle” definition with a 90 second delay added on top). It also listens for commands to sleep both the computer and my monitors. Tag me in a comment on another feed if you have other questions. For linux systems, see the hibernation example at the bottom of the Wake on LAN doc to shutdown via SSH. Come to think of it, using HA to reboot the relay remotely may be a temporary solution to the issue some of us are having with MQTT dropping offline…
I
Does your branch also publish the state of the screen? So the proximity sensor reports to HA? One of my relays is in a narrow hallway and I’m trying to avoid buying another motion sensor.
And until I resolve the MQTT connectivity issue, local control is critical for allowing basic use of the switch when the connection is dropped. Based on github, others have reported the issue - very curious what it is that is causing some to experience it and others not to. I just added a “keepalive” automation that publishes the current state of the switch via the MQTT command every 5 minutes - will post an update in the off chance that it makes a difference.
Hello all. I’m actually a Homeseer users looking for the pre-compiled binary of the mqtt wink-relay apk. I don’t have a linux VM to compile the code on. Any help?
@Bill,
I dont believe The Home Remote works on the wink relay. It needs I believe a minimum of Android 5 while the Wink relay is 4.3. Were you able to get it working ?
Anyone else having problems with the screen not turning off? I’ve got everything else running as I’d like, but the screen is on 24/7. I’ve seen that there a way to turn on the screen using MQTT (msg “ON” to Relay/screen), but I can’t figure out how to turn it off. I’m using the original build and not @marthocoo 's build. Anyone have a recent compiled version of that fork?
EDIT: As a followup, @marthocoo has just updated his branch to include MQTT control over the screen. It’s available here!! I just grabbed it and will try it out tonight, but if anyone else is having this problem, the new build is worth a try. Big Thanks to @marthocoo for the update!
@arth33 Hey thanks for this and sorry I hadn’t seen your message sooner. Let me know how it works - and if you haven’t gotten to it yet I’ve cut another release today - v1.1-fork.1 - you should use. I’ve been using the screen-control version for quite a while now in testing and its working very well.
Today’s release fixes a problem I had noticed for quite a while - button press messages were being sent with the retained flag set, so when I would restart Home Assistant, the lights I had automated on the button presses were toggling because they were being delivered the retained ‘on’ message. If you don’t understand any of that, it’s not important - just know that this makes the system work better and as it should.
I just cut another release - v1.1-fork.2 - this one should be of interest to @Woodsmith as it uses the proximity sensor as an MQTT motion detector, publishing an “on” message when the prox is tripped and an “off” message after a configurable number of seconds (30 by default). I’ve tested it briefly and it’s working fine. Read about it in the release notes or in the README on my dev branch. Raise issues here or on GitHub. https://github.com/marthoc/wink-relay-handler/releases.
Thanks for all the updates! I grabbed v1.1-fork.2 and I am getting mqtt messages from my proximity sensor and I’m able to turn off the screen momentarily. as a result, I think I’ve figured out my problem, my proximity sensor is broken in the other direction: it’s stuck constantly reporting activity, so it’s always reactivating the screen. Is there any way to disable the proximity sensor, or at least disconnect it from triggering the screen? (so I can either rely on another sensor, or just activate the screen on touch instead)? Thanks again for all your work on this, even if this doesn’t happen I really appreciate the functions you’ve already incorporated.
@arth33 I have an idea for debugging the prox sensor if you’re game to try it - it will require another release though, I’m going to build some debug code in and see if we can figure out collectively why everyone’s prox sensors seem to react differently. My hunch is that the prox threshold is not uniform across Wink Relays; currently the code reads the prox and says if the value is < 5000, turn the screen on. 5000 what? I don’t know, originally I thought maybe a unit of measure but I’m not sure. Problem may be that yours is differently sensitive or the original Wink code accounts for the variations in some way that wink-handler isn’t, so 5000 may not be the right threshold for you. Not exactly sure when I can get to this, probably not this weekend unfortunately but likely Tuesday.
I also have some ideas for solving the MQTT issues others have been having so some testing needs to be done on that front too.
@arth33 There’s a debug version I just posted to my releases page I’d like you to try - wink-handler-v1.1-fork.2-debug.
After you install it and reboot your Wink Relay, subscribe an MQTT client to topic_prefix/prox. Every second, you should see a value coming through that corresponds to the value that is being read from the prox sensor. I was slightly wrong about the code in my earlier post (was just typing a response quickly from my phone) - it reads the prox and says if the value is >= 5000, turn the screen on. At rest (i.e. when there’s nothing in front of it) my WR is reporting a value ~3700. My guess is that at rest yours is reporting >5000. So see what yours is at rest, then stand in front of it where you’d like the prox to trigger, and see what it changes to. If this testing is successful, I can turn the prox threshold into a variable to be set in mqtt.ini.
I was about to post a message regarding this, I have two relays one of them shows a reading of 3300 when there is nothing in front of the sensor the other one stays around 8400 when there is nothing near the sensor.
Here are my detailed results:
Relay1 Nothing in Front: 3400
Relay1 Finger on 1inch from the sensor: 9000
Relay2 Nothing in Front: 8400
Relay2 Finger on 1inch from the sensor: 12000
It would be ideal if you can add a sensitivity variable in the config file. I also noticed that the proximity sensor was more sensitive when I was running the stock Wink software.
@cptquad Thanks for the data. And what about the value when you are at a reasonable distance in front of the WR (like not an inch away, but standing more or less at a distance where you’d expect it/like it to trigger)? At that range, what’s the value? And at what point (distance) do you start noticing the value increasing from the resting value?
Infinity- No available, there is a wall around 36 inches from the relay
36 Inches- ~8910
30 Inches- ~ 8950
20 Inches- ~9000
10 Inches- ~9260
5 Inches- ~11000
@cptquad Thanks. I’m going to wait for data from a few more users but I think the way I’m going to try to solve this is to make the trigger point a value relative to the absolute reading from the prox sensor, and allow the user to set the delta percentage via a config parameter.
So for example, take your relay 1. At rest it’s 3400. Say the default delta is 5%. Meaning the prox value has to increase by 5% over resting before it’s considered tripped. So your screen wouldn’t come on until the value was 3570, or by your test something was about 15 inches away.
With your relay 2, if you wanted the screen to turn on at the same distance, you’d need to adjust the delta (according to your testing) as the default 5% over resting would mean the screen wouldn’t trigger until maybe 9 or 8 inches (absolute value 9355). So you might need to dial the delta down to about 3% (so the screen would come on at absolute value 9177).
So that’s the basic idea. It accounts for the wide variation between the prox values being reported by different Wink Relay units and lets the user modify how sensitive the trigger point is. Note that because of the variability in what’s reported by the prox the minimum usable delta is probably about 1%? It will need testing.
