Issues with latest releases

[JayNewstrom]

Hi,

I was running https://github.com/jdeath/rd200v2/commit/ab4119d4d9203c4a2d26f4423e86bea7e980f82d for a day or so with really good success!

However, after updating to 1.0 and 1.1 the integration keeps going unavailable after rebooting home assistant. I get a reading for 5-15 minutes, but then it won't come back until I restart home assistant.

I have been using ESPHome with bluetooth proxy the whole time for my bluetooth connection.

[JayNewstrom]

Home assistant logs are:

Timeout getting command data.

Error fetching rd200_ble data: Unable to fetch data: unpack requires a buffer of 2 bytes

[jdeath]

That is weird. Mine has been fine. Occasional dropouts, but I think that is to be expected with BLE. I did add another sensor, that requires a second BLE command. I am going to push another update. Perhaps hard reboot your machine and/or proxies and see if better. If it doesn't work. comment out line 150 in rd200_ble/parser.py . that will stop the second BLE call that is used to get the peak value.

[JayNewstrom]

No luck with the commenting out of the second BLE call. I looked at very verbose logs on the ESPHome device, but it's a lot of logs. And nothing really sticks out.

[jdeath]

Maybe try moving the rd200 closer to the esphome, just to see if a connection issue.

In the parser there are two lines like this: await asyncio.wait_for(self._event.wait(), 5)

Maybe make it 10, so it waits longer for a response.

Also make sure your esphome is not always scanning, use the defaults for the ble tracker and proxy:

esp32_ble_tracker:
  scan_parameters:
    active: true

bluetooth_proxy:
  active: true

[JayNewstrom]

I've got an Ethernet esphome device, and it's right next to it (I think the antenna is also very good, as it covers my entire house with other devices).

I'll try extending the timeout.

[JayNewstrom]

Still have the same issues with timeouts, as well as the other error.

[jdeath]

darn sorry. I'll keep an eye out for happening on mine and try to fix if I see it. Maybee its too close?

[JayNewstrom]

Is there anything I can do to help? I can (privately) send you some logs, or do some debugging on my end if that would help.

[jdeath]

I am not really an expert on BLE, just learned about it last week! Not sure what else can do unless I get the issue too. The missed connections do not have much debugging info. Perhaps stick some extra debug statements to see why it is failing. Weird that it works, then stops. Do you have any other homeassistant BLE integrations? Do those all work fine? Can you add BT to your homeassistant box, and skip the esphome?

[arpia49]

Hello, I think I'm facing the same issue than @JayNewstrom , I will try to get some time in the next couple of days to test the proposed solution and share some feedback.

[jdeath]

Thanks. Mine is still stable. Let me know if you find a fix.

[arpia49]

I don't know if this rings any bell for you... this has been running with peak line commented, DEFAULT_SCAN_INTERVAL = 60 and also adding a client.disconnect to the _get_radon on the exception. Since I'm not very skilled I don't know if after an exception the disconnect from update_device would be triggered.

While there are gaps in that graph, the entities show as 'not available'.

I'll update the comment in an hour with data (image) with the defaults code.

[jdeath]

I think client.disconnect should only be in the update_device function. This is how the airthings_ble integration does it, and I just modified that code. If you find a fix, let me know https://github.com/vincegio/airthings-ble/blob/main/airthings_ble/parser.py

[JayNewstrom]

I changed a few things, and it's back to reporting stable values again. I'm not sure what did it, but I'll continue to monitor and try other things to see if it begins to have issues again.

I removed the interval, and window from my

esp32_ble_tracker:
  scan_parameters:

I updated to the latest version of the integration released this morning.

I commented out the peak sensor in the integration.

I'd like to get the peak sensor working again, so I'll try to uncomment that and see what happens after it's stable for a day or so.

[arpia49]

I may have a solution/workaround, waiting for the kids going to sleep too start preparing a pull_request.

El jue, 29 dic 2022 20:05, Jay Newstrom @.***> escribió:

I changed a few things, and it's back to reporting stable values again. I'm not sure what did it, but I'll continue to monitor and try other things to see if it begins to have issues again.

I removed the interval, and window from my

esp32_ble_tracker: scan_parameters:

I updated to the latest version of the integration released this morning.

I commented out the peak sensor in the integration.

I'd like to get the peak sensor working again, so I'll try to uncomment that and see what happens after it's stable for a day or so.

— Reply to this email directly, view it on GitHub https://github.com/jdeath/rd200v2/issues/3#issuecomment-1367526972, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA664LSMRD4XGTVRAFYJS3WPXOF7ANCNFSM6AAAAAATLTJGKM . You are receiving this because you commented.Message ID: @.***>

[colinmcintosh]

I just tested the PR and it seems to resolve my issue with unpack requires a buffer of 2 bytes. Connection seems stable now. Thanks for fixing this @arpia49!

[jdeath]

I'll ask the pros on discord before doing the commit.

Sorry, await is required. Feel free to comment out in your local version but removing the await is equal to removing the disconnect line as it does not get called. If it works for you, great, but will probably cause other problems.

[jdeath]

Closing this as I think the latest update fixes stability. Please reopen if not the case

[JayNewstrom]

@jdeath I saw your note in the readme about https://github.com/esphome/issues/issues/4041 and can confirm the update fixed this issue for me.

Thanks!