Bermuda - Bluetooth/BLE Room Presence and tracking [custom integration]

Share your Projects! Custom Integrations
122

Lots of ways to do this. You could tie your home assistant instances together via GitHub - custom-components/remote_homeassistant: Links multiple home-assistant instances together and then use all the entities however you like on your main instance. My main purpose for Bermuda is tracking the dogs as well. In my case, I’m mainly looking for inside vs outside. I do have a couple of proxies out on the deck though, which is technically outside, and the yard is big enough for them to get out of range of any receiver. So in my case, the built-in “home/away” logic would not depict the states I’m lookinf for. So I created secondary device trackers and set their states via automation, based on what proxies are picking them up. You could do the same and set the states however you want. My automation code is below.

alias: Presence - dog location updates for device_tracker
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.maizey_ble_area
    id: MaizeyLocationUpdate
  - platform: state
    entity_id:
      - sensor.river_ble_area
    id: RiverLocationUpdate
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - MaizeyLocationUpdate
        sequence:
          - if:
              - condition: state
                entity_id: sensor.maizey_ble_area
                state:
                  - unknown
                  - Deck
                  - Dog Door Outside
            then:
              - service: device_tracker.see
                data:
                  dev_id: maizeytracker
                  location_name: not_home
            else:
              - service: device_tracker.see
                data:
                  dev_id: maizeytracker
                  location_name: home
      - conditions:
          - condition: trigger
            id:
              - RiverLocationUpdate
        sequence:
          - if:
              - condition: state
                entity_id: sensor.river_ble_area
                state:
                  - unknown
                  - Deck
                  - Dog Door Outside
            then:
              - service: device_tracker.see
                data:
                  dev_id: rivertracker
                  location_name: not_home
            else:
              - service: device_tracker.see
                data:
                  dev_id: rivertracker
                  location_name: home
mode: parallel
max: 10
2 Likes
123

Nice. I have to run the gamut of testing I would guess.
I already use Remote Home Assistant also so I get that part.
Home Assistant Gate + Reolink + HA → Notifications for cars/humans (bike riders)
Home Assistant Winery + Alexa → Webhook that you can open the gate

Just need to track those pesky dogs right now only for gate or winery. In between there is nothing, 1/2 mile of mountainside. Unless I do something in between in a few steps with solar charging and batteries.

124

Your mind-map of how it works looks pretty sound. You can use the device_tracker entities as you describe which give you home/away, or you could use the “Area” sensors which effectively tell you which proxy is hearing them.

Since you have just two proxies planned for now, and a big distance between them, it won’t matter which way you go. But if you decide to deploy a few more proxies (say, one in a back yard, or equipment shed, or some inside the house) then using the “Area” sensor will be much more flexible and informative.

Bear in mind that the option for Devtracker Timeout will delay the “departed” area from switching to “away”, so keep that in mind before concluding you have half a dog at each location! :rofl:

125

Has anyone managed to get Bermuda to track a Samsung Galaxy Watch 6? It’s connected to my phone via the Samsung Wearables app rather than WearOS app and I have no idea how to enable a BLE transmitter on it. I have my phone tracked but I often leave that lying around the house so my watch would be far more useful to track.

126

Haha I just saw your comment at the end of a thread when I went a-googling for context :slight_smile: I am not sure the OP wasn’t a bit confused between the watch’s ibeacon and what they were reading about the companion app’s ibeacon, but if the watch can send iBeacon adverts then it should work with Bermuda.

Even if it can’t send iBeacon adverts, as long as it’s advertiseming something (on a static MAC address) then Bermuda should be able to use it.

If it uses a resolvable non-static MAC, it should (in theory) be possible to obtain the IRK through pairing, and then the Private BLE Device integration can spot it, and Bermuda will use that.

Have you tried the Beacon Maker app? Beacon Maker - Apps on Galaxy Store No idea if it’s fit-for-purpose or not.

Some BLE devices also only send their normal discovery adverts when they are not otherwise connected. The nrfconnect app can be really helpful for seeing what’s happening over the air so you can know which end to blame.

I know this isn’t directly relevant to your question, I’m just info-dumping in case it helps when you’re troubleshooting!

127

Thanks for the info, I’ll look into those options and see what I can do. I’ll report back once I get an answer, good or bad. Cheers mate.

128

Install the HA companion app on your watch. Go to settings, sensors, and enable the ble transmitter. I have one, works a treat.
1000085187

2 Likes
129

