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

[Gabe]

Hallo zusammen,

Vllt hat jemand von euch eine Idee.

Ich habe bei meinem Fibaro Motion Sensor die Batterie gewechselt, seit dem meldet er keine Bewegung mehr.

Ich habe ihn bereits exkludiert und inkludiert, alle Daten werden gelesen nur das Bewegungobjekt ändert sich nicht.

Hier mal kurzer Ausschnitt aus dem Log

Logs abonniert...2023-06-14T15:10:12.854Z SERIAL « 0x010c00040043063105030a033cb0                                      (14 bytes)2023-06-14T15:10:12.857Z SERIAL » [ACK]                                                                   (0x06)2023-06-14T15:10:12.860Z CNTRLR   [Node 067] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]2023-06-14T15:10:12.861Z CNTRLR   [Node 067] [~] [Multilevel Sensor] Illuminance: 57 => 828         [Endpoint 0]2023-06-14T15:10:12.862Z DRIVER « [Node 067] [REQ] [ApplicationCommand]
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 8282023-06-14T15:10:21.079Z SERIAL « 0x010d00040043079c024300ff000090                                    (15 bytes)2023-06-14T15:10:21.081Z SERIAL » [ACK]                                                                   (0x06)2023-06-14T15:10:21.083Z CNTRLR   [Node 067] [~] [Alarm Sensor] state[0]: true => true              [Endpoint 0]2023-06-14T15:10:21.084Z CNTRLR   [Node 067] [~] [Alarm Sensor] severity[0]: undefined => undefined [Endpoint 0]2023-06-14T15:10:21.085Z CNTRLR   [Node 067] [~] [Alarm Sensor] duration[0]: undefined => undefined [Endpoint 0]2023-06-14T15:10:21.086Z DRIVER « [Node 067] [REQ] [ApplicationCommand]
                                  └─[AlarmSensorCCReport]
                                      sensor type: General Purpose
                                      alarm state: true2023-06-14T15:10:21.099Z SERIAL « 0x010d00040043079c024300ff000090                                    (15 bytes)2023-06-14T15:10:21.100Z SERIAL » [ACK]                                                                   (0x06)2023-06-14T15:10:21.101Z CNTRLR   [Node 067] [~] [Alarm Sensor] state[0]: true => true              [Endpoint 0]2023-06-14T15:10:21.102Z CNTRLR   [Node 067] [~] [Alarm Sensor] severity[0]: undefined => undefined [Endpoint 0]2023-06-14T15:10:21.103Z CNTRLR   [Node 067] [~] [Alarm Sensor] duration[0]: undefined => undefined [Endpoint 0]2023-06-14T15:10:21.104Z DRIVER « [Node 067] [REQ] [ApplicationCommand]
                                  └─[AlarmSensorCCReport]
                                      sensor type: General Purpose
                                      alarm state: true2023-06-14T15:10:24.577Z SERIAL « 0x010c00040043063105030a0020af                                      (14 bytes)2023-06-14T15:10:24.579Z SERIAL » [ACK]                                                                   (0x06)2023-06-14T15:10:24.581Z CNTRLR   [Node 067] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]2023-06-14T15:10:24.582Z CNTRLR   [Node 067] [~] [Multilevel Sensor] Illuminance: 828 => 32         [Endpoint 0]2023-06-14T15:10:24.584Z DRIVER « [Node 067] [REQ] [ApplicationCommand]
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 32

Hatbje,and evtl. Eine Idee?

Update leider ändert sich der State weiterhin nicht

