Missing BT related fields when trying to compile against riscv32imac-esp-espidf (esp32c6) #5
Comments
|
I can offer a reproducible environment leading to this error in my fork, in case you are willing to install Nix. You can then enter a shell with the full environment by running |
|
One more question: when compiling for one of the targets which are part of the CI - like |
|
Yes, riscv32imc-esp-espidf works |
|
Ok. Then it is not *nix specific and I'll look into it. Might take a day or two though. |
oddlama
changed the title
|
You'll need this PR to be merged in In the meantime, I've added the branch supporting this PR to I can't test the project with the esp32c6 right now, as I'm not at home and don't have a c6 chip with me. |
|
Thanks a ton for the quick fix! Works flawlessly on my C6 now! |
The question is if |
|
Sorry I only had time to test it thoroughly today. I tested the "light" example now. There are no obvious errors reported by the device from what I can tell, everything looks like it is working. I just cannot get the device to actually finish commissioning in Home Assistant. But I can see that the Wifi credentials are correctly sent to the device, and it acquires an IP address. The phone just fails to find it afterwards, but this may very well be due to the HA matter addon being experimental. I think you can probably directly tell whether this is device related or HA related issue from the logs: ESP output log |
What happens is that the first part of the commissioning process, which is running over BLE completes successfully. 99% this is due to some sort of mDNS issue, because:
I would check the following:
The reason for the above is that Matter runs over Ipv6. Moreover, more often than not it runs over link-local ipv6 addresses (again, google it, but these are - roughly speaking - something like the 169.254.0.0/16 range that Macs sometimes use when they can't find a DHCP server, except ipv6 link-local addresses are (a) much more popular - basically there is no DHCP in the ipv6 world (b) should almost always be present on your ipv6 NIC even if there are no other ipv6 addresses because - say - your internet provider does not offer ipv6 connectivity). But as I said, link-local only works on a single (or L2/bridged) LAN, as there is no routing involved.
I would not sit on this. HA likely uses the C++ Matter SDK which is the most stable one and is used by basically all the big players (Apple/Samsung/Google/AWS) in production, as they basically created it. With other companies like Espressif participating too. Would it be possible to paste the HA Matter logs here? Also your phone logs? This would:
Another option: Can you try the |
Yes. All devices in my home network have a working link local address and also ULAs that I commission via IPv6 Router Advertisements from my main gateway server. Pinging either of them works fine from any device. While testing this I just noticed that the phone I used yesterday apparently doesn't resolve mDNS addresses (some 6 year old huawei phone). So I repeated the commissioning with a Google Pixel where I tested mDNS resolution beforehand. Still after a while it shows "Unknown Error" while commissioning, pretty much the same as yesterday.
Yes. All devices can reach the HA instance via its IPv6 LLA. While testing I noticed something odd though, I cannot reach the ESPC6 via it's LLA until I ping it once via IPv4:
All devices are physically connected to the same switch, and I would hope that the wifi AP isn't doing any shenanigans. I can at least ping other wifi devices via their LLA without pre-pinging ipv4.
I just repeated the commissioning today, so ignore anything in the logs after yesterday. The attempt from yesterday was at 20:47. HA LogsI could not find any relevant logs on the mobile phone. There are the companion app logs, but they show nothing about the matter commissioning process just about 50 lines of Android UI framework stuff.
I'll check if I have a supported ethernet module lying around somewhere. |
|
Interestingly, I was just able to get the device to commission now, by repeating the process 5 times (actually on the old mDNS-unaware phone). Nothing else has changed, same setup as yesterday. I actually just wanted to get one session of coherent logs to check if the android system logs would contain anything (they didn't), restarted the ESP as usual and this time it worked for whatever reason. I can see ACL errors regularly when the light state changes, but I cannot spot anything that isn't working. Here are the logs: ESP log (3k lines)HA logThe switch state updates are properly sent to Home Assistant and the light can be toggled from there. So except for the commissioning issues, everything seems to be functional. Although after restarting the ESP device it want's to be commissioned again, but to be honest I'm not sure whether persistence is actually implemented in this project. |
This sounds weird! Will try it out myself.
No - if you look at the |
That's "ok". We have to remove the error logs from AclMgr, as they are confusing (and are not really errors).
Persistence is currently commented out. It was supposed to be implemented (tested actually) more than a month ago, but there is something more important constantly popping up. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Transfer of esp-rs/esp-idf-svc#442; Summary:
When I'm trying to compile this for the esp32c6 using riscv32imc-esp-espidf, I run into the following issue:
It happens on esp-idf v5.2 and v5.2.2. EDIT: As we found out later it seems to be related to the architecture.
Full cargo build error
The text was updated successfully, but these errors were encountered: