Consider home setting and device tracker
See original GitHub issueDescribe the bug Not really sure if I would describe it as a bug 😃 I’ve been using bluetooth classic the last couple of months and was working fine except the times that the bt was off on our mobiles 😁 , so I decided to go over to BLE and tiles instead.
I started experimenting with a tile as a BLE tracker and the begining the results were disappointing. A lot of false not_home in the room presence sensor and sometimes for a long period.
After a little bit of googling I realised that tiles maybe was not the best choice but I made some changes in my configuration with the help of @mKeRix and finally I had less false_home in the sensor. The false not_home states in the sensor was between 0 (strangely 0, so i guess ms) to 7 seconds and I got like one or less per hour. It would be great to get rid of the too or to ignored them in some way.
After some more digging I saw that the mqtt device_tracker has exactly the same not_home as the sensor even if in my configuration I’m using consider_home with a value of 180 seconds. I read somewhere that can be a home assistant problem when using payload settings but that was not the case with or without payload settings I get the same not_home in my mqtt device_tracker.
Then I decide to give it a try with making my own fake device_tracker which with a binary_sensor and some automations I’m updating the device_tracker to home or not_home. Unfortunatelly the same thing. I don’t know if this is a home assistant limitation and the consider_home setting works only for local device trackers or something else.
But maybe a consider_home setting in room-assistant could solve the problem. And I think that timeout and consider_home should be different settings.
I forgot to mention that I even had some drops (about 30 min) in the mqtt device_tracker, meaning that stopped updating even if the sensor was still updating. I checked the logs in mqtt.fx and I couldn’t see any messages in room-assistant/device_tracker/ble-device_id-tracker/state
so it seems that room-assistant stopped publishing.
Relevant configuration My configuration right now is the following for the 3 nodes in the cluster
global:
instanceName: room 1 (room 2, room 3)
integrations:
- homeAssistant
- bluetoothLowEnergy
cluster:
networkInterface: eno1 (wlan0, wlan0)
port: 6425
weight: 15 (10, 5)
peerAddresses:
- '192.168.1.2:6425'
- '192.168.1.3.105:6425'
- '192.168.1.4:6425'
homeAssistant:
mqttUrl: 'mqtt://192.168.1.1:1883'
bluetoothLowEnergy:
timeout: 15
updateFrequency: 5
maxDistance: 15
whitelist:
- 1x2x3x4x5x6x
tagOverrides:
1x2x3x4x5x6x:
name: Keys
Environment
- Latest version of room-assistant, cluster of 3 nodes
- 2 nodes are NodeJS and the leader node of the cluster in HA Supervisor
- NodeJS in Raspberry Pi 3 and Raspberry Pi Zero W, HA Supervisor in NUC
Issue Analytics
- State:
- Created 3 years ago
- Comments:13 (4 by maintainers)
Top GitHub Comments
@cfpandrade The
debounce
option is a room-assistant specific one, so it needs to go in the room-assistant config. If you’re using ansible you would put it inhosts.yaml
.There is an example config in the docs, click the grey box titled “Example Config” in the Debounce section. Instead of
d6t_occupancy_count
you should use the ID of your device tracker - you can figure that one out by openinghttp://<your-room-assistant-ip>:6415/entities
in your browser and then looking for the device tracker entry and its id.There hasn’t been any activity on this issue recently. In an effort to provide a better overview of current issues we automatically clean some of the old ones. Many of them may already be resolved in newer versions of room-assistant. This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.