2023-06-21T15:43:52.654Z SERIAL « 0x010d00040047079c024700ff000090                                    (15 bytes)2023-06-21T15:43:52.661Z SERIAL » [ACK]                                                                   (0x06)2023-06-21T15:43:52.669Z CNTRLR   [Node 071] [~] [Alarm Sensor] state[0]: true => true              [Endpoint 0]2023-06-21T15:43:52.671Z CNTRLR   [Node 071] [~] [Alarm Sensor] severity[0]: undefined => undefined [Endpoint 0]2023-06-21T15:43:52.673Z CNTRLR   [Node 071] [~] [Alarm Sensor] duration[0]: undefined => undefined [Endpoint 0]2023-06-21T15:43:52.677Z DRIVER « [Node 071] [REQ] [ApplicationCommand]
                                  └─[AlarmSensorCCReport]
                                      sensor type: General Purpose
                                      alarm state: true2023-06-21T15:43:52.682Z SERIAL « 0x010d00040047079c024700ff000090                                    (15 bytes)2023-06-21T15:43:52.683Z SERIAL » [ACK]                                                                   (0x06)2023-06-21T15:43:52.685Z CNTRLR   [Node 071] [~] [Alarm Sensor] state[0]: true => true              [Endpoint 0]2023-06-21T15:43:52.687Z CNTRLR   [Node 071] [~] [Alarm Sensor] severity[0]: undefined => undefined [Endpoint 0]2023-06-21T15:43:52.689Z CNTRLR   [Node 071] [~] [Alarm Sensor] duration[0]: undefined => undefined [Endpoint 0]2023-06-21T15:43:52.691Z DRIVER « [Node 071] [REQ] [ApplicationCommand]
                                  └─[AlarmSensorCCReport]
                                      sensor type: General Purpose
                                      alarm state: true
ˋˋˋ

hat da jemand eine Idee alle anderen States ändern sich…

Danke

[peppino]

Hallo,
Ich habe von einen ZME-UZB1 ein NVM Backup gemacht und auf einen Aeotec Z-Stick Gen5 übertragen.
Im Iobroker Adapter wird bei Node 1 aber noch der ZME-UZB1 angeführt. Sämtliche Z-Wave Teilnehmer funktionieren aber ganz normal. Wie bekommt man den Node 1 auf den Aeotec Z-Stick.

Bg
Josef

[jupzup]

@AlCalzone
Kurze Frage kommen eigentlich keine weiteren Updates mehr für ioBroker zwave-js ist ja mittlerweile schon in der Version 11.5.3 ?

[Tobias 0]

@peppino Hallo Peppino, könntest du kurz erklären wie das vorgehen mit dem NVM Backup durchgeführt wird. Ich würde gerne auf einen Z-Stick 7 umsteigen.
Dankeschön

[Tobias 0]

Gleiche Frage nochmals an alle: Hat jemand schon erfolgreich die Zwave Stick umgezogen von z.B. Aeotec Z-Stick Gen 5 auf die erwähnten 700 und eine kurze Anleitung dazu?
Gruß Tobias

[Flopsi]

Hat wer den Aeotec MultiSensor 7 im Einsatz ?

[gelberlemmy]

Guten Morgen,

ich habe schon ein wenig gesucht und noch nicht wirklich etwas passendes gefunden. Ich habe bei einem test festgestellt, dass sich ein Rauchmelder von Fibaro aus dem Zwave Netzwerk verabschiedet hat. Wobei dieser unter dem Datenpunkt als "ready" und unter Status als "asleep" steht. Stelle bei den Dingern auch fest, dass diese immer 100% Batterie anzeigen, was echt doof ist.
Gibt es eine Möglichkeit die Geräte zu überwachen ? Muss ich dafür eventuell in der Config der Geräte das Wakeup ändern ? Wobei das ja dann zur schnelleren Entleerung der Batterie führt.

Oder wie habet Ihr das gelöst. Ist blöd, wenn einfach so ein Gerät aussteigt.

Und wo bekomme ich für Fibaro Aeontec Geräte etc die aktuellen FW her ? Eventuell muss auch einmal diese Updaten.

Gruß André

[arteck]

@gelberlemmy die müssen doch piepen wenn die Batterie leer wird.. alo meine tun es..
ja du kannst den wake up intervall verkürzen .. aber dann wird die Batterie schneller leer

[gelberlemmy]

@arteck ja das tun Sie auch. Das blöde ist nur, meistens in der Nacht. Findet meine Familie dann nicht so charmant. Würde natürlich vorher schon diese tauschen.

