Shelly Device configuration

Shelly devices (Gen2 and later) support acting as bluetooth proxies for HA. This means if you already have Shelly switches etc installed, you can get BLE location tracking essentially for free!

Setup

From John Munro's experience the configuration is pretty simple:

• In HA, Devices and Services, Shelly:
• On each device, click CONFIGURE
• For "Bluetooth scanner mode" choose Active and SUBMIT
  • You can choose Passive instead, but active mode will give you discovered device names more reliably.

(Image courtesy of JHM)

This should be all that's required to get your Shelly devices reporting bluetooth advertisements into Home Assistant!

Some caveats:

• My understanding is that the Shelly firmware will only update a given device's advertisement every three seconds, so you might find it slightly less responsive than an esphome device for tracking movement, including switching between areas. But it should be just as fast for the initial "arrival" indications, such as when you first arrive at home, or a device starts advertising.
• Shelly cautions against tightening the interval/window timings, but it seems likely one could experiment - just bear in mind if you lock up your shelly device it might be more difficult to recover if it's already behind plastering or wall-plates!

My advice is to just use the default script installed by the Shelly integration, and once you see any adverts showing up, leave it alone and examine the debug info in HA (using the dump_devices service in Bermuda is very helpful) to see what things are being reported and at what intervals.

Troubleshooting

Device tracker sensors switch to Away even though they haven't moved

The device_tracker sensor uses a timeout configured in Bermuda's global options called devtracker_timeout. The default is 30 seconds which is fairly short for a lot of purposes, and means that your device might be marked as away sooner than they should in the case where no advertisements are received.

This can happen if you don't have enough proxies to cover the places the device normally is, or if there are issues with advertisements not making it back to HA, due to proxy issues, wifi issues or the dog lying down on top of the tag, blocking the signal.

The quickest work-around for this is to increase the devtracker_timeout in Bermuda's global options:

Another option is to design your automations to wait until a device has remained as Away for a time period before proceeding, but in this case it's probably much better to fix the issue at the source, using the above setting and/or troubleshooting to see if you have a deeper issue.

There is a possible Shelly-specific issue some folk have encountered, where there are delays or "blackouts" of advertisements coming from their shelly devices for upwards of a minute. See the point below for more info.

Devices jump between areas even though they haven't moved

This is probably caused not by distance measurement differences, but by timing differences. If the nearest proxy doesn't report in for a while[^1], but another proxy does, Bermuda will assign the device to the more recently-updated area since it implies that the device left the previous area. It will do this immediately if the other proxy is reporting a distance closer than the previous proxy was, or after a length of time if the new proxy is reporting a more distant measurement.

[^1]: A while, in this context is currently 30 seconds. This is hard-coded in Bermuda as the DISTANCE_TIMEOUT. This is actively being looked at as an area for improvement.

The problem is we are balancing latency against stability, and ultimately that decision depends on the use-case. So Bermuda prefers to notify you of the area change ASAP (low-latency), and you can choose how quickly to respond to that.

Some folk are experiencing oddly long delays between advertisements being reported, often upwards of a minute! It is unclear yet if this is a firmware issue or if it's related to people using scripts other than the one installed by the HA Shelly integration, or if it's environmental like WiFi issues.

Please get in touch if you are having this issue, as I'd love to get to the bottom of it!

Workarounds

If this is causing issues with your automations, consider using the "duration" param of your trigger to delay the action for a time that is suitable for the given action.

So for lights, you might want no delay at all - this is because quick response is good, and a false positive is "cheap", relatively speaking.

But if you are automating a trap-door in your hallway, you might want a delay of a few seconds to ensure your favourite guest really is half-way down the hall before you trigger the yawning portal to their doom. This is because re-setting a trap-door is "expensive" in time terms, and it's always harder to get someone to re-enter the hallway after they've already seen the sharks.