Zigbee2mqtt - open source zigbee bridge - Deel 2

[Septillion]

@Wachten... Yep, een ESP32 als controller/host incl ethernet en afhankelijk van het type nog een CC2552P, een EFR32MG21 of zelfs beide voor de dual radio (Zigbee+Thread). De Zigbee chips zijn dus gelijk aan die in de ZBDongle-P en ZBDongle-E.

Vandaar dat je dus ook twee (of drie) firmware upgrade knoppen hebt.

[ Voor 13% gewijzigd door Septillion op 26-11-2025 20:46 ]

[Wachten...]

Septillion schreef op woensdag 26 november 2025 @ 20:45:
@Wachten... Yep, een ESP32 als controller incl ethernet en afhankelijk van het type nog een CC2552P, een EFR32MG21 of zelfs beide voor de dual radio (Zigbee+Thread). De Zigbee chips zijn dus gelijk aan die in de ZBDongle-P en ZBDongle-E.

Vandaar dat je dus ook twee (of drie) firmware upgrade knoppen hebt.

Goed om te weten, dank voor je uitgebreide uitleg.

Had ik trouwens de buffer overflow kunnen voorkomen? Ik heb het gelukkig in 5 jaar tijd nog nooit gehad, maar heb nu sinds een maand deze stick, en nu ineens dit probleem. Ik hoop niet dat dit al te vaak gebeurd, want dat zou wel erg vervelend zijn (vooral voor vrouwlief als ik niet thuis ben)

[Septillion]

@Wachten... Ik gebruik hem niet thuis, alleen op de vereniging. Maar uitgaande van de SLZB-06 (dus zonder M), ben je op OS/Core 3.1.3? En 20250325 voor de radio (CC2552P)?

[Wachten...]

Septillion schreef op woensdag 26 november 2025 @ 20:52:
@Wachten... Ik gebruik hem niet thuis, alleen op de vereniging. Maar uitgaande van de SLZB-06 (dus zonder M), ben je op OS/Core 3.1.3? En 20250325 voor de radio (CC2552P)?

Ja ik heb beide naar de laatste versie geupdate nadat ik de problemen had. De problemen zijn dus niet ontstaan door de update. Zit daar een fix in dan dat je weet? Ik zat op 3.1.0

[Beekforel]

Septillion schreef op woensdag 26 november 2025 @ 20:52:
@Wachten... Ik gebruik hem niet thuis, alleen op de vereniging. Maar uitgaande van de SLZB-06 (dus zonder M), ben je op OS/Core 3.1.3? En 20250325 voor de radio (CC2552P)?

Mijn Zigbee (iets andere chip, CC2674P10) zit nog op 20240716 want 20250325 staat als dev firmware met een opmerking over een probleem met de PAN id dus die durf ik niet aan. Is wel stabiel?

[Wachten...]

Beekforel schreef op woensdag 26 november 2025 @ 20:58:
[...]

Mijn Zigbee (iets andere chip, CC2674P10) zit nog op 20240716 want 20250325 staat als dev firmware met een opmerking over een probleem met de PAN id dus die durf ik niet aan. Is wel stabiel?

Nou ik heb wel wat vertragingen gehad en af en toe wat slechter reageren van de stick. Ik weet niet of ik makkelijk terug kan naar een vorige versie, maar anders zou ik dat liever doen.

[Beekforel]

Wachten... schreef op woensdag 26 november 2025 @ 21:06:
[...]


Nou ik heb wel wat vertragingen gehad en af en toe wat slechter reageren van de stick. Ik weet niet of ik makkelijk terug kan naar een vorige versie, maar anders zou ik dat liever doen.

Ja, je kunt erg eenvoudig wisselen tussen firmwares.

[Wachten...]

@Septillion Overigens nog wat anders. Ik heb hier 1 Hue dimmer V1, en die wil maar niet updaten in Z2M.
Ik heb hem ook al een keer verwijderd, gereset en opnieuw toegevoegd in Z2M, maar ook dan doet hij het niet. Er zit een nieuwe volle batterij in, maar ook dat helpt niet.

Ook druk ik steeds knoppen in om hem "wakker" te maken, maar niks helpt.

Al mijn andere Hue V1 dimmers zijn wel gewoon geupdate!

[RobertMe]

Septillion schreef op woensdag 26 november 2025 @ 20:45:
of zelfs beide voor de dual radio (Zigbee+Thread)

Of Zigbee + Zigbee, of Thread + Thread. Wat wel dom klinkt, maar in het eerste geval ook ZHA + Z2M kan zijn bv. Maar voor Thread is er vast alleen OpenThread Border Router dus 2x is dan wel onlogisch

[Wachten...]

@Beekforel bedoel je overigens niet Revision: 20240710? i.p.v. Revision: 20240716?

[Septillion]

@Beekforel Ah, ja, ik zie dat iemand hem gewoon een update gegeven heeft en ik deed gewoon copy-paste 20240710 is dan de laatste niet-dev firmware.

Ook al moet ik zeggen dat het dus wel prima draait maar is het netwerk nog niet zo groot.

[ Voor 24% gewijzigd door Septillion op 26-11-2025 21:14 ]

[Beekforel]

Wachten... schreef op woensdag 26 november 2025 @ 21:11:
@Beekforel bedoel je overigens niet Revision: 20240710? i.p.v. Revision: 20240716?

Ik heb 20240716, maar ik heb een andere SLZB en daarin een andere Zigbee chip (CC2674P10) dus dat zal denk ik het verschil verklaren.

[Wachten...]

Septillion schreef op woensdag 26 november 2025 @ 21:13:
@Beekforel Ah, ja, ik zie dat iemand hem gewoon een update gegeven heeft en ik deed gewoon copy-paste 20240710 is dan de laatste niet-dev firmware.

Ook al moet ik zeggen dat het dus wel prima draait maar is het netwerk nog niet zo groot.

Ik had daar uberhaupt nooit op gelet. Een extra popup met de melding dat het geen "normale" update is, was wel welkom geweest. ik heb de update even terug gezet naar de 20240710 versie, thx!

[HuismAndré]

Zijn er toevallig ook mensen die zijn overgestapt van een SonOff Dongle P naar de Sonoff Dongle Max? Zo ja, moest alles opnieuw gepaird worden?

[BiG-GuY]

HuismAndré schreef op donderdag 27 november 2025 @ 21:28:
Zijn er toevallig ook mensen die zijn overgestapt van een SonOff Dongle P naar de Sonoff Dongle Max? Zo ja, moest alles opnieuw gepaird worden?

Heb het zelf niet gedaan tussen die twee, maar doordat de P een Texas Instruments chip heeft en de Dongle Max een Silicon Labs chip, is het bijna zeker dat je alles moet repairen.

Als je vanaf de Dongle E naar de Dongle Max zou gaan, zou het mogelijk wel lukken. Al is het mij nog niet gelukt om bij Z2M te migreren tussen sticks zonder dat ik iets hoef te repairen. Maar heb het niet recent geprobeerd. Met ZHA heb ik zonder problemen kunnen migreren tussen coordinators.

[RobertMe]

HuismAndré schreef op donderdag 27 november 2025 @ 21:28:
Zijn er toevallig ook mensen die zijn overgestapt van een SonOff Dongle P naar de Sonoff Dongle Max? Zo ja, moest alles opnieuw gepaird worden?

Als alternatief: Een SMLight MR (/Multi Radio) variant met TI chip + Silicon Labs chip? Dan kun je Z2M blijven draaien op de TI chip. Wel opletten dat je dan de juiste hebt. Want er zijn varianten met 2x Silicon Labs en varianten met 1x TI + 1x Silicon Labs).

Overigens geeft de Z2M docs aan dat zstack => ember en ember => zstack zou kunnen werken zonder te re-pairen, maar officieel niet ondersteund is. Dat is afhankelijk van de gebruikte apparaten? Waarbij mogelijk sommige wel opnieuw gepaired moeten worden maar andere niet. Zul je uiteraard zien dat die wat je eenvoudig opnieuw kunt pairen blijven werken en bv inbouwmodules die je moet uitbouwen om te re-pairen wel opnieuw gekoppeld moeten worden .

[skank]

Vermoedelijk niet het correcte topic?
MAar zijn dit nou de goeie zigbee aqara deur sensors?
Ik zie dat ze in BE 15 euro kosten...
https://www.aliexpress.co...a_LYhW0NWqYBoCF_wQAvD_BwE

[Martin.Air]

skank schreef op vrijdag 28 november 2025 @ 19:55:
Vermoedelijk niet het correcte topic?
MAar zijn dit nou de goeie zigbee aqara deur sensors?
Ik zie dat ze in BE 15 euro kosten...
https://www.aliexpress.co...a_LYhW0NWqYBoCF_wQAvD_BwE

Je link lijkt het niet helemaal te doen, maar ik gebruik tegenwoordig Moes (Tuya) sensoren. Deze bieden ook een "tamper" detectie en koppelen gaat een stuk betrouwbaarder.
https://nl.aliexpress.com/w/wholesale-moes-door-sensor.html

[banaliteit]

Wachten... schreef op woensdag 26 november 2025 @ 21:08:
@Septillion Overigens nog wat anders. Ik heb hier 1 Hue dimmer V1, en die wil maar niet updaten in Z2M.
Ik heb hem ook al een keer verwijderd, gereset en opnieuw toegevoegd in Z2M, maar ook dan doet hij het niet. Er zit een nieuwe volle batterij in, maar ook dat helpt niet.

Ook druk ik steeds knoppen in om hem "wakker" te maken, maar niks helpt.

Al mijn andere Hue V1 dimmers zijn wel gewoon geupdate!

Toevallig loop ik hier ook tegen aan. Ben jij al verder gekomen met de Hue dimmer knop v1?

Edit: heb al gefixeerd. Kwestie van bijv. aan knop ingedrukt houden en dan op update knop drukken.

[ Voor 7% gewijzigd door banaliteit op 29-11-2025 10:01 ]

[Martin.Air]

banaliteit schreef op zaterdag 29 november 2025 @ 09:56:
[...]

Toevallig loop ik hier ook tegen aan. Ben jij al verder gekomen met de Hue dimmer knop v1?

De batterij moet genoeg spanning geven om te willen updaten, je zou het even kunnen proberen met een batterij uit een dimmer die wel heeft geupdate?

[ComTech]

Ik heb al jaren een zzh! CC2652R usb stick.
Ik heb daar zo'n 45 apparaten op.
Wat deur en raam sensoren bewegingssensoren en temperatuursensoren en lampen.
De lampen welke niet aan de hue bridge gekoppeld kunnen worden (ik heb ook een hue bridge voor lampen die echt moeten werken aldus de vrouw des huizes ).

Maar die zzh! CC2652R stick heb ik ooit ingesteld het werkt en nooit meer aangezeten.
De laatste tijd doet hij nog wel eens moeilijk na een HA update en dan is het weer klooien om hem aan de gang te houden.
Mocht hij defect raken dan zit ik ineens zonder en is het niet even makkelijk te herstellen eerst een nieuwe bestellen en dan alles opnieuw pairen.
En firmware updaten is lastig en ik wil gewoon iets wat makkelijk te updaten is via de gui en goed door HA wordt ondersteund.
Nu lijkt mij de Home Assistant Connect ZBT-2 wel wat.

Ik zie op de webshop staan
"Migreer je Zigbee- of Thread-netwerk naadloos met de meegeleverde wizard van Home Assistant"

Maar gaat dat ook met de zzh! CC2652R stick of moet ik echt alles opnieuw pairen?
Als dat zo is dan maar een keer een dagje prutsen maar liever niet natuurlijk.
Of is er een andere manier met eventueel een andere stick welke kan wat ik wil.
Alle tips zijn welkom

[ Voor 4% gewijzigd door ComTech op 30-11-2025 10:58 . Reden: typos ]

[dixet]

ComTech schreef op zondag 30 november 2025 @ 10:55:
Maar die zzh! CC2652R stick heb ik ooit ingesteld het werkt en nooit meer aangezeten.
De laatste tijd doet hij nog wel eens moeilijk na een HA update en dan is het weer klooien om hem aan de gang te houden.
[...]

Als je z2m gebruikt zou een herstart van HA weinig invloed op de stick moeten hebben. Bij een update van HA start alleen de HA container, niet het hele OS. Z2m blijft dus gewoon doordraaien. Of gebeurt het na een update van HAOS? Want dat reboot wel je hele systeem. Wat zeggen de logs van z2m wanneer de stick uitvalt?

ComTech schreef op zondag 30 november 2025 @ 10:55:
Ik zie op de webshop staan
"Migreer je Zigbee- of Thread-netwerk naadloos met de meegeleverde wizard van Home Assistant"

Maar gaat dat ook met de zzh! CC2652R stick of moet ik echt alles opnieuw pairen?
Als dat zo is dan maar een keer een dagje prutsen maar liever niet natuurlijk.
Of is er een andere manier met eventueel een andere stick welke kan wat ik wil.
Alle tips zijn welkom

Het lijkt mij dat een wizard in home assistant werkt voor ZHA, niet voor z2m. Er zijn wel handleidingen hoe je in z2m een netwerk kan migreren, maar ik weet niet hoe makkelijk dat gaat en of jou stick dat ook ondersteunt.

[ComTech]

dixet schreef op zondag 30 november 2025 @ 11:56:
[...]

Als je z2m gebruikt zou een herstart van HA weinig invloed op de stick moeten hebben. Bij een update van HA start alleen de HA container, niet het hele OS. Z2m blijft dus gewoon doordraaien. Of gebeurt het na een update van HAOS? Want dat reboot wel je hele systeem. Wat zeggen de logs van z2m wanneer de stick uitvalt?

Ik draai HAOS op een intel nuc met proxmox en het gebeurd vaak als de vm dus HAOS is herstart of iets.
Dan ziet z2m de usb stick niet, vaak is het even de usb stekker eruit en en weer in en klaar maar soms moet dat een paar keer.
[...]

Het lijkt mij dat een wizard in home assistant werkt voor ZHA, niet voor z2m. Er zijn wel handleidingen hoe je in z2m een netwerk kan migreren, maar ik weet niet hoe makkelijk dat gaat en of jou stick dat ook ondersteunt.

Ik denk dat het inderdaad alleen voor ZHA is en niet voor z2m.
Met mijn stick schijnt het wel te kunnen maar je hebt dan iets van pan id en netwerk key nodig.
Die kan ik wel vinden in de config files van z2m.

[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 ]