Zigbee2mqtt - open source zigbee bridge - Deel 2

[ahbart]

Ik heb net van mijn "SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P" de firmware geupdate via de docker container. nu versie: "CC1352P2_CC2652P_launchpad_coordinator_20250321.hex" geflashed.
Maar kan ik in Zigbee2Mqtt ergens zien welke versie van firmware er op de Sonoff gebruikt wordt? Dubbelcheck van het flashen zeg maar?

[RobertMe]

ahbart schreef op dinsdag 2 december 2025 @ 12:05:
Ik heb net van mijn "SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P" de firmware geupdate via de docker container. nu versie: "CC1352P2_CC2652P_launchpad_coordinator_20250321.hex" geflashed.
Maar kan ik in Zigbee2Mqtt ergens zien welke versie van firmware er op de Sonoff gebruikt wordt? Dubbelcheck van het flashen zeg maar?

Bij "Instellingen" staat bij mij "Coördinator" met daaronder "ZStack3x0" en "20220219" (ja, ik heb de stick al langer en nooit geupdate ).

[ahbart]

RobertMe schreef op dinsdag 2 december 2025 @ 12:44:
[...]

Bij "Instellingen" staat bij mij "Coördinator" met daaronder "ZStack3x0" en "20220219" (ja, ik heb de stick al langer en nooit geupdate ).

Yes gevonden! Steeds overheen gekeken. Dank! Flash was geslaagd.

Vanwege een error: "ERROR: int() can't convert non-string with explicit base", moest ik overigens wel de specifieke versie :2024-03-19 toevoegen aan de image lijn.

[datadevil]

weet iemand of het normaal is dat Philips 12v spotjes als de stroom er weer op komt weer naar 100% op een bepaalde lichtstand springen die bepaald niet de laatste is waar ze op stonden?

[RobertMe]

datadevil schreef op dinsdag 2 december 2025 @ 13:55:
weet iemand of het normaal is dat Philips 12v spotjes als de stroom er weer op komt weer naar 100% op een bepaalde lichtstand springen die bepaald niet de laatste is waar ze op stonden?

Dat zou heel goed kunnen. Want heel veel slimme lampen doen dat. Zodat in het geval van een storing / ... in bv een "noodsituatie" je wel verlichting hebt.

Mogelijk dat je dit gedrag wel kunt aanpassen (bij mijn gewone Hue spotjes (230V ) kan dat in ieder geval wel).

[HuismAndré]

datadevil schreef op dinsdag 2 december 2025 @ 13:55:
weet iemand of het normaal is dat Philips 12v spotjes als de stroom er weer op komt weer naar 100% op een bepaalde lichtstand springen die bepaald niet de laatste is waar ze op stonden?

De opstartstand kun je zelf instellen. Zie hieronder zoals het er in de webinterface van Z2M uitziet.



Daarnaast is het, als ik me niet vergis, zo dat ongeacht welke opstartstand je kiest, als je de lamp onder spanning zet, deze wegneemt en daarna gelijk weer aanbiedt, de lamp in de 100% stand zal gaan staan.

[ Voor 9% gewijzigd door HuismAndré op 02-12-2025 15:44 ]

[Rouwette]

Grrr ik was bezig met een nieuwe Rodret knop van de ikea, per ongeluk koppelde die aan een lamp, deze lamp werd daardoor uit Zigbee2MQTT gegooid. Nu wilt die lamp (ikea) wel in koppelmodus te komen maar de E-dongel lijkt niets toe te voegen. In de log zie ik niks gebeuren.

[luigi87]

Kan iemand mij mogelijk adviseren voor een Zigbee schakelmodule (achter de fysieke schakelaar) die ook kan binden via Zigbee2mqtt en HA?
Ik heb nu diverse gehad en geprobeerd, maar helaas blijft het binden altijd een issue.

Ik wil graag een groep met Ikea trafdfri spot direct binden met de schakelaar module, ivm met uitval van zigbee2mqtt dat de lampen bedienbaar blijven.

[Esumontere]

luigi87 schreef op maandag 8 december 2025 @ 10:39:
Kan iemand mij mogelijk adviseren voor een Zigbee schakelmodule (achter de fysieke schakelaar) die ook kan binden via Zigbee2mqtt en HA?
Ik heb nu diverse gehad en geprobeerd, maar helaas blijft het binden altijd een issue.

Ik wil graag een groep met Ikea trafdfri spot direct binden met de schakelaar module, ivm met uitval van zigbee2mqtt dat de lampen bedienbaar blijven.

Je kunt in Zigbee2MQTT een willekeurige Zigbee schakelaar (bijvoorbeeld die van Tradfri) direct binden aan een lamp, zonder dat HA daar tussen zit. Hiervoor kun je de bind/unbind functie gebruiken in het menu van de schakelaar. De Tradfri schakelaars gaan echter wel vrijwel instantaan in slaapstand na een knopdruk, dus tijdens het binden kan je het beste een knop ingedrukt houden.

[HuismAndré]

Esumontere schreef op maandag 8 december 2025 @ 10:43:
[...]

Je kunt in Zigbee2MQTT een willekeurige Wifi schakelaar (bijvoorbeeld die van Tradfri) direct binden aan een lamp, zonder dat HA daar tussen zit. Hiervoor kun je de bind/unbind functie gebruiken in het menu van de schakelaar.

Kun je omschrijven hoe je dit doet? Bij mijn weten is wat je omschrijft namelijk compleet onmogelijk (en mocht het niet zo zijn dan hoor ik graag hoe ik mijn Shelly i4 gen3 rechtstreeks bind via Zigbee2MQTT). Binnen Zigbee heeft "binden" namelijk een erg specifieke betekenis (een directe verbinding tussen 2 apparaten die zelfs blijft werken als de coördinator er de brui aan geeft).

https://www.zigbee2mqtt.io/guide/usage/binding.html

[ Voor 17% gewijzigd door HuismAndré op 08-12-2025 10:53 ]

[Esumontere]

HuismAndré schreef op maandag 8 december 2025 @ 10:48:
[...]

Kun je omschrijven hoe je dit doet? Bij mijn weten is wat je omschrijft namelijk compleet onmogelijk (en mocht het niet zo zijn dan hoor ik graag hoe ik mijn Shelly i4 gen3 rechtstreeks bind via Zigbee2MQTT). Binnen Zigbee heeft "binden" namelijk een erg specifieke betekenis (een directe verbinding tussen 2 apparaten die zelfs blijft werken als de coördinator er de brui aan geeft).

https://www.zigbee2mqtt.io/guide/usage/binding.html

Excuus, in mijn post stond 'Wifi schakelaar', dat moest 'Zigbee schakelaar' zijn. Dan kan het dus in de properties van de schakelaar in Z2M onder bind.

[luigi87]

Esumontere schreef op maandag 8 december 2025 @ 10:43:
[...]

Je kunt in Zigbee2MQTT een willekeurige Zigbee schakelaar (bijvoorbeeld die van Tradfri) direct binden aan een lamp, zonder dat HA daar tussen zit. Hiervoor kun je de bind/unbind functie gebruiken in het menu van de schakelaar. De Tradfri schakelaars gaan echter wel vrijwel instantaan in slaapstand na een knopdruk, dus tijdens het binden kan je het beste een knop ingedrukt houden.

Ik heb nu een Aqata t1 zitten en deze support het niet omdat die niet de genOnOff support bij het binden.
Dus kan ik deze niet toevoegen aan een groep.

Niet iedere switch support het binden dus op dezelfde wijze, vandaar mijn vraag.


als voorbeeld de "RODRET wireless dimmer" kan dit wel

[ Voor 17% gewijzigd door luigi87 op 08-12-2025 11:51 ]

[Martin.Air]

Rouwette schreef op maandag 8 december 2025 @ 00:53:
Grrr ik was bezig met een nieuwe Rodret knop van de ikea, per ongeluk koppelde die aan een lamp, deze lamp werd daardoor uit Zigbee2MQTT gegooid. Nu wilt die lamp (ikea) wel in koppelmodus te komen maar de E-dongel lijkt niets toe te voegen. In de log zie ik niks gebeuren.

