Monatsrückblick Januar/Februar 2026 ist online!

[AlCalzone]

@Schlumpf ich weiß was los ist, Fix sollte heute Abend noch kommen.

Edit: v1.6.1 kommt in Kürze :)

[Schlumpf]

@AlCalzone was war es denn? (Für doofe bitte. :grin: )

Ach ja, neu einbinden, Cache leeren, Netzwerk heilen?

Gruß
Jan

[AlCalzone]

@Schlumpf Nix tun und warten. Wenns nicht besser wird, nochmal ein Log machen bitte :)

Das Problem:
Die BasicCC stellt eins der einfachsten Kommandos dar, welches einen Wert ohne Bedeutung schreiben und lesen kann. Was die Geräte daraus machen, ist ihnen überlassen.

Im vorliegenden Fall hat das Lock explizit angegeben, dass es die unterstützt - dann fragt der Adapter die Werte beim Interview ab. Jetzt hat das Gerät aber nicht geantwortet, der Adapter ging von einem Verbindungsproblem aus und hat das Interview abgebrochen. Beim nächsten Versuch das gleiche von vorne.

Irgendwo tief in den Spezifikationen (das sind weit über 1000 Seiten verteilt auf mehrere PDFs) hab ich dann gefunden, dass man in dem Fall davon ausgehen muss, dass BasicCC doch nicht unterstützt ist. Das bedeutet, der Adapter macht in diesem Fall unbeirrt weiter und entfernt die BasicCC von der Liste.
Das wäre im Anschluss an das Interview eh passiert, jetzt tut er es von vornherein.

[Geko Eder]

@AlCalzone Mit der Version 1.6.1 hatte ich bisher keinen Ausfall mehr. Mit dem 1.6 gabs den vor 2 Tagen noch. Bisher soweit fein - vielen Dank!!

[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.