Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[arteck]

@Geko-Eder da ist noch einer... schau dir mal die cpu zeiten an

geht an alle ... bitte..zwecks vergleich

[Geko Eder]

@arteck sry, aber wie meinst du? Im IOBroker selbst sieht die Auslastung ok aus. Im Vergleich scheint die Memory Consumption höher zu sein als mit dem alten ZWave. Dazu müsste ich aber nochmal umschalten um das zu sehen.
Du siehst noch Ausfälle oder wie meinst du das?
Bei mir gingen keine Kommandos mehr über ZWave an meine Fibaros. Konnte einen Wert im Object setzen, hat aber nichts bewegt und der Wert wurde danach auch gleich "rot". Das hatte ich aber jetzt mit der 1.6.1 nicht mehr. Bisher war das immer noch am selben Tag.

[arteck]

@Geko-Eder ich meine schau dir die CPU Auslastung des Adapter an in den console..

[AlCalzone]

@arteck Das müsste aber auch vorherige Versionen betreffen - nicht nur 1.6.1.

@Geko-Eder Ich glaube das ist Zufall. Die Änderungen, die das beheben sollten, sind noch nicht im master Branch angekommen und damit noch nicht released.

[Geko Eder]

@AlCalzone ok danke, weisst du schon wann du sie reinbekommst? Ich habe die logs auf jeden Fall mal laufen. Es geht bisher immer noch sehr gut.

[Geko Eder]

@AlCalzone Jetzt habe ich gerade das erste Problem wieder: Objekt wird auf den anzufahrenden Wert gesetzt, bleibt aber auf dem vorherigen "hängen":

Fährt aber noch zur angegebenen Position = 0. Log sieht gut aus:

Interessanterweise gehts bei einem anderen Shutter noch problemlos. Soweit mal zur Info. Wenn du noch was wissen müsstest sag bescheid.

[arteck]

@Geko-Eder ach den hab ich auch... gut das du es sagst

[AlCalzone]

@Geko-Eder sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.0 / 1.6.x):

bleibt aber auf dem vorherigen "hängen"

Würde ich mir mal im Log anschauen. Dazu die Node-Nummer bitte

[Geko Eder]

@AlCalzone Hier das Log vom betreffenden Zeitpunkt. zwave2_log.txt
Node9 ist die betreffende Node gewesen.

[AlCalzone]

@Geko-Eder Bitte nicht den ioBroker-Log, sondern wie hier beschrieben: https://forum.iobroker.net/post/479513

[AlCalzone]

Version 1.6.2 ist unterwegs mit einem Fix speziell für @arteck
In großen Netzwerken sollte die CPU-Last jetzt deutlich geringer ausfallen.

[Geko Eder]

@AlCalzone sry for being a Noop So, habe gewartet bis es wieder aufgetreten ist. Node ist: zwave2.0.Node_009zwave-17204.log
Hatte jetzt gerade wieder dasselbe, Werte bleiben rot, shutter fährt aber noch korrekt.

[AlCalzone]

@Geko-Eder Ok so 100% kann ichs noch nicht nachvollziehen. Im Log (letzter Schaltvorgang) sehe ich folgendes:

• 16:20:27.858 - Du stellst den Zielwert 20 ein
• 16:20:27.941 - Das Gerät bestätigt und sagt, es dauert noch ca. 17 Sekunden
• 16:20:27.943 - Adapter fragt den aktuellen Zustand an
• 16:20:28.213 - Antwort vom Gerät: Zielwert 20, aktueller Wert 28, dauert doch nur noch 2 Sekunden.
• 16:20:30.851 - Update vom Gerät: fertig
• 16:20:30.853 - Adapter fragt den aktuellen Zustand an
• 16:20:30.988 - Antwort vom Gerät: Zielwert 20, aktueller Wert 20

Wenn das dein letzter Schaltvorgang war heißt das, die Daten kommen zumindest an. Die Frage ist jetzt, warum sie nicht in ioBroker als bestätigt angezeigt werden.

[Geko Eder]

@AlCalzone Danke, ja genau. Ich hab am Ende ein paar mal geschaltet, der Wert blieb aber immer gleich. Wie gesagt, die Signale kommen an, nur iobroker bekommt/kann das Update nicht verarbeiten. Es funktioniert aber noch, es war aber in den vorigen Versionen so, dass auch das steuern nicht mehr geklappt hatte. An was liegt denn das? Du meintest ja du hättest es noch nicht eingebaut in die neue Version, wüsstest aber woran es liegt?

[AlCalzone]

@Geko-Eder Der bisherige Kommunikations-Code verwendet eine Vielzahl von überlappenden Timeouts und Bedingungen mit diversen Ausnahmen, um den Nachrichtenfluss zu steuern. Das hat in der Vergangenheit schon öfters dafür gesorgt, dass doch ein Zustand eingetreten ist, den ich nicht bedacht hatte.

Teil meines erwähnten Umbaus ist es, diesen auf sogenannte State-Charts umzubauen, hier ein einfaches Beispiel:

Damit befindet sich der Treiber jederzeit in einem definierten Zustand mit definierten Auslösern für Zustandsübergänge und sollte damit nicht mehr stecken bleiben.
Allerdings hängt es noch daran, dass der Zustand der Geräte, den der Adapter braucht, um zu steuern mit welchem Gerät gerade kommuniziert wird, noch nicht korrekt aktualisiert wird. Ergebnis: er denkt immer nach 10 Sekunden, dass ein Node schläft, obwohl er gerade mit ihm kommuniziert hat. Sobald ich das auch noch habe, kann ichs veröffentlichen.

[AlCalzone]

@Geko-Eder Zurück zum eigentlichen Problem... Kannst du mal den Adapter aufs Loglevel Debug stellen und nochmal laufen lassen? Dann kann ich wenn es wieder passiert zwischen ioBroker-Log und ZWave-Log abgleichen. Nur zur Vorwarnung, das kann auch eine Menge Logs erzeugen.

[Harry94]

Guten Abend allerseits,

mein Z-Wave adapter hängt sich ja regelmäßig auf, (noch 1.5.0)
interessante Beobachtung hierbei ist dass die Skripe die ich mit meinem HeatIt Push-Button 8 (NODE 036) steuere weiterhin auslösen. Die Befehle kommen also an.
Evtl hilft das weiter?

zwave-11512.rar

[Esmax666]

@AlCalzone ok sorray anbei die dateien

zwave-7277.log zwave-4546.log zwave-4403.log zwave-4110.log zwave-1118.log zwave-30679.log zwave-27988.log zwave-25510.log zwave-24652.log zwave-20913.log zwave-17636.log

LOG2020-09-06.txt

und noch von gestern
LOG2020-09-05.txt

[Esmax666]

HAllo @_nico, @wykat und @Schlumpf,

ich habe gesehen das ihr Figaro rauchmelder haben.

Ich habe ein ABUS rauchmelder gekauft und es gibt sehr wenig infomationnen

Haben Sie auch die Attribute "Ready" und "Status"?
Was genau meint er mit diesen Informationen, ich konnte die Informationen im Handbuch nicht finden

Ist der figaro besser als ABUS? Er scheint mehr Informationen wie die Temperatur, Alarm aktiviert,... zu geben.

Danke

[Harry94]

@Esmax666
Die Datenpunkte ready und Status gibt es bei allen Nodes,

ready gibt wieder ob das interview abgeschlossen ist (wenn ich mich richtig erinnere)
Status kann z.b. awake, asleep oder dead sein.

Awake heisst der Aktor ist Wach, sollte bei Fest angeschlossenen Geräten immer der Fall sein.
Batteriebetriebene geräte können "schlafen" um Energie zu sparen und wachen nur auf um Informationen zu senden oder diese in bestimmten Abständen abzufragen (Wake-Up intervall). Die werden dann als asleep angezeigt.

Nodes die nicht mehr erreichbar sind werden als dead markiert.

Lg