I would like to have an counter for each battery. The counter should incrase if a communication cyclus is performed

[Karatzie]

Checklist

• [X] I have filled out the template to the best of my ability.
• [X] I have understood that this integration is only about battery management systems with Bluetooth Low Energy support.
• [X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• [X] This issue is not a duplicate of any previous feature requests.

Please describe the enhancement you would like to have.

I am suspicious about the Bluetooth communication with the RB Pi 4 and the Supervolt batteries.
To compare the number of data communications between the two batteries over the course of the day, a counter was set up in the Batmon-ha.
This counter was integrated into each cycle.
If the curves were the same throughout the day, everything was fine.
In my energy dashboard I also had an LED symbol for active data transmission.
The counter should be reset automatically at the end of the day.

Additional context

Here is a coure curve of the counter: At the moment I see a lot of gaps because the values are not changed. This is my energie dashboard. You can see the LED for the communication.

[patman15]

If data update was successful, sensors (except RSSI and link quality which have a different logic) are available, otherwise they switch to unavailable, the link quality sensor does what you are asking for. It shows you how many of the last 100 cycles (each 30s) have been successful.

[Karatzie]

Hi Patrick. I check your comment and saw that the link quality only updates if the value is changed. At the end, I add following in your code: This code forced a signal update without value changing. I have add an template helper by myself. {{ (as_timestamp(states.sensor.libatt14f6_batterie.last_changed)) }} This helper get the last chaged time of the battery value.

If this value is changed, the LED is switched on. I still observe some caps.

But it is better than before.

[Karatzie]

I have set the update_interval to your value 30 seconds. I saw still observe gabs.

[patman15]

I check your comment and saw that the link quality only updates if the value is changed.

I would disagree with that statement, why do you think so?

I have set the update_interval to your value 30 seconds.

I'm not clear, which update_interval you mean.

I saw still observe gabs.

I can't follow your intention. What are you trying to proof or what do you want to achieve? I remember you are using the internal BT of the RPi4, correct? This one is known to have it's limitations, so it is quite unlikely that you can achieve 100% availability. If you want to go there, you need to change the physical setup unless you have spotted a bug in the integration. Currently, I'm not aware of any tough.

[Karatzie]

Hi Patrick,

thank you for your response.

I am now using an ESP32 Bluetooth proxy.

When I look at the link quality, I see 100% and last updated 22 hours ago. There is no new trigger from this entity. It is possible that your integration sends an update to HA, but HA does not take the new value and the update information is not change.

I have set the UPDATE_INTERVAL: Final = 30 # [s] in the const.py to 15 seconds.

I don't want to prove anything.

I have had problems with the Bluetooth connection from the Raspberry Pi3 in the past. With the Raspberry Pi4 this has become even worse. But I need the Raspberry Pi 4 for ESPHome. I can no longer build FW with the RB Pi3. Your integration now offers Bluetooth proxy support.

In the battmon-ha a counter was integrated, which was increased by 1 with each Bluetooth query of the battery. This counter was reset each time the integration was started.

With the counter, a failure of the logic behind an interface is recognized immediately and there is no need to wait for the signals to time out. Frozen values can be recognized very quickly. There have been problems in the past when the counters have run out.

Just for your information: We uses these counters also for serial interfaces with our power plant control system. Here we can then switch to the redundant interface very quickly before the timeout is happen. In the system we had a timeout of 32 seconds.

I am now looking for a value from the battery that changes with every query via bluetooth in the Home Assistant. I would like to have this value as a trigger for my flashing LED in the energy overview. Unfortunately, there is no such value.

You can see here one gap over 45 seconds without an update of the update forced signal. It is possible, if no value from the battery is changed in a new bluetooth query, the send to HA code in youe integration will not perform. But that's just a guess on my part.

I can use your integration. The bluetooth connection is very good over a Bluetooth Proxy.

[patman15]

Ok, now I think I know your issue. Probably you are misinterpreting the name of the values (which also happend to me). HA uses it's own logic. Debatable, but I'm bound to it unless HA changes them:

• last_updated is not what you (most probably) think, see this post.
• This in consequence means, that as long as link_quality stays on the same value, i.e. 100% in your case, last_updated is the time it reached 100%.

So in consequence everything works fine if you see the 100%. Since you are looking for some proof that the sensor values are actually updated (which is in HA logic, that they are available), you can have a look at the logic in the code, or trust my short explanation below:

• HA calls the integration every 30s to update the sensor values
• The integration adds False to a shift register and queries the battery
• In case the battery returns (some) values the False is replaced by True. We can debate if the "some" should be "all", but in any case HA will care that the individual non-reported sensors switch to unavailable as no value is available to update.
• The link_quality sensor is always available and tells you how many of the last 100 calls to update the sensors where successful. (successful == at least one sensor as been reported, which is then available, others are not)
• So as soon as it deviates from 100% you lost a sample, the detection time is something around 0-90s given by the polling logic HA (default 30s) and the underlying BT stack (default ~60s) has.

I think the logic and reporting is very close to what you want if you consider the definitions correctly. Just to make it clear:

[!CAUTION] Neither Home Assistant nor this integration can be used for safety (ISO 26262) relevant operations! There are numerous issues with the Bluetooth code or dongles that can lead to stuck values that you cannot detect. So do not use the results for safety critical actions.

E.g. if the Bluetooth stack crashes and/or HA doesn't call the integration every 30s there is nothing the integration can do about it.

So long story short, in your case everything is fine, you can rely on the link_quality. If you think this not reliable enough, I would like you to think about the following case: "What if the BMS gets stuck and just continuously sends the same sensor values from some register although it's overheating?" The BMS is also not reliable itself ...

Hope that helps, enjoy your weekend, Patrick