Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not all events of Shelly BLU devices arrive in HA #113983

Closed
FlorianWilk opened this issue Mar 22, 2024 · 3 comments
Closed

Not all events of Shelly BLU devices arrive in HA #113983

FlorianWilk opened this issue Mar 22, 2024 · 3 comments
Labels

Comments

@FlorianWilk
Copy link

FlorianWilk commented Mar 22, 2024

The problem

First of all: This issue might look/feel similar to #111137, but i think the reasons for this are totally different.

I have several Shelly BLU devices and multiple Shelly devices as Proxy (1PM,2PM, Pro 3EM).
My Problem only occurs with Shelly BLU DW.

Sometimes HomeAssistant has a wrong state (open) of these Sensors than the Shelly App does (closed).

Here some Screenshots:

HA - last event 23:30:48 "open"

WhatsApp Image 2024-03-22 at 07 43 02 (1)

Shelly APP - last event 23:30:57 "closed"

WhatsApp Image 2024-03-22 at 07 43 02 (2)

Shelly APP - last reporter 23:31:38

WhatsApp Image 2024-03-22 at 07 43 03

Here is the log:

btonlykellerintime.log

The Log is filtered for this particular Shelly BLU Device only (3C:2E:F5:FB:AA:C0) and for this day only.

What i think is interesting:

  1. Reporters/Proxies in this Log are devices, which are on another floor that the Shelly BLU device (has nothing to do with the HA integration, but i wonder why the Shelly BLU does not connect the devices, which are about 5m away on the same floor).

  2. And i think this is the issue: The Log does not contain the close event at 23:30:57. The open event occured at 23:30:48. Enough time in between, so it should not be a race condition. What is also interesting: The Shelly App say "last Reporter for this BLU Devices is NT" - which is a Shelly Pro 3EM on the same floor as the Shelly BLU DW and about 5-8m away. This device does not show up in the HA logs above.

So, somehow this close-event, which was fired at 23:30:57 did reach the Shelly Proxy Device (the Shelly Pro 3 EM) and was sent to the Shelly Cloud, but did not reach my HA.

Update 1:
The proxy device, which was used to transmit the Close Event to the ShellyCloud is 34:98:7A:45:3D:70 (Shelly Pro 3EM).
I just checked my HA logs for this device and its full of:

"Bluetooth scanner has gone quiet for 90s, check logs on the scanner device for more information"

onlyntintime.log

I just opened/closed that particular door a few minutes ago. And NONE of the events (open/close) arrive in HA anymore. But the Shelly APP history shows all open/close-events.

newone

Again the Shelly APP says: Last reporter is the Shelly Pro 3EM i mentioned above.

newone2

I downloaded a new log and filtered for the BLU device, but no entries for today. The events just don't arrive in HA anymore / when sent over the Shelly Pro 3EM as Proxy.

Update 2:
I restarted HA, opened/closed the door. Still it says: Last event 10h ago. Shelly App receives every event. I have no idea of whats wrong here now.

What version of Home Assistant Core has the issue?

core-2024.3.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

bthome, shelly?

Link to integration documentation on our website

No response

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

@FlorianWilk
Copy link
Author

Ok, I just noticed, that in the Shelly App the ProxyDevice (Shelly 3 Pro EM) did not have BLE Observer enabled anymore. I reenabled it and now the events arrive in HA. I am sure it was enabled in the past (also the logs of the past days say so), but this is not an issue of the HA BTHome integration.

@FlorianWilk
Copy link
Author

FlorianWilk commented Mar 25, 2024

I am sorry, but i have to reopen this issue again. The above was not the reason for this issue.
I am having this issue now nearly every day with different sensors (maindoor, floor door, kitchen window).
It seems as if the close event does not reach HA (and it's not in the logs), but in the Shelly APP the state is always correct and it shows the closing event in the history. Something seems to dismiss this event when going throught BTHome, but i am not sure why.

The Shelly APP shows the last proxy used for this (close) event and these devices have "Enable Bluetooth gatway" enabled.

err.log

This logs shows the sensor opened at 9:56:18, but not the close event (closed at 9:56:51 - shelly app said). I can't show you the history in the shelly app, because my history is limited to 5 events and the door has been opened/closed since then.

One thing i don't understand is, that the Shelly APP sometimes shows another reporting device (proxy), than HA/BTHome shows in it's log. not sure if this is an issue but i was wondering why that is.

@FlorianWilk FlorianWilk reopened this Mar 25, 2024
@issue-triage-workflows
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@issue-triage-workflows issue-triage-workflows bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 30, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jul 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant