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

EvilEls

@AlCalzone
Habe seit 1.7.3 Probleme mit den zuvor unauffälligen Nodes 2 und 3.
Für beide bekommt der Adapter kein Interview mehr zustande.
Das Log umfasst ca 10 Min. Die Interviews sind aber auch nach Stunden noch nicht da.
Auch erneutes Auslösen der Interviews bringt nichts.

zwave2.0	2020-10-04 21:56:00.137	info	(5310) Node 3 is alive
zwave2.0	2020-10-04 21:55:56.321	info	(5310) Node 3: interview restarted
zwave2.0	2020-10-04 21:55:54.108	info	(5310) Node 2 is alive
zwave2.0	2020-10-04 21:55:54.062	info	(5310) Node 2: interview restarted

Erreichbar und alive sind die Nodes. zwave2.0.Node_xxx.ready bleibt aber false
Netzwerk heilen fehlerfrei.
Irgendwann geht zwave2.0.Node_xxx.status dann auf unknown

Habe mit und ohne die neuen Optionen (Timeout +, Sendeversuche +) versucht. Selbes Ergebnis.

Bin Schrittweise die Versionen zurück gerollt, bis 1.6.3. Aber selbst da bekommen ich keine Interviews mehr für die Nodes.
Habe die Dimmer zurückgesetzt. Trotzdem kein Interview.

Bevor ich Kahlschlag mache, kannst du evtl. an den Logs was erkennen. ob es ein (behebbares) Software Problem ist?

Die Logs: 2020-10-04.zip

Besten Dank im Voraus!

zanabria

@AlCalzone, @Flopsi ,
habe das Problem gefunden.
Nachdem ich im Ausschlußverfahren und nicht im Schwachsinn, @arteck, die Hardware ausschließen konnte habe ich die Bootdateien geprüft. Da habe ich in der "cmdline.txt", am Ende der Datei eine Zusatzzeile gefunden, die vor dem Update von Node.js nicht drin war. Es war was mit "xxxPi3xxx". Zeile entfernt, neu gestartet und der Adapter war wieder lauffähig. Hat auch alle Aktoren erkannt und wieder richtig Interviewt.:blush:

AlCalzone · Die Logs: 2020-10-04.zip

@EvilEls Hast du Node 2 und 3 sicher eingebunden? Irgendwas ist da komisch... Node 2 behauptet, er wäre ein Multilevel Power Switch:

21:30:42.991 CNTRLR « [Node 002] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Multilevel Switch
                      specific device class: Multilevel Power Switch
[...]

behauptet dann aber, er unterstützt nur die folgenden 3 CCs:

21:30:43.319 CNTRLR « [Node 002] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      controlled CCs:

Aufgrund der ersten Aussage wird zu diesen noch die "Pflicht"-CC Multilevel Switch ergänzt, auf deren Interview vom Node aber keine Antwort kommt.

Node 4 (ein ähnliches Gerät?) gibt zusätzlich noch Security CC als unterstützt an:

21:30:43.493 CNTRLR « [Node 004] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      · Security

und berichtet dort, dass Multilevel Switch CC verschlüsselt unterstützt ist:

21:30:44.615 DRIVER « [Node 004] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[SecurityCCCommandsSupportedReport]
                            reportsToFollow: 0
                            supportedCCs:
                            · Version
                            · Manufacturer Specific
                            · All Switch
                            · Binary Switch
                            · Multilevel Switch
                            · Meter
                            · Notification
                            · Association
                            · Multi Channel Association
                            · Association Group Information
                            · Configuration
                            controlledCCs:
                            · Multilevel Switch

EvilEls

hi @AlCalzone!
Danke für dein Feedback!