Now that I think about, I did have to set the transmit power to high before it ever showed up on any of my proxies. It’s worked great ever since, but that can only be done via service call. I believe you can turn on/off all the sensors through the mobile device integration in HA, which is probably easier than doing it on the watch.

service: notify.mobile_app_galaxy_watch6_classic_npbm
data:
  message: command_ble_transmitter
  data:
    command: ble_set_transmit_power
    ble_transmit: ble_transmit_high
130

Thanks for this. I did have it installed on the watch already but just discovered it wasn’t up to date. Updating now.

Hopefully I can also set the BLE beacon to only be on while I’m at home, like I do on my phone.

I tried a test message to me phone last week with a similar service call to your example but nothing came through so I need to figure out what is going on there.

EDIT: looks like my previous issue was that I’d never actually opened the HA app on my watch (Its new, only a few weeks old) and only ever dealt with HA notifications that came through. Looking forward to testing things when I get home!

EDIT 2: I just created an automation to control the watch BLE transmitter based on me being home or not so now I REALLY want to get home and test this out. I need to setup more Bluetooth proxies…

2 Likes
131

I have enabled the BLE transmitter on my watch but it’s MAC address still doesn’t show up in the Bermuda Config dialogue. (based on the apparent watch MAC address as listed in the Watch settings and also the Samsung Wearable app on my phone)

Any tips for this?

132

I downloaded “BLE Scanner” on my phone and was able to find my watch in the list on that app. With that info, I was able to find the watch in Bermuda. It was listed in the Bermuda device list as Ibeacon and then it’s UUID which I got from the BLE Scanner app. Once configured in Bermuda, I changed the device name. Here’s a link to the ble scanner app and a screenshot of what my watch looks like in the app. Once you get the UUID for the watch, just search for the first few characters in the Bermuda device list and you should be able to find it. If you can’t see your watch in BLE Scanner for some reason, then you’ve got an issue with the transmitter and none of your proxies will find it either. This is the process I use for adding any device in Bermuda, unless it’s just immediately obvious in the drop down list.

1000085231
10000852311920×683 57.7 KB

1 Like
133

Awesome! Thank you, found it and got it configured. Much appreciated mate

134

Not sure what just happened but my HA crashed and restarted itself… the last thing in the log before the crash was:

2024-05-22 07:24:38.342 WARNING (MainThread) [custom_components.bermuda] No area name or no area id updating scanner hci0 (38:00:25:80:0B:A5), area_id None (331 previous messages suppressed)
2024-05-22 07:24:38.357 WARNING (MainThread) [custom_components.bermuda] Could not discern area from scanner hci0 (38:00:25:80:0B:A5): None.Please assign an area then reload this integration- Bermuda can't really work without it. (13359 previous messages suppressed)

It may be completely unrelated to the crash but either way I guess this is something I need to address…

EDIT: looks like I simply must have a Bluetooth Proxy with no area somewhere. Easy fix once I figure out which one it is. (turns out it was the server bluetooth)

Maybe the crash was unrelated…

135

The log messages are unlikely to be related to the crash, they are “normal” when a scanner doesn’t have an area assigned to it (as you worked out).

HA 2024.5 seems much more sensitive to async issues, so it’s possible that it was bermuda or any other (particularly non-core) integration that might have caused the restart. There’s a new debug option that can be added to the homeassistant section of configuration.yaml which might give more info if it happens again. I think bdraco mentioned it adds about 1% of performance overhead.

I’m interested in your experience with adding the watch once you got the beacon transmitting. Was it ultimately listed in the first few options with “iBeacon” prefixed?

I was a bit unsure about how I decided to list devices in the current version, I went with:

  • ibeacons first (but without mac address noted)
  • static MAC addresses
  • random MAC addresses

So if you were looking through the list for the MAC address I can see why it would have been hard to find!

I’m thinking perhaps part of the problem is that I don’t include the (current) MAC address on the iBeacon entry, so if you typed part of the MAC to filter the results you wouldn’t see the beacon in the list. I’ll fix that in the next release, hopefully the longer device name won’t cause issues with narrow screens.

I think it’s an ok way to go but for that issue…

Here you can see an iBeacon at the top of the list, but doesn’t have the MAC on it.
image

Scrolling down finds the current MAC of the beacon, which might be static (as in this case) or random. If it’s random, selecting this entry will only work until the MAC gets rotated.
image

Typing part of the MAC address to filter the results shows only the by-mac-address entry, and not the actual iBeacon entry which is the one you’d want. I’ll fix that.
image

136

I do actually have that enabled. Before the Bermuda related log entry there is a bunch of stuff relating to ZigBee, with ‘async’ stuff in it so that may indeed have bene the root cause.

