NEWS
Test Adapter Z-Wave 2 (v1.7.x)
Test Adapter Z-Wave 2 (v1.7.x)
-
@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
@AlCalzone
Moin,ich habe jetzt mal zwei Tage lang eine Log schreiben lassen. Devolo Raumthermoastat steht immer noch auf false.
Node ID: 035
Da ich hier nur 5Mb hochladen kann habe ich die Datein bei Dropbox hochgeladen
zwave-11037.log@AlCalzone
Hast du mich überlesen?@Domoe Ja hatte ich tatsächlich. Problem gefunden:
Das Gerät unterstütztCentral Scene CC, antwortet aber nicht auf die nötige Abfrage der unterstützten Szenen, was das Interview abbrechen lässt.
Sollte sich relativ leicht beheben lassen - nur werden dann die Szenen nicht vorangelegt. -
@Domoe Ja hatte ich tatsächlich. Problem gefunden:
Das Gerät unterstütztCentral Scene CC, antwortet aber nicht auf die nötige Abfrage der unterstützten Szenen, was das Interview abbrechen lässt.
Sollte sich relativ leicht beheben lassen - nur werden dann die Szenen nicht vorangelegt.@AlCalzone
Das heißt, wenn man das Gerät neu anlernt dann erstellt es die einzelne Objekte nicht?
Verstehe ich das richtig? -
@AlCalzone
Das heißt, wenn man das Gerät neu anlernt dann erstellt es die einzelne Objekte nicht?
Verstehe ich das richtig? -
@Domoe Ja, du hast dann anfangs keine einzelnen Datenpunkte für die einzelnen Scenes
zwave2.0.Central_Scene. Die werden aber jeweils angelegt, sobald eine Benachrichtigung über Szenenbetätigung kommt.Ok, vielen Dank für deine Erklärung.
-
@jrgsch sagte in Test Adapter Z-Wave 2 (v1.7.x):
Welche Strategie verfolgt der Adapter, um "tote" Geräte wieder ran zubekommen?
Eine echte Strategie gibts da nicht. Neuerdings werden als tot markierte Geräte vor einem Befehl gepingt, um zu sehen, ob sich nicht doch reagieren. Das sollte viele temporäre Ausfälle abdecken.
Ansonsten muss sich der Adapter auf die Reorganisation des Meshs (Netzwerk heilen) verlassen. Dabei suchen alle erreichbaren Nodes, welche anderen in ihrer Nähe sind. Spätestens wenn die "toten" dabei gefunden werden, sollte auch eine Kommunikation möglich sein.
Ist das Netzwerk Heilen denn bei dir durchgelaufen?@AlCalzone
Ich habe 3 gleiche Motion Sensoren neu angelernt, bei einem sind sofort alle Objekte da, bei den zwei weiteren fehlen einige, u.a. komplett "Configuration". Jetzt habe ich mich mehrere Tage in Geduld geübt, um den Sensoren die Chance zu geben, ihre Daten nach Aufwachen loszuwerden. Bisher Fehlanzeige. Die Einstellung "Datenpunktnamen nicht überschreiben" habe ich aktiviert, da ich meinen Z-Wave Module sprechende Namen gebe. Ich gehe aber davon aus, dass das nicht das Anlegen neuer Objekte verhindert.Irgendeinen Tipp?
-
@AlCalzone
Ich habe 3 gleiche Motion Sensoren neu angelernt, bei einem sind sofort alle Objekte da, bei den zwei weiteren fehlen einige, u.a. komplett "Configuration". Jetzt habe ich mich mehrere Tage in Geduld geübt, um den Sensoren die Chance zu geben, ihre Daten nach Aufwachen loszuwerden. Bisher Fehlanzeige. Die Einstellung "Datenpunktnamen nicht überschreiben" habe ich aktiviert, da ich meinen Z-Wave Module sprechende Namen gebe. Ich gehe aber davon aus, dass das nicht das Anlegen neuer Objekte verhindert.Irgendeinen Tipp?
-
@AlCalzone
Ich habe 3 gleiche Motion Sensoren neu angelernt, bei einem sind sofort alle Objekte da, bei den zwei weiteren fehlen einige, u.a. komplett "Configuration". Jetzt habe ich mich mehrere Tage in Geduld geübt, um den Sensoren die Chance zu geben, ihre Daten nach Aufwachen loszuwerden. Bisher Fehlanzeige. Die Einstellung "Datenpunktnamen nicht überschreiben" habe ich aktiviert, da ich meinen Z-Wave Module sprechende Namen gebe. Ich gehe aber davon aus, dass das nicht das Anlegen neuer Objekte verhindert.Irgendeinen Tipp?
-
@jrgsch Bitte die folgenden Infos liefern:
https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue@AlCalzone : Danke diesen link hab ich gesucht

