Failed to initialize BMS

[7wells]

Hello!

I see a warning after every HA restart, but the readings seem to be ok.

Sorry that it's partly in German, despite I changed the language in several places to English. The BMS number shown below is partly redacted:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: custom_components/bms_ble/__init__.py:46
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 20:42:32 (1 Vorkommnisse)
Zuletzt protokolliert: 20:42:32

Failed to initialize BMS x6xx10xx6xx, continuing

Do you have an idea for the reason? Shall I simply ignore it, or is there something I should do about it? Shall I add some log file?

Thanks for your help! 👍

PS: The log file ends with this (number partly redacted):

[custom_components.bms_ble] Finished fetching x6xx10xx6xx data in 0.120 seconds (success: True)

[patman15]

Do you have an idea for the reason?

I'm aware of this issue, happens for me as well. I suspect it's an issue with the HA Bluetooth integration not being ready when bms_ble is started. This happens despite the fact that bms_ble has a dependency towards Bluetooth. Probably due to devices not yet being discovered/resolved. Only happens on complete HA restart, if you just restart bms_ble it does not occur.

Shall I simply ignore it, or is there something I should do about it? Shall I add some log file?

You can safely ignore it. If I'm really bored, I might dig into it at a later point in time. :sunglasses: You shouldn't see any impact except probably a bit delayed first measurements.

[7wells]

Thank you so much for your swift and kind explanation. Please don't waste your time on further digging into it. 😉

[7wells]

@patman15 Hi Patrick, Am I right assuming that the following warning is related?

Logger: homeassistant.helpers.template
Quelle: helpers/template.py:2651
Erstmals aufgetreten: 08:29:23 (8 Vorkommnisse)
Zuletzt protokolliert: 08:29:23

Template variable warning: None has no element 0 when rendering '{{ state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[0] }}'
Template variable warning: None has no element 1 when rendering '{{ state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[1] }}'
Template variable warning: None has no element 2 when rendering '{{ state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[2] }}'
Template variable warning: None has no element 3 when rendering '{{ state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[3] }}'

I understand that the template is a HA function, but maybe you have a bit time to provide a hint how to set up the template in a different way, so that it does not throw this warning if no values are yet available?

Thank you, and have a great weekend! 🌞

[patman15]

Am I right assuming that the following warning is related?

Not sure since I can see (8 Vorkommnisse). Did you restart that often? Or, which I suspect, do you have BT connection issue, i.e. battery is too far away? You could enable the RSSI sensor and monitor that value over a day or so.

The template can be fixed like this:

{{ iif(has_value("sensor.car_battery2_delta_voltage"), state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[0], "n/a")}}

That will show n/a when the value is not available and not throw an error.

Enjoy your weekend as well!

[7wells]

Only happens on complete HA restart, if you just restart bms_ble it does not occur.

It also happens when I reload the integration:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: custom_components/bms_ble/__init__.py:44
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 14:24:40 (1 Vorkommnisse)
Zuletzt protokolliert: 14:24:40

Failed to initialize BMS xxxxxxxxxxx, continuing

PS - signal strength seems to be ok: [EDIT: Well, there are short interruptions, I only later realised when watching at it on a larger screen, sorry.]

[patman15]

The signal strength picture shows some unavailable parts (interrupted line). So it looks like you have some BT disturbances around. The message is just a warning that the initial retrieval of data failed. The integration will continue to work normal. Probably I should downgrade the severity of that message as it is really not that critical, can happen any time. Or I can introduce the retry library to make the connection more robust. Do you have issues with data availability? I would guess so from the graph. Do you see the same unavailability also in the other values?

[7wells]

Do you have issues with data availability? I would guess so from the graph. Do you see the same unavailability also in the other values?

Yes, time and again I see "unavailable" messages from your integration, which is undoubtedly related to my not always good connection. And please accept my apologies that I did not realize this earlier. The graph does show (though short) interruptions. I should have put my glasses on or posted this via PC with a larger screen than via mobile phone. 🫢 The "unavailable" messages come only for parameters from your integration, i.e. from the RC battery that is in the front under the seat, whereas the RPi4 with HA is in the back under the roof. Maybe I should try to use some ESPhome BT extension?

