Matter Binding

I feel like I’m crazy… but does the openHAB Matter binding not support initial provisioning of WiFi devices? The readme makes it clear that Thread devices need to be set up in another ecosystem first, but other than that, it’s just “put in the manual pair code”. But if I do that I just get a Raw Output Value of { "result": "The device could not be discovered using the provided code" }. Which makes sense, since the device isn’t on any network yet, and I don’t see how openHAB could communicate in any way without additional information. My openHAB is running on Linux box (Intel NUC) with an ethernet connection. It has WiFi hardware, but it’s unconfigured, and bluetooth, but that’s not set up in any way in openHAB. My server is also multi-homed with a separate VLAN for IoT devices (which has a separate WiFi SSID), but I don’t think I’m even getting that far for that to be an issue. Is this just a magical thing that if your server is on WiFi, the pairing code (just 10 digits??) has enough information in it to find a SoftAP from the device, join that network, infer the WiFi credentials the server is using, and send those credentials to the device? Or is BLE provisioning supposed to work?

The device I’m trying to connect is an Intecular InvisOutlet Pro. From my phone, I don’t see that it’s even advertising a SoftAP, nor can I find it in a search of bluetooth devices, though using the official InvisHome app, it sees it immediately, so I’m assuming it is BLE. BUT.. setting it up this way it seems to just use the WiFi credentials my phone is using, which I would prefer to connect it to my IoT SSID instead.

