Probleme mit ZWAVE Netzwerk und ??? im Kopf... (Neo cool cam / Fibaro Switch)

Begonnen von fireball, 21 September 2018, 21:50:45

Vorheriges Thema - Nächstes Thema

fireball

Hi, habe mir ein paar neue ZWAVE Spielereien gegönnt und nun noch viele FIBARO DoubleSwitche und NEO COOL CAM Window Module besorgt.
Bei der Eindung der FIBARO Module hatte ich erstmal keine Probleme... doch einmal wunderte ich mich, warum mein Licht abends nicht mehr automatisch ausgehen sollte.
Erst nach einem Reboot des gesamten PIs lief dann wieder einwandfrei.

So nun habe ich die NEOs inkludiert und musste feststellen, dass genau dies wieder zu dem Effekt führte, dass Abends die Lichter nicht mehr ausgingen... als wenn sich irgendwas in FHEM/PI oder dem ZWAVE aufgehagen hatte.
Reboot und dann liefs wieder.

1. Irgendwer ne Idee oder den gleichen Effekt mal gehabt, warum das so ist?

Beim Inkludieren der NEOs viel mir noch folgendes auf:
- Nicht alle Module wurden gleichmäßig in FHEM eingetragen, bei einigen mit dem PRoduktbild, einige nicht...
- Viel kurioser war, dass bei einigen die Zeile mit den vClasses automatisch angelegt wurde, bei einigen nicht.

2. Gibts da ne Idee warum das so ist? Kann ich die Zeile mit den vClasses einfach in der Konfig per c+p an die anderen Module anfügen?

In der Übersicht der Module wird kein State angezeigt, beim öffnen und schließen.

3. Muss ich den State selber mit der MAP umschreiben? in den Readings ist nur "alarm" und "doorWindow".

Es gibt viel mehr Readings, die wurde auch mal teilweise ausgelesen. Ich habe dann nochmal exkludiert und inkludiert, aber sie kommen nicht wieder.  Jetzt steht da immer was von "Scheduled for sending after WAKEUP"

4. Was habe ich falsch gemacht? Ich habe eigentlich nur die Namen der Devices in lesbare Namen geändert.

In meinem ZWAVE STICK AEON wird folgendes angezeigt:

isFailedNode_KWL

no

2018-02-06 20:43:54
isFailedNode_UNKNOWN_3

no

2018-02-06 20:44:00
nodeInfo_KWL

ProtocolVers:SDK5.0x+4.2x listening routing maxBaud:40kbps Controller SpecificDev RoleType:N/A BasicDevClass:STATIC_CONTROLLER GenericDevClass:VENTILATION SpecificDevClass:01

2018-02-06 20:41:55
nodeInfo_UNKNOWN_3

ProtocolVers:SDK5.0x+4.2x listening routing maxBaud:40kbps Controller SpecificDev RoleType:N/A BasicDevClass:STATIC_CONTROLLER GenericDevClass:VENTILATION SpecificDevClass:01

2018-02-06 20:41:35
nodeList

ZWDongle_0 FIBARO_RGB ON_OFF_SWITCH_KWL KWL Aussenlicht_vorn Aussenlicht_Terr_hin Innenlicht_FensterStDo_Treppe UNKNOWN_11 Fenstersensor_EG_Bad UNKNOWN_13 UNKNOWN_14 Fenstersensor_OG_Bad Fenstersensor_OG_Schlafzimmer Fenstersensor_EG_Terasse

2018-09-21 06:51:19


5. Was könnte nodeInfo_UNKNOWN_3 sein?
Was ist isFailedNode_KWL?
6. UNKNOWN_11,13 und 14 sind die NEOs vom Inkludieren exkludieren... wie bekomme ich die wieder raus?

und zu guter letzt:
Diese ZWAVE MAP zeigt doch an, wie die Module miteinander sprechen oder?

7. Wieso sind die nicht alle miteinander verbunden? Siehe Anhang, meine Map.

VG und danke für die Ratschläge im Voraus.
René

rudolfkoenig

ZitatDiese ZWAVE MAP zeigt doch an, wie die Module miteinander sprechen oder?
Nicht wirklich, diese Darstellung zeigt nur die neighborList Daten, die man jeweils mit neighborUpdate erzeugt. Der Controller _kann_ diese Daten verwenden, um einen Knoten zu erreichen. In einem ZWave+ Netz gibt es auch noch den Weg der Explorer-Frames, um problematische Knoten zu erreichen.

