Test Adapter Z-Wave 2 (v1.8.x)
-
@alcalzone
ok wird ignoriert (kann ich gut
) -
Thema Gleich Node behalten:
Was für ein trick meinst du genau ?Thema Alias:
meinst du device management ?
Ich habe es getestet, aber das erlaubt nicht die Eingabe aller Parameter, die man verwenden möchte, richtig? die parameter pro "device" sind limitert und festdefniert oder ?
Man kann die parameter hier nicht eintragen
hier auch möchte ich auch gern andere parameter nehmen (akku zustand in %
-
@esmax666 sagte in Test Adapter Z-Wave 2 (v1.8.x):
meinst du device management ?
Nein, ich meine schon "Alias". Eine kurze Forensuche liefert u.a. https://forum.iobroker.net/topic/33747/alias-best-practices-wie-kann-man-es-besser-machen
-
@esmax666 batteriebetrieben .. NEIN
-
@arteck ?? nein was ?
-
Moin,
mein Schloss ABUS CFA3010 wird seit gestern Mittag als 'dead' gelistet und reagiert auf nichts mehr aus dem iobroker.zwave2.0 2021-02-09 07:53:56.280 error (563) Node 89 interview failed: The node is dead zwave2.0 2021-02-09 07:53:43.331 error (563) Node 89 does not support the Command Class Configuration! zwave2.0 2021-02-09 07:53:16.871 info (563) Node 89 is deadHabe zuvor den Wert von zwave2.0.Node_089.Configuration.latchHoldTime auf 0 gesetzt. (Hoffnung war damit das Schloss nur zu öffnen ohne den Schnapper zu ziehen)
Jedoch ist 0 ausserhalb der Parameter:Aus dem RAW-Teil
"min": 1,
"max": 20,Der Wert ist also wieder auf 1 "gesprungen" und ich meine seitdem ist das Schloss tot.
Was hab ich bisher gemacht:
- iobroker neugestartet
- Node neu interviewt.
- Schloss per Hand/Hardware-Button bedient.
- Batterien raus/rein
- Update auf 1.8.10
Mein nächstes Vorgehen wäre ex-/inkludieren, außer jemand hat ne andere Idee.
Nachtrag :
Durch ex-includieren funktioniert es wieder.
-
Benötigen Geräte, die sicher mit S0 und/oder S2 kommunizieren, "viel" mehr RAM?
oder ändert es sich kaum?
Das Hinzufügen eines neuen Geräts erfordert z. B. 10 MB RAM. Das Umschalten auf S0 erfordert z.B 15 MB RAM und S2 40 MB? danke
-
@troya Bitte https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md lesen - insbesondere ganz unten (da wo es um die Logs geht).
@Esmax666 Ich habe den Zusammenhang zwischen RAM und Geräten noch nicht betrachtet. Das hängt eher mit der Anzahl der Datenpunkte zusammen.
-
Hallo,
ich habe ein kleines Problem mit dem Danalock und dem Danapad.
Wenn die Tür abgeschlossen ist und ich von außen mit Danapad entriegele stürzt der Z-Wave2 Adapter ab.
Nach dem Neustart funktioniert alles wie vorher...
-
Wie oft werden diese Datenpunkten aktualisiert ?
Will mir anzeigen lassen wann die Geäte ausfallen, haben den Stecker gezogen nach 30 min immer noch erreichbar und alive.
-
@flopsi sagte in Test Adapter Z-Wave 2 (v1.8.x):
Will mir anzeigen lassen wann die Geäte ausfallen
Die werden nur aktualisiert, wenn der Adapter Nachrichten an die Geräte sendet. Live-Update geht prinzipbedingt nicht.
-
mist ....:)
-
@wellknownasmax Kannst du das Logfile mal herunterladen und hier posten?
Und kannst du bitte mal eine ZWave-Logdatei erstellen, das Problem herbeiführen und ebenfalls hier posten?
==> https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue -
16:59:37.918 CNTRLR [Node 013] [~] [Multilevel Switch] currentValue: 26 => 24 [Endpoint 0] 16:59:37.919 SERIAL » [ACK] (0x06) 16:59:37.920 DRIVER « [Node 013] [REQ] [ApplicationCommand] └─[MultilevelSwitchCCReport] current value: 24 16:59:48.990 SERIAL « 0x010a00040011028407c100a0 (12 bytes) 16:59:48.991 SERIAL » [ACK] (0x06) 16:59:48.991 DRIVER « [Node 017] [REQ] [ApplicationCommand] └─[WakeUpCCWakeUpNotification] 16:59:48.992 CNTRLR « [Node 017] received wakeup notification 16:59:48.993 CNTRLR [Node 017] The node is now awake. 16:59:49.993 CNTRLR » [Node 017] Sending node back to sleep... 16:59:50.000 SERIAL » 0x0109001311028408252877 (11 bytes) 16:59:50.001 DRIVER » [Node 017] [REQ] [SendData] │ transmit options: 0x25 │ callback id: 40 └─[WakeUpCCNoMoreInformation] 16:59:50.003 SERIAL « [ACK] (0x06) 16:59:50.009 SERIAL « 0x0104011301e8 (6 bytes) 16:59:50.010 SERIAL » [ACK] (0x06) 16:59:50.010 DRIVER « [RES] [SendData] was sent: true 16:59:50.029 SERIAL « 0x011800132800000200c17f7f7f7f00000300000000030100001e (26 bytes) 16:59:50.030 SERIAL » [ACK] (0x06) 16:59:50.030 DRIVER « [REQ] [SendData] callback id: 40 transmit status: OK 16:59:50.034 CNTRLR [Node 017] The node is now asleep. 17:00:49.995 SERIAL « 0x010a00040012029840c300fa (12 bytes) 17:00:49.997 SERIAL » [ACK] (0x06) 17:00:49.998 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 17:00:50.010 SERIAL » 0x01110013120a9880c6f8737c0d7062240529db (19 bytes) 17:00:50.011 DRIVER » [Node 018] [REQ] [SendData] │ transmit options: 0x05 │ callback id: 41 └─[SecurityCCNonceReport] nonce: 0xc6f8737c0d706224 17:00:50.014 SERIAL « [ACK] (0x06) 17:00:50.019 SERIAL « 0x0104011301e8 (6 bytes) 17:00:50.020 SERIAL » [ACK] (0x06) 17:00:50.021 DRIVER « [RES] [SendData] was sent: true 17:00:50.185 SERIAL « 0x011800132900001101c47f7f7f7f0001030f0000000201000007 (26 bytes) 17:00:50.186 SERIAL » [ACK] (0x06) 17:00:50.186 DRIVER « [REQ] [SendData] callback id: 41 transmit status: OK 17:00:50.313 SERIAL « 0x0125000400121d9881e1deb84cae0e94dad241faba87797f9d59fbc69e99edb65 (39 bytes) 7fcfb76c400f8 17:00:50.315 SERIAL » [ACK] (0x06) 17:00:50.318 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCCommandEncapsulation] │ sequenced: false └─[NotificationCCReport] notification type: Access Control notification status: 255 notification event: Keypad lock operation 17:00:50.456 SERIAL « 0x010a00040012029840c400fd (12 bytes) 17:00:50.456 SERIAL » [ACK] (0x06) 17:00:50.459 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 17:00:50.467 SERIAL » 0x01110013120a9880d6177db2dc4338f6052a8d (19 bytes) 17:00:50.468 DRIVER » [Node 018] [REQ] [SendData] │ transmit options: 0x05 │ callback id: 42 └─[SecurityCCNonceReport] nonce: 0xd6177db2dc4338f6 17:00:50.470 SERIAL « [ACK] (0x06) 17:00:50.475 SERIAL « 0x0104011301e8 (6 bytes) 17:00:50.475 SERIAL » [ACK] (0x06) 17:00:50.476 DRIVER « [RES] [SendData] was sent: true 17:00:50.607 SERIAL « 0x011800132a00000d01c47f7f7f7f0001030f0000000201000018 (26 bytes) 17:00:50.608 SERIAL » [ACK] (0x06) 17:00:50.608 DRIVER « [REQ] [SendData] callback id: 42 transmit status: OK 17:00:50.701 SERIAL « 0x0123000400121b9881dff663b9c1a0e9eddb2963a18708f083d61466ddc0eb6bb (37 bytes) ed6c40007 17:00:50.702 SERIAL » [ACK] (0x06) 17:00:50.703 CNTRLR [Node 018] [~] [Door Lock] currentMode: 0 => 255 [Endpoint 0] 17:00:50.704 CNTRLR [Node 018] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0] false,false => true,false,false,false 17:00:50.704 CNTRLR [Node 018] [~] [Door Lock] insideHandlesCanOpenDoor: true,false,f [Endpoint 0] alse,false => true,false,false,false 17:00:50.705 CNTRLR [Node 018] [~] [Door Lock] latchStatus: "open" => "closed" [Endpoint 0] 17:00:50.705 CNTRLR [Node 018] [~] [Door Lock] boltStatus: "unlocked" => "locked" [Endpoint 0] 17:00:50.706 CNTRLR [Node 018] [~] [Door Lock] doorStatus: "open" => "closed" [Endpoint 0] 17:00:50.707 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCCommandEncapsulation] │ sequenced: false └─[DoorLockCCOperationReport] current mode: Secured active outside handles: true, false, false, false active inside handles: true, false, false, false latch status: closed bolt status: locked door status: closed 17:01:23.630 SERIAL « 0x010a00040012029840c300fa (12 bytes) 17:01:23.631 SERIAL » [ACK] (0x06) 17:01:23.631 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 17:01:23.637 SERIAL » 0x01110013120a98805b9aa75aa55d67bd052bcd (19 bytes) 17:01:23.638 DRIVER » [Node 018] [REQ] [SendData] │ transmit options: 0x05 │ callback id: 43 └─[SecurityCCNonceReport] nonce: 0x5b9aa75aa55d67bd 17:01:23.640 SERIAL « [ACK] (0x06) 17:01:23.646 SERIAL « 0x0104011301e8 (6 bytes) 17:01:23.646 SERIAL » [ACK] (0x06) 17:01:23.647 DRIVER « [RES] [SendData] was sent: true 17:01:23.770 SERIAL « 0x011800132b00000c01c47f7f7f7f0001030f0000000201000018 (26 bytes) 17:01:23.770 SERIAL » [ACK] (0x06) 17:01:23.771 DRIVER « [REQ] [SendData] callback id: 43 transmit status: OK 17:01:23.897 SERIAL « 0x012d00040012259881a8a4d273dbd4b29918e39697599383ac38dfc6596743940 (47 bytes) ee3625b56a3cf7a98279721c400ff 17:01:23.898 SERIAL » [ACK] (0x06) 17:01:23.902 CNTRLR [Node 018] [~] [User Code] userIdStatus[2]: 1 => 1 [Endpoint 0] 17:01:23.903 CNTRLR [Node 018] [~] [User Code] userCode[2]: "5397" => "5397" [Endpoint 0] 17:01:23.904 DRIVER « [Node 018] [REQ] [ApplicationCommand] └─[SecurityCCCommandEncapsulation] │ sequenced: false └─[NotificationCCReport] notification type: Access Control notification status: 255 notification event: Keypad unlock operation event parameters: [object Object] 17:01:23.955 DRIVER destroying driver instance...Node ID des Danalock ist 018
-
@wellknownasmax Super, danke! Jetzt bräuchte ich noch deinen Netzwerkschlüssel. Kannst du mir per PN schicken.
-
@wellknownasmax Sollte in der nächsten Version gefixt sein. Bin grade noch an nem anderen Problem dran, danach kann ich releasen.
-
1.8.11 auf dem Weg - Changelog oben!
-
Du bist einfach perfekt
-
@alcalzone
funktioniert jetzt fehlerfrei!
Vielen Dank!! -
Hallo an alle,
ich hab mal ein kleines Problem.
Warscheinlich wurde es schon irgendwo beantwortet oder es ist selbsterklähren und ich komm nur einfach nicht drauf. Ich habe bei mir mehrere Fibaro Rauchmelder und diese in ein Skript eingebunden. Gestern, nachdem ich mal ein "Netzwerk heilen" durchlaufen ließ, sind diese Skripte ausgelöst worden.
Bisher haben ich mich als Auslöser auf den Parameter zwave2.0.Node_013.Notification.smokeAlarm_alarmStatus gestützt und hier die abfrage auf "= 0" aufgebaut. Scheinbar hat sich der Wert der hier geschrieben wird geändert oder ich habe, warum auch immer, hier eine falsche annahme getroffen und das ganze falsch abgefragt.
Meine Frage: Wo und wie wird mir denn ein Rauchmelderalarm angezeigt bzw. wo rufe ich diesen ab?
Gruß
Jan
