seit einigen Tagen habe ich das Problem, dass mein Z-Wave Netzwerk sehr instabil ist und einige Geräte nur sporadisch erreichbar sind. Die Ursache ist mir noch unklar, aber eventuell sind die Geräte nun einfach zu alt.
Das Folge-Problem ist aber, dass ich meine Z-Wave Geräte über Events und Skripte ansteuere, welche dann jedoch nicht reagieren. Dadurch hängen sich die PHP-Threads auf und beenden sich nur nach Stunden wieder. Ich habe zwar bereits sehr viele Threads (1000) zur Verfügung gestellt, aber irgendwann sind eben auch diese aufgebraucht. Damit kann ich dann auch keine anderen Geräte mehr steuern, welche eigentlich noch funktionieren.
Ich finde es etwas ungünstig, dass man kein Timeout für die PHP-Skripte mehr definieren kann. Gibt es denn eine andere Möglichkeit, wie ich verhindern kann, dass sich die Skripte aufhängen, wenn ein Gerät nicht mehr so reagiert, wie es eigentlich soll?
Das ursächliche Problem ist natürlich klar und ich muss das Z-Wave Netzwerk reparieren. Es kann jedoch immer passieren, dass einmal Geräte kaputt gehen und dann darf das eigentlich nicht passieren.
Zeig doch mal den Inhalt der entsprechenden Scripte. Du könntest z.B. mit einer Semaphore arbeiten, die ein weiteres Starten eines Scripts erst erlaubt, wenn das vorherige abgelaufen ist.
@paresy: Das Z-Wave Gateway sieht für mich ok aus. So nach 25s, spätestens nach 30s sollte der Versuch ein Gerät anzusteuern aufgegeben werden. Die Threads hängen aber teilweise über Stunden fest.
@tobiasr: Viele meiner Skripte verwenden zwar bereits das Semaphore, aber einige Skripte sind generisch und werden von vielen Geräten verwendet. Hier muss die Mehrfach-Ausführung explizit möglich sein.
Ebenso hängen eigentlich alle Threads, welche die problematischen Geräte ansteuern. einigen habe ich auch über Workflows realisiert. Hier kann ich glaube gar keine Semaphores definieren. Hier mal ein Beispiel eines Workflows, welcher meine Z-Wave-Dimmer anhand von Bewegungsmelder-Daten steuert
Soweit ich es bisher eingrenzen konnte, hängen eventuell 2 meiner 33 Z-Wave-Geräte und sind sporadisch immer mal wieder nicht erreichbar. Diese lassen dann durch die Trigger der Bewegungsmelder die Threads voll laufen und anschließend können auch keine anderen Geräte mehr gesteuert werden.
Ggf. könntest du als Notfallmaßnahme den Bewegungsmelder etwas besser abfangen? So kann er nur schalten, wenn seine vorherige Schaltaktion auch sauber durchgeführt wurde. Ggf. über ‚letzte Änderung‘ oder ähnliches die Status-Variablen überwachen.
Insbesondere das Optimieren macht Ärger und ist unnütz. Das brauchst nur wenn du mal etwas am Netzwerk änderst. Im Normalbetrieb kann sich das Netzwerk ganz gut selbst reorganisieren und tut das auch.
Vor langer Zeit gab es beim Reorganisieren auch das Problem das ALLE Nodes angestoßen wurden. Das war aber Quatsch, weil Batterienodes antworten ja nicht. Es führte dann dazu das die Pipeline überquoll und eigentlich nix mehr ging. Ob das noch immer so ist weiß ich nicht. Weiters ist während reorganisieren der jeweilige Node&Gateway für einige Sekunden nicht ansprechbar. Sollen während dieser Zeit Daten übertragen werden bleiben die hängen und das Unglück nimmt seinen Lauf.
Weiters verstehe ich nicht warum bei dir PHP Threads wegen nicht erreichbarer Nodes hängenbleiben sollen. Hab hier weit über hundert Nodes aber keinerlei hängenden Threads. Und ich arbeite sehr viele mit Scripten.
1000Threads wie Eingangs erwähnt ist auch viel zu viel. Da ist ja schon der Overhead enorm. Hab 50 Threads und alles ist gut.
Ich glaube bei dir ist irgendwas anderes grundlegend faul.
Obs an den Workflows liegt ? k.A. die verwende ich nicht.
Also ich habe nun die letzten Wochen viel herumprobiert, die Z-Wave-Gateway-Konfiguration in vielen Varianten ausprobiert und diverse Skripte komplett deaktiviert. Es lässt sich nicht genau an einem defekten Z-Wave-Gerät festmachen, da immer wieder verschiedene Geräte vermeintlich nicht erreichbar sind. Wenige Stunden später funktionieren sie dann spontan wieder.
Das Resultat ist nun, dass ich nicht glaube, dass das Z-Wave-Netzwerk an sich das Problem ist, sondern vielmehr das Gateway, was herum spinnt. Da es sich um das Z-Wave-Gateway von Symcon handelt, möchte ich hier doch noch einmal @paresy um Hilfe bitten. Wie könnte ich das weiter debuggen? Und warum wird das Gateway bei euch im Shop nicht mehr angeboten?
Zusätzlich überlege ich aber auch, ob ich nicht das ganze Z-Wave-Zeugs bei mir rauswerfe und durch irgendetwas zuverlässigeres ersetzen sollte. Gibt es hierzu eventuell Vorschläge?
Morgen,
ohne dein Setup zu kennen glaube ich ehrlich gesagt immer noch das du dein Gateway bzw. den Funkkanal überlastest.
Hats du evtl. irgendwelche Scripts oder Funktionen laufen welche den Befehl wiederholen falls keine Bestätigung kommt ?
Oder dimmst du vielleicht in dem du mit mittels Schleifen Helligkeiten setzt ?
Oder pollst du permanent den Zustand von Geräten.
Oder versuchst du zig. Geräte gleichzeitig zu schalten ?
Oder … ?
Versuche die Last am Funkkanal so gering als möglich zu halten. Dann funktioniert das.
gruß
bb
Ist dir bewusst, dass es bei 868 MHz einen gesetzlich festgelegten Duty Cycle gibt und die Geräte nicht mehr als 1% der Zeit senden dürfen? Das betrifft alle Systeme in diesem Frequenzbereich, nicht nur Z-Wave.
Was du beobachtest könnte eine Zwangspause sein, wenn vorher zu intensive Kommunikation war. Du solltest also mal schauen, wieviel Datenverkehr dein Z-Wave Gateway hat und ob man das reduzieren kann.
Hallo,
sowas habe ich auch immer wieder mal. Bei mir ist es so, dass im Task-Manager manchmal die IPS-Symcon Management Console nicht geschlossen wird und dann mehrere Tasks bleiben. WEnn ich dann den Task abschiesse läuft es. Vielleicht ist das bei dir auch so
sieht aber genauso aus bei den PHP Treats wie bei mir letztes Jahr
wenn ich meinen Proxmox angesehen habe hatte der Prozessor nichts zu tun, aber die Abarbeitung der PHP Treats hing teilweise über fünf minuten hinterher
z.B Post 25
Die ipskonsole ist, vereinfacht gesagt, ein Anzeigetool. Hängende php threads sind aber module/scripte die, aus welchen gründen auch immer, unendlich laufen.
Beides hat nichts miteinander zu tun. Wenn dein php threads voll läuft muss man also die ursache in den scripten suchen. Gerne ist es ein curl oder shell befehl der nicht sauber abgefangen wird, bspw wenn ein gerät nicht erreichbar ist, aber dennoch immer wieder versucht wird.
