Zigbee2mqtt - open source zigbee bridge - Deel 2

[gastje01]

Ik heb heb opzich niks tegen Thread (Of Matter over Thread), maar ik heb nu een goed werkend ZigBee netwerk, volledig lokaal en prima functioneel, waar mogelijk blijf ik dat gewoon uitbreiden in plaats van weer een 'nieuw' netwerk naast mijn huidige te maken. Hetzelfde geldt voor mijn vader, die is nu op zoek naar een doosje GU10 voor de tuin (overkapping), is INNR een goed alternatief voor de Ikea spots?

Andere vraag voor de ZigBee kenners hier. Recent overgestapt op een nieuwe coordinator (POE variant i.v.m. iets meer flexibilteit que plaatsing. Het is een SLZB06 geworden, werkt prima en bij het overzetten heb ik maar een paar lampen hoeven repairen.
Nu heeft dit ding een grotere antenne dan de coordinator die ik hiervoor had en kan ik het zendvermogen een stuk hoger zetten dan ik voorheen kon.

Wat is hierin wijsheid? Lage zendsterte aanhouden zodat er goed gemeshed wordt of net. hoog zodat de coordinator de end devices mogelijk direct kan bereiken? Bij de 2e optie loop ik natuurlijk het risico dat de lampen zelf niet genoeg vermogen hebben om de coordinator direct te bereiken, maar ik weet niet of dit een issue is dat wel of niet door ZigBee zelf opgelost wordt.

[DjoeC]

gastje01 schreef op vrijdag 9 januari 2026 @ 10:23:
Ik heb heb opzich niks tegen Thread (Of Matter over Thread), maar ik heb nu een goed werkend ZigBee netwerk, volledig lokaal en prima functioneel, waar mogelijk blijf ik dat gewoon uitbreiden in plaats van weer een 'nieuw' netwerk naast mijn huidige te maken. Hetzelfde geldt voor mijn vader, die is nu op zoek naar een doosje GU10 voor de tuin (overkapping), is INNR een goed alternatief voor de Ikea spots?

Andere vraag voor de ZigBee kenners hier. Recent overgestapt op een nieuwe coordinator (POE variant i.v.m. iets meer flexibilteit que plaatsing. Het is een SLZB06 geworden, werkt prima en bij het overzetten heb ik maar een paar lampen hoeven repairen.
Nu heeft dit ding een grotere antenne dan de coordinator die ik hiervoor had en kan ik het zendvermogen een stuk hoger zetten dan ik voorheen kon.

Wat is hierin wijsheid? Lage zendsterte aanhouden zodat er goed gemeshed wordt of net. hoog zodat de coordinator de end devices mogelijk direct kan bereiken? Bij de 2e optie loop ik natuurlijk het risico dat de lampen zelf niet genoeg vermogen hebben om de coordinator direct te bereiken, maar ik weet niet of dit een issue is dat wel of niet door ZigBee zelf opgelost wordt.

Algemeen: Meer zendvermogen kan zorgen voor betere ontvangst door de clients. MAAR kan de coordinator dan de clients die minder sterk zijn nog wel horen? Ik ben geen voorstander van veel ongelijkheid...

[Deshmir]

@gastje01 ik heb 2 van de Matter(Thread) GU10's in de tuin hangen, maar 0 verbinding naar de HomePod Mini in de woonkamer. Afstand is ongeveer 13 meter.

Nu een Eve Plug in de schuur erachter gehangen (15m vanaf de HomePod Mini), en nu zijn ze wel connected in het netwerk.

Dus afhangend waar de overkapping zit, zou ik nog even bij Zigbee blijven hangen.

[RobertMe]

Deshmir schreef op vrijdag 9 januari 2026 @ 11:54:
@gastje01 ik heb 2 van de Matter(Thread) GU10's in de tuin hangen, maar 0 verbinding naar de HomePod Mini in de woonkamer. Afstand is ongeveer 13 meter.

Nu een Eve Plug in de schuur erachter gehangen (15m vanaf de HomePod Mini), en nu zijn ze wel connected in het netwerk.

Dus afhangend waar de overkapping zit, zou ik nog even bij Zigbee blijven hangen.

Zowel Zigbee als Thread gebruiken 802.15.4 als standaard voor het radiosignaal door de lucht. Het lijkt mij dus sterk dat de een beter werkt dan de ander (met dezelfde antennes/... en dezelfde instellingen v.w.b. frequentie etc).

[gastje01]

Deshmir schreef op vrijdag 9 januari 2026 @ 11:54:
@gastje01 ik heb 2 van de Matter(Thread) GU10's in de tuin hangen, maar 0 verbinding naar de HomePod Mini in de woonkamer. Afstand is ongeveer 13 meter.

Nu een Eve Plug in de schuur erachter gehangen (15m vanaf de HomePod Mini), en nu zijn ze wel connected in het netwerk.

Dus afhangend waar de overkapping zit, zou ik nog even bij Zigbee blijven hangen.

Dat is ook de bedoeling, het is uitbreiding van een bestaand netwerk, dat lijkt me zinvoller dan er een nieuw netwerk naast te zetten.

DjoeC schreef op vrijdag 9 januari 2026 @ 11:35:
[...]

Algemeen: Meer zendvermogen kan zorgen voor betere ontvangst door de clients. MAAR kan de coordinator dan de clients die minder sterk zijn nog wel horen? Ik ben geen voorstander van veel ongelijkheid...

Dat vraag ik me dus af hoe dat werkt. In theorie zou ik dit kunnen testen door het zendvermogen zeer laag te zetten. De kans dat de lamp achter in m'n tuin dan direct verbinding kan maken is nagenoeg 0, als referentie, 2.4 GHz wifi redt dat ook niet en dat zit op een betere locatie dan deze lamp.

Ik ben vooral nieuwsgierig naar de werking hierachter, ik heb ongeveer 7-12 low LQI clients (op 110 devices) maar deze wisselen nogal. Ik zou verwachten dat wanneer een route sub-optimaal is, ZigBee zelf een nieuwe route zoekt via een hop dichterbij. Dat lijkt in de praktijk ook wel te gebeuren, zij het erg traag. De vraag is alleen of dit ook gebeurt wanneer de coordinator wel tot aan het device komt, maar niet terug.

[DjoeC]

gastje01 schreef op vrijdag 9 januari 2026 @ 12:53:
[...]

Dat is ook de bedoeling, het is uitbreiding van een bestaand netwerk, dat lijkt me zinvoller dan er een nieuw netwerk naast te zetten.


[...]


Dat vraag ik me dus af hoe dat werkt. In theorie zou ik dit kunnen testen door het zendvermogen zeer laag te zetten. De kans dat de lamp achter in m'n tuin dan direct verbinding kan maken is nagenoeg 0, als referentie, 2.4 GHz wifi redt dat ook niet en dat zit op een betere locatie dan deze lamp.

Ik ben vooral nieuwsgierig naar de werking hierachter, ik heb ongeveer 7-12 low LQI clients (op 110 devices) maar deze wisselen nogal. Ik zou verwachten dat wanneer een route sub-optimaal is, ZigBee zelf een nieuwe route zoekt via een hop dichterbij. Dat lijkt in de praktijk ook wel te gebeuren, zij het erg traag. De vraag is alleen of dit ook gebeurt wanneer de coordinator wel tot aan het device komt, maar niet terug.

Tja, met zenders en ontvangers kan ik je dat uit ervaring met zenden en ontvangen wel met zekerheid zeggen. D'r zijn nog veel meer factoren die meespelen maar verschil in zendvermogen wordt meestal niet gecompenseerd door verbeterde ontvangst in het hoog vermogen apparaat. Mijn Zigbee stick staat op de default 5dBm, 3mW terijl ie 20dBm 100mW maximaal kan. Bij maximaal had ik ook dat meerdere devices niet "gehoord" werden. Nu werkt het al een paar jaar soepel. Wel moet je hier en daar repeaters gebruiken en in de Z2M map eens goed kijken naar de LQI (bijvoorbeeld in Network -> type Map). De waarde staat ook op andere pagina's, maar in de Map weergave zie je veel beter hoe alles "loopt".

[DjoeC]

gastje01 schreef op vrijdag 9 januari 2026 @ 12:53:
[...]
Ik ben vooral nieuwsgierig naar de werking hierachter, ik heb ongeveer 7-12 low LQI clients (op 110 devices) maar deze wisselen nogal. Ik zou verwachten dat wanneer een route sub-optimaal is, ZigBee zelf een nieuwe route zoekt via een hop dichterbij. Dat lijkt in de praktijk ook wel te gebeuren, zij het erg traag. De vraag is alleen of dit ook gebeurt wanneer de coordinator wel tot aan het device komt, maar niet terug.

Als ik het zigbee protocol goed begrijp zou "uiteindelijk" de beste route gekozen moeten worden. Maar het is bekend dat niet alle zigbee apparaten de standaard goed volgen . Vooral Aqara doet dat niet, iig bij mij niet...

[HuismAndré]

DjoeC schreef op vrijdag 9 januari 2026 @ 11:35:
[...]

Algemeen: Meer zendvermogen kan zorgen voor betere ontvangst door de clients. MAAR kan de coordinator dan de clients die minder sterk zijn nog wel horen? Ik ben geen voorstander van veel ongelijkheid...

Aan de andere kant. De ontvanger wordt niet dover als hij zelf harder schreeuwt. Simpelste oplossing is gewoon testen. De ene maand een lager vermogen, de andere maand een hoger vermogen. Precies dat heb ik gedaan waarbij het aantal fouten bij laag vermogen 2 was in 1 maand en bij hoog vermogen 0 (ca. 100 devices waarvan 60 coördinator waarbij lampgroepen met grote regelmaat spanningsloos gemaakt worden, dus Zigbee netwerk moet daar soepel mee omgaan). Ik heb hem dus op hoog vermogen gezet omdat dit voor _mijn_ situatie het beste uitpakte in deze beperkte test.

[ Voor 11% gewijzigd door HuismAndré op 10-01-2026 11:20 ]

[Ben(V)]

Aangezien Zigbee verkeer tweeweg verkeer is heeft het aan een kant van de verbinding met veel meer vermogen te laten zenden vrij weinig zin, het device waar de coordinator mee moet communiceren heeft dat vermogen niet en zal dus berichten moeten terug sturen via een of meer routers.
Dat er dan twee wegen gebruikt worden moet wel werken, maar bevordert de soepelheid van de communicatie niet.

Ook zijn er devices die dan alleen met het device willen praten waar ze het bericht van kregen en dan gaat het veel slechter werken omdat de routers dan niet gebruikt worden.

Verder zijn er devices zoals bijvoorbeeld die van aqare, die helemaal niet via routers willen werken maar enkel via het device waar ze eenmaal mee gepaired zijn, dus als je die hebt moet je die altijd met de dichtbijzijnde router pairen en niet met de coordinator.

[DjoeC]

HuismAndré schreef op zaterdag 10 januari 2026 @ 11:17:
[...]

Aan de andere kant. De ontvanger wordt niet dover als hij zelf harder schreeuwt. Simpelste oplossing is gewoon testen. De ene maand een lager vermogen, de andere maand een hoger vermogen. Precies dat heb ik gedaan waarbij het aantal fouten bij laag vermogen 2 was in 1 maand en bij hoog vermogen 0 (ca. 100 devices waarvan 60 coördinator waarbij lampgroepen met grote regelmaat spanningsloos gemaakt worden, dus Zigbee netwerk moet daar soepel mee omgaan). Ik heb hem dus op hoog vermogen gezet omdat dit voor _mijn_ situatie het beste uitpakte in deze beperkte test.

Correct. Hij wordt niet dover. Maar, zou die ontvanger die met 15dBm extra uitzend ook 15dB gevoeliger zijn? Ik geloof er geen bal van. Ofwel: Als het werkt is dat vermoeelijk omdat de coordinator interferentie bij haar (zijn?) eindpunten overstemt terwijl de coordinator zelf geen of minder interferentie heeft. Denk aan: Coordinator midden in huis heeft minder last van de buren dan een schakelaar in de buitenmuur, een lamp op een zolderkamer die in het zicht van signalen van "de buren" hangen.

[HuismAndré]

Ben(V) schreef op zaterdag 10 januari 2026 @ 12:04:
Aangezien Zigbee verkeer tweeweg verkeer is heeft het aan een kant van de verbinding met veel meer vermogen te laten zenden vrij weinig zin, het device waar de coordinator mee moet communiceren heeft dat vermogen niet en zal dus berichten moeten terug sturen via een of meer routers.

Maar wat is daarbij het probleem? Bij het aansturen van lampen is het fijn dat ze "instant" reageren. Dat hun "ack" pas 100ms later aankomt is vaak veel minder boeiend. Ik zie dan ook totaal het probleem niet in een coördinator die, vanwege hoger zendvermogen, meer devices rechtstreeks aanroept maar waarbij het antwoord via een router terug moet komen Bij een lager zendvermogen had dat óók gemoeten (naast dat bij lager vermogen ook het heengaande verkeer door die router(s) verwerkt zou moeten worden).

Ik heb diverse Aqara WSDCGQ11LM temperatuursensoren die berucht zijn om hun nukkigheid qua routerkeuze. Sinds ik het zendvermogen op vol heb staan heb ik NUL problemen met die sensoren (nu al meer dan een jaar foutloos). Zelfs niet met die sensor op zolder die door dikke cementvloeren moet. De ontvanger heeft gevoelige antennes en kan dus prima het kleine signaal van de temp sensor ontvangen. Bij het standaard zendvermogen was juist die sensor op zolder een van de devices die wel eens de handdoek in de ring gooide (waarschijnlijk omdat hij soms de coördinator niet hoorde en vertikte een andere route te kiezen).

Maar, laat ik het nog eens herhalen: Iedereen kan voor zichzelf uittesten wat het meest betrouwbaar werkt. Kost niks, alleen wat tijd. Wat het beste werkt zal ook afhangen van het netwerk. Zoals ik al aangaf: Wij schakelen lichtgroepen die uit staan af van het lichtnet. Ons netwerk is dus nogal dynamisch (want ik vertik het om 60 Hue lampen 24/7 aan de spanning te hebben hangen). Kan zijn dat in zo'n geval het grotere zendvermogen van de coördinator een positief effect heeft vanwege de grotere directe routes dichtheid.

[con1]

Wie kan mij helpen, Ik heb Zigbee2mqtt een aantal Sonoff pluggen,
een chinese regenmelder, een aqare temp. sensor en sinds deze
week een Nod-on temperatuursensor STPH-4-1-00 welke op
een piepklein zonnepaneeltje werkt.
Het probleem hiermee is dat de sensor alleen maar de waarden
(T en RV) stuurt indien er een temperatuurswijziging is van 0,5gr
of een RV wijziging van 3% en anders ieder uur een status.
Ik zou graag minimaal iedere 5 minuten een waarde willen hebben
of bij een wijziging van 0,1 gr. minimaal omdat ik deze in wil zetten
voor ruimteverwarmingsensor.
Weet iemand of je die frequentie kunt aanpassen?

[ Voor 3% gewijzigd door con1 op 10-01-2026 23:22 ]

[BiG-GuY]

con1 schreef op zaterdag 10 januari 2026 @ 23:20:
Wie kan mij helpen, Ik heb Zigbee2mqtt een aantal Sonoff pluggen,
een chinese regenmelder, een aqare temp. sensor en sinds deze
week een Nod-on temperatuursensor STPH-4-1-00 welke op
een piepklein zonnepaneeltje werkt.
Het probleem hiermee is dat de sensor alleen maar de waarden
(T en RV) stuurt indien er een temperatuurswijziging is van 0,5gr
of een RV wijziging van 3% en anders ieder uur een status.
Ik zou graag minimaal iedere 5 minuten een waarde willen hebben
of bij een wijziging van 0,1 gr. minimaal omdat ik deze in wil zetten
voor ruimteverwarmingsensor.
Weet iemand of je die frequentie kunt aanpassen?

In Z2M kan je dit per Device instellen op de Reporting pagina per Device. Standaard staat de Max rep interval op 3600 (s). Je kan deze op van alles instellen, 600 zou kunnen. Gebruik ik zelf ook voor meerdere sensoren die niet snel genoeg waren in Z2M. De Min rep chance reflecteert het verschil tussen ruwe meetwaardes waarop hij geforceerd refresht.

Uiteindelijk ben je wel afhankelijk van je apparaten hoe vaak ze daadwerkelijk data delen, met deze instellingen stel je alleen in of Z2M het binnen gekomen verkeer verwerkt of dropt.

[con1]

Bedankt voor je reactie.
Ik had al zitten spelen met "max interval" maar kreeg
daarbij foutmeldingen. Het zit blijkbaar in de Nod-On
ingebakken. Dus is deze sensor, hoe mooi ook, niet
geschikt voor meting/sturing vloerverwarming, te traag
en te onzuiver. Helaas maar iig geprobeerd.
Voor zaken als buitentemperatuurmeting voldoet hij wel
dus daar ga ik hem voor inzetten.

[Ben(V)]

@con1
Dit is gewoon de standaard methode van batterij devices voor temperatuur.
Het is vrij zinloos om een niet veranderende temperatuur te melden, dus doen ze dat niet om de batterij te sparen.
Als je een sensor vind die het sneller doet zul je merken dat je batterijen blijft vervangen of in dit geval dat de accu gewoon leeg raakt omdat de zonnecel hem niet snel genoeg bij kan laden.
En 0,1 graad zit over het algemeen buiten de nauwkeurigheid van deze sensors en daarom zul je er waarschijnlijk geen vinden die zulke lage delta's kan terugmelden.

De enige optie is een sensor te vinden die wil reageren op polling, wat de meeste temperatuur sensors niet doen, maar als je die vind zul je nog steeds tegen het batterij probleem aanlopen.

Tenslotte lijk me voor een regeling van een vloerverwarming zo'n snelle interval volkomen overbodig is, een vloerverwarming is een super traag systeem die daar helemaal niet op kan reageren.

[RobertMe]

Ben(V) schreef op zondag 11 januari 2026 @ 10:33:
@con1
Dit is gewoon de standaard methode van batterij devices voor temperatuur.
Het is vrij zinloos om een niet veranderende temperatuur te melden, dus doen ze dat niet om de batterij te sparen.
Als je een sensor vind die het sneller doet zul je merken dat je batterijen blijft vervangen of in dit geval dat de accu gewoon leeg raakt omdat de zonnecel hem niet snel genoeg bij kan laden.
En 0,1 graad zit over het algemeen buiten de nauwkeurigheid van deze sensors en daarom zul je er waarschijnlijk geen vinden die zulke lage delta's kan terugmelden.

Onzin:


Aqara temp sensor, meldt gewoon changes van 0,1 graad (per 5 minuten lijkt het?). Zit een CR2032 in en gaat "lang" mee (zo lang dat ik het niet weet, denk rond een jaar).

Edit:
Zelfde trouwens voor mijn Fibaro Multi Sensor (Z-Wave). Zit zo'n "halve lengte AA" batterij in. En dan een PIR, temp sensor en lux sensor. temp en lux meet die (standaard) elke 15 minuten en is instelbaar (ook korter) en ook daarvan gaat de batterij zeker een half jaar mee, maar neig eerder naar 3/4 jaar tot een heel jaar.

[ Voor 12% gewijzigd door RobertMe op 11-01-2026 10:59 ]

[HuismAndré]

con1 schreef op zondag 11 januari 2026 @ 09:50:
Bedankt voor je reactie.
Ik had al zitten spelen met "max interval" maar kreeg
daarbij foutmeldingen. Het zit blijkbaar in de Nod-On
ingebakken. Dus is deze sensor, hoe mooi ook, niet
geschikt voor meting/sturing vloerverwarming, te traag
en te onzuiver. Helaas maar iig geprobeerd.
Voor zaken als buitentemperatuurmeting voldoet hij wel
dus daar ga ik hem voor inzetten.

Veel batterijgevoede devices slapen tussendoor. Dan kun je commando's erheen sturen totdat je erbij neervalt (maar ze horen het niet). Belangrijk is dus om vlak vóór je zo'n commando verstuurt (echt vlak voor) het device even wakker te maken. Dat kan door kort op de reset knop te drukken (en dat te herhalen zolang je nog geen melding hebt gekregen dat het commando verwerkt is) of, als die reset button er niet is, het device even beet te pakken zodat z'n temperatuur verandert (en hij moet gaan rapporteren). Dat laatste is wel een beetje en hit or miss natuurlijk (maar er zijn nu eenmaal sensoren waarbij men nog en paar cent heeft bespaard door de reset button weg te laten).

In het geval van vloerverwarming kan ik de goedkope Tuya/SonOff kloon temperatuursensoren van harte aanbevelen. Die hebben een bruikbare 0,01 graad resolutie (ideaal bij vloerverwarming waar je bovenop de "trend" wilt zitten om overshoot te voorkomen) en kosten net niks (ik heb nog geen 3 euro per stuk betaald voor die dingen). Gaat om deze apparaatjes:

https://nl.aliexpress.com/item/1005006995080978.html

Let wel op dat je de Zigbee versie kiest (er zijn namelijk ook WiFi versies). Hieronder zie je het verschil tussen een 0.1 graad sensor en een 0.01 graad sensor (onze vloerverwarming).

[HuismAndré]

RobertMe schreef op zondag 11 januari 2026 @ 10:57:
[...]

Onzin:
[Afbeelding]

Aqara temp sensor, meldt gewoon changes van 0,1 graad (per 5 minuten lijkt het?).

Als de verandering hoog genoeg is dan rapporteren ze vaker dan eens per 5 minuten. Gelukkig maar. Maar jammer is wel dat je het bij de Aqara WSDCGQ11LM (meest verkochte temperatuur, luchtvochtigheid en luchtdruksensor van Aqara) zelf niet aan kunt passen.

[con1]

Aan ieder die gereageerd heeft;

Ik was daar wat kort door de bocht door. De tijdspanne maakt
inderdaad in de basis niet uit als ik maar een wake up krijg als
de temperatuur wijzigt En 0,1 graad is goed werkbaar.

[deepbass909]

con1 schreef op zondag 11 januari 2026 @ 09:50:
Bedankt voor je reactie.
Ik had al zitten spelen met "max interval" maar kreeg
daarbij foutmeldingen. Het zit blijkbaar in de Nod-On
ingebakken. Dus is deze sensor, hoe mooi ook, niet
geschikt voor meting/sturing vloerverwarming, te traag
en te onzuiver. Helaas maar iig geprobeerd.
Voor zaken als buitentemperatuurmeting voldoet hij wel
dus daar ga ik hem voor inzetten.

Zo goed als zeker slaapt de sensor als je dit wilt veranderen en dan krijg je een foutmelding (want er komt geen bevestiging terug dat het commando ontvangen/verwerkt is).

Wat je wel of niet kan instellen, is verder volledig afhankelijk van wat de fabrikant beschikbaar heeft gemaakt. Ik heb verschillende thermometers in huis staan, en verschillende "merken" (bij spul van AliExpress is merk altijd een beetje vaag begrip) staan verschillende instellingen toe.

Voorbeeld, ik heb verschillende bewegingsmelders in huis (Ikea Vallhorn, Philips Hue, maar ook "merkloze" Chinese dingen) en bij de Ikea melders kan ik de gevoeligheid niet instellen (en die zijn helaas niet gevoelig genoeg om m'n dochter van 3 betrouwbaar op te merken...), terwijl ik bij de merkloze van alles kan inregelen en eigenlijk beter werkt. En dat is eigenlijk wel vervelend, want de Ikea werkt perfect op 2 oplaadbare AAA NiMH cellen, terwijl die merkloze veel moeilijk verkrijgbare CR2450 batterijen gebruiken...

[deepbass909]

RobertMe schreef op donderdag 1 januari 2026 @ 16:17:
[...]

Totdat die niet meer gemaakt worden. Zie Ikea die alle Zigbee spul de deur uit hebben gedaan "per vandaag" en nog alleen maar Matter (over Thread) spul verkopen.

Alhoewel lampen en knoppen voor lampen schijnbaar ook nog Zigbee ondersteunen. "Voornamelijk" omdat ze dan touchlink? kunnen gebruiken daar waar dat met Matter (over Thread?) nog niet kan, of in ieder geval niet op de apparaten die ze nu hebben uitgebracht.

En gezien zowel Thread als Zigbee gebruik maken van 802.15.4 is er een kans dat er uiteindelijk nogal gehackt gaat worden om Zigbee firmwares voor Thread apparaten te maken. Vaak ondersteund de hardware namelijk wel Zigbee, ook al zou de software (firmware) dat niet doen.

Is daar ergens iets over te vinden? Ik ben wel fan van de slimme stekkers en losse lampen (E27 en GU10), die toch van een wat betrouwbaardere kwaliteit zijn, gevoelsmatig, en erg scherp geprijsd. Dat ze van zigbee af stappen, vind ik erg jammer. Dus als Zigbee nog wel mogelijk is met de nieuwe devices, zou dat wel heel prettig zijn.

Ergens lijkt het mij ook wel logisch als het nog wel mogelijk blijft, Ikea maakt anders in één klap hun hele vorige ecosysteem obsolete...

[RobertMe]

deepbass909 schreef op dinsdag 13 januari 2026 @ 12:41:
[...]


Is daar ergens iets over te vinden? Ik ben wel fan van de slimme stekkers en losse lampen (E27 en GU10), die toch van een wat betrouwbaardere kwaliteit zijn, gevoelsmatig, en erg scherp geprijsd. Dat ze van zigbee af stappen, vind ik erg jammer. Dus als Zigbee nog wel mogelijk is met de nieuwe devices, zou dat wel heel prettig zijn.

Het geldt sowieso alleen voor lampen en de bijbehorende schakelaars. Omdat die nog steeds (Zigbee) TouchLink ondersteunen. De slimme stekkers gaat het dus sowieso niet bij.
Verder meen ik dat het pairen in Zigbee gaat met "9x ...". Thread pairen moet je "3x ...", TouchLink "6x ..." en Zigbee dan 9x.

Ergens lijkt het mij ook wel logisch als het nog wel mogelijk blijft, Ikea maakt anders in één klap hun hele vorige ecosysteem obsolete...

De huidige bridge (die volgens mij niet nieuw is maar al veel langer verkocht wordt) ondersteund volgens mij beide protocollen? Dus daarmee valt het oude Tradfri assortiment prima te combineren met het nieuwe Thread assortiment.

[deepbass909]

RobertMe schreef op dinsdag 13 januari 2026 @ 12:49:
[...]

Het geldt sowieso alleen voor lampen en de bijbehorende schakelaars. Omdat die nog steeds (Zigbee) TouchLink ondersteunen. De slimme stekkers gaat het dus sowieso niet bij.
Verder meen ik dat het pairen in Zigbee gaat met "9x ...". Thread pairen moet je "3x ...", TouchLink "6x ..." en Zigbee dan 9x.


[...]

De huidige bridge (die volgens mij niet nieuw is maar al veel langer verkocht wordt) ondersteund volgens mij beide protocollen? Dus daarmee valt het oude Tradfri assortiment prima te combineren met het nieuwe Thread assortiment.

Ik ben nu een issue in git aan het lezen erover, en daar wordt gesproken over 6 keer aan/uit voor Thread en 12x voor Zigbee Touchlink, met als grootste probleem dat erg totaal geen identifiers meekomen als ze een succesvolle link over zigbee weten te krijgen.

Ik vrees dus dat Ikea einde verhaal voor zigbee spul is...

[JBS]

deepbass909 schreef op dinsdag 13 januari 2026 @ 12:54:
[...]


Ik ben nu een issue in git aan het lezen erover, en daar wordt gesproken over 6 keer aan/uit voor Thread en 12x voor Zigbee Touchlink, met als grootste probleem dat erg totaal geen identifiers meekomen als ze een succesvolle link over zigbee weten te krijgen.

Ik vrees dus dat Ikea einde verhaal voor zigbee spul is...

En doel je dan op de lampen, sensoren, knoppen of stekkers? Hierbij een voorbeeld van een KAJPLATS E27 (specifiek deze https://www.ikea.com/nl/n...-globe-opaalwit-10611302/) in m'n Z2M (inderdaad gekoppeld door eerste 6x aan/uit voor reset en dan 12x aan/uit voor Zigbee mode). Werkt vervolgens feilloos, zowel aan/uit als dimmen als wit spectrum.

[ Voor 13% gewijzigd door JBS op 13-01-2026 14:12 ]

[deepbass909]

JBS schreef op dinsdag 13 januari 2026 @ 14:09:
[...]
En doel je dan op de lampen, sensoren, knoppen of stekkers? Hierbij een voorbeeld van een KAJPLATS E27 (specifiek deze https://www.ikea.com/nl/n...-globe-opaalwit-10611302/) in m'n Z2M (inderdaad gekoppeld door eerste 6x aan/uit voor reset en dan 12x aan/uit voor Zigbee mode). Werkt vervolgens feilloos.

[Afbeelding]

Kajplats, en wat ik daar las, is het afhankelijk van het exacte model lamp of het wel of niet werkt.

[JBS]

deepbass909 schreef op dinsdag 13 januari 2026 @ 14:13:
[...]


Kajplats, en wat ik daar las, is het afhankelijk van het exacte model lamp of het wel of niet werkt.

In de meeste recente release zijn er 5 type KAJPLATS lampen toegevoegd: https://github.com/Koenkk/zigbee2mqtt/releases/tag/2.7.2
https://www.zigbee2mqtt.io/supported-devices/#s=kajplats

Dat bijvoorbeeld 'n specifieke GU10 (https://www.ikea.com/nl/n...rt-wit-spectrum-50611442/) nog niet ondersteund wordt, kan er zomaar mee te maken hebben dat deze nog nergens (in Nederland) bij IKEA op voorraad is(?). Of wellicht toch omdat ze officieel niet Zigbee 3.0 gecertificeerd zijn? https://csa-iot.org/csa-i...p_family=&p_firmware_ver=

En zonder filter op 'KAJPLATS' maar voor volledige IKEA assortiment: https://csa-iot.org/csa-i...p_family=&p_firmware_ver=

[ Voor 28% gewijzigd door JBS op 13-01-2026 14:27 ]

[deepbass909]

JBS schreef op dinsdag 13 januari 2026 @ 14:23:
[...]

In de meeste recente release zijn er 5 type KAJPLATS lampen toegevoegd: https://github.com/Koenkk/zigbee2mqtt/releases/tag/2.7.2
https://www.zigbee2mqtt.io/supported-devices/#s=kajplats

Dat bijvoorbeeld 'n specifieke GU10 (https://www.ikea.com/nl/n...rt-wit-spectrum-50611442/) nog niet ondersteund wordt, kan er zomaar mee te maken hebben dat deze nog nergens (in Nederland) bij IKEA op voorraad is(?). Of wellicht toch omdat ze officieel niet gecertificeerd zijn? https://csa-iot.org/csa-i...p_family=&p_firmware_ver=

Dat ziet er in ieder geval positief uit. Ik blijf me er keer op keer over verbazen hoe actief die database bijgewerkt wordt.

[The Zep Man]

deepbass909 schreef op dinsdag 13 januari 2026 @ 14:28:
Dat ziet er in ieder geval positief uit. Ik blijf me er keer op keer over verbazen hoe actief die database bijgewerkt wordt.

Als Zigbee hardwareboer zou ik (stilletjes) zelf bijdragen aan die database. Dan weet ik dat mijn hardware goed werkt met Z2M, en aan het einde van de dag is hardwareverkoop waar ik mijn geld mee verdien.

[BiG-GuY]

deepbass909 schreef op dinsdag 13 januari 2026 @ 14:28:
[...]


Dat ziet er in ieder geval positief uit. Ik blijf me er keer op keer over verbazen hoe actief die database bijgewerkt wordt.

Dat is bij Z2M dus gelinkt aan de releases. Zodra iets toegevoegd wordt, wordt automatisch de bijbehorende pagina gegenereerd.

Als het een compleet nieuw product is, kan de gegenereerde pagina nog aangepast worden voor dat specifieke product.

Heb al vaker nieuwe producten toegevoegd, wat sinds een tijdje een stuk makkelijker is geworden doordat Z2M de basis al automatisch herkend bij veel apparaten. Daarna kunnen gebruikers zelf meer data rapporteren om eventuele advanced features ook te implementeren.

[ Voor 20% gewijzigd door BiG-GuY op 14-01-2026 08:07 ]

[rogervdh]

Vanochtend ging Z2M opeens plotseling uit de lucht. Ik draai deze als add-on op Home Assistant. Het heeft jaren goed/stabiel gewerkt, maar opeens problemen en ik kreeg het niet meer werkend. In het verleden was wel eens een reboot van de coordinator noodzakelijk, maar dat hielp nu ook niet. Ik gebruik de SLZB-06 coordinator, deze eens gereboot via de webinterface (die kon ik zonder problemen benaderen, ook de SMLight SLZB integratie in Home Assistant had gewoon contact met de coordinator), uiteindelijk deze zelfs uitgetrokken, Z2M config file nog eens bekeken en alles klopte. De coordinator heeft een vast IP-adres (192.168.189.31), etc. etc. Niks lukte, terwijl ik überhaupt helemaal niks aangepast, geupdate of gereboot had. Uiteindelijk maar een backup van HA teruggezet van afgelopen nacht en toen werkte het weer. Ik vond het wel bizar (en ook wel een beetje beangstigend, want ik heb toch zo'n 100 Zigbee devices die opeens niet meer werken). Heeft iemand op basis van onderstaande logging een idee waar het euvel in gezeten zou kunnen hebben of in welke richting ik moet denken? HA, Z2M, firmware SLZB-06, etc. is allemaal volledig up-to-date.

code:

[09:51:08] INFO: [32mPreparing to start...[0m
[09:51:08] INFO: [32mSocat not enabled[0m
[09:51:08] INFO: [32mStarting Zigbee2MQTT...[0m
Starting Zigbee2MQTT without watchdog.
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Removing old log directory '/config/zigbee2mqtt/log/2025-12-04.15-01-46'
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Logging to console, file (filename: log.log)
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Loaded state from file /config/zigbee2mqtt/state.json
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Starting Zigbee2MQTT version 2.7.2 (commit #unknown)
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Starting zigbee-herdsman (8.0.1)
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Using zigbee-herdsman with settings: '"{\"network\":{\"panID\":6754,\"extendedPanID\":[221,221,221,221,221,221,221,221],\"channelList\":[11],\"networkKey\":\"HIDDEN\"},\"databasePath\":\"/config/zigbee2mqtt/database.db\",\"databaseBackupPath\":\"/config/zigbee2mqtt/database.db.backup\",\"backupPath\":\"/config/zigbee2mqtt/coordinator_backup.json\",\"serialPort\":{\"baudRate\":115200,\"path\":\"tcp://192.168.189.31:6638\",\"adapter\":\"zstack\"},\"adapter\":{\"disableLED\":false,\"transmitPower\":20}}"'
[2026-01-14 09:51:09] [34mdebug[39m:    zh:controller: Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":"HIDDEN","panID":6754,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11]},"serialPort":{"baudRate":115200,"path":"tcp://192.168.189.31:6638","adapter":"zstack"},"adapter":{"disableLED":false,"transmitPower":20},"databasePath":"/config/zigbee2mqtt/database.db","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","backupPath":"/config/zigbee2mqtt/coordinator_backup.json"}'
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Opening TCP socket with 192.168.189.31:6638
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Socket connected
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Socket ready
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2026-01-14 09:51:09] [34mdebug[39m:    zh:zstack:unpi:writer: --> buffer [239]
[2026-01-14 09:51:10] [32minfo[39m:     zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2026-01-14 09:51:10] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:10] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:16] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:16] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:22] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:22] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:28] [31merror[39m:    z2m: Error while starting zigbee-herdsman
[2026-01-14 09:51:28] [31merror[39m:    z2m: Failed to start zigbee-herdsman
[2026-01-14 09:51:28] [31merror[39m:    z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-01-14 09:51:28] [31merror[39m:    z2m: Exiting...
[2026-01-14 09:51:28] [31merror[39m:    z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@8.0.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:107:27)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@8.0.1/node_modules/zigbee-herdsman/src/controller/controller.ts:143:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:101:13)
    at start (/app/index.js:149:5)

Deze riedel bleef zich maar eindeloos herhalen, etc.

[Cyberpope]

Heb je je log na opstart al door claude.ai gegooit. Dat werkt soms verhelderd.

Hier zie ik vooral dat hij 3x de coordinator probeert te bereiken, maar dat dit niet lukt (ping).

[HuismAndré]

En de URL die in de logfile getoond wordt:

https://www.zigbee2mqtt.i...tart_crashes-runtime.html

[rogervdh]

HuismAndré schreef op woensdag 14 januari 2026 @ 17:45:
En de URL die in de logfile getoond wordt:

https://www.zigbee2mqtt.i...tart_crashes-runtime.html

Dat had ik al gedaan. Foutmelding verwijst naar deze directe link, maar ik kan niks bedenken wat van toepassing is. Port (= IP adres van de SLZB) is hetzelfde (= fixed IP). Enige wat kan is "Your network Zigbee adapter is not accessible over the LAN network.", maar waarom is dat plotseling het geval terwijl ik de adapter wel kon pingen (en Home Assistant kon 'm ook gewoon benaderen). Vervolgens restore van HA backup en problem solved. Ik kan er vooralsnog niet de vinger op leggen en dat is nooit zo fijn.

[Lizard]

rogervdh schreef op woensdag 14 januari 2026 @ 16:56:
Vanochtend ging Z2M opeens plotseling uit de lucht. Ik draai deze als add-on op Home Assistant. Het heeft jaren goed/stabiel gewerkt, maar opeens problemen en ik kreeg het niet meer werkend. In het verleden was wel eens een reboot van de coordinator noodzakelijk, maar dat hielp nu ook niet. Ik gebruik de SLZB-06 coordinator, deze eens gereboot via de webinterface (die kon ik zonder problemen benaderen, ook de SMLight SLZB integratie in Home Assistant had gewoon contact met de coordinator), uiteindelijk deze zelfs uitgetrokken, Z2M config file nog eens bekeken en alles klopte. De coordinator heeft een vast IP-adres (192.168.189.31), etc. etc. Niks lukte, terwijl ik überhaupt helemaal niks aangepast, geupdate of gereboot had. Uiteindelijk maar een backup van HA teruggezet van afgelopen nacht en toen werkte het weer. Ik vond het wel bizar (en ook wel een beetje beangstigend, want ik heb toch zo'n 100 Zigbee devices die opeens niet meer werken). Heeft iemand op basis van onderstaande logging een idee waar het euvel in gezeten zou kunnen hebben of in welke richting ik moet denken? HA, Z2M, firmware SLZB-06, etc. is allemaal volledig up-to-date.

code:

[09:51:08] INFO: [32mPreparing to start...[0m
[09:51:08] INFO: [32mSocat not enabled[0m
[09:51:08] INFO: [32mStarting Zigbee2MQTT...[0m
Starting Zigbee2MQTT without watchdog.
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Removing old log directory '/config/zigbee2mqtt/log/2025-12-04.15-01-46'
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Logging to console, file (filename: log.log)
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Loaded state from file /config/zigbee2mqtt/state.json
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Starting Zigbee2MQTT version 2.7.2 (commit #unknown)
[2026-01-14 09:51:09] [32minfo[39m:     z2m: Starting zigbee-herdsman (8.0.1)
[2026-01-14 09:51:09] [34mdebug[39m:    z2m: Using zigbee-herdsman with settings: '"{\"network\":{\"panID\":6754,\"extendedPanID\":[221,221,221,221,221,221,221,221],\"channelList\":[11],\"networkKey\":\"HIDDEN\"},\"databasePath\":\"/config/zigbee2mqtt/database.db\",\"databaseBackupPath\":\"/config/zigbee2mqtt/database.db.backup\",\"backupPath\":\"/config/zigbee2mqtt/coordinator_backup.json\",\"serialPort\":{\"baudRate\":115200,\"path\":\"tcp://192.168.189.31:6638\",\"adapter\":\"zstack\"},\"adapter\":{\"disableLED\":false,\"transmitPower\":20}}"'
[2026-01-14 09:51:09] [34mdebug[39m:    zh:controller: Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":"HIDDEN","panID":6754,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11]},"serialPort":{"baudRate":115200,"path":"tcp://192.168.189.31:6638","adapter":"zstack"},"adapter":{"disableLED":false,"transmitPower":20},"databasePath":"/config/zigbee2mqtt/database.db","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","backupPath":"/config/zigbee2mqtt/coordinator_backup.json"}'
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Opening TCP socket with 192.168.189.31:6638
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Socket connected
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Socket ready
[2026-01-14 09:51:09] [32minfo[39m:     zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2026-01-14 09:51:09] [34mdebug[39m:    zh:zstack:unpi:writer: --> buffer [239]
[2026-01-14 09:51:10] [32minfo[39m:     zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2026-01-14 09:51:10] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:10] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:16] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:16] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:22] [34mdebug[39m:    zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2026-01-14 09:51:22] [34mdebug[39m:    zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2026-01-14 09:51:28] [31merror[39m:    z2m: Error while starting zigbee-herdsman
[2026-01-14 09:51:28] [31merror[39m:    z2m: Failed to start zigbee-herdsman
[2026-01-14 09:51:28] [31merror[39m:    z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-01-14 09:51:28] [31merror[39m:    z2m: Exiting...
[2026-01-14 09:51:28] [31merror[39m:    z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@8.0.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:107:27)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@8.0.1/node_modules/zigbee-herdsman/src/controller/controller.ts:143:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:101:13)
    at start (/app/index.js:149:5)

Deze riedel bleef zich maar eindeloos herhalen, etc.

Ik zie zigbee-herdsman staan, moet dat niet ember zijn voor de SLZB-06?

Dit stukje staat in mijn configuration.yaml:

YAML:

serial:
  adapter: ember
  rtscts: false
  port: tcp://192.168.1.xx:6638
  baudrate: 115200

[BiG-GuY]

Lizard schreef op donderdag 15 januari 2026 @ 13:12:
[...]

Ik zie zigbee-herdsman staan, moet dat niet ember zijn voor de SLZB-06?

Dit stukje staat in mijn configuration.yaml:

YAML:

serial:
  adapter: ember
  rtscts: false
  port: tcp://192.168.1.xx:6638
  baudrate: 115200

Ember is alleen voor de SLZB-06M met Silicon Labs chip, de normale SLZB-06 heeft een Texas Instruments chip, dus gebruik je zStack voor.

[JBS]

deepbass909 schreef op dinsdag 13 januari 2026 @ 14:28:
[...]


Dat ziet er in ieder geval positief uit. Ik blijf me er keer op keer over verbazen hoe actief die database bijgewerkt wordt.

En de KAJPLATS GU10 (https://www.ikea.com/nl/n...rt-wit-spectrum-50611442/) doet ook Zigbee (ook voor deze geldt 12x aan/uit voor Zigbee mode).

[JBS]

JBS schreef op zondag 18 januari 2026 @ 13:23:
[...]
En de KAJPLATS GU10 (https://www.ikea.com/nl/n...rt-wit-spectrum-50611442/) doet ook Zigbee (ook voor deze geldt 12x aan/uit voor Zigbee mode).

De MYGGBETT kunnen wel via Zigbee touchlink direct gekoppeld worden aan een lamp, maar ik krijg 'm niet gepaired met Z2M. Ook vlakbij de Zigbee coördinator en 4x op knopje drukken voor touchlink, verbind ie met 'n lamp verderop.

De MYGGBETT lijkt dus geen volwaardige "Zigbee mode" te hebben. Heb 'm nu dus in HA via Matter over Thread.

[Eärendil]

Heb je ook de methode geprobeerd die voor BILRESA beschreven is:

Press the pairing button 4 times. When the first LED blinks, press the pairing button 8 times.

https://www.zigbee2mqtt.io/devices/E2490.html

[DAX23E]

Ik gebruik al meer dan een jaar ikea lampen via Zigbee2MQTT. Het toevoegen ging toen super makkelijk.

Ik heb nog 3 ongebruikte over, maar het toevoegen lukt niet met de huidige versie 2.7.2-1. Deze versie heeft ook de nieuwe layout. Ik heb de lampen ook al meerdere keren gereset. En als in op de "Join toestaan" knop klik in Zigbee2MQTT dan zie ik verder niks gebeuren. Ook het aantal apparaten blijft gelijk. De lamp staat 50cm van de ontvanger.

Doe ik iets verkeerd?

Schopje naar het juiste topic

[ Voor 4% gewijzigd door Septillion op 22-01-2026 20:11 ]

[Septillion]

@DAX23E Als je op "Permit join" drukt, verandert hij dan in "Disable join x:xx" waarbij x:xx aftelt?

[InjecTioN]

DAX23E schreef op donderdag 22 januari 2026 @ 19:38:
Ik gebruik al meer dan een jaar ikea lampen via Zigbee2MQTT. Het toevoegen ging toen super makkelijk.

Ik heb nog 3 ongebruikte over, maar het toevoegen lukt niet met de huidige versie 2.7.2-1. Deze versie heeft ook de nieuwe layout. Ik heb de lampen ook al meerdere keren gereset. En als in op de "Join toestaan" knop klik in Zigbee2MQTT dan zie ik verder niks gebeuren. Ook het aantal apparaten blijft gelijk. De lamp staat 50cm van de ontvanger.

Doe ik iets verkeerd?

Mogelijk heb je er wat aan om eens te zien of het ontvangst goed is?

Pairing van mesh nodes (apparaten die op het lichtnet aangesloten zijn) doe je overigens eigenlijk altijd op de plek waar die permanent zou moeten komen te hangen, anders probeert die gebruik te maken van de verkeerde mesh node, waardoor het ontvangst slecht zal worden. Vervolgens de lamp 10x uit en aan schakelen (let op de timing: 1 sec uit, 1 sec aan, etc…), de lamp zal dan langzaam dimmen en lichter worden, waarna je ‘m kan toevoegen met de ZHA “add device” -wizard. Hij moet sneller dimmen en lichter worden wanneer die succesvol toegevoegd is.

[ Voor 3% gewijzigd door InjecTioN op 22-01-2026 20:23 ]

[Deshmir]

@DAX23E en tel je 6x vanaf aan stand of vanaf uit stand?

Vanaf uit is het 3x aan, 3x uit en dan weer aan (eigenlijk 7).

Vanaf aan is het 3x uit en 3x aan, eindstand lamp blijft eigenlijk “aan”

[JBS]

Eärendil schreef op donderdag 22 januari 2026 @ 12:52:
Heb je ook de methode geprobeerd die voor BILRESA beschreven is:

[...]

https://www.zigbee2mqtt.io/devices/E2490.html

Nee, dat lukt (mij) (nog) niet. Het hangt hier ook vol met Zigbee lampen, en na de eerste keer 4x drukken begint vrijwel direct één van die Zigbee lampen te knipperen omdat de MYGGBETT via touchlink wil koppelen.

Zo heeft die MYGGBETT vanmiddag zonder dat ik 't door had (want het was licht overdag) bij elke poging een Zigbee lamp uit m'n Zigbee mesh getrokken (5 stuks zo zag ik later).

[DAX23E]

Septillion schreef op donderdag 22 januari 2026 @ 20:13:
@DAX23E Als je op "Permit join" drukt, verandert hij dan in "Disable join x:xx" waarbij x:xx aftelt?

Dan krijg ik de tekst "Jion uitschakelen" met een timer die afloopt.

InjecTioN schreef op donderdag 22 januari 2026 @ 20:22:
[...]

Mogelijk heb je er wat aan om eens te zien of het ontvangst goed is?

Pairing van mesh nodes (apparaten die op het lichtnet aangesloten zijn) doe je overigens eigenlijk altijd op de plek waar die permanent zou moeten komen te hangen, anders probeert die gebruik te maken van de verkeerde mesh node, waardoor het ontvangst slecht zal worden. Vervolgens de lamp 10x uit en aan schakelen (let op de timing: 1 sec uit, 1 sec aan, etc…), de lamp zal dan langzaam dimmen en lichter worden, waarna je ‘m kan toevoegen met de ZHA “add device” -wizard. Hij moet sneller dimmen en lichter worden wanneer die succesvol toegevoegd is.

De ontvangt van de andere lampen en apparaten zijn gewoon goed. Ik wil de lamp nu tijdelijk toevoegen om iets anders te kunnen testen en wil daarvoor mijn huidige lampen niet gebruiken.

In heb de lamp meerdere keren gerest zoals het zou moeten. Soms zelf vaker aan en uit. De lamp laat ik aan het einde dan aan en dan begint de lamp te knipperen. Maar na een tijdje stop dat knipperen.

Bewerkt: 23-01-2026
Vandaag weer bezig geweest door een schakelaar te ontkoppelen en die kon ik wel weer toevoegen.

Ik heb dus even goed naar de lamp gekeken en zag LSC. Blijkbaar ben ik zo stom geweest om deze oude wifi lampen in het IKEA doosje te doen .

[ Voor 8% gewijzigd door DAX23E op 23-01-2026 17:04 ]

[jimmydwn]

Beste Tweakers,

Ik heb een vraag over de ROBB Dimmer voor Aan-Uit Schakelaar:
https://www.robbshop.nl/r...r-voor-aan-uit-schakelaar

Het probleem wat ik heb is dat als ik de dimmer module schakel via Home Assistant het prima werkt, alleen zodra ik mijn traditionele schakelaar gebruik schakelt de lamp wel, maar krijg ik geen terugkoppeling in home assistant. Dus als de lamp van uit naar aan gaat blijft hij in home assistant uit staan en andersom. Ik heb inmiddels 2 modules aangesloten die beide hetzelfde gedrag vertonen.

Het is me wel opgevallen dat in Zigbee2Mqtt de ROB_200-011-1 herkend wordt terwijl het apparaat zelf de ROB_200-004-1 is. Maar dat zou naar mijn idee geen verschil moeten maken voor de state.

Mijn hoop is dat er hier misschien iemand is die dezelfde dimmers gebruikt en mij kan vertellen of het uitlezen van de state gewoon niet mogelijk is bij fysiek schakelen, ik toch nog iets moet aanpassen in de z2m config of dat de modules een defect hebben.

Aansluiting is volgens het volgende schema:


Ik zit op Zigbee2Mqtt versie 2.7.2-1.

Alvast bedankt.

Edit:
Oplossing gekregen op mijn reddit post. Tip om de min. interval op 0 ter zetten.

You need to activate state reporting.
Go to Z2M -> ROB device -> Reporting
Add genOnOff -> onOff and genLevelCtrl -> currentLevel.

Some more information here:
https://www.reddit.com/r/.../1q6g7b4/comment/ny7b9b8/

I will try to update Z2M, so reporting will be enabled by default for your device in the next release

[ Voor 15% gewijzigd door jimmydwn op 27-01-2026 12:43 . Reden: Oplossing toegevoegd ]

[Septillion]

@jimmydwn Even schopje hierheen gedaan want lijkt me meer een Z2M issue.

Ik heb geen ervaring met die Robb module maar het is niet standaard gedrag. Zit je op de laatste versie van Z2M (2.7.2)?

En in de Z2M interface zie je hem ook niet wijzigen?

[jimmydwn]

Septillion schreef op maandag 26 januari 2026 @ 10:25:
@jimmydwn Even schopje hierheen gedaan want lijkt me meer een Z2M issue.

Ik heb geen ervaring met die Robb module maar het is niet standaard gedrag. Zit je op de laatste versie van Z2M (2.7.2)?

En in de Z2M interface zie je hem ook niet wijzigen?

Ik zit op versie 2.7.2-1 en ik zie de state niet wijzigen in het device onder het tabje "Status". Ook in het "Activiteiten" menu blijft de state op "Off". Ik krijg wel een nieuwe message binnen als ik hem inschakel, maar dat komt waarschijnlijk omdat de Power geüpdatet wordt. Deze werkt namelijk wel.

[HuismAndré]

jimmydwn schreef op maandag 26 januari 2026 @ 10:39:
[...]


Ik zit op versie 2.7.2-1 en ik zie de state niet wijzigen in het device onder het tabje "Status". Ook in het "Activiteiten" menu blijft de state op "Off". Ik krijg wel een nieuwe message binnen als ik hem inschakel, maar dat komt waarschijnlijk omdat de Power geüpdatet wordt. Deze werkt namelijk wel.

Bij sommige devices moet je de optie "state action" even aanzetten zodat een statusverandering veroorzaakt op het device zelf terug gemeld wordt. Staat in Z2M op tabblad "instellingen (specifiek)".

[ Voor 9% gewijzigd door HuismAndré op 26-01-2026 12:48 . Reden: Beter plaatje. ]

[jimmydwn]

HuismAndré schreef op maandag 26 januari 2026 @ 12:47:
[...]

Bij sommige devices moet je de optie "state action" even aanzetten zodat een statusverandering veroorzaakt op het device zelf terug gemeld wordt. Staat in Z2M op tabblad "instellingen (specifiek)".

[Afbeelding]

Bedankt voor de tip, helaas heb ik deze al aan staan. Dus dat kan het niet zijn.

[kroonen]

Opgelost. Toen ik spefifiek een kleur koos, ging hij wel updaten van de brightness.


Hoi ,

Ik heb een Philips (Hue outdoor Impress wall lamp). In de zigbee2mqtt wordt hij netjes gemeld en ook de brightness gaat goed, en onthoud deze.

In homeassinstant kom hij ook netjes, ik kan de brightness wijzigen en doet hij ook maar hij bewaart hem niet. in de statussen (in onwikkelhulpmiddelen, daar de attiuburen bljift hij op null staan). Het lijkt net of zigbee2mqtt de brightness niet doorgeeft aan homeassistant.

Enig idee wat hier fout gaat? Of moet ik nog ergens een vinkje zetten. Ik heb hem ook al een keer verwijdert en opnieuw gekoppeld

met mqtt explorer kriijg ik gewoon de waarde

{"brightness":99,"effect":null,"linkquality":142,"power_on_behavior":"off","state":"ON","update":{"installed_version":16786692,"latest_version":16787202,"progress":0.51,"remaining":97194,"state":"updating"}}


in ontwikkelhulpmiddelen heb ik deze waarde

code:

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6666
min_mireds: 150
max_mireds: 500
effect_list:
  - blink
  - breathe
  - okay
  - channel_change
  - candle
  - fireplace
  - colorloop
  - finish_effect
  - stop_effect
  - stop_hue_effect
supported_color_modes:
  - color_temp
  - xy
friendly_name: Bijkeuken Buiten
supported_features: 44
effect: null
color_mode: unknown
brightness: null
color_temp_kelvin: null
color_temp: null
hs_color: null
rgb_color: null
xy_color: null

[ Voor 46% gewijzigd door kroonen op 28-01-2026 18:28 ]

[badkuip]

@rogervdh Ben je al achter de oorzaak van je chrashende Z2M gekomen? Bij mij draaide het ook jaren stabiel maar deze week heb ik al twee keer moeten herstarten.
Gelukkig hoefde ik niets te restoren en werkte het gewoon weer. Ook heb ik een usb Zigbee coordinator en volgens mij heb jij er een via ethernet.

Ik had het zelf gerelateerd aan dit probleem maar dat is niet helemaal aan de orde. Het enige andere wat ik kan bedenken is de update naar HA OS 17.0.

Mijn logs zeggen mij niets. Het staat vol met debug info en ik heb geen log meer van de vastloper. Maar misschien kijk ik verkeerd. Welk log moet ik raadplegen?
Ik draai het op Proxmox in HA OS supervised. ZIgbee2MQTT is een Add on in mijn home assistant.

[HuismAndré]

badkuip schreef op donderdag 29 januari 2026 @ 19:59:
@rogervdh Ben je al achter de oorzaak van je chrashende Z2M gekomen? Bij mij draaide het ook jaren stabiel maar deze week heb ik al twee keer moeten herstarten.
Gelukkig hoefde ik niets te restoren en werkte het gewoon weer. Ook heb ik een usb Zigbee coordinator en volgens mij heb jij er een via ethernet.

Ik had het zelf gerelateerd aan dit probleem maar dat is niet helemaal aan de orde. Het enige andere wat ik kan bedenken is de update naar HA OS 17.0.

Mijn logs zeggen mij niets. Het staat vol met debug info en ik heb geen log meer van de vastloper. Maar misschien kijk ik verkeerd. Welk log moet ik raadplegen?
Ik draai het op Proxmox in HA OS supervised. ZIgbee2MQTT is een Add on in mijn home assistant.

Als je log vol staat met debug info dan heb je log level verkeerd staan tenzij je daadwerkelijk aan het debuggen bent. Ben je dat niet dan dient het level op warning of error te staan (anders loopt de boel best snel vast).

[rogervdh]

badkuip schreef op donderdag 29 januari 2026 @ 19:59:
@rogervdh Ben je al achter de oorzaak van je chrashende Z2M gekomen? Bij mij draaide het ook jaren stabiel maar deze week heb ik al twee keer moeten herstarten.

@badkuip Nee, ik ben er niet achter gekomen. Op de een of andere manier kon Z2M geen verbinding meer krijgen met de ethernet Zigbee coordinator. Vervolgens echt vanalles geprobeerd om het weer werkend te krijgen, maar zonder resultaat. Restore gedaan en voila...het werkte direct weer. Bizar en irritant dat ik de oorzaak nooit heb kunnen achterhalen. Sindsdien draait het gewoon weer stabiel aan een stuk. Inmiddels overigens HAOS 17.0 draaien.

Ik had het zelf gerelateerd aan dit probleem maar dat is niet helemaal aan de orde. Het enige andere wat ik kan bedenken is de update naar HA OS 17.0.

Lijkt erop dat gebruiker empierrelouis in bovenstaande link exact hetzelfde probleem had als ik. Exact zelfde foutmelding, hardware, etc. full restore was de enige oplossing om het weer werkend te krijgen en sindsdien werkt het weer.

[ Voor 26% gewijzigd door rogervdh op 29-01-2026 22:13 ]

[sapphire]

Hier sinds vanavond wat vage problemen met Z2M, tenminste dat of mijn ZBMINI-L2 is gaar.

Vanavond opeens licht niet meer aan via de wandschakelaar, en via de HA app/Z2M reageerde de ZBMINI-L2 ook niet meer. Nagekeken of alles nog goed zat, voelde niet warm aan, geen brandplekken oid dus dat kan het niet zijn. Module geforceerd verwijderd, weer toegevoegd maar nu staat er een rood uitroepteken bij interview status 'failed'. Hij is gewoon te bedienen via Z2M/HA

Voor het verwijderen kreeg ik de volgende error:


Wat ik zo snel heb kunnen vinden is een verouderde firmware maar dit is de nieuwste versie en de overige modules hebben dezelfde versie en werken prima

[ Voor 68% gewijzigd door sapphire op 04-02-2026 23:55 ]

[HuismAndré]

Als bedienen met de wandschakelaar niet meer werkt dan zou je denken dat er een hardware issue is met je ZBMINIL2. Hij kan immers niet in detached mode werken (zoals z'n ZBMINIR2 broertje dat kan) zodat hij altijd zal moeten reageren op de schakelaar (kan hooguit per ongeluk in edge mode terecht komen ipv high/low maar zelfs dan moet hij reageren op een aangesloten schakelaar).

Geforceerd verwijderen is nooit een goed idee. Altijd eerst proberen het device op de nette manier te verwijderen (ook omdat het device dan tenminste netjes een zelfreset uitvoert). Nu kun je nog overwegen om dat zelf te doen. Knop op de ZBMINIL2 een seconde of 10 ingedrukt houden. Als hij ingebouwd zit dan kun je het ook met de aangesloten aan/uit schakelaar doen (keer of 10 heen en weer in een vrij vlot tempo). Licht knippert even als het gelukt is (IIRC). Daarna is hij gereset zou zou de coördinator hem weer moeten kunnen vinden.

[Ben.Hahlen]

Misschien heeft iemand hier dit al een keer meegemaakt, maar deze is nieuw voor mij:
Ik heb een "Tradfri Starterset" gekocht (3 lampen + afstandsbediening), maar ik krijg de lampen met geen mogelijkheid gekoppeld in Z2M.
Het gaat om LED2106R3 GU10's, die "gewoon" supported zouden moeten zijn.

Normaliter zouden ze zelfs moeten verbinden als ze niet supported zijn, maar ook dat doen ze niet...
Alle 3 overigens niet.
Heb ook nog met een Hue Bridge geprobeerd (even afgestoft en aangesloten), maar ook daar joinen ze niet.

Heb er ook een issue voor aangemaakt, maar wilde het ook hier proberen.

[Cyberpope]

Sinds een paar weken heb ik dat mijn ikea afstandbedieningen (strybar en rotred heten ze geloof ik) de verbinding verliezen met de coordinator. Ik heb toch genoeg routers. Iemand een begin waar ik moet gaan zoeken. IA komt vooral dat ik mijn kanaal naar 20 moet zetten, terwijl ze eerst het advies hadden om mijn zigbee kanaal op 25 te zetten.

[Gizz]

@Ben.Hahlen waarschijnlijk is je timing niet goed bij de factory reset. Die luistert heel nauw bij IKEA. Zie ook de uitleg bij deze lampjes in de database van Z2M:

Pairing

Factory reset the light bulb (video). After resetting the bulb will automatically connect.

While pairing, keep the bulb close to the coordinator (adapter).

What works is to use (very) short “on’s” and a little bit longer “off’s”, where you kill the light as soon as the bulb shows signs of turning on. Start with bulb on, then off, and then 6 “on’s”, wait in the 6th ON state. (If you try play safe and go for 7 "on's" the reset sometimes fails.)

[ Voor 5% gewijzigd door Gizz op 06-02-2026 12:39 ]

[Ben.Hahlen]

Gizz schreef op vrijdag 6 februari 2026 @ 12:38:
@Ben.Hahlen waarschijnlijk is je timing niet goed bij de factory reset. Die luistert heel nauw bij IKEA. Zie ook de uitleg bij deze lampjes in de database van Z2M:
[...]

Ok... 6 times is the charm
Blijkbaar deed ik steeds 7 keer, omdat ik niet kan lezen, ofzo...
Nu dus wel gelukt!
Dank!

[belly89]

Ben.Hahlen schreef op vrijdag 6 februari 2026 @ 12:55:
[...]



Ok... 6 times is the charm
Blijkbaar deed ik steeds 7 keer, omdat ik niet kan lezen, ofzo...
Nu dus wel gelukt!
Dank!

Voor een volgende keer, dit script helpt mij altijd uit de brand.
https://gathering.tweaker...message/76068562#76068562

Alle credits uiteraard voor @TheFes

[Hmmbob]

belly89 schreef op vrijdag 6 februari 2026 @ 14:38:
[...]


Voor een volgende keer, dit script helpt mij altijd uit de brand.
https://gathering.tweaker...message/76068562#76068562

Alle credits uiteraard voor @TheFes

Nieuwe locatie van die code:

https://github.com/TheFes/HA-configuration/blob/main/packages/00%20general/ikea_pairing.yaml

[Ben.Hahlen]

belly89 schreef op vrijdag 6 februari 2026 @ 14:38:
[...]


Voor een volgende keer, dit script helpt mij altijd uit de brand.
https://gathering.tweaker...message/76068562#76068562

Alle credits uiteraard voor @TheFes

Dat werkt uiteraard alleen als je slimme schakelaars hebt ook, dat heb ik niet :-)

Wel een cool script, overigens!

[oltk]

rogervdh schreef op donderdag 29 januari 2026 @ 22:06:
[...]


@badkuip Nee, ik ben er niet achter gekomen. Op de een of andere manier kon Z2M geen verbinding meer krijgen met de ethernet Zigbee coordinator. Vervolgens echt vanalles geprobeerd om het weer werkend te krijgen, maar zonder resultaat. Restore gedaan en voila...het werkte direct weer. Bizar en irritant dat ik de oorzaak nooit heb kunnen achterhalen. Sindsdien draait het gewoon weer stabiel aan een stuk. Inmiddels overigens HAOS 17.0 draaien.


[...]


Lijkt erop dat gebruiker empierrelouis in bovenstaande link exact hetzelfde probleem had als ik. Exact zelfde foutmelding, hardware, etc. full restore was de enige oplossing om het weer werkend te krijgen en sindsdien werkt het weer.

Ik had zo een maandje geleden hetzelfde. Ineens werd mjn sonoff-P stick niet meer gevonden. Erin en eruit: bij hardware info in HA geen Sonoff. Uiteindelijk de USB hub (van de Hema) eruit gehaald en vervangen door een andere USB hub, en het werkte weer. Geen idee wat er aan de hand was.

[HowsMyApple]

Sinds een week of 2 valt een Aqara Motion Sensor met regelmaat weg uit m'n netwerk. In Zigbee2MQTT staat dat de device nog wel online is, maar het is nergens meer mee verbonden in het mesh netwerk. Opnieuw pairen en dan doet ie het weer voor een paar uur.
Ik heb deze motion sensor al ruim 5 jaar in gebruik en het heeft altijd zonder problemen gedraaid. Je zou denken dan is de batterij vast aan vervanging toe, maar ook met een nieuwe batterij blijft het probleem zich voordoen. De motion sensor staat op een meter of 3 van m'n Coordinator. En er is onlangs niets gewijzigd aan m'n mesh netwerk.

Iemand een idee wat er aan de hand kan zijn?

[Gizz]

HowsMyApple schreef op maandag 16 februari 2026 @ 08:30:
Sinds een week of 2 valt een Aqara Motion Sensor met regelmaat weg uit m'n netwerk. In Zigbee2MQTT staat dat de device nog wel online is, maar het is nergens meer mee verbonden in het mesh netwerk. Opnieuw pairen en dan doet ie het weer voor een paar uur.
Ik heb deze motion sensor al ruim 5 jaar in gebruik en het heeft altijd zonder problemen gedraaid. Je zou denken dan is de batterij vast aan vervanging toe, maar ook met een nieuwe batterij blijft het probleem zich voordoen. De motion sensor staat op een meter of 3 van m'n Coordinator. En er is onlangs niets gewijzigd aan m'n mesh netwerk.

Iemand een idee wat er aan de hand kan zijn?

(ik reageer hier even op je, want dit heeft met Z2M te maken en niet HA )
Kijk even met welke router je verbindt, de Aqara houdt zich niet helemaal netjes aan de zigbee-standaard en heeft daarom ruzie met bijvoorbeeld routers van Lidl en nog wat andere merken.

Zie ook de uitleg in de documentatie:

Troubleshooting: device stops sending messages/disconnects from network

Since Xiaomi devices do not fully comply to the Zigbee standard, it sometimes happens that they disconnect from the network. Most of the times this happens because of the following reasons:

Device has a weak signal, you can see the signal quality in the published messages as linkquality. A linkquality < 20 is considered weak.
Low battery voltage, this can even happen when the battery still appears full. Try a different battery.
The device is connected through a router which cannot deal with Xiaomi devices. This is known to happen devices from: Centralite, General Electric, Iris, Ledvance, Legrand, OSRAM, Sylvania, SmartThings, Securifi. A possible solution is to connect the device directly to the central coordinator by pushing the reset button while being physically close to it

Dit kun je oplossen door niet Permit join All te kiezen, maar een specifieke router te selecteren.

edit: nu ik toch aan het posten ben, ik heb zelf ook ruzie met een Aqara RTCGQ11LM. Ik krijg deze niet meer gereset of aan het pairen.

Gedrag:

• 1x klikken op de resetknop = blauwe led knippert, 2 seconden wachten, blauwe led knippert weer
• Resetknop ingedrukt houden voor 5, 10, 15 seconden of nog langer: er gebeurt niks, geen blauwe led.

Terwijl dat laatste de procedure zou moeten zijn voor een reset en het activeren van de pairmodus.

Geprobeerd met verse batterijtjes van 2 verschillende merken/batches. Wat nu?

[ Voor 11% gewijzigd door Gizz op 16-02-2026 08:39 ]

[HowsMyApple]

@Gizz Ah dat van die Permit join All wist ik niet, nooit bij stil gestaan eigenlijk

Maar de motion sensor heeft altijd een directe verbinding met de coordinator gehad, welke dus op zo'n 3 meter afstand staat. De sensor is m'n meest betrouwbare zigbee device tot nu toe geweest. Er is niets veranderd, geen idee waarom 'ie nu telkens na een paar uur 'niet meer werkt' ..

Ik zie nu je edit. Weet jij toevallig vanaf welke dag exact jouw problemen spelen? Ik helaas niet, maar wellicht kunnen we dan opzoeken of er rond die dag een update is geweest voor Z2MQTT waar die motion sensors niet heel blij mee zijn.

[ Voor 24% gewijzigd door HowsMyApple op 16-02-2026 09:00 ]

[Septillion]

@HowsMyApple Detail dat ik mis, werkt hij ook werkelijk niet?

Want Zigbee kent geen echte manier om "offline" te detecteren, dan kan alleen door reactie te timen. En dat staat standaard uit in Z2M. En dat van een batterij device tijdens een scan niet duidelijk is met wel device hij verbonden is wil ook nog niets zeggen.

[HowsMyApple]

@Septillion Ja de sensor werkt nog wel. Zodra ik 'm opnieuw pair wordt ie gelijk gevonden en springen de lichten in de keuken direct aan (oftewel, de sensor ziet dat er iemand in de keuken is en de juiste automation wordt afgetrapt)

[Septillion]

@HowsMyApple Nee, niet na re-pairen. Geen streepje op het kaartje of offline melding zijn beide maar symptomen. Maar werkt de sensor dan werkelijk dan ook niet meer?

[HowsMyApple]

@Septillion
Precies andersom: volgens Z2MQTT is er niets aan de hand met de sensor. Status in het Devices overzicht is dan nog steeds online. DE LQI was +- 150.
Maar in werkelijkheid komt er niets meer binnen in de logs. Niet wanneer er iemand de keuken in loopt maar ook geen tussentijdse status updates (voor zover batterypowered devices dat doen?).

Overigens vermoed ik inderdaad toch dat het met de route te maken heeft (gehad). De sensor hangt nu alweer +- 20 uur in m'n netwerk zonder weg te vallen. En vermoedelijk juist omdat deze nu niet meer direct met m'n coordinator is verbonden maar via een Zigbee wanddimmer (die verder weg zit dan de coordinator..)

Kortom: Na een reboot van HASS heeft de sensor bedacht een andere route dan de 5 jaar ervoor te nemen. Dat was niet stabiel. Na meerdere malen opnieuw pairen koos de sensor weer een andere route en sindsdien draait dat weer stabiel.

Bedankt voor het meedenken @Septillion en @Gizz

[Ben(V)]

Het probleem met aqara devices is dat ze altijd alleen maar verbinden met het device waar ze mee gepaired zijn en nooit meer met een ander device willen verbinden (slechte Zigbee implementatie).

Als er dan tijden het pairen een device is zoals bijvoorbeeld de coordinator die relatief veel signaal uitstuurt loopt je de kans dat hij daar mee paired, terwijl hij zelf niet zoveel signal heeft en die coordinator eigenlijk slecht kan bereiken.

Als je tegen dit probleem aanloopt kun je proberen geforceerd te pairen via een bepaalt device waar hij wel mee kan verbinden of die coordinator even afschermen tijden het pairen.

[Septillion]

@HowsMyApple Dat detail miste dus even en probeerde ik duidelijk te krijgen. Gezien ik ook wel eens gezien heb dat men een "verbindingsprobleem" probeerde op te lossen terwijl hij alleen soms als offlinf of zonder lijntje op de kaart stond maar wel gewoon nog werkte. Dan ben je dus achter een spook aan het gaan. Maar als hij werkelijk niets doorgeeft heb je een probleem ja.

Welke coördinator heb je? En welke firmware?

[manusjevanalles]

Ik probeer https://www.ikea.com/nl/n...-globe-opaalwit-10611302/ te koppelen in z2m (laatste versie). Als ik met reset (6x aan/uit) en vervolgens 12x aan/uit zet dan paired hij wel (en wordt ook herkend met de juiste naam), en gedurende een seconde of 10 kan ik hem bedienen. Vervolgens valt hij weer uit het netwerk. Dit gebeurt elke keer. Iemand die dit herkent en een oplossing weet?

[ Voor 4% gewijzigd door manusjevanalles op 21-02-2026 09:58 ]

[PCan]

Valt mij op dat in de Zigbee to mqqt configuratie.yaml onder serial niet meer het zinnetje
adapter: ember
staat.
Vraag 1: Hoeft dat niet meer?
Ik ben er een tijd uit geweest, dus excusses als er iets veranderd is.

Mijn geflashte Sonoff zigbee dongle E werkt volgens mij normaal en ondersteund ook Matter in HA.
Dat is het probleem niet.
Alleen lukt het mij niet om zowel via de Zigbee Bridge-Pro in Ewelink én de Dongle E in HA tegelijk verbinding te maken met de Sonoff Air Quality Monitor (matter). Waarschijnlijk omdat de Pro geen matter ondersteund. Wat er gebeurd is dat ik wel de sensor kan toevoegen in Ewelink, maar dan krijgt hij geen contact meer via mijn WiFi thuisnetwerk Router. Doe ik andersom de sensor eerst in HA en daarna in Ewelink, dan werkt hij niet meer in HA. alle waardes staan dan op onbereikbaar.
Verwijder ik alle apparaten in HA en Ewelink en doe ik een schone toevoeging in HA dan werkt de sensor prima via de Matter server in HA.
Alleen in de Ewelink App is de grafische interface wat mooier.

Vraag 2: Kan ik dit oplossen door een Dongle Max (€44,-), een Dongle Plus MG24 €34,- of een Zigbee Bridge Ultra (€72,-) te kopen? De Dongels zijn ember adapters. De Ultra is vergelijkbaar met de Pro, maar dan met thread (matter). De max heeft een ethernet kabel PoE aansluiting en web interface.
Of blijft ook daarnee het probleem bestaan?

[Gizz]

Volgens mij ben je wat zaken door elkaar aan het halen @PCan

PCan schreef op maandag 2 maart 2026 @ 12:37:
Valt mij op dat in de Zigbee to mqqt configuratie.yaml onder serial niet meer het zinnetje
adapter: ember
staat.
Vraag 1: Hoeft dat niet meer?

Daar moet iets van een adapter-type staan. Of dat ember moet zijn hangt van je adapter af.

Mijn geflashte Sonoff zigbee dongle E werkt volgens mij normaal en ondersteund ook Matter in HA.

Wat bedoel je met dat je dongle Matter ondersteund? Dongles spreken geen matter, maar een radioprotocol zoals zigbee, thread of z-wave.

Er zijn een paar opties bij je Sonoff dongle:

• Er staat zigbee-firmware op je stick: hij ondersteunt alleen zigbee
• Er staat thread-firmware op je stick: hij ondersteunt alleen thread
• Er staat combi-firmware op je stick: hij ondersteunt zigbee en thread. Deze optie wordt eigenlijk overal afgeraden omdat het niet goed werkt.

Thread is het radioprotocol. Als je een dongle met Thread-firmware hebt kun je zorgen dat Thread-apparaten met je Home Assistant kunnen praten, in Home Assistant zit dan het stukje waardoor Matter werkt.

Alleen lukt het mij niet om zowel via de Zigbee Bridge-Pro in Ewelink én de Dongle E in HA tegelijk verbinding te maken met de Sonoff Air Quality Monitor (matter).

Gaat het om dit ding? Dat is een apparaat op basis van wifi en heeft dus helemaal niks te maken met je Sonoff dongle. Die Air Quality Monitor moet gewoon verbinden met je eigen wifi-netwerk en zal dan ook in Home Assistant werken, via de Matter integration.

Vraag 2: Kan ik dit oplossen door een Dongle Max (€44,-), een Dongle Plus MG24 €34,- of een Zigbee Bridge Ultra (€72,-) te kopen? De Dongels zijn ember adapters. De Ultra is vergelijkbaar met de Pro, maar dan met thread (matter). De max heeft een ethernet kabel PoE aansluiting en web interface.
Of blijft ook daarnee het probleem bestaan?

Je kan er tig dongles tegenaan gooien, maar dat gaat je dus niet helpen met een wifi-apparaat. Net als dat je mobiel en laptop wifi hebben en ook niet verbinden met je zigbee/thread-dongle

[ Voor 4% gewijzigd door Gizz op 02-03-2026 15:58 ]

[deepbass909]

Ben(V) schreef op dinsdag 17 februari 2026 @ 09:53:
Het probleem met aqara devices is dat ze altijd alleen maar verbinden met het device waar ze mee gepaired zijn en nooit meer met een ander device willen verbinden (slechte Zigbee implementatie).

Als er dan tijden het pairen een device is zoals bijvoorbeeld de coordinator die relatief veel signaal uitstuurt loopt je de kans dat hij daar mee paired, terwijl hij zelf niet zoveel signal heeft en die coordinator eigenlijk slecht kan bereiken.

Als je tegen dit probleem aanloopt kun je proberen geforceerd te pairen via een bepaalt device waar hij wel mee kan verbinden of die coordinator even afschermen tijden het pairen.

Goed om te weten, ik heb een aqara schakelaar die regelmatig verbinding verliest. Ik moet even kijken met welke router hij verbinding maakt, of wellicht direct met de controller, die op nog geen meter daar vandaan hangt.

[PCan]

In 3 van de 4 dongles zit een chip die thread ondersteund. Zonder Thread geen Matter.
Wel zie ik in alle 4 Thread RCP firmware support. Ik vermoed echter dat de Z-stack SIP in de Pro roet in het eten gooit.
Ik heb inmiddels de Max besteld en verwacht dat het daarmee beter zal gaan.

[Gizz]

@PCan heb je ook maar iets van mijn post gelezen?

Zonder Thread kun je prima met Matter werken. Die SONOFF AirGuard PM2.5/PM10 Matter Over Wi-Fi Air Quality Monitor werkt via wifi.. Dat hij wel kan verbinden met je Zigbee Bridge-Pro is logisch, want die is ook een wifi-accesspoint. Daarom loop je ook tegen het probleem aan dat als die Air Quality Monitor via wifi met de Zigbee Bridge-Pro verbindt hij niet meer te verbinden is met je eigen wifi-netwerk.

Lees ook even de link door van de Matter Integration die ik al eerder met je deelde. Daarin staat wat meer uitleg over Matter en waarom je prima Matter kunt hebben zonder Thread:

Unlike other common radio-based protocols for IoT, (like Zigbee, Z-Wave, and Bluetooth), the Matter standard specification itself does not contain its own proprietary radio protocol or network transport protocol, but instead, it is a service control protocol that runs on top of the existing network infrastructure at the application level, with all Matter devices communicating using standard IP-based (IPv6) communication over your existing local area network (i.e. LAN networks like Wi-Fi and Ethernet)
or Thread (Low-Power Wireless Personal Area Network) depending on the type of device.

Je koopt nu spullen die je niet nodig hebt, waar ik je al voor waarschuwde. Je vraagt advies en je doet het tegenovergestelde?

Om je wifi(!) Sonoff air quality geval in Home Assistant te krijgen doe je het volgende:

1. Installeer de Matter Integration in HA
2. Ga met je telefoon naar je Sonoff Air Quality Monitor en doe dit (Android) of dit (iPhone).
3. Klaar

[Septillion]

@PCan Matter is alleen een top level protocol, het heeft nog een (IP based) netwerk nodig om over te werken. Vandaar dat gewoon spreken over "het doet Matter" eigenlijk dus incompleet is. Het is dus Matter over Thread, matter over Wifi, Matter over Ethernet, Matter over Mijn eigen netwerkprotocol etc. Vandaar dat ik het dus zo BS vind dat Ikea nu alleen "Matter" op de verpakking heeft staan.

En voor de MQTT config, daar hoort inderdaad het adapter type te staan. Maar wel alleen in de echte configuration.yaml van Z2M. De addon app config mag tegenwoordig eigenlijk gewoon leeg zijn en doet Z2M zelf onboarding waarbij de configuration.yaml gemaakt wordt.

[PCan]

@Septillion @Gizz
Bedankt voor de hulp.
Ik heb gewoon teveel aan mijn hoofd de laatste tijd. Waardoor ik soms door de bomen het bos niet meer zie.
In HA doet doen de sensoren het gewoon. Ik vond alleen de interface van Ewelink mooi, dus hoopte dat het allebei kon. Veel van mijn automatiseringen lopen via Ewelink, maar ik wordt langzaam steeds beter in HA.
Ik heb wel vaak last van uitval in HA, dan wordt e.e.a. niet ververst of is niet meer bereikbaar.
Ook de nieuwe CO2 sensor was er gisteren spontaan mee gestopt. Geen idee waarom. Vanmorgen de USB-C er ff uit en weer in, toen deed hij het weer een tijdje.

In het Yaml bestand heb ik vanmorgen de toevoeging "adapter: Ember" er weer uit gehaald.
Volgens mij is het ook Z-stack of zoiets. (Sonoff dongel E firmware geflashed in 2024), direct in mijn minipc met HA, met verlengkabel)
Gekke is dat hij gisteren toen ik de regel er tussen gezet had, hij alle overige regels daaronder wiste.

Ik ga alle adviezen etc. nog eens goed doornemen en alles op een rijtje zetten.
Kan de Max gewoon terugsturen als ik dat wil.

[Gizz]

PCan schreef op dinsdag 3 maart 2026 @ 15:58:
In HA doet doen de sensoren het gewoon. Ik vond alleen de interface van Ewelink mooi, dus hoopte dat het allebei kon.

Een Matter-apparaat moet met minimaal 5 andere systemen te koppelen zijn. Dus aan HA en Ewelink gekoppeld zijn zou qua hoeveelheid geen probleem moeten zijn.

Waar je misschien tegenaan loopt (ik heb zelf geen Ewelink spullen of die Sonoff Zigbee Bridge Pro) is dat die Ewelink-app alleen apparaten wil laten zien die direct wifi-verbinding maken met die Zigbee Bridge Pro.

Ik denk dat je dit beter verder kan uitzoeken met hulp van anderen in dit topic: Sonoff: goedkope smart modules met wifi (ESP) / Zigbee
Want met zigbee of Z2M heeft jouw probleem niks te maken

edit: nu je apparaat met HA verbonden is via Matter, lukt het je dan echt niet met deze stappen in de documentatie van de Matter Integration om 'm vervolgens ook in Ewelink te krijgen?

1: Go to Settings > Devices & services and on the Matter integration card, select Devices.
2: From the list of devices, select the device you want to share.
3: Select Share device, then in the dialog, select Share device again.
There is no need to press a hardware button on the device to set it to commissioning mode.
4: To join the device to the other platform, in their app, scan the QR code or enter the sharing code.
5: Follow the instructions in their app.

[ Voor 63% gewijzigd door Gizz op 03-03-2026 16:30 ]

[PCan]

@Gizz Heb ik kort geprobeert, die share functie. Dan zegt hij dat je niet iets met jezelf kan delen.
Maar, ik heb nog niet uitgezocht waarom en of ik dat kan omzeilen.

[Gizz]

@PCan de QR-code maak je in de HA-app en scan je met de Ewelink app. Klopt het dat je het zo doet? Waarom je dan de melding krijgt in Ewelink dat je iets met jezelf deelt snap ik niet.

Maar goed, dit wordt misschien iets voor een apart of ander topic

[Septillion]

Had de vraag eerst door laten gaan omdat er zoveel Matter verwarring was, maar nu beter in het HA topic verder.