I just had a chance to measure mine. I’m at
Infinity- 5888
40 Inches- 5912
30 Inches- 5924
20 Inches- 5957
10 Inches- 6304
5 Inches- 8193
1 inch- 31000
@marthocoo Thanks again for this. I like the approach you’re planning. Certainly better than relying on any absolute values.
@arth33 Great to see the data confirming my theory. So far for our four relays (mine, yours, and the two of @cptquad) my approach would work to make the prox more (properly) sensitive and in the case of yours and one of his make it actually work to turn the screen on/off.
I’ll try to get this done today and test before getting you guys to test.
@arth33, @cptquad: See my releases page for my first attempt at a fix for this: the increasingly ridiculously named wink-handler-v1.1-fork.2-debug.1. After a bit of testing on my Relay, I set the default change required to trigger the screen (and an mqtt motion sensor message if you’re using that feature) to 1%, but 0.75 works well for me too. The mqtt.ini parameter is prox_delta and it takes decimal or integer values (lower value = more “sensitive” proximity detection); as I said the default is currently 1 if not defined in mqtt.ini.
Edit: Just to add a bit more detail. If you install this version and your screen won’t turn off (or turns on and off by itself), up the value by say 0.25. If its not “sensitive” enough, decrease the value by 0.25. Ideally you want the threshold to be just above the range of normal variability.
Awesome thank you, I will post the results when I get back home tonight.
Just tried the new build and it works perfectly! I’m tweaking the delta percentage a bit (my sensor is pretty finicky), but it works exactly as you hoped. Thanks so much for this @marthocoo . It’s a great solution to the problem.
Great to hear! let me know what delta number you end up settling on.
Looks like I’m settling in on a 0.30. I went as low as 0.15, but I started to hit the lower limit. Because of the sudden ramp up with my sensor, there isn’t really a real world difference between 0.30 through 4 or 5. I can’t trigger it at a long distance no matter what number I set. 0.30 is about 4 or 5 inches on mine. I’d like it a little further, but I think the sensor is effectively at infinity by about 6 inches. Regardless, this is really great. Thanks again @marthocoo !
Hmm that sounds strange - are you rebooting the relay after changing the parameter? A reboot is needed for Wink-handler to pick up the change.
The new version works like a charm, I am running .75 on both my relays and everything is working as expected.
I just found something really interesting, My relay 2 (The one that has high readings). It seems the readings are inversely proportional to the temperature. As you can see in the image the readings are continuously going up as the temperature is falling. Around the 22:23 mark I raised the temperature by keeping my hand on the relay for a minute.
Reading from the other relay.
I am going to let this run overnight and see how it looks like in the morning.
Glad to hear it’s working! That’s interesting about the prox readings - I’m hard pressed at the moment to explain why that would be happening. At any rate, the prox code I wrote should take account of that - it bases whether to turn the screen on on the current reading of the prox versus the last reading of the prox, so it’s always relative to the most recent readings - assuming of course that the threshold doesn’t change as the temperature does (meaning that an object in front of the sensor raises the prox reading by approximately the same amount at any temperature).
To anyone joining this topic now, I just released a new version on my fork that addresses the proximity sensor issue in addition to my other modifications - v1.1-fork.3: https://github.com/marthoc/wink-relay-handler/releases.
Thanks! I’ve pushed out a v1.2 that includes these PRs.
Somewhat mystifyingly, I don’t experience them. Maybe it’s my network? I’m currently looking into the mqtt broker connectivity issue and I think I’ve narrowed things down to a couple of issues - one is an easily solvable problem I’m working on implementing a fix for, the other I think is a problem with the underlying Paho mqtt embedded-c library that wink-handler relies on, which is proving to be a bit more mystifying for me. Work continues and I hope to have something for people with disconnection problems to test soon.
One problem is that C is not my forte and I’m learning how to do things as I go!
So I just saw this thread doh…
I have been using wink-relay-handler and it definitely made my relays much better, especially integrating with HA.
Great work with GPIO and Sensor integration @mjg59.
A big source of frustrations though are MQTT disconnections. Nothing good with seeing a stale Relay and the wife is trying to turn on stuff.
The pattern I noticed is that if HA (embedded MQTT) goes down (or server decides to kick off client), the relay doesn’t even notice and in theory should fail on its next MQTT message and reconnect. It doesn’t and actually sometimes crashes the app but its restarted (not terrible). If it doesn’t crash it just sits there until we restart the Relay
Issues I noticed:
I did some experiments with the Relay’s GPIOs and started a new project (C/C++ based) that polls (see poll()) state on a thread and also uses the latest Paho Async MQTT lib which I heavily tested with all kinds of disconnect/reconnects.
Using poll() blocks until a button is pressed, meaning the response time is incredibly fast. So fast in fact that I was able to implement single and multi click events but also press & hold (with multi clicks).
All these different variations can probably send different MQTT messages (on different topics or just different payloads, haven’t decided that yet).
I am planning on creating a new project and publish on github, once I implement all the sensors and the awesome proximity fixes in this thread.
Hm. My testing had indicated that the GPIO files didn’t handle poll() properly, hence the looping reads. It’d obviously be preferable to be event driven (although there’s not really any way around polling the proximity sensor, as far as I can tell) and I could look into figuring out why my approach didn’t work. But I’m also lazy, so if you’re going to just write a new app that does everything mine did but better I’m more than happy to just point people at that 
Aha, better is subjective
The main reason I started playing around was the MQTT connection issues.
As a side note, to get polling working you need to set the gpio7 and 8 edge files from none to both. You can simple write “both” to the files and the value files will be pollable.
I haven’t looked into getting sensor data by polling, but I’ll probably end up using the same methodology as your solution.
@jimpastos - great initiative! I’ve been considering writing a native Android app to replicate the functionality of Wink-handler because I can’t solve the disconnect issue. I think it’s down to the embedded-c library but C isn’t my thing so I’m at my limit in terms of debugging it. Happy to contribute testing or anything else you might need.
sorry possible stupid question (and never played with android before) how do you get the app after rooting the device on to the wink relay (got MQTT etc all set up in my environment, just cant figure this bit out. thanks
from your pc/mac:
adb connect <relay ip>
adb push <binary file> /sdcard/
adb shell <-- this will get you a shell to the wink
su <-- get root
mount -o rw,remount /system <-- mount read/rewrite
cp /sdcard/<binary> /system/bin/
...