Willie, give this a try. Note: It’s had minimal testing so far (only a few times driving in and out from home) but it’s worked each time. I will do more testing and update code when I’m not so busy at work… change the values at the top of the code to suit your own needs, I haven’t coded to allow for multiple vehicles yet, so consider beta version for testing…
2 Likes
The controller won’t work without a Ubiquiti access point though, unless i’m reading things wrong he has a Google router/AP
Ofocuse not, as it wouldnt make any sense using that binding without the controller (software) and at least one access point.
Having a read of the URL of the other Car presence for Home Assistant on github as posted above, I can see why he uses a Wemos D1 Mini Pro (the pro has more flash, but more importantly supports an external antenna) Because to gain more accuracy, we need more RSSI signal strength samples taken over a longer period of time, and the only way to gain more (wireless air) time is to achieve a further distance, and the only way to do that is to add a larger antenna to the client.
So as the vehicle begins to arrive home, the Wemos (with antenna) associates with your Wireless AP much earlier, and therefore the baseline that the code takes should have a relatively weak signal. As the car drives up your driveway and closer to your house, the signal gets stronger and therefore associates the car with arriving home. Conversely, if the car starts up from say your garage or driveway, the signal should be relatively strong (assuming your garage is near your house / access point) and gets weaker as you gradually leave home.
The MQTT LWT (last will and testament) - eg: “MQTT broker checks to see whether it has received regular polling messages from the Wemos, if yes (1 = alive) or no (0 = dead)” - this basically overrides the signal strength as determined in OpenHAB (but only for being at home). In other words, the vehicle.rules in OpenHAB will help iron out any discrepancies by comparing both LWT and whatever the Wemos predicts as to being “home” or “away”.
LWT = alive & RSSI = getting stronger, then (arriving) = HOME
LWT = alive & RSSI = getting weaker, then (leaving, but still) = HOME
LWT = dead & (last) RSSI = getting stronger, then = HOME
LWT = dead & (last) RSSI = getting weaker, then = AWAY
So only a weaker signal and LWT dead will generate an Away, which makes sense.
I’ve done more testing, and it still seems to work ok (except that when arriving home, the Wemos D1 Mini only just connects to Wifi about 2 seconds before I go to switch my ignition off, so it may not have a chance to even tell OpenHAB it’s home) so I’ve just ordered a Wemos D1 Mini Pro with aerial from Aliexpress to test further. The 3D printed case on the Home Assistant Car presence for the Wemos Pro is pretty cool, so might steal his STL and print one myself 
Will see how it goes when the Pro turns up…
Excellent, will look into it this weekend! Bit snowed under with work stuff now, but will find an hour or so to test. Sounds great, thanks.
Hope to give feedback by Monday latest.
Hello,
in another thread https://community.openhab.org/t/presence-open/38671/28 I posted my solution to presence detection. I use the keys to detect if the corresponding person or vehicle is at home or not. Maybe my approach can help you with your problem.
Greetings
1 Like
Its an awesome idea… But it means all people have to use a key with metal ring, and leave it hanging at the board. Not a big issue though…
Good idea, but as above means you physically need to place your keys on the holder, which means getting into good habits which is not something I’m particularly good at
It is perhaps a more fool proof solution, but it also has some limitations with regards to triggering certain rules, like automatically opening a garage door, automatically turning inside lights on when coming home at night etc. Detection via WiFi means these things can run before you actually get inside. It would be good to run in conjunction with WiFi though, I don’t think there will ever be a single solid method for presence detection.
Exactly, super cool idea but if I have to do something… is it really automation? 
Not that I don’t admire how it works and gives me some cool ideas but I have bent over backwards to do something ‘automatically’ that I could just push a button or flip a switch to do. Humans are dumb, we get tired, excited or rushed and forget stuff,not to mention sometimes actually trying to ‘fool’ the automation system
Pretend scenario:
Daughter sneaks out with boyfriend late, leave audio jack plugged in, parents think she is home 
Haha no good 
Real example:
When I moved in to my house, I took some time to update and tune up the security system. It had a bunch of dead batteries in sensors and missing keyfobs and things.
In doing that, I found a fun thing. For the door labelled “SONS BEDROOM”, someone (the son, presumably) had peeled the magnetic sensor off the door, and stuck it right to the reed switch next to the door. Suddenly, he could open that door without the alarm binging or going off! And his parents would never know.
So, yeah, people do things to avoid “automation” if they can.
Your life is MUCH harder if you assume you can’t trust your residents.
Willie, did you (or anyone else for that matter) get a chance to test the code on a Wemos D1 Mino Pro in your car? I assume someone must have one floating around. I’m still waiting for mine to turn up (from aliexpress, so a good week away still), so can’t test (with antenna) to see how well it functions. I’ll write a detailed instructable on how to setup once the better parts arrive.
Hi chimera,
Yes the code on the ESP works like a charm. 10 points for that. I can see via the flickering blue light what happens. I too ordered some ESP D1 Mini Pro’s from Banggood, but having shipping problems so it may be another two weeks before they arrive.
On the OH side it didn’t go to well. It is likely my fault/ignorance. I first tried to add the code to my config, that didn’t work as expected. I of course did substantial editing to replace your car make with my car make. (Maybe it will just be easier for me to buy a Ford Ranger 
)
I then removed the code again and tried to set it up as separate sitemap and that didn’t work either. I use MQTTv2 so I also tried to set it up in that manner but also no luck.
When I say it doesn’t work, I mean that the status doesn’t change it just shows a “-” line. I did see if I “flicked the switch” in Paper UI, the “-” changed to “Home”. But after a few days now of going in and out of the yard it hasn’t changed.
Unfortunatly I have assignments due next week, so I’m a bit hectic now. Will be able to give it my full attention after the 29th 
I also still want to implement the Presence Detection as mentioned by Rich in the post using Apple Watches and my son’s Dexcom to depict people being home as opposed to a certain car being home. Those are two different use cases I have.
Chat soonest.
My wife has a Dexcom too (G6). You might also be interested in NightScout openHAB Integration (you can set up Nightscout as a follower to CLARITY so you don’t have to use xDrip or Spike to populate it I think). And I can confirm, at least with the G4 (I haven’t tested this in a long time) that the receiver shows up really well using reelyActive and other BT scanners (there is a not yet accepted BT binding that would probably work too) as Dexcom didn’t bother to spoof the BT address for privacy.
I should see how it works with the G6. I can probably inspect the broadcasts and see they are coming from a G6 sensor and don’t even need to worry about the fact that a new sensor needs to be inserted every 10 days (longer if you are using xDrip) potentially changing the broadcast source address.
As for the Apple Watch, you will be able to see that an Apple watch is present, but not that a specific watch is present. Apple is pretty good about privacy in this respect so the watch spoofs it’s BT address, changing it every few minutes. There might be something in the message that can uniquely identify the watch though, I haven’t looked. My wife quit her iPhone and Apple Watch when she decided to move to xDrip and Nightscout and I prefer Android.
NOTE: While Dexcom does offer an API to get the readings from CLARITY, they delay the data by 30 minutes making it almost useless for driving home automation. You can see my experiments there at OAuth2 using just OH Rules and myopenhab.org.
Thanks for the info Rich. Will dissect it next week in more detail. Yea been following the NightScout and OpenAPS for a while. very interesting stuff. Thanks for your links as well. There are certainly some possibilities to look into. Last night as an example, he went really low, and neither my wife or my phones alerted us. (One was flat and one was on silent for some reason, silly little Apple switch). Would have been nice if the house could have turned on every single light known to man.
I was thinking of giving the Apple Watches static IP addresses and following them on Wifi rather than BT, but will see what works best. Thanks for all your comments and participation in the community. You have helped people more times that you will know
Right on Will!
Thanks Rich!
I forgot about WiFi on the watches. That should work pretty well. Good luck on the assignments! If you have any ideas for the diabetic stuff I’m more than willing to help out. I do think that this sort of thing is one of the hidden killer apps for home automation.
1 Like
Hi, sounds like you need to do more diagnosis from the OpenHAB/Moquitto side. From the CLI on your RPi (or whatever O/S you run OH / mosquitto on) can you run the following (or alter it to suit the topic if you changed it, the # is a wildcard)
mosquitto_sub -t openhab/vehicle/# -v
Watch the MQTT messages come in from the Wemos. From another CLI, tail your OpenHAB logs as the rules will output what’s happening also, eg:
tail -f /var/log/openhab2/openhab.log
(once everything is working ok, you can remove the logInfo() entries from the rules file if necessary)
1 Like
Someone told, to change the smartphone ip from dhcp to static. I did that and i changed the network thing from hostname “smartphone” to my new static ip. I did this in the router settings, smartphone is still in dhcp mode, but gets always the same ip from the router now.
But it still has the same behaviour.
In my router (fritzbox) i can see the phone online all the day. But with my openhab-network-binding it isn´t online some time later. The phone is still in the house, i think it switches to a deeper standby.
It is a android smartphone and wifi is set to “always on”, but that doesn´t help.
I can´t use the fritzbox binding, because i already use it for a second fritzbox and i only can configure it to work with one device.
So why told someone that static ip on the smartphone helped in this way?
(i´m on oh 2.5 latest snapshot)
1 Like
Did you also configure the Network binding Thing to use arping? arping is able to wake up the phone and will get a result from the phone (if it is present) even when the phone goes into a deep sleep and stops responding to pings.