Staat de oude entry van de lamp nog in Z2M? In dat geval eerst "forceful" verwijderen, daarna zou opnieuw koppelen moeten werken.

[Rouwette]

Martin.Air schreef op maandag 8 december 2025 @ 12:57:
[...]

Staat de oude entry van de lamp nog in Z2M? In dat geval eerst "forceful" verwijderen, daarna zou opnieuw koppelen moeten werken.

Ik zag in de log wat hij de Z2M left. Nu vind ik hem niet in de apparaten lijst.

[Septillion]

Rouwette schreef op maandag 8 december 2025 @ 00:53:
Grrr ik was bezig met een nieuwe Rodret knop van de ikea, per ongeluk koppelde die aan een lamp, deze lamp werd daardoor uit Zigbee2MQTT gegooid. Nu wilt die lamp (ikea) wel in koppelmodus te komen maar de E-dongel lijkt niets toe te voegen. In de log zie ik niks gebeuren.

Misschien eerst de knop aan HA koppelen (of de batterij eruit). Mijn indruk zou dan namelijk zijn dat hij weer aan de knop koppelt.

[JBS]

Knip, verkeerde topic.

[ Voor 94% gewijzigd door JBS op 18-12-2025 14:33 ]

[Biba2000]

Hierbij een melding van het logboek.
Ik zie onderaan bij http://0.0.0.0:8099/ geen IP adres staan??


13:49:16] INFO: Preparing to start...
[13:49:17] INFO: Socat enabled
[13:49:17] INFO: Starting socat
Socat startup parameters:
Options: -d -d
Master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
Slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
[13:49:17] INFO: Starting socat process ...
2025/12/23 13:49:17 socat[46] N PTY is /dev/pts/0
2025/12/23 13:49:17 socat[46] N listening on AF=2 0.0.0.0:8485
[13:49:18] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
Onboarding page is available at http://0.0.0.0:8099/

SChopje naar het grote topic. Graag ook aanvullen met details, dit is te karig.

[ Voor 6% gewijzigd door Septillion op 23-12-2025 14:09 ]

[maubaan]

heb je DHCP aan staan in je netwerk?

[Biba2000]

Nee vast IP adres

[Cyberpope]

Is er een best kanaal om te kiezen. Nu is mijn linkkwaliteit erg laag overal, maar zit op het standaard kanaal 11.

[Beekforel]

Cyberpope schreef op vrijdag 26 december 2025 @ 22:55:
Is er een best kanaal om te kiezen. Nu is mijn linkkwaliteit erg laag overal, maar zit op het standaard kanaal 11.

https://www.zigbee2mqtt.i...ate-minimal-configuration

Er zijn ook wel overzichten van de overlap te vinden.

[Cyberpope]

Beekforel schreef op vrijdag 26 december 2025 @ 23:44:
[...]

https://www.zigbee2mqtt.i...ate-minimal-configuration

Er zijn ook wel overzichten van de overlap te vinden.

Ja, dat kun je overal vinden. Ben al weken aan het lezen. Maar mensen die er echt zeggen dat hun netwerk na een kanaal wissel er hard op vooruit is gegaan ben ik niet tegengekomen. Vandaar mijn vraag. Want als 25 zoveel het beste is (zoals je overal bijna leest) waarom is dat dan niet het standaard kanaal maar is 11 dat? Terwijl 6 bijna overal de standaard is voor Wifi. En laat die 2 elkaar net in de wet zitten.

[JaapB]

Cyberpope schreef op zaterdag 27 december 2025 @ 07:51:
[...]

Ja, dat kun je overal vinden. Ben al weken aan het lezen. Maar mensen die er echt zeggen dat hun netwerk na een kanaal wissel er hard op vooruit is gegaan ben ik niet tegengekomen. Vandaar mijn vraag. Want als 25 zoveel het beste is (zoals je overal bijna leest) waarom is dat dan niet het standaard kanaal maar is 11 dat? Terwijl 6 bijna overal de standaard is voor Wifi. En laat die 2 elkaar net in de wet zitten.

Hier net een wissel van coördinator gedaan en daarbij stond dus in eerste instantie WIFI op kanaal 1 en Zigbee op 11 waarbij ik in het netwerk 8 van de 36 devices met een slechte LQI had, kanaal van Zigbee naar 25 loste dit op.

Nu heb ik het geluk dat er niet veel andere krachtige WIFI netwerken dichtbij zitten dus misschien ook kijken of er in je omgeving mogelijk een ander sterk WIFI netwerk actief is?

[Beekforel]

Cyberpope schreef op zaterdag 27 december 2025 @ 07:51:
[...]

Ja, dat kun je overal vinden. Ben al weken aan het lezen. Maar mensen die er echt zeggen dat hun netwerk na een kanaal wissel er hard op vooruit is gegaan ben ik niet tegengekomen. Vandaar mijn vraag. Want als 25 zoveel het beste is (zoals je overal bijna leest) waarom is dat dan niet het standaard kanaal maar is 11 dat? Terwijl 6 bijna overal de standaard is voor Wifi. En laat die 2 elkaar net in de wet zitten.

Bij mij ging het enorm vooruit na aanpassen. Ik heb zowel mijn wifi, zigbee en openthreas aangepast en op elkaar afgestemd.
Zogbee prestaties gingen weer omlaag nasat ik een extra accesspoint toevoegde, heb toen 1 2,4 AP uitgeschakeld en het was weer in orde.

[andru123]

Ben(V) schreef op vrijdag 31 oktober 2025 @ 17:12:
Als je echt twee stacks wilt gaan gebruiken bijvoorbeeld Zigbee en Thread dan zou ik voor een SLBZ-MR gaan die hebben twee radios en twee aparte stacks die volkomen onafhankelijk van elkaar zijn.

Zie:
https://smlight.tech/manu...-overview/#slzb-06-models

@Cyberpope
De SLZB-06 heeft geen twee radios.

Als ik mijn eerste nieuwe SLZB ga kopen, welke is dan beter?
Ik heb alleen ZigBee- of Wi-Fi-apparaten, maar alle nieuwe apparaten worden geleverd als "threads" of "matter". Is het echt verstandig om een ​​SLZB-06 of toch een MR te kopen? Ik wil de complexiteit en het hogere stroomverbruik van een MR niet, met het oog op “mogelijke toekomstige” thread-ondersteuning.
Of is het beter dan in de toekomst een aparte threads-controller toe te voegen?

[ Voor 18% gewijzigd door andru123 op 01-01-2026 01:09 ]

[Septillion]

@andru123 Zou zeggen, als je nu nog geen Thread wilt doen dan zou ik voor een single radio gaan. Niets mis met twee coördinators straks. Wil je er nu al mee spelen is een dual radio wel interessant.

[Ben(V)]

Ik heb zelf besloten om op Zigbee te blijven en matter over thread te vermijden.
Ik proef dat veel fabrikanten weer proberen een "lock in" te creëren door die thread devices weer niet helemaal compatible te maken, zo werken de nieuwe Ikea devices alleen echt lekker met de Ikea dirigera momenteel.

[RobertMe]

Ben(V) schreef op donderdag 1 januari 2026 @ 10:26:
Ik heb zelf besloten om op Zigbee te blijven en matter over thread te vermijden.
Ik proef dat veel fabrikanten weer proberen een "lock in" te creëren door die thread devices weer niet helemaal compatible te maken, zo werken de nieuwe Ikea devices alleen echt lekker met de Ikea dirigera momenteel.

Rolt dat niet ook gedeeltelijk uit dat simpelweg (nog) niet alles in Matter zit? Het is best lastig om met alle fabrikanten een standaard op te stellen die én universeel is én aan alle vendor specifieke features kan voldoen. Al helemaal als je dus als fabrikant nieuwe features op een apparaat wilt toevoegen, als je dan eerst door het volledige standaardisatie proces heen moet voordat je die feature uit kunt brengen heeft de concurrentie je al links en rechts ingehaald.

