Is this an issue with the controller or bridge feature (see supported modes below)?
Supported modes
This binding supports 2 different types of Matter functionality.
A Matter controller
This allows openHAB to discover and control other Matter devices like lights, thermostats, window coverings, locks, etc…
A Matter Bridge
This allows openHAB to expose items as Matter devices to other Matter clients. This allows local control of openHAB devices from 3rd party ecosystems like Apple Home, Amazon Alexa, and Google Home.
I had the same error message on one battery device after updating to M3.
After several OH restarts and one OS restart the message changed to “Waiting for data”.
After a couple of minutes the errors went away and everything is working.
Hmm, so I removed the old matter binding from my addons folder, upgraded to m3, installed the official matter addon, and everything worked out of the box. I’m using the Docker builds FYI.
That error is very strange, its like there is an issue with the nodejs app not able to resolve a class, but i don’t see how that would be possible just yet, since the app does load and accepts connections (and throws an proper error message). Do you know if there is an existing NodeJS installation on your PI? Can you start it up with TRACE logging and send me those logs? Would be curious to see the initialization part where we load the WS connection.
I wonder if this is a timing issue on slower hardware, where not all classes have been loaded (required) do to async loading in the webpack file…its the only thing that makes sense to me.
@Lolodomo what happens if you pause your controller thing, restart the bundle, then start your controller thing again (giving it time to load). If you are using the bridge, maybe disable it for this test. EDIT maybe restart it twice, if the fist time errors.
I think i see the problem, its indeed a async loading issue, not with imports, but our class is not entirely initialized before we accept a request. My guess is on startup or other heavy loaded operations, this condition gets hit, on faster hardware or lower load its rare to see, i’ll have a fix shortly.
Hi Dan,
I managed to setup Matter Binding as a bridge for MQTT elements (I want to control my HVAC system with Alexa). So, using the GUI, I created an Item group and added all HVAC Items (modes, fans, temperatures, etc.) as members. I added Matter metadata and configured “Matter Attributes Mapping” with (I think) the corresponding elements. Then I searched and found the new Matter device (“Clima”) in the Alexa app. The “Clima” device gives me the option to set the mode (Heating, Cooling, Auto, Off but not Drying), but when I select the mode in the app I see that the command received from the “mode” element is a number and not a string as needed (0 and not “off”, 1 and not “heat_cool”, etc.) and therefore it is not executed. I saw that I can configure the mapping, but despite what is written in the “Mapping options” text box, when I set the mode via the app I always get a number as a command in the mode Item.
Where am I going wrong?
Thanks for any help.
Hi @p-ranit , this is likely an issue with the UI, I have to admit i probably did not test that as extensively as i should of, and the UI code is actually pretty complex to handle all the different tagging cases. I’ll look at this today and see if i can find a workaround for you in the mean time.
Thanks Dan for the quick reply,
I confirm that I have applied “update group members” when I did the configuration (otherwise the changes are not kept even if you save the configuration).
Ok, its a UI bug. As a workaround, you can modify the yaml in the UI until i get it fixed.
After you save your mappings and click update group members, go back to items and edit your "mode’ item, and edit the Matter metadata. You won’t see the mappings in the UI, but if you click on the code tab, you will see your mappings, like:
We need to remove the “thermostat.systemmode:” entry from under the config, and then unindent the rest of the values (so select them and click “shift tab” ). It should look like this:
But of course with your mappings (i use _heat and so on just for testing). Once you change this, it won’t show up as mapped in the group item, but it should still work. Let me know how that goes.
As described in more detail at the following, this is in regards to a Tapo s505d Matter Wifi Smart Dimmer Switch. This is my second Matter device. The other, a simple on/off wall switch, is working as expected.
This issue that I have encountered is that the binding detects the node for the device and creates a node Thing. But it only provides one channel, a dimmer “levelcontol-level” channel. There is no channel for onoffcontrol-onoff, though the trace log shows that Matter is aware of it both controller clusters.
As described in the link above, if the dimmer channel receives ON, OFF or a number representing the level, it performs the appropriate action on the device. With a virtual switch, I created a rule that makes everything work as expected (ON/OFF switch works both ways as does the dimmer. But I would think that both of these endpoints should be available. I checked the Thing Inbox, and there are no EndPoint Things for the Matter binding there.
This is by design. Since a dimmer accepts ON and OFF , there is no point to having 2 channels. If an ON or OFF command is received, we use the ONOFF cluster in matter, we also respond to ONOFF matter events. And just FYI the matter spec requires dimmer devices to alway include a ONOFF cluster, its not something a vendor has the option of not including.
I’m reading your other post, this definitely seems like a Main UI bug, you can link a Switch item to a dimmer channel in openHAB without a profile, i do that in my file based items all the time. We should open an issue up to fix that in the MainUI.
