Den Rand kann ich absolut nicht nachvollziehen. Statt sich über eine höchst aktive OS/Fw- Entwicklung und Pflege des Herstellers zu freuen, wird hier abgeledert.
Es gibt im Ggs. zu den meisten anderen Herstellern alle neuen/alten verfügbar Versionen zum Download.
Dauert 2 mins. und man ist auf dem vorherigen Stand. Stattdessen wird hier ewig rumlaviert.
Dann lass doch einfach die Finger von den Updates und bleib bei der bei dir funktionierenden Version. Zwingt ja keiner zum Update. Aber das ist dann auch wieder nicht Recht und man schreit nach " Updaaaaaates". Erinnert an die immer gleichen Diskussionen bei Fritz!Boxen.
Und immer diese Anspruchshaltung! Herrje, ich muss ruhiger werden…
Das ist alles etwas “seltsam”. Auch bei mir zeigt das SLZB-Dashboard an, daß IPv6 inaktiv wäre:
was aber definitiv falsch ist - der SLZB-06m für Thread (das ist das zweite Device von oben) ist mit dem Router über IPv6 verbunden und hat eine funktionierende lokale IPv6-Adresse, wie ich in meinem Router (Asus BT8) sehe:
Das dritte ist ein baugleiches Gerät, das ich als Zigbee-Koordinator verwende, und das unter Version 3.2.9 läuft - und KEINE IPv6-Adresse hat.
Aber “the proof is in the pudding” - mit 3.2.9 funktioniert weder IPv6 noch - konsequenterweise - Thread. Mit 3.2.0 funktioniert beides.
Warum “konsequenterweise”?
In meinem Setup ist auch kein IPv6 aktiv und der SLZB funktioniert problemlos als BR.
Ich denke,@Osorkon hat a der Stelle schon Recht - IPv6 wird für den OTBR benötigt, was ja die Integration in HA übernimmt und nicht der SLZB. Für die Kommunikation BR (der SLZB) und OTBR (HA Integration) ist wohl IPv4 ausreichend.
Wenn der SLZB auch noch den OTBR übernimmt, sieht es natürlich anders aus - diesen Modus unterstützt der 06M meines Wissens aber gar nicht.
Hier der Screenshot meines SLZB-MR4U, welcher den neuen zusätzlichen Modus implementiert hat.
Gruß, Lars
Ja, du musst ruhiger werden ![]()
Der Punkt ist nicht, daß irgendjemand zu einem Update gezwungen wird, sondern daß nach dem Update die entscheidenden Funktion des Geräts nicht mehr geht. Und es Ist ja nicht so, als würde Thread als solches immer problemlos funktionieren. Das Nicht-Funktionieren sofort auf das Update zurückzuführen ist deswegen nicht selbstverständlich. Dann darf man möglicherweise stundenlang Troubleshooting machen. Wäre schon nett, der Hersteller würde in den Change-logs erwähnen, daß Thread erstmal nicht mehr geht, findest du nicht? Ist das eine unangemessene “Anspruchshaltung”?
Wie auch immer, Fakt ist daß nach dem Update Thread nicht mehr funktioniert, weil die OTBR-App den SLZB-06M nicht mehr als Thread Border Router findet. Re-Flash mit der älteren 3.2.0-Version und alles geht wieder.
Auch ich hatte nach dem Update des SLZB den Effekt, das meine OTBR Integration den Stick nicht gefunden hat. Erst, nachdem ich den Stick stromlos (nicht nur Reboot) machte, klappte es. Diesen Effekt hatte ich auch schon bei vergangenen Updates des SLZB.
Vielleicht ist es bei Dir ja auch so…
Am fehlenden IPv6 scheint es aber nicht zu liegen.
Gruß, Lars
Ich vermute, dass ist in Wirklichkeit das “andere” Problem. Wie LvS21 oben schon schrieb, ist bei mir genauso: IPv6 ist auf dem SLZB mit “remote OTBR” nicht nötig/inaktiv.
P.S.
das Problem hier war gemeint:
Gibt aber noch diverse andere ähnliche Meldungen.
Das erneute Flashen der gleichen(!) Fw. löst hier das Problem.
Danke für den Hinweis! Das kann ich ja mal ausprobieren, ist ja kein Ding wieder zurück zu flashen wenn es nicht geht.
Öfter mal was Neues.
Die Option für das aktivieren oder deaktieren von IPv6 ist nicht da zu sehen wo sie sonst mal war, IPv6 ist trotzdem auf On und der OTBR läuft scheinbar direkt auf dem Dongle.
Was für ein SMLight Modell nutzt Du denn da genau? Offensichtlich gibt es da dann ja doch noch/wieder Unterschiede von Modell zu Modell.
VG Jim
Auch das SLZB-MR4U.
Trau mich gar nicht den jetzt neuzustarten ![]()
Finde ich sehr Interessant.
Das heißt, du benutzt diese Option schon, richtig?
Hattest du vorher auch schon den HA OTBR als Integration laufen?
Wenn ja, musstest du die Thread Geräte neu Verbinden?
Welche Geräte hast du am Start?
Laut SMLight soll die Funktion noch wacklig sein - wie sieht es bei dir aus?
Gruß, Lars
Musst Du ja auch nicht unbedingt.
Nach dem Firmware-Update wurde der Dongle ja neu gestartet und so lange alles funktioniert gibt es ja auch keinen Grund den neu zu starten, oder gar per Strom weg und wieder anschließen neu zu booten.
D.h. so lange es keine neue Firmware-Version gibt, bei der dann offiziell auch wieder IPv6 vorhanden ist, würde ich jetzt schön die Finger davon lassen.
Sofern denn alles problemlos funktioniert.
VG Jim
Ich hatte 2 Wochen bevor die Funktion mit “OTBR running on device” kam, die Option mit “Remote OTBR” am Laufen. Das war aber noch in einer sehr frühen Phase und ich musste mehrmals meine Geräte neu koppeln.
Als die Funktion mit “OTBR running on device” kam, hab ich die Funktion aktiviert und seitdem läuft es einigermaßen stabil. Ich habe aktuell nur ein schwaches Mesh, das änder sich hoffentlich morgen (da kommen 3 IKEA Grillplats).
Ich bin also ein schlechtes Beispiel um zu sagen, ob es gut oder schlecht läuft ![]()
Auch wenn es jetzt nicht zu diesem Firmware-Beitrag passt, aber ich will deshalb nicht extra einen neuen Beitrag erstellen. ![]()
Kann es ggf. sein das es aktuell irgendein Verbindungs-Problem zu dem/den OTA-Server(n) von SMLight gibt? Wenn ich versuche per Firmware-Update —> Auf Updates prüfen mir die verfügbaren Firmware-Versionen (egal ob Core oder Radio) anzeigen zu lassen passiert das:
Der SLZB-06 hat aber eine I-Net-Verbindung

und an der Netzwerkkonfiguration, oder dem Netzwerk selber, hat sich auch nichts geändert. Auch gibt hier keinerlei Einschränkungen was die I-Net-Zugriff betrifft und alle anderen LAN-Clients haben damit auch kein Problem. Anm.: Die IP-Vergabe für den SLZB-06 erfolgt per DHCP-Server, aber auch das war schon immer so und spielt daher in dem Fall keine Rolle.
OK ich nutze hier noch eine ältere Core-Version (v3.2.0)
aber das sollte bzgl. der OTA-Verbindung ja eigentlich keine Rolle spielen.
Bevor ich hier jetzt irgendwelche Neustarts/Reboots und ähnliche Dinge mache und ggf. “Geister jage”,
die Frage in die Runde ob bei anderen SLZB-Nutzern die Verbindung zu dem/den OTA-Server(n) von SMLight aktuell möglich ist?
Edit: Bitte gebt bei einer Rückmeldung zu meiner Frage auch die von Euch genutzte Core Firmware Version mit an, um vielleicht auch zu klären ob es ggf. an der von mir genutzen v3.2.0 liegen könnte. Weil bei neueren Firmware-Versionen sich ggf. die OTA-Server-URL/IP geändert hat.
VG Jim
Ich habe Core Version 3.3.1 und bei mir gibt es keine Probleme mit der OTA Abfrage. Sowohl Core als auch OS Abfrage funktionieren sofort.
Moin
Danke für Deine Rückmeldung. ![]()
Da die bisherigen Rückmeldungen zu meiner Frage ja durchaus überschaubar waren,
habe ich eben dann weitere Versuche gestartet die OTA-Funktion wieder zum Leben zu erwecken.
- SLZB-06 stromlos gemacht = Weiterhin OTA-Fehler
- SLZB-06 von DHCP auf statische IP-Vergabe gestellt = Weiterhin OTA-Fehler
- Manuell die Firmware von 3.20 auf 3.2.9 aktualisiert = Weiterhin OTA-Fehler
Auch im SLZB-06 System-Log taucht nichts auf was auf irgendein Problem hindeuten könnte:
[01.05.2026 08:35:57] setup | Starting firmware: v3.2.9
[01.05.2026 08:35:57] getDevType | using ADC
[01.05.2026 08:35:58] setup | FS mounted
[01.05.2026 08:35:59] Config | load config
[01.05.2026 08:35:59] Config | config open: Ok
[01.05.2026 08:35:59] setup | Reboot reason: SOFTWARE
[01.05.2026 08:35:59] setup | starting ZB1 serial on: 115200 baud. HW Flow: off
[01.05.2026 08:35:59] setup | Coordinator mode: LAN
[01.05.2026 08:35:59] setup | Device: 'SLZB-06' PCB revision: 0
[01.05.2026 08:35:59] setup | Radio mode: "ZB COORD" Radio FW version: 20240710 Radio FW CH: Unknown
[01.05.2026 08:35:59] Network | init
[01.05.2026 08:35:59] taskAP | start task
[01.05.2026 08:36:00] Network | EVENT: 1 - ETH_START
[01.05.2026 08:36:00] Network | EVENT: 3 - ETH_CONNECTED
[01.05.2026 08:36:00] Network | ETH init: OK
[01.05.2026 08:36:00] Network | EVENT: 5 - ETH_GOT_IP
[01.05.2026 08:36:00] Network | ETH MAC: 08:A6:F7:xx:xx:xx IPv4: 192.168.1.5 GW: 192.168.1.1 Speed: 100Mbps DNS1: 0.0.0.0 DNS2: 0.0.0.0
[01.05.2026 08:36:00] Network | AP task deleted
[01.05.2026 08:36:00] Network | Network up
[01.05.2026 08:36:00] SocketServer | [CC2652P] Setup done
[01.05.2026 08:36:00] SocketServer | [CC2652P] Task started
[01.05.2026 08:36:00] Network | ETH static IP config: OK
[01.05.2026 08:36:00] Network | [mDNS] Started
[01.05.2026 08:36:00] SocketServer | [CC2652P] Started server on port: 6638
[01.05.2026 08:36:01] loadMqttConfig | config does not exist! Using defaults
[01.05.2026 08:36:01] Web | Web services init done
[01.05.2026 08:36:01] time | time sync start
[01.05.2026 08:36:01] setup | Filesystem size: 3456
[01.05.2026 10:36:01] setup | Filesystem used: 192
[01.05.2026 10:36:01] setup | SM Console started
[01.05.2026 10:36:01] setup | done
[01.05.2026 10:36:01] [LEDs init] | done
[01.05.2026 10:36:02] internet | connected
[01.05.2026 10:36:04] SocketServer | [CC2652P] New client, id: 0
[01.05.2026 10:36:04] time | timezone: CET-1CEST,M3.5.0,M10.5.0/3
[01.05.2026 10:36:05] time | Friday, May 01 2026 10:36:05
[01.05.2026 10:36:05] taskTimeSync | Heap: 1920
[01.05.2026 10:36:05] time | stop task
[01.05.2026 10:36:05] time | Heap: 1920
[01.05.2026 10:36:05] Network | [POST] result: 200
[01.05.2026 10:36:05] stats | Statistics sent
[01.05.2026 10:36:05] stats | Heap: 3772
[01.05.2026 10:36:23] SSE | new client: 192.168.1.61
[01.05.2026 10:36:35] internet state | Heap: 2324
[01.05.2026 10:36:35] SSE | new client: 192.168.1.150
[01.05.2026 10:36:35] internet state | Heap: 2320
[01.05.2026 10:36:42] Config | write config
[01.05.2026 10:36:42] Config | config saved
[01.05.2026 10:37:21] Config | write config
[01.05.2026 10:37:21] Config | config saved
[01.05.2026 10:38:08] internet state | Heap: 2552
[01.05.2026 10:47:51] internet state | Heap: 2552
[01.05.2026 11:02:51] internet state | Heap: 2552
[01.05.2026 11:06:47] SSE | new client: 192.168.1.150
[01.05.2026 11:06:47] internet state | Heap: 2548
Hm - so langsam gehen mir die Idee aus.
Klar das klingt natürlich danach das irgendetwas im LAN den Zugriff auf das I-Net beim SLZB-06 verhindern würde, aber das kann ich ausschließen. Es gibt bei mir im LAN nicht irgendwelche “Blocker” ala Adguard oder Ähnliches und der Zugriff wird auch nicht durch irgendeine Firewall blockiert. Der SLZB-06 ist per LAN und Switch mit meiner FB verbunden - genau so wie aktuell weitere ca. 40 Clients - und kein Client hat irgendwelche Probleme mit dem I-Net Zugriff. Abgesehen davon habe ich hier bei der grundsätzlichen Netzwerkeinrichtung und/oder dem SLZB-06, schon seit Monaten nichts mehr geändert. Außerdem zeigt mir das WebGUI des SLZB-06 ja auch an das eine Internet-Verbindung bestehen würde und der Zugriff auf den NTP-Server erfolgt lt. Log ja auch problemlos.
Aus dem Bauch heraus würde ich immer noch vermuten das SMLight da etwas an deren OTA-Server(n) geändert hat, aber dann müsste das Problem bei @onofthepagans ja eigentlich auch auftauchen.
Naja - zumindest habe ich hier jetzt etwas über das ich wohl etwas länger “nachgrübeln” kann/darf.
Falls jemand dazu noch eine Idee hat dann immer her damit. ![]()
Edit: Das Problem hat sich geklärt! Ich hätte auf die Idee einfach mal einen anderen Browser zu benutzen vielleicht schon gestern kommen sollen,
aber genau das habe ich gerade mal gemacht und siehe da per Chromium wird eine Verbindung zu den OTA-Servern von SMLight aufgebaut. Offensichtlich hat das letzte Update in dieser Woche bei meinem Waterfox Browser zu dem Problem geführt. Was auch immer da jetzt genau bei Waterfox geändert wurde, denn den Browser benutze ich hier schon lange und auch mit dem WebGUI des SLZB-06 kam es dabei bisher nie zu einem Problem.
OK das ist jetzt auch erst einmal egal. Wichtig ist das ich jetzt weiß was das Problem ist.
Somit hat sich meine Frage hier erledigt.
Edit 2: Die NoScript-Erweiterung bei Waterfox war das “Problem”. Vermutlich durch mein Firmware-Update bei dem SLZB-06 vor ein paar Wochen auf die Firmware 3.2.0, wurde auch die URL für die OTA-Server-Adresse geändert. Diese neue Adresse wurde standardmäßig von NoScript blockiert und musst erst freigegeben werden. Somit ist jetzt auch die Erklärung für das Problem gefunden. ![]()
VG Jim










