project-chip / rs-matter Goto Github PK

Hi, I'm implementing some of the clusters related to audio devices - level control, audio output, etc.
I will open a PR for them soon but there are some long-running commands that cause issues.

Specifically with level control - A lot of the commands contain optional transition time - they can take up X amount of seconds to complete. This obviously can't block the main thread as everything will time out and we need to issue a response right after we process it.
In order to have it run in the background, I've implemented a background thread for the level control cluster that will update some values and the main thread can update the data model from that whenever a command is issued. This has a problem currently - values are updated from this update-store only on writes, read interactions are not processed through the specific cluster implementations. So if we're slowly updating the level of a device from X to Y in the background, reads will not show this until an actual cluster commands is issued.

My question is, should I make this like a cluster trait for all clusters to implement on top of if needed? I assume some other clusters to be implemented in the future will also require handling of long running commands.

Any suggestions, or other ideas how to do this properly ?

I'm unable to use the project as a dependency on an ESP32 based project.

Please see a minimal reproduction at https://github.com/nevi-me/esp32-c3-matter-minimal. The summary is that some of the dependencies don't yet support the esp-idf framework. The esp-rs folks are aware of some of them, as there are forks at https://github.com/esp-rs-compat.

Follow-up on #66

Here a Result is returned, whereas an error case is not handled. Since no error case is handled, I'd like to suggest returning Self instead of a result, which would remove a lot of question mark operators within the library. This is not a minor refactor, therefore I'd like to post it as an issue first. Would love to hear what you think!

1. generated a new project with cargo generate esp-rs/esp-idf-template cargo
2. added rs-matter as a dependency
3. copied the onoff_light example code into it
4. used the provided command from the README.md
   export MCU=esp32; export CARGO_TARGET_XTENSA_ESP32_ESPIDF_LINKER=ldproxy; export RUSTFLAGS="-C default-linker-libraries"; export WIFI_SSID=ssid;export WIFI_PASS=pass; cargo build --no-default-features --target xtensa-esp32-espidf -Zbuild-std=std,panic_abort

expected: successful build
outcome: error: failed to run custom build command for rs-matter v0.1.1
Error: environment variable not found

quite not sure which env variable is not set

Branch : no_std
Platform : Darwin arm64 (M1 Mac Book Pro)

When trying to run the example on M1 Mac I get the following error.
I might have time to investigate this later in the meantime I'm leaving this here:

