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
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)
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)
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.
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?
I was having similar issues with proximity and in my implementation I ended up using a configurable value for proximity, not delta (e.g 5000, as the original wink-handler did).
The proximity sensor on the device has actually 3 leds, each with its own proximity value. We only use the first one which seems to do a great job.
In addition I noticed we have access to Light sensors, both visible and IR.
I will be publishing my work to github soon (hopefully tonight EST, time permitting).
If anyone is interested in building/testing, I suggest peeps download the latest Android NDK
The only problem I found with setting an absolute value for the prox threshold (even a configurable one) is that the value reported by the prox seems to walk all over the place, steadily increasing or decreasing over time. Another user in this thread graphed it and thought it might be related to ambient temperature.
So my “relative” prox code was in part an attempt to compensate for that (the other part was to accommodate the fact that each relay seems to have a different resting prox value).
If you are going in this direction I’d suggest also an mqtt topic that reports the prox value to make it easy for users to figure out what the absolute value is to set the corresponding parameter.
Hey @jimpastos - got it compiled and installed, but it doesn’t seem to be connecting to my mqtt broker (Mosca). The mqtt_address parameter looks like this, is this correct?
tcp://192.168.88.10:1883
Any way for me to debug what’s going on?
Edit: Also, the screen is constantly on, if that’s a clue to anything (and the default of 5000 should be well above my prox sensor resting value).
Address looks good.
I think i should send a screen on event at start so the off timer kicks in. Test by touching the screen/press button or trigger proximity and wait 20 seconds.
You 100% sure it doesnt crash?
You can delete edisonwink and run it manually as root in adb shell.
I followed the directions for creating the build, and after some path issues (running windows 10 w/ cygwin) got the build to complete. Followed the rest of the instructions.
am start wont work as its not an Android app with activities.
You either replace /system/bin/edisonwink (first rm and then cp over and chmod 755) and reboot (this will run in the background on boot) or you can manually copy the binary in /system/bin/wink_manager and run (just type /system/bin/wink_manager) in the foreground to test. Just make sure you dont have multiple versions running
BTW the wink_manager build is 222kb in size. Does that sound right? I have never built form source so I don’t know what I am doing in that arena, but the build did produce a file…
Nothing is good, means its running.
Most of the logging is commented out so you wont see much but i believe paho has an environment variable you can set that will post more mqtt debug logs.
Type export MQTT_C_CLIENT_TRACE=ON before you run the app.
As for size 200k is mostly linking in C++ stuff and android NDK libs. We can probably look into reducing but not priority right now.
@lightmind as a side note, what happens when you press the top button when its running? Does the too relay switch on?
Also does your mqtt server show anything in its logs?
