Matter Binding

Very strange: when I first set this up, [inverted=false] was needed, but when I now delete it and do a new scan in Alexa, it works without.
So I must have done something wrong :innocent:

I’m fed up with my smoke detectors, for which I have to replace many batteries every year, with siren triggered generally during the night because the battery level is low !

Moving to smart smoke sensors is an interesting option. The Heiman HS1SA-M is one of the current options available with Matter. This would be also for me a way to start with Matter over Thread.

Dan, can you confirm that this device follows properly the Matter standard and so could be added to OH with full features ?

@raphael : I imagine this device can work even without any smart feature, I mean as standalone device without any connection feature ?

Regarding Thread, is the Thread version something important to consider even for devices, or is it important only for the TBR ?

Could we list the current options availalble for TBR compatible with Thread 1.4 ? And which ones are relatively easy to setup ?

@digitaldan : when I check the content of my folder userdata/matter, I am a little surprised to discover 3 sub-folders.

controller-openhab-0 is certainly the folder for OH as matter controller.

But why do I have two folders for the bridge feature: bridge-0 and oh-bridge ? Checking the modification dates, I believe oh-bridge is still updated while bridge-0 is not. bridge-0 could have been created when I first install OH 5.1 (from scratch). Is it a bug to have them both ?

What about the file controller-openhab.converted.json, can I remove it or is it necessary ?

The HS1SA-M also works without integration into a smart home, as it only transmits status messages and does not pair with other smoke sensors or the same. Compared to the Zigbee HS1SA-E variant, the Matter Thread variant has a reduced battery life of 5 years compared to 10 years.

A Thread Border Router is required for the integration of Thread-enabled Matter devices. In addition, a tool for pairing and maintenance, such as firmware updates for the devices, is required. To my understanding, these are functions that are not yet supported by the current Matter binding for OH.

The integration of Matter devices (including Thread-enabled Matter devices) works well if they have been previously set up in a third-party system such as Google Home, Apple Home, Alexa Smart Home, SmartThings, etc. In this case, the Matter devices can also be integrated into OH. I ultimately decided to go this route and chose HA as the third-party system.

Alternatively, a standalone Thread Border Router based on OTBR or an ESP can be set up. Instructions for this can be found in the forum, e.g., under this post and on the Internet. I also got this approach to work to some extent, but ultimately decided against it due to the complexity of maintaining the system.

According to Smart Smoke Alarm - CSA-IOT the device is certified and supports the CO2 Cluster, so yes, i don’t see why it would not work. I was planning on adding the CO2 cluster converter this weekend.

Personally, its only TBRs that i care about Thread versions right now, these newer 1.4+ Thread releases are really aimed at making the TBR ecosystem easier to manage and ensure that a multi-vendor TBR setup works almost out of the box, there really is not much that i care about for end devices, 1.2.and 1.3 are fine for those IMHO.

Regarding thread, this is kinda fun, but I also have a PR up in the MainUI to visualize a thread network, which is really geared towards running TBR that support Matter 1.4 ( not to be confused with Thread 1.4, Matter1.4 != Thread1.4 here), I have a few tweaks i’ll push up this weekend for managing OTBRs a bit easier too.

The setup below has 2 OTBR managed by openHAB , one is the Leader, the other acts as a Router, but if the Leader dies, it would automatically take over, pretty cool. You can see my Sleepy (read battery) device connects to just the Leader for power reasons, but the Inovelli light switch connects to both for redundancy (and also acts as router for messages if a thread device could not connect to a TBR)

2 Likes

Yes this are old versions before we released the GA version of the binding and can be removed.

So i can confirm this is an Alexa bug reversing the Open/Close voice commands, and have reported it again to Amazon (second time)… there is a rumor that they will be fixing this in January… but i can neither confirm or deny such a rumor :wink:

I was going to put an optional hack in to invert this if we detect Amazon, but i think i’m going to wait now and see if they fix this (its affecting all window covering devices)

Thanks for the update. Funny that the biggest player is by far the biggest weak point :wink:
A workaround is not necessary as we still got the Alexa skill, so let’s see… :smiling_face_with_sunglasses:

See [matter] Add Smoke, CO and CO2 client device support by digitaldan Ā· Pull Request #19897 Ā· openhab/openhab-addons Ā· GitHub

1 Like

Thanks for your effort to support Smoke CO Alram device types. For my HS1SA-M smoke sensor the addtional channels got now detected.

Did you build and install my PR branch then?

Yes

1 Like

@raphael : I don’t know what kind of channel is added but were you able to test that its state is properly updated when fire is detected ? :wink:

1 Like

There is the SmartThings option which was recently upgraded to Thread 1.4 and even to Matter 1.5.

But the Aeotec Smart Home Hub 2 at 100€ is a little expensive just to get a TBR and it seems to be not yet available! I hesitate…

Aqara released recently a new hub with is also a thread border router, the M200. Relatively cheap at around 60 €. I did not find the information about the thread version on Internet but is a new product released in November 2025 capable to be only Thread 1.3 ? I guess they would be capable to not provide Thread 1.4…

@Lolodomo : So far I was only able to execute a manual alarm by pressing the button on the device. This action was reported by a state change of the Test in Progress channel. To test the Smoke Alarm channel I have first to order a test spray.

@digitaldan : I see in the screen capture that the channel ā€œSmoke Alarmā€ is of type ā€œNumberā€. What means this number ? I was imagined more something binary, alarm or not.

@raphael : maybe this could be tested with a match or lighter ? By the way, the test is optional :wink:

@digitaldan I got a Yale Smart Lock with Matter and the following warning has occurred 17 times in the past 24 hours:

2025-12-28 08:06:00.392 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:523) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1359) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1472) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1443) ~[?:?]
        at com.google.gson.internal.bind.TreeTypeAdapter$GsonContextImpl.deserialize(TreeTypeAdapter.java:200) ~[?:?]
        at org.openhab.binding.matter.internal.client.MatterWebsocketClient$EventTriggeredMessageDeserializer.deserialize(MatterWebsocketClient.java:678) ~[?:?]
        at org.openhab.binding.matter.internal.client.MatterWebsocketClient$EventTriggeredMessageDeserializer.deserialize(MatterWebsocketClient.java:1) ~[?:?]
        at com.google.gson.internal.bind.TreeTypeAdapter.read(TreeTypeAdapter.java:95) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1359) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1472) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:1416) ~[?:?]
        at org.openhab.binding.matter.internal.client.MatterWebsocketClient.lambda$2(MatterWebsocketClient.java:298) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
        at java.lang.Thread.run(Thread.java:1583) [?:?]
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $
        at com.google.gson.internal.bind.JsonTreeReader.expect(JsonTreeReader.java:184) ~[?:?]
        at com.google.gson.internal.bind.JsonTreeReader.beginObject(JsonTreeReader.java:101) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:512) ~[?:?]
        ... 17 more

EDIT, i’ll see about adding the state options to the README for channels like this.

Can you enable TRACE logging on the Matter binding and send me the JSON message(s) right before that error? (the line will start with onWebSocketText { )

1 Like