Gestern wurde eine neue SLZB-OS Version 3.2.7 veröffentlicht.
SLZB-OS 3.2.7 - Release Notes
Highlights
**Integrated 30+ services **for local automatiations, including WLED, Telegram, Weather, Slack, Wake-on-Lan, MS Teams, E-mail, OpenWRT, and more.
AI is here: Added AI Assistant to help users write automation scripts more easily. in Beta test. Requires AI credentials (so far - Anthropic only).Watch the quick 4-minute YouTube overview .
SLZB-xU devices can now try a new experimental mode with native OTBR app running directly on the SLZB-xU device. Mode is still experimental, and there is reported bug in some installations - the coordinator may become unavailable after some time. Pattern is unknown, that is why still experimental status.
Improvements
Moved Ethernet processing to Core 0 for better load balancing.
Optimized the scripts virtual machine for better performance.
For U devices, the BT Proxy option now links directly to the activation manual.
IPv6 has been temporarily disabled for rework.
All localizations except EN have been moved to a cloud server to reduce firmware size. On first opening the coordinator interface, the localization will load in the browser if internet access is available. Without internet access, EN will be used.
Fixes
Fixed metadata overflow crashes for older .gbl update files.
MRW10/10U now use the Z-Wave packet parser, improving socket stability.
Fixed a crash in the hard reset handler.
Zigbee Hub
Replaced the LQI unit with “none”.
Fixed logging of values for Tuya DP.
MQTT now sends correct values even for unsupported devices, allowing them to be used in automations.
Ob man das sich jetzt schon installieren sollte muss jeder für sich selber entscheiden. Aktuell ist dazu gerade dieses Posting im HA-Forum aufgetaucht:
Bei den Z2M Issues-Meldungen bei Github konnte ich - Stand jetzt - noch keine Problemmeldungen zu der Version 3.2.7 finden. Aber so viele User werden sich das Update wohl auch noch nicht installiert haben. Ich selber warte wie üblicher erst einmal ab.
Ich habe es auf beiden Installiert. Das einzig negative war, das der 06M´er (Coordinator) eine neue IP Adresse bekommen hat. Die geschwind in Z2M geändert und weiter gings.
Hi, hab das auch auf beiden Sticks, 1 Coordinator und 1 Router, installiert ohne Probleme. Die IP hat sich auch nicht geändert, da ich das in der Fritzbox drin hab das die die selbe IP erhalten.
Das mit der geänderten IP bei dem SLZB-06M wundert mich ein wenig. Wie hat oder bekommt der denn seine IP? Statisch oder per DHCP?
Bei DHCP dürfte der ja eigentlich nur eine neue IP bekommen falls sich seine MAC-Adresse geändert haben sollte. Bei einer statischen IP hätte das Firmware-Update diese dann ja selbstständig durch irgendeine andere ersetzen müssen. Was auch eher ungewöhnlich wäre.
Ach ja - die oben von mir verlinkte Meldung im HA-Forum hat sich auch erledigt. Da hatte der User wohl nur irgendein “Kabel-Problem”.
Keine Ahnung warum. Vielleicht hängt es auch mit dem Update der 7590 von 8.20 auf 8.25 zusammen, das ich gestern zeitnah kurz vor den SLZB´s durchgeführt habe. In der FB habe ich auch mal die “Leichen” aussortiert die noch so verbucht waren.
Ist jetzt nichts dramatisches, das sich lohnt genauer erforscht zu werden. Es läuft.
Was am Ende das Wichtigste ist. Ich bleibe bei mir b.a.W. noch bei
weil ich damit überhaupt keine Probleme habe und im Moment auch keine Notwendigkeit sehe für irgendein Update.
Wenn man in der FritzBox die einmal vergebene IP-Adresse „IPv4-Adresse dauerhaft zuweisen“ Funktion benutzt sollte das nicht passieren, dass sich bei einem Upgrade oder Neustart der FB die IP-Adresse geändert wird.
Die MAC Adresse der Geräte ist nicht dauerhaft änderbar sein.
Ich habe 3 Sticks im Einsatz, bleibe aber vorerst auch bei deren älteren Firmware. Never touch a running system und die genannten Neuerungen sind jetzt für mich nicht besonders interessant.
Wenn es beim flashen der neuen Firmware mit mqtt oder Matter mal klemmt, hat sich ein erneutes flashen der mqtt oder matter firmware oft als hilfreich erwiesen. Es gab wohl mal eine Zeit, wo diese Bereiche durchs flashen des OS zerschossen wurden.
Das weiß ich soweit, danke. Ich mache da keinen Hehl draus, sondern wollte es nur erwähnt haben. Ob das nun vom SLZB Update alleine oder im Zusammenhang mit dem vorherigen FB Update herrührt entzieht sich meiner Kenntnis. Da es in weniger als 60 Sekunden bemerkt und gefixt wurde, stufe ich es in die Kategorie “ist halt passiert, jedoch nicht dramatisch “ ein.
ja, “super”. Nach dieser “Verbesserung” kann man den SLZB-06M halt nicht mehr als Thread Border Router verwenden, weil Thread zwingend IPv6 verlangt. Ich hatte deswegen das .7-Update erstmal nicht installiert, und bin erst auf das gestern veröffentlichte .9-Update gesprungen, weil in dessen Change-Log IPv6 nicht mehr erwähnt wird und ich gehofft hatte, daß IPv6 wieder läuft. Aber nix - die OTBR-App findet (logischerweise) keinen Border Router, weil der SLZB-06m “derzeit” kein IPv6 mehr spricht. Nachdem ich das Update rück-abgewickelt habe (per re-flash des SLZB auf Version 3.2.0 und HA-Neustart), läuft jetzt alles wieder. Welcher Honk bei SMLIGHT hat eigentlich gedacht, das Abschalten von IPv6 wäre eine gute Idee???
Ja IPv6 scheinbar kompl. zu deaktivieren und das damit zu begründen das das “überarbeitet” wird, ist schon ein etwas ungewöhnlicher Schritt. Insbesondere weil man damit den Funktionsumfang ja entsprechend einschränkt. Ich konnte im I-Net so spontan aber auch keine Infos oder Diskussion zu dem Thema finden, aus der hervorgeht warum dieser Schritt quasi zwingend notwendig ist. Denn ohne einen wirklich zwingenden Grund - z.B. irgendeine Sicherheitslücke oder so - kommt man wohl nicht auf so eine Idee. Da wäre es m.M.n. durchaus angebracht das dann auch näher zu begründen und nicht einfach nur zu schreiben: “IPv6 has been temporarily disabled for rework.”
OK mich betrifft das hier mit meinem SLZB-06 nicht wirklich, aber trotzdem finde ich das Vorgehen von SMLight da etwas ungewöhnlich.
gut, das wäre ein Argument. Aus Sicherheitsgründen habe ich bei mir IPv6 auch nur lokal aktiv - besonders mit einem Smart Home muß man schon aufpassen, daß Geräte nicht global eindeutige Adressen haben.
Aber man könnte bei einer solchen Veränderung ja die Nutzer davor warnen, daß das Update die Thread-Funktion abschaltet. Hätte ich nicht vor einer Woche den Change-log der 3.2.7-Version gelesen, wüsste ich davon nix (im Change-log der 3.2.9-Version wir IPv6 ja nicht mehr erwähnt) und hätte jetzt einfach ein kaputtes Thread-Netzwerk. Nicht, daß Thread nicht sowieso schon “halbgar” ist… Aber stundenlanges Troubleshooting wegen so einem Update braucht kein Mensch!
Aktuell ist dazu gerade dieses Posting im HA-Forum aufgetaucht:
Wie hat oder bekommt der denn seine IP? Statisch oder per DHCP?
