NEWS
Probleme nach ZWave Update mit ZME_WALLC-S
-
@cburghardt vielen Dank für die Benachrichtigung, hatte den Fix schon im Github gesehen.
Parallel zu diesem Text installiere ich die 1.7.1 noch mal.
Die Kommunikation ist seit dem Update auf die 1.6 sowie "besonders". Neben dem nicht mehr funktionierendem Taster (der ja mindestens bei einem weiteren Hersteller auch auftritt) hat sich auch bei meinen Bewegungsmeldern (3x Steinel IS 140-2) merkwürdiges Verhalten eingebürgert.
Bei Update auf die 1.6 laufen die Meldungen über detektierte Bewegung nicht mehr als Einbruchsalarm auf, sondern im Bereich "Home_Security_1" - meinetwegen. Beim Einrichten des Adapters gibt's die aber nicht zwingend (kann sein, dass das noch Verbindungsprobleme sind), mit Aktualiserung der Informationen sind sie dann irgenwann da. Ab einem Zeitpunkt, den ich nicht mehr genau benennen kann, gibt es nun Home_Security_1 und..._2; die Bwegung wird in _2 angemeldet. Nach Veränderung der Skripte wieder alles gut - bis zu dem Zeitpunkt gestern abend, oder heute Nacht, bei dem sich die BewMelder gedacht haben, es wäre eine gute Idee, die Bewegung wieder in Home_Security_1 zu melden...
Das Skript werde ich wohl nicht zurück schreiben, sondern ab sofort beide Kanäle (_1 und _2) abfragen. Ist aber irgendwie unbefriedigend.Welchen Wechsel hat es bei dem hinterlegten OZW Modul gegeben? Damit ich das für einen möglichen Eintrag dort mit angeben kann.
Die Installation der 1.7.1 und das Erzeugen der Instanz sind hier auch sauber durchgelaufen. Ein Fehler beim Scannen der Nodes ist aufgelaufen. Node 16 ist der BewMelder, der am weitesten weg hängt. Ich update die Informationen gerade, hier sind nämlich auch wieder nur die States für/um Home_Security_1 aufgelaufen.
host.rockpro64 2019-11-25 16:32:49.313 info Restart adapter system.adapter.zwave.0 because enabled host.rockpro64 2019-11-25 16:32:49.312 info instance system.adapter.zwave.0 terminated with code NaN () host.rockpro64 2019-11-25 16:32:49.311 warn instance system.adapter.zwave.0 terminated due to SIGABRT host.rockpro64 2019-11-25 16:32:49.310 error Caught by controller[0]: what(): Manager.cpp:1514 - InvalidValueIDError (101) Msg: Invalid ValueID passed to GetValueLabel host.rockpro64 2019-11-25 16:32:49.308 error Caught by controller[0]: terminate called after throwing an instance of 'OpenZWave::OZWException' web.0 2019-11-25 16:32:47.823 info (1709) ==>Connected system.user.admin from ::ffff:192.168.178.201 zwave.0 2019-11-25 16:32:43.723 info (14003) State created: zwave.0.NODE16.SENSOR_MULTILEVEL.Illuminance_1 = undefined, index = 3, comClass = 49, instance = 1 zwave.0 2019-11-25 16:32:43.721 info (14003) Channel created: zwave.0.NODE16.SENSOR_MULTILEVEL = 2, index = 3, comClass = 49, instance = 1 zwave.0 2019-11-25 16:32:43.719 info (14003) State created: zwave.0.NODE16.SENSOR_MULTILEVEL.Illuminance_1 = undefined, index = 3, comClass = 49, instance = 1"Info aktualisieren" startet bei mir im Moment keine Prozesse (Zeile bei der Geräteübersicht wird nicht kurz blau und die Auswahl bleibt auch auf "Info aktualisieren" stehen) - Ampel ist auch 3x rot...
Vielen Dank für Eure Arbeit
-
@cburghardt vielen Dank für die Benachrichtigung, hatte den Fix schon im Github gesehen.
Parallel zu diesem Text installiere ich die 1.7.1 noch mal.
Die Kommunikation ist seit dem Update auf die 1.6 sowie "besonders". Neben dem nicht mehr funktionierendem Taster (der ja mindestens bei einem weiteren Hersteller auch auftritt) hat sich auch bei meinen Bewegungsmeldern (3x Steinel IS 140-2) merkwürdiges Verhalten eingebürgert.
Bei Update auf die 1.6 laufen die Meldungen über detektierte Bewegung nicht mehr als Einbruchsalarm auf, sondern im Bereich "Home_Security_1" - meinetwegen. Beim Einrichten des Adapters gibt's die aber nicht zwingend (kann sein, dass das noch Verbindungsprobleme sind), mit Aktualiserung der Informationen sind sie dann irgenwann da. Ab einem Zeitpunkt, den ich nicht mehr genau benennen kann, gibt es nun Home_Security_1 und..._2; die Bwegung wird in _2 angemeldet. Nach Veränderung der Skripte wieder alles gut - bis zu dem Zeitpunkt gestern abend, oder heute Nacht, bei dem sich die BewMelder gedacht haben, es wäre eine gute Idee, die Bewegung wieder in Home_Security_1 zu melden...
Das Skript werde ich wohl nicht zurück schreiben, sondern ab sofort beide Kanäle (_1 und _2) abfragen. Ist aber irgendwie unbefriedigend.Welchen Wechsel hat es bei dem hinterlegten OZW Modul gegeben? Damit ich das für einen möglichen Eintrag dort mit angeben kann.
Die Installation der 1.7.1 und das Erzeugen der Instanz sind hier auch sauber durchgelaufen. Ein Fehler beim Scannen der Nodes ist aufgelaufen. Node 16 ist der BewMelder, der am weitesten weg hängt. Ich update die Informationen gerade, hier sind nämlich auch wieder nur die States für/um Home_Security_1 aufgelaufen.
host.rockpro64 2019-11-25 16:32:49.313 info Restart adapter system.adapter.zwave.0 because enabled host.rockpro64 2019-11-25 16:32:49.312 info instance system.adapter.zwave.0 terminated with code NaN () host.rockpro64 2019-11-25 16:32:49.311 warn instance system.adapter.zwave.0 terminated due to SIGABRT host.rockpro64 2019-11-25 16:32:49.310 error Caught by controller[0]: what(): Manager.cpp:1514 - InvalidValueIDError (101) Msg: Invalid ValueID passed to GetValueLabel host.rockpro64 2019-11-25 16:32:49.308 error Caught by controller[0]: terminate called after throwing an instance of 'OpenZWave::OZWException' web.0 2019-11-25 16:32:47.823 info (1709) ==>Connected system.user.admin from ::ffff:192.168.178.201 zwave.0 2019-11-25 16:32:43.723 info (14003) State created: zwave.0.NODE16.SENSOR_MULTILEVEL.Illuminance_1 = undefined, index = 3, comClass = 49, instance = 1 zwave.0 2019-11-25 16:32:43.721 info (14003) Channel created: zwave.0.NODE16.SENSOR_MULTILEVEL = 2, index = 3, comClass = 49, instance = 1 zwave.0 2019-11-25 16:32:43.719 info (14003) State created: zwave.0.NODE16.SENSOR_MULTILEVEL.Illuminance_1 = undefined, index = 3, comClass = 49, instance = 1"Info aktualisieren" startet bei mir im Moment keine Prozesse (Zeile bei der Geräteübersicht wird nicht kurz blau und die Auswahl bleibt auch auf "Info aktualisieren" stehen) - Ampel ist auch 3x rot...
Vielen Dank für Eure Arbeit
@SirHenri der Fehler oben deutet auf falsche Informationen in dem openzwave Cache hin. Das wird normal durch das Info aktualisieren behoben.
-
@SirHenri der Fehler der Version 1.7.1 wurde nun gefixt, er ist aktuell aber nur in der GitHub Version behoben.
Wegen dem Wallplug würde ich mal bei openzwave nachfragen, da scheint es ein Kommunikationsproblem zu geben. -
@cburghardt @SirHenri v1.7.2 ist jetzt auf npm
-
@AlCalzone hab s einmal mit einem Update probiert, danach Instanz und Adapter raus und von Null wieder neu - der Adapter behauptet in der Adapteransicht weiterhin eine 1.7.1 zu sein
-
@SirHenri der Fehler der Version 1.7.1 wurde nun gefixt, er ist aktuell aber nur in der GitHub Version behoben.
Wegen dem Wallplug würde ich mal bei openzwave nachfragen, da scheint es ein Kommunikationsproblem zu geben.@cburghardt sagte in Probleme nach ZWave Update mit ZME_WALLC-S:
Wegen dem Wallplug würde ich mal bei openzwave nachfragen, da scheint es ein Kommunikationsproblem zu geben.
Schätze, wir kommen hier nicht weiter. Liege im Moment krankheitsbedingt flach. Soweit ich das verstanden habe liegt das Problem "hinter" iobroker.zwave; direkt in openzwave und wir müssen da mal unsere (inzwischen habe ich mindestens drei gesehen) Beoachtungen schildern. Ich würde als Grundlage dafür gerne noch raus bekommen, welcher Wechsel in der openzwave Version beim Update auf den Zwave Adapter 1.6 im Broker statt gefunden hat.
Ich vermute das Problem dort. -
@cburghardt sagte in Probleme nach ZWave Update mit ZME_WALLC-S:
Wegen dem Wallplug würde ich mal bei openzwave nachfragen, da scheint es ein Kommunikationsproblem zu geben.
Schätze, wir kommen hier nicht weiter. Liege im Moment krankheitsbedingt flach. Soweit ich das verstanden habe liegt das Problem "hinter" iobroker.zwave; direkt in openzwave und wir müssen da mal unsere (inzwischen habe ich mindestens drei gesehen) Beoachtungen schildern. Ich würde als Grundlage dafür gerne noch raus bekommen, welcher Wechsel in der openzwave Version beim Update auf den Zwave Adapter 1.6 im Broker statt gefunden hat.
Ich vermute das Problem dort.@SirHenri kommt drauf an von welcher Version wir sprechen. Von zwave 1.4 auf 1.6 wurde die openzwave Version grundlegend gewechselt, sprich openzwave 1.4 auf 1.6.
-
@SirHenri kommt drauf an von welcher Version wir sprechen. Von zwave 1.4 auf 1.6 wurde die openzwave Version grundlegend gewechselt, sprich openzwave 1.4 auf 1.6.
@cburghardt den Schritt meinte ich. Der Versionssprung heißt also in beiden Systemen gleich?!
Dann will ich mal sehen, ob mein kranker Kopf eine verständliche Beschreibung hin bekommt.
Fragen in der Google-Gruppe? -
@cburghardt den Schritt meinte ich. Der Versionssprung heißt also in beiden Systemen gleich?!
Dann will ich mal sehen, ob mein kranker Kopf eine verständliche Beschreibung hin bekommt.
Fragen in der Google-Gruppe?@SirHenri ja, zufällig heißen die Versionen identisch. Wobei wir auf openzwave 1.6 schon mit iobroker.zwave 1.5 gegangen sind..
Man kann entweder in der Mailinglist nachfragen oder gleich nen issue aufmachen. Aktuell im Einsatz ist die openzwave Version 1.6.953 -
Hallo.
Hier besteht auch das Problem mit dem "heatit z-push button 8" das die Scenen nicht angelegt werden. Nur Scene_Count_1 und Scene_Reset_Timeout.
Grüße
Marcel -
@Marsx79 Hi,
ich habe ein issue im Github von openzwave zum Thema eröffnet. Vielleicht magst Du Dich da dran hängen?
https://github.com/OpenZWave/open-zwave/issues/2020
Gruß
Andreas@SirHenri es sieht so aus als ob das Gerät schlichtweg nicht lange genug wach ist, damit openzwave herausfinden kann, um was es sich handelt. Somit gehen die Central Scene Schalter auch nicht.
Der Vorschlag bei diesem Gerät (und den anderen) ist die Reduzierung des timeout in der openzwave config und das Gerät manuell mehrmals aufzuwecken. Sobald das Interview durch ist, weiß openzwave wie mit dem Gerät zu verfahren ist und ergo auch iobroker. Danach geht dann alles. -
@SirHenri es sieht so aus als ob das Gerät schlichtweg nicht lange genug wach ist, damit openzwave herausfinden kann, um was es sich handelt. Somit gehen die Central Scene Schalter auch nicht.
Der Vorschlag bei diesem Gerät (und den anderen) ist die Reduzierung des timeout in der openzwave config und das Gerät manuell mehrmals aufzuwecken. Sobald das Interview durch ist, weiß openzwave wie mit dem Gerät zu verfahren ist und ergo auch iobroker. Danach geht dann alles.@cburghardt hab ich probiert - "Protokoll" steht im issue in OZW. Einmal hat's geklappt beim zweiten Taster nicht mehr :-(
-
Nachricht "aus OZW":
[...] ... but
Those values where never in the official OpenZWave.
Ich hatte das bisher so verstanden, dass nur Werte, die aus OZW kommen auch im Broker dargestellt werden (können)?:thinking_face:
-
Habe heute die alten OZW_Log.txt und die ozwcache*.xml zur Seite geräumt (iobroker war aus) und den broker neu gestartet. Die Ampel wollte spontan nicht grün werden (hing bei gelb). Nach dem ersten Neustart des Adapters über die "Instanzen" Seite hing der Adapter bei rot, zweiter Neustart war dann erfolgreich.
Die Logdatei habe ich bei OZW Team "abgegeben", mal sehen, was da kommt. Leider siehts aber wohl auch so aus, dass mein funktionierenden Taster wieder nicht mehr funktioniert; ich vermute mal, das liegt am gelöschten ozwcache. -
Problem gelöst - mit einem Update von OZW (vgl.: issue openzwave)
Hat funktioniert, wie in ioBroker.zwave/issues/99 beschrieben.
Vielen Dank an alle Mitdenkenden. -
@SirHenri sagte in Probleme nach ZWave Update mit ZME_WALLC-S:
Ich hatte das bisher so verstanden, dass nur Werte, die aus OZW kommen auch im Broker dargestellt werden (können)
So ist es auch.
Hi zusammen,
wollte hier kurz nachfragen bis wann es eine eventuell gefixte 1.7.3er Version gibt ? Hab im Git gesehen ihr habt schon einen Branch dafür offen.
@SirHenri hat ja schon bestätigt das er es auf manuellem Wege fixen konnte, ich würde gerne den "offiziellen" testen :)
Vielen Dank und viele Grüße
Ralf
-
Hi zusammen,
wollte hier kurz nachfragen bis wann es eine eventuell gefixte 1.7.3er Version gibt ? Hab im Git gesehen ihr habt schon einen Branch dafür offen.
@SirHenri hat ja schon bestätigt das er es auf manuellem Wege fixen konnte, ich würde gerne den "offiziellen" testen :)
Vielen Dank und viele Grüße
Ralf
@AggroRalf sagte in Probleme nach ZWave Update mit ZME_WALLC-S:
bis wann es eine eventuell gefixte 1.7.3er Version gibt
Seit etwa 1 Woche :)
389
Online32.4k
Users81.5k
Topics1.3m
Posts