NEWS
Test Adapter Z-Wave 2 (v1.7.x)
-
@AlCalzone anbei die Screenshots von Note 20. Danke
-
@AlCalzone
Prima Adapter, aber ein Problem habe ich noch.
Ich bin gerade beim Umzug von PI3 auf PI 4 und habe dann auch den Adapter auf zwave2 gewechselt. Beim starten der Instanz wurden alle Nodes gefunden, aber Node 9 zeigt mir keine Datenpunkte an (Fibaro Roller Shutter 2). Des weiteren ist bei laufender Instanz bei Aufruf der Adapterkonfiguration die Seite kurz sichtbar und verschwindet plötzlich. Wenn die Instanz gestoppt wird, ist auch die Adapterkonfiguration sichtbar.Danke dir im Voraus für deine Hilfe.
-
@AlCalzone
Prima Adapter, aber ein Problem habe ich noch.
Ich bin gerade beim Umzug von PI3 auf PI 4 und habe dann auch den Adapter auf zwave2 gewechselt. Beim starten der Instanz wurden alle Nodes gefunden, aber Node 9 zeigt mir keine Datenpunkte an (Fibaro Roller Shutter 2). Des weiteren ist bei laufender Instanz bei Aufruf der Adapterkonfiguration die Seite kurz sichtbar und verschwindet plötzlich. Wenn die Instanz gestoppt wird, ist auch die Adapterkonfiguration sichtbar.Danke dir im Voraus für deine Hilfe.
-
@DrHouse03 fürs erste problem bitte mal ein log erstellen.
Fürs zweite in die browserkonsole schauen (F12) ob da Fehler stehen.
Danke für deine schnelle Hilfe.
In der Browser Konsole steht bei Aufruf der Adapterkonfig folgendes:
TypeError: Cannot read property 'basic' of undefined
TypeError: socket.removeEventHandler is not a function
Uncaught TypeError: socket.removeEventHandler is not a function
Uncaught (in promise) TypeError: Cannot read property 'basic' of undefinedEdit: Die Datenpunkte ready und status waren für Node 9 vorhanden. Habe diese gelöscht, dann war auch die Adapterkonfig bei laufenden Adapter wieder sichtbar. Cache wurde dann geleert und nun funktioniert alles.
Danke
-
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 super danke für die super schnelle Adapter Weiterentwickelung. Bei meinem Versuch meinen Note 20 zu löschen, bekomme ich eine Fehlermeldung. Ich habe Dir einmal die Log und ein Screenshot per Mail zugesendet.
Schönen Restsonntag
Gruß 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.
-
Danke für deine schnelle Hilfe.
In der Browser Konsole steht bei Aufruf der Adapterkonfig folgendes:
TypeError: Cannot read property 'basic' of undefined
TypeError: socket.removeEventHandler is not a function
Uncaught TypeError: socket.removeEventHandler is not a function
Uncaught (in promise) TypeError: Cannot read property 'basic' of undefinedEdit: Die Datenpunkte ready und status waren für Node 9 vorhanden. Habe diese gelöscht, dann war auch die Adapterkonfig bei laufenden Adapter wieder sichtbar. Cache wurde dann geleert und nun funktioniert alles.
Danke
@DrHouse03 sagte in Test Adapter Z-Wave 2 (v1.7.x):
Habe diese gelöscht, [...] Cache wurde dann geleert und nun funktioniert alles.
Das hilft mir nicht unbedingt, den Fehler zukünfig zu vermeiden
-
Kannst du mal bitte schauen warum bei Node 29 die "Configuration" fehlt. Ist schon ein etwas älteres Z-Wave Gerät.
Außerdem steht bei Node 10 und 11 im Log alle 5 Minuten (wenn diese aufwachen) awake - asleep. Das sind Danfoss Thermostate. Die anderen Geräte melden im Log nicht ständig das sie wach sind. Soll das so?
Gruß
Marcel -
Kannst du mal bitte schauen warum bei Node 29 die "Configuration" fehlt. Ist schon ein etwas älteres Z-Wave Gerät.
Außerdem steht bei Node 10 und 11 im Log alle 5 Minuten (wenn diese aufwachen) awake - asleep. Das sind Danfoss Thermostate. Die anderen Geräte melden im Log nicht ständig das sie wach sind. Soll das so?
Gruß
Marcel@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
warum bei Node 29 die "Configuration" fehlt
Da hab ich keine Konfigurationsdatei für - daher sind keine Parameter bekannt. Ist es der hier?
https://products.z-wavealliance.org/products/583/@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
Außerdem steht bei Node 10 und 11 im Log alle 5 Minuten
Die anderen batteriebetriebenen melden das auch, sind vermutlich nur nicht so oft wach
-
@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
warum bei Node 29 die "Configuration" fehlt
Da hab ich keine Konfigurationsdatei für - daher sind keine Parameter bekannt. Ist es der hier?
https://products.z-wavealliance.org/products/583/@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
Außerdem steht bei Node 10 und 11 im Log alle 5 Minuten
Die anderen batteriebetriebenen melden das auch, sind vermutlich nur nicht so oft wach
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
Ist es der hier?
https://products.z-wavealliance.org/products/583/Ja das sollte er sein.
-
@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
warum bei Node 29 die "Configuration" fehlt
Da hab ich keine Konfigurationsdatei für - daher sind keine Parameter bekannt. Ist es der hier?
https://products.z-wavealliance.org/products/583/@Marsx79 sagte in Test Adapter Z-Wave 2 (v1.7.x):
Außerdem steht bei Node 10 und 11 im Log alle 5 Minuten
Die anderen batteriebetriebenen melden das auch, sind vermutlich nur nicht so oft wach
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
Die anderen batteriebetriebenen melden das auch, sind vermutlich nur nicht so oft wach
Ok danke für die Info.
-
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
Ist es der hier?
https://products.z-wavealliance.org/products/583/Ja das sollte er sein.
-
@AlCalzone
Ich habe gestern Abend 1.7.8 installiert. Devolo Raumthermostat neu angelernt Cache geleert. Leider will er das Interview nicht beenden. Soll ich noch bisschen warten oder gleich wieder eine Log machen? Wird ja sicher nichts anderes drin stehen wie bei der letzten Log. -
@AlCalzone
Ich habe gestern Abend 1.7.8 installiert. Devolo Raumthermostat neu angelernt Cache geleert. Leider will er das Interview nicht beenden. Soll ich noch bisschen warten oder gleich wieder eine Log machen? Wird ja sicher nichts anderes drin stehen wie bei der letzten Log.@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Cache geleert.
Warum??? Das setzt alle bekannten Informationen über alle Nodes zurück. Wenn nix übel schief läuft würde ich die Finger davon lassen.
@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Leider will er das Interview nicht beenden. Soll ich noch bisschen warten oder gleich wieder eine Log machen?
Haste das Gerät währenddessen mal manuell geweckt? Sonst gerne nochmal ein Log.
-
@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Cache geleert.
Warum??? Das setzt alle bekannten Informationen über alle Nodes zurück. Wenn nix übel schief läuft würde ich die Finger davon lassen.
@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Leider will er das Interview nicht beenden. Soll ich noch bisschen warten oder gleich wieder eine Log machen?
Haste das Gerät währenddessen mal manuell geweckt? Sonst gerne nochmal ein Log.
@AlCalzone
Ok, ich lass die Finger vom Cache
zwave-7291.log
Node 035
Ich habe ihn ab und zu mal manuell geweckt. -
@AlCalzone
Ok, ich lass die Finger vom Cache
zwave-7291.log
Node 035
Ich habe ihn ab und zu mal manuell geweckt.@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Ich habe ihn ab und zu mal manuell geweckt.
Joar, schätze das musst du noch ein paar mal machen. Das Interview schreitet Stück für Stück voran, ist aber noch nicht durch. Und am besten den Adapter laufen lassen, sonst geht ein Teil des Fortschritts verloren.
-
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 danke für den Support. Note 20 ist jetzt verschwunden.
Gruß 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.
-
@Domoe sagte in Test Adapter Z-Wave 2 (v1.7.x):
Ich habe ihn ab und zu mal manuell geweckt.
Joar, schätze das musst du noch ein paar mal machen. Das Interview schreitet Stück für Stück voran, ist aber noch nicht durch. Und am besten den Adapter laufen lassen, sonst geht ein Teil des Fortschritts verloren.
-
@AlCalzone
Woran erkenne ich denn das dass Interview weiter geht?
Er steht heute immer noch nicht auf ready.
Ich habe Wake up Zeit auf 5 Minuten gestellt und ihn die letzten 48 Stunden ab und zu auch manuell geweckt. -
@Domoe So einfach ist das ohne Log leider nicht zu erkennen. Es müssten nach und nach neue Datenpunkte dazu kommen
@AlCalzone seit einigen versionen bzw der letzten habe ich viele zugriffe von diesen ip's
194.190.114.100 : 22
185.25.224.206 : 22
185.25.224.111 : 22Alle sind von zwave.me Fernzugriff angeblich.
Machen wohl Portscans und versuchen sich per ssh zu verbinden lt. meine Firewall.Gruß Alex
Support us
714
Online32.4k
Users81.4k
Topics1.3m
Posts