Hopefully you are right.
Mine showed up yesterday from them and I had to do the same thing. Lol
1 Like
Wait, you had to sign something before or after they shipped.
Before. To state we were not shipping out of the country.
Received an order confirmation on June 2nd. I didnāt see the attached form requiring the need to āsign my life awayā until today!! Hope mine arrives in time for the session.
My guess (completely without evidence), is something like an ESP32-C3 version of ESPhome or something simpler like a config / onboarding process based on Improv or even BTLE which needs access to hardware outside the container.
1 Like
Is IPV6 required to run the demo?
Iāve seen documentation that implies that Matter might require IPV6 (e.g. this espressif blog ). Iāve currently got IPV6 disabled on my internal network / WiFi and was wondering if I need to get this setup before the workshop?
The current version (that the workshop will probably be using, possibly with a few small last minute tweaks) is using a client server approach over websockets, similar to ZWave-JS, but both ends are python (with the server side portion utilizing the c++ code from the matter SDK).
So a self-contained component that does not need a separate server is quite possible, and could potentially be the final state. One complication is that building the upstream repo to a python wheel for easy installation is a bit complicated, as it has a native component, and does not follow normal python packaging standards. Just about everything related to this is actively being developed and changed. They may not have even decided on the final design of the component.
A separate server does have some advantages, like allowing for an independent patching cycle, less GIL contention, better isolation (the server crashing due to a bug in the C++ code wonāt take down all of core), etc. The downside is somewhat increased setup/deployment complexity.
Matter has standardized connectivity over BTLE for comissioning tasks, including setting wifi network and password, (and similar setup for providing information needed to join a thread network).
My understanding is that Matter is based exclusively on IPv6, but that you might not need to enable IPv6 on the router, unless the router is actively blocking LAN based IPv6 connectivity.
The default behavior of a Wifi access point is to be bridged to ethernet, allowing even unknown ethertypes to seamlessly flow. Thus by default in order to break IPv6 working between Wifi and local ethernet, the āwifi routerā would need to be selectively bridging (which would basically be a layer-2 firewall) or be routing rather than bridging between Wifi and LAN ethernet. Iāve never heard of a router access-point combination device doing the latter unless you specifically configure it to do so.
So while it certainly possible that your router access point combination device could break local-only IPV6 by actively filtering it from the bridging when the setting is off, that setting is typically only related to the actual LAN to WAN routing functionality like: enabling IPv6 level routing, using DHCPv6 or using Router Advertisements to determine WAN IPv6 prefix, enable a stateful firewall (consumer-style NAT provides equivalent stateful firewall functionality automatically for ipv4).
@KevinCathcart Thanks Kevin, I have a UniFi setup, and I think all Iāve done is to disable IPV6 for WAN to LAN and inter LAN routing (i.e. between sub networks) so providing I keep the host and end device on the same subnet I should be OK. Still to get my head around IPV6 - I enabled it internally once my ISP offered it, but it seemed to stop all sorts of internal service operating correctly; clearly I have a lot to learn.
UniFi is one of the ones where you could break ipv6 working between Wifi and ethernet. But as long as the (virtual) access point in question is bridged to ethernet (v)LAN, I would expect it to work. I am not familiar enough with the UniFi products to be certain of this, but it would be unusual to do otherwise.
Generally, the bridging vs routing boundaries will follow the ipv4 subnets (this not technically required, but few people try to do otherwise), so as long as the (virtual) access point you are using uses the same subnet as the ethernet (v)lan you have home assistant on, it will probably just work.
If not then you might need to enable ipv6 routing between LAN subnetworks, but should not require it WAN-to-LAN.
Makes sense, so a bit like Zigbee2MQTT, but with an API I guess?
Anyway, Iām pretty convinced an addon will not be the only way. Definitely you would be able to use a āstandaloneā container. Now, will they support a pure software install is to be seenā¦
Interesting - Iāve got as far as the need for IPv6 addressing and āfabricā encryption, but not the mechanism and transports for set-up. Google Play Services seem to wrap this process up completely making the Android Google Home sample app more of a set of stub API-calls. āLocal fabricā smells a lot like a self-signed certificate / credentials.
Matter seems to be fairly resource intensive due its use of Wi-Fi radios and encrypted IPv6, meaning battery powered devices will use Zigbee/ BLE/ Thread (/ Z-Wave?) requiring hub Border Routers even when the costs of micro-controllers with cryptographic accelerators drops.
Some initial research suggests existing ESP12 / ESP8* canāt support Thread (no IEEE 802.15.4) and Matter might be a struggle (no hardware encryption). Plain-text MQTT works well enough on the LAN, although it would be good if IPv6 was supported.
Tried to get the idf environment compiled, has anyone really solved the libusb-1.0.0dev problem?
Just tried that with the code sample from the ESPHome docs:
esphome:
name: "c3-devkitm-1"
comment: "Testing the ESP32-C3-DevKitM-1 board"
esp32:
board: esp32-c3-devkitm-1
framework:
type: esp-idf
version: recommended
# Custom sdkconfig options
sdkconfig_options:
CONFIG_COMPILER_OPTIMIZATION_SIZE: y
# Advanced tweaking options
advanced:
ignore_efuse_mac_crc: false
But it does not compile:
INFO Reading configuration /config/esphome/esp32c3devkitm1.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing c3-devkitm-1 (board: esp32-c3-devkitm-1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
Tool Manager: Installing espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
Error: Could not find the package with 'espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2' requirements for your system 'linux_aarch64'
System is latest stable HA / HAOS 64 bit with everything up-to-date (but not beta or dev) running on RPi 4b. Compilation was started through the web frontend of the ESPHome add-on.
1 Like
There is whole thread about this. Short answer, compile it on an amd64 machine.
1 Like
I tried to find discussions about that problem, but didnāt. Could you add a link?
I hope that Intel is possible too. No AMD available.
Amd64 covers intel and amd. Iāll try and find the link.
Edit First ESPHome project (ESP32-S2 feather board) stuck on initial configuration install
1 Like
Yepp, that explains it all. Thanks!
I am very curious how code for this dev board will be compiled during the workshop. From the OP I conclude that RPi should be fine.
1 Like