Tedee official/local integration much slower to update lock status than custom/cloud component

[LordShadowen]

The problem

The older custom Tedee custom component working with the Cloud API takes around 5s to update the lock status (when manually locking/unlocking). This was a bit slow, but not too bad.

The official component uses the local API of the bridge, so it should be, in theory, even faster. (not to mention all the other benefits of being local). However, it consistently takes between 20 to 30 seconds to update - much much slower, resulting in a poorer experience.

This looks like there is a bug somewhere, not?

What version of Home Assistant Core has the issue?

core-2024.7

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

tedee

Link to integration documentation on our website

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

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

[home-assistant[bot]]

Hey there @patrickhilker, @zweckj, mind taking a look at this issue as it has been labeled with an integration (tedee) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `tedee` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign tedee` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

tedee documentation tedee source _{^{(message by IssueLinks)}}

[zweckj]

I can't reproduce that one. Since 2024.5, the bridge pushes any updates to HA, resulting in (near) instant state changes. Check your logs if you can find any warnings that indicate a failure in setting up the webhook for tedee. Also, try to set a non-HTTPS internal URL for your HA, as the bridge sometimes had issues with SSL in the past.

[LordShadowen]

Thanks for the quick reply!

There aren't any errors/warning messages in the log. If you want me to setup something in debug mode, let me know.

My HA is not running on HTTPS, just plain basic HTTP... But just so I'm clear, the webhook communication is from HA to Bridge right? Meaning, it's an established connection? Because the bridge is not on the same VLAN as HA, and by design, it's not allowed to initiate connections to other VLANs. Could this be an issue?

[zweckj]

Thanks for the quick reply!

There aren't any errors/warning messages in the log. If you want me to setup something in debug mode, let me know.

My HA is not running on HTTPS, just plain basic HTTP... But just so I'm clear, the webhook communication is from HA to Bridge right? Meaning, it's an established connection? Because the bridge is not on the same VLAN as HA, and by design, it's not allowed to initiate connections to other VLANs. Could this be an issue?

communication is from bridge to HA for the push feature. Then your VLAN FW is most likely the problem.

[LordShadowen]

Ah! That explains it... Ok, got it working. Yes, it's nearly instant now - awesome!

But I think this is a rather big issue that should, at least, be mentioned in the documentation. I understand that we are limited by the API and how it works, but I suspect that a lot of people will have the same experience I had, and will just assume that the slow response is "normal".

I actually had two barriers to overcome:

1) VLAN isolation (I suspect this will be very common, as lots and lots of folks place their devices on a separate IoT VLAN). I solved this by creating an explicit firewall rule to allow the bridge specifically to do it.

2) HA running on Docker - I had to enable the logs on debug to figure this one out. The advertised IP address for the callbacks was the internal IP inside the container, which would not be reachable anyway. I fixed it by changing the network_mode to Host, but I guess not everyone will want to do this...

The larger point is that I was assuming that "local" means only "HA talks to Bridge", and not the other way around. For example, the Shelly integration is also "local", also classified as "Local Push" on the Integrations page, and doesn't have any of these issues. (I assume because they establish a web socket to the Shelly device, and all updates are sent back by that same established connection).

I don't suppose there is a similar mechanism with Tedee bridges? It would be soooo much easier :)

[zweckj]

Ah! That explains it... Ok, got it working. Yes, it's nearly instant now - awesome!

But I think this is a rather big issue that should, at least, be mentioned in the documentation. I understand that we are limited by the API and how it works, but I suspect that a lot of people will have the same experience I had, and will just assume that the slow response is "normal".

What kind of text would you have liked there?

HA running on Docker - I had to enable the logs on debug to figure this one out. The advertised IP address for the callbacks was the internal IP inside the container, which would not be reachable anyway. I fixed it by changing the network_mode to Host, but I guess not everyone will want to do this...

if you set a internal_url in your config.yaml or settings, I'd assume it'd also be fine.

I don't suppose there is a similar mechanism with Tedee bridges? It would be soooo much easier :)

nope...

[zweckj]

@home-assistant close

[LordShadowen]

What kind of text would you have liked there?

Some sort of note that "instant" status (callbacks) updates requires HA to be "network reachable" by the bridge (not sure about the proper wording, but you know what I mean).

The reason I think such a note is so important is the fact that updates do work anyway, since there's some sort of polling/refresh going on every 30s or so. If it was just plain broken, there would be no updates at all and users would know there was some sort of issue. Because they do work, I think most people will assume "it's just the way it is", and even worse, might prefer to keep using the old custom component instead as a result - I know I did :)

if you set a internal_url in your config.yaml or settings, I'd assume it'd also be fine.

Yes, probably. Didn't think of that... A good think to mention in the note as well.

Regardless, thanks a lot for you help 👍

[zweckj]

Thanks, will add that to the documentation hope this makes it clearer.

[LordShadowen]

👍 👍