Hallo
Bin mal wieder dabei im Zwave Netzwerk zu debuggen.
Dabei stoße ich immer wieder auf Logs mit ähnlichem Muster:
In regelmäßigen Abständen kommen von vielen Nodes mehr oder weniger zugleich Statusmeldungen rein.
Während die Meldungen empfangen werden will IPS zeitgleich an andere Nodes Daten schicken.
Dies geht dann schief.
Logisch das beides zugleich nicht geht, aber sollte das nicht durch diverse Queue oder Buffer abgefangen werden ?
Was ich auch sehe ist, das wenn Daten an einen Node gesendet werden sollen, dies aber fehlschlägt, dann ist gehen auch unmittelbar nachfolgende Sendeversuche zu anderen Nodes schief.
Während dieser Zeit können aber Daten von wieder anderen Nodes empfangen werden. d.h. der Funkkanal als solches ist vermutlich nicht gestört.-
Auch das riecht doch nach Queue/Buffer Problemen. Wobei ich ehrlich gesagt keine Ahnung habe welchen Anteil das Gateway oder IPS daran haben.
evtl. ist auch FLIRS das Problem. zzt. beschreibe ich die recht häufig (Heizungsventile) und da sehe ich das vermehrt.
Hab hier mal ein exemplarisches Log rausgesucht.
IPS Logfile:
Gesendet wird im Script 21776 an die Nodes 224 und 72
Wäre echt toll, wenn sich an den verschiedenen Problemen von Z-Wave was verbessern lassen würde.
Ich kaufe schon keine neuen Z-Wave Geräte mehr und bin am überlegen, welches System ich stattdessen verwenden möchte.
Habe aktuell noch so um die 60 Geräte im Einsatz.
Und wenn man dann noch so Geräte von Namenhaften Herstellern bekommt, welche mit einem Bewegungsmelder das komplette Z-Wave Netzwerk lahm legen, dann kann es einem schon vergehen
Ich muss sagen, dass ich auch schon ziemlich am Verzweifeln war aber mir vor allem zwei Dinge geholfen haben:
Ich habe mir einen Zniffer USB stick zugelegt, das hat ca. 35 EUR gekostet. Damit sieht man, wo es zu Staus und schlechtem Routing kommt.
Das zweite sind APRs (seit Symcon 6.3 IIRC). Damit sorge ich dafür, dass der Traffic möglichst direkt geht.
Aber ich gebe Euch Recht, erwas meht Übersicht über die Queue zwischen IPS und Controller wäre schön, ähnlich wie das z.B. zway macht
Naja,
grundsätzlich läuft das zWave (etwas um die 130Nodes) schon sehr gut zuverlässig. Bin soweit sehr zufrieden. Liegt wohl auch an einigen Workarounds und Fallbacks die ich mir im Laufe der Zeit so eingebaut habe.
Nur wenn man in die Tiefe blickt findet doch so einige Unzulänglichkeiten. - wie eben die im Eingangspost. Wobei ich in diesem Fall nicht beurteilen kann ob in diesem Fall IPS oder das Gateway der Verursacher ist.
An anderen Stellen ist es wohl eindeutig IPS. Habs ja auch schon immer mal wieder angemeckert. bspw. die Timeouts und das oft nicht nachvollziebbare Verhalten der Konsole beim An und ablernen von Nodes. (Die alte Konsole hatte das Problem übrigens nicht).
Ein weiters Problem ist die strikte Kopplung an diese CD-Jackson Datenbank. Wenn da was nicht stimmt oder die Firmware der Nodes etwas anders regiert als in der Datenbank hinterlegt gibts Knatsch. Ok, das ist kein primäres IPS Problem, IPS könnte aber entsprechende Workarounds anbieten.
Ja und das mit Security angelernte Nodes zicken liegt ggfls. auch an IPS. Weil in anderen Foren liest man nix davon. Da ist das Thema gar nicht existent.
Unterm Strich bin ich trotzdem zufrieden und es gab ja auch immer mal Verbesserungen. Aber wie gesagt, es ist auch noch genug Luft nach oben. Insbesondere wenn man etwas genauer hinschaut.
Ist vielleicht etwas offtopic, aber habt ihr schon mal überlegt z-wave via zwave-js-ui und mqtt einzubinden?
Ich hab jetzt nicht viel z-wave bei mir im Haus aber die IPS implementierung hat mich schon einiges an zeit und nerven gekostet. Zumal funktionen die ich bräuchte (temperatur senden, bbernhard kennt das problem) nicht unterstützt werden. Ich verstehe auch, dass das nicht die Top Prio ist aber nervig ist es schon. Immerhin ist die Z-Wave Unterstützung eine Kernfunktionalität in IPS. Ich hab HomeAssistant noch nie benutzt aber ich hatte dort über z-wave-js-ui alles in wenigen minuten am start. Ich hab nur leider kein Plan von Docker sonst hätte ich es schon versucht.
Na ja, so off-topic ist es gar nicht. Es wäre ähnlich wie Zigbee eine valide Möglichkeit die Geräte anzubinden und einige der Features (automatische Backups, Firmware-Updates) werden vermutlich so schnell auch nicht in IPS landen.
Soweit ich das sehen kann kann man zwave-js-ui ja auch über Snap installieren, da muss man nicht unbedingt mit Docker anfangen.
Es gibt ja auch noch eine alternative IPS Anbindung über das Fibaro Homecenter.
Ehrlich gesagt bin ich bei solchen Lösungen immer etwas zwiespältig. Je komplexer sie sind, desto mehr Probleme kann es geben und desto mehr kann auch kaputtgehen. Darum forciere ich native möglichst direkte Lösungen ohne allzu viel IT rumgehampel. Auch wenn es technisch weniger geil ist, unterm Strich es ist es einfach robuster und benötigt weniger Wartung.
Spass beiseite, ich verstehe deinen Einwand und das ist natürlich auch immer eine Glaubenssache. Aber vom Prinzip ist zwave-js einfach nur ein Gateway das dir über ein standardisiertes Protokoll (MQTT) eine Steuerung von Z-Wave erlaubt. Das auf einem Raspi mit einem minimalen OS und schon hättest du ein fertiges „Produkt“ mit einer WebGui. Jederzeit unabhängig vom IPS was eigentlich sogar die stabilität/wartbarkeit,… des Gesamtsystems (dein Smarthome) erhöht (aber natürlich dafür andere probleme schafft).
Soll jetzt aber keine Grundsatzdiskussion geben, jeder darf da seiner Ansicht sein und hat damit genau so unrecht wie ich
Lange rede kurzer Sinn, ich werd mir das für meine paar Geräte mal anschauen. Anscheinend läuft es sehr zuverlässig und wenn ich damit ohne Umwege (aka Stellwertmodus und PID Regler) die Regelung verbessern kann dann versuch ich mal mein Glück. Besser oder Einfacher ist es wahrscheinlich nicht, nur anders.
So langsam wird es glaube ich doch ziemlich off-topic bezogen auf das Ursprungsproblem. @moderatoren Könnte einer bitte die Beiträge (ab dem den ich versehentlich gemeldet habe) in ein neues Thema „zwave-js-ui“ verschieben? Danke!
Ich hab es nämlich schon am laufen mit dem externen Temperaturwert an die Thermostate zu senden
Sorry: IIRC ist chat slang für If I remember correctly. Eventuell war es auch schon früher als 6.3
APRs sind Application Priority Routes. Damit kannst Du Nodes sagen, wie sie den Controller oder andere Nodes erreichen, bzw. Dem Controller wie er die Nodes erreicht.
Ich hatte z.B. eine direkte Assoziation von Dimmer1 auf Dimmer 2 und 3. Die Pakete liefen quer durchs Haus. Nach dem Setzen der Routen war es ein einzelnes Multicast Paket an beide.
)