Ich habe an dem ganzen z-wave Setup rein gar nichts verändert. Lediglich auf die 1.7.3 ge-updated.
Node 2 und 3 (https://support.qubino.com/support/solutions/articles/44001757253-qubino-din-dimmer) liefen bis vor wenigen Tagen noch tadellos.

Node 4 (https://support.qubino.com/support/solutions/articles/44001757250-qubino-flush-dimmer) ist in der Tat ein ähnliches Gerät.

Bis vor Kurzem sah das noch so aus:

20:51:24.933 CNTRLR « [Node 002] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Multilevel Switch
                      specific device class: Multilevel Power Switch
                      is a listening device: true
                      is frequent listening: false
                      is a routing device:   true
                      is a secure device:    unknown
                      is a beaming device:   true
                      maximum baud rate:     40000 kbps
                      version:               4

20:51:25.295 CNTRLR « [Node 002] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      · Security
                      controlled CCs:

Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?

AlCalzone

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

Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?

Ne keinen Schimmer - aber anscheinend vergessen die auch gerne mal zu berichten, dass sie manche Dinge können... Eventuell lohnt es sich, mal beim Support nachzufragen.
Einen Workaround hätte ich - du solltest danach nur vermeiden, den Cache zu löschen, sonst gehts wieder von vorne los.

Adapter stoppen.
/opt/iobroker/iobroker-data/zwave2.0/cache/<deine-home-id>.json mit einem Editor öffnen

Die Datei enthält eine Struktur, die in etwa so aussieht:

{
    "nodes": {
        "1": {
            "id": 1,
            ...
        },
        "2": {
            "id": 2,
            ...
            "commandClasses": {
                ...
            }
        },
        "3": {
            "id": 3,
            ...
            "commandClasses": {
                ...
            }
        }
        ...
    }
}

Nach der Zeile mit commandClasses von Node 2 und 3 jeweils bitte folgendes einfügen:

                "0x98": {
                    "name": "Security",
                    "endpoints": {
                        "0": {
                            "isSupported": true,
                            "isControlled": false,
                            "secure": true,
                            "version": 1
                        }
                    }
                },

Datei speichern, Adapter wieder starten.

AlCalzone

v1.7.4 ist da, mit einigen Stabilitätsverbesserungen. Unter anderem sollte sie den berühmten E5-Fehler beheben, der sich in 1.7.0 wieder eingeschlichen hat. Danke fürs Testen @arteck

EvilEls

@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wieder alive und ready.
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.
Habe den Support befragt.

Das es Probleme mit den Dimmern gibt, scheint aber nicht ganz neu:
https://community.openhab.org/t/status-updates-for-qubino-relays-dimmers-generally-do-not-work/32527/280

AlCalzone

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

Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.

Kannste mir davon mal ein Log machen bitte? Und die Cache-Dateien vor dem Backup würde ich auch gerne sehen.

EvilEls

@AlCalzone
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zip

Node 3 steuern über Multi- oder Binary Switch geht nicht.
Config übertragen (zwave2.0.Node_003.Configuration.maximumDimmingValue) scheint zu funktionieren. Wenn auch langsam. Wert steht ein paar Sekunden auf rot bevor Ack kommt.

Hier Log mit gelöschtem Cache: Cache_geloescht.zip
Dimmer nicht steuerbar und auch keine Config übertragbar.

Der Support sagt:

The secure modes in the z-wave are S0, S2 Authenticated and S2 unauthenticated. There was probably a gateway update that cause this as our devices are not updatable remotely.

Gibt es eine Möglichkeit mit zwave-js < 5.2. zu testen?

AlCalzone

@EvilEls Ich glaube nicht, dass irgend eine andere Adapter-Version daran was ändert - die machen die gleichen Abfragen.
Mit den Cache-Dateien aus dem Backup wird zwar versucht, die Security CC zu interviewen, aber selbst darauf antwortet Node 3 nicht mehr. Ich würde den Support mal fragen, wie es sein kann, dass der Node überhaupt keine Security mehr unterstützt (und sonst auch nix).

Falls sie sich selbst vergewissern wollen, das ist was der Node behauptet zu können:

14 bytes:
01 - Start of Frame
0c - 12 bytes follow
00 - type: Request
49 - function type: ApplicationUpdateRequest
84 - update type: NodeInfo_Received
03 - node ID 3
06 - 6 bytes follow
04 - basic device class: Static Controller
11 - generic device class: Multilevel Switch
01 - specific device class: Multilevel Power Switch
5e - CC supported: "Z-Wave Plus Info"
5a - CC supported: "Device Reset Locally"
73 - CC supported: "Powerlevel"
58 - checksum

während es für Node 4 wie folgt aussieht:

15 bytes:
01 - Start of Frame
0d - 13 bytes follow (!)
00 - type: Request
49 - function type: ApplicationUpdateRequest
84 - update type: NodeInfo_Received
04 - node ID 4
07 - 7 bytes follow (!)
04 - basic device class: Static Controller
11 - generic device class: Multilevel Switch
01 - specific device class: Multilevel Power Switch
5e - CC supported: "Z-Wave Plus Info"
5a - CC supported: "Device Reset Locally"
73 - CC supported: "Powerlevel"
98 - CC supported: "Security S0" (!)
c7 - checksum

Es ist also eindeutig, dass Node 3 "vergessen" hat, dass er Security kann. Die Support-Aussage erscheint mir etwas abwimmelnd.

Falls du auf dieser Front nicht weiter kommst, bleibt dir wie ich fürchte nur noch eine Lösung:

Gerät ablernen
Gerät auf Auslieferungszustand zurücksetzen
Gerät wieder anlernen

EvilEls

@AlCalzone
Ich habe nun alles platt gemacht und von NULL angefangen.
Also,

Stick reset
alle Nodes reset
Adapter gelöscht
1.7.4. neu drauf
neu inkludiert

Ich konnte die Problem Nodes 2 und 3 sicher hinzufügen und im Anschluss auch konfigurieren und schalten. Zu sehen in Log.
Leider habe ich nur das Log und vergessen die Cache Dateien zu sichern.
zwave-1712.zip

Dann habe ich eine neue Node inkludiert, die nicht aufgetaucht ist. Deshalb habe ich Instanz neu gestartet und den Cache gelöscht.

Auf einmal funktioniert nur noch Node 3 und Node 2 behauptet wieder keine Secure zu können. Also selber Fehler wie zuvor. Nur jetzt nicht bei beiden, sondern nur einer Node.
neu.zip

EvilEls

@AlCalzone
So, nach dem Cache Löschen war immer wieder eine oder beide neu inkludierte Nodes nicht mehr erreichbar. Node 4 (die mit früheren Versionen gezickt hat und immer wieder dead war) war nur noch manchmal erreichbar/steuerbar, trotz dass sie auf alive stand.

Ich habe nun also alles noch mal platt gemacht (Stick, Nodes, Adapter, pipapo...)
Allerdings habe ich, bevor ich den Adapter auf den Stick losgelassen habe,
zwave-js (in der Version 5.2.2) komplett deinstalliert und die 5.2.0 installiert.

Danach habe ich wieder Node 2, 3 und 4 inkludiert. Und getestet: nach_install.zip
Alles problemlos. MultiLevel Steuerung funzt zuverlässig und sehr schnell. Für alle Nodes. Keine die rumzickt.

Nun habe ich den Cache gelöscht. Interviews sehr schnell. Alle Nodes erreichbar und steuerbar. Steuerung der Multilevel geht zackig. Kein Warten und irgendwann Schalten.
nach_cache_clear.zip

Ich könnte das Ganze noch mal mit zwave-js@5.2.1 testen, aber ich hab heute keinen Bock mehr Steckdosen aufzuschrauben 😋
Wenn du da aber noch mal ein Log brauchst, mach ich dir das gerne morgen.

Ich lass dass Setup jetzt erst mal so und schaue was passiert.

AlCalzone

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

Dann habe ich eine neue Node inkludiert, die nicht aufgetaucht ist. Deshalb habe ich Instanz neu gestartet und den Cache gelöscht.

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

Nun habe ich den Cache gelöscht.

Gefühlt löschst du sehr oft den Cache. Das löscht alle Informationen über alle Nodes und führt dazu, dass alle neu interviewt werden. Wenn dabei einer der Nodes entscheidet, dass er plötzlich keine Security CC mehr kann, stehst du wieder vor der Wand.

Wenn ein Node nach dem Einbinden nicht kommt, reicht es in der Regel, zu warten ihn zu wecken oder den Adapter neu zu starten.

_nico

Habe Version 1.7.4 installiert, läuft scheinbar alles ohne Probleme. DANKE

AlCalzone

v1.7.5 ist da! Changelog wieder oben.

gfrene

Moin Moin zusammen,
ich habe vor kurzen das ABUS CFA3010 bekommen und dachte mir hey das kannste für den Abstellraum nehmen aber ich bekomme es einfach nicht eingebunden.

Z-Wave 2 in IO installiert.

Hardware:
Z-Wave USB Stick (ZMEEUZB1)

Kann mir jemand helfen was ich hier falsch mache ? Falls noch was fehlt bitte bescheid geben. Ich danke euch.

Gruß
Rene

BausSH

Hat außer mir sonst noch jemand die Zipato RGB Bulb 2 im Einsatz? Sie wird im Z-Wave 2-Adapter nicht richtig eingebunden:
Die Datenpunkte scheinen - soweit ich das beurteilen kann - vollständig erzeugt, jedoch werden die Target-Values schreibgeschützt erstellt. Wenn ich das ändere, werden die Eingaben in die Current-Values übernommen, aber ohne dass die Lampe die Farbe ändert.
Ich kann also die Lampe dimmen, aber keine Farbe ändern.
Diesen Fehler habe ich übrigens mit der Version 1.5.1 und nun auch in der 1.7.5.

AlCalzone

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

Kann mir jemand helfen was ich hier falsch mache

Weck das Teil mal manuell auf. Wie das geht, sollte in der Anleitung stehen. Manche Geräte brauchen 1-2 Anläufe, bis das Interview fertig ist.

Falls das alles nicht hilft, wie hier beschrieben ein Log erstellen und posten.

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

jedoch werden die Target-Values schreibgeschützt erstellt

Das dürfte eigentlich nicht sein. Zeig mir mal die ioBroker-Objektdefinition (auf Bleistift, dann auf Reiter "Raw").

Harry94

Hallo,

habe folgendes Problem mit meiner Steinel RS LED D2 Z-Wave.
NODE_027
Sobald ich diese einschalte Spamt Sie so das Netzwerk voll, dass kaum noch andere Befehle durchkommen.

Auszug iobroker Log

zwave2.1	2020-10-12 10:53:07.141	debug	(22492) Node 15: metadata updated: airTemperature
zwave2.1	2020-10-12 10:53:07.084	debug	(22492) Node 15: value updated: overrideState => Unused
zwave2.1	2020-10-12 10:53:07.083	debug	(22492) Node 15: value updated: overrideType => 0
zwave2.1	2020-10-12 10:53:07.026	debug	(22492) Node 15: value updated: setpoint_heating => 4
zwave2.1	2020-10-12 10:53:06.977	debug	(22492) Node 15: value updated: isLow => true
zwave2.1	2020-10-12 10:53:06.973	debug	(22492) Node 15: value updated: level => 0
zwave2.1	2020-10-12 10:51:01.941	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.920	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.899	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.874	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.854	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.834	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.813	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.791	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.771	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.750	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.729	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.708	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.686	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.667	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.645	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.623	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.603	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.581	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.561	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.540	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.519	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.498	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.477	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.456	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.435	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.414	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.393	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.373	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.352	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.330	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.310	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.289	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.268	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.247	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.226	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.205	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.184	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.162	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.142	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.122	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.100	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.078	debug	(22492) Node 27: value updated: currentValue => false
zwave2.1	2020-10-12 10:51:01.059	debug	(22492) Node 27: value updated: currentValue => false

Log Dateien Anbei

201012 Steinel RS LED D2 Harry94.rar

Vielen Dank schonmal

BausSH

@AlCalzone
Hier ist die Anzeige vom target-Value (blue):

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

Community Forum

NEWS

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

Support us

722

32.4k

81.5k

1.3m