UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[taba_luga]

@AlCalzone, ich habe die Netzerk Heilung bei mir getestet. Sie läuft bei mir immer noch. Ich denke ich habe den Fehler bei mir gefunden:

Hier der Auszug aus dem Log:

Die Nodes 6 und 23 gibt es nicht mehr und können nicht antworten.
In der Geräte Übersicht sind beide Nodes nicht gelistet.

In den Objekten sind sie allerdings bei den Nodes gelistet:

Sie stehen beide im Status "asleep". Ist das so richtig? Da der Node auf keine Anfrage antworten kann, müsste er da nicht direkt im Status "dead" stehen und ist es gewollt, dass diese nicht in der Geräte Übersicht auftauchen?

Ebenso kannst du im Screenshot der Geräte Übersicht sehen, dass die Spinner neben jedem Node erscheinen. Ist das so gewollt und richtig?

[taba_luga]

Mir ist noch was aufgefallen. In der Netzwerk Übersicht sind die Nodes auch gelistet und haben auch Kommunikationswege eingezeichnet.

Das kann eigentlich auch nicht stimmen, oder?

[AlCalzone]

@taba_luga Das hilft mir weiter, danke!

Die Kommunikationswege sind im Controller gespeichert und sind die letzten bekannten Nachbarn. Da bei batteriebetriebenen Nodes keine Antwort kommt, wenn diese schlafen, kann man sie nicht ohne weiteres als tot einstufen - sie könnten auch einfach eine lange Aufweckzeit haben.

Hast du v0.9.1 installiert und hast du nach der Installation einen Upload (iobroker upload zwave2) durchgeführt? Dann sollte eigentlich neben fehlgeschlagenen Nodes ein (!) erscheinen. Dein Netzwerk sieht eigentlich recht gut vernetzt aus - lediglich der Controller selbst hat nur 3 Direktverbindungen. Vielleicht gibt es für den eine bessere Position?

Wenn Node 6 und 23 entfernt sind (komme ggf. am Wochenende zur Erweiterung der UI), sind diese beiden immerhin als Fehlerquelle ausgeschlossen.

[taba_luga]

Hast du v0.9.1 installiert und hast du nach der Installation einen Upload (iobroker upload zwave2) durchgeführt? Dann sollte eigentlich neben fehlgeschlagenen Nodes ein (!) erscheinen. Dein Netzwerk sieht eigentlich recht gut vernetzt aus - lediglich der Controller selbst hat nur 3 Direktverbindungen. Vielleicht gibt es für den eine bessere Position?

Ja, ich habe die Version v.0.9.1 installiert. Allerdings nicht über die Konsole, sondern aus dem UI heraus. Daher habe ich auch kein iobroker upload zwave2 durchgeführt.

Die "!" waren am Anfang direkt nach dem Start der Netzwerk Heilung zu sehen, aber fast an jedem Gerät. Sie wechselten dann sukzessive auf die Spinner. Nach dem der Spinner am Gerät erschienen ist kam kein "!" mehr.

Ich werde es heute Nachmittag nochmal versuchen und gebe dann weitere Infos.

[AlCalzone]

@taba_luga sagte in Test adapter ZWave2 (v0.9.x):

Ich werde es heute Nachmittag nochmal versuchen und gebe dann weitere Infos.

Spar dir die Mühe. Ich ändere in der nächsten Version ein bisschen was am Heilprozess mit den Infos die du mir gegeben hast. Dann sag ich nochmal Bescheid (ggf. heute Abend).

[Rolf_KA]

@AlCalzone

Habe deinen neuen 0.9.2-beta Adapter installiert... :+1:

Was mit aufgefallen ist; wenn ein node für "dead" erklärt wurde, weil der z. B. kein Strom hatte (Sicherung draußen), wird dieser Node erst nach einem Adapter Neustart auch wieder aktiviert.
Können Nodes nicht regelmäßig abgefragt werden, ob sie noch leben oder tot sind z.B. 1 x pro Minute - gilt natürlich nicht bei schlafende Node.

Im Screen habe ich bei Node_004 den Strom bei laufendem Adapter abgeklemmt, als ich dann einen Wert ändern wollte, wurde
der Node_004 dann für tot erklärt und eine Fehlermeldung im Log ausgegeben - soweit gut.
Nachdem ich den Node_004 dann wieder mit Strom versorgt habe, bleibt er aber Tot - auch nach Minuten und nach Änderung eines Werts, welcher dann auch im Log wieder als Fehler ausgegeben wird (leider ohne Node Nr.)
Nach einem Adapter Neustart war dann alles wieder okay.

Der Rest läuft bei mir sonst wie gewohnt perfekt :-)

ioBroker Log: (Bei der langen Fehlermeldung war der Strom abgeklemmt, bei der kuzen wieder angeklemmt)

[Schuko80]

@Schuko80 sagte in Test adapter ZWave2 (v0.9.x):

@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):

@Schuko80 sagte in Test adapter ZWave2 (v0.9.x):

Vielleicht habe ich mich auch schlecht ausgedrückt. Mit dem alten Adapter gingen Befehle direkt durch, Verzögerung so gering, das ich vom Display durch die Tür zur Heizung gegangen bin und diese schon umgeschaltet war.
Jetzt könnte ich einen wenn sie überhaupt durchgehen, einen Kaffee trinken gehen.

Dann muss ich mal vergleichen, was die Adapter machen. Kannst du mir bitte mit dem alten und dem neuen jeweils ein Log erzeugen (OZW_Log.txt und zwave-<12345>.log), die jeweils das Interview plus 1-2 Schaltbefehle an die entsprechenden Thermostate beinhalten?

So, anbei die Dateien, war gar nicht so einfach, die zu finden ... es könnte sein, das am Anfang Probleme mit dem Start zu sehen sind, habe die Adapter nicht mehr zum Starten bekommen, da der OZW noch im Hintergrund aktiv geblieben ist.

Was mir noch aufgefallen ist, eine Heizung stand auf 20.5 Grad, das kann dein Adapter auch nicht, der hat den Wert als 20 ausgelesen.

Mit deinem Adapter habe ich Versucht Node 2 & 3 zu beschreiben, bei dem OZW lediglich einen, dafür zwei mal, einmal rauf und einmal runter :)

Inhalt ist über Windows kopiert, ich hoffe es sind trotzdem alle wichtigen Daten da.

OZW_log.txt zwave2_Adapter.txt

Habe gerade mal ein Update auf die 0.9.2 beta gemacht, die Temperatur wird nun korrekt mit Kommastelle ausgelesen, an dem Kommunikationsproblem hat sich bei mir aber leider nichts getan - die Thermostate verhalten sich weiterhin, als wenn sie abgemeldet sind, auch werden Änderungen scheinbar nicht gesendet, die gehen unter "Objekte" nach kurzer Zeit auf rot.

[AlCalzone]

@Schuko80 @Rolf_KA
Ach ihr seid zu schnell ;) In ein paar Minuten kommt v0.9.2.

Diese enthält einige Stabilitätsverbesserungen (die zum Teil aber auch schon in der Beta sind):

• Das Interview wird sauber abgebrochen und später wiederholt, wenn es ein Timeout o.ä. gab ( @taba_luga, @maloross, das könnte euch helfen bzgl. fehlende Datenpunkte )
• Nachrichten an Nodes, die schlafen können, werden jetzt erst wiederholt, anstatt den Node sofort als schlafend zu markieren.

Außerdem gibt es folgende Features:

• Wenn ein Node entfernt wird, werden auch Assoziationen zu diesem Node entfernt.
• Der Netzwerk-Heil-Prozess wurde nochmal verbessert und sollte jetzt auch übersprungene Nodes (z.B. weil tot) anzeigen. (ist aber auch bei mir manchmal noch hakelig).

@Schuko80 Deine Logs schaue ich mir gleich mal an.

[AlCalzone]

@Schuko80
Zu deinen Logs: Bei OZW sehe ich nur, dass die Nachrichten an den Node in die Warteschlange aufgenommen wurden - gesendet wurde laut Log aber nichts. Das würde sich mit der Ausgabe von meinem Adapter decken "wird nichts gesendet, weil alles schläft".

Bitte probiere auch mal die 0.9.2, aber lösche unbedingt den Cache.

[Rolf_KA]