Das plugin (verwende noch 1.7.5) funktioniert richtig gut mit die meiste meine z-wave modulen

Nur 1 (von 8 ) Fibaro FGK-101 Tur/Fenster sensoren gibt leider nicht alle daten. Es funktionieren die tur erkennung und tamper, nur gibt er nicht alle weitere info's (wie zum beispiel batterie). Die andere 7 funktionieren einwandfrei.

Im log steht:
08:55:54.023 CNTRLR [Node 036] Beginning interview - last completed stage: None
08:55:54.024 CNTRLR [Node 036] new node, doing a full interview...
08:55:54.024 CNTRLR » [Node 036] querying protocol info...
08:55:54.033 SERIAL » 0x01040041249e (6 bytes)
08:55:54.035 DRIVER » [REQ] [GetNodeProtocolInfo]
payload: 0x24
08:55:54.042 SERIAL « [ACK] (0x06)
08:55:54.044 SERIAL « 0x01090141539c010407017a (11 bytes)
08:55:54.044 SERIAL » [ACK] (0x06)
08:55:54.046 DRIVER « [RES] [GetNodeProtocolInfo]
payload: 0x539c01040701
08:55:54.051 CNTRLR « [Node 036] received response for protocol info:
basic device class: Static Controller
generic device class: Notification Sensor
specific device class: Notification Sensor
is a listening device: false
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
08:55:54.052 CNTRLR [Node 036] The node is now awake.
08:55:54.057 CNTRLR [Node 036] Interview stage completed: ProtocolInfo
08:55:54.061 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.065 CNTRLR [Node 036] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
08:55:54.066 CNTRLR » [Node 036] pinging the node...
08:55:54.568 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.570 CNTRLR [Node 036] did not respond after 2/3 attempts. Scheduling next try in 500 ms.
08:55:55.073 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!]
08:55:55.098 SERIAL » 0x01080013240100255fbb (10 bytes)
08:55:55.099 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 95
└─[NoOperationCC]
08:55:55.099 CNTRLR [Node 036] The node is not included securely. Continuing interview non-securel
y.
08:55:55.100 CNTRLR [Node 036] WakeUpCC: doing a complete interview...
08:55:55.100 CNTRLR » [Node 036] retrieving wakeup interval from the device...
08:55:55.103 SERIAL « [ACK] (0x06)
08:55:55.106 SERIAL « 0x0104011301e8 (6 bytes)
08:55:55.107 SERIAL » [ACK] (0x06)
08:55:55.108 DRIVER « [RES] [SendData]
was sent: true
08:56:01.922 SERIAL « 0x010700135f0102aa1d (9 bytes)
08:56:01.923 SERIAL » [ACK] (0x06)
08:56:01.925 DRIVER « [REQ] [SendData]
callback id: 95
transmit status: NoAck
08:56:01.938 SERIAL » 0x01090013240272042560f0 (11 bytes)
08:56:01.939 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 96
└─[ManufacturerSpecificCCGet]
08:56:01.940 CNTRLR [Node 036] The node did not respond after 1 attempts.
It is probably asleep, moving its messages to the wakeup queue.
08:56:01.941 CNTRLR [Node 036] The node is now asleep.
08:56:01.944 CNTRLR [Node 036] ping failed: Failed to send the command after 1 attempts (Status No
Ack)
08:56:01.945 CNTRLR » [Node 036] querying node info...
08:56:01.955 SERIAL « [ACK] (0x06)
08:56:01.958 SERIAL « 0x0104011301e8 (6 bytes)
08:56:01.959 SERIAL » [ACK] (0x06)
08:56:01.961 DRIVER « [RES] [SendData]
was sent: true
08:56:08.672 SERIAL « 0x01070013600102a028 (9 bytes)
08:56:08.672 SERIAL » [ACK] (0x06)
08:56:08.673 DRIVER « [REQ] [SendData]
callback id: 96
transmit status: NoAckWurde ein upgrade auf 1.7.8 helfen? Ich hab auch noch ein Fibaro rauchmelder die sich ahnlich verhalt, da muss ich mir das log noch mal anschauen. Ein 2e rauchmelder bleibt immer wach (und damit mit batterie nutzlos)
Danke fur die sehr gute arbeit!
-
@AlCalzone : Danke diesen link hab ich gesucht

