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 ]