@Schuko80 sagte in Test adapter ZWave2 (v0.9.x):

die Thermostate verhalten sich weiterhin, als wenn sie abgemeldet sind, auch werden Änderungen scheinbar nicht gesendet, die gehen unter "Objekte" nach kurzer Zeit auf rot.

Ich hatte gestern meine neuen Fibaro Door/Window Sensor2 (mit Batterie) erhalten und im ZWave2 Adapter eingebunden.
Das hat soweit auch alles sehr gut Konfiguriert.

Als ich den Sensor dann konfigurieren wollte, hatte ich bemerkt, das alle meine Werte- Änderungen in rot quittiert werden...
Ich dachte da schon an dich - mir war dann aber klar, dass der Sensor ja schläft und weckte ihn mit dem Knopf am Sensor auf, was auch funktionierte - danach wurden meine Änderungen/Anpassung auch ohne Probleme übernommen.

@AlCalzone
Bei der neuen 0.9.2 beta Version funktioniert das aufwecken mit der Taste am Sensor jetzt nicht mehr - in der 0.9.1 funktionierte es.
Die neue Version bekommt wohl nicht mit, das ein Sensor aufweckt wurd.

[Rolf_KA]

@AlCalzone

Bitte probiere auch mal die 0.9.2, aber lösche unbedingt den Cache.

Ich lasse mich von dir immer gerne überraschen, und bitte keinen Stress ! :-)
Gebe dann Bescheid :+1:

[Schuko80]

@Rolf_KA sagte in Test adapter ZWave2 (v0.9.x):

Ich dachte da schon an dich - mir war dann aber klar, dass der Sensor ja schläft und weckte ihn mit dem Knopf am Sensor auf, was auch funktionierte - danach wurden meine Änderungen/Anpassung auch ohne Probleme übernommen.

Ja, wenn der Taster an dem Thermostat gedrückt wird, dann wacht er auf, dauert aber gut 10sekunden, da er das Netz dann scheinbar sucht. Und es bringt natürlich nichts, wenn ich Daten sende und den Node dann per Hand wecken muß :)

@AlCalzone

ich probiere gleich mal deine neue Version, was mir aktuell halt auffällt, es fehlen einige Datenpunkte bei allen Thermostaten, anbei ein Screenshot wie sie unter OZW sind - insbesondere fällt mir da der Punkt "ready" auf, ich möchte wetten das der bei deinem Adapter auf "false" stehen würde. Warum kein Plan. Wie gesagt, ich probiere gleich mal den neuen Adapter, vielleicht ändert sich ja was.

[Xyolyp]

@AlCalzone bei der Konfiguration habe ich die serielle Schnittstelle vor dem ersten Start der Instanz so eingegeben: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Immer wenn ich die Instanz laufen habe und die Konfiguration läuft wird das DropDown mit /dev/ttyAMA0, /dev/ttyACM0 und /dev/ttyUSB0 angezeigt. Wäre es möglich wenn ein Wert eingetragen ist, der nicht im DropDown zur Auswahl steht, diesen automatisch in die Auswahl mit aufzunehmen?

[Schuko80]

Hab gerade das Update auf die 0.9.2 direkt über GitHub gemacht, Cache danach geleert, leider immer noch die gleiche Problematik.

[Rolf_KA]

@AlCalzone

mir war dann aber klar, dass der Sensor ja schläft und weckte ihn mit dem Knopf am Sensor auf, was auch funktionierte

Das aufwecken funktioniert jetzt bei mir wieder wie vorher - und auch recht zügig :+1:
(Vielleicht hatte ich bei der beta Version aber auch vorher den Sabotage Sicherungsknopf nicht gedrückt :face_with_rolling_eyes: )

Nachdem ich den Node_004 dann wieder mit Strom versorgt habe, bleibt er aber Tot - auch nach Minuten und nach Änderung eines Werts, welcher dann auch im Log wieder als Fehler ausgegeben wird (leider ohne Node Nr.)
Nach einem Adapter Neustart war dann alles wieder okay.

Daran hat sich aber nichts geändert - einmal "dead" wohl immer "dead" - bis zum Adapter Neustart.
Z-Wave müsste doch aber erkennen, das ein Node der vorher "dead" war, jetzt wieder aktiv ist :face_with_rolling_eyes:

:-)

[Rolf_KA]

@AlCalzone

@Rolf_KA sagte in Test adapter ZWave2 (v0.9.x):
Daran hat sich aber nichts geändert - einmal "dead" wohl immer "dead" - bis zum Adapter Neustart.
Z-Wave müsste doch aber erkennen, das ein Node der vorher "dead" war, jetzt wieder aktiv ist

Habe gerade herausgefunden das dieses Problem wohl am RollerShuter 2 liegt - und der hat noch kein ZWave PLUS ! ;-)
Bei allen anderen Modulen mit ZWave PLUS funktioniert die automatische Statusänderung von "dead" auf "alive" nach dem die Stromversorgung wieder vorhanden ist, einwandfrei - TOP !

Von meiner Seite ist jetzt soweit alles wieder okay :-)

Danke @AlCalzone :+1:

[AlCalzone]

@Schuko80 Dann hätte ich gerne nochmal ein Log mit der neuen Version. Bitte Cache löschen und dann nach Adapterstart den Node aufwecken, damit das Interview durchlaufen kann.

Bitte auch nach der Sollwertänderung den Node aufwecken, damit ich sehen kann, was dabei passiert. Im OZW-Log sehe ich nichts, dass der irgendwas anderes machen würde, was die Verzögerung erklärt.

Ob der Node ready ist, solltest du im Log sehen - ich habe drauf verzichtet, dafür einen DP zu machen.

---

@Rolf_KA Sobald von einem toten Node eine Nachricht empfangen wird, wird dieser wieder als lebendig markiert. Regelmäßig "pingen" wäre allerdings eine Idee.

---

@Xyolyp habe mal ein Issue erstellt, dass ich das demnächst angehen kann - gute Idee!

[Schuko80]

@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):

@Schuko80 Dann hätte ich gerne nochmal ein Log mit der neuen Version. Bitte Cache löschen und dann nach Adapterstart den Node aufwecken, damit das Interview durchlaufen kann.

Bitte auch nach der Sollwertänderung den Node aufwecken, damit ich sehen kann, was dabei passiert. Im OZW-Log sehe ich nichts, dass der irgendwas anderes machen würde, was die Verzögerung erklärt.

Ob der Node ready ist, solltest du im Log sehen - ich habe drauf verzichtet, dafür einen DP zu machen.

Guten Morgen, "DP"? Was soll das bedeuten?

Ich habe zwei Log Dateien für dich, einmal Adapter Start, danach Cache geleert, da ist glaube ich eine neue Datei angelegt worden.
Vorgegangen bin ich wie folgt:

1. Adapter starten
2. Cache geleert
3. Interview abgewartet
4. Wert an Node 3 gesendet und direkt danach den Node von Hand geweckt
5. Wert an Node 2 manuell geändert auf 21.5 und kurz danach wieder auf 21

Was mir aufgefallen ist, die Thermostate verbinden sich laut deren Anzeige gar nicht mit dem System, sie blinken nämlich dauerhaft mit kein Empfang. Aber:

1. Das Interview läuft von alleine durch, ich brauch da nichts von Hand aufwecken
2. Auch wenn die Anzeige mit kein Empfang blinkt, sendet das Thermostat seinen Wert an deinen Adapter
3. Kommastellen funktionieren, zumindest vom Thermostat zum Adapter, andersherum konnte ich es nicht nicht testen

Dennoch:

1. Der Adapter sendet keinen Wert an das Thermostat, der Wert kommt einfach nicht an, auch wenn ich sofort manuell aufwecke.
2. gab es diesmal einen Fehler in der Log von IOBroker, den ich aber nicht in der Log Datei vom Adapter gefunden habe, oder ich habe ihn übersehen- Screenshot im Anhang

zwave-22472.log zwave-22436.log

[AlCalzone]

@Schuko80 "DP" = Datenpunkt (oder State) in ioBroker.

Woran machst du fest, dass das Interview für Node 3 durch ist? Laut Log hängt der Adapter momentan noch am Interview der Thermostat Setpoint CC. "Interview completed" lese ich da nicht. Fürchte den musst du noch 1-2x aufwecken.

Interessanterweise antworten Node 2, 3 und 8 auch nicht auf die Abfrage des aktuellen Sollwerts, obwohl sie diesen bei Änderungen von sich aus senden. Woran das liegt, ist mir aber noch nicht klar. Ggf. tut es eine Netzwerk-Heilung?

Laut diesem Thread kommt es wohl öfters vor, dass diese Thermostate sich bei einem Batteriestand unter 60% über schlechte Verbindung beschweren.

Ich brauche nochmal etwas Input von dir, um das Problem einzugrenzen. Im Internet liest man von zahlreichen Problemen des LC-13 mit allen Smart-Home-Systemen, aber keine klare Lösung.

• Was genau zeigen denn die Thermostate an, wenn sie angeblich keine Verbindung haben?
• Kannst du mir bitte nochmal einen Log von dem originalen Adapter schicken? Da tritt der genannte Fehler ja nicht auf, richtig? Bitte abwarten, bis der Scan abgeschlossen ist. Danach das Thermostat manuell aufwecken, ohne setpoint-Änderungen zu senden. Dann den Setpoint ändern und nochmal aufwecken.

[Schuko80]

@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):

@Schuko80 "DP" = Datenpunkt (oder State) in ioBroker.

Woran machst du fest, dass das Interview für Node 3 durch ist? Laut Log hängt der Adapter momentan noch am Interview der Thermostat Setpoint CC. "Interview completed" lese ich da nicht. Fürchte den musst du noch 1-2x aufwecken.

Ich habe es eigentlich an der Log Datei festgemacht - zum einen meldet Node1 also der Stick - Interview completed, all values are updated - zum anderen sind alle anderen Nodes aufgewacht und wieder eingeschlafen.

Interessanterweise antworten Node 2, 3 und 8 auch nicht auf die Abfrage des aktuellen Sollwerts, obwohl sie diesen bei Änderungen von sich aus senden. Woran das liegt, ist mir aber noch nicht klar. Ggf. tut es eine Netzwerk-Heilung?

Meinst du "Ist" oder "Soll" Wert? Node 8 habe ich soweit ich weiß nie angesprochen, oder unbewusst.

Laut diesem Thread kommt es wohl öfters vor, dass diese Thermostate sich bei einem Batteriestand unter 60% über schlechte Verbindung beschweren.

Ich brauche nochmal etwas Input von dir, um das Problem einzugrenzen. Im Internet liest man von zahlreichen Problemen des LC-13 mit allen Smart-Home-Systemen, aber keine klare Lösung.

Über die LC-13 beschweren sich viele, das weiß ich, bei mir liefen sie immer sehr gut, ob unter IOBroker oder damals unter Domoticz - wenn der Stick ordentlich aufgestellt ist, sind die Verbindungen wirklich stabil, solange bis die Batterie leer ist.

• Was genau zeigen denn die Thermostate an, wenn sie angeblich keine Verbindung haben?
• Kannst du mir bitte nochmal einen Log von dem originalen Adapter schicken? Da tritt der genannte Fehler ja nicht auf, richtig? Bitte abwarten, bis der Scan abgeschlossen ist. Danach das Thermostat manuell aufwecken, ohne setpoint-Änderungen zu senden. Dann den Setpoint ändern und nochmal aufwecken.

Anbei findest du den Log, achte bitte auf Node 4, hab erst 2 und 3 durcheinander gewürfelt, daher sind die nicht aussagekräftig, Node 4 wurde aufgeweckt, danach SetPoint von 5 auf 4 gesetzt und noch einmal aufgeweckt.

OZW_log.txt

Bzgl. der Anzeige habe ich dir zwei Videos an gehangen (leider extern, da zu groß), dann siehst du es genau - das Lange ist von deinem Adapter, das kurze von OZW - da sieht man, das ich zum manuellen Steuern der Heizung 17 Sekunden benötige, bevor ich etwas machen kann.

OZW Video
Zwave2 Video

So, ich glaube ich habe alles :grin: - wenn du noch was brauchst, immer raus damit ...

EDIT:

Hab evtl. zum Aufwecken die falsche Taste genutzt, daher hier noch mal die ganz aktuelle Log Datei - geht wieder um Node 4

OZW_log.txt