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

[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

[AlCalzone]

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

Haben Sie auch die Attribute "Ready" und "Status"?

Ich habe dir diese Frage hier doch schon mehrfach beantwortet. Was ist denn noch unklar?

Das Interview kann sich bei batteriebetriebenen Geräten ziehen, gerne auch mal Stunden bis Tage. Erst danach ist ready = true und alle Daten da.

[Mojito Joe]

Bin mir nicht sicher, ob ich in diesem Thread richtig bin:

Habe gestern den Aeotec Z-Stick Gen5 und als erstes ZWave-Gerät überhaupt ein batteriebetriebenes SmartLock von ABUS (CFA3010) installiert. Dazu habe ich zuerst den zwave2 Adapter verwendet.

• Der Stick wurde mir sofort erkannt und in der Adapter-Instanz als Device angezeigt. Das SmartLock wurde nach Inklusion ebenfalls in der Device-Liste geführt.
• Als Datenpunkte wurden mir einige unter "Objects" angezeigt - unter anderem auch "Door_Lock" (oder so ähnlich).

Leider konnte ich keinen Konfigurations-Datenpunkt finden unter dem ich die Parameter aus der Anleitung (siehe auch hier) finden. Auch war/ist mir nicht klar, wie ich das Schloss steuern soll, da Änderungen an den Datenpunkt-Werten keinen Effekt hatte.

Deshalb habe ich den zwave2-Adapter deinstalliert und es stattdessen mit dem zwave-Adapter versucht. Damit wurden mir aber kaum Datenpunkte unter Objects angeboten. Somit bin ich wieder zurück zum zwave2-Adapter gewechselt. Der Stick taucht nach Installation und Erstkonfiguration wieder unter Devices auf, doch nach vom Schloss visuell bestätigter Inklusion des SmartLocks taucht dieses nun nicht mehr unter Devices auf. Auch die bei der ersten Adapterinstallation noch angezeigten Datenpunkte sind nun nicht mehr vorhanden - selbst 16h nach Inklusion.

Zusammenfassung:

• SmartLock taucht nach Inklusion nicht mehr - wie beim ersten Versuch - in Device-Liste auf
• Ursprünglich (beim ersten Versuch) angezeigte Datenpunkte nicht mehr vorhanden
• Von Anfang an fehlende Datenpunkte (Grund für die ganze Adapter-In/Deinstallation) bzw. wo können in IOBroker überhaupt Parameter von zWave-Geräten konfiguriert werden?.

Ich habe den Adapter soeben neu gestartet und hänge mal das detaillierte Log hier an. Bei dem SmartLock handelt es sich um Node_003.
zwave-27366.log