Das plugin (verwende noch 1.7.5) funktioniert richtig gut mit die meiste meine z-wave modulen

Nur 1 (von 8 ) Fibaro FGK-101 Tur/Fenster sensoren gibt leider nicht alle daten. Es funktionieren die tur erkennung und tamper, nur gibt er nicht alle weitere info's (wie zum beispiel batterie). Die andere 7 funktionieren einwandfrei.

Im log steht:
08:55:54.023 CNTRLR [Node 036] Beginning interview - last completed stage: None
08:55:54.024 CNTRLR [Node 036] new node, doing a full interview...
08:55:54.024 CNTRLR » [Node 036] querying protocol info...
08:55:54.033 SERIAL » 0x01040041249e (6 bytes)
08:55:54.035 DRIVER » [REQ] [GetNodeProtocolInfo]
payload: 0x24
08:55:54.042 SERIAL « [ACK] (0x06)
08:55:54.044 SERIAL « 0x01090141539c010407017a (11 bytes)
08:55:54.044 SERIAL » [ACK] (0x06)
08:55:54.046 DRIVER « [RES] [GetNodeProtocolInfo]
payload: 0x539c01040701
08:55:54.051 CNTRLR « [Node 036] received response for protocol info:
basic device class: Static Controller
generic device class: Notification Sensor
specific device class: Notification Sensor
is a listening device: false
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
08:55:54.052 CNTRLR [Node 036] The node is now awake.
08:55:54.057 CNTRLR [Node 036] Interview stage completed: ProtocolInfo
08:55:54.061 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.065 CNTRLR [Node 036] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
08:55:54.066 CNTRLR » [Node 036] pinging the node...
08:55:54.568 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.570 CNTRLR [Node 036] did not respond after 2/3 attempts. Scheduling next try in 500 ms.
08:55:55.073 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!]
08:55:55.098 SERIAL » 0x01080013240100255fbb (10 bytes)
08:55:55.099 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 95
└─[NoOperationCC]
08:55:55.099 CNTRLR [Node 036] The node is not included securely. Continuing interview non-securel
y.
08:55:55.100 CNTRLR [Node 036] WakeUpCC: doing a complete interview...
08:55:55.100 CNTRLR » [Node 036] retrieving wakeup interval from the device...
08:55:55.103 SERIAL « [ACK] (0x06)
08:55:55.106 SERIAL « 0x0104011301e8 (6 bytes)
08:55:55.107 SERIAL » [ACK] (0x06)
08:55:55.108 DRIVER « [RES] [SendData]
was sent: true
08:56:01.922 SERIAL « 0x010700135f0102aa1d (9 bytes)
08:56:01.923 SERIAL » [ACK] (0x06)
08:56:01.925 DRIVER « [REQ] [SendData]
callback id: 95
transmit status: NoAck
08:56:01.938 SERIAL » 0x01090013240272042560f0 (11 bytes)
08:56:01.939 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 96
└─[ManufacturerSpecificCCGet]
08:56:01.940 CNTRLR [Node 036] The node did not respond after 1 attempts.
It is probably asleep, moving its messages to the wakeup queue.
08:56:01.941 CNTRLR [Node 036] The node is now asleep.
08:56:01.944 CNTRLR [Node 036] ping failed: Failed to send the command after 1 attempts (Status No
Ack)
08:56:01.945 CNTRLR » [Node 036] querying node info...
08:56:01.955 SERIAL « [ACK] (0x06)
08:56:01.958 SERIAL « 0x0104011301e8 (6 bytes)
08:56:01.959 SERIAL » [ACK] (0x06)
08:56:01.961 DRIVER « [RES] [SendData]
was sent: true
08:56:08.672 SERIAL « 0x01070013600102a028 (9 bytes)
08:56:08.672 SERIAL » [ACK] (0x06)
08:56:08.673 DRIVER « [REQ] [SendData]
callback id: 96
transmit status: NoAckWurde ein upgrade auf 1.7.8 helfen? Ich hab auch noch ein Fibaro rauchmelder die sich ahnlich verhalt, da muss ich mir das log noch mal anschauen. Ein 2e rauchmelder bleibt immer wach (und damit mit batterie nutzlos)
Danke fur die sehr gute arbeit!
@AlCalzone : Beim versuch mit der Rauchmelder hat's dann auf einmal funktioniert (paar mal tamper taste gedruckt) und der ist dann angefangen seine konfiguration zu senden
Hab das noch ein mal mit der tur sensor getan (hatte das vorher ohne erfolg versucht) und sehe da auf einmal funktioniert er 
Hab jetzt aber das probleem das 2 rauchmelder immer awake bleiben. Hab die geraten auch schon auf factory default gereset aber das bringt leider nichts. Kann dein adapter da helfen oder liegt das einfach an die geraten?
-
@AlCalzone : Beim versuch mit der Rauchmelder hat's dann auf einmal funktioniert (paar mal tamper taste gedruckt) und der ist dann angefangen seine konfiguration zu senden
Hab das noch ein mal mit der tur sensor getan (hatte das vorher ohne erfolg versucht) und sehe da auf einmal funktioniert er 
Hab jetzt aber das probleem das 2 rauchmelder immer awake bleiben. Hab die geraten auch schon auf factory default gereset aber das bringt leider nichts. Kann dein adapter da helfen oder liegt das einfach an die geraten?
Es sind alle Fibaro FGSS001 Rauchmelder, sind laut Manufacturing information gleich, aber unterscheiden sich:
Ein funktionierende FGSS001:

Bemerke ControllerNodeId beim Wakeup (1)Der erste FGSS001 die bleibt alive:

Hier steht ControllerNodeId auf 255 ! obwohl manufacturing specific und version gleich sind. Ich kann diesen wert auch nicht andernDer 3e FGSS001 gibt uberhaupt keine Wakeup informationen (vielleicht weil der batterie schnell lehr ist)

Ich habe mal das log file vom node 038 dran gehangt und ein paar batterie punkten rot markiert. Vielleicht gibt's da eine losung?
-
Es sind alle Fibaro FGSS001 Rauchmelder, sind laut Manufacturing information gleich, aber unterscheiden sich:
Ein funktionierende FGSS001:

Bemerke ControllerNodeId beim Wakeup (1)Der erste FGSS001 die bleibt alive:

Hier steht ControllerNodeId auf 255 ! obwohl manufacturing specific und version gleich sind. Ich kann diesen wert auch nicht andernDer 3e FGSS001 gibt uberhaupt keine Wakeup informationen (vielleicht weil der batterie schnell lehr ist)

Ich habe mal das log file vom node 038 dran gehangt und ein paar batterie punkten rot markiert. Vielleicht gibt's da eine losung?
-
@wykat : Hier der anhang als PDF....
@wykat Puh, das ist eine chaotische Meldung.
Bitte:
- Update auf 1.7.10 um auszuschließen, dass wir Geister jagen
- Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung
- Geräte, bei denen
readyauftruesteht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen. - Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.
-
@wykat Puh, das ist eine chaotische Meldung.
Bitte:
- Update auf 1.7.10 um auszuschließen, dass wir Geister jagen
- Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung
- Geräte, bei denen
readyauftruesteht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen. - Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
@wykat Puh, das ist eine chaotische Meldung.
Bitte:
- Update auf 1.7.10 um auszuschließen, dass wir Geister jagen
Gemacht, aber leider keine verbesserung
- Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung
Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?
- Geräte, bei denen
readyauftruesteht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen.
Ja das hab ich schon mehrmals gemacht (man sieht im log was alles ausgetauscht wird zwischen zWave stick und die rauchmelder
- Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.
Ich hab 3 Fibaro FGSS001 rauchmelder die alle 3 behaupten identisch zu sein (gleiche firmware, library, etc.):
Node4: Funktioniert einwandfrei
Node29: Bleibt immer 'alive', sowohl im zWave2 instance als im objects. Hab kein eintrag im log gefunden das Node29 'asleep' gegangen ist. Beim Node29 fehlt immer noch die option Wake_up (ist bei Nodes 4 und 38 da).


Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist. Hab jetzt mal eine neue batterie installiert aber denke der wird auch wieder schnell lehr sein.


-
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
@wykat Puh, das ist eine chaotische Meldung.
Bitte:
- Update auf 1.7.10 um auszuschließen, dass wir Geister jagen
Gemacht, aber leider keine verbesserung
- Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung
Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?
- Geräte, bei denen
readyauftruesteht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen.
Ja das hab ich schon mehrmals gemacht (man sieht im log was alles ausgetauscht wird zwischen zWave stick und die rauchmelder
- Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.
Ich hab 3 Fibaro FGSS001 rauchmelder die alle 3 behaupten identisch zu sein (gleiche firmware, library, etc.):
Node4: Funktioniert einwandfrei
Node29: Bleibt immer 'alive', sowohl im zWave2 instance als im objects. Hab kein eintrag im log gefunden das Node29 'asleep' gegangen ist. Beim Node29 fehlt immer noch die option Wake_up (ist bei Nodes 4 und 38 da).


Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist. Hab jetzt mal eine neue batterie installiert aber denke der wird auch wieder schnell lehr sein.


@wykat sagte in Test Adapter Z-Wave 2 (v1.7.x):
Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?
Jup, einfach hier im Forum hochladen.
@wykat sagte in Test Adapter Z-Wave 2 (v1.7.x):
Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist.
Das könnte ein Anzeigefehler im Admin sein. Bei den anderen ist definitiv was faul.
-
@wykat sagte in Test Adapter Z-Wave 2 (v1.7.x):
Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?
Jup, einfach hier im Forum hochladen.
@wykat sagte in Test Adapter Z-Wave 2 (v1.7.x):
Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist.
Das könnte ein Anzeigefehler im Admin sein. Bei den anderen ist definitiv was faul.
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
@wykat sagte in Test Adapter Z-Wave 2 (v1.7.x):
Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?
Jup, einfach hier im Forum hochladen.
Anbei, danke!
zwave-12345.log -
Aktuelle Test Version 1.7.8 Veröffentlichungsdatum 25.10.2020 Github Link https://github.com/AlCalzone/ioBroker.zwave2/ Changelog
Ich habe ja schon länger angekündigt, dass ich den Adapter bzw. die zugrundeliegende Library in großem Stil umschreibe. Das wichtigste hiervon (Änderung von knapp 10.000 Code-Zeilen) ist seit heute soweit, dass es überhaupt wieder läuft und einem Alpha-Test unterzogen werden kann. Ein paar Änderungen in dieser Richtung kommen noch, aber das ist etwas für eine 1.8 oder später.Was heißt das effektiv für euch als Nutzer?
- Der Nachrichtenfluss sowie die Status-Verwaltung der Nodes wird jetzt durch eine State-Machine abgebildet, sodass jederzeit definiert ist, in welchem Zustand man sich befindet und welche Übergänge in andere Zustände möglich sind.
Einfach mal hängen bleiben sollte damit der Vergangenheit angehören. - Die Priorisierung von Nachrichten wurde optimiert. D.h. ihr könnt eure Geräte jetzt auch schalten, während andere noch fleißig interview werden, und trotzdem eine zeitnahe Reaktion sehen.
- Weitere Performance-Optimierung (über das hinaus, was schon in 1.6.x eingeflossen ist)
Ich freue mich über mutige Tester. Wer Stabilität will und keine Probleme hat, sollte aber erst mal bei 1.6.x bleiben.
Update 1.7.0-alpha.3:
Ich habe erneut nochmal rund 3000 Code-Zeilen umgeschrieben. Hiermit sollte der Umgang mit sicher eingebundenen Geräten etwas flexibler sein und die oben beschriebenen dead-alive-Probleme hoffentlich weg sein. @EvilEls @Chris_78 @Harry94
Weitere Änderungen:
-
Konfigurationsdateien für
ABUS CFA3010undEverspring AC301hinzugefügt. -
Statt einer echten seriellen Schnittstelle kann jetzt auch eine im Netzwerk verfügbare serielle Schnittstelle genutzt werden. @arteck
Hierzu den Adapter stoppen und ins "Port"-Feld die Adresse in der Form
tcp://hostname:porteingeben. Eine vernünftige Eingabemöglichkeit für diese Adressen folgt noch.
Ein solcher Netzwerkport kann z.B. auf Linux mitser2netzur Verfügung gestellt werden. Hierzu folgende Konfiguration nutzen (mit ersetzten Platzhaltern):<port>:raw:0:<serieller-pfad>:115200 8DATABITS NONE 1STOPBIT
Update 1.7.0-alpha.5:
- Die Eingabe der seriellen Schnittstelle ist jetzt als Textfeld mit auto-complete möglich.
- Fix für Geräte, die Basic CC für Aktualisierungen nutzen
Update 1.7.0-alpha.7:
- Die unzähligen Warnmeldungen bezüglich
qsollten jetzt weg sein. - Crash behoben, der beim Dekodieren bestimmter partieller Nachrichten auftreten konnte, wenn der Treiber noch nicht so weit ist. @arteck
Update 1.7.0:
- Der Adapter startet sich jetzt nach 1 Sekunde neu, wenn das Starten des Treibers fehlschlägt.
- Es wurde ein Problem der alpha-Version behoben, dass ein Node beim erneuten Interview sofort als bereit markiert und alle States gelöscht wurden.
Update 1.7.1:
- Nodes sollten jetzt nicht mehr als tot/schlafend markiert werden, wenn sie zwar den Empfang einer Nachricht bestätigen, aber nicht auf diese antworten.
- Unterstützung für
User Code CChinzugefügt - Zwei Optionen zum Erhöhen der Timeouts und Sendeversuche hinzugefügt, die die Zuverlässigkeit in instabilen Netzen erhöhen können. Dies geht jedoch mit trägerer Kommunikation einher.
Update 1.7.2:
- Option hinzugefügt, um die Kompatibilität mit älteren Switches zu verbessern. Ich bin nicht sicher, ob es sinnvoll ist, das global zu machen, daher erst mal als (standardmäßig ausgeschaltete) Option. Wenn diese aktiviert ist, wird
targetValuebei Binary und Multilevel Switches immer mitcurrentValueüberschrieben:

@Flopsi hab mich spontan doch entschieden, das mal auszuprobieren
- Bei Netzwerkheilung sollte der Fortschritt jetzt sofort erscheinen, nicht erst, nachdem der erste Node fertig ist
- Zwei mögliche Crashes behoben, danke @EvilEls
- Implementation der
Notification CCverbessert:- Es wird jetzt korrekt zwischen Push und Pull-Nodes unterschieden
- Push-Nodes werden nicht mehr abgefragt - damit sollten keine "UNKNOWN" States mehr erscheinen
- Wenn Werte von Push-Nodes nicht gesetzt sind, werden sie beim Interview (sofern erlaubt) auf "idle" gesetzt @Gabe
- Pull-Nodes werden nun alle 6h und beim Aufwachen abgefragt
- Beim Einbinden von sicheren Geräten wird nun entsprechend der Z-Wave-Spezifikation abgebrochen, wenn das Gerät zu lange benötigt, um zu antworten.
Update 1.7.3:
Zwei Crashes während desNotification CCInterviews behoben
Update 1.7.4:
- Eine Konfigurationsdatei für
Electronic Solutions DBMZ EUhinzugefügt - Absturz beim Empfang unvollständiger Nachrichten behoben
- Absturz beim Versuch, sichere Befehle mit einem abgelaufenen Einmalschlüssel zu senden, behoben (
Security CC requires a nonce to be sent!) - Mehrere Fehlerbehebungen im Zusammenhang mit batteriebetriebenen Geräten (dies sollte den gefürchteten
E5-Fehler auf einigen Thermostaten verhindern, der seit v1.7.0 wieder auftrat), darunter:- Batteriebetriebene Geräte werden aktiv wieder in den Schlafmodus versetzt, wenn sie keine ausstehenden Nachrichten haben.
- Kompatibilitätsabfragen werden jetzt verworfen, wenn ein Gerät schläft, wodurch doppelte Abfragen beim Aufwachen vermieden werden
- Das Senden eines Geräts in den Schlafmodus funktioniert jetzt auch dann weiter, wenn es einmal fehlgeschlagen ist.
Update 1.7.5:
- Einige fehlende States werden jetzt korrekt angelegt (
Alarm Sensor CCwenn kein Alarm aktiv,Multilevel Switch CCV1/V2) - Wenn eine Nachricht an ein Gerät gesendet werden soll, dass als tot markiert ist, wird dieses zuerst gepingt, um festzustellen, ob es wirklich tot ist.
- Verbesserte Kompatibilität mit Geräten, die
Notification CC(V3+) unterstützen, aberAlarm Reports (V1/V2) senden. Z.B. Fibaro Flood sensor.
Update 1.7.6:
targetValueinColor Switch CCis nun nicht mehr readonly @BausSH- Es ist jetzt konfigurierbar, ob die Namen von States überschrieben werden dürfen @gelberlemmy
- Datenpunkte bekommen jetzt eine (einfache, aber) korrekte Rolle zugewiesen anstatt nur
"value". @gelberlemmy
Update 1.7.7:
- Objekte und States für Werte aus dem Cache werden jetzt sofort erstellt, wenn der Adapter startet. @gelberlemmy schau mal ob damit dein Node 20 zu sehen ist
- Nach dem ersten Interview eines Nodes werden frische States nicht mehr als "möglicherweise nicht aktuell" (orange) markiert
- Fehler beim Interview von Nodes mit
User Code CC V1behoben - Fehler beim Interview von Nodes, die
Central Scene CCaber nichtAssociation Group Information CCunterstützen, behoben @Domoe (das ist dein Devolo-Fehler) - Einige Interviews werden jetzt ohne aktuelle Werte weitergeführt statt abzubrechen, wenn Nodes auf eine nicht-kritische Abfrage nicht antworten @Flopsi das sollte deine hängen bleibenden Interviews beheben
- Kompatibilität mit Geräten verbessert, die Einmal-Codes nicht akzeptieren, die ohne Frage nach einer Bestätigung versendet wurden
- Unkritischer Fehler beim Logging von
DoorLockCCConfigurationSetbehoben - Geräte wie der Multisensor 6, die mit und ohne Batterie betrieben werden können, werden nach einem vollständigen Interview nicht mehr in eine "Geh schlafen"-Schleife geschickt, wenn sie am Strom hängen.
- Wenn Geräte Anfragen nach Einmal-Codes spammen, wird nur noch der letzte beantwortet @Flopsi, Node 8

Update 1.7.8:
- Ein Absturz wurde behoben, der beim Senden eines
Door Lock-Befehls unter bestimmten Umständen auftreten konnte - Die Zeitspanne, in der ein Gerät als wach angenommen wird, wird jetzt auch verlängert, wenn er einen Befehl bestätigt. Dies sollte Interviews besser durchlaufen lassen, wenn ein Gerät oft keine Antwort auf Anfragen sendet.
- Ein Fehler wurde behoben, durch den
Alarm Sensor CC-Berichte einem nicht existierenden Node zugeordnet werden konnten. - Inkludieren von Geräten, die als Controller fungieren können, wird jetzt unterstützt
- Für Geräte mit dem Status
unbekanntist die Schaltfläche "Ausgefallenes Gerät entfernen" jetzt aktiviert @gelberlemmy, das sollte bei Node 20 helfen - Der Loglevel für Meldungen wegen unsicherer Kommunikation aufgrund eines fehlenden Netzwerkschlüssels wurde von Error auf Warnung reduziert.
@AlCalzone ich habe da auch noch ein kleines Anliegen bezüglich eine Aeon Lab Keyfob. Die Fernbedienung habe ich angelernt. Nur scheinen dort auch noch Datenpunkte zu fehlen. habe bereits das Gerät neu interviewt. Anbei einmal ein Screenshot welche Datenpunkte dort angelegt sind. Auch mit der Betätigung von Tasten, kommen keine neuen Datenpunkten. Logs schicke ich Dir per Mail. Es geht da um Note 071
Gruß und Danke André

- Der Nachrichtenfluss sowie die Status-Verwaltung der Nodes wird jetzt durch eine State-Machine abgebildet, sodass jederzeit definiert ist, in welchem Zustand man sich befindet und welche Übergänge in andere Zustände möglich sind.
-
@AlCalzone ich habe da auch noch ein kleines Anliegen bezüglich eine Aeon Lab Keyfob. Die Fernbedienung habe ich angelernt. Nur scheinen dort auch noch Datenpunkte zu fehlen. habe bereits das Gerät neu interviewt. Anbei einmal ein Screenshot welche Datenpunkte dort angelegt sind. Auch mit der Betätigung von Tasten, kommen keine neuen Datenpunkten. Logs schicke ich Dir per Mail. Es geht da um Note 071
Gruß und Danke André

Das war ein Fall von "Anleitung lesen"
Dein Gerät ist im Group-Modus, d.h. es kommuniziert direkt mit den Geräten, die du verknüpft hast!Your Key Fob is in Use (Group) Mode.
In order to program each button of your Key Fob, please refer to the ‘Selecting which devices to control’ section of this guide.Your Key Fob is in Use (Scene) Mode.
In this mode your Key Fob communicates directly with your Z-Wave network’s primary controller, generally a gateway or hub. By pressing each scene button, your Key Fob will send out a scene ID telling the primary controller to activate customized scenes that need to be setup via your controller’s interface.Stell den Konfigurationsparameter auf Scene Mode und alles sollte gut sein.
-
Das war ein Fall von "Anleitung lesen"
Dein Gerät ist im Group-Modus, d.h. es kommuniziert direkt mit den Geräten, die du verknüpft hast!Your Key Fob is in Use (Group) Mode.
In order to program each button of your Key Fob, please refer to the ‘Selecting which devices to control’ section of this guide.Your Key Fob is in Use (Scene) Mode.
In this mode your Key Fob communicates directly with your Z-Wave network’s primary controller, generally a gateway or hub. By pressing each scene button, your Key Fob will send out a scene ID telling the primary controller to activate customized scenes that need to be setup via your controller’s interface.Stell den Konfigurationsparameter auf Scene Mode und alles sollte gut sein.
@AlCalzone ja hab ich auch gesehen. Aber im Szenen Modus ist es nicht anders. Da schicke ich einmal den Log. Hatte beides versucht.
-
Hallöchen,
ich hätte da mal wieder ein Log

Und zwar habe ich mir ein HeatIT Z-TRM3 beigeschafft, lässt sich auch (ohne Verschlüsselung) problemlos inkludieren.
Die Werte des Sensors kommen an, und stimmen auch mit denen auf dem lokalen Display überein.
Auch die anderen Datenpunkte wie Stauts (an/aus) oder ob grade geheizt wird sowie der aktuelle Setpoint kommt durch.
Wenn ich jetzt über iobroker einen Befehl senden will kommt nichts an. im Iobroker selbst wird der wert aber als bestätigt angegeben.
In den Objekten wird auch keine Bezeichnung außer NODE 046 angegeben.201112 HeatIT Z-TRM3 NODE 046.rar
Anbei noch die Datenpunkte die Vorhanden sind.

hoffe das Hilft weiter.
Lg