matter-rs % bash -c "RUST_BACKTRACE=1 cargo run --example onoff_light"
warning: Patch `polling v2.2.0 (https://github.com/esp-rs-compat/polling#0a016089)` was not used in the crate graph.
Patch `smol v1.2.5 (https://github.com/esp-rs-compat/smol#15918c3c)` was not used in the crate graph.
Patch `socket2 v0.4.5 (https://github.com/esp-rs-compat/socket2#afeb7231)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Finished dev [optimized + debuginfo] target(s) in 0.26s
     Running `target/debug/examples/onoff_light`
[2023-06-30T07:59:59Z INFO  onoff_light] Matter memory: mDNS=320, Matter=12080, Transport=39736
[2023-06-30T07:59:59Z INFO  onoff_light] Will use network interface en0 with 10.5.221.91/fe80::1ca2:f0c3:35b1:2a5d for mDNS
[2023-06-30T07:59:59Z INFO  onoff_light] Persisting from/to /var/folders/zf/jdpvrr2n04v_pgcx1_hjkn300000gn/T/matter-iot
[2023-06-30T07:59:59Z INFO  matter::transport::core] Starting Matter transport
[2023-06-30T07:59:59Z INFO  matter::pairing::code] Pairing Code: 0087-6800-071
[2023-06-30T07:59:59Z INFO  matter::pairing::qr] QR Code: MT:Y.K90Q1212Z6Q66D33P084L90Z.I332SQ43I15T0
[2023-06-30T07:59:59Z INFO  matter::pairing::qr] 
    █████████████████████████████████████
    █████████████████████████████████████
    ████ ▄▄▄▄▄ █▀██ █▀▀▄ █  ▄█ ▄▄▄▄▄ ████
    ████ █   █ █ ▀█▀▄▄█▄▀▄ ▄▄█ █   █ ████
    ████ █▄▄▄█ ██▄ █ ██ ▄ ▀▀▀█ █▄▄▄█ ████
    ████▄▄▄▄▄▄▄█ █▄█ █ ▀ █ █ █▄▄▄▄▄▄▄████
    ████▄▀▀▀▀▀▄█▄▀█ █▀██ ▀ ██▄ ▀▀ ▄ ▀████
    ████▀█  ▀▀▄ ▄▄▀▄▄ ▄▄▄█▀█▄██▄ ▄▀▀▄████
    ████▀ ▀ █▄▄▀▄▀▀█ ▄█▄ ▀ ▀█ ██   ▀▀████
    ████ █  █▀▄█  ▄▀▀██▀█▀█ ▀▄ ▀ ██ ▄████
    ████▀▄▄█▄ ▄ ▀ ▀ ▄▀▀█▄▀█▀▄▄▀▄▄▀ ▀ ████
    ████ ▄▀█▄█▄ ▄█▀▄█▀█▄█▄▄▄█▄█  ▄  ▀████
    ████▄█▄██▄▄█▀▀   █ ▄█▀█▄ ▄▄▄ ▄▀▀▄████
    ████ ▄▄▄▄▄ ██▀█ ▄█▀▀▀▀ ▀ █▄█ ▄▄ ▄████
    ████ █   █ ██ ▀█▄▄ █▄▀██▄▄▄ ▄▄ ▀▄████
    ████ █▄▄▄█ ██ ▀▀ ▄█▄▀▄▀█▀▄▀ ▀  ▄█████
    ████▄▄▄▄▄▄▄█▄█████▄▄██▄▄█▄██▄█▄▄█████
    █████████████████████████████████████
    ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
[2023-06-30T07:59:59Z INFO  matter::transport::core] Comissioning started
[2023-06-30T07:59:59Z INFO  matter::transport::udp::smol_udp] Listening on [::]:5540
Error: Error::StdIoError {
   0: std::backtrace::Backtrace::create
   1: matter::error::Error::new
             at ./matter/src/error.rs:93:24
   2: <matter::error::Error as core::convert::From<std::io::error::Error>>::from
             at ./matter/src/error.rs:141:9
   3: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/result.rs:2002:27
   4: matter::transport::udp::smol_udp::UdpListener::new::{{closure}}
             at ./matter/src/transport/udp.rs:39:25
   5: matter::mdns::builtin::MdnsRunner::run_udp::{{closure}}
             at ./matter/src/mdns/builtin.rs:124:76
   6: onoff_light::run::{{closure}}
             at ./matter/../examples/onoff_light/src/main.rs:223:63
   7: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/future/future.rs:125:9
   8: <&mut F as core::future::future::Future>::poll
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/future/future.rs:113:9
   9: <embassy_futures::select::Select<A,B> as core::future::future::Future>::poll
             at /Users/nikolasvonlonski/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-futures-0.1.0/src/select.rs:55:33
  10: onoff_light::run::{{closure}}
             at ./matter/../examples/onoff_light/src/main.rs:225:71
  11: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/future/future.rs:125:9
  12: <&mut F as core::future::future::Future>::poll
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/future/future.rs:113:9
  13: async_io::driver::block_on
             at /Users/nikolasvonlonski/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-1.12.0/src/driver.rs:146:33
  14: onoff_light::run
             at ./matter/../examples/onoff_light/src/main.rs:228:5
  15: core::ops::function::FnOnce::call_once
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/ops/function.rs:250:5
  16: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/sys_common/backtrace.rs:134:18
  17: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/thread/mod.rs:526:17
  18: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/panic/unwind_safe.rs:271:9
  19: std::panicking::try::do_call
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/panicking.rs:485:40
  20: std::panicking::try
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/panicking.rs:449:19
  21: std::panic::catch_unwind
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/panic.rs:140:14
  22: std::thread::Builder::spawn_unchecked_::{{closure}}
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/thread/mod.rs:525:30
  23: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/ops/function.rs:250:5
  24: std::sys::unix::thread::Thread::new::thread_start
  25: __pthread_joiner_wake
}

Hi,

Thanks for picking up the work to create a Rust version of the Matter implementation. Not an easy endeavour.
I've done a bit of experimenting with your "old" repository and am looking forward to see how this work develops.

My main objective is to replace the current HomeKit bridge that was developed with (https://github.com/ewilken/hap-rs) with a Matter equivalent.

I have an Apple eco-system with Somfy smart devices and use the bridge to connect the two worlds.
If needed, I may be able to help test your code with Apple Home.

Kind regards,
Marcel

PS.
I'll do a PR that implements a bunch of Clippy suggestions. That should help quiet the compilation. 😄

On M1 on the sequential branch running the onoff_light example and commissioning with Apple Home the device is unable to be commissioned.
Using chip-tool it works.

I'm able to commission my own custom devices based on the main repo (project-chip/connectedhomeip) just fine.

The only Error I can see in the log is the following :

[2023-07-12T11:15:48Z ERROR matter::acl] ACL Disallow for subjects [1921388213, ] fab idx 1
[2023-07-12T11:15:48Z ERROR matter::acl] ACLS: []

Any pointers in the right direction would be appreciated.

Here is the full log :
error.log

I'm almost starting a zigbee project in rust. Will this project eventually have zigbee support? I'd like to not reinvent the wheel

reproduction:

1. cloned the current main branch and run cargo build on my machine
2. opened the Alexa App on my phone to add a new device, a matter device was recognised suggested
3. scanned the QR code from the terminal with the phone

expected: successful pairing
outcome: The Alexa App says: "Something gone wrong, an unexpected error occurred, please try again later" (Translated)

the important lines could be

[2023-10-03T15:07:59Z ERROR rs_matter::secure_channel::case] Certificate Chain doesn't match: Invalid: 
[2023-10-03T15:07:59Z ERROR rs_matter::tlv::parser] Invalid value found: 0 self TLVListIterator { buf: [1, 0, 0, 0, 0, 0, 2, 0], current: 8 } size 1

log.txt

I'm confused where I would add user code to actually do something with the on/off commands are received, am I missing something from the example code? It would seem that this is internally handled by OnOffCluster with no ability for me to observe changes like we see with other clusters like MediaPlaybackCluster. Perhaps we could include some simple print debugging or something when the user code would be expected to interact with a physical device to make this clearer for folks?

Turns out the reason is we don't (yet) support the RevokeComm command on the admin cluster.

My next branch has an impl that fixes the issue. To be merged soon, hopefully.

After implementing PR #7 the pairing of the onoff_light can be started from Apple Home using the QR code.
It prompts the user that the device is uncertified. After confirming the dialog, the process continues.
Ultimately the onboarding fails, indicating that the accessory could not be paired.
In the logs there is no error, or an indication as to what went wrong:

2023-01-11-matter_rs_log-1.log

It would be useful for us to have code coverage in CI, especially for the crypto backends.
Depending on what service we use, this might require some integrating the repo to an external service, e.g. coveralls.

I can work on the Github Actions part and figure out how coverage will work for mutually exclusive targets, then I can leave some instructions for how a repo admin can enable CI on a service.

Nightly Rust on Debian 10

nightly-x86_64-unknown-linux-gnu (overridden by '/home/chung/repos/matter-rs/rust-toolchain.toml')
rustc 1.70.0-nightly (478cbb42b 2023-03-28)

❯ RUST_BACKTRACE=1 cargo run --example onoff_light
    Finished dev [optimized + debuginfo] target(s) in 0.09s
     Running `target/debug/examples/onoff_light`
[2023-07-10T04:54:36Z INFO  onoff_light] Matter memory: mDNS=320, Matter=12080, Transport=39736
[2023-07-10T04:54:36Z INFO  onoff_light] Will use network interface enp3s0 with for mDNS
[2023-07-10T04:54:36Z INFO  onoff_light] Persisting from/to /tmp/matter-iot
[2023-07-10T04:54:36Z INFO  matter::transport::core] Starting Matter transport
[2023-07-10T04:54:36Z INFO  matter::pairing::code] Pairing Code:
[2023-07-10T04:54:36Z INFO  matter::pairing::qr] QR Code: 
[2023-07-10T04:54:36Z INFO  matter::pairing::qr] 
[2023-07-10T04:54:36Z INFO  matter::transport::core] Comissioning started
[2023-07-10T04:54:36Z INFO  matter::transport::udp::smol_udp] Listening on [::]:5540
Error: Error::StdIoError {
   0: matter::error::Error::new
             at ./matter/src/error.rs:93:24
   1: <matter::error::Error as core::convert::From<std::io::error::Error>>::from
             at ./matter/src/error.rs:141:9
   2: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/result.rs:2067:27
   3: matter::transport::udp::smol_udp::UdpListener::new::{{closure}}
             at ./matter/src/transport/udp.rs:39:25
   4: matter::mdns::builtin::MdnsRunner::run_udp::{{closure}}
             at ./matter/src/mdns/builtin.rs:124:76
   5: onoff_light::run::{{closure}}
             at ./matter/../examples/onoff_light/src/main.rs:223:63
   6: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/future/future.rs:125:9
   7: <&mut F as core::future::future::Future>::poll
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/future/future.rs:113:9
   8: <embassy_futures::select::Select<A,B> as core::future::future::Future>::poll
             at /home/chung/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-futures-0.1.0/src/select.rs:55:33
   9: onoff_light::run::{{closure}}
             at ./matter/../examples/onoff_light/src/main.rs:225:71
  10: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/future/future.rs:125:9
  11: <&mut F as core::future::future::Future>::poll
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/future/future.rs:113:9
  12: async_io::driver::block_on
             at /home/chung/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-1.12.0/src/driver.rs:146:33
  13: onoff_light::run
             at ./matter/../examples/onoff_light/src/main.rs:228:5
  14: core::ops::function::FnOnce::call_once
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/ops/function.rs:250:5
  15: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/sys_common/backtrace.rs:134:18
  16: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/thread/mod.rs:525:17
  17: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/panic/unwind_safe.rs:271:9
  18: std::panicking::try::do_call
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/panicking.rs:485:40
  19: std::panicking::try
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/panicking.rs:449:19
  20: std::panic::catch_unwind
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/panic.rs:140:14
  21: std::thread::Builder::spawn_unchecked_::{{closure}}
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/thread/mod.rs:524:30
  22: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/core/src/ops/function.rs:250:5
  23: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/alloc/src/boxed.rs:1988:9
  24: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/alloc/src/boxed.rs:1988:9
  25: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/478cbb42b730ba4739351b72ce2aa928e78e2f81/library/std/src/sys/unix/thread.rs:108:17
  26: start_thread
  27: __clone
}

I got the onoff_light example working on my ESP32-C3-DevKitM-1 (after some tweaking to remove IPv6 support, see #100), but I'm having a couple of issues getting the device to appear and be controllable from Google Home.

First, trying to scan the QR code doesn't work and immediately produces an error as soon as I move my phone camera nearby to the QR code (see [1] below). If I switch to manually entering the pairing code things progress and I see a lot of log spamming from the device (which all looks successful generally and nothing appears to timeout).

Second, after seemingly trying to pair with the new device and bring it into Google Home I'm presented with [2] and I can't do anything to try again or proceed, only back out.

Full logs from boot-up attached here: https://gist.github.com/jasta/ed826fed780f9cc6109499b3fbe4f852

Is this expected? If no, anything I can try to do to debug and figure out what's wrong? I was able to successfully add a device using the main C++ matter repository and the all-clusters-app example and it seemingly worked well even to control the device. This was however a few months ago with a beta of Google Home.

[1]
[2]

EDIT: Apologies I just realized the screenshots are in Spanish. [1] is saying that it's not a matter QR code, and [2] is saying that the device isn't certified for use with Matter.

I'm trying to commission a test device utilizing this crate with a SmartThings Hub. It's currently failing to establish CASE, and I've tracked it down to the verification of the initiator ICAC sent by the controller to the device.

This is what I could find in the spec about validating the Sigma3 message:

The responder SHALL verify that the NOC in TBEData3.responderNOC and the ICAC in TBEData3.responderICAC fulfill the following constraints:
a. The Fabric ID SHALL match the Fabric ID matched during processing of the Destination
Identifier after receiving Sigma1.
b. If an ICAC is present, and it contains a Fabric ID in its subject, then it SHALL match the Fab
ricID in the NOC leaf certificate.
c. The certificate chain SHALL chain back to the Trusted Root CA Certificate TrustedRCAC whose
public key was matched during processing of the Destination Identifier after receiving Sig
ma1.
d. All the elements in the certificate chain SHALL respect the Matter Certificate DN Encoding
Rules, including range checks for identifiers such as Fabric ID and Node ID.

The only validation specified for ICAC is that the fabric ID matches that of the NOC leaf certificate, which appears to be done here:

I've verified that that is occurring with log statements. However, just below that, it is failing to add the cert to the verifier. From adding my own logs, I've determined that it is failing here:

The ICAC has no subject key ID extension, so the function returns an error. Given that the ST Hub is Matter certified I suspect that something is overly strict with this certificate verification. However, this is out of my realm of expertise.

I also logged the ICAC following the parsing from TLV in case that's helpful:

Cert { 
    serial_no: OctetStr([67, 38, 73, 198, 26, 31, 20, 101, 57, 46, 16, 143, 77, 160, 128, 161]), 
    sign_algo: 1, 
    issuer: DistNames { 
        dn: [(20, Uint(15512483513290480383))] 
    }, 
    not_before: 718486395, 
    not_after: 874187555, 
    subject: DistNames { 
        dn: [(19, Uint(14440658877384716286))] 
    }, 
    pubkey_algo: 1, 
    ec_curve_id: 1, 
    pubkey: OctetStr([4, 88, 188, 13, 87, 50, 3, 213, 248, 182, 12, 240, 164, 220, 127, 150, 65, 81, 244, 125, 24, 48, 203, 83, 111, 133, 175, 182, 10, 40, 80, 147, 28, 39, 121, 183, 61, 159, 178, 231, 133, 75, 189, 143, 136, 191, 254, 115, 228, 186, 129, 56, 137, 213, 177, 13, 46, 97, 202, 95, 41, 5, 16, 24, 228]), 
    extensions: Extensions { 
        basic_const: Some(BasicConstraints { is_ca: true, path: Some(0) }), 
        key_usage: None, 
        ext_key_usage: None, 
        subj_key_id: None, 
        auth_key_id: Some(OctetStr([243, 119, 107, 152, 3, 212, 205, 76, 85, 38, 158, 240, 27, 213, 11, 235, 33, 21, 38, 5])), 
        future_extensions: None 
    }, 
    signature: OctetStr([70, 43, 150, 195, 194, 170, 43, 125, 91, 213, 210, 221, 175, 131, 131, 85, 22, 247, 213, 18, 101, 189, 30, 134, 20, 226, 217, 145, 41, 225, 181, 150, 28, 200, 52, 237, 218, 195, 144, 209, 205, 73, 88, 114, 139, 216, 85, 170, 63, 238, 164, 69, 35, 69, 39, 87, 211, 234, 57, 98, 19, 43, 13, 0]) 
}

• Generate appropriate error codes as per the spec
• Overall robustness/state machine for state cleanup during error scenarios

Hello there,

I have a suggestion regarding the print_pairing_code_and_qr() function. Currently, it accepts comm_data: &CommissioningData as an argument. However, according to section 5.1 of the Matter-1.0-Core-Specification, both MPC and QR Code require a passcode.

The CommissioningData has either VerifierOption::Password or VerifierOption::Verifier. In my understanding, passing VerifierOption::Verifier instead of VerifierOption::Password as an argument to print_pairing_code_and_qr() will result in a runtime error.

To avoid this issue, I recommend passing VerifierOption::Password as the argument to print_pairing_code_and_qr() instead.

(@kedars We should probably open the "Discussions" functionality in the GH project, and then make one item there, "Meetings". Or at least this is what the esp-rs folks practice.)

CC: @jasta @MabezDev @jessebraham

Overall: Intro, availability of folks

• Participants: @kedars, @bjoernQ, @ivmarkov

Did a review of the existing issues / errors:

• #109

  • Hypothesis 1: (Kedars) extra/changed parameters in the ASN.1 certificate encoding that need processing
  • Hypothesis 2: (Ivan) the Fabric ID coming with the cert does not match the one in the session (?)
  • Action: @ivmarkov to try to repro the bug with his Alexa controller

• #103

  • Will be addressed by PR #107

• #102 (also PR #107)

  • Seems Matter C++ SDK returns empty string instead of UnsupportedAttribute (to be confirmed)
  • Kedar reported that for him provisioning does work with a Matter C++ SDK device (but then again, that might be because the C++ SDK returns an empty string)
  • Action: @kedars to check with chiptool the Matter C++ device what exactly it returns for UniqueId - empty strong or not
  • Action: @kedars to check another optional attribute with the Matter C++ device; if both return default values with the Matter C++ SDK then we should do the same; if only UniqueId returns a default values, we should treat it as a special case, as we do now

• #100

  • Action: @kedars, Merge

• #108

  • Agreement is we would not be doing this
  • Action: @kedars, Close

• #94

  • Action: @kedars, Merge

• #101

  • The source of confusion here is that the OnOffCluster sample implementation is part of the rs-matter library, while it should be provided as part of the example, to make it clear that users should provide their own one
  • Action: @ivmarkov - open a PR

Did a review of the longer term roadmap; Top 3 roadmap items seem to be:

• #41

  • In a way this is also the way to provision for Wifi
  • Also the way to provision for Thread
  • Ivan noted that there is another way for WiFi provisioning (SoftAP with a special name, according to the spec)
  • Action, @kedars - to check if any company has implemented this ^^^ else it might become optional part of the spec and would not be a widely used feature anyway
  • Bjoern mentioned that he is looking into Thread support; seems that also is a sub-item of BLE provisioning

• #35

  • Ivan suspects the lack of this is the reason why provisioning with Google controller fails with "device not found" at the end, however Kedar believes this is most likely an mDNS issue (so much easier to fix)
  • In any case consensus is we need this functionality
  • Ivan mentioned this would most likely need Exchange in Initiator mode to be supported; Kedar believes it should actually be a long-running Exchange initiated by the controller
  • Action, @kedars, all: check in the spec if subscription events are delivered over a long running Exchange/Transaction opened by the controller, or (as Ivan believes) each subscription report is a new exchange initiated by the device

• #37

  • Should be relatively easy to implement, now that we are async based
  • (Not mentioned during the discussion) After that we probably need another roadmap item - "Consolidate most of exchange logic in ExchangeMgr"; also related to #35 ^^^

• #36

  • Not one of the top 3, but maybe still important; Kedar explained this is the vehicle for delivering notifications of a type "new fabric was provisioned", which might be important
  • Action, @kedars - check if this part of the spec is actually implemented by anybody

I hope this message finds you well. I am reaching out to kindly request the upload of the matter-rs packages to crates.io in order to facilitate their usage in our projects.

We have been eagerly following the development of matter-rs and are impressed by its features and potential benefits for our projects. However, we have encountered difficulty in accessing the crates through crates.io, which is the primary repository for Rust packages.

To ensure seamless integration and compatibility within our projects, we kindly request that you consider publishing the matter-rs packages to crates.io. This will enable us and other members of the Rust community to easily include and utilize this valuable resource in our development workflows.

We understand the effort and dedication required to maintain and distribute crates, and we truly appreciate your contribution to the Rust ecosystem. By making the matter-rs packages available on crates.io, you would greatly enhance their accessibility and encourage wider adoption among developers.

Thank you for your time and consideration. We look forward to your positive response and eagerly anticipate the availability of the matter-rs packages on crates.io.

I am new to matter and do not know anything about it.
The readme.md mentions a chip-tool, but there is no link to this tool.
At first, I thought that I installed this tool via espup, but that is not the case.
Through googling, I found this site and I guess that is the mentioned tool?

It would make sense to explain in the readme, how one can install the tool/where one can find it.

Environment
Chip: ESP32-C3-MINI-1
Hardware: ESP32-C3-DevKitM-1
Platform: esp-idf (Rust std)

Problem
I likely have something misconfigured on my network causing IPv6 broadcasts to yield a surprising "Host is unreachable" error, however the more important issue is that the way the master future is structured in my example (and onoff_light) causes the entire Matter runtime to effectively shutdown and not automatically restart.

An abridged version of the log shows the issue:

I (7607) rs_matter::transport::core: Comissioning started
I (7617) rs_matter::transport::core: Creating queue for 1 exchanges
I (7617) rs_matter::transport::core: Creating 8 handlers
I (7627) rs_matter::transport::core: Handlers size: 9992
I (7637) rs_matter::transport::core: Transport: waiting for incoming packets
I (7647) rs_matter::transport::udp::async_io: Listening on [::]:5353
I (7647) rs_matter::transport::udp::async_io: Joined IPV6 multicast ff02::fb/2
I (7657) rs_matter::transport::udp::async_io: Joined IP multicast 224.0.0.251/192.168.86.32
I (7667) rs_matter::mdns::builtin: Broadcasting mDNS entry to 224.0.0.251:5353
I (7687) rs_matter::mdns::builtin: Broadcasting mDNS entry to ff02::fb:5353
W (7697) rs_matter::transport::udp::async_io: Error on the network: Os { code: 118, kind: HostUnreachable, message: "Host is unreachable" }
Error: Error::Network

The last line in particular appears to be coming from the master future in the onoff light example: https://github.com/project-chip/rs-matter/blob/main/examples/onoff_light/src/main.rs#L165

This is "fixed" by just disabling IPv6 for me, but I do think this highlights some bigger issues with the error handling robustness inside the runtime. In particular I'd expect that the IPv4 and IPv6 behaviour be separated into separate futures that can error out independently and that one reaching a terminal state wouldn't negatively impact the other. Further I think some measure of error handling policy is appropriate (Host is unreachable seems like it should probably be retryable for example). I could take a crack at a patch but I do worry based on the current state of the code that it might be a bit intrusive. Any guidance from the maintainers would be greatly appreciated before getting started!

Thanks again for this awesome project, it's renewed my interest big time in IoT :)

Add an error: Box<dyn std::error::Error> member to the Error enum here. Then include the original error message (and possibly its backtrace, if any) in the Debug and Display impl for the matter-rs Error enum.

Just like the backtrace member, it should be enabled only when both std and backtrace features are enabled, as it would be bringing non-trivial cost to the unhappy path.

Yet very useful for proper diagnostics of errors originating outside of matter-rs itself.

When an interaction arrives at the device, the TLV contents are logged, but it's not easy to get the cluster path or attribute being read. The general commissioning cluster handlers have some code for invoke commands, but it'd make it easier to debug from log captures if the log line included information about the cluster being queried in a ReadRequest or other requests, like in #102

Handle error scenarios gracefully

Hello matter-rs,

sorry for creating a non-issue. Please simply close it if that is not interesting for you.

I‘m one of the maintainers of matter.js (also project under project-chip orga) and we implement matter in JavaScript/typescript.

To support the open source community in developing with and for matter I also created a discord called „matter-integrators“ where I would like to invite you. There are already other open source projects like the tasmota matter implementations in and beside building a developer community it also started to be a good place to exchange opinions on matter specs and how to read/interpret it ;-).

Thank you and maybe see you there ;-)

Ingo

During pairing with Apple Home a panic was triggered in crypto_mbedtls.rs.
This happened only once and I was unable to reproduce the issue so far. Will update this issue if it happens again.

[2023-01-15T10:52:02Z INFO  matter::data_model::sdm::noc] Handling Command CSRRequest
[2023-01-15T10:52:02Z INFO  matter::data_model::sdm::noc] Received CSR Nonce:OctetStr([52, 226, 46, 191, 82, 255, 246, 250, 115, 248, 188, 209, 33, 137, 211, 219, 31, 19, 195, 59, 234, 232, 71, 18, 40, 161, 131, 213, 218, 57, 218, 134])
thread 'main' panicked at 'attempt to subtract with overflow', src/crypto/crypto_mbedtls.rs:290:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

To run this on an MCU it would be beneficial to support no_std environments

I did a POC "from scratch" which is no_std and no_alloc here: https://github.com/bjoernQ/bare-matter (the code is very bad but might be an inspiration)

I guess making this completely no_alloc will be hard but at least no_std should be possible

Hi,

The instructions for how to build rs-matter for esp-idf were removed in pull request #129 citing that support was upstreamed. Unfortunately it is now unclear from looking at the repository whether using matter-rs on an ESP32 is supported, and if so what networking stack is supported (wifi, threads... etc).

Some clarification with minimal build instructions on how to build rs-matter for ESP-IDF would be amazing.

This project looks really cool to me to build some easy and cross compatible lights with something like a raspberry pi or any other wireless connected device. I'd really like to use it with my custom built light, without needing to implement something specific to my current solution (I currently use HomeAssistant MQTT). It would be really nice to have dimmable, CCT, RGB and RGB-CCT lights supported by this SDK, that could make it really cool for home projects. (Also switches would be a great addition, but one thing at a time)