Connection failed: MDNS lookup failed: SMLight #136864
Labels
integration: smlight
problem in device
Issue lies within the device, such firmware, software, or user customization/config
Milestone
Comments
|
Hey there @tl-sl, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) smlight documentation |
This comment has been minimized.
This comment has been minimized.
|
thanks, ok. Here's what I have for you: Step 1: all good here, I can acess the adapter via local LAN to Will get you logs on Step 6 on my next post. But here is another log I missed in the HA Core logs (Different from above): |
|
Regarding Step 6, after adding this to my configuration.yaml and rebooting Home Assistant, the adapter and integration are working well, but after a few minutes, it fails and goes unavaiable. The are the logs associated with SMLite during this time. During this time, i can easily login to the adapter via chrome broswer to Also, it does work for the first minutes from rebooting HA. |
|
Can confirm this. When removing and re-adding the config entry it works for some time. @bdraco can this relate to the changes made to mDNS caching? |
|
It does look like it. Going to need debug logs for |
|
Also strange in the log its Which one is the correct name, and which one is it actually trying to connect to ? |
|
Service call to turn on action: logger.set_level
data:
zeroconf: debug |
|
The core/homeassistant/components/smlight/coordinator.py Lines 52 to 56 in aca9607 Will turn on |
|
After seeing the |
bdraco
changed the title
The ignoring is fine as its the question it just asked being reflected back to itself. However it seems like its never getting an answer. |
|
It sure looks like we ask the right question, but the device never responds back to us |
|
When discovery happens earlier, the A record gets populated as an when it asks for |
when on my home network, i use |
|
So its likely that the mDNS stack on the device is not very compliant, and whatever Chrome is using to do the query is sending it in an order that it happens to work, and when It could be any of the following:
It sure looks like a bug in the mDNS stack of the device. |
|
Its pretty clear from the logs that the device isn't responding to the A record query, and It does respond to the |
bdraco
added
the
problem in device
|
I ordered one to see if I can come up with a workaround, but the vendor should fix the device so it responds to |
|
Maybe could make a new class with To make that work we would need to reimplement https://github.com/aio-libs/aiohttp-asyncmdnsresolver/blob/7bce43593a21050d46a9cdd5f39be6d36ef67fa3/src/aiohttp_asyncmdnsresolver/_impl.py#L13 https://github.com/aio-libs/aiohttp-asyncmdnsresolver/blob/7bce43593a21050d46a9cdd5f39be6d36ef67fa3/src/aiohttp_asyncmdnsresolver/_impl.py#L22 https://github.com/aio-libs/aiohttp-asyncmdnsresolver/blob/7bce43593a21050d46a9cdd5f39be6d36ef67fa3/src/aiohttp_asyncmdnsresolver/_impl.py#L31 in ... thats assuming its not a UPPERcase lowercase bug in the device's stack.... really hard to guess what magic is needed to make the device happy without it in hand. |
|
Wow thanks a lot @bdraco for your extensive debugging. Is there a way how I can verify (mostly the first 3 cases) this:
|
|
The best way would be to manually construct and send some |
|
I'll see if I can come up with some sample test scripts |
That would be awesome. Otherwise, I would have a look for myself tomorrow. |
import asyncio
import logging
from zeroconf import (
DNSOutgoing,
DNSQuestion,
)
from zeroconf.asyncio import AsyncZeroconf
from zeroconf.const import _CLASS_IN, _FLAGS_QR_QUERY, _TYPE_A, _TYPE_AAAA, _TYPE_ANY
logging.basicConfig(level=logging.DEBUG)
logging.getLogger("zeroconf").setLevel(logging.DEBUG)
name = "SLZB-06.local."
lower_name = name.lower()
async def test_send_a_query_lowercase_a():
"""Send a query with the A record type with the lowercase name."""
aiozc = AsyncZeroconf()
await aiozc.zeroconf.async_wait_for_start()
question = DNSQuestion(lower_name, _TYPE_A, _CLASS_IN)
outgoing = DNSOutgoing(_FLAGS_QR_QUERY)
outgoing.add_question(question)
aiozc.zeroconf.async_send(outgoing)
await asyncio.sleep(3)
async def test_send_a_query_lowercase_aaaa_and_a():
"""Send a query with the AAAA and A record types first.
The A record will have name compression because
it is the same as the AAAA record.
"""
aiozc = AsyncZeroconf()
await aiozc.zeroconf.async_wait_for_start()
question_a = DNSQuestion(lower_name, _TYPE_A, _CLASS_IN)
question_aaaa = DNSQuestion(lower_name, _TYPE_AAAA, _CLASS_IN)
outgoing = DNSOutgoing(_FLAGS_QR_QUERY)
outgoing.add_question(question_aaaa)
outgoing.add_question(question_a)
aiozc.zeroconf.async_send(outgoing)
await asyncio.sleep(3)
async def test_send_a_query_lowercase_any():
"""Send a query with the ANY record type with the lowercase name."""
aiozc = AsyncZeroconf()
await aiozc.zeroconf.async_wait_for_start()
question = DNSQuestion(lower_name, _TYPE_ANY, _CLASS_IN)
outgoing = DNSOutgoing(_FLAGS_QR_QUERY)
outgoing.add_question(question)
aiozc.zeroconf.async_send(outgoing)
await asyncio.sleep(3)
async def test_send_a_query_uppercase_a():
"""Send a query with the A record type with the uppercase name."""
aiozc = AsyncZeroconf()
await aiozc.zeroconf.async_wait_for_start()
question = DNSQuestion(name, _TYPE_A, _CLASS_IN)
outgoing = DNSOutgoing(_FLAGS_QR_QUERY)
outgoing.add_question(question)
aiozc.zeroconf.async_send(outgoing)
await asyncio.sleep(3)
print("Running tests")
print("==============")
print("test_send_a_query_lowercase_a")
print("==============")
asyncio.run(test_send_a_query_lowercase_a())
print("==============")
print ("\n" * 10)
print("test_send_a_query_lowercase_aaaa_and_a")
print("==============")
asyncio.run(test_send_a_query_lowercase_aaaa_and_a())
print("==============")
print ("\n" * 10)
print("test_send_a_query_lowercase_any")
print("==============")
asyncio.run(test_send_a_query_lowercase_any())
print("==============")
print ("\n" * 10)
print("test_send_a_query_uppercase_a")
print("==============")
asyncio.run(test_send_a_query_uppercase_a())
print("==============")
print ("\n" * 10)
print("Done")You'll need to capture the stdout and stderr ie
|
|
@Anto79-ops just sent me his logs. Confirms the device is ignoring the questions for |
this issue should be fixed in 2025.02.0b0
I will look into this, but seemingly can't reproduce here yet. |
@tl-sl thanks! Please ignore my comment about #135870. I don't see that issue anymore. The mdns is the new issue. You may wish to wait maybe 5 minutes after HA startup, then the integration goes offline but the adapter itself works perfectly well. |
|
Another random thought is everyone with the issue using unifi with multicast enhancement turned on? |
Still waiting, its been about 2hrs without errors... |
just checked my settings:
|
|
Here's something you may want to see it seems to come back briefly and then go offline. For example, the history of one of the buttons:
|
No Unifi at all here. See the attached debug log from the script. As @Anto79-ops already said, from time to time the device comes accessible but I can't figure out why. |
In your debug log you get answers right away, and everything responds as expected. I'm starting to think the device doesn't like PTR and SRV records queries in the same request |
@Anto79-ops
|
@jpbede Can you try this version with the other record types? |
Sure, here you go. From my pov, the device has not answered this question. |
|
So it seems that by asking for the TXT and SRV records in addition to the A and AAAA records it causes the query to fail |
|
We don't actually need the SRV and TXT record requests so I've added a new class in zeroconf 0.142.0 to be able to make the request without them |
|
Once thats in we can bump the |
bdraco
added a commit
that referenced
this issue
Jan 30, 2025
19 tasks
|
#136942 to bump to 0.0.2 which will not send the SRV and TXT record queries |
|
Nice, thanks a lot! |
|
Please do reopen if it doesn't solve the issue. The test unit arrives tomorrow so I'll able to do more exhaustive testing when it does. |
|
For the records, I run the v2.7.1 on the SLZB-06, which is the newest firmware. 
|
|
same here, same device and FW. thanks all! |
|
I'm going to close this as fixed for now. Thanks @bdraco for your help! |
|
Confirmed that the device never responds when the query includes the |
|
Also wanted to add, since updating to b2 (8 hrs ago) with the above fix, all is back to normal now. Thanks again, all.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem
hello!
Upon updating to 2025.2.0b0, i noticed thes logs and my SMLite integration entities are unavailable.
Z2M and directly connecting to the adapter are working normally, just the integration is failing. Rebooting the adapter, restores the entities, but after a few minutes, they go back to being unavailable.
might be related to this.thanks
SLZB-06 by SMLIGHT
Firmware: core: v2.7.1 / zigbee: 20240710
What version of Home Assistant Core has the issue?
2025.2.0b0
What was the last working version of Home Assistant Core?
2025.1.x
What type of installation are you running?
Home Assistant OS
Integration causing the issue
SMLight
Link to integration documentation on our website
https://www.home-assistant.io/integrations/smlight/
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: