Hallo zusammen
Ich habe hier ein zWave Netz welcehs schon seit Jahren mit weit über hundert Nodes läuft. Bis vor einigen Monaten hab ich es unter IPSymcon betrieben. Im wesentlichen ohne nennenswerte Probleme.
Seit der Umstellung auf HA (zWave JS UI) habe ich aber zwei Effekte welche ich aus all den Jahren davor nicht kenne.
Es gibt immer mal wieder längere Verzögerungen - bis zu etwa 10-15sec. Das tritt so alle 1-2 mal am Tag mal bei beliebigen Aktoren auf. Die Aktoren werden immer geschaltete, es wird kein Befehl vergessen, nur eben Verzögert. Hauptsächlich tritt dies auf wenn sie längere Zeit nicht angesprochen wurden also zb. in der Nacht oder am Morgen. Ist viel Betrieb im Netz so habe ich den Effekt nur ganz selten beobachtet.
Routen wurden natürlich schon neue aufgebaut, irgendwelche Nodes welche den Funkkanal “zumüllen” habe ich bis dato keine gefunden.
Logging habe ich natürlich aktiviert, bis dato aber noch nichts rauslesen können.
Bin mir daher auch gar nicht sicher ob es tatsächlich ein Zwave Problem oder ein allgemeines HA Problem ist.
Hardwareseitig hat sich im Netz nichts wesentliches getan, inkl. Gateway ist alles gleich wie schon seit Jahren. Habe auch testweise 3 verschiedene Gateways probiert (UZB, Aeotec GEN5 und GEN 9). Vorher hatte ich aber properitäres Gateway auf Razberry Basis.
Routen wurden natürlich schon mehrmals neu aufgebaut. Habe keine toten Nodes oder ähnliche Problemkinder.
Ab und an mal (sehr selten) schalten sich meine Schaltsteckdosen Plugs von selbst ab. Betroffen sind nur die Teile von NeoCoolcam. Ich habe keine Automationen auf den betroffenen Plugs. Sie dienen rein nur der Energiemessung. Auch das kannte ich von früher nicht, kein einziges mal ist das vorher passiert.
Irgendjemand eine Idee wo ich ansetzen könnte ? Insbesondere Problem #1 nerft gewaltig.
Langsam wird meine Frau ungeduldig, wäre echt gut wenn ich das über die Feiertage in den Griff bekommen würde.
Weder hier noch im englischen Forum hab ich von ähnlichen Beobachtungen gelesen.
schönen Dank für eure Meinung
Bernhard
Betreibe Z-Wave auch schon fast seit 15 Jahren. Home Assistant und Zwave JS UI seit gut 5 Jahren mit aktuell 92 Nodes und dem ZWA-2. Kenne solche Probleme aber nicht. Z-Wave war schon immer stabil und performant, außer in der Zeit mit homee! Auch zuvor mit dem Aeotec Gen5, den Gen7 wie auch mit der Z-Station keine Probleme gehabt.
Weil @vital555 das Thema Spock anspricht. Auch bei mir läuft Spook absolut unauffällig schon seit Jahren in friedlicher Koexistenz mit Z-Wave, ZigBee, EnOcen und Matter over Thread.
Was aber nicht heißen soll, dass er bei Dir zu Problemen führt.
Hast Du Dir mal die Protokolle angeschaut auch mal speziell mal die von ZwaveJS UI (ZwaveJS Control Panel)
Wenn Du von Verzögerung sprichst, treten diese auf, wenn Du Geräte in der Home Assistant APP schalten bedienen tust, oder wenn Automationen im Spiel sind?
Betrifft es ausschließlich Z-Wave Geräte oder auch andere?
Was nutzt Du gerade als Z-Wave Koordinator und mit welcher Firmware?
Servus @vital: Ich habe in der Tat Spook laufen. Werds mal abschalten, und sehen.
@oskorn: Auch hier war ich immer sehr zufrieden mit zWave. Von da her vermute ich die Probleme eher irgendwo auf HA oder zWave JS Seite.
Das log ist etwas widersprüchlich. Einerseits gibt es Meldungen wie
“Error while executing automation automation.lichtsteuerung_flur_unten: Unable to set value 15-38-1-targetValue: zwave_error: Z-Wave error 202 - Failed to send the command after 5 attempts (ZW0202)”
die eigentlich auf ein Netzwerkproblem hindeuten, andererseits wird das Licht IMMER geschaltet, verlorene Befehle wie es die Fehlermeldung suggeriert kann ich jetzt nicht nachvollziehen.
Das einzige was neue ist (zusammen mit HA gekommen) sind zwei Qubino Smartmeter. Und die sind tatsächliche seeehr geprächig. Das könnte evtl. erklären das hauptsächlich Räume betroffen sind bei denen am “weg dorthin” vorher andere Lampen geschaltet werden. d.h. die vorher geschalteten Lampen lösen eine Änderung im Stromverbrauch aus und triggern die Smartmeter zu reporten welche dann das Netz fluten und die Befehle zu meinen Problemraumen verzögern. Mal sehen, das läßt sich ja leicht abstellen, passt aber auch nicht zu allen Situationen wo es zickt.
Auffällig ist es hauptsächlich wenn über Automationen geschaltet wird. Händisch schalte ich so gut wie nie. Leider kann ich die lags nicht bewusst herbeiführen. Wenn ich händisch (per GUI) schalte klappt es immer, läufe ich durchs Haus UND war vorher eine längere Pause - so gibt es gerne die Verzögerung.
Achja, Firmware is auf allen Gateways die akuelste, das hab ich natürlich gleich als erstes geprüft.
Das werden auch die Übeltäter sein. Wenn Du diese vom Netzt nimmst, wird der Spook wieder vorbei sein.
Du solltest dann die Frequenz der reportings anpassen.
Ich hatte auch zwei Devolo Steckdosen die Amok gelaufen sind. Diese musste ich ich entsorgen.
Nicht wirklich. Home Assistant versucht das Geräte zu schalten, bekommt aber wiederholt keine Antwort, ob das auch erfolgreich war. Die Befehle hängen nämlich in der Warteschlange auf Zwavejs Seite, diese wird erst mit Verzögerung abgearbeitet.
EDIT:
Wie hast Du die Smart Meter inkludiert? Secure oder unsecure?
Wenn S2 nicht unterstütz wird, inkludiere diese Unsecure. S0 verursacht zusätzlich traffic und ist nicht zu empfehlen
Wollte mal Bescheid geben wie es weiterging.
Das Gute vorweg, alles läuft wieder, seit vier Tagen kein einziger Hänger - Frau glücklich, ich auch.
zzt. ist war auch Spook disabled ich denke aber eher das das Problem an einem vergessenen Node lag.
Im Log fand ich einen Bewegungsmelder welcher bei ansprechen immer versuchte eine Security Verbindung aufzubauen. zWave JS war er aber als ohne Security eingetragen und so ging das einige Zeit hin und her bis dann das Gateway rebootete. Ich hatte ganz bewußt immer ohne Security includiert, k.A. warum es sich der blöde Sensor anders überlegt hatte.
Das gemeine war das er gar nicht mehr gebraucht wurde, weil an der Stelle schon ein ESP basierender Präsenzmelder Dienst tut. So viele es nicht auf das er nicht funktionierte. Er hing auch nur noch unjustiert blöd rum und so sprach er auch oft gar nicht an.
Hoffe echt das bleibt jetzt so. Mit der Wiederinbetriebnahme von anderen Verdächtigen (und Spook) warte ich aber noch etwas, da muß bei meinen Mädels noch etwas Gras über die Sache wachsen.
Hast Du Assoziation in BM verwendet, zu einen secure inkludierten Gerät?
In dem Fall Unsecure zu Secure. Bei Assoziationen zwischen Geräten, musst Du drauf achten, dass diese beide unsecure oder beide Secure inkludiert sind.
Was das Thema secure oder unsecure angeht. S0 würde ich wenn möglich vermeiden.
Wenn kein S2 unterstütz wirdt, dann dann nur unsecure includieren. Hintergrund ist, dass S0 zusätzlichen Traffic verursacht und bei vielen Geräte, vor allem Sensoren, die oft Daten senden zu Problemen führen kann.
Dann drücke ich Dir mal die Daumen, dass Du den Übeltäter überführen konntest.
Servus
Bis auf die Danalock (der geht nicht anders) ist alles konsequent unsecure inkludiert. Das war auch früher schon der Schlüssel zum Erfolg. Man tut sich auch leichter wenn man bei Problemen mal den Sniffer anwirft. Wenn secure siehst gar nix, unsecure kanns alles tracen und ggfl. in Klartext rückwandeln. Hatte in den Anfangszeiten einige China gen 300 Nodes. Die Gedankengänge der Firmwareentwickler konntest nur auf HEX Ebene verstehen _ und die Teile dann entsorgen.
k.A. warum der eine BW (von Fibaro) plötzlich dachte er hat Secure, und dann noch dazu das Gateway crashte.
Naja, im nächsten Leben gibts sowieso nur mehr KNX, im Altbau ist halt nicht so einfach überall Kabel zu legen.
.