Adventures with Matter protocol on Tasmota

[s-hadinger]

The time has come! Tasmota support for Matter protocol is progressively building. This thread will allow you to follow progress.

This first milestone implements device commissioning over Wifi. It works with the reference tool chip-tool but is not yet validated on Alexa and not tested on iOS.

To compile you need to add #define USE_MATTER_DEVICE. Once compiled with Matter support, you need to do SetOption151 1 to enable Matter support, or use the WebUI. The code is almost entirely in Berry code solidified in Flash, the impact on RAM is very low.

Tasmota is constantly in Provisioning Mode. When pairing Tasmota, you will need either the Manual Pairing Code (11 digits) or the QR Code:

[MrJelly17]

Does anyone know how to use the virtual contact sensor to match the status of a real relay?

[s-hadinger]

Please open a new discussion, and provide more information about what you are trying to achieve

[M4rkoV2]

Should Tasmota Matter also work with Samsung SmartThings?

I can not get it to work. It won't connect successfully:

[Johnnybegoode13]

Did you get it to work in the end?

[M4rkoV2]

No. I used Edge Tasmota to connect it with Smartthings.

[Johnnybegoode13]

Ok thanks. That's what I'm using now but liked the idea of using Matter - everything else Matter I've tried runs well with ST. Had seen another guy on the ST community site.
https://community.smartthings.com/t/tasmota-on-esp32-conected-via-matter/272430?u=johnnybegoode

[s-hadinger]

Message to all. Matter has now achieved official support since Tasmota v13. This discussion was exploratory, and it's getting too long.

I am now closing this discussion. New questions or discussions around Matter needs to happen on new (and shorter) discussions.

Thanks to all, it's been fun. And it's only the beginning!

[tokamac]

The behavior has changed in Tasmota 13. When I now add my Matter accessory to Apple Home, it needs to create a bridge first, then the accessory itself. My accessory is a single light, the additional bridge adds unnecessary clutter to HomeKit.
How to proceed to have the previous behavior? That is to say, add a Matter accessory straightforward without any bridge creation?

[Jason2866]

Nothing has changed in Matter. The way it is included in standard Tasmota32 is the same as it was in the extra matter Tasmota32 version. So it is a coincedence.

[deepcoder]

@Jason2866 I don't understand why there is not a 'standard Tasmota ESP32 latest development' image here???? Everything else, however no 'standard'. I am trying to test your Matter implementation, there used to be a specific image for this. However, as you relayed to me, this has been integrated into the 'standard Tasmota32'. Well, that is what I want to test! Thanks for your work and help, give me a straightforward set of steps to download this latest build of the 'standard Tasmota32' image.

https://github.com/Jason2866/Tasmota-specials/tree/firmware

[darkxst]

It is included in all tasmota32 builds starting with v13.

[deepcoder]

@darkxst Thanks for your reply, the whole Tasmota web environment is in need of a bit housekeeping, and that is not good for the 'average using' IMHO.

I was able to find the latest 'standard' development build at this link:
https://github.com/Jason2866/Tasmota-specials/tree/firmware/firmware/tasmota32/other

however, at this link:

https://github.com/Jason2866/Tasmota-specials/tree/firmware/firmware/tasmota32/other

there is no tasmota32.bin .

I am trying to not introduce other variables. IMHO, the average user that want to expose a Tasmota device to Matter does not want to first face the 'wall' of all the other options in Tasmota...

[darkxst]

The average user is probably using the Web Installer or at the very least the official repos. All of which will come with Matter now.

[sfromis]

Standard development builds are specifically not to to be found in Tasmota-specials, but in http://ota.tasmota.com/tasmota32/

You also have both development, release and "unofficial" special builds here:
https://github.com/tasmota/install/tree/firmware/firmware

[Jason2866]

@deepcoder The "standard" development builds do include matter by default since last week.

[s-hadinger]

Yes. It doesn't harm to have an aggregator endpoint. Why would you want to change anything else?

[jactmp]

Hmmm, Just followed this advise how to check whether bridge mode is used.

[s-hadinger]

This advise is outdated, it was only to distinguish between two versions.

I'm repeating myself again: THE ONLY DIFFERENCE is the DeviceTypeList.

[deepcoder]

@s-hadinger

Just flashed the 13.0.0.1-2023-06-28T13-02-19 firmware and am starting to test.

A couple items right out of the gate.

Wiped out existing configuration in Google, turned off Matter on Tasmota32, deleted '_matter_device.json. Rebooted and flashed.

Just a RGB LED and DS18 temperature physically on the ESP32 gateway device.

SetOption8 1 applied for fahrenheit

I added to Google first, added fine, however only the one 'device' added. No Gateway, Not LED, no temperature. The device that added came up as just a RGB Light. I was able to rename it and add it to a room. Synced Google Home and was able to iOS and voice commands to Google Hubs to control light.

Then for kicks, I decided to try and add to Apple HomeKit. Turned reopened commissioning on the Tasmota32 bridge and then went to iOS and in HomeKit added a device. It worked!!!!!

HomeKit added three devices, bridge, light and temperature. I was able to renamed all three and place them in a room. I am able to control the light from iOS and by voice via HomePods. Apple reports the correct temperature in fahrenheit, matches what is displayed on the Tasmota32 web page.

Changes devices on HomeKit reflect in Google Home and the opposite as well.

And you have to like this, even though Google Home did not show adding the temperature device and it does NOT show up on the iOS Google Home app, if I ask the Google Home speakers what the 'Den Temperature is', it tells me the temperature. However it reports the temperature in celsius! And it tells me the state of the light in the den as well. if I ask Google for the state of den light, it tells me the light state, but does not report the temperature.

I will continue to test and see how robust this release is.

Thank you again for your work and help! Let me know if I can report an think of use to you.

[s-hadinger]

This is weird. Thanks a lot for your feedback. It definitely sounds like a bug in the Google iOS app.

[ad-borges]

Guys,
Im testing Tasmota Matter to help me in some cross platform automations without the use of external Raspberries, HA's and homebrdiges.

My idea was create 8 dummy switches using tasmota matter in a esp32 and pair them with Homekit and Alexa.
Comission OK in Homekit first (tasmota creates 1 bridge and 8 accessories). Alexa gets an error to comission when I put up in pairing mode via Home App.

If I setup first in Alexa, comission OK, but gets just the First Relay.

There is some limitation in Alexa to multiple gang switches? Because im not getting this right.

Im from brazil, sorry for the bad english. Thanks

[deepcoder]

I've not tried Alexa yet, only HomeKit and Google Home. But as I understand if from reading this thread, you are correct Alexa only support one 'device' currently.

[s-hadinger]

Alexa currently only supports 1 device, only on endpoint 1.

[Jason2866]

@ad-borges Off topic.

[ad-borges]

@Jason2866 Sorry. Deleted

[deepcoder]

Sunday 2023-Jun-25, not finding a Tasmota32 Matter build here????

https://github.com/Jason2866/Tasmota-specials/tree/firmware/firmware/tasmota32/other

FYI as well , someone should check the links at the main Tasmota github as well, this leads to a 404:

https://github.com/arendst/Tasmota-firmware/tree/main/release-firmware

[kiralikbeyin]

I flashed from web installer.

{"NAME":"Test3","GPIO":[33,0,0,0,32,576,0,0,0,0,0,34,0,0,258,257,0,0,0,256,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}

With alexa, only the 1st relay is visible, the 2nd and 3rd relays are not.

[maxdamage2122]

Not sure I captured everything but this is everything that was in the console.

21:49:42.989 MTR: >Read_Attr ( 235) [FF00]001D/0002 (ClientList) - []
21:49:43.110 MTR: >OK ( 235) exch=64650 not found
21:49:43.210 MTR: >Read_Attr ( 235) [01]001D/0003 (PartsList) - []
21:49:43.334 MTR: >OK ( 235) exch=64651 not found
21:49:43.460 MTR: >Read_Attr ( 235) [01]001D/0000 (DeviceTypeList) - [{0 = 257U, 1 = 2U}, {0 = 19U, 1 = 1U}]
21:49:43.540 MTR: >OK ( 235) exch=64652 not found
21:49:43.702 MTR: >Read_Attr ( 235) [01]001D/0001 (ServerList) - [8U, 57U, 3U, 4U, 5U, 6U, 29U]
21:49:43.774 MTR: >OK ( 235) exch=64653 not found
21:49:43.897 MTR: >Read_Attr ( 235) [01]001D/0002 (ClientList) - []
21:49:44.116 MTR: >OK ( 235) exch=64654 not found
21:49:44.221 MTR: >Read_Attr ( 235) [02]001D/0003 (PartsList) - []
21:49:44.340 MTR: >OK ( 235) exch=64655 not found
21:49:44.463 MTR: >Read_Attr ( 235) [02]001D/0000 (DeviceTypeList) - [{0 = 770U, 1 = 2U}, {0 = 19U, 1 = 1U}]
21:49:44.542 MTR: >OK ( 235) exch=64656 not found
21:49:44.704 MTR: >Read_Attr ( 235) [02]001D/0001 (ServerList) - [1026U, 29U, 3U, 57U, 4U, 5U]
21:49:44.787 MTR: >OK ( 235) exch=64657 not found
21:49:44.886 MTR: >Read_Attr ( 235) [02]001D/0002 (ClientList) - []
21:49:45.014 MTR: >OK ( 235) exch=64658 not found
21:49:45.122 MTR: >Read_Attr ( 235) [04]001D/0003 (PartsList) - []
21:49:45.197 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:45.254 MTR: >OK ( 235) exch=64659 not found
21:49:45.384 MTR: >Read_Attr ( 235) [04]001D/0000 (DeviceTypeList) - [{0 = 256U, 1 = 2U}, {0 = 19U, 1 = 1U}]
21:49:45.464 MTR: >OK ( 235) exch=64660 not found
21:49:45.626 MTR: >Read_Attr ( 235) [04]001D/0001 (ServerList) - [6U, 29U, 3U, 57U, 4U, 5U]
21:49:45.710 MTR: >OK ( 235) exch=64661 not found
21:49:45.817 MTR: >Read_Attr ( 235) [04]001D/0002 (ClientList) - []
21:49:45.868 MTR: HTTP async-resp in 664 ms from 192.168.1.113: [0] ''
21:49:45.966 MTR: >OK ( 235) exch=64662 not found
21:49:47.510 MTR: =Saved 1 fabric(s) and 1 session(s)
21:49:47.522 MTR: >Command ( 235) [00]0030/0004 CommissioningComplete
21:49:47.527 MTR: <Replied ( 235) [00]0030/0005 CommissioningCompleteResponse
21:49:47.630 MTR: --- Commissioning complete for Fabric 'CC54128ED3F7862B' (Vendor Google LLC) ---
21:49:48.342 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:48.555 MTR: HTTP async-resp in 205 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:48.563 MTR: HTTP async-resp in 213 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:49.656 RSL: STATE = {"Time":"2023-06-20T21:49:49","Uptime":"0T20:45:25","UptimeSec":74725,"Heap":70,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":57,"MqttCount":0,"Berry":{"HeapUsed":42,"Objects":606},"POWER":"OFF","Dimmer":80,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Quahog","BSSId":"E0:63:DA:3D:C7:44","Channel":1,"Mode":"11n","RSSI":100,"Signal":-41,"LinkCount":1,"Downtime":"0T00:00:04"}}
21:49:49.675 RSL: SENSOR = {"Time":"2023-06-20T21:49:49","ESP32":{"Temperature":53.3},"TempUnit":"C"}
21:49:51.298 MTR: >Received ( 0) CASE_Sigma1 rid=218628645 exch=17453 from [fe80::4607:bff:feab:9410]:5540
21:49:51.353 MTR: New_Session( 4885) from '[fe80::4607:bff:feab:9410]:5540'
21:49:51.635 MTR: <Replied ( 0) CASE_Sigma2
21:49:51.639 MTR: New Connection (CASE id=4885) from [fe80::4607:bff:feab:9410]:5540
21:49:51.679 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:51.751 MTR: >Received ( 0) CASE_Sigma3 rid=218628647 exch=17453 from [fe80::4607:bff:feab:9410]:5540
21:49:51.988 MTR: Sigma3 verified, computing new keys
21:49:51.997 MTR: <Replied ( 0) StatusReport
21:49:52.425 MTR: =Saved 1 fabric(s) and 2 session(s)
21:49:52.500 MTR: >Subscribe ( 4885) []/ (min=0, max=60, keep=0) sub=31663
21:49:52.505 MTR: >Read_Attr ( 4885) []/
21:49:55.051 MTR: HTTP sync request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:55.373 MTR: HTTP sync-resp in 304 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:55.848 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:56.020 MTR: >Sub_OK ( 4885) sub=31663
21:49:56.147 MTR: >Sub_OK ( 4885) sub=31663
21:49:56.233 MTR: HTTP async-resp in 380 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:56.241 MTR: HTTP async-resp in 388 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:56.292 MTR: >Sub_OK ( 4885) sub=31663
21:49:56.528 MTR: >Sub_OK ( 4885) sub=31663
21:49:56.561 MTR: .Sub_Done ( ) sub=31663
21:49:58.863 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:49:59.161 MTR: HTTP async-resp in 290 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:49:59.169 MTR: HTTP async-resp in 298 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:01.878 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:50:02.146 MTR: HTTP async-resp in 260 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:02.153 MTR: HTTP async-resp in 268 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:05.216 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:50:05.425 MTR: HTTP async-resp in 204 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:05.437 MTR: HTTP async-resp in 216 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:08.392 MTR: HTTP async request 'http://192.168.1.113:80/cm?cmnd=Status+11'
21:50:08.656 MTR: HTTP async-resp in 256 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:08.664 MTR: HTTP async-resp in 264 ms from 192.168.1.113: [315] '{"StatusSTS":{"Time":"2023-06-...'
21:50:09.691 HTP: Consoles
21:50:10.628 HTP: Console

These are the screenshots I was able to take in the Google home app. 1st there are the 4 devices that quickly get removed to just the one device under "in your home"

[s-hadinger]

I don't see anything wrong in the logs, I will try on my side.

[s-hadinger]

It's all working fine on my side, on iOS with Nest mini. The only thing is that I need to restart the Google Home app to make display of new devices to appear faster.

[maxdamage2122]

Is it possible that a particular template could cause this bug? I've been playing around more with this and have gotten it to work with the esp32-devkit template but as soon as I set it to use the linkind dimmer switch template found here https://templates.blakadder.com/linkind_WS2400101.html I get the issue I mentioned before.

[s-hadinger]

It does not sound plausible but who knows

[deepcoder]

@s-hadinger @openshwprojects I let the 12.5.0.4(matter) 2023-06-06T17:41:20 run for several days with the OpenBeken device all attached to Apple HomeKit. It has been solid, responsive to HomePods voice requests. A simple case I'm sure, but I am very happy and impressed by your work. I will move forward and try your newer build of the Gateway and will try and write up my experiences with some Apple and Google and a bit more complex a setup. Again, thank you for your fine and useful work!

[s-hadinger]

There is a new version with reduced logs and polished UI, allowing to add/remove endpoints without rebooting.

Here is for reference a pairing of a simple ESP32C3 with RGB led, from an iPhone/AppleTV:

00:00:00.001 HDW: ESP32-C3
00:00:00.028 UFS: FlashFS mounted with 428 kB free
00:00:00.044 CFG: Loaded from File, Count 973
00:00:00.049 QPC: Count 1
00:00:00.249 MTR: Loaded 0 fabric(s)
00:00:00.259 MTR: Manual pairing code: 06403737300
00:00:00.265 RSL: RESULT = {"Matter":{"Commissioning":1,"PairingCode":"06403737300","QRCode":"MT:Y.K90Q1212HWXO33B10"}}
00:00:00.587 BRY: Berry initialized, RAM used=10140 bytes
00:00:00.625 TFS: File '.drvset003' not found
00:00:00.625 CFG: Energy use defaults as file system not ready or file not found
00:00:00.640 Project tasmota - Tasmota Version 12.5.0.4(tasmota)-2_0_9(2023-06-12T19:39:00)
00:00:01.409 WIF: Connecting to AP1 Livebox-781A Channel 1 BSSId 74:83:C2:D0:D6:15 in mode 11n as tasmota-673244-4676...
00:00:03.592 WIF: Connected
00:00:03.662 MTR: Configuring endpoints
00:00:03.678 MTR:   endpoint =     0 type = root
00:00:03.697 MTR:   endpoint =     1 type = light3
00:00:03.698 MTR:   endpoint = 65280 type = aggregator
00:00:03.700 RSL: RESULT = {"Matter":{"Initialized":1}}
00:00:03.716 MTR: Starting UDP server on port: 5540
18:40:19.021 HTP: Web server active on tasmota-673244-4676 with IP address 192.168.1.139

[...] Starting commissioning on iPhone

18:40:40.898 MTR: New Commissioning (PASE id=44463) from [fe80::8dc:bbb5:122c:c29c]:61990
18:40:46.927 RSL: RESULT = {"Matter":{"Commissioning":0}}
18:40:48.672 MTR: New Connection (CASE id=20055) from [fe80::8dc:bbb5:122c:c29c]:61990
18:40:49.689 MTR: --- Commissioning complete for Fabric '0000000000000001' (Vendor Apple Home) ---
18:41:00.567 MTR: New Connection (CASE id=46995) from [fe80::8dc:bbb5:122c:c29c]:53457
18:41:01.628 MTR: --- Commissioning complete for Fabric '0000000000000002' (Vendor Apple Keychain) ---
18:41:06.903 MTR: New Connection (CASE id=18239) from [fe80::1c1c:f128:4452:ea52]:50516

[...] Activating On/Off on iPhone

18:41:34.145 RSL: RESULT = {"POWER":"ON"}
18:41:34.147 RSL: POWER = ON
18:41:34.155 MTR: >Command   ( 18239) [01]0006/0001 On
18:41:36.223 RSL: RESULT = {"POWER":"OFF"}
18:41:36.225 RSL: POWER = OFF
18:41:36.233 MTR: >Command   ( 18239) [01]0006/0000 Off

[...] Removing bridge from iPhone

18:41:51.175 MTR: removing fabric 0000000000000001
18:41:51.202 MTR: removing fabric 0000000000000002

[deepcoder]

Testing your Matter 2023-06-13T21:41:02 build on Google home now. I have one remote Tasmota relay and one remote OpenBeken LED strip as well as a temperature sensor in the ESP32. Seems to be working fine! I was able to rename and move the devices around the Google Home with no issues. It was a bit confusing what to enter into the Google Home Dev pages for a gateway device and the two remotes. But Google does not seem to really care what is on that page and gets it config from the Matter pairing steps. The querying of the remote devices by the Matter bridge worked fine, though I did readjust the device 'types' after the initial automatic query. Again, great work, thanks!

[s-hadinger]

Thanks for reporting this. Indeed the Google console is only useful to declare de vendor/device ids.

Do you have more information on how the bridge wrongly detected remote devices ?

[yousaf465]

commissioned without using Google Hub or Homeassistant (homeassistant powered off)

[macjl]

Thank you for the great job !

I'm using an ESP32 with a BH1750 attached. The luminance is working well on Tasmoata Device, and is published as a accessory Matter (iOS 16.5).

But when the luminance shows 152 lux on Tasmota :

on iOS Home app, it shows only 1.04 lux :

Is there a know bug ?

[sfromis]

TSL2591 or TSL2561 does provide low luminosity decimals. While I haven't made a calibration-style check, with TSL2561 I do see plausible values increasing from zero in steps around 0.01 lux in the early dawn (resolution 0.001, but I'd not expect the accuracy being that good). Neither of these included in default precompiled builds.

[joba-1]

do you have an idea how to do such a calibration?
Back when I wrote the driver for the tsl2561 i followed the datasheet calculation but I found no way to calibrate (would need expensive equipment).
But the values made sense comparing with candles and bright sunlight.

[sfromis]

I've not got much calibration info, without a good reference to compare to. And most "environmental" references can vary a bit depending on details. My view on those cheap sensors is that I'm not so much looking for a "lab" measurement to make a claim that I know the "real" value, but instead something allowing me to see a reasonable range of change across normal conditions, which for a luminosity sensor obviously goes from darkness to full daylight, with a reasonable progression in between. My expectation is that those TSL sensors are better than messing with a LDR and calibration of that....

[s-hadinger]

I pushed a new fix to conform to spec. But considering 0 as invalid is a clearly a bug.

[s-hadinger]

@macjl See #18847, I'm actually fixing the formula so it's close enough to the standard, but also usable for low lux values. Just substract 1 to the value reported by the controller.

[Noschvie]

Is this a typo ? _X20and_X20condiguration vs _X20and_X20configuration

https://github.com/arendst/Tasmota/blob/31b93f8d4820c51431911a97d80bdfc34c334c0e/lib/libesp32/berry_matter/src/solidify/solidified_Matter_Device.h#LL5283C36-L5283C60

[s-hadinger]

Yes, thanks for the fix.

[yousaf465]

version number not updated? still Tasmota 12.5.0.4 by Theo Arends

[s-hadinger]

No, we don't change the version number for each fix.

[sfromis]

After having flashed a new build, you can see update level (timestamp) in Status 2 output...
"StatusFWR":{"Version":"12.5.0.4(matter)","BuildDateTime":"2023-06-06T08:43:53"
(and also on the Information page in the web UI).

[kiralikbeyin]

Testing with 2 same esp32 2 relay devices, both devices have same template..

I compiled with #define USE_MATTER_DEVICE
There is no "Current Configuration" field.?? (tried master and dev branches)

Web installer works fines and shows "Current Configuration" field.

I don't understand why my own build didn't work while the web installer worked perfect.

[kiralikbeyin]

This commits fixed

https://github.com/arendst/Tasmota/tree/31b93f8d4820c51431911a97d80bdfc34c334c0e thanks

[deepcoder]

Hello,
Thank you for the follow up. To your questions:

1. I tried replacing the '+' with '%20' space and the curl seems to return the same, results below for the query with space:

2. I deleted the Tasmota border router from the Apple HomeKit Home and readded it with the _matter_device.json as shown below, serial log output from Tasmota 12.5.0.4 border router attached below. I believe I got the serial debugging level set to 'debug', although I am not sure I can tell. FYI, the Tasmota32 device seems to crash and reboot when you download the serial log from the Web Installer. Apple Home continue to show the Matter Accessory as 'No Response'. Again, as a reminder, I was able to add a 'real' Tasmota 8266 device with same Relay setup yesterday and Apple HomeKit happily worked with that device. Hope something shows in log file. However, my noob eye does not see any log info about the response or lack of from the OpenBeken device.

esp-web-tools-logs-matter-issue-202306041548.txt
esp-web-tools-logs-matter-issue-202306041548.txt

{"distinguish":4041,"passcode":72798548,"ipv4only":false,"config":{
    "0": {
      "type": "root"
    },
    "1": {
      "type": "http_light0",
      "url": "192.168.2.220",
      "relay": 1
    }
}}

$ curl -s http://192.168.2.220:80/cm?cmnd=Status%2011 | jq .
{
  "Status": {
    "Module": 0,
    "DeviceName": "ew010-00",
    "FriendlyName": [
      "ew010-00_1"
    ],
    "Topic": "ew0101/00",
    "ButtonTopic": "0",
    "Power": 1,
    "PowerOnState": 3,
    "LedState": 1,
    "LedMask": "FFFF",
    "SaveData": 1,
    "SaveState": 1,
    "SwitchTopic": "0",
    "SwitchMode": [
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0
    ],
    "ButtonRetain": 0,
    "SwitchRetain": 0,
    "SensorRetain": 0,
    "PowerRetain": 0,
    "InfoRetain": 0,
    "StateRetain": 0
  },
  "StatusPRM": {
    "Baudrate": 115200,
    "SerialConfig": "8N1",
    "GroupTopic": "",
    "OtaUrl": "https://github.com/openshwprojects/OpenBK7231T_App/releases/latest",
    "RestartReason": "HardwareWatchdog",
    "Uptime": 14692,
    "StartupUTC": "2023-06-04T18:16:23",
    "Sleep": 50,
    "CfgHolder": 4617,
    "BootCount": 22,
    "BCResetTime": "2022-01-27T16:10:56",
    "SaveCount": 1235,
    "SaveAddress": "F9000"
  },
  "StatusFWR": {
    "Version": "OpenBK7231N_1.17.132",
    "BuildDateTime": "Jun  3 2023 17:52:25",
    "Boot": 7,
    "Core": "0.0",
    "SDK": "obk",
    "CpuFrequency": 80,
    "Hardware": "BK7231N",
    "CR": "465/699"
  },
  "StatusLOG": {
    "SerialLog": 2,
    "WebLog": 2,
    "MqttLog": 0,
    "SysLog": 0,
    "LogHost": "",
    "LogPort": 514,
    "SSId1": "gfi",
    "SSId2": "",
    "TelePeriod": 300,
    "Resolution": "558180C0",
    "SetOption": [
      "000A8009",
      "2805C80001000600003C5A0A000000000000",
      "00000280",
      "00006008",
      "00004000"
    ]
  },
  "StatusMEM": {
    "ProgramSize": 616,
    "Free": 384,
    "Heap": 25,
    "ProgramFlashSize": 1024,
    "FlashSize": 2048,
    "FlashChipId": "1540A1",
    "FlashFrequency": 40,
    "FlashMode": 3,
    "Features": [
      "00000809",
      "8FDAC787",
      "04368001",
      "000000CF",
      "010013C0",
      "C000F981",
      "00004004",
      "00001000",
      "00000020"
    ],
    "Drivers": "1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37,45",
    "Sensors": "1,2,3,4,5,6"
  },
  "StatusNET": {
    "Hostname": "ew010-00",
    "IPAddress": "192.168.2.220",
    "Gateway": "192.168.0.1",
    "Subnetmask": "255.255.255.0",
    "DNSServer1": "192.168.0.1",
    "DNSServer2": "0.0.0.0",
    "Mac": "50:8a:06:b6:bf:e8",
    "Webserver": 2,
    "HTTP_API": 1,
    "WifiConfig": 4,
    "WifiPower": 17
  },
  "StatusMQT": {
    "MqttHost": "192.168.2.242",
    "MqttPort": 1883,
    "MqttClientMask": "core",
    "MqttClient": "ew0101/00",
    "MqttUser": "homeassistant",
    "MqttCount": 23,
    "MAX_PACKET_SIZE": 1200,
    "KEEPALIVE": 30,
    "SOCKET_TIMEOUT": 4
  },
  "StatusTIM": {
    "UTC": "2023-06-04T22:21:15",
    "Local": "2023-06-04T22:21:15",
    "StartDST": "2022-03-27T02:00:00",
    "EndDST": "2022-10-30T03:00:00",
    "Timezone": "+01:00",
    "Sunrise": "07:50",
    "Sunset": "17:17"
  },
  "StatusSNS": {
    "Time": "2023-06-04T22:21:15"
  },
  "StatusSTS": {
    "Time": "2023-06-04T22:21:15",
    "Uptime": "0T04:04:52",
    "UptimeSec": 14692,
    "Heap": 25,
    "SleepMode": "Dynamic",
    "Sleep": 10,
    "LoadAvg": 99,
    "MqttCount": 23,
    "POWER": "ON",
    "Wifi": {
      "AP": 1,
      "SSId": "gfi",
      "BSSId": "30:B5:C2:5D:70:72",
      "Channel": 11,
      "Mode": "11n",
      "RSSI": 110,
      "Signal": -45,
      "LinkCount": 21,
      "Downtime": "0T06:13:34"
    }
  }
}

[s-hadinger]

Here is the new logging format. Below is a commissioning done with chip-tool:

21:43:34.701 MTR: >Received  PBKDFParamRequest from [xxx.xxx.x.x]:43433
21:43:34.770 MTR: <Replied   PBKDFParamResponse
21:43:34.846 MTR: >Received  PASE_Pake1 from [xxx.xxx.x.x]:43433
21:43:35.448 MTR: <Replied   PASE_Pake2
21:43:35.513 MTR: >Received  PASE_Pake3 from [xxx.xxx.x.x]:43433
21:43:35.563 MTR: <Replied   StatusReport
21:43:35.762 MTR: Read_Attr  [**]0031/FFFC (FeatureMap)
21:43:35.785 MTR: Read_Attr  [00]0031/FFFC (FeatureMap) - 0U
21:43:35.805 MTR: Read_Attr  [00]0030/0000 (Breadcrumb) - 0U
21:43:35.830 MTR: Read_Attr  [00]0030/0001 (BasicCommissioningInfo) - {0 = 60U, 1 = 900U}
21:43:35.848 MTR: Read_Attr  [00]0030/0002 (RegulatoryConfig) - 2U
21:43:35.869 MTR: Read_Attr  [00]0030/0003 (LocationCapability) - 2U
21:43:35.888 MTR: Read_Attr  [00]0028/0002 (VendorID) - 65521U
21:43:35.910 MTR: Read_Attr  [00]0028/0004 (ProductID) - 32768U
21:43:35.913 MTR: Read_Attr  [**]0031/0003 (ConnectMaxTimeSeconds)
21:43:35.935 MTR: Read_Attr  [00]0031/0003 (ConnectMaxTimeSeconds) - 30U
21:43:36.389 MTR: >Status
21:43:36.523 MTR: >Received  [00]0030/0000 ArmFailSafe from [xxx.xxx.x.x]:43433
21:43:36.529 MTR: <Replied   [00]0030/0001 ArmFailSafeResponse
21:43:36.788 MTR: >Received  [00]0030/0002 SetRegulatoryConfig from [xxx.xxx.x.x]:43433
21:43:36.794 MTR: <Replied   [00]0030/0003 SetRegulatoryConfigResponse
21:43:37.062 MTR: >Received  [00]003E/0002 CertificateChainRequest from [xxx.xxx.x.x]:43433
21:43:37.068 MTR: <Replied   [00]003E/0003 CertificateChainResponse
21:43:37.338 MTR: >Received  [00]003E/0002 CertificateChainRequest from [xxx.xxx.x.x]:43433
21:43:37.344 MTR: <Replied   [00]003E/0003 CertificateChainResponse
21:43:37.638 MTR: >Received  [00]003E/0000 AttestationRequest from [xxx.xxx.x.x]:43433
21:43:37.755 MTR: <Replied   [00]003E/0001 AttestationResponse
21:43:38.059 MTR: >Received  [00]003E/0004 CSRRequest from [xxx.xxx.x.x]:43433
21:43:38.345 MTR: <Replied   [00]003E/0005 CSRResponse
21:43:38.630 MTR: >Received  [00]003E/000B AddTrustedRootCertificate from [xxx.xxx.x.x]:43433
21:43:38.957 MTR: >Received  [00]003E/0006 AddNOC from [xxx.xxx.x.x]:43433
21:43:39.008 MTR: <Replied   [00]003E/0008 NOCResponse
21:43:39.373 MTR: Saved 1 session(s)
21:43:39.375 MTR: Operational Discovery node = CF3DA9A2739885FD-0000000000000001
21:43:40.520 MTR: >Received  CASE_Sigma1 from [fe80::1bf1:bd1a:c5ff:818a]:54823
21:43:40.929 MTR: <Replied   CASE_Sigma2
21:43:41.063 MTR: >Received  CASE_Sigma3 from [fe80::1bf1:bd1a:c5ff:818a]:54823
21:43:41.398 MTR: <Replied   StatusReport
21:43:41.574 MTR: Saved 1 session(s)
21:43:41.668 MTR: >Received  [00]0030/0004 CommissioningComplete from [fe80::1bf1:bd1a:c5ff:818a]:54823
21:43:41.675 MTR: <Replied   [00]0030/0005 CommissioningCompleteResponse
21:43:41.877 MTR: *** Commissioning complete ***

[s-hadinger]

The current code size increase for Matter is 209KB. It will continue to increase moderately.

[s-hadinger]

There are some major improvements with the latest PR:

• full support for "read attributes", including expansion and chunked responses
• full support for "write attributes"
• full support for commands
• implements a simple OnOff light
• basic support for "subsribe": responds initial attributes and sends the heartbeat. But does not report changed attributes yet.
  Note: the link with Tasmota Light behavior is not done

Multi-fabric is not yet supported, this is still a blocking point for Google/Apple compatibility.

[s-hadinger]

Indeed. The certification scheme is clearly not well suited for DYI.

[nikito7]

Reverse proxy. And easy Google Assistant / Alexa integration.

[nikito7]

Sells zigbee matter dongle "SkyConnect"

[s-hadinger]

Thanks for the suggestions. But we don't plan to make a business out of Tasmota. It's still a hobby project for the contributors. We'll explore some options.

[a-d-r-i-a-n-d]

0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4 are Test Vendors. The Test Vendor IDs are reserved for test and development by device manufacturers or hobbyists. Commissioners SHOULD NOT commission devices using one of these VIDs onto an operational Fabric under normal operation unless the user is made fully aware of the security risks of providing an uncertified device with operational and networking credentials.

I've recently read the Matter specs and one of the notes was the one above. I don't think they would restrict devices but the user will be notified about it, which I personally don't mind.

[Hedda]

Thanks for the suggestions. But we don't plan to make a business out of Tasmota. It's still a hobby project for the contributors. We'll explore some options.

FYI, Kodi/XBMC is not a company, Kodi/XBMC is still a profit hobby project with only unpaid volenteers, but with their foundation being a legal entiry does open some doors that otherwise would be closed.

[Jason2866]

Let us hope the do for Matter as the do for Homekit. The allow.
If certification is needed there is no room for Matter in DIY projects. Strictly speaking it is the dead of.

[bakman2]

Device Attestation is currently hard-coded to 0xFFF1/0x8000 using certificates from connectedhomeip.

I wonder if this will ultimately become a blocking factor, where let's say Apple does not allow uncertified matter products to be added to their home app and the only way would be is to have it certified in order to get a valid cert. Matter is good for manufacturers, not for the DIY community.

[Apollon77]

From what we know is that the "Matter alliance" decises to allow uncertified devices to be added when the user is "asked". So Apple does it that way already and I would assume it stays that way. Google is a bit more complex to allow it but also possible and ALexa works too.
So yes theoretically it could be an issue (beside the fact that there are some more "allowed" test vendor/product ids), but lets stay optimistic for now :)