Aber der eine Rauchmelder war komplett vom Adapter getrennt. Dieser hatte noch als Stand Alone funktioniert. Musste neu eingelernt werden.

[arteck]

@gelberlemmy hmm.. komisch. ich hab auch paar von den Teilen hier. aber nää noch nie passiert

ich hab mir aber damit ich wenn sowas passiert in der VIS

eingebaut.. dass ich manuell hochsetzte wenn ich was ins Netznehme .. der rest läuft über den Device-watcher

[gelberlemmy]

@arteck ja den Device Watcher habe ich mir auch einmal installiert. Den muss ich noch einmal korrekt einstellen. Aber wie ist denn bei Dir der Batterie Datenpunkt. Wird da dies korrekt angezeigt ? Ich habe bei den RM immer 100 %

[arteck]

@gelberlemmy joa

[Esmax666]

@tobias-0 said in Test Adapter Z-Wave 2 v3.0.x:

Ich würde gerne auf einen Z-Stick 7 umsteigen.

Hi, wie hast du das gemacht ? was sind die vorteile mit Z-Stick 7 ? (Statt Aeotec Z-Stick Gen)

[Esmax666]

Kann mir jemand helfen ?

ich habe die Kommunikation mit 2 ZWave-Geräten - TechniSat 0300/9496 verloren

Was ist das Problem?
Es kommt vor, dass mein Wave-Schalter nach einiger Zeit keine Verbindung mehr herstellen kann. Ich muss meinen Wave-Schalter zurücksetzen, damit die Kommunikation wieder funktioniert.
Haben Sie eine Idee, woher der Verlust kommt?

Ist es möglich, das Gerät zurückzusetzen und die Knotennummer, die ich derzeit habe, zu behalten (das erspart mir, meine Konfiguration zu ändern)?

danke
hier ist das PRoblem für Node 29/30:

Welches Gerät ist betroffen?
Beide: TechniSat 0300/9496
zwave2.0.Node_029
zwave2.0.Node_030

on the iobroker log we can see this error:
zwave2.0 | 2023-10-01 09:00:13.393 | error | Timeout while waiting for an ACK from the controller (ZW0200)

oldlog.zip

json.zip

zwave_2023-12-11_12-14-48-988.log

[Berges01]

@esmax666

Hallo

Das hatte ich auch mal, da hilft es etweder den Betreffenden Node zu resetten und nicht exkludieren, dann den Node in der Instanz zu ersetzen.
Dann nimmt der Node wieder die selbe Nummer an. (Erst mal bei einem einfachen das Probieren damit du etwas Routine darin bekommst).
Ich gabe alle Skripte nicht direkt auf die Geräte Objekte verknüpft sondern auf Alias.
Dann kannst du die Nodes einfach tauschen ohne die Skripte zu verändern.
Auch ein ändern von z-wave auf Shelly oder zigbee ist dann schnell möglich, einfach den Bezug tauschen und alles Andere kann bleiben wie es ist.

Grüße aus dem Sauerland

[Esmax666]

@berges01

Wie/Wo geht das mit "Reset"? meinst du "Refresh node info" ?

ich habe ein refresh all gemacht aber das ist seltsam, er zeigt das man kein Problem mehr hat, aber die verbindung geht trotzdem nicht

timestamp ist noch von Juni

Command geht auch nicht raus, kein reaktion von rollo ...

aber laut Zwave adapter ist er "live"

und replace ist nicht mehr möglich ...

hier bekommt er auch kein antwort:

Subscribed to logs...

2023-12-11T14:51:50.477Z CNTRLR   [Node 029] Beginning interview - last completed stage: None

2023-12-11T14:52:00.533Z CNTRLR   No response from controller after 1/3 attempts. Scheduling next try in 100 ms.

2023-12-11T14:52:01.644Z CNTRLR   Failed to execute controller command after 2/3 attempts. Scheduling next try i
                                  n 1100 ms.

2023-12-11T14:52:02.748Z SERIAL » 0x010400601d86                                                       (6 bytes)