[7wells]

The template can be fixed like this:

{{ iif(has_value("sensor.car_battery2_delta_voltage"), state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[0], "n/a")}}

That will show n/a when the value is not available and not throw an error.

Thanks, I have implemented this. However, it creates another error in the HA protocol. If I understand it correctly, the last line shows the reason, i.e. mismatch of variable type - "n/a" is not of type integer (not numeric):

Logger: homeassistant.core
Quelle: core.py:1564
Erstmals aufgetreten: 15:26:35 (4 Vorkommnisse)
Zuletzt protokolliert: 15:26:35

Error running job: <Job onetime listen homeassistant_start <function _async_at_core_state.<locals>._matched_event at 0x7f___d0___> HassJobType.Callback <_OneTimeListener homeassistant.helpers.start:<function _async_at_core_state.<locals>._matched_event at 0x7f___d0___>>>
Error running job: <Job onetime listen homeassistant_start <function _async_at_core_state.<locals>._matched_event at 0x7f___d0___> HassJobType.Callback <_OneTimeListener homeassistant.helpers.start:<function _async_at_core_state.<locals>._matched_event at 0x7f___d0___>>>
Error running job: <Job onetime listen homeassistant_start <function _async_at_core_state.<locals>._matched_event at 0x7f___d0___> HassJobType.Callback <_OneTimeListener homeassistant.helpers.start:<function _async_at_core_state.<locals>._matched_event at 0x7f___d0___>>>
Error running job: <Job onetime listen homeassistant_start <function _async_at_core_state.<locals>._matched_event at 0x7f___d0___> HassJobType.Callback <_OneTimeListener homeassistant.helpers.start:<function _async_at_core_state.<locals>._matched_event at 0x7f___d0___>>>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 657, in state
    numerical_value = int(value)
                      ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: 'n/a'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 660, in state
    numerical_value = float(value)
                      ^^^^^^^^^^^^
ValueError: could not convert string to float: 'n/a'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 1564, in async_fire_internal
    self._hass.async_run_hass_job(job, event)
  File "/usr/src/homeassistant/homeassistant/core.py", line 938, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/core.py", line 1425, in __call__
    self.hass.async_run_hass_job(self.listener_job, event)
  File "/usr/src/homeassistant/homeassistant/core.py", line 938, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/helpers/start.py", line 44, in _matched_event
    hass.async_run_hass_job(at_start_job, hass)
  File "/usr/src/homeassistant/homeassistant/core.py", line 938, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/components/template/template_entity.py", line 486, in _async_template_startup
    result_info.async_refresh()
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1108, in async_refresh
    self._refresh(None)
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1294, in _refresh
    self.hass.async_run_hass_job(self._job, event, updates)
  File "/usr/src/homeassistant/homeassistant/core.py", line 938, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/components/template/template_entity.py", line 435, in _handle_results
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1005, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1130, in _async_write_ha_state
    self.__async_calculate_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1067, in __async_calculate_state
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1011, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 664, in state
    raise ValueError(
ValueError: Sensor sensor.car_battery2_cell1 has device class 'voltage', state class 'measurement' unit 'V' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: 'n/a' (<class 'str'>)

Is there anything I can do about this, or do I have to ignore it?

[patman15]

Sorry for that, I oversaw that the configuration via GUI is limited, try this:

{{ iif(has_value("sensor.car_battery2_delta_voltage"), state_attr("sensor.car_battery2_delta_voltage", "cell_voltages")[0], None) }}

Difference is only the None at the end. This will result in unknown instead of unavailable which would be correct, but in the end does not matter and for the latter you need to go into the YAML configuration. :wink:

[patman15]

Yes, time and again I see "unavailable" messages from your integration, which is undoubtedly related to my not always good connection. And please accept my apologies that I did not realize this earlier.

No worries, happy to help. I can make a branch to test a version that is a bit more robust to disturbance (does retries) if you want. Nevertheless, when there is no connection (within 30s), you won't get data so not sure it really makes a difference. Let me know your preferences.

[7wells]

If you have time and would like to do this, I am happy to test and report back. Would it be possible and make sense to retain the last value (as with "last will" in MQTT) in case of loss of connection? Maybe not, but I am unsure.

Whether the value reads "unavailable" or "unknown" does not matter to me. If it does for other users? I doubt it, and it would be a bit better than seeing error messages in the protocol (if you have time to branch this for testing).

In parallel, I will add another ESP32 to see whether it can ameliorate the signal.

Thanks a lot for your great integration, patience, and help! 👍

PS and a bit OT: I observe signal interruptions during similar periods each and every day. Maybe there are Wifi or BT signals from the neighbourhood or our own that disturb the BT signal between the battery and the Raspberry Pi 4 (HA instance) in our RC car. I should disable the BT of the ESP32 that is directly connected (USB cable) to the RPi4, which could be the culprit for the signal disturbance, too.

[patman15]

If you have time and would like to do this, I am happy to test and report back.

Ok, give me a bit of time, I'll ping you if I have branch. Shouldn't be too complicated.

Would it be possible and make sense to retain the last value (as with "last will" in MQTT) in case of loss of connection? Maybe not, but I am unsure.

I'm a fan of separation of concerns which in this case means, the integration should assume something about the usage, i.e. there might be applications where you want to know if you loose the connection, thus the integration should not hide that. Templating could help in your case again if necessary. But let's see if the more robust version can fix it as well.

Maybe there are Wifi or BT signals from the neighbourhood or our own that disturb the BT signal

2.4GHz WiFi is in the same band as Bluetooth, also other Bluetooth devices (like your ESP32) might disturb. Removing thos should definitely enhance the availability.

[patman15]

@7wells I made a quick fix for your connection issues that might help. Currently, it only affects the JBD type BMSs. The modifications are in a feature branch for robustness. Do you know how to install or do you need guidance?

[7wells]

@patman15 Yes, some hints how to install this branch are very welcome.

Do I have to replace/overwrite the main version with the code from there? https://github.com/patman15/BMS_BLE-HA/tree/feature/retry_for_robustness

Shall I store the files there? /root/config/custom_components

In case you know of some generic HA documentation about running/testing tree/dev versions of HA integrations, I am happy to read that, also for my personal education. I have searched already about it but have not found something that seems to help me (maybe also due to lack of understanding).

Thank you so much!

[patman15]

Instructions are actually here: https://github.com/patman15/BMS_BLE-HA/tree/feature/retry_for_robustness?tab=readme-ov-file#manual and you just need to get the files from the branch (link you sent is correct). The folders should already exist if you installed via HACS, so basically replacing the files should do it.

[7wells]

Thank you! Sadly, it takes me longer than I thought. I had a working ssh (pubkey) to my HA instance, but it does no longer work. Now I am looking for another way to get the files there, maybe wget, but I am not a Linux expert and need to first find out how. Sorry about the delay for testing.

PS: So I simply pulled all files/folders individually via wget - not elegant at all, but it works. I had deactivated the integration before, activated it after fetching the files from the repo, and restarted HA. Maybe I did something wrong - see error in protocol:

Logger: homeassistant.bootstrap
Quelle: util/json.py:81
Erstmals aufgetreten: 16:12:46 (1 Vorkommnisse)
Zuletzt protokolliert: 16:12:46

Error setting up integration bms_ble - received exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 75, in load_json
    return orjson.loads(fdesc.read())  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
orjson.JSONDecodeError: unexpected character: line 7 column 1 (char 6)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 185, in async_setup_component
    await future
  File "/usr/src/homeassistant/homeassistant/setup.py", line 185, in async_setup_component
    await future
  File "/usr/src/homeassistant/homeassistant/setup.py", line 165, in async_setup_component
    result = await _async_setup_component(hass, domain, config)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/setup.py", line 446, in _async_setup_component
    await load_translations_task
  File "/usr/src/homeassistant/homeassistant/helpers/translation.py", line 420, in async_load_integrations
    await _async_get_translations_cache(hass).async_load(
  File "/usr/src/homeassistant/homeassistant/helpers/translation.py", line 179, in async_load
    await self._async_load(language, components_to_load)
  File "/usr/src/homeassistant/homeassistant/helpers/translation.py", line 232, in _async_load
    translation_by_language_strings = await _async_get_component_strings(
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/translation.py", line 115, in _async_get_component_strings
    loaded_translations_by_language = await hass.async_add_executor_job(
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/translation.py", line 59, in _load_translations_files_by_language
    loaded_json = load_json(translation_file)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 81, in load_json
    raise HomeAssistantError(f"Error while loading {filename}: {error}") from error
homeassistant.exceptions.HomeAssistantError: Error while loading /config/custom_components/bms_ble/translations/de.json: unexpected character: line 7 column 1 (char 6)

I will check later what could be the problem. Maybe something went wrong when trying to download the files etc.

[patman15]

Hey, just say ... I can prepare a beta version a bit later today so you can install via HACS. No problem!

Touched, not typed.

[7wells]

Hi! I am very grateful for your time and friendly patience with me. I promise to test and report back, so hopfully other users will have some benefit, too. 😊

[patman15]

Hi, you can try v1.6.3_retry, which should be available via HACS (try update information, redownload). I do not know why, but the error above looks like an issue with my new German translation which I can't find. In case it persists even after updating via HACS (no idea why), please delete the file custom_components/bms_ble/translations/de.json in your local installation and try again.

[7wells]

Ah, I already wondered about the new de file. 😉 Shall I help you with the translation? (if needed at all)

Right after installation of your new 1.6.3 pre-release via HACS (and HA restart), the protocol now longer shows this warning.

However, its initialization procedure now shows this:

Battery
1 Gerät und 11 Entitäten
Einrichtung fehlgeschlagen, wird erneut versucht: device communication timed out

(sorry for "DEnglish")

This keeps showing after about 10 minutes retrying, but maybe that is exactly as you intended to handle it in case of interrupted connection. Correct?

I will check again tomorrow, and I will place my extra ESP32 with Bluetooth proxy in the car to (hopefully) ameliorate the situation regarding the connectivity.

Once again, thank you very much for looking into this and offering this new version. 👍

PS @patman15 It still tries to initialize ("device communication timed out"). What can I do to find out more? Running in debug mode and post a log? I am not sure how to do that.

[patman15]

Shall I help you with the translation? (if needed at all)

Thanks, there is not much to do, only a few sentences and they are done.

(sorry for "DEnglish")

That's a HA backend issue ...

What can I do to find out more? Running in debug mode and post a log?

Unfortunately, debug log won't help much in this case. Tried to debug it myself, BT says connection timed out. :face_with_diagonal_mouth:

Please try this version, I reverted a change. For some reason the initialization often fails (on unknown criteria) and won't recover. I removed the recovery function because all other BT integrations do not have a similar function, but obviously that was a mistake. :disappointed:

[7wells]

Thanks. I just tried the new version and got this in the protocol:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: custom_components/bms_ble/__init__.py:53
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 08:13:08 (1 Vorkommnisse)
Zuletzt protokolliert: 08:13:08

Failed to initialize BMS 06xxxxxxxxxx, continuing

It indeed only appears once, and everything seems to work fine so far.

A bit OT about the language in the HA backend issue (just in case some user wants to change it): https://community.home-assistant.io/t/date-not-visual-in-local-language/572704/7

[7wells]

Well, this warning now appears and repeats:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: helpers/update_coordinator.py:360
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 09:11:18 (3 Vorkommnisse)
Zuletzt protokolliert: 09:32:18

Timeout fetching 06xxxxxxxxx data

My connection must be bad, despite the HA instance (RPi4) is inside the car as the battery, only about 4 m apart.

[patman15]

And these messages are produced by the v1.6.3_exch release you installed and rebooted? You have a type JBD BMS, correct? Just checking, because that would mean that HA could not connect to the BMS after 4 retries ...

[7wells]

Yes, produced by the v1.6.3_exch release (and not by the v1.6.2 release). Yes, it is a JBD (Jiabaida) BMS.

To double-check, I installed again the v1.6.2 release, cleared the protocol, restarted HA, and the protocol then shows:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: custom_components/bms_ble/__init__.py:53
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 14:30:28 (1 Vorkommnisse)
Zuletzt protokolliert: 14:30:28

Failed to initialize BMS 06xxxxxxxxx, continuing

The battery values are ok at this stage.

[7wells]

To triple-check, I installed again the v1.6.3_exch release, cleared the protocol, restarted HA, and the protocol then shows:

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: custom_components/bms_ble/__init__.py:53
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 14:35:37 (1 Vorkommnisse)
Zuletzt protokolliert: 14:35:37

Failed to initialize BMS 06xxxxxxxxx, continuing

The battery values are EDIT: ok ~not available~ at this stage.

So currently, it seems as if the 2 releases show the same protocol warnings, at least on my end.

[7wells]

Maybe I misunderstand something, but I wonder how there can be values for the battery voltage and temperature during a period (highlighted in blue) where there are no values for the battery signal strength:

[7wells]

I am still on the v1.6.3_exch release release. Since the warning posted before, there is only one new entry in the protocol, an error (7 times as of writing this):

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.bms_ble
Quelle: helpers/update_coordinator.py:360
Integration: BLE Battery Management (Dokumentation, Probleme)
Erstmals aufgetreten: 14:59:07 (7 Vorkommnisse)
Zuletzt protokolliert: 16:24:47

Timeout fetching 06xxxxxxxxx data

And I do not get any values since 16:24 (last time this error was seen), i.e. all related entities are not available since then.

[patman15]

Maybe I misunderstand something, but I wonder how there can be values for the battery voltage and temperature during a period (highlighted in blue) where there are no values for the battery signal strength:

Hmm, I could imagine that the regular advertisements are not received (used to calculate RSSI), while the connection still standing. Strange but theoretically possible.

I am still on the v1.6.3_exch release release. Since the warning posted https://github.com/patman15/BMS_BLE-HA/issues/35#issuecomment-2338012054, there is only one new entry in the protocol, an error (7 times as of writing this):

Well, it's still the same issue (HA not able to reach the battery), seems that the changes I did cannot recover much and your connection is really bad. I'll think of a way to track signal quality in a better way. I'll come back with a proposal.

[7wells]

I placed an ESP32 with BT proxy at half of the distance between RPi4/HA and battery. I posted the debug log of this BT proxy on the forum: https://community.home-assistant.io/t/esp32-bt-proxy-and-power-save-mode/768929

I could not see any problems in the log but asked the community for feedback if something could be enhanced on my side. I am not sure if something could be seen there at all that could be of relevance here.

BTW, when I reload the integration, the entities become available again almost instantly. Would it make sense to auto-reload on disconnection in order to thus try to reconnect?

[patman15]

BTW, when I reload the integration, the entities become available again almost instantly. Would it make sense to auto-reload on disconnection in order to thus try to reconnect?

Hmm, that is also a strange behavior. I do not have much experience with BT proxy, in principle it should be transparent for the integration.

I made a new version, that adds two diagnostic sensor (you need to enable them like the RSSI sensor): v1.6.3_lq. Link quality shows you the percentage of successful queries within the last 100 tries, link down the longest duration the BMS was not available (within the last ~hour). Maybe you can let this version run at least a day and then let's have a look at the graphs. Also you could use it to experiment with your setup to fix the connection issue. Let me know what you think.

[7wells]

Thank you - I will let you know about the result tomorrow!

[7wells]

Hours later (since my previous post), I see link down = 0 and link quality = 100. The signal strength remained unchanged at -56 dBm since then. There is no new message in the protocol. Now that look good, and I will keep an eye on it.

Please let me know what I could further try and report, if you need something. Thank you!

PS - now like this: link down = 6:30 and link quality = 79 %, but first value decreasing and second value increasing again by the minute.

[patman15]

Can you post a >=24h graph of the two new sensors?

[7wells]

Obviously 4h of 24h are missing, sorry. I will attach the full 24h later.

If I see it correctly, there were 3 periods of 50min without connectivity. That is quite long, especially since the car is not moved, i.e. HA instance (RPi4) and battery are at the same place.

[patman15]

The fact that on the two instances below there is a hard switch in both measurements (there actually must be a ramp as both are moving average) indicates to me that either the integration or even the whole HA was restarted. Can you check your home-assistant.log for restart/reboot notifications? Could it be that you have a power supply issue with RPi4, i.e. USB power supply to weak?

[7wells]

Sorry, I had restarted HA at those times - and only now realise that this biases the results. 🫢

Please see below another run over the last 24h. I am not sure whether I restarted HA yesterday at ~15:00 (wehere that ramp is shown). But I am sure that I did not restart HA and did not reload the integration later till now. The 4th graph (SoC) is shown for reference.

I have also checked the HA log for any hints for power issues but there are none.

[7wells]

And once more that past 24h (back-to-back with the previous screenshot):

[patman15]

Wild guess, your (solar) charge controller disturbs the BT connection? Just guessing, because during the night everything looks fine, while in the morning there is a serious outage. Maybe the ESPhome proxy reboots? Also the outage is so long that even my robustness enhancement won't help there. Sorry, running out of ideas otherwise. Probably by monitoring you find some pattern when the outage occurs.

[7wells]

Yes, I will have to check these possibilities, too.

Please allow me asking these 2 questions:

I restarted HA (because of an update of another integration), and everything (incl. your BLE integration and the battery signal) came back within approx. 30 seconds. Why does it take so long for the graphs of link down and link quality to come back to normal?

Maybe I misunderstood what they show?

Will you make this pre-release an official release? Currently, I would like to stick to it and not revert to 1.6.3 - or should I?

[patman15]

Why does it take so long for the graphs of link down and link quality to come back to normal?

Because the integration always starts with worst case (thought about changing this, but then you wouldn't see restarts) and as mentioned in https://github.com/patman15/BMS_BLE-HA/issues/35#issuecomment-2339038088 the values are averaged over the last 100 tries == 3000s == 50 minutes. So if all is good link quality will show 100% after 50 minutes. Hope that helps!

[patman15]

Will you make this pre-release an official release?

I tend to say no, but I'm not sure yet. It's mainly a debugging feature. Anyways, you can stay on the beta for a while because the next release will be just some minor corrections and mainly test coverage enhancements. So no feature changes.

I'm still struggling whether I should or shouldn't remove the message at the beginning "Failed to initialize BMS, continuing." It seemed that without (which is the default with all other HA integrations!) the initialization got stuck with your bad connection. Or maybe just coincidence? Not sure, maybe I will run some further tests ...

[patman15]

Hey @7wells, I played around quite some time with a device and an intentionally bad connection, i.e. RSSI below -86dBm. I was worried because you said in https://github.com/patman15/BMS_BLE-HA/issues/35#issuecomment-2336820689 that even after 10 minutes the system did not proceed to normal operation. I did notice that when you have the connection established the RSSI can drop a bit more and you still get data while it won't establish a connection. So there some kind of "when it works, it stays" thingy but when it exceeded a level it always connected and never stayed off. In the end I cannot relate the changes I did in v1.6.3_retry to your observation that it did not connect for a long time. In my opinion that was an unfortunate coincidence. Would you agree? If so, consequently, I would proceed with removing the message Failed to initialize BMS, continuing. and the associated behavior (to continue despite a device not being reachable at start-up), which is the default for all HA integrations.