[tokamac]

I use DIY HomeKit accessories from ESP8266 devices flashed with the HAA firmware (esp-homekit) and would like to try the Matter implementation of Tasmota with ESP32 devices. I can confirm that, from the Apple side of things, there is a warning in the Apple Home app that pops up when one tries to add such a "non approved" HK accessory, but the user just has to acknowledge the message and proceed with no error or issue afterward. It's a simple two-step process (clicking + to add a device, then flashing QR code or type the device passcode, and voilà).
What exactly is behind the sentence "Google is a bit more complex to allow it"?

[s-hadinger]

Google requires that you first register the VendorID/DeviceID in your Google Home Dev console.

[kskenyon]

Commissioning success. Session established. Nice work! ./chip-tool pairing onnetwork 0x7234 20202021 Kevin

…

On Feb 14, 2023, at 2:53 AM, s-hadinger ***@***.***> wrote: They may have changed the commands. It should be onnetwork, try to get the options for this command — Reply to this email directly, view it on GitHub <#17872 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF4WTTCXMFFFGFQ6M5ZQUUTWXM2WRANCNFSM6AAAAAAUQYNQYQ>. You are receiving this because you commented.

[kskenyon]

I finally got chip-tool compiled on MacOS after a few false starts. They have a few relevant script bugs.

Can you help me with the command line for chip-tool for a Tasmota device over WiFi? I can't quite figure it out from the chip-tool Wiki.

Thanks

[nikito7]

chip-tool pairing ethernet 0x7283 20202021 1021 192.168.1.116 5540

Change ip address

[kskenyon]

./chip-tool pairing ethernet 0x7283 20202021 1021 192.168.1.122 5540

[1676340404302] [56522:171048869] [TOO] Unknown command: ethernet
Usage:
./chip-tool pairing command_name [param1 param2 ...]

+-------------------------------------------------------------------------------------+
| Commands: |
+-------------------------------------------------------------------------------------+
| * unpair |
| * code |
| * code-paseonly |
| * code-wifi |
| * code-thread |
| * ble-wifi |
| * ble-thread |
| * softap |
| * already-discovered |
| * onnetwork |
| * onnetwork-short |
| * onnetwork-long |
| * onnetwork-vendor |
| * onnetwork-commissioning-mode |
| * onnetwork-commissioner |
| * onnetwork-device-type |
| * onnetwork-instance-name |
| * start-udc-server |
| * open-commissioning-window |
| * close-session |
| * get-commissioner-node-id |
+-------------------------------------------------------------------------------------+
[1676340404302] [56522:171048869] [TOO] Run command failure: ../../examples/chip-tool/commands/common/Commands.cpp:224: Error 0x0000002F
➜ standalone git:(master) ✗

pairing is not a command with ethernet? fresh git pull.

tried everything I can think of without luck.

[s-hadinger]

They may have changed the commands. It should be onnetwork, try to get the options for this command

[kskenyon]

No luck connecting to Home app 16.3.1. FYI.

00:00:00.002 HDW: ESP32-D0WDQ6
00:00:00.069 UFS: FlashFS mounted with 304 kB free
00:00:00.101 CFG: Loaded from File, Count 11
00:00:00.111 QPC: Count 1
00:00:00.636 BRY: Berry initialized, RAM used=6624 bytes
00:00:00.657 TFS: File '.drvset003' not found
00:00:00.658 CFG: Energy use defaults as file system not ready or file not found
00:00:00.666 Project tasmota - Tasmota Version 12.3.1.6(tasmota)-2_0_6(2023-02-12T17:40:50)
00:00:01.461 WIF: Connecting to AP1 IoT_2g Channel 6 BSSId 74:83:C2:8D:83:EF in mode 11n as tasmota-0AC044-0068...
00:00:03.480 WIF: Connected
00:00:03.557 MTR: starting mDNS on wifi '1CE440836BD8C6C7' ptr to 30AEA40AC044.local
00:00:03.560 MTR: Exceptioninternal_error|mdns add_subtype err=261
00:00:03.577 MTR: starting UDP server on port: 5540
00:00:03.768 HTP: Web server active on tasmota-0AC044-0068 with IP address 192.168.2.122
00:03:48.720 RSL: INFO1 = {"Info1":{"Module":"ESP32-DevKit","Version":"12.3.1.6(tasmota)","FallbackTopic":"cmnd/DVES_0AC044_fb/","GroupTopic":"cmnd/tasmotas/"}}
00:03:48.744 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-0AC044-0068","IPAddress":"192.168.2.122","IP6Global":"","IP6Local":"fe80::32ae:a4ff:fe0a:c044"}}
00:03:48.768 RSL: INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":5}}
00:03:51.004 QPC: Reset
0

[nikito7]

Only work with chip-tool

[sushantr5]

Thank you very much for bringing matter into Tasmota. I was waiting patiently this to happen. When can I expect a berry example to add matter support to custom device?

[s-hadinger]

Thanks for your kind message. It will probably require a month or two.
Just out of curiosity, what do you have in mind?

[sushantr5]

I have designed two esp32 devices, basically switches. One is 4 Gang Switch and another one is 4 Speed Fan control. Both the device drivers are written in berry.
I was waiting for matter so that I do not have to write my own app. One other option is go Home Assistant Route, so far device drivers written in berry send Home Assistant MQTT discovery message. I am using MQTT discovery instead of tasmota discovery, because I wanted to detect Fan control device correctly in HA.
Then Matter started come into picture and with all the benefits, I am excited since I am seeing this thread, previous to this, #13020 was my hope, someday it will happen. Long time back, Berry saved me from plucking my hairs understanding tasmota code, and now Matter as well will save me.

[nikito7]

ESP32-DevKit
cpha.pt

Welcome to the Berry Scripting console. Check the [documentation](https://tasmota.github.io/docs/Berry/).
BRY: Exception> 'attribute_error' - module 'crypto' has no member 'PBKDF2_HMAC_SHA256'
stack traceback:
	<unknown source>: in function `compute_pbkdf`
	<unknown source>: in function `start_basic_commissioning`
	<unknown source>: in function `init`
	<unknown source>: in function `main`
BRY: Exception> 'import_error' - module 'mdns' not found
stack traceback:
	<unknown source>: in function `_start_mdns_announce`
	<unknown source>: in function `_anonymous_`
	<unknown source>: in function `try_rule`
	<unknown source>: in function `exec_rules`
	<unknown source>: in function `event`
Run code (or press 'Enter' twice)
Consoles
[Tasmota 12.3.1.6 by Theo Arends](https://bit.ly/tasmota)

[s-hadinger]

Oh. You also need #define USE_BERRY_DEBUG

[nikito7]

Maybe this is need too:

SetOption55 1

[s-hadinger]

It's not necessary. Matter support does enable the needed mdns pièces

[nikito7]

Home Assistant and Chip Tool.

Google Home fails

[s-hadinger]

Good. Do you have the Tasmota logs of Google Home failing?

[Jason2866]

@Apollon77 a warm welcome here Mr. ioBroker ;-)

[Apollon77]

Thank you, didn't know I earned that name ;-)

[jnsw]

just a little bit working with iobroker in the past makes your name weirdly familiar 😆

[probonopd]

What are the system requirements (e.g., MCUs)?

[sfromis]

No, not ESP8266. What might become feasible would be for one ESP32 device with Tasmota to act as a gateway to Matter, for multiple ESP8266 devices.

[tokamac]

Any ESP32

Matter devices use BLE for commissioning. ESP32-S2 does not have Bluetooth. Will an ESP32-S2 board able to be configured as a working Matter accessory when flashed with the Tasmota32 MATTER version?

[s-hadinger]

In Matter, BLE is optional and mostly used to configure the Wifi credentials with a mobile app. This is not needed in Tasmota that has its own way of configuring Wifi.

We don't support BLE commissioning in Tasmota, because the BLE code from esp-idf is too large. We only support "on-network" commissioning. This means that the device is already on the Wifi network, and BLE is not needed.

Matter on Tasmota does work on ESP32-S2. But be aware that S2 has less memory, hence more limited. Especially using ESP32-S2 as bridge would not be viable.

[tokamac]

If I understand correctly, that means that a Tasmota Matter device cannot be configured right from the start by the final user like a commercial device just by flashing a QR code or entering a passcode directly in the user's home automation mobile app (e.g. Apple Home); the user must first open the Tasmota control panel, choose his SSID and enter his Wi-Fi credentials first, before he can finally add the device to his mobile app?

Thanks for the warning about memory. I ordered a LOLIN S2 MINI development board but also a LuatOS ESP32 C3-CORE that will be more suitable for tests than the S2 I think. I also ordered an ESP-C3-12F (C3FN4, 4MB) chip that I plan to try on a MOES Rotary dimmer, unsoldering the incompatible WB3S chip in it. I know the Tasmota firmware for Matter is specific. Can you tell me if the code for the configuration is the same as for versions swapped with an ESP8266 (configuration code described on the Tasmota template page for that device)?

I will then test it in the Apple Home app. I will report my findings here for the community.

[s-hadinger]

If I understand correctly, that means that a Tasmota Matter device cannot be configured right from the start by the final user like a commercial device just by flashing a QR code or entering a passcode directly in the user's home automation mobile app (e.g. Apple Home); the user must first open the Tasmota control panel, choose his SSID and enter his Wi-Fi credentials first, before he can finally add the device to his mobile app?

Right. Matter for Tasmota is designed to be an extension of Tasmota. We don't plan to have Matter-only devices. For this you can use esp-matter or other on-the-shelf solutions. Also we don't have plans to have Tasmota Matter-certified, since this would be needed for each hardware device.

ESP32C3 and ESP8266 templates are different, but it should be easy to remap the pins to ESP32C3.

[Hedda]

Tip: If and when come to the point that want to test both commissionings a Tasmota Matter device inside some other open-source Matter Server/Controller implementations and/or testing to commission other virtual Matter devices inside Tasmota then check out these projects:

node-matter (Matter protocol client / server for node.js)

• https://github.com/mfucci/node-matter

Home Assistant (Matter integration with Matter protocol client / server )

• https://www.home-assistant.io/integrations/matter/
  • https://www.home-assistant.io/blog/2022/12/07/release-202212/#it-does-matter
    ´ - https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

PS: Note that both node-matter and Home Assistant have the ability to act as either a Matter server/controller or a client (or both).

[s-hadinger]

I tried generating a new Certification Declaration with device_type_id=0x0100 but it fails the same way

[Apollon77]

One user had success with uninstal/install Alexa App but me not so far. It wooulf maybe a try to downgrade ALexa App to the version from end december ... we did succesfull tests on 8.1. roughly and there such a december version was current. But ok "good to hear" that I'm ot the only one affected.

BTW: node-matter Hithub version controller should at least du susccessfull commisioning!

[Hedda]

Home Assistant (Matter integration with Matter protocol client / server )

• https://www.home-assistant.io/integrations/matter/

  • https://www.home-assistant.io/blog/2022/12/07/release-202212/#it-does-matter
    ´ - https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

FYI, Home Assistant posted a new blog post with a status update regarding its Matter support, and in summary, they have done big updates to their documentation on Matter, (and the next upcoming release version (Home Assistant core 2023.3 will also get experimental integration support for Thread Border Router in Home Assistant)

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

https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/

https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/#matter

https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/#thread

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

[Jason2866]

Yes, and Home Assistant added a note which highlights a need of Matter which is a big problem in not small or secured LANs. -> mDNS

The Matter protocol relies on (local) IPv6 and mDNS (multicast traffic) which should be able to travel freely in your network. Matter devices (and any Thread Border routers) must be on the same LAN/VLAN as Home Assistant. Implementations like mDNS reflectors usually do more harm than good.

[Apollon77]

And will produce all lots of fun with docker :-)

[s-hadinger]

Here what it looks like with weblog 2 when pairing with chip-tool, it takes ~7 seconds:

The chip-tool command is:

~/connectedhomeip/examples/chip-tool/out/debug/chip-tool pairing ethernet 0x7283 20202022 1 192.168.1.116 5540

09:34:16.340 MTR: >Received      PBKDFParamRequest from [192.168.1.3]:44420
09:34:16.402 MTR: <Replied       PBKDFParamResponse
09:34:16.489 MTR: >Received      PASE_Pake1 from [192.168.1.3]:44420
09:34:17.080 MTR: <Replied       PASE_Pake2
09:34:17.138 MTR: >Received      PASE_Pake3 from [192.168.1.3]:44420
09:34:17.182 MTR: <Replied       StatusReport
09:34:17.366 MTR: Read Attribute [**]0031/FFFC (FeatureMap)
09:34:17.370 MTR: Read Attribute [00]0030/0000 (Breadcrumb)
09:34:17.374 MTR: Read Attribute [00]0030/0001 (BasicCommissioningInfo)
09:34:17.379 MTR: Read Attribute [00]0030/0002 (RegulatoryConfig)
09:34:17.383 MTR: Read Attribute [00]0030/0003 (LocationCapability)
09:34:17.397 MTR: Read Attribute [00]0028/0002 (VendorID)
09:34:17.401 MTR: Read Attribute [00]0028/0004 (ProductID)
09:34:17.405 MTR: Read Attribute [**]0031/0003 (ConnectMaxTimeSeconds)
09:34:17.862 MTR: >Received_cmd  ArmFailSafe from [192.168.1.3]:44420
09:34:17.867 MTR: <Replied_cmd   ArmFailSafeResponse
09:34:18.103 MTR: >Received_cmd  SetRegulatoryConfig from [192.168.1.3]:44420
09:34:18.108 MTR: <Replied_cmd   SetRegulatoryConfigResponse
09:34:18.358 MTR: >Received_cmd  CertificateChainRequest from [192.168.1.3]:44420
09:34:18.363 MTR: <Replied_cmd   CertificateChainResponse
09:34:18.605 MTR: >Received_cmd  CertificateChainRequest from [192.168.1.3]:44420
09:34:18.612 MTR: <Replied_cmd   CertificateChainResponse
09:34:18.867 MTR: >Received_cmd  AttestationRequest from [192.168.1.3]:44420
09:34:18.984 MTR: <Replied_cmd   AttestationResponse
09:34:19.250 MTR: >Received_cmd  CSRRequest from [192.168.1.3]:44420
09:34:19.533 MTR: <Replied_cmd   CSRResponse
09:34:19.837 MTR: >Received_cmd  AddTrustedRootCertificate from [192.168.1.3]:44420
09:34:20.142 MTR: >Received_cmd  AddNOC from [192.168.1.3]:44420
09:34:20.185 MTR: <Replied_cmd   NOCResponse
09:34:20.519 MTR: Saved 1 session(s)
09:34:20.521 MTR: Operational Discovery node = 0F881703EF7391B4-0000000000007283
09:34:21.678 MTR: >Received      CASE_Sigma1 from [fe80::1bf1:bd1a:c5ff:818a]:39554
09:34:22.077 MTR: <Replied       CASE_Sigma2
09:34:22.175 MTR: >Received      CASE_Sigma3 from [fe80::1bf1:bd1a:c5ff:818a]:39554
09:34:22.494 MTR: <Replied       StatusReport
09:34:22.644 MTR: Saved 1 session(s)
09:34:22.729 MTR: >Received_cmd  CommissioningComplete from [fe80::1bf1:bd1a:c5ff:818a]:39554
09:34:22.734 MTR: <Replied_cmd   CommissioningCompleteResponse
09:34:22.900 MTR: *** Commissioning complete ***

[nikito7]

What is "0x7283" ?

[s-hadinger]

It's the identifier-id assigned to the node. It can be almost any 32bits number. You just can't have two nodes with the same id.

This value is just random

[s-hadinger]

This next message keeps track of what's already implemented, what's missing and what will not be implemented:

What is already implemented:

• 100% Berry implementation for fast development and easy extension
• ~200KB Flash impact (which is very low compared to connectedhomeip)
• full support of encryption via BearSSL without increased size that mbedTLS would have implied: SHA256, AES_CCM 256, HKDF_SHA256, HMAC_SHA256, PKKDF2 with HMAC SHA256 key derivation, SPAKE2+, ECDH with P256 (secp256r1).
• Commissioning over Wifi (via DNS-SD)
  • selection of passcode and discriminator (distinguish id)
  • WebUI with QR code
  • full commissioning process with PASE and CASE according to spec (and checked with chip-tool)
  • operational discovery via DNS-SD
  • core minimal attributes for chip-tool to work
  • handling of multiple sessions
• support for Berry plug-ins

What's not yet implemented:

• Encryption
  • no group messages nor keys
  • privacy encryption not implemented
  • no check of NOC/ICAC certificate chain
  • epoch key rotation
  • Device Attestation is currently hard-coded to 0xFFF1/0x8000 using certificates from connectedhomeip.

Not in scope

• no Thread support
• no support for bridge mode (will be implemented later)
• no support of Tasmota as commissioner

[ptommson]

This looks great! I got it running on my ZigbeeBridgePro but then read there is not yet support for bridge mode. Any idea when this might be coming? :)

[s-hadinger]

It's too early for bridged mode. We're still focusing on simple devices. But indeed bridged mode will be interesting to connect all ESP8266 devices as well.

[ptommson]

Good to know thanks, can't wait to try it out when it comes. In the mean time i'll try it out on some non bridged devices. I saw that Google home lets you scan a matter barcode now, interested to see if it lets you control devices directly.