Test Adapter Z-Wave 2 (v1.7.x)

[jrgsch]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

Das initiale Interview ist noch nicht durch - erkennbar am Status "ready", der bei dir auf "false" steht. Batteriebetriebene Geräte müssen aufgeweckt werden (bzw. es muss lange genug gewartet werden), damit das durchläuft. Oft wachen die nur alle paar Stunden ganz kurz auf.

da muss mehr dahinter stecken, alle anderen Objekte sind da und ich habe den Sensor mehrfach manuell aufgeweckt und dabei auch das Interview wiederholt

[BausSH]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

v1.7.6 ist auf dem Weg

Danke für deine Mühe. Leider ist mein Problem noch nicht ganz beseitigt. Der Target-Value der Helligkeit ist jetzt tatsächlich schreibbar, aber die Target-Values der Farben und Weißkanäle sind noch immer nicht beschreibbar. Ändere ich das, bleibt die Lampenfarbe immer noch nicht geändert. Hier sind die Raw-Daten des Grünkanals:

{
  "from": "system.adapter.zwave2.0",
  "user": "system.user.admin",
  "ts": 1602862049462,
  "common": {
    "name": "Target value (Green)",
    "role": "value",
    "desc": "The target value of the Green color.",
    "type": "number",
    "min": 0,
    "max": 255,
    "read": true,
    "write": false
  },
  "native": {
    "nodeId": 9,
    "valueId": {
      "commandClass": 51,
      "endpoint": 0,
      "property": "targetColor",
      "propertyKey": 3
    }
  },
  "acl": {
    "object": 1638,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1638
  },
  "_id": "zwave2.0.Node_009.Color_Switch.targetColor_green",
  "type": "state"
}

Brauchst du für die nicht funktionierende Farbenänderung noch ein Log?

[AlCalzone]

@jrgsch Ok dann brauche ich mal ein Log bitte

@BausSH ja von dir auch Wegen der nicht schreibbaren DPs bitte mal das Interview des Nodes wiederholen (über Geräte -> [...]).

[jrgsch]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

@jrgsch Ok dann brauche ich mal ein Log bitte

Mach ich heute am späten Abend

Zuvor aber eine Verständnisfrage: ich habe lokal die fgkf601.json geändert und das Gerät erneut interviewt --> ergab erstmal nichts. Dann habe ich den Objekten den Pfad "Configuration" gelöscht damit er neu aufgebaut werden kann. Erneut das Interview gestartet (und auch nachweislich das Gerät aufgeweckt) --> der Pfad Configuration wird nicht angelegt. Muss ich das Gerät komplett ex- und inkludieren? Wäre blöd, da sich in den Scripten dann immer die Node-Nr verschieben.

[BausSH]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

@BausSH ja von dir auch

Alles klar. Ich habe:

• das Log aktiviert
• ioBroker neu gestartet
• das Interview neu durchgeführt und
• einige Farben geändert.

Die Target-Values sind jetzt tatsächlich schreibbar. Aber die Farben ändern sich noch immer nicht.

Hier ist das Log:
c2ec032b.values.jsonl

Es geht übrigens mal wieder um das Node 009. Danke für die Mühe.

[zanabria]

@AlCalzone
Danke geht nach neuer Inclusion!

[AlCalzone]

@BausSH Das ist leider nicht das Log. Bitte nochmal genau lesen: https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue Punkt 1

[BausSH]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

Das ist leider nicht das Log.

Ja, entschuldige. Da bin ich irgendwann falsch abgebogen. Hier müsste jetzt das Log sein:
zwave-10250.log

[AlCalzone]

@BausSH
Ich sehe im Log folgendes:

• Kommando: Blau auf 255
• Bestätigung: Blau wurde geändert auf 255
• Kommando: Grün auf 0
• Bestätigung Grün wurde geändert auf 0
• Kommando: Rot auf 0
• Bestätigung Rot wurde geändert auf 0
• Kommando: Kaltweiß auf 255
• Bestätigung: Kaltweiß wurde geändert auf 255

In der Kommunikation scheint es schon mal zu funktionieren. Die States in ioBroker müssten auch aktualisiert werden.

Ich bin ehrlich gesagt etwas ratlos was es noch sein könnte. Aus meiner Sicht siehts gut aus.

[jrgsch]

@jrgsch said in Test Adapter Z-Wave 2 (v1.7.x):

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