2023-12-11T14:52:08.074Z SERIAL « 0x01040160019b                                                       (6 bytes)

2023-12-11T14:52:18.795Z CNTRLR   No response from controller after 1/3 attempts. Scheduling next try in 100 ms.

2023-12-11T14:52:19.904Z CNTRLR   Failed to execute controller command after 2/3 attempts. Scheduling next try i
                                  n 1100 ms.

2023-12-11T14:52:21.007Z SERIAL » 0x010400601d86                                                       (6 bytes)

2023-12-11T14:52:21.011Z DRIVER » [Node 029] [REQ] [RequestNodeInfo]
                                    node id: 29

2023-12-11T14:52:26.340Z SERIAL « 0x01040160019b                                                       (6 bytes)

2023-12-11T14:52:29.607Z SERIAL « 0x0106004981000031                                                   (8 bytes)

2023-12-11T14:52:30.436Z SERIAL » [ACK]                                                                   (0x06)

2023-12-11T14:52:30.438Z DRIVER « [REQ] [ApplicationUpdateRequest]
                                    payload: 0x0000

2023-12-11T14:52:32.027Z CNTRLR   [Node 029] Beginning interview - last completed stage: ProtocolInfo

2023-12-11T14:52:42.052Z CNTRLR   No response from controller after 1/3 attempts. Scheduling next try in 100 ms.

2023-12-11T14:52:43.162Z CNTRLR   Failed to execute controller command after 2/3 attempts. Scheduling next try i
                                  n 1100 ms.

2023-12-11T14:52:44.266Z SERIAL » 0x010400601d86                                                       (6 bytes)

2023-12-11T14:52:44.270Z DRIVER » [Node 029] [REQ] [RequestNodeInfo]
                                    node id: 29

2023-12-11T14:52:45.280Z CNTRLR   [Node 029] Interview attempt 3/5 failed, retrying in 15000 ms...

2023-12-11T14:52:49.598Z SERIAL « 0x01040160019b                                                       (6 bytes)

2023-12-11T14:52:53.739Z SERIAL « 0x0106004981000031                                                   (8 bytes)

2023-12-11T14:52:53.743Z SERIAL » [ACK]                                                                   (0x06)

2023-12-11T14:52:53.745Z DRIVER « [REQ] [ApplicationUpdateRequest]
                                    payload: 0x0000

2023-12-11T14:53:00.283Z CNTRLR   [Node 029] Beginning interview - last completed stage: ProtocolInfo

2023-12-11T14:53:10.313Z CNTRLR   No response from controller after 1/3 attempts. Scheduling next try in 100 ms.

[Berges01]

@esmax666

Reset direkt am Gerät (Node) meist Werksreset also hartes endfernen aus dem Netz ohne dei Informationen auf den z-wave Hub zu endfernen.
Dann

mit ausgefallenes Gerät ersetzen das Gleiche Gerät wieder anlernen.

Wie gesagt erst mal ausprobieren damit du das schon mal gemacht hast.
Ist aber eigendlich einfach.
So wird ein Gerät ersetzt ohne das die Nodenummer wieder erneuert wird und du eventuell Scripte umschreiben musst.

Das mit dem Netzwerk heilen ist hier zu finden,

[Esmax666]

@berges01

bei mir ist das jetzt grau

übrigens wie kann man die name ändern ? (hier zum beispiel eurotronics Spirit)

[Berges01]

@esmax666
So sieht einer bei mir aus :

das ist OK, so lange hinten das Funksymbol nicht rot und durchgestrichen ist.

[Esmax666]

@berges01 aber das ist nicht ok für mich weil ich habe kein kommunikation und trotdem ist es ok,

nach Zwave adapter neu start zeigt er mich für ein das Problem

wirklich ganz seltsam, ok ich kann jetzt ein "replace" machen

wie soll ich das am besten machen ? Das Gerät ist circa 8 meter entfernt also USB Aeotec Z-stick einfach so ausstecken und dort pairing machen und wieder einsteken geht nicht oder?