Monatsrückblick Januar/Februar 2026 ist online!

[AlCalzone]

@maloross Jeder "Bogen" in der Mitte stellt eine Verbindung zwischen Knoten dar. Die Größe der Knoten-Rechtecke skaliert mit der Anzahl der Verbindungen zu anderen Knoten.

Man sieht also folgendes:

• Node 6 scheint im Controller noch vorhanden, ist aber gar nicht verbunden (vmtl. tot)
• Nodes 9, 10, 11, 18 und 19 haben nur sehr wenige Verbindungen, ggf. rührt daher die Verzögerung.

Vielleicht hilft ja schon ein "Netzwerk heilen" auf der Geräteübersicht.

[maloross]

@AlCalzone

• Node 6 ist meine Leiche im Keller
• Node 9 + 11 sind weiter entfernt -> Garage und batteriebetrieben
• Node 10, 18 und 19 sind max. 4 m vom Stick entfernt in nebeneinander liegenden Räumen
• Heilung hatte ich auch durchgeführt -> keine Änderung

Welche anderen Apps oder Programme könnten Einfluss nehmen?

[arteck]

währe es nicht schöner wenn du so eine generieren könnest

das nutzen wir im zigbee..da sieht man direkt wer mit dem über wen redet

[maloross]

Alleweil macht's Fortschritte!

• Hatte auf dem Pi noch den z-way-server installiert -> deinstalliert + Neustart
• Im Adapter Cache geleert
• bis auf Node 10 - da hattest du schon darauf hingewiesen - wurden alle Geräte korrekt erkannt

Fibaro RGBW Controller: hier fehlt noch die Auswahl der Farben. Die voreingesteltten Lichtanimationen funktionieren

[AlCalzone]

@arteck Hatte ich anfangs mal mit gespielt. Sah damals hässlich aus, weswegen ich mich erst mal für die einfachere Variante entschieden habe. Wäre ggf. nochmal eine Überlegung wert.

[AlCalzone]

@maloross Super, dass es doch geht.

Wie meinst du das mit der Farbauswahl? Soweit ich das richtig im Hinterkopf habe, hat der 6 Kanäle, von denen 3-6 R, G, B, W entsprechen und 1-2 irgend einen Unsinn machen.

[maloross]

@AlCalzone
ja alles passt ich war etwas zu flott in der Objektansicht unterwegs. Alles funktioniert wie es soll, die von genannten Kanäle stimmen.
Diese Warnungen kamen gerade

(8379) Deleting orphaned state zwave2.0.Node_010.Binary_Sensor.water

zwave2.0	2020-01-16 14:55:48.422	warn	(8379) Deleting orphaned state zwave2.0.Node_019.Multilevel_Switch.currentValue
zwave2.0	2020-01-16 14:55:48.351	warn	(8379) Deleting orphaned state zwave2.0.Node_019.Multilevel_Switch.duration
zwave2.0	2020-01-16 14:55:48.276	warn	(8379) Deleting orphaned state zwave2.0.Node_019.Multilevel_Switch.targetValue
zwave2.0	2020-01-16 14:55:48.172	warn	(8379) Deleting orphaned state zwave2.0.Node_019.Basic.targetValue
zwave2.0	2020-01-16 14:55:48.091	warn	(8379) Deleting orphaned state zwave2.0.Node_019.Basic.currentValue
zwave2.0	2020-01-16 14:55:48.038	warn	(8379) Deleting orphaned channel zwave2.0.Node_019.Multilevel_Switch
zwave2.0	2020-01-16 14:55:48.026	warn	(8379) Deleting orphaned channel zwave2.0.Node_019.Basic

Die 1. Meldung betrifft den Phileo Wassersensor, die 2. Meldung den WallC-S Schalter. Funktionieren aber beide wie sie sollen

[AlCalzone]

@maloross Ja, die bekomme ich auch ab und an. Muss ich mir bei Gelegenheit mal in Ruhe anschauen, ob da zu viel gelöscht und dann wieder erstellt wird.

[maloross]

@AlCalzone ok, dann behalte ich das im Hinterkopf.
Ich finde deinen Adapter sehr gut, die Anzahl der Datenpunkte hat sich nahezu halbiert, die ID sind jetzt auch in der richtigen Reihenfolge.
Gibt es etwas, auf das besonders geachtet werden? Ansonsten bau ich meine Skripte jetzt um.

[Rolf_KA]

@maloross sagte in Test Adapter ZWave2 (v0.8.x):

Ich finde deinen Adapter sehr gut, die Anzahl der Datenpunkte hat sich nahezu halbiert, die ID sind jetzt auch in der richtigen Reihenfolge.

Deshalb liebe ich diesen Zwave2 Adapter von @AlCalzone so sehr, nicht nur weil er meinen Scene Controller ZHC5002 (habe jetzt schon 2 Stück davon) zum Leuchten gebracht hat, was über OpenZW einfach nicht möglich war :hugging_face:

Die restlichen Problem-Aktoren wird er auch noch hinbekommen, davon min ich überzeugt :+1:

[maloross]

@Rolf_KA sagte in Test Adapter ZWave2 (v0.8.x):

Die restlichen Problem-Aktoren wird er auch noch hinbekommen, davon min ich überzeugt :+1:

Das denke ich auch, ist schon ein cleveres Kerlchen :wink:

[AlCalzone]

:face_with_cowboy_hat:

[taba_luga]

@AlCalzone sorry, ich war gestern leider verhindert. Hier meine Cache Datei e64b94c3.json

[taba_luga]

@AlCalzone wenn ich den "targetvalue" = 80 setze, dann fährt das Rollo korrekt auf ca 80%. Der "current Value" wird leider nicht aktualisiert.

Auf dem Screenshot siehst du den "currentValue" = 19. Dieser Wert ist korrekt beim aller ersten Mal übernommen worden. Soll heißen, der Node 15 war das erste mal in deinem zwave2 Adapter sichtbar und es stand noch kein Wert in dem Datenpunkt "currentValue". Durch Bedienung des DP Down = true wurde das Rollo heruntergefahren. Down = false stoppte das Rollo bei 19%. Dieser Wert ist immer noch sichtbar. Danach gab es keinerlei Aktualisierung mehr. Das ist bei allen RollerShutter 3 Nodes der Fall gewesen. Das erste Mal klappt, danach nicht mehr.

[AlCalzone]

@taba_luga Danke schon mal für die Info.

Zu den fehlenden Datenpunkten: Ich schätze, da war das Interview nicht vollständig. Ich baue die Tage mal eine Möglichkeit ein, die Infos zu aktualisieren.

Das andere Problem hoffe ich zumindest teilweise mit der Supervision CC gelöst zu bekommen. Für Aktualisierung nach up/down fürchte ich muss Fibaro ein Firmware-Update liefern (wir werden es aber mal testen).

[Rolf_KA]

@taba_luga sagte in Test Adapter ZWave2 (v0.8.x):

wenn ich den "targetvalue" = 80 setze, dann fährt das Rollo korrekt auf ca 80%. Der "current Value" wird leider nicht aktualisiert.

Das gleiche Problem habe ich leider auch... aber @AlCalzone ist an der Sache mit dem RolllerShutter 3 wohl dran.
Aber alles braucht halt seine Zeit.

Wie ich oben schon geschrieben habe

echt schade das Fibaro den RollerShutter 3 gegenüber dem 2er so verkompliziert hat und dann noch den 2er vom Markt genommen hat 😞

Beim RollerShutter 2 war alles noch wunderbar in Ordnung und jetzt beim Nachfolger RollerShutter 3 nur noch Ärger...
Auch OpenZwave kämpft mit dem Ding rum :-(

[Rolf_KA]

@AlCalzone sagte in Test Adapter ZWave2 (v0.8.x):

Das andere Problem hoffe ich zumindest teilweise mit der Supervision CC gelöst zu bekommen. Für Aktualisierung nach up/down fürchte ich muss Fibaro ein Firmware-Update liefern (wir werden es aber mal testen).

Noch zur Info @AlCalzone zum RolllerShutter 3:

Ich habe festgestellt, wenn ich den targetValue Wert 2 x manuell eingebe, bei der zweiten Eingabe der currentValue Wert automatisch den targetValue Wert erhält - currentValue ist dann also mit dem TargetValue Wert identisch.

Wenn ich über einen Trigger den targetValue Wert 2 x setze (auch über eine Verzögerung) ändert sich currentValue aber nicht, nur bei händischer Eingabe bei targetVAlue im ioBroker.

[AlCalzone]

@Rolf_KA Ja das liegt daran, dass der sofort nach dem Setzen seinen derzeitigen Status reportet - aber nicht mehr wenn der Zielstatus erreicht ist.
Beim zweiten Setzen ist der Status dann ja schon korrekt.

[AlCalzone]

Kleines Update an alle: Ich hab euch nicht vergessen - die Implementierung der Supervision CC geht voran. Allerdings erfordert die ein paar Änderungen im Kern, damit dieser Typ von Kommandoklassen korrekt behandelt wird.

Beim Testen hab ich dann allerdings zwei fette Bugs gefunden, die dafür sorgen können, dass die Kommunikation seitens des Controllers hängen bleibt (könnte auch @maloross Probleme mit den unvollständigen Geräten erklären).
Einen davon habe ich (hoffentlich) behoben, der andere wird die nächsten Tage angegangen.

Danach gehts hoffentlich weiter mit dem eigentlichen Problem :)

[taba_luga]

@AlCalzone ich habe nochmal die Aussage von @Rolf_KA getestet, dass der "current value" sich beim zweiten mal eingeben des gleichen "target value" aktualisiert. Das ist bei mir nicht der Fall. Ich kann den "target value" setzen und das Rollo fährt auf den eingestellten Wert. Der "target value" wird allerdings nie bestätigt. Er bleibt immer rot und unbestätigt. Der "current value" aktualisiert sich bei mir nie, egal wie oft ich den gleichen "target Value" eingebe.