@jrgsch Ok dann brauche ich mal ein Log bitte

Mach ich heute am späten Abend

Es ist heute früh geworden. Aber immerhin mit dem Erfolg, dass für das Node 5 jetzt die Command Class Configuration Objekte vorhanden sind.

Zu Node 3 (KeyFob): für die von mir gelöschten Objekte der Command Class Configuration sind noch nicht wieder da (bei wiederholtem Interview - im log 00:57:xx und Aufwecken). Ich warte da jetzt auch noch mal laaaange, anschließend exkludiere ich das Teil mal und inkludiere es neu, bei dem Keyfob waren (die alten unvollständigen Einträge) ja beim ersten Inkludieren sofort da.

Vielen Dank für deine Unterstützung!

fdd5cdf7.json
fdd5cdf7.values.jsonl
zwave-11347.log

[jrgsch]

@jrgsch said in Test Adapter Z-Wave 2 (v1.7.x):

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

@jrgsch Ok dann brauche ich mal ein Log bitte

Mach ich heute am späten Abend

Entwarnung! Das Node 3 hat jetzt seine Configuration Objekte. Es hat ohne Neu-Inkludieren funktioniert und es sind jetzt auch alle Parameter da. Jetzt muss ich nur mal schauen, wie ich meine lokalen Änderungen an der fgkf601.json als PR im git hinbekomme (hab ich noch nie gemacht, aber irgendwann muss man ja mal anfangen).

[AlCalzone]

@jrgsch sagte in Test Adapter Z-Wave 2 (v1.7.x):

anschließend exkludiere ich das Teil mal und inkludiere es neu

Ist eigentlich nie nötig. Dafür gibts die Aktion "erneut interviewen", die sich hinter jedem Gerät unter [...] versteckt.

[Mojito Joe]

Habe heute auch von 1.7.5 auf 1.7.6 upgedated. Kann mich bei den vorherigen Updates nicht erinnern, solche Warnungen erhalten zu haben:

$ ./iobroker upgrade zwave2
Update zwave2 from @1.7.5 to @1.7.6
NPM version: 6.14.8
npm install iobroker.zwave2@1.7.6 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call)
../src/serialport_unix.cpp: In function ‘int setup(int, OpenBaton*)’:../src/serialport_unix.cpp:166:5: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1005 [-Wformat-truncation=] int setup(int fd, OpenBaton *data) {
     ^~~~~
In file included from /usr/include/stdio.h:862:0,                 from ../src/serialport.h:3,                 from ../src/serialport_unix.cpp:2:/usr/include/x86_64-linux-gnu/bits/stdio2.h:65:44: note: ‘__builtin___snprintf_chk’ output 20 or more bytes (assuming 1043) into a destination of size 1024        __bos (__s), __fmt, __va_arg_pack ());                                            ^
../src/serialport_unix.cpp: In function ‘void EIO_Open(uv_work_t*)’:../src/serialport_unix.cpp:79:6: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1003 [-Wformat-truncation=] void EIO_Open(uv_work_t* req) {
      ^~~~~~~~In file included from /usr/include/stdio.h:862:0,                 from ../src/serialport.h:3,                 from ../src/serialport_unix.cpp:2:/usr/include/x86_64-linux-gnu/bits/stdio2.h:65:44: note: ‘__builtin___snprintf_chk’ output 22 or more bytes (assuming 1045) into a destination of size 1024        __bos (__s), __fmt, __va_arg_pack ());                                            ^
../src/serialport_unix.cpp: In function ‘int setup(int, OpenBaton*)’:../src/serialport_unix.cpp:166:5: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1005 [-Wformat-truncation=] int setup(int fd, OpenBaton *data) {
     ^~~~~
In file included from /usr/include/stdio.h:862:0,                 from ../src/serialport.h:3,                 from ../src/serialport_unix.cpp:2:/usr/include/x86_64-linux-gnu/bits/stdio2.h:65:44: note: ‘__builtin___snprintf_chk’ output 20 or more bytes (assuming 1043) into a destination of size 1024        __bos (__s), __fmt, __va_arg_pack ());                                            ^
../src/serialport_unix.cpp: In function ‘void EIO_Open(uv_work_t*)’:../src/serialport_unix.cpp:79:6: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1003 [-Wformat-truncation=] void EIO_Open(uv_work_t* req) {
      ^~~~~~~~In file included from /usr/include/stdio.h:862:0,                 from ../src/serialport.h:3,                 from ../src/serialport_unix.cpp:2:/usr/include/x86_64-linux-gnu/bits/stdio2.h:65:44: note: ‘__builtin___snprintf_chk’ output 22 or more bytes (assuming 1045) into a destination of size 1024        __bos (__s), __fmt, __va_arg_pack ());                                            ^
upload [6] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/zwave2.svg zwave2.svg image/svg+xml
Update "system.adapter.zwave2.0"
upload [5] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/words.js words.js application/javascript
upload [4] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/style.css style.css text/css
upload [3] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/script/d3.min.js script/d3.min.js application/javascript
upload [2] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/index_m.html index_m.html text/html
upload [1] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/build/index.js.map build/index.js.map application/json
upload [0] zwave2.admin /opt/iobroker/node_modules/iobroker.zwave2/admin/build/index.js build/index.js application/javascript
Adapter "zwave2" updated
process exited with code 0

Falls Du diese nicht kennst @AlCalzone

[AlCalzone]

@Mojito-Joe Das kommt von der Serialport-Library, müsste aber unkritisch sein. Hast du sonst irgendwas geändert? Node-Version z.B.?

[Domoe]

Moin zusammen,

ich bin seit langer Zeit stiller mitleser und benutze auch den Z-Wave 2 Adapter.
Ich hatte bis jetzt noch keine Probleme.

Heute als ich meine Heizungssteuerung für den Winter Fit machen wollte ist mir aufgefallen das ein Devolo Raumthermostat (Unter Geräte als Danfoss MT 2649 aufgeführt) das Interview nicht beendet.
Unter Objekte steht das Raumthermostat bei "ready" auch auf false.
Ich habe vor 3 Tagen das Raumthermostat neu angelernt leider wurde es dadurch nicht besser.

Wie kann ich dazu beitragen das dieser Fehler gefixt wird?

Vielen Dank und Grüße

Dominik

[Mojito Joe]

@AlCalzone Ja, hatte vor einiger Zeit js-controller v3.1.6 und Node v.12.19.0 upgedated. Leider blieb anschließend der zwave2 Adapter (als Einziger) immer wieder sporadisch im Status gelb hängen und warf im Log Fehler. Auch die automatischen Rebuild-Versuche schlugen fehl und im Log wurde dann "npm rebuild" oder "npm install" vorgeschlagen. In der Anleitung zum Node-Update habe ich dann aber von "iobroker rebuild zwave2" gelesen. Ich muss zugeben, genau weiß ich nicht, was ich da tue, habe das Update das erste mal gemacht. Aber seit "iobroker rebuild zwave2" meldet der Adapter keine Startprobleme mehr.

[Flopsi]

@AlCalzone

Ich habe des öfteren Probleme mit dem Fibaro Heat Controller und zwar immer wenn ich ein Update (in diesem Fall 1.7.6) mache oder den Controller neu starte.. dann sind die Werte nicht grün/schwarz..... sondern orange/rot.

Hier der letzte Log:

zwave-15713.log

[AlCalzone]

@Flopsi Das Interview läuft nicht durch, da er auf die aktive Abfrage des Thermostat-Status nicht antwortet. Ich habe schon diverse Ausnahmen eingebaut, schätze ich muss das auf alle Statusabfragen erweitern.
Ach und nächstes Mal (wie eigentlich immer) die Node-Nr. nennen. Hier hatte ich Glück, dass es im Screenshot versteckt war

[Flopsi]

@AlCalzone

Sorry du suchst dir ja einen Wolf ist Node 18 und 29 aktuell ....

Komischerweise laufen die andern Heizungen bis jetzt ..... nur bei den beiden läuft es nicht oder vertue ich mich da ??

Zur Not hier noch die anderen Node der Heizungen:

Node 35
Node 22
Node 28
Node 06

[AlCalzone]

@Flopsi
29 antwortet korrekt auf die Solltemperaturabfrage, hat dann aber das gleiche Problem bei Notifications
6 rennt in das gleiche Problem bei den Notifications
Die restlichen genannten funktionieren.

Hab mir mal ein Issue gemacht, damit ich es nicht vergesse. Dürfte aber 1-2 Tage dauern bis ich dazu komme.