Feature Request: Longer unavailability timeout

[HenryLoenwind]

My mug's data go into "unavailable" quite often, as I'm usually at the edge of my Bluetooth range with it, and the coffee maker is even further out. However, this makes automating anything based on a state change next to impossible as half the time the state change is to or from "unavailable". On my first try, it turned the coffee maker off in the middle of making a cup of coffee (unavailable->empty); on the second try, it wouldn't turn off at all as it went "Heating->unavailable->Empty".

As such, I'd request a setting to keep the state for a longer time—either a configurable timeout or a toggle to keep the cached state (as this is primarily an issue for the enumeration) even if the device goes unavailable. I'd much prefer the state update to be delayed due to bad reception over not being able to trigger from it.

The latter could even be the default; as long as there's one property that goes to "unavailable", people could still use their travel mug as a beacon.

PS: Same for "Power" to automate "Charging->Unplugged => Turn on Coffee Maker".

Edit: Note that adding more Bluetooth proxies wouldn't help me as the mug is paired to one that cannot cover my kitchen and living room. For a non-paired BLE device, this certainly would work, but sadly, not for the Ember Mug.

[sopelj]

Hi! I understand how that would be an issue and I will look into this, but I'm not sure it's a real solution, but simply a workaround to poor signal strength. You will likely get fairly unreliable results even if we fake staying connected for longer. For example it might skip over a state and go straight from Off to Heating or something.

I'm curious about why proxies would not help. It is possible to pair the mug with multiple proxies, but might need pair them individually. You can do this by turning off other proxies and putting the mug into pairing mode. Why would proxies not help with the mug?

[HenryLoenwind]

About multiple proxies, to my understanding, the mug will only pair to one of them. I mean, it's in the name, a "pair" are two. It's fairly rare that any BT client device can pair to multiple controllers; there are some speaker-type devices that can do that and even those are usually limited to 2 or 4 hosts.

On the other hand, I can test that easily. (I'd say "give me a sec", but that doesn't work while writing a post... ;) )

Ok, at first, it seemed my assumption was right. I pulled the proxy I knew I had paired it with after I had put the proxy I had paired it with second to last in range. It went into "unavailable", as I expected. However, then the doorbell rang and a package with more ESP32s arrived (pure coincidence, I hope...). When I came back, it was online again. I tested some more and found that it takes between 2 and 3 minutes of "unavailable" until it reconnects to another proxy. Reconnecting to the same proxy after being out of range only takes a couple of seconds.

So, adding more proxies doesn't help with automation, but it would extend the area the mug can be used in as long as it stays within one proxy's range.

(Side rant: Bluetooth is such an annoying technology. That unobstructed-10-metre range is so useless. Sure, it is better than the IrDA's range of 0.2 metres "line-of-sight while not in direct sunlight", but they could have upped it in any of the newer specs...)

[sopelj]

It depends on the device. "Pairing" establishes a link and trust level between two devices and allows for future connections and is not limited to a single device unless the device is. Bluetooth proxies support up to 4 active connections. As for the mug, we have no way of knowing as its undocumented and closed source, however, it seems to remember at least a few paired as you can switch between home assistant and your phone for example and if you don't disable your phone fight with home assistant and cause connection issues. That is why it's mentioned in the docs.

I'm not sure I follow. If you can extend the range, how does this not help with the issue? If it is within range and with a good signal you should not get unavailable. It may indeed take a moment to switch between devices. It probably depends on the overlap. If there is a zone where the first proxy is still connected slightly, it might maintain that weak connection it may either keep that weak connection or alternate between the two proxies. You might want to lower the strength of the proxies to make the switch more obvious.

(I agree, Bluetooth quite frustrating to work with. It's not for nothing like 80% of the issues I get here are connection issues...)

[HenryLoenwind]

This is from my test. I put two paired proxies within arm's reach of the mug, then pulled the power plug out of the proxy it was connected to. It took about 2 minutes for the mug to decide that I couldn't talk to one proxy anymore and would connect to the other one. Then, I powered the first proxy again and pulled the power from the second one. Again, two minutes until the mug switched over. And those gaps show in HA as "unavailable".

For the temperature, those gaps are of no concern; triggering on temperature still works when there's a gap and it suddenly jumps up/down. For triggering on state changes, things become an issue as HA sees, for example, "unplugged->unavailable->unplugged" as 2 valid changes and would trigger on those.

I've now dialled in my automation for turning on and off the coffee maker finely enough that it works, but that took a whole couple of extra triggers to account for those extra state changes. And it really only works because turning it on or off twice in a row doesn't matter.

I understand this boils down to a core HA issue, as treating "no idea what the current value is" as a valid value in the state change triggering logic is a fundamental design decision in HA. Still, it can be alleviated by keeping the state up during the expected timespan it takes for a good connection switchover, especially when the information on the connection loss is still available, e.g., by looking if the current temperature is "unavailable". (It would be so much nicer if HA kept the last known value for states and just made "unavailable" a property of it, but we won't ever get that. Funnily enough, the Inkbird temperature sensor has the opposite problem. The only way to know if that one is offline is to look at the last_change timestamp, as the integration keeps the last value indefinitely.)