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

SMLIGHT Integration Bug: Connection fails when HA is unable to access 45.83.192.98 ? #132374

Open
agriffin777 opened this issue Dec 5, 2024 · 8 comments · May be fixed by #136497
Open

SMLIGHT Integration Bug: Connection fails when HA is unable to access 45.83.192.98 ? #132374

agriffin777 opened this issue Dec 5, 2024 · 8 comments · May be fixed by #136497

Comments

@agriffin777
Copy link

The problem

Hi,

I have an SMLIGHT SLZB-06M (Zigbee Coordinator Mode, Core Firmware = v2.6.8.dev16, Zigbee Firmware = 20241127) connected to a HomeAssistant Green using ZHA.

Both the SLZB-06M and HomeAssistant devices are behind a firewall which blocks all outbound internet access, unless specifically allowed. I have generally allowed DNS and NTP.

After a few minutes the SMLIGHT integration shows "Failed setup, will retry: Connection failed". When in this state, I can access the SLZB-06M via a web-browser...so it's not offline.

All other integrations I'm using are working correctly...it's only the SMLIGHT integration that is the a failed state.

If I update the firewall to allow access to 45.83.192.98 from the SLZB-06M...the integration is still broken.
If I update the firewall to allow access to 45.83.192.98 from the HomeAssistant Green...the integration starts working again.

This is 100% reproducible.

Ideally the integration should not lose connection to the SLZB-06M when HA doesn't have access to the IP address shown above, but if the integration requires internet access to function it should be declared as such.

If you need further info, please let me know.

Thanks.

What version of Home Assistant Core has the issue?

core-2024.12.0

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

SMILIGHT SLZB

Link to integration documentation on our website

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

Diagnostics information

home-assistant_smlight_2024-12-05T12-01-18.102Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@home-assistant
Copy link

home-assistant bot commented Dec 5, 2024

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

Code owner commands

Code owners of smlight 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 smlight 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)


smlight documentation
smlight source
(message by IssueLinks)

@tl-sl
Copy link
Contributor

tl-sl commented Dec 6, 2024

Hi,
The SMLIGHT integration only makes local api calls directly to the SLZB device. We do however require internet access to download the firmware update manifests that provide data for the update entities, which come from the below server.

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	smlight.tech
Address: 45.83.192.98

Probably this shouldn't block the startup of the integration, however I have never tested in a firewalled environment. I will look into why this is happening. However if you want updates to work from within HA, then you need to enable this address.

@agriffin777
Copy link
Author

Great...I appreciate you taking a look.

Yes, I agree the lack of access to the update server shouldn't block the whole integration from functioning.

Would it be possible to add a System Option that stops the integration trying to download the firmware update manifests so this issue doesn't negatively impact ?

Thanks.

@tl-sl
Copy link
Contributor

tl-sl commented Dec 6, 2024

no probably doesnt need an option, if the download fails for any reason it should just disable update entities.

@ptegler
Copy link

ptegler commented Dec 21, 2024

ditto on this issue HAOS 12.4. One is set as coordinator, a second is zigbee/bluetooth repeater.
I comment here, as this issue (as above) is only on this second SLZB-06 setup as a repeater.
QUESTION.... which firmware load (should we be using?) to the radio might be causing this connectivity issue.... EG:
1- oem 2.3.6 loaded from the oem website/app oem website/app
2- Radio web page loaded at slzb-06.local ::: WHICH RADIO MODE SHOULD WE BE USING HERE IF ANY?? :::
3- Load the default from the oem and just use HAOS and ESPHome to config everything??
tia for any clarifiactions... both as proper config.... and could these radio configs be the issue with the IP access routings???

@b2dmx
Copy link

b2dmx commented Jan 7, 2025

I also have this issue and cannot resolve at all

@agriffin777
Copy link
Author

no probably doesnt need an option, if the download fails for any reason it should just disable update entities.

Yes...that makes sense. Please let me know when the code has been amended so I can test.

Thanks.

@tl-sl tl-sl linked a pull request Jan 25, 2025 that will close this issue
19 tasks
@tl-sl
Copy link
Contributor

tl-sl commented Jan 25, 2025

This will be fixed with above PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants