Presence Detection Seems Too Hard

Hi, I saw this and got the D1 Mini part to work, but haven’t managed to set up the OH part yet. From what I can see on FX-MQtt the D1 MINI broadcasts wifi strength and uptime in seconds. https://github.com/aderusha/MQTTCarPresence.

Would be great is someone can translate the HomeAssistant to OpenHab.

You mean the Home Assistant rules?

yes. I see the D1 MINI boot and connect to wifi in mere seconds, so that part works, but I have no idea what to config in OH. Is it a rule or a “thing” .
I mean once you have that working, I imagine turning on lights after dark and all kinds of stuff.

Ok thanks Rich, off to go reading…
thanks

That seems to relate to MQTT and I have not worked with that yet, Home Assistant does not separate things and items. They use entities which is sort of a combination.

The Home Assistant automation would be rules.

I assume you have the Network binding installed.

  1. Create Things, one for each of the devices you want to monitor for presence.
  2. Create the Group Item as described in the linked tutorial above
  3. Create Items and link the Item to the Channels on those Things. Add those Items to the Group created in 2.
  4. Copy the Rule linked to above to a .rules file.

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. :smile:

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.

1 Like

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 :slight_smile:

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 :slight_smile:

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? :wink:
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 :laughing:

Haha no good :grin: