Readings become unavailable all the time (and then come back).

galmok commented 7 months ago

The problem

The logged readings are not continuous. This means the devices keep becoming unavailable and then come back. Can we please have an option that prevents logging when the device is unavailable? That would save spare and be more useful.

What version of Home Assistant Core has the issue?

core-2024.1.6

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Airthings BLE

Link to integration documentation on our website

https://www.home-assistant.io/integrations/airthings_ble/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

HomeAssistantPim commented 5 months ago

I just upgraded from 2024.1.5 to: Core 2024.3.3 Supervisor 2024.03.0 Operating System 12.1 Frontend 20240307.0

Didn't read any release notes (#QA #clean-code #test-driven #living-on-the-edge #life-is-to-short) And yes my Airthings is losing the device multiple times a day and the connection restore can take hours. Other changes I noted from 2024.1.5:

Also got some warnings about the lightness sensor having a different unit of measurement (I don't think my wave plus has such a sensor, thus I disabled it)
Change in battery level (54% -> 80%), I suspect this is the result of a bug fix as my battery level dropped instantely when I moved several weeks ago from the anythings cloud integration to the anythings ble integration.

I also have Xiaomi integration active for my bluetooth plant sensors, they did not suffer from these updates.

Many thnx on the tip to reload the integration when the device is dropped, that at least helps a bit. It was triggered already 5 minutes after I dis/enabled a sensor to give communications a little kick. Hopefully a real fix will come soon?

The workaround: ` alias: Airthings Bug Workaround trigger:

platform: template value_template: "{{ states('sensor.airthings_wave_136828_batterij') == 'unavailable' }}" action:
service: homeassistant.reload_config_entry target: device_id: 3e03dbe33d551de3bdc8cd2e21fc9204 mode: single `

sdaltons1 commented 5 months ago

Could someone who is connecting this with an ESPHome Bluetooth proxy share their ESPHome config?

I disabled my HA Bluetooth integration and have one of these running and it isn't picking up my AirThings at all. I assume I have something configured incorrectly.

jac2424 commented 5 months ago

Could someone who is connecting this with an ESPHome Bluetooth proxy share their ESPHome config?

I disabled my HA Bluetooth integration and have one of these running and it isn't picking up my AirThings at all. I assume I have something configured incorrectly.

I just tried this myself and didn't really do anything special, I flashed the ESP32 device using Bluetooth Proxy option from below site. Once flashing was complete and device was added to home assistant I just placed it close to middle of all my devices and then disabled the Bluetooth dongle in my home assistant. No other config changes were done and my Bluetooth sensors and Airthings Wave+ are all showing up fine. So far with the proxy AirThings is lot more stable and haven't seen any unavailable messages yet but its only been a couple of days. I still think issue is with AirThings integration perhaps not gracefully handling connection issues or weak signals at its set pooling intervals and resulting in unavailable message rather then just retrying it or waiting for several failed tries before marking entities as unavailable.

https://esphome.io/projects/?type=bluetooth

sdaltons1 commented 5 months ago

Could someone who is connecting this with an ESPHome Bluetooth proxy share their ESPHome config? I disabled my HA Bluetooth integration and have one of these running and it isn't picking up my AirThings at all. I assume I have something configured incorrectly.

I just tried this myself and didn't really do anything special, I flashed the ESP32 device using Bluetooth Proxy option from below site. Once flashing was complete and device was added to home assistant I just placed it close to middle of all my devices and then disabled the Bluetooth dongle in my home assistant. No other config changes were done and my Bluetooth sensors and Airthings Wave+ are all showing up fine. So far with the proxy AirThings is lot more stable and haven't seen any unavailable messages yet but its only been a couple of days. I still think issue is with AirThings integration perhaps not gracefully handling connection issues or weak signals at its set pooling intervals and resulting in unavailable message rather then just retrying it or waiting for several failed tries before marking entities as unavailable.

https://esphome.io/projects/?type=bluetooth

Thanks for this. Helped me to understand I wasn't doing anything wrong and had followed the right steps. Turned out I needed to clean build files and reinstall.

Past 24 hours of near perfect connection now.

HomeAssistantPim commented 5 months ago

Improved version as reloading the config apparently may not always result in the device becoming available...

description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.airthings_wave_136828_batterij
    to: unavailable
condition: []
action:
  - repeat:
      sequence:
        - service: homeassistant.reload_config_entry
          metadata: {}
          data: {}
          target:
            device_id: 3e03dbe33d551de3bdc8cd2e21fc9204
        - delay: "00:01:00"
      while:
        - condition: state
          entity_id: sensor.airthings_wave_136828_batterij
          state: unavailable
mode: single

AllenBurgett commented 5 months ago

I have a similar concept, but I try to lower the amount of reload requests sent over a short period of time:

alias: Reload Airthings Devices Periodically
description: Reloads devices periodically every 5 minutes if conditions are met.
trigger:
  - platform: time_pattern
    minutes: /5
condition: []
action:
  - if:
      - condition: state
        state: unavailable
        entity_id: sensor.allens_office_airthings_temperature
    then:
      - service: homeassistant.reload_config_entry
        data: {}
        target:
          device_id: adc3f0aed148269948faa7fb829a16fc
  - if:
      - condition: state
        state: unavailable
        entity_id: sensor.basement_bedroom_airthings_temperature
    then:
      - service: homeassistant.reload_config_entry
        data: {}
        target:
          device_id: d71e8e2f99d3457c1e13f376387c3de7
  - if:
      - condition: state
        state: unavailable
        entity_id: sensor.basement_unfinished_side_airthings_temperature
    then:
      - service: homeassistant.reload_config_entry
        data: {}
        target:
          device_id: 7e043b859169e3b365b1642390cc08cc

I've been kicking around setting a limit on how many times it tries to reload, before it just notifies me that something's wrong (ex. Like the battery is dead and it's never going to reload).

jaydeethree commented 5 months ago

Copy/pasting my comment from https://github.com/home-assistant/core/issues/113610 since there are more people following this issue:

I've done some testing and I believe the problems were caused by this PR (which unfortunately contains a ton of changes, so it's hard to say which specific change is the bad one).

For now I've worked around this by rolling back to the version of the airthings_ble integration that was in use prior to that PR. There's a little bit of info about how to do this in the Home Assistant docs, but here's a slightly more detailed version of the process:

Go to the last working version of the airthings_ble integration, open each file, and download the raw file.
Create a custom_components/airthings_ble/ directory and add all of those files to it.
Edit the manifest.json file to add this line (the specific version number doesn't matter, but you have to specify some version number for this to work):
- "version": "0.0.1",
- It should look something like this:
Restart Home Assistant.
Check your Devices & Services page to confirm that the Airthings integration now shows the "Custom integration" icon (the yellow icon in the lower-right corner):

This seems to have fixed the instability problems that I've been having.

bobloadmire commented 5 months ago

This has been ongoing for months, is there anything us regular people can do to help development for a fix?

estofira commented 4 months ago

@LaStrada , any idea when this would be fixed ? Its 2.5 months now

williameriksson commented 4 months ago

Copy/pasting my comment from #113610 since there are more people following this issue:

I've done some testing and I believe the problems were caused by this PR (which unfortunately contains a ton of changes, so it's hard to say which specific change is the bad one).

For now I've worked around this by rolling back to the version of the airthings_ble integration that was in use prior to that PR. There's a little bit of info about how to do this in the Home Assistant docs, but here's a slightly more detailed version of the process:

Go to the last working version of the airthings_ble integration, open each file, and download the raw file.

Create a custom_components/airthings_ble/ directory and add all of those files to it.

Edit the manifest.json file to add this line (the specific version number doesn't matter, but you have to specify some version number for this to work):

"version": "0.0.1",

It should look something like this:

Restart Home Assistant.

Check your Devices & Services page to confirm that the Airthings integration now shows the "Custom integration" icon (the yellow icon in the lower-right corner):

This seems to have fixed the instability problems that I've been having.

Thanks for this work around, it's working great now

mwaterbu commented 4 months ago

I've done some testing and I believe the problems were caused by this PR (which unfortunately contains a ton of changes, so it's hard to say which specific change is the bad one).

b244fa0 seems potentially related.

SuppleCowChunks commented 4 months ago

Copy/pasting my comment from #113610 since there are more people following this issue:

I've done some testing and I believe the problems were caused by this PR (which unfortunately contains a ton of changes, so it's hard to say which specific change is the bad one).

For now I've worked around this by rolling back to the version of the airthings_ble integration that was in use prior to that PR. There's a little bit of info about how to do this in the Home Assistant docs, but here's a slightly more detailed version of the process:

Go to the last working version of the airthings_ble integration, open each file, and download the raw file.

Create a custom_components/airthings_ble/ directory and add all of those files to it.

Edit the manifest.json file to add this line (the specific version number doesn't matter, but you have to specify some version number for this to work):

"version": "0.0.1",

It should look something like this:

Restart Home Assistant.

Check your Devices & Services page to confirm that the Airthings integration now shows the "Custom integration" icon (the yellow icon in the lower-right corner):

This seems to have fixed the instability problems that I've been having.

Thank you for this. My integration has been running solid for the past few hours now. Haven't seen that since January.

bdraco commented 4 months ago

duplicate of #113610

That one has more information, so please continue there instead.

home-assistant / core