Zie bv ook de Aqara FP300 die via Matter veel minder gegevens verstuurd dan over Zigbee. "Want het kan niet met Matter". Waarbij ik twijfel over of alle features wel beschikbaar zijn als je de sensor via Thread koppelt aan de Aqara hub. Ik meen van niet, en dat de features op de Aqara hub ook alleen beschikbaar zijn als je via Zigbee koppelt.

En hopelijk ontstaat er een situatie waarin bv Home Assistant ook weer vendor specifieke zaken kan ondersteunen in Matter. Hetzelfde als dat ZHA en Z2M veel maatwerk bevatten voor fabrikant specifieke zaken. Want volgens mij heeft Matter zelf wel ondersteuning voor fabrikant specifieke toevoegingen.

---

Een veel groter obstakel van (Matter over) Thread vind ik dat het volledig IP based is, incl een verplichting voor Thread Border Routers om internet toegang te verlenen. Naast dat een Thread apparaat dus via IP overal mee zou kunnen babbelen, en niet een afgebakend protocol heeft met een harde scheiding tussen "IoT" en "LAN" (/IP / ...) zou het voor elk Thread apparaat ook nog eens mogelijk moeten zijn om met internet te verbinden. En dat gaat mij veel te ver (en is ook een van de redenen waarom ik wifi mijd). En ja, met een firewall kun je dat vast wel weer blokkeren, maar daarmee heb je een TBR die niet aan de specificatie en dus ook verwachtingen van de fabrikant voldoet. Als je een apparaat koopt weet je niet of dat nu, of in de toekomst, internet toegang vereist. Terwijl het apparaat dus wel altijd de mogelijkheid zou moeten hebben om met internet te verbinden. Dus de fabrikant hoeft helemaal geen rekening te houden met het scenario dat er geen internet is.

[Ben(V)]

Mee eens, thread heeft dezelfde potentiële problemen die je ook met wifi iot devices hebt.
De fabrikanten hebben de neiging (omdat het kan) alles via hun cloud te laten werken en dat is voor mij een no go.
Dat is het mooie van Zigbee, dat is gegarandeerd altijd alleen lokaal.

[banaliteit]

Als we gewoon zigbee devices blijven kopen is er niks aan de hand?

[RobertMe]

banaliteit schreef op donderdag 1 januari 2026 @ 16:08:
Als we gewoon zigbee devices blijven kopen is er niks aan de hand?

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.

[Overspark]

HA is juist de andere kant op gegaan. Die hebben een tijdje hardware verkocht die theoretisch dual stack zou kunnen ondersteunen, maar na een tijdje hebben ze het opgegeven om dat stabiel te krijgen en kan je nu alleen nog maar kiezen voor of ZigBee, of Thread. Als je ze allebei wilt heb je een tweede controller nodig.

[RobertMe]

Overspark schreef op donderdag 1 januari 2026 @ 20:55:
HA is juist de andere kant op gegaan. Die hebben een tijdje hardware verkocht die theoretisch dual stack zou kunnen ondersteunen, maar na een tijdje hebben ze het opgegeven om dat stabiel te krijgen en kan je nu alleen nog maar kiezen voor of ZigBee, of Thread. Als je ze allebei wilt heb je een tweede controller nodig.

Datzelfde geldt voor de "802.15.4" apparaten. Dat Ikea spul bv kan ook alleen maar of met Thread of met Zigbee verbinden, en niet met beide tegelijkertijd. En bv de Aqara FP300 moet een volledig andere firmware op. Het ding wordt geleverd met de Matter over Thread firmware, en tijdens de setup met de Aqara app kun je kiezen om Zigbee te gebruiken, waarna die (via Bluetooth) een totaal andere firmware er op flasht.

"Multi pan" routers / end devices zijn er bij mijn weten dus ook niet. En multi pan coordinators hebben "ze" geprobeerd en werkte niet goed en is dus ook weer vanaf gestapt.