I have the watch now being tracked. I had checked the entire list for the apparent MAC of the watch but it definitely wasn’t there. The one provided for the watch as per the app that sdholden28 mentioned gave me a different MAC address, one which was in the Bermuda list… I take it that the watch MAC is different to the iBeacon MAC?

ok, yeah, this is what I was thinking (sorry, replying as I read your post!)

I will have to check which one I used last night (I think it may have been the random MAC) as I potentially selected the wrong entry, thanks for the heads-up.

137

Awesome, that all sounds good.

The on-broadcast-at-home automation sounds super schmick, too!

Hmmm… I wonder if one could set it up to trigger based on a neighbour’s wifi or a GPS-bounded zone, so the phone enables the watch’s beacon a block away or something, which would give you a quicker “at home” response on arrival (since the automation will otherwise have to wait for your phone to connect to wifi etc before it can trigger “home”).

138

I set up the below automation to control the watch BLE transmitter based on a few things. Home / Away and also my house alarm since I see no point in the BLE transmitter being on while I’m sleeping.

Automation 
alias: Daves watch BLE transmitter control
description: on and off based on being home or not
trigger:
  - platform: state
    entity_id:
      - person.dave
    to: home
    id: home
  - platform: state
    entity_id:
      - person.dave
    to: not_home
    for:
      hours: 0
      minutes: 0
      seconds: 55
    id: away
  - platform: state
    entity_id:
      - person.dave
      - alarm_control_panel.house
    to: home
    for:
      hours: 0
      minutes: 0
      seconds: 30
    id: alarm_home
  - platform: state
    entity_id:
      - alarm_control_panel.house
    to: disarmed
    for:
      hours: 0
      minutes: 0
      seconds: 30
    id: alarm_disarmed
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - home
        sequence:
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: turn_on
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: ble_set_transmit_power
                ble_transmit: ble_transmit_high
      - conditions:
          - condition: trigger
            id:
              - away
        sequence:
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: turn_off
      - conditions:
          - condition: and
            conditions:
              - condition: trigger
                id:
                  - alarm_home
              - condition: state
                entity_id: person.dave
                state: home
        sequence:
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: turn_off
      - conditions:
          - condition: and
            conditions:
              - condition: trigger
                id:
                  - alarm_disarmed
              - condition: state
                entity_id: person.dave
                state: home
        sequence:
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: turn_on
          - service: notify.mobile_app_daves_galaxy_watch
            data:
              message: command_ble_transmitter
              data:
                command: ble_set_transmit_power
                ble_transmit: ble_transmit_high
mode: single

For this the above automation could be modified to use a Zone placed wide around the house. To begin with my plan with Bermuda is to replicate what I saw on a YouTube video about having dynamic dashboard cards based on what room I’m in. My general home / away status currently works really well based on Zone and wifi connection. I actually use the Proximity integration to trigger automations based on me approaching the house irrespective of Zone or wifi which also works really well (disarms alarm and opens the garage door as I come up the street)

1 Like
139

How close is too close between BLE proxies…? I’m finding that my phone seems to jump between the one only 1m away and others in nearby rooms that are on the other side of brick walls and/or 4m away…

It also goes to ‘unknown’ for quite long periods in-between.

140

:person_shrugging: I don’t think they can be “too close”, however 2.4GHz is well and truly into the dark arts area of RF propagation, so line-of-sight I’d expect anything under 2.5m or so you could expect random hopping between them because of reflections etc. But 2 metres or more, with a wall I’d expect should be pretty stable, purely on signal range, anyway.

What you might be seeing is less signal strength and more temporal - if a proxy doesn’t report in for a few seconds and a more distant one does, the odds of the device popping over to the other side go up. There is filtering to reduce this so it would normally take quite some seconds to happen (effectively a close proxy that goes quiet should still “win” for a while, but if another proxy reports a closer measurement than the older one did we jump immediately). Also if a close proxy reports a distant measurement which implies rapid movement, we either ignore it or we filter it to gradually increase the range to that measurement over time.

I suspect (because other Shelly users have reported it, too) that your proxies might be not reporting in for some time (someone else had 70 second gaps in theirs!).

If you call the bermuda.dump_devices service you’ll get a dump of Bermuda’s internal state. It’s a list of every “device” seen, its attributes, and a tree containing data from every scanner that has “seen” it. That tree contains per-scanner(proxy) histories, the one called hist_interval tells us the interval between each received update for that proxy/device combination - most recent first. (tip: use the “fill example data” button to see how to limit the export to a few addresses, will make looking for things much easier).

So for a given thermometer, my main studio proxy has:

      hist_interval:
        - 59.845819782000035
        - 30.15393078204943
        - 40.07791629899293
        - 12.498973899986595
        - 12.501973896985874
        - 10.005979107983876
        - 9.953979222045746
        - 2.558994658989832
        - 12.385974148986861
        - 5.119989314000122

Which is truly terrible - hopefully that device is at the other end of the house, because this says I am only getting updates for it on that proxy very sporadically - nearly a minute between the last and second-last, 30s before that and so on.

Oh… I just checked and the distance on that thing is only 2.9m or so - I should be getting much better intervals than that! Around 2 to 4 seconds is “typically ok” (but still disappointing).

If I look at the device entry for my “development watch” which just hangs out on my desk, and check the stats for prox-studio on that, I see a distance of 5 to 6m, and the hist_interval is:

hist_interval:
        - 0.8139985819580033
        - 2.7419952219934203
        - 0.4239992620423436
        - 0.8269985590013675
        - 2.120996303972788
        - 0.9479983490309678
        - 0.9299983789678663
        - 2.0489964309963398
        - 1.0239982150378637
        - 3.778993413958233

This shows that the proxy is actually working fine, as we’re getting 1 to 2s between adverts (we only check every second, so that’s sort of our min resolution). So that means the thermometer is probably reporting at weird intervals (quite likely, it almost certainly has a flat battery in it, so maybe it’s booting any time a stray neutrino pushes a spare electron out, then dies again).

If you take a look at your hist_interval’s and compare between devices vs between scanners it might give you some insights. @lazmo88 had some issues with their Shellys, you can see the hist_interval in my comment at Bermuda - Bluetooth/BLE Room Presence and tracking [custom integration] - #95 by agittins - good-looking ~3s intervals but with over minute-long gaps every ~10s or so!

These sort of gaps will cause the device to “jump” over to the next-nearest proxy, even if it’s quite far away. And if there isn’t a next-nearest proxy, it will go “unavailable” instead. For the unavailable state, you can increase the devtracker timeout setting in the bermuda global options, it will leave the device in the last-known area for the same timeout in the absence of any competing measurement.(Edit: incorrect. the current version uses a separate, hard-coded timeout of 30s. See my next post for more info).

It’s difficult to filter/tune these things out because one proxy suddenly not seeing a device and another one suddenly seeing it is an entirely valid situation when things move around, so it’s a case of balancing responsiveness/latency against stability. I personally lean toward reducing latency so that entering an area happens promptly.

You can then use the duration param in automations to delay acting on a change trigger until you’re happy to commit - for lights, you might want to trigger immediately since the risks are low, but for a trap-door you want to make sure they’re far enough down the hallway first, say.

3 Likes
141

Oops, mea culpa - the devtracker_timeout does NOT affect per-area distance/area calculations. It DOES affect the device_tracker sensor for Home/Away. @sparkydave and @lazmo88 this means I gave you a bum steer (translation: incorrect advice) on how to improve devices going “unknown”.

I’ve raised a ticket to dig into this problem, which includes a lot of navel-gazing / rambling about the root of the issue at Revisit DISTANCE_TIMEOUT for proxies that stop reporting adverts, and sudden departures. · Issue #206 · agittins/bermuda · GitHub

But the TL/DR is:

If your distance or area sensors go “Unknown” when a device is still close to a proxy, it (almost certainly?) means that either:

  • your max_radius is too low. I use 70 metres(!) for mine, since I want a device to show up somewhere if it’s still around. Also possible your calibration is way off, so don’t do that (put ref_power and attenuation back to their defaults). Unlikely to cause area-hopping.
  • OR your device really did stop transmitting. NRFConnect on your phone can really help diagnose this. This is unlikely to be the cause if devices are jumping between areas, though.
  • OR HA did not receive an advertisement from that proxy in at least 30 seconds - which is NotGood :tm: and probably indicates an issue with your proxy or its wifi connection. This will also cause area-hopping if you have other proxies.

You can use the devtracker_timeout config setting to make the device tracker entities less twitchy about setting devices to “Away”, but the current version doesn’t give you a lever to alter how the area and distance sensors behave. Ultimately though this is a proxy issue.

I’ll revisit the logic of that timeout (see ticket above), but in the meantime use the hist_interval info noted in my previous post to troubleshoot, and look into if your proxies are having issues like rebooting, running out of ram, non-default ble script, wifi connection troubles etc.

3 Likes