fireball

Hi,

ich habe nochmal intensiver die Doku durchsucht und damit konnte ich einige meiner Fragen selber klären:
1. Habe ich keine Erklärung, warum das eingefrohren ist.

2. Ich habe bei der Inklusion im Fhem log gesehen, das die Inklusion sogar mit Auffinden der XML geklappt hat.
2018.09.23 09:43:31 2: autocreate: define ZWave_SENSOR_NOTIFICATION_20 ZWave ec4154d2 20 5e86725a7380713085598470
2018.09.23 09:43:31 2: autocreate: define FileLog_ZWave_SENSOR_NOTIFICATION_20 FileLog ./log/ZWave_SENSOR_NOTIFICATION_20-%Y.log ZWave_SENSOR_NOTIFICATION_20
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass ALARM
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass ASSOCIATION
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass ASSOCIATION_GRP_INFO
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass BATTERY
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass CONFIGURATION
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass DEVICE_RESET_LOCALLY
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass MANUFACTURER_SPECIFIC
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass POWERLEVEL
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass SENSOR_BINARY
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass VERSION
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass WAKE_UP
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 versionClass ZWAVEPLUS_INFO
2018.09.23 09:43:32 1: ZWAVE INIT: get ZWave_SENSOR_NOTIFICATION_20 versionClassAll: Scheduled get requests for sending after WAKEUP, check the vclasses attribute
2018.09.23 09:43:32 3: ZWave set ZWave_SENSOR_NOTIFICATION_20 associationAdd 1 1
2018.09.23 09:43:32 3: ZWave set ZWave_SENSOR_NOTIFICATION_20 wakeupInterval 86400 1
2018.09.23 09:43:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_20 model
2018.09.23 09:43:36 3: ZWave got config for shenzen_neo/nas-ds01z.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz


Aber:
Nachdem ich den DeviceNamen händisch in der Konfig umgeschrieben habe, ist sowohl das Bild weg, als auch das Attribut oder wars ein Internal?! von der XML Datei .

Bekomme ich das Bild irgendwie wieder?
BTW: Ich habe dann auch laut Doku mit jedem ZWAVE Device ein associationAdd gemacht.

Die vClassen wurden nicht bei jedem Inklude gefunden, ich habe sie dann von den anderen Modulen kopiert, ich hoffe das ist nicht tragisch?!

Hier mal ein Bsp:

define FSensor_OG_Kind_2 ZWave ec4154d2 21
attr FSensor_OG_Kind_2 IODev ZWDongle_0
attr FSensor_OG_Kind_2 classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BATTERY ALARM SENSOR_BINARY ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION WAKE_UP
attr FSensor_OG_Kind_2 devStateIcon on:fts_window_1w_open off:fts_window_1w
attr FSensor_OG_Kind_2 icon fts_window_1w
attr FSensor_OG_Kind_2 room FENSTER
attr FSensor_OG_Kind_2 stateFormat doorWindow
attr FSensor_OG_Kind_2 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:2 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

define ZWave_SENSOR_NOTIFICATION_22 ZWave ec4154d2 22
attr ZWave_SENSOR_NOTIFICATION_22 IODev ZWDongle_0
attr ZWave_SENSOR_NOTIFICATION_22 classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BATTERY ALARM SENSOR_BINARY ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION WAKE_UP
attr ZWave_SENSOR_NOTIFICATION_22 devStateIcon on:fts_window_1w_open off:fts_window_1w
attr ZWave_SENSOR_NOTIFICATION_22 icon fts_window_1w
attr ZWave_SENSOR_NOTIFICATION_22 room FENSTER
attr ZWave_SENSOR_NOTIFICATION_22 stateFormat doorWindow


Der Sensor mit einem schönen Namen hat die vClasses, wahrscheinlich weil ich sie noch hinkopiert habe.
Der Sensor_22 hat keine vClasses nach der Inklusion, da steht auch im LOG
2018.09.23 09:46:50 1: ZWAVE INIT: get ZWave_SENSOR_NOTIFICATION_22 versionClassAll: Scheduled get requests for sending after WAKEUP, check the vclasses attribute

Kurios ist hier, der Sensor_22 hat aber das Bild und diese Einträge in der Übersicht:
IMAGE = /fhem/deviceimages/zwave/ZC10-16055076
model=Neo CoolCam Door/Window Detector
modelConfig=shenzen_neo/nas-ds01z.xml
modelId=0258-0003-1082

3. Den State habe ich jetzt mit
attr FSensor_EG_WZ_hinten stateFormat doorWindow
gesetzt. Dadurch habe ich ein on/off für State und dieses nutze ich dann (zB für ein offen oder geschlossenes Fensterbild)


5 und 6:
Diese Unknown-Sachen habe ich rausbekommen.... auf diese Liste setzen und dann löschen.

Was hier komisch finde, die freien Node-IDs wurden nicht wieder genommen, ZWAVE zählt weiter munter hoch.
Gibts hier eine Möglichkeit einen Abgleich aller benutzten NodeIDs mit den bestehenden zu machen?
Viell. zeigt FHEM ja nichts mehr an, aber die werden doch nicht wieder freigegeben?!

7: Durch deaktivieren von "WAKUP" und dann "neighborUpdate" konnte fast jedes Device sein neighborList updaten und nun stehen da auch einige SAchen drin und die Map sieht "verbundener" aus. Allerdings gibts immernoch freischwebende Module, dafunktioniert das neighborUpdate einfach nicht, auch nicht nachdem Löschen von WAKUP aus der Config. Kommt immer ein Timeout.
Aber schalten bzw. empfangen der Date geht.

Komisch oder?!

VG
René

krikan

Zitat1. Habe ich keine Erklärung, warum das eingefrohren ist.
Evtl. weil die Geräte eingeschlafen sind, bevor die Abfrage "get <device> model bzw. "get <device> versionClassAll" verarbeitet wurde, oder die Abfrage ist gescheitert. -> Manuell aufwecken bzw. Befehle selbst noch einmal absetzen und aufwecken. https://wiki.fhem.de/wiki/Z-Wave#batteriebetriebene_Ger.C3.A4te

ZitatNachdem ich den DeviceNamen händisch in der Konfig umgeschrieben habe,
Wenn man die fhem.cfg nicht direkt bearbeitet, sondern das Webfrontend nutzt und den passenden Befehl https://fhem.de/commandref.html#rename verwendet, bleiben solche Effekte aus. FHEM setzt dann Abhängigkeiten richtig, die man bei fhem.cfg-Editierei selbst machen muss oder vor neuen Problemen steht.
https://wiki.fhem.de/wiki/Konfiguration#Bearbeitung_der_Konfiguration

ZitatBekomme ich das Bild irgendwie wieder?
get <device> model

siehe auch: https://wiki.fhem.de/wiki/Z-Wave#Konfiguration

ZitatDie vClassen wurden nicht bei jedem Inklude gefunden, ich habe sie dann von den anderen Modulen kopiert, ich hoffe das ist nicht tragisch?!
Nicht tragisch, get aber auch mit
get <device> versionClassAll


Zitat5 und 6:
Diese Unknown-Sachen habe ich rausbekommen.... auf diese Liste setzen und dann löschen.
beschrieben unter anderem in: https://wiki.fhem.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F

ZitatWas hier komisch finde, die freien Node-IDs wurden nicht wieder genommen, ZWAVE zählt weiter munter hoch.
Gibts hier eine Möglichkeit einen Abgleich aller benutzten NodeIDs mit den bestehenden zu machen?
Viell. zeigt FHEM ja nichts mehr an, aber die werden doch nicht wieder freigegeben?!
https://wiki.fhem.de/wiki/Z-Wave#Bei_einer_Inklusion_wird_eine_durch_Exklusion.2FremoveFailedNode_frei_gewordenen_NodeId_nicht_mehr_vergeben._Ist_das_korrekt.3F
Wo FHEM nichts in der nodeList anzeigt, ist nichts mehr.

Zitat7: Durch deaktivieren von "WAKUP" und dann "neighborUpdate" konnte fast jedes Device sein neighborList updaten und nun stehen da auch einige SAchen drin und die Map sieht "verbundener" aus. Allerdings gibts immernoch freischwebende Module, dafunktioniert das neighborUpdate einfach nicht, auch nicht nachdem Löschen von WAKUP aus der Config. Kommt immer ein Timeout.
Aber schalten bzw. empfangen der Date geht.
Das deaktivieren von WAKEUP (=Löschen von WAKEUP aus dem Attribut classes?) führt quasi zwangsläufig zum NO_ACK, da Befehle zu nicht "wach"-zeiten an das Gerät verschickt werden. ->https://wiki.fhem.de/wiki/Z-Wave#batteriebetriebene_Ger.C3.A4te

Gruß, Christian