[gastje01]

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

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

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

[DjoeC]

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

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

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

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

[Deshmir]

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

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

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

[RobertMe]

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

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

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

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

[gastje01]

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

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

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

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

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

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

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

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

[DjoeC]

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

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


[...]


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

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

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

[DjoeC]

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

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

[HuismAndré]

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

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

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

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

[Ben(V)]

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

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

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

[DjoeC]

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

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

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

[HuismAndré]

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

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

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

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

[con1]

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

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

[BiG-GuY]

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

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

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

[con1]

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

[Ben(V)]

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

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

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

[RobertMe]

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

Onzin:


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

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

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

[HuismAndré]

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

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

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

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

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

[HuismAndré]

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

Onzin:
[Afbeelding]

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

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

[con1]

Aan ieder die gereageerd heeft;

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

[deepbass909]

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

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

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

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

[deepbass909]

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

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

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

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

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

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

[RobertMe]

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


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

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

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

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

[deepbass909]

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

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


[...]

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

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

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

[JBS]

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


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

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

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

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

[deepbass909]

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

[Afbeelding]

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

[JBS]

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


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

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

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

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

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

[deepbass909]

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

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

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

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

[The Zep Man]

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

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

[BiG-GuY]

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


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

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

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

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

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

[rogervdh]

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

code:

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

Deze riedel bleef zich maar eindeloos herhalen, etc.

[Cyberpope]

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

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

[HuismAndré]

En de URL die in de logfile getoond wordt:

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

[rogervdh]

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

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

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

[Lizard]

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

code:

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

Deze riedel bleef zich maar eindeloos herhalen, etc.

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

Dit stukje staat in mijn configuration.yaml:

YAML:

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

[BiG-GuY]

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

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

Dit stukje staat in mijn configuration.yaml:

YAML:

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

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

[JBS]

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


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

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

[JBS]

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

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

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

[Eärendil]

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

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

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

[DAX23E]

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

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

Doe ik iets verkeerd?

Schopje naar het juiste topic

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

[Septillion]

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

[InjecTioN]

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

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

Doe ik iets verkeerd?

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

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

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

[Deshmir]

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

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

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

[JBS]

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

[...]

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

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

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

[DAX23E]

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

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

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

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

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

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

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

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

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

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

[jimmydwn]

Beste Tweakers,

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

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

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

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

Aansluiting is volgens het volgende schema:


Ik zit op Zigbee2Mqtt versie 2.7.2-1.

Alvast bedankt.

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

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

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

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

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

[Septillion]

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

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

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

[jimmydwn]

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

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

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

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

[HuismAndré]

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


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

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

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

[jimmydwn]

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

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

[Afbeelding]

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

[kroonen]

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


Hoi ,

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

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

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

met mqtt explorer kriijg ik gewoon de waarde

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


in ontwikkelhulpmiddelen heb ik deze waarde

code:

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

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

[badkuip]

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

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

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

[HuismAndré]

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

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

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

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

[rogervdh]

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

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

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

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

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

[sapphire]

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

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

Voor het verwijderen kreeg ik de volgende error:


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

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

[HuismAndré]

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

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

[Ben.Hahlen]

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

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

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

[Cyberpope]

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

[Gizz]

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

Pairing

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

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

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

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

[Ben.Hahlen]

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

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

[belly89]

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



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

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

Alle credits uiteraard voor @TheFes

[Hmmbob]

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


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

Alle credits uiteraard voor @TheFes

Nieuwe locatie van die code:

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

[Ben.Hahlen]

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


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

Alle credits uiteraard voor @TheFes

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

Wel een cool script, overigens!

[oltk]

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


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


[...]


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

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

[HowsMyApple]

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

Iemand een idee wat er aan de hand kan zijn?

[Gizz]

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

Iemand een idee wat er aan de hand kan zijn?

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

Zie ook de uitleg in de documentatie:

Troubleshooting: device stops sending messages/disconnects from network

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

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

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

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

Gedrag:

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

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

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

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

[HowsMyApple]

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

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

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

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

[Septillion]

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

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