Cool project. I tried using the HASSIO addon, and the Bluetooth Low Energy option, seems more effective than Bluetooth Classic for me (I was getting HCI0 errors). That said, it appears my setup is unable to produce stable results. I am running Linux Mint VM, with Home Assistant with Supervisor installed. I am using a Plugable BLE USB dongle - which truthfully hasn’t been that stable so maybe that’s the cause of the problem. On my phone, I’m running Beacon Scope to mimic an iBeacon. The MQTT state will alternate between Home and Not Home every 30 seconds. Any idea what is causing this behavior even though I haven’t left the room? If it’s the USB dongle, does anyone have any recommendations? Thanks.
Have you tried increasing the advertisement rate in Beacon Scope (if that’s possible) or increasing the timeout of the BLE integration in room-assistant? The latter should even help if your dongle is just acting up a bit, provided that you can live with a slight delay in the switch to not_home. Maybe try 30s or 60s.
To debug this you could also run hcitool lescan on the machine to see what it receives on the system level.
Thank you for your thoughtful suggestions @mKeRix. I think the issue is, if I get a false capture in MQTT (not_home) even though the device is home, then it may trigger automations (eg security system).
I think the adapter is problematic in linux though. I couldn’t run “hcitool lescan” - as I was getting “Set scan parameters failed”. However, Google pointed me to sudo hciconfig hci0 reset. Then I ran sudo hcitool lescan, and I can see a bunch of MAC addresses of different devices. Many of the mac addresses are repeated. Conversely, the scan seemed to be hung after 20 secs.
Cheers,
J
I’m excited to try this out. I’m planning on using raspberry pi zero w’s for the bluetooth hubs. Can I use any motor sensor I have in HA, or does it have have to be a sensor hooked up to a linux board like the pi?
Is there a way to force a manual scan?
Use Case:
room-assistant shows a not_home and it has been in said state for 5 minutes. An automation is triggered to turn off a light but before doing so it would be nice to be able to force a manual scan. If the manual scan still says not_home then turn off the light. Otherwise, do not turn off the light.
It would also be nice if a tracker (e.g. rpi0w) can force another tracker to do a manual scan. That way if the bedroom rpi says not_home (not in the bedroom) then force the other rpis to scan. If the kitchen rpi says home (in the kitchen) then that is the current location of the bluetooth device. If all trackers says not_home then the bluetooth device is currently out of range and thus not_home.
I am trying to use our Letscom smart watches to turn on lights as we come into rooms after dark. I have made a lot of progress, however I am having some issues as well. Could anyone please review my setup and tell me why the state of the watches is true/false instead of home/not_home? Thanks in advance!
Home Assistant config.yaml
device_tracker:
- platform: mqtt
devices:
smart_watch: 'room-assistant/device_tracker/ble-MACADDRESS-tracker/state'
id107_ble: 'room-assistant/device_tracker/ble-MACADDRESS-tracker/state'
payload_home: 'home'
payload_not_home: 'not home'
source_type: bluetooth_le
This is my Room Assistant configuration
global:
instanceName: basement
integrations:
- homeAssistant
- bluetoothLowEnergy
homeAssistant:
mqttUrl: 'mqtt://xxx.xxx.xxx.xxx:1883'
mqttOptions:
username: XXXXXXXXX
password: XXXXXXXXX
bluetoothLowEnergy:
processIBeacon: true
maxDistance: 4
timeout: 5
updateFrequency: 0
whitelist:
- MACADDRESS1
- MACADDRESS2
tagOverrides:
MACADDRESS1:
name: Smart Watch
MACADDRESS2:
name: ID107
Could you elaborate what you mean by motor sensor or more specifically, what you’re trying to achieve?
It’s not currently possible, but I’m open for adding something like this. Would be great if you could open a feature request on GitHub for this. One thing to keep in mind is that for Bluetooth Classic only one instance of room-assistant should query a device at a time, as the readings are unreliable otherwise. Alternatively you could do a “power scan” sorted by previously closest distance maybe, which just cycles through the instances quickly.
Your room-assistant config looks good, for the device trackers in Home Assistant could you adjust the payload settings to 'true' and 'false' as shown in the docs? These values tell Home Assistant what it should convert to the corresponding device tracker state.
1 Like
Yes, I will submit a feature request on GitHub. Thank you.
I’m wondering why I’m getting state changes in HA with room-assistant when the state hasn’t changed. From my understanding this shouldn’t really be happening, right? A state change should onyl occur when old_state != new_state, but this is what I see in the logbook and NodeRed triggers every time there is an update. I can work around it by actually checking old against new state, but I think it would be better to only have state changes, when, you know, the state actually changes.
I searched on github for this issue, but couldn’t find anything. Any ideas why this is happening?
For the most part room-assistant will only send messages to MQTT when something changes, it also sends the current state of all entities to MQTT whenever the leader changes though (to make sure the state is up-to-date). I believe that this is what you might be seeing here. I thought that Home Assistant also filters these state updates, but I guess I misunderstood that part. For Node-RED I usually check the “output only on state change” box of the events: state node, which may be why I never noticed this before.
Maybe check your leader sensors In Home Assistant to see if there are a lot of changes happening. If that’s the case you could play around with some of the cluster options to stabilize that a bit more.
Hi!
This looks really promising! I set it up for my Raspberry Pi 4, already running Home Assistant. Tracking my Mi Band 4, it looks like this. Has anyone made any progress on having it not switching this often between home/away?
These are my setup configurations:
global:
instanceName: apartment
integrations:
- bluetoothLowEnergy
- homeAssistant
bluetoothLowEnergy:
whitelist:
- [MAC ADDRESS]
device_tracker:
- platform: mqtt
devices:
molles_mi_band: 'room-assistant/device_tracker/ble-[MAC ADDRESS]-tracker/state'
payload_home: 'true'
payload_not_home: 'false'
source_type: bluetooth_le
Two suggestions that might help you filter out the false negatives:
- increase the
timeoutin your room-assistantbluetoothLowEnergysettings - if that doesn’t help enough you can also take a look at entity behaviors, which allow you to debounce entities or pull states from a rolling window average
Nice work, @mKeRix!! I got this successfully working in two raspberries Pi 3b, an OrangePi Zero with armbian, and a Bluetooth USB adapter, impressive work.
I’m unable, though, to get the raspberry pi 3b on which Homeassistant is running to produce any readings whatsoever. I suspect that this may be due to the fact that the hci adapter is somehow clogged up, but I don’t want to reset the board, as there is no access to hciconfig via HomeassistantOS.
What does troubles me is that all the five devices at home, I can only connect to two of them: A ZTE mobile phone and my Huawei P20 Pro. For the Fitbit Versa, TicWatch Pro and Motorola Fusion One there is no way I can get any readings at all, once the connection request. Any ideas would be very welcome, and thanks again!
For the Home Assistant OS problem there is a thread here that may contain some helpful information: https://github.com/mKeRix/room-assistant/issues/314. In the SSH add-on you have access to bluetoothctl, which you can use to show the adapter state and reset it if needed.
As for tracking your other devices: every device behaves differently, so it’s a bit hard to give general advice. Some things you can try to get BT Classic working:
- try to pair your device to some BT peripheral like headphones once if possible and not already done before (for e.g. the Apple Watch this makes it allow incoming connections)
- verify that you are using the Bluetooth MAC and not the WiFi MAC - these are different, but sometimes very close together
- check if you can detect the device while the Bluetooth menu is open in the settings of the device
- some smart watches are only detectable when not currently connected to a phone
For the Motorola Fusion One you could also try the bluetoothLowEnergy integration as an alternative. For Android phones there are apps available that broadcast iBeacon data in the background, which can be detected by that. These apps unfortunately do not work on WearOS yet. You can run both Bluetooth integrations in parallel with the latest room-assistant versions.
Thanks for the reply. The ssh command worked. Unfortunately, when enabling the BLE plugin it seems that it ceased to detect the classic Bluetooth phones that it used to detect before, and the situation hasn’t changed for the devices I was trying to detect in the first place, both the Motorola and the smartwatches. It seems that this won’t be the solution for my use case.
Thanks a lot again!
Using this together with Bluetooth Classicon the same adapter works, but will slightly degrade the performance. If you encounter issues you can try to run to run the integrations from different HCI devices.
So it’s best to stick with either Classic or BLE or use an extra RPIW.
Is it possible to run Room Assistant over TLS? Specifically I want to run it on port 8883. I keep on getting “error - HomeAssistantService: read ECONNRESET” when I start room assistant.