I assume you have the Network binding installed.
You might find some resources to help get you started with generic concepts in openHAB in How to get started (there is no step-by-step tutorial).
thanks boss, will dig into that now. As always thanks for the help. 
It works with their controller. And since the controller is software which can be installed on a Rpi, NAS or even windows, it will work fine without any Gateway.
I have been using the method in this thread
Admittedly, I live alone but the premise could easily work with more then one person, although the rules would become more complex. I also agree with Rich that setting static IPs for the phone is simple and works with the network binding well
Hi Willie, I can do the OH side.
I wrote my own Arduino code last night which is a lot smarter than the one on github as it takes samples of RSSI signal strength and then takes an average rather than one offs due to the nature of signal strength not always being exact even when the WiFi client is in the same location, so it takes an initial baseline when starts up (based on samples over 5 seconds) then continuously takes an average based on the samples again and compares to the baseline to determine if it’s “home” or “away”. Problem I’m having is I think I have too many global variables and am running out of memory space on the stack because everything works, except when I call my “publishmqttmessage” function it works but when it returns to the loop the global variables the values are either lost or completely different.
I’ll post code in a new thread here once I have it working.
EDIT: Sorted code, issue was char array for MQTT topic not being defined large enough. Initial tests look good, it updated to indicate my Ford Ranger was AWAY when I left home. Still need to do more testing, uses combo of state (via RSSI strength) and status (via LWT) plus rules to determine likelihood of HOME or AWAY. Will post code tomorrow.
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…
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
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