EDIT: I at least got it connected to openHAB by adding it to the manufacturer’s app first, then to HomeKit (because the "Turn on Pairing Mode” in the manufacturer’s app only have an 8 digit code, and it failed adding to openHAB with that), then to openHAB from “Turn On Pairing Mode” in the iOS Home app. I’ll fight with using the IoT SSID another day.

If I correctly remember, I was also forced to connect my Tapo P110M to the Tapo app before being able to pair it with any Matter controller using the QR code.

That is something that the manufacturer should not require normally. Unfortunately you have sometimes to do it!

So up until just very recently, most matter devices required the manufacturer app to get on the wifi and get a code. That has changed in the last few months as true native Matter only wifi devices have started hitting the market. So yes, you need to use the Apple/Google/Alexa app or the manufacture app to pair first, get it on the network and then get a code. I’ll need to update the docs on that

I have a IOS app i wrote that solves this, i’m planning on integrating it into our openHAB mobile app, right now this supports both Wifi and Thread devices. The only sticking point is Apple requires a special “entitlement” to access matter IOS features and you have to be a member of the Thread working group to qualify for it, which is like $15k to join. I’m going to see if we can get around that somehow, or hopefully they change that policy. I also plan on doing the same for the Android app.

3 Likes

I dream for the day when matter matures enough that device manufactures see Matter as their only realistic choice and choose to not make a proprietary app. All device manufactures apps are essentially Spyware for harvesting user data.

Hi Dan,

Hope all is fine.

I got somewhat sidetracked but finally I was able to come back to the problem with my WOOX smart plug. You mentioned you required the JSON initialization string. I hope I located the part you need. Appreciate your insights about this plug. Thanks

I’m still using 5.0.0.0. I believe I’m using the Matter Binding wich came OOTB with that version.

2025-08-18 20:09:02.276 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"nodeData","data":{"id":"4640140916271736671","rootEndpoint":{"number":0,"clusters":{"Groups":{"id":4,"name":"Groups","nameSupport":{"nameSupport":true,"groupNames":true},"clusterRevision":4,"featureMap":{"groupNames":true},"attributeList":[0,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,2,3,4,5],"generatedCommandList":[0,1,2,3]},"Descriptor":{"id":29,"name":"Descriptor","deviceTypeList":[{"deviceType":22,"revision":1}],"serverList":[4,29,31,40,42,43,48,49,50,51,52,54,60,62,63,64],"clientList":[41],"partsList":[1],"clusterRevision":1,"featureMap":{"tagList":false},"attributeList":[0,1,2,3,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[]},"AccessControl":{"id":31,"name":"AccessControl","acl":[{"privilege":5,"authMode":2,"subjects":["5407251166427936440"],"targets":null,"fabricIndex":7}],"subjectsPerAccessControlEntry":64,"targetsPerAccessControlEntry":3,"accessControlEntriesPerFabric":3,"clusterRevision":1,"featureMap":{"extension":false,"managedDevice":false},"attributeList":[0,1,2,3,4,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[],"extension":[]},"BasicInformation":{"id":40,"name":"BasicInformation","dataModelRevision":1,"vendorName":"WOOX","vendorId":5190,"productName":"Smart Plug","productId":965,"nodeLabel":"","location":"XX","hardwareVersion":1,"hardwareVersionString":"1.0","softwareVersion":0,"softwareVersionString":"1.2.6","manufacturingDate":"20220915","partNumber":"R6169","serialNumber":"40000244100196","capabilityMinima":{"caseSessionsPerFabric":3,"subscriptionsPerFabric":65535},"clusterRevision":1,"featureMap":{},"attributeList":[0,1,2,3,4,5,6,7,8,9,10,11,12,15,19,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[]},"OtaSoftwareUpdateRequestor":{"id":42,"name":"OtaSoftwareUpdateRequestor","defaultOtaProviders":[],"updatePossible":true,"updateState":1,"updateStateProgress":null,"clusterRevision":1,"featureMap":{},"attributeList":[0,1,2,3,65528,65529,65531,65532,65533],"acceptedCommandList":[0],"generatedCommandList":[]},"LocalizationConfiguration":{"id":43,"name":"LocalizationConfiguration","activeLocale":"en-US","supportedLocales":["en-US","de-DE","fr-FR","en-GB","es-ES","zh-CN","it-IT","ja-JP"],"clusterRevision":1,"featureMap":{},"attributeList":[0,1,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[]},"GeneralCommissioning":{"id":48,"name":"GeneralCommissioning","breadcrumb":0,"basicCommissioningInfo":{"failSafeExpiryLengthSeconds":60,"maxCumulativeFailsafeSeconds":900},"regulatoryConfig":0,"locationCapability":0,"supportsConcurrentConnection":true,"clusterRevision":1,"featureMap":{"termsAndConditions":false},"attributeList":[0,1,2,3,4,65528,65529,65531,65532,65533],"acceptedCommandList":[0,2,4],"generatedCommandList":[1,3,5]},"NetworkCommissioning":{"id":49,"name":"NetworkCommissioning","maxNetworks":1,"networks":[{"networkId":"5056475f484f4d455f303032","connected":true}],"interfaceEnabled":true,"lastNetworkingStatus":0,"lastNetworkId":"5056475f484f4d455f303032","lastConnectErrorValue":null,"scanMaxTimeSeconds":10,"connectMaxTimeSeconds":20,"clusterRevision":1,"featureMap":{"wiFiNetworkInterface":true,"threadNetworkInterface":false,"ethernetNetworkInterface":false},"attributeList":[0,1,2,3,4,65528,65529,65531,308084743,5,6,7,65532,65533],"acceptedCommandList":[0,2,4,6,8],"generatedCommandList":[1,5,7],"unknownAttribute_0x125d0007":"en-US"},"DiagnosticLogs":{"id":50,"name":"DiagnosticLogs","clusterRevision":1,"featureMap":{},"attributeList":[65528,65529,65531,65532,65533],"acceptedCommandList":[0],"generatedCommandList":[1]},"GeneralDiagnostics":{"id":51,"name":"GeneralDiagnostics","networkInterfaces":[{"name":"r0","isOperational":true,"offPremiseServicesReachableIPv4":null,"offPremiseServicesReachableIPv6":null,"hardwareAddress":"c482e118c6ac","iPv4Addresses":["c0a80185"],"iPv6Addresses":["fe80000000000000c682e1fffe18c6ac"],"type":1}],"rebootCount":13,"upTime":376655,"testEventTriggersEnabled":false,"clusterRevision":1,"featureMap":{"dataModelTest":false},"attributeList":[0,1,2,8,65528,65529,65531,65532,65533],"acceptedCommandList":[0],"generatedCommandList":[]},"SoftwareDiagnostics":{"id":52,"name":"SoftwareDiagnostics","threadMetrics":[{"id":6,"name":"app_msgA","stackFreeCurrent":1799704897,"stackFreeMinimum":349,"stackSize":1211118157},{"id":18,"name":"kmsgbk","stackFreeCurrent":1245795393,"stackFreeMinimum":635,"stackSize":1198091624},{"id":22,"name":"core_thB","stackFreeCurrent":1633054262,"stackFreeMinimum":343,"stackSize":1632128625},{"id":17,"name":"temp_dem","stackFreeCurrent":1178696268,"stackFreeMinimum":136,"stackSize":1802068790},{"id":8,"name":"wq_highG","stackFreeCurrent":1801073456,"stackFreeMinimum":214,"stackSize":1380139842},{"id":15,"name":"ble","stackFreeCurrent":1094795585,"stackFreeMinimum":643},{"id":10,"name":"mq_cntl","stackFreeMinimum":325},{"id":11,"name":"button_","stackFreeMinimum":444},{"id":4,"name":"timer_t","stackFreeMinimum":705},{"id":9,"name":"health_","stackFreeMinimum":246},{"id":20,"name":"wpas_th","stackFreeCurrent":353936970,"stackFreeMinimum":633,"stackSize":4350852},{"id":16,"name":"host_ma","stackFreeCurrent":952,"stackFreeMinimum":623,"stackSize":4349768},{"id":12,"name":"tfm_bas","stackFreeCurrent":48,"stackFreeMinimum":876},{"id":5,"name":"TUYA_TC","stackFreeCurrent":4349908,"stackFreeMinimum":291,"stackSize":4350096},{"id":7,"name":"sys_timp","stackFreeCurrent":1164137286,"stackFreeMinimum":91,"stackSize":862147650},{"id":3,"name":"idle","stackFreeCurrent":1094795585,"stackFreeMinimum":223,"stackSize":1497448769},{"id":23,"name":"CHIP","stackFreeCurrent":4246316,"stackFreeMinimum":913,"stackSize":4349280}],"currentHeapFree":36608,"currentHeapUsed":114368,"clusterRevision":1,"featureMap":{"watermarks":true},"attributeList":[0,1,2,3,65528,65529,65531,65532,65533],"acceptedCommandList":[0],"generatedCommandList":[],"currentHeapHighWatermark":139724},"WiFiNetworkDiagnostics":{"id":54,"name":"WiFiNetworkDiagnostics","bssid":"08cd41001d60","securityType":5,"wiFiVersion":3,"channelNumber":1,"rssi":-54,"clusterRevision":1,"featureMap":{"packetCounts":false,"errorCounts":false},"attributeList":[0,1,2,3,4,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[]},"AdministratorCommissioning":{"id":60,"name":"AdministratorCommissioning","windowStatus":0,"adminFabricIndex":null,"adminVendorId":null,"clusterRevision":1,"featureMap":{"basic":false},"attributeList":[0,1,2,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,2],"generatedCommandList":[]},"OperationalCredentials":{"id":62,"name":"OperationalCredentials","nocs":[{"noc":"15300101012402013703241400182604e81b082e26056852b542370624150127115fe7212e941765401824070124080130094104a8356f293bb8bdf32aeffb2166b6211fa7c4dd5f926a09c594f49e04ca4661bf386fee1ee5dc0c4c21d2d3c8cac232858aa3257d859f224fa1e52e2209c177a9370a35012801182402013603040204011830041475833d82d553f54af689bb45fe4957895175fd093005146278974c0ff09ffe9a04f7e93272a2304b682c0e18300b409265d58c262c9bfcc4f0b622a483970022297001ada514f6137586a47cfdeda3f8d80b4fa2b36018b0df65c9980a6fa881ca81cd82831d06865fd7b425a71e0418","icac":null,"fabricIndex":7}],"fabrics":[{"rootPublicKey":"04d2bb31342525f6c1a777151bde336f2e57f1e4f219ab118e00a6d1732a28ca85d58c0062860fce2e18a29112369fa940393d277916c1ed04709252b208372be2","vendorId":65521,"fabricId":"1","nodeId":"4640140916271736671","label":"openHAB: controller-385a4b8ee5","fabricIndex":7}],"supportedFabrics":5,"commissionedFabrics":3,"trustedRootCertificates":["153001010124020137032c840255532c0706476f6f676c652c010b4d617474657220526f6f74271401000000feffffff1826047fd2432926057f945be537062c840255532c0706476f6f676c652c010b4d617474657220526f6f74271401000000feffffff18240701240801300941045b37df6549c20dc8d722a6b8acb660a8a764ce7baf6c6c224f7ee84349684ad7d809ff650033d1527dcf1fbaac6a9c3ad8b41edac909f7b5c760fd542c892375370a350129012402011824026030041472c201f7571913b348ca00ca7b45f4774668c97e30051472c201f7571913b348ca00ca7b45f4774668c97e18300b4065164b166adff18c15610a8ce91bd703e9c1f677b711ce133505152df0da15111675ac5591cee786851cdd9efdad296674bebcb2a3a3209bcde7b309db552c6f18","153001090119fbbae394444e672402013703271401000000cacacaca182604e93a872b2605e9401f513706271401000000cacacaca18240701240801300941047192a1b7b5db9c41c31c277dfa0e9bda0987c21cfe8b373b47160a195e25e8aef1afecc9f59b9859358860179eed62c2254321fcc118bcc699a661742411336c370a350129011824026030041443d42d7c8fa13c2b04a404ae31cd53d25202288130051443d42d7c8fa13c2b04a404ae31cd53d25202288118300b40f34872544cf81725079e2d5dd412a3d0f3287026782a37b52273e7e94529126ac04665362ed9d9d20414d62e56b6ff78f1a434d0d414aa85c39f6be1728f098518","153001010024020137032414001826045fe0062e2605df16b44237062414001824070124080130094104d2bb31342525f6c1a777151bde336f2e57f1e4f219ab118e00a6d1732a28ca85d58c0062860fce2e18a29112369fa940393d277916c1ed04709252b208372be2370a35012901182402603004146278974c0ff09ffe9a04f7e93272a2304b682c0e3005146278974c0ff09ffe9a04f7e93272a2304b682c0e18300b4091f4689e84c2a9dee6f59d3a95a40af5f8bed21859b4b988d707dcd8faa911fb5f00dc089c0aaa1bdf198c28075496e8763b4110dcaff5f2572f090f3cb8eaca18"],"currentFabricIndex":7,"clusterRevision":1,"featureMap":{},"attributeList":[0,1,2,3,4,5,65528,65529,65531,65532,65533],"acceptedCommandList":[0,2,4,6,7,9,10,11],"generatedCommandList":[1,3,5,8]},"GroupKeyManagement":{"id":63,"name":"GroupKeyManagement","groupKeyMap":[],"groupTable":[],"maxGroupsPerFabric":3,"maxGroupKeysPerFabric":3,"clusterRevision":1,"featureMap":{"cacheAndSync":false},"attributeList":[0,1,2,3,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,3,4],"generatedCommandList":[2,5]},"FixedLabel":{"id":64,"name":"FixedLabel","labelList":[{"label":"room","value":"bedroom 2"},{"label":"orientation","value":"North"},{"label":"floor","value":"2"},{"label":"direction","value":"up"}],"clusterRevision":1,"featureMap":{},"attributeList":[0,65528,65529,65531,65532,65533],"acceptedCommandList":[],"generatedCommandList":[]}},"children":[{"number":1,"clusters":{"Identify":{"id":3,"name":"Identify","identifyTime":0,"identifyType":2,"clusterRevision":4,"featureMap":{},"attributeList":[0,1,65528,65529,65531,65532,65533],"acceptedCommandList":[0,64],"generatedCommandList":[0]},"Groups":{"id":4,"name":"Groups","nameSupport":{"nameSupport":true,"groupNames":true},"clusterRevision":4,"featureMap":{"groupNames":true},"attributeList":[0,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,2,3,4,5],"generatedCommandList":[0,1,2,3]},"OnOff":{"id":6,"name":"OnOff","onOff":true,"clusterRevision":4,"featureMap":{"lighting":false,"deadFrontBehavior":false,"offOnly":false},"attributeList":[0,16387,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,2,64,65,66],"generatedCommandList":[],"startUpOnOff":null},"Descriptor":{"id":29,"name":"Descriptor","deviceTypeList":[{"deviceType":266,"revision":1}],"serverList":[3,4,6,29,308149265],"clientList":[],"partsList":[],"clusterRevision":1,"featureMap":{"tagList":false},"attributeList":[0,1,2,3,65528,65529,65531,65532,65533],"acceptedCommandList":[0,1,2,3,4,5,6,7],"generatedCommandList":[]},"Unknown cluster 0x125dfc11":{"id":308149265,"name":"Unknown cluster 0x125dfc11","clusterRevision":5,"featureMap":{},"attributeList":[65528,65529,65531,308084737,308084745,308084746,308084748,308084753,308084754,308084755,308084769,308084770,308084771,308084772,308084773,308084774,308084775,308084776,308084777,308084778,308084779,65532,65533],"acceptedCommandList":[],"generatedCommandList":[],"unknownAttribute_0x125d0001":0,"unknownAttribute_0x125d0009":255,"unknownAttribute_0x125d000a":0,"unknownAttribute_0x125d000c":0,"unknownAttribute_0x125d0011":"","unknownAttribute_0x125d0012":"","unknownAttribute_0x125d0013":"","unknownAttribute_0x125d0021":0,"unknownAttribute_0x125d0022":0,"unknownAttribute_0x125d0023":0,"unknownAttribute_0x125d0024":2232,"unknownAttribute_0x125d0025":1,"unknownAttribute_0x125d0026":553,"unknownAttribute_0x125d0027":27000,"unknownAttribute_0x125d0028":14866,"unknownAttribute_0x125d0029":2800,"unknownAttribute_0x125d002a":0,"unknownAttribute_0x125d002b":0}},"children":[]}]}}}}

Thanks for the JSON, so yeah that uses a non standard cluster for its energy monitoring. At some point i do plan to try and support that, i’m not sure when however. Hopefully basic ON/OFF control is working in any case.

Thanks for you answer.

Yes, on/off is working.

At some point i do plan to try and support that

That would be great, thanks. I’ve acquired a couple of Tapo P110M. I read that @Lolodomo confirmed the power management after a firmware update, is coming through in OH. I’ll read through the different messages talking about the channels and clusters as it seem to be a topic of discussion. For now, I’ll use my WOOX plugs for powering devices which I know are not requirement to much electricity.

My smartplugs from Tapo got the expected update. Quick disable/enable of their Thing and 5 additional energy measurement channels got added.

OH Matter binding handled this like a charm whereas my Google Home is struggling. For some reason it sees it as a additional new Matter device.

Excellent, just FYI i’m planning on continuing the work @Lolodomo did with providing a better channel for calculating the measurement of power over the sample period, probably this weekend when i finally have some time to work on this again.

Yeah, thats odd, although i have found the Matter client support in Google home is rather minimal, i am guessing thats going to get better soon as Google has gone all in on Matter and Thread :crossed_fingers:… but who knows ?

Since upgrading from 5.0.0 to 5.0.1 the label metadata option does not work anymore for Amazon Alexa connected devices through the Matter Bridge function.

Example:

Dimmer Technisat_1_Dim "Küche Dimmer" { channel="zwave:device:uzb:node49:switch_dimmer", matter="DimmableLight" [label="Küchenlicht"] }

leads to

Küche Dimmer in Alexa instead of Küchenlicht

This worked fine in 5.0 Release, but I am not sure if it is a Matter issue or an Amazon Alexa issue, though …

is this binding not available for OH4 at add-on store? couldn’t find a hint…README says: “Install the Matter binding from the openHAB add-on store.”

Correct. The binding was released with OH 5 and not available for OH 4.

1 Like

Thanks I’ll take a look tomorrow !

I am currently trying to get openhab running as bridge to use google home. I can pair the bridge but all devices are offline.

However it appears to me that the bridge is advertising the ipv4 address:

avahi-browse -rt _matter._tcp

  • wlp1s0 IPv6 EE9E95F762E6BF1B-00000000666E0369 _matter._tcp local
  • wlp1s0 IPv6 FF31D95C65DEA0D7-53F90FE102623B18 _matter._tcp local
  • wlp1s0 IPv4 EE9E95F762E6BF1B-00000000666E0369 _matter._tcp local
  • wlp1s0 IPv4 FF31D95C65DEA0D7-53F90FE102623B18 _matter._tcp local
    = wlp1s0 IPv6 EE9E95F762E6BF1B-00000000666E0369 _matter._tcp local
    hostname = [2ACCC3D2AD2D0000.local]
    address = [192.168.3.2]
    port = [5540]
    txt = [“SAT=4000” “SAI=300” “SII=500”]
    = wlp1s0 IPv6 FF31D95C65DEA0D7-53F90FE102623B18 _matter._tcp local
    hostname = [2ACCC3D2AD2D0000.local]
    address = [192.168.3.2]
    port = [43059]
    txt = [“SAT=4000” “SAI=300” “SII=500”]
    = wlp1s0 IPv4 EE9E95F762E6BF1B-00000000666E0369 _matter._tcp local
    hostname = [2ACCC3D2AD2D0000.local]
    address = [192.168.3.2]
    port = [5540]
    txt = [“SAT=4000” “SAI=300” “SII=500”]
    = wlp1s0 IPv4 FF31D95C65DEA0D7-53F90FE102623B18 _matter._tcp local
    hostname = [2ACCC3D2AD2D0000.local]
    address = [192.168.3.2]
    port = [43059]
    txt = [“SAT=4000” “SAI=300” “SII=500”]

I am using docker and inside the container I have the following addresses:

docker exec -it openhab /bin/bash
root@2e5a08dd9acd:/openhab# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if109: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 86:58:b9:5d:06:20 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.18.0.12/16 brd 172.18.255.255 scope global eth0
valid_lft forever preferred_lft forever
110: eth1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 2a:cc:c3:d2:ad:2d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.3.2/24 brd 192.168.3.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fdb9:418d:dbe0:0:28cc:c3ff:fed2:ad2d/64 scope global dynamic mngtmpaddr
valid_lft 85907sec preferred_lft 85907sec
inet6 fdb9:418d:dbe0::2/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::28cc:c3ff:fed2:ad2d/64 scope link
valid_lft forever preferred_lft forever

any Idea why the bridge picks the 192.168.3.2?

It binds and advertises all addresses that it can access, both IPV4 and IPV6.

If its paired, it means it was able to talk to the bridge via matter at some point

Can you be more specific about how you are using docker? How are you running networking, what is it running on? What does your docker file look like? How have you configured iPV6 for this environment (host and container)?

I would also need logs to help, if you can put the binding in TRACE mode and restart the bridge (like toggling enable in the MainUI matter settings menu and clicking save) that will show us what its binding to, and there should be logs when Google tries to connect, if not, reboot the google device and then watch for lots of logs a min or two latter when it connects.

While IPV6 is required for device communication by the standard, IPV4 works if client and server support it. Alexa for example defaults to using IPV4 in my network for example, while Apple defaults to the IPV6 address that my openHAB advertises.

I suppose that the interface might be running on both addresses. However on the dns advertisement it sends the IPv4 address for the IPV6 entry as posted above.

I am using Docker and assigning a macVlan to the container:

Here is a shortened version of my compose file:

version: “3.10”
services:
openhab:
image: “openhab/openhab:latest”
container_name: openhab
restart: always
depends_on:

  • influxdb
    volumes:
  • “/etc/localtime:/etc/localtime:ro”
  • “/etc/timezone:/etc/timezone:ro”
  • “/opt/data/openhab/addons:/openhab/addons”
  • “/opt/data/openhab/conf:/openhab/conf”
  • “/opt/data/openhab/userdata:/openhab/userdata”
    environment:
    CRYPTO_POLICY: “unlimited”
    EXTRA_JAVA_OPTS: “-Duser.timezone=Europe/Berlin”
    OPENHAB_HTTP_PORT: “8080”
    OPENHAB_HTTPS_PORT: “8443”
    networks:
    dockervlan:
    ipv4_address: 192.168.3.2
    ipv6_address: “fdb9:418d:dbe0::2”
    default:

networks:
default:
name: HomeAutomation
driver: bridge
attachable: true

dockervlan:
name: dockervlan
driver: macvlan
driver_opts:
parent: enp2s0
enable_ipv6: true
ipam:
config:

  • subnet: “192.168.3.0/24”
    gateway: “192.168.3.1”
  • subnet: “fdb9:418d:dbe0::/64”
    gateway: “fdb9:418d:dbe0::1”

The container also receives an ipv6 address from the router. The addresses i posted earlier where from inside the container.

If I try netcat from my laptop i can also reach the bridge via ipv6 but apparently not via ipv4 which is strange:

$ nc -u -v -6 fdb9:418d:dbe0:0:94e7:6eff:feb4:91d7 5540
Connection to fdb9:418d:dbe0:0:94e7:6eff:feb4:91d7 5540 port [udp/*] succeeded!

$ nc -u 192.168.3.2 5540

#hits timeout

Here are the logs.

logfile.txt (93.2 KB)

There are no entries from the time the device is connecting. I am using the google app on my phone here. For whatever reason there are no entries. I even removed the bridge and paired it again. Same thing. No log entries on openhab side.

Apparently only the logviewer was not showing some entries. Sorry for that. I reset the bridge and then paired the phone again. Here are the logs of that process.

matterParingLog.txt (213.8 KB)

Is this a iOS device or Android?

The logs show that a device with the IPV6 address fdb9:418d:dbe0:0:e4d8:63b5:3beb:a825 is pairing successfully with your bridge so its likely the IPV6 address is being broadcasted correctly (or it would not have an ipv6 address to connect to), but then no traffic after that (so its not reading the devices). If using the google home app on iOS, then the Apple/iPhone device actually does the initial pairing using the Apple matter SDK, and then hands that off to the Google hardware when its done, which means it could be that your phone is what connected, but the Google hardware can’t reach it. This is real pain sometimes for many reasons (which i will need to come up with some tools for). If you are on Android, then it might do something similar, using the android phone to pair before handing off to the Google device. (both vendors kinda agreed on this method i guess, Alexa does not do this).

The not being able to connect via IPV4 seems odd, I take it you can reach your openHAB on the 192.168.3.2 address ?

I also run Macvlan on my container, but my container has a single ethernet device, yours seems to have 2 devices, including what looks like a docker bridge ip ? (172.18.0.12). I don’t know if that effects anything. You also have 2 IPV6 addresses, i would remove “fdb9:418d:dbe0::2” from your config since your container is also grabbing fdb9:418d:dbe0:0:28cc:c3ff:fed2:ad2d/64 via SLAAC and see if that helps ? Also is your Google Home device on the same Lan/VLan?

here’s mine

root@efbf1bc82ed0:/openhab# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo
       valid_lft forever preferred_lft forever
319: eth0@if61: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 6e:ba:ea:54:6f:7b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.91.10/23 brd 192.168.91.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2600:7903:de1a:ed01:6cba:eaff:fe54:6f7b/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 80761sec preferred_lft 80761sec
    inet6 fe80::6cba:eaff:fe54:6f7b/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Lastly, i forgot, it actually would be helpful to restart the binding (either from the openhab CLI, or just restart openhab) and grab logs, the Matter server will bind to ports when if first starts up, which can be independent of the bridge starting, so we may have missed those logs.

I am on an android device. And I don’t have any google hardware. I just want to use my devices using the Google integration. After pairing the tagged items show up in the Google App. But they are all offline.

The second network device is for an nginx proxy to do the ssl for the UI and to connect to Influx etc.

I can restart openhab and Provide the logs.

Could you test the mdns advertisement on your end to check if it also only Providing the ipv4 address?

Hmm, i have never tested that. I know from others this does work on Apple devices, but i have not tried on Android. I don’t see why it would not as long as you are local in your network. I’m also not sure how that works when the app goes to the background, does it reconnect every time its launched? A bridge with lots of devices can take a while to connect, so things like Google hubs keep always on connections so connects only happen when there are network hiccups (and they can react to real time events).

Linux /Avahi only returns the first found ip address and prefers ipv4 (assuming ipv6 is even enabled). You need to specifically query for the IPV6 address since there are both A and AAA records for it.

For example, my openHAB :

# avahi-browse -rt _matter._tcp
+   eno1 IPv6 2FF8383F54626E41-322CE4B47BA4B4B2             _matter._tcp         local
....bunch more
=   eno1 IPv6 2FF8383F54626E41-322CE4B47BA4B4B2             _matter._tcp         local
   hostname = [6EBAEA546F7B0000.local]
   address = [192.168.91.10]
   port = [5540]
   txt = ["SAT=4000" "SAI=300" "SII=500"]
# avahi-resolve-host-name 6EBAEA546F7B0000.local
6EBAEA546F7B0000.local	192.168.91.10

# avahi-resolve-host-name -6 6EBAEA546F7B0000.local
6EBAEA546F7B0000.local	fe80::6cba:eaff:fe54:6f7b