NEWS
ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk
-
@asgothian
Das ist interessant. Ich erinnere mich! Vor länger Zeit wurde mir tatsächlich ein mir unbekanntes 'Thermostat' (sogar mit Bildchen) angezeigt. Und dabei habe ich gar keine smarten Thermostate im Haus (und Zigbee schon gar nicht) und habe ich auch nie besessen. Ich habe das damals auch mehrmals gelöscht, bis es irgendwann nicht wieder kam. Aber möglicherweise ist jetzt bloß kein Bildchen und kein Name mehr da. Den Namen habe ich mir damals leider nicht gemerkt oder notiert, drum kann ich jetzt nicht sagen, ob es genau das von Dir genannte war.In meinen Unterlagen finde ich gerade eine Notiz, dass der 'undefined' 0x84ba20fffe28ba94 mindestens im April 2023 schon mal aufgetaucht ist. Ich weiß - das hilft jetzt auch nicht weiter. Aber offenbar besteht das "Phänomen" schon deutlich länger, als mir vorhin bewusst war.
Hallo @Asgothian,
heute Morgen habe ich noch etwas weiter geforscht und folgende Erkenntnisse hinzugewonnen zu denen ich gern Deine Meinung wüsste:Ich habe mir im Ordner
/opt/iobroker/iobroker-data/zigbee_0die Dateiennvbackup.jsonLocalOverrides.jsonundshepherd.db
angeschaut. Dabei ist mir aufgefallen, dass in der 'nvbackup.json' fünf Geräte aufgeführt werden, die ich gar nicht besitze und auch nie besessen habe. Lediglich den 'f0d1b8000015541c ' (SmartPlug) hatte ich früher einmal. Zudem werden in der 'LocalOverrides.json' sogar zu zwei dieser Geräte Alternativbezeichnungen vorgehalten.
In der 'shepherd.db' kommt derzeit keine der unten in der Tabelle genannten ieee's vor. (sicher auch weil ich gestern die zwei 'undefined' über den Adapter gelöscht hatte)
Kann ich die unbekannten Geräte einfach von Hand aus den Dateien entfernen oder mache ich da mehr Schaden?
-
Hallo @Asgothian,
heute Morgen habe ich noch etwas weiter geforscht und folgende Erkenntnisse hinzugewonnen zu denen ich gern Deine Meinung wüsste:Ich habe mir im Ordner
/opt/iobroker/iobroker-data/zigbee_0die Dateiennvbackup.jsonLocalOverrides.jsonundshepherd.db
angeschaut. Dabei ist mir aufgefallen, dass in der 'nvbackup.json' fünf Geräte aufgeführt werden, die ich gar nicht besitze und auch nie besessen habe. Lediglich den 'f0d1b8000015541c ' (SmartPlug) hatte ich früher einmal. Zudem werden in der 'LocalOverrides.json' sogar zu zwei dieser Geräte Alternativbezeichnungen vorgehalten.
In der 'shepherd.db' kommt derzeit keine der unten in der Tabelle genannten ieee's vor. (sicher auch weil ich gestern die zwei 'undefined' über den Adapter gelöscht hatte)Kann ich die unbekannten Geräte einfach von Hand aus den Dateien entfernen oder mache ich da mehr Schaden?
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Hallo @Asgothian,
heute Morgen habe ich noch etwas weiter geforscht und folgende Erkenntnisse hinzugewonnen zu denen ich gern Deine Meinung wüsste:Ich habe mir im Ordner
/opt/iobroker/iobroker-data/zigbee_0die Dateiennvbackup.jsonLocalOverrides.jsonundshepherd.db
angeschaut. Dabei ist mir aufgefallen, dass in der 'nvbackup.json' fünf Geräte aufgeführt werden, die ich gar nicht besitze und auch nie besessen habe. Lediglich den 'f0d1b8000015541c ' (SmartPlug) hatte ich früher einmal. Zudem werden in der 'LocalOverrides.json' sogar zu zwei dieser Geräte Alternativbezeichnungen vorgehalten.
In der 'shepherd.db' kommt derzeit keine der unten in der Tabelle genannten ieee's vor. (sicher auch weil ich gestern die zwei 'undefined' über den Adapter gelöscht hatte)Kann ich die unbekannten Geräte einfach von Hand aus den Dateien entfernen oder mache ich da mehr Schaden?
Du solltest folgendes machen - zur Sicherheit:
- Adapter anhalten
- Den Haken bei
start the Zigbee network automaticallyentfernen, settings speichern. - Sicherheitskopie von nvbackup.json machen
- adapter starten
- über den
Start/StopButton in der Konfiguration (tab Hardware) versuchen den Adapter zu starten - im Textbereich darunter wird angezeigt was passiert. Sofern das Zigbee-Subsystem durchstartet ist alles ok. Wenn es Probleme gibt kannst du die nvbackup.json restaurieren und den Test wiederholen.
Alle Geräte die in der LocalOverrides.json eingetragen sind müssen
- mit dem Netzwerk verbunden gewesen sein.
- korrekt erkannt worden sein.
Die Einträge entstehen erst nachdem ein Gerät sauber gepaired wurde.
Die Einträge in der nvbackup.json können Grund sein warum die Geräte sich wieder mit dem Netz verbinden, obwohl sie das nicht dürften. Sie müssen aber irgendwo in Reichweite sein.
lebst du in einem Mehrfamilienhaus ?
A.
Die Einträge in der LocalOverrides.json kannst du gefahrlos beseitigen. Das schlimmste was passiert ist das von Dir vergebene Namen ggf. entfallen, und Wieder neu vergeben werden müssen.Bei der nvBackup.json ist es etwas schwieriger - es gibt fälle wo es Probleme gibt den Adapter zu starten nachdem die Datei geändert wurde.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Hallo @Asgothian,
heute Morgen habe ich noch etwas weiter geforscht und folgende Erkenntnisse hinzugewonnen zu denen ich gern Deine Meinung wüsste:Ich habe mir im Ordner
/opt/iobroker/iobroker-data/zigbee_0die Dateiennvbackup.jsonLocalOverrides.jsonundshepherd.db
angeschaut. Dabei ist mir aufgefallen, dass in der 'nvbackup.json' fünf Geräte aufgeführt werden, die ich gar nicht besitze und auch nie besessen habe. Lediglich den 'f0d1b8000015541c ' (SmartPlug) hatte ich früher einmal. Zudem werden in der 'LocalOverrides.json' sogar zu zwei dieser Geräte Alternativbezeichnungen vorgehalten.
In der 'shepherd.db' kommt derzeit keine der unten in der Tabelle genannten ieee's vor. (sicher auch weil ich gestern die zwei 'undefined' über den Adapter gelöscht hatte)Kann ich die unbekannten Geräte einfach von Hand aus den Dateien entfernen oder mache ich da mehr Schaden?
Du solltest folgendes machen - zur Sicherheit:
- Adapter anhalten
- Den Haken bei
start the Zigbee network automaticallyentfernen, settings speichern. - Sicherheitskopie von nvbackup.json machen
- adapter starten
- über den
Start/StopButton in der Konfiguration (tab Hardware) versuchen den Adapter zu starten - im Textbereich darunter wird angezeigt was passiert. Sofern das Zigbee-Subsystem durchstartet ist alles ok. Wenn es Probleme gibt kannst du die nvbackup.json restaurieren und den Test wiederholen.
Alle Geräte die in der LocalOverrides.json eingetragen sind müssen
- mit dem Netzwerk verbunden gewesen sein.
- korrekt erkannt worden sein.
Die Einträge entstehen erst nachdem ein Gerät sauber gepaired wurde.
Die Einträge in der nvbackup.json können Grund sein warum die Geräte sich wieder mit dem Netz verbinden, obwohl sie das nicht dürften. Sie müssen aber irgendwo in Reichweite sein.
lebst du in einem Mehrfamilienhaus ?
A.
Die Einträge in der LocalOverrides.json kannst du gefahrlos beseitigen. Das schlimmste was passiert ist das von Dir vergebene Namen ggf. entfallen, und Wieder neu vergeben werden müssen.Bei der nvBackup.json ist es etwas schwieriger - es gibt fälle wo es Probleme gibt den Adapter zu starten nachdem die Datei geändert wurde.
-
@asgothian
OK, danke für den Tipp. Hab ich gemacht. Lief alles wieder fehlerfrei an. Werde es nun weiter beobachten. -
@arteck
Ausschließen kann ich es nicht - halte es aus persönlicher Erfahrung mit der Zigbee-Reichweite doch für sehr unwahrscheinlich. Mein direktes Nachbarhaus hat definitiv keine Zigbee-Geräte (oder sonstige 'smarte' Komponenten) im Einsatz. Das Nachbarhaus über die Straße ist locker 25 m von meinem Koordinator entfernt plus mind. 2 dicke Außenwände und kleine Fenster. Ich habe ja schon Empfangsprobleme mit Sensoren, die ich selbst außen "nur" 4-5 Meter von der Hauswand entfernt platziert habe.Ich werde aber tatsächlich bei Gelegenheit mal nachfragen. Das interessiert mich schon. Auch wenn ich es für unwahrscheinlich halte, da sie m.W. auch komplett Fußbodenheizung haben und somit ebenfalls keine Verwendung für ein Heizkörperthermostat hätten.
Aber mal angenommen das wäre so: In welchen Fällen konnte sich ein fremdes Gerät mit meinem Netzwerk verbinden? So selten und kurz, wie ich den Pairing-Modus aktiv habe. Noch dazu: Wie kommen mir völlig unbekannte Namen in die 'LocalOverrides.json'? Ich habe es so verstanden, dass dort nur selbst vergebene Namen landen.
Edit: Habe gerade mal nach ME167 und TRVZB gegoogelt. Das sind ja offensichtlich auch alles Heizkörperthermostate. Also mind. 3 verschiedene, die mal bei mir drin waren.
-
@arteck
Ausschließen kann ich es nicht - halte es aus persönlicher Erfahrung mit der Zigbee-Reichweite doch für sehr unwahrscheinlich. Mein direktes Nachbarhaus hat definitiv keine Zigbee-Geräte (oder sonstige 'smarte' Komponenten) im Einsatz. Das Nachbarhaus über die Straße ist locker 25 m von meinem Koordinator entfernt plus mind. 2 dicke Außenwände und kleine Fenster. Ich habe ja schon Empfangsprobleme mit Sensoren, die ich selbst außen "nur" 4-5 Meter von der Hauswand entfernt platziert habe.Ich werde aber tatsächlich bei Gelegenheit mal nachfragen. Das interessiert mich schon. Auch wenn ich es für unwahrscheinlich halte, da sie m.W. auch komplett Fußbodenheizung haben und somit ebenfalls keine Verwendung für ein Heizkörperthermostat hätten.
Aber mal angenommen das wäre so: In welchen Fällen konnte sich ein fremdes Gerät mit meinem Netzwerk verbinden? So selten und kurz, wie ich den Pairing-Modus aktiv habe. Noch dazu: Wie kommen mir völlig unbekannte Namen in die 'LocalOverrides.json'? Ich habe es so verstanden, dass dort nur selbst vergebene Namen landen.
Edit: Habe gerade mal nach ME167 und TRVZB gegoogelt. Das sind ja offensichtlich auch alles Heizkörperthermostate. Also mind. 3 verschiedene, die mal bei mir drin waren.
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Aber mal angenommen das wäre so: In welchen Fällen konnte sich ein fremdes Gerät mit meinem Netzwerk verbinden? So selten und kurz, wie ich den Pairing-Modus aktiv habe. Noch dazu: Wie kommen mir völlig unbekannte Namen in die 'LocalOverrides.json'? Ich habe es so verstanden, dass dort nur selbst vergebene Namen landen.
Das ist nicht zu 100% richtig.
Vor den
LocalOverrides.jsonin denen deutlich mehr gespeichert werden kann als nur Namen gab es schon eine DateidevNames.json. In diese wurde der Name des Gerätes direkt beim Pairing eingetragen - sprich selbst wenn der Name nicht manuell verändert wurde gab es einen Eintrag in dieser Datei.Beim Update auf 2.x wurde diese Datei eingelesen und dann in die LocalOverrides.json übertragen. Sprich die Geräte waren vor dem Update auf 2.x mal in deinem Netz.
A.
-
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Also mind. 3 verschiedene, die mal bei mir drin waren.
ja was den jetzt ..
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Und dabei habe ich gar keine smarten Thermostate im Haus (und Zigbee schon gar nicht) und habe ich auch nie besessen.
hatte ..hat.. werde haben... vielleicht..
was den nu???
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Also mind. 3 verschiedene, die mal bei mir drin waren.
ja was den jetzt ..
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Und dabei habe ich gar keine smarten Thermostate im Haus (und Zigbee schon gar nicht) und habe ich auch nie besessen.
hatte ..hat.. werde haben... vielleicht..
was den nu???
-
@arteck
Falls ich mich wirklich missverständlich ausgedrückt habe:- mind. 3 der mir unbekannten Geräte in meiner Zigbee-Konfig sind Heizkörperthermostate
- ich besitze aber weder Thermostate und hab auch nie welche bessen
@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
mind. 3 der mir unbekannten Geräte in meiner Zigbee-Konfig sind Heizkörperthermostate
ich besitze aber weder Thermostate und hab auch nie welche bessenMindestens eine der Aussagen ist falsch.
Von alleine kommen die Geräte nicht in Dein Netz. Und da es sich bei den Geräten um TuYa Geräte handelt ist nicht einmal mehr sichergestellt das es sich um Heizkörperthermostate handelt - Sie haben sich halt nur mit den ID's von Heizkörperthermostaten gemeldet. Such mal unter https://www.zigbee2mqtt.io/supported-devices/ nach 'ts0601' und schau Dir an wie viele doch sehr wenig gleiche Geräte da gelistet werden - die alle melden sich initial als TS0601 - Erst durch Fingerprinting lassen die sich exakt identifizieren. Daher ist die Folgende Situation nicht unwahrscheinlich:
- Jemand kauft ein TuYa Gerät
- Er versucht dieses mit dem Netzwerk zu verbinden - das klappt auch, aber das erkannte Gerät und das gekaufte Gerät passen nicht zusammen (kein passender fingerprint)
- Er nimmt das Gerät aus dem Netzwerk und schickt es zurück.
In diesem Fall verbleibt ein Eintrag in derdev_names.json(Absichtlich - die Datei dient ja gerade dazu das ein Gerät basierend auf seiner IEEE auch dann den gleichen Namen bekommt wenn ansonsten alles zurück gesetzt wurde.
Wenn man das mit betrachtet erscheint es unmöglich im Nachgang zu klären welches die falsche(n) Aussage(n) ist(sind).
Sicher ist:
- Irgendwann haben sich Geräte mit den entsprechenden IEEE während des Pairings mit Deinem Netzwerk verbunden und sind entsprechend in der Shepherd.db (und nachfolgend der devnames.json) eingetragen worden. Zu diesem Zeitpunkt muss es auch die Objekte gegeben haben.
- Diese Geräte wurden wieder aus dem Netzwerk entfernt - entweder manuell durch einen Bediener oder durch eine
device leaveNachricht vom Gerät selber.
Zum Thema Reichweite, Funknetz und so weiter:
- Insbesondere bei Sensoren die mit Knopfzellen betrieben werden ist oft die Sendeleistung besonders gering um die Lebensdauer der Batterie zu erhöhen
- 2.4 GHz Funkwellen können durch Reflexion / Schwebung erstaunliche Reichweite erreichen - teilweise abhängig vom Wetter, von geparkten Autos oder anderen Effekten.
- Die Geräte können Zeitweilig irgendwo vorhanden gewesen sein (zum Test, o.ä.)
letztendlich bezweifle ich dass du dem wirklich auf den Grund gehen kannst. Was ich anbieten kann
Ab Version 3.1.x (wahrscheinlich 3.1.3, ggf. 3.1.2) kann der Adapter die Datenpunkte
Zigbee.0.info.devicecountundZigbee.0.info.groupount(beide neu, gibts aktuell noch nicht) befüllen, so das du einen Zeitlich zum hinzugefügten Device passenden Trigger bekommen kannst. Diese beiden DP werden aktualisiert:- bei jedem Start des Adpaters
- Wenn der Adapter ein neues Gerät einbindet
- Wenn der Nutzer ein Gerät(eine Gruppe) im Adapter löscht
- Wenn ein Gerät via
device_leavedas Netzwerk verlässt. - Wenn der Nutzer eine Gruppe hinzufügt.
Dabei wird nicht garantiert das die Aktualisierung genau den Zeitpunkt trifft wo ein Gerät dem Netz beitritt - es wird der Zeitpunkt genommen an dem der Adapter dieses bemerkt. Und auch da ist es denkbar das zumindest am Anfang nicht alle Möglichkeiten dazu sauber erkannt werden.
A.
-
Ich weiß zwar nicht genau wann, da ich's nun nicht mehr täglich beobachtet habe. Muss aber aber erst vor kurzem passiert sein: Das 'undefined' Gerät mit ieee 0x0x28dba7fffe741692 ist wieder da! Ich habe seit meinem letzten Post kein Pairing aktiv gehabt. Ich kann's mir beim besten Willen nicht erklären...
-
Hallo @Asgothian, Hallo @arteck
HILFE! Ich glaube es nicht: Ich habe jetzt seit ein paar Wochen den Adapter nicht angefasst, keine neuen Zigbeegeräte angeschafft und auch keine vorhandenen neu gepairt. Und trotzdem habe ich nun zusätzlich drei neue unbekannte Koordinatoren und einen "fremdländischen Stecker" im System.
Wo kann das nur herkommen? Was kann ich nur noch tun, um das künftig zu verhindern? Netz mit neuer Konfig (IDs, Key, usw.) neu aufbauen? Koordinator tauschen?
-
- Welche Adapter version hast du installiert ?
- kannst die aktuelle GitHub Version installieren - da sind ein paar relevante Anpassungen drin.
Danach solltest Du den folgenden Weg gehen:
- die nicht vorhandenen Geräte aus dem Netz Löschern (mit zwingen)
- in die Konfiguration gehen und nur das Zigbee netz anhalten (siehe Screenshot) - abwarten bis es wirklich angehalten ist! (Bild)
- Dann den Adapter anhalten und wieder starten.
Danach sollten sie erst einmal sicher weg sein, und sich auch nicht wieder anmelden können.
A.
Wenn das nicht hilft musst du das gesamte Netz neu aufbauen:
- alle Geräte nacheinander aus dem Netz werfen bis es leer ist
- Netz anhalten wie oben
- Hard Reset durchführen (der 5. Button in der Button-Reihe)
- eine neu PanID und extPanID vergeben
- das Netz starten (wieder der Button mit dem Pfeil)
- alles neu anlernen.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
Hallo @Asgothian, Hallo @arteck
HILFE! Ich glaube es nicht: Ich habe jetzt seit ein paar Wochen den Adapter nicht angefasst, keine neuen Zigbeegeräte angeschafft und auch keine vorhandenen neu gepairt. Und trotzdem habe ich nun zusätzlich drei neue unbekannte Koordinatoren und einen "fremdländischen Stecker" im System.
Wo kann das nur herkommen? Was kann ich nur noch tun, um das künftig zu verhindern? Netz mit neuer Konfig (IDs, Key, usw.) neu aufbauen? Koordinator tauschen?
@bilberry Also ich würde das mit den Nachbarn nicht ausschließen. Ich sehe auch oft diverse Geräte meiner Nachbarn, mindestens einer hat eine WLAN-Tasmotasteckdose die verzweifelt nach jemanden sucht der diese Konfiguriert.
Mein zweiter heißer Tipp: Ich habe hier eine ganze Eurobox die ich mit "Zigbee + RF" beschriftet habe und in der ich allen möglichen Spielkram lagere den ich gerade nicht benutze. Da meldet sich auch ab und zu was heraus obwohl ich da nicht bewusst Batterien eingelegt oder den Plastikstreifen entfernt hatte.
Und manchmal sind es Geräte die man nicht als solches Erkannt hätte. Die Stehlampe z.B. hat auch ZigBee.
TS0601 Geräte habe ich übrigens auch eine Menge, bei mir sind das aber Thermometer/Hygrometer, zumeist mit LCD-Display -
-
Heute auf frische Tat erwischt!
Schon wieder ein (angebliches) Heizungsthermostat:
ieee:0x28dba7fffe741692
nwk:27820 (0x6cac)
model:TRVZBIst sogar noch erreichbar und ich könnte es steuern. Nimmt Werte an. Sonst wurden die Geräte ja immer als offline angezeigt.
EDIT:
muss gestern reingekommen sein: am 15.12.2025 um 9:03 Uhr
zigbee.0.info.pairingMessage:New device joined '0x28dba7fffe741692' model TRVZBDa war ich gar nicht zu Hause!
Mit den Angaben konnte ich auch mal das Log durchsuchen - ist zugleich der erste Zigbee-Eintrag des Tages:
-
- Hast du andere Sonoff Geräte im Zigbee Netz ? (Insbesondere Router) ?
- es ist schon auffällig das das Gerät trotz geschlossenem Netz dazu kommen konnte - da muss dem jemand die Verschlusselung 'gepetzt' haben.
Ich kann Dir eine Sonder-Version bauen, die Geräte die ein Interview bei geschlossenem Netz versuchen hart aus dem Netzwerk wirft - incl. force. Dauert aber bis zum Wochenende.
A.
-
Hallo @asgothian, vielen Dank für Dein Angebot - das weiß ich sehr zu schätzen! Du machst bereits tolle Arbeit für die ganze Community. Bitte investiere nicht noch Zeit in eine Sonderlösung nur für mich allein.
Da ich offenbar der einzige mit vergleichbarem Phänomen bin, sollte ich die Ursache auch in meiner Umgebung finden und beheben.Ich habe nur einen Router im Netz und bin mir inzwischen ziemlich sicher, dass die Fremdgeräte von Außerhalb kommen. Wahrscheinlich muss ich mich da auch an die eigene Nase fassen!
Die ExtPanID habe ich ziemlich sicher mal bei einem Netzumbau geändert. Bei PanID und TransportKey bin ich mir nicht so sicher. In der naiven Annahme, ich sei der einzige "Nerd" in meiner unmittelbaren Wohngegend, hab ich dem bislang wenig Beachtung geschenkt. Falls die wirklich noch auf Standard-Werten stehen, könnte sich das nun rächen und wäre eine plausible Erklärung.Kannst Du mir bitte noch mal kurz erklären (oder Link schicken) für welche Funktion welcher der drei Schlüssel relevant ist? Möchte das gern besser verstehen.
-
Vielen Dank für das Verständnis - allerdings ist da ggf. ein generelles Problem, wesegen ich trotzdem darüber nachdenke die Option zum Ausschluss von solchen Geräten einzubauen.
Zum Thema Schlüssel - es gibt 3:
PanID - ein 16 bit Wert der ähnlich zur SSID von WLAN benutzt wird. Dieser wird zwischen allen Geräten im Netzwerk geteilt.
ExtPanID - ein 128 bit Wert der parallel zur PanID benutzt wird. Dieser wird oft von der Hardware-ID des Koordinators abgeleitet, so das nur die PanID 'user configurable' ausgeführt werden muss
Transport Key - ein 128 bit Wert, der die eigentliche Netzwerkverschlüsselung darstellt. Dieser war in der Anfangszeit des Adapters mit einem festen Wert vorgegeben und wurde eigentlich von niemandem angepasst. ich denke das hier auch für Deinen Fall der Schlüssel versteckt ist - offensichtlich war das TRV mit einem legacy Zigbee Netzwerk (Zigbee Adapter oder Zigbee2mqtt.io vor version 1.33) verbunden und hat damit die Verschlüsselung gespeichert. Damit kann das Gerät prinzipiell mit dem Netzwerk kommunizieren / die Netzwerknachrichten lesen. Das es in den Pairing modus geht und das an den Koordinator meldet ist aber entgegen der Spezifikation. Siehe auch hier: https://www.zigbee2mqtt.io/advanced/zigbee/03_secure_network.htmlA.
-
- Welche Adapter version hast du installiert ?
- kannst die aktuelle GitHub Version installieren - da sind ein paar relevante Anpassungen drin.
Danach solltest Du den folgenden Weg gehen:
- die nicht vorhandenen Geräte aus dem Netz Löschern (mit zwingen)
- in die Konfiguration gehen und nur das Zigbee netz anhalten (siehe Screenshot) - abwarten bis es wirklich angehalten ist! (Bild)
- Dann den Adapter anhalten und wieder starten.
Danach sollten sie erst einmal sicher weg sein, und sich auch nicht wieder anmelden können.
A.
Wenn das nicht hilft musst du das gesamte Netz neu aufbauen:
- alle Geräte nacheinander aus dem Netz werfen bis es leer ist
- Netz anhalten wie oben
- Hard Reset durchführen (der 5. Button in der Button-Reihe)
- eine neu PanID und extPanID vergeben
- das Netz starten (wieder der Button mit dem Pfeil)
- alles neu anlernen.
A.
Hallo @asgothian
Brau'mal bitte dringed Deine Unterstützung bei Wiederaufbau.
@Asgothian sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:
Wenn das nicht hilft musst du das gesamte Netz neu aufbauen:
alle Geräte nacheinander aus dem Netz werfen bis es leer ist Netz anhalten wie oben Hard Reset durchführen (der 5. Button in der Button-Reihe) eine neu PanID und extPanID vergeben das Netz starten (wieder der Button mit dem Pfeil) alles neu anlernen.Hab nun alles gelöscht. Wenn ich das Netz anhalte, lässt sich der Reset-Button nicht anklicken. Ist das ein Fehler? Wie kann ich die PanID und extPanID vom Stick zurücksetzen?
Support us
694
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge