Presence detection with low cost BLE devices and Raspberry Pi/Zero W

The timeout that returns ‘not_home’ and also an aspec of the update speed is in the mqtt_room settings and is quite low. I would be inclined to experiment with long timeouts or mqtt_room might need to be forked to deal with presence properly. The common thread I find with tracking and presence is that state is recorded on significant change and in this case it’s not handling a lack of significant change.

hi sfgreenwood,

would you be willing to share your settings of MQTT in Room Assistance and your settings of the MQTT_Room in Home Asisstance?

Thanks,
Regards,
Dieter

My settings are in my first post at the top of this topic :slight_smile:

As I say I think the issue would be with the away timeout, and my guess would be you could set it to a long period - say 8 -10 hours, as there should always be a change in that period, but you would have the last known location before you went to bed. The alternative would be to make the mqtt_room component not change to away when it no longer detects a beacon. I actually only noticed this when I was testing another presence system.

ah, correct :slightly_smiling_face:
I have the same settings of MQTT_Room in Home Assistance.

The Room Assistance however, I have set the “update_frequency” to 5000, as I understood from the documentation that this value is in milliseconds and I also read in above posts that some users had issues with overstacking the MQTT server with messages resulting in the server to crash.

Maybe I should try a value of 5 :slight_smile:

I think it must be five seconds, which probably isn’t necessary so I may increase it. Your use case may vary of course.
As for MQTT it may depend on how many things are accessing it and indeed whether you are using mosquitto or the native server in HA but I would rather suspect the buffer response may actually be the issue there, especially if it’s on a slowish SD card.

Interesting topic, I’ve also been looking at this recently and I think I’ll use some ESP32 as “sensor”.

They already include bluetooth and wifi, so with the right piece of code, they should be good to go without any soldering or other module.
And they cost only 6$ with no need for SD card, more availability than pi zero w, no sd corruption and lower power consumption.

I’ve order some ESP32 and can share my result once I got them if there is some interest (I plan to make them publish mqtt message for happy-bubbles).

3 Likes

Interesting, keep us posted by all means. I was thinking about devices like this and I think Happy Bubbles are based on the ESP32. I may have a look myself.

I got this working with an external mqtt, very strange when creating the user “roomassistant” and sharing the topic “#” and using the credentials for the created user i could not connect.

I could connect from room-assistant using the default username / password but no topics was pushed from “room-assistant” to my mqtt instance.

I then created a user with the same username / password as the default user and saw the messages populate into the console.

No, they are based on an ESP8266, a custom PCB and a Bluetooth module, thus making them more expensive to produce.

It’s a pity for the guy who created them, it was a beautiful product for small series.
But, it could now be replaced by of the shelf component (I say that but the bluetooth module is maybe not the same/not as good on the ESP32, we’ll see :slight_smile: )

4 Likes

Thanks for the update, I will investigate.

1 Like

Just a thought, mine started crashing after a day. Went back through the docs and realised I’ve got each room assistant client using the same MQTT login. Changed these so they now have an individual one each and its been working like a dream since.

I have all of them running on the MQTT Server with the same login.
So far no problems.

Are you running a private server or a cloudserver?
I am running HassIo and the Mosquitto add-on.

Same here, using the same credential on every mqtt client I have (probably more then 10 now), and never had a problem with that.

Of course the cliend ID must be unique, but not the credential.

Not yet easily, ble support of esp32 is not implemented into arduino ide

Ah sorry I thought you said yours was still crashing. I’m running mosquito locally.

@getsmokes, no this got resolved, very happy with how things working now :slight_smile:

Sweet. It would be good to see what type of automations everyones using this for so far.

I don’t have a whole lot of time this weekend to explain and post the code, but I already got it working (but not finalize).
You can see here some example of BLE usage in Arduino sketch for the ESP32:

And this library is already in the espressif official Arduino ESP32 repo:

Thanks for these infos, by got it working you mean that you are able to scan BLE devices with ESP32 and get their mac adresses and maybe more?

Yes, I get the most important and more :slight_smile:

That is the mac address and the RSSI that are needed for detection as well as (not always) the ManufacturerData, ServiceUUID and Name (not published to mqtt).

It’s only a very quick and dirty piece of code that still need a lot of improvement but you can already see it here:

I’ll for example certainly replace the MQTT library with another one as this one is giving me trouble, it lost connection after a while (I had the same phenomena on ESP8266 with the default PubSubClient).

Happy-Bubbles can treat the received mqtt message without problem:

I’ve just implemented the first type of message, no Eddystone beacons or iBeacons, I honestly don’t know the difference and don’t know how to separate one from another, I’ll also have to check into that.
https://www.happybubbles.tech/presence/docs/mqtt/

8 Likes