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).