[patch] Controller als Sekundärcontroller anlernen

[krikan]

Anliegender Patch implementiert ZW_SET_LEARN_MODE und log-Zeilen für ZW_APPLICATION_UPDATE (Controller).

Setzt man den Controller mit "set <ZWdongle> learnMode on" in den learnMode, so wird er als Sekundärcontroller in ein anderes ZWave-Netz aufgenommen. Hierzu muss der andere Controller im Inklusionsmodus (addnode on/onNw) sein. Austausch der Nodeinfos und Routen zwischen Pimär- und Sekundärcontroller findet automatisch statt. Der learnMode wird automatisch nach erfolgreicher Inklusion als Sekundärcontroller beendet.

Informationsaustausch auf zwapi-Ebene findet per ZW_APPLICATION_UPDATE statt, was mit dem anliegenden Patch erst einmal nur geloggt wird. Möchte ich bei Gelegenheit noch ausbauen.

Anlernen und entfernen Sekundärcontroller an Primärcontroller habe ich ein paar Mal getestet, wobei die Controller an verschiedenen FHEM-Instanzen installiert waren. Wechselseitige Zuweisung des SUCs mit Log ist ebenfalls ein paar Mal getestet

Für meine weiteren Überlegungen hinsichtlich Einbindung von ZW_LEARN_MODE und die darauf aufbauenden Controllerfunktionen wäre es schön, wenn ich bitte Nachhilfe bekommen könnte:
- Warum wird in ZWDongle_Get($@) nicht readings.*Update genutzt, sondern die direkte Zuweisung? Ist das nur nicht angepasst oder zwingend?
- Die Controllerfunktionen werden per DoTrigger als Event in 10_ZWave.pm generiert und keine Reading im ZWDongle-Device angelegt. Macht man das nicht bzw.geht das nicht über readings.*Update? Beispiel: Bei ZW_APPLICATION_UPDATE sucId würde ich eigentlich das entsprechende Reading mit Event schreiben.
- Nach "ZW_SET_LEARN_MODE" done würde ich gerne alle Controllerfunktionen aus ZWDongle_DoInit($) noch einmal abarbeiten. Kann ich das gefahrlos so einbinden oder mache ich damit den SendStack o.ä. kaputt?

Rudi, falls das zuviel der dummen Fragen ist, bitte sagen bzw. schweigen . Auch wenn Dir das zu viele Patchhäppchen sind und Du lieber mehr auf einmal haben möchtest. Fühle mich nur sicherer, wenn ich in kleinen Abschnitten abliefere. Momentan kann ich auch noch nicht genau schreiben, wann ich weitermachen kann. Fernziel ist eigentlich ZW_CREATE_NEW_PRIMARY bzw. ZW_CONTROLLER_CHANGE.

Btw.: Die Events bei ZW_SET_SUC_ID habe ich im anliegenden Patch verkürzt und Tippfehler verbessert.

Gruß, Christian

[rudolfkoenig]

Hab dein Patch ohne Aenderungen nach kurzen (syntax-)Test eingecheckt.

Warum wird in ZWDongle_Get($@) nicht readings.*Update genutzt, sondern die direkte Zuweisung? Ist das nur nicht angepasst oder zwingend?

Weiss nicht mehr warum. Habs umgebaut.

Die Controllerfunktionen werden per DoTrigger als Event in 10_ZWave.pm generiert und keine Reading im ZWDongle-Device angelegt. Macht man das nicht bzw.geht das nicht über readings.*Update?

Die aktuelle Implementation ist eigentlich "krank". Ich wusste am Anfang nicht so recht, was ZWDongle und was ZWave Funktion ist, deswegen ist das meiste an Dekodieren in ZWave.pm gelandet. Man koennte von hier auch mit readings*Update events fuer $iodev generieren, das erscheint mir aber auch jetzt etwas unnatuerlich: ZWave_Parse sollte nicht den Namen eines ZWDongles als "erkannt" an Dispatch zurueckliefern.
Eigentlich sollten wir die Controller Funktionen nach ZWDongle_Parse uebersiedeln.

Nach "ZW_SET_LEARN_MODE" done würde ich gerne alle Controllerfunktionen aus ZWDongle_DoInit($) noch einmal abarbeiten. Kann ich das gefahrlos so einbinden oder mache ich damit den SendStack o.ä. kaputt?

ZWDongle_Clear schmeisst halt die Controller-Antowrten der naechsten Sekunde weg. Mit dem Stack sollte kein Problem geben, die Init-Befehle laufen auch ueber dem Stack.

Anzahl/Groesse der Patches ist so ideal

[krikan]

Hab dein Patch ohne Aenderungen nach kurzen (syntax-)Test eingecheckt.

Funktionale, ausführliche Tests dürften auch nicht so einfach sein. Habe zwar einiges probiert, aber längst nicht alles (bspw. security). Bin selbst erstaunt, dass alle meine Tests problemlos durchliefen. Das Meiste wickelt aber das Protokoll automatisch ab. Was nicht automatisch passiert und optional ist (Replication) habe ich nicht eingebaut. Erstens habe ich Zusammenspiel ControllerCommands ZW_REPLICATION* und Command Class Replication nicht begriffen und zweitens halte ich das derzeit für unwichtig. Es werden per Replication wohl nur Groups und Scenes übertragen, die meinen Eindruck nach nicht so viel genutzt werden. Problem stellt derzeit eher die fehlende automatische Abarbeitung von Init-Controllerbefehlen nach Änderungen der Controllereigenschaften dar. Dazu unten mehr.

Eigentlich sollten wir die Controller Funktionen nach ZWDongle_Parse uebersiedeln.

Ok, nutze das solange einfach so weiter, bis sich ein Freiwilliger zur Überarbeitung findet. Mich überfordert das. Mir fällt es immer noch schwer zwischen ZWDongle und was ZWave-Funktion abzugrenzen. Manches überschneidet sich.

ZWDongle_Clear schmeisst halt die Controller-Antowrten der naechsten Sekunde weg. Mit dem Stack sollte kein Problem geben, die Init-Befehle laufen auch ueber dem Stack.

ZWDongle_Clear ist eventuell nicht ideal, aber ob es sonderlich tragisch ist, bezweifel ich erst einmal.
Im Prinzip muss Init nur dann abgearbeitet werden, wenn gravierende Änderungen an den Controllereigenschaften vorgenommen werden. Bspw. HomeId-Änderungen (über learnMode, factoryReset), SUC-Anlage und ähnliches. Die Änderungen sind so tiefgreifend, das Init meiner Meinung nach zwingend für einen vernünftigen Weiterbetrieb von FHEM ist. Mit dem jetzigen Stand von FHEM muss der Anwender selbst das sicherstellen und dies halte ich nicht für optimal. Habe gestern mal kurz versuchsweise über AnalyzeCommand "reopen" genutzt, um die Init-Befehle abzusetzen. Hat funktioniert, aber Nebenwirkungen nicht ausgeschlossen.

ZW_CREATE_NEW_PRIMARY bzw. ZW_CONTROLLER_CHANGE sind vermutlich auch einfach einzubauen. Erster Test war OK, aber muss noch experimentieren. SUC/SIS ist das größere Thema. Hierfür muss nach meinem derzeitigen Stand Init auch noch erweitert werden. Handfestes (Code) hoffentlich demnächst...

[scooty]

Hallo,

aus Ausfallsicherheits-/Backup-/"einfacher zu ersetzen"-Gründen habe auf einem zweiten Raspi (mit eigener FHEM Instanz) einen weiteren ZWave ZME UZB1 in Betrieb genommen.
Ich glaube mich zu erinnern, noch im zweiten ZME UZB1-Device die gleiche Home-ID gesetzt zu haben, wie im Primär-System.
Über "addnode on" am primären Controller (erster Raspi mit eigener FHEM Instanz) und "learnmode on" im zweiten FHEM wurden dann alle Nodes vom Primär- an den Sekundär-Controller übertragen.
Alle zwar als "UNKNOWN_.*" in der nodeList, aber woher soll die zweite FHEM Instanz die Namen aus der ersten Instanz auch kennen.
Also bis dahin für mich alles erklär-/nachvollziehbar und der Stand, den ich soweit erwartet habe und es recht einfach machen sollte, den primären Controller bei Ausfall durch den Sekundär-Controller zu ersetzen.

Nun aber zum für mich Unerklärlichen:
Im zweiten FHEM hatte ich autocreate aktiv.
Mit Erstaunen stellte ich fest, dass nach ein paar Tagen Betrieb in der zweiten FHEM Instanz mit dem Sekundärcontroller plötzlich ZWave-Devices angelegt wurden (bis ich nun erst einmal autocreate deaktiviert habe).
Diese waren bis dahin Devices für ein Fibaro-Unterputzaktor und ein Danfoss Thermostat.
Beim Fibaro stand im state auch noch ein "associate 1 134" (134 ist die Node-ID des sekundären ZME UZB1) und in seiner Association Group 1 waren nun auch beide Controller aufgenommen.
OK, diese zusätzliche association konnte ich mit asssociationDel (über die erste FHEM-Instanz) rückgängig machen, das entsprechende ZWave-Device im zweiten FHEM habe ich auch gelöscht. So glaube ich nun wieder einen sauberen Stand zu haben.

Nun zum aktuellen Problem:
Das Danfoss Thermostat  ist da etwas hartnäckiger. In keiner der beiden FHEM Instanzen stehen mir aktuell am jeweiligen Danfoss-Device die "association"-Befehle zur Verfügung (über Befehlszeile eingegeben kommt nur die Fehlermeldung, dass der Befehl nicht gültig sei). Auch sind keine "association.*"-Readings mehr gelistet.
Wie kann ich nun den aktuellen Stand der Assoziation auslesen bzw. wieder korrigieren?

Weitere folgende Fragen stellen sich mir:
- War das Einbinden eine zweiten UZB ZM1 wie oben beschrieben überhaupt korrekt?
- Wie kann "autocreate" (mit den dann folgenden problematischen associations) für ZWave-Devices bei einem Sekundärcontroller an einem zweiten Raspi verhindert werden, ist es ggf. besser, den zweiten ZME UZB1 auch an der primären FHEM Instanz zu betreiben?

Wäre nett, wenn mir weitergeholfen werden könnte.
Weitere benötigte Infos liefere ich gerne.

Anbei die list der beiden Controller:
Primär-FHEM:

Code Auswählen Erweitern

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM1@115200
   DeviceName /dev/ttyACM1@115200
   FD         28
   MaxSendRetries 3
   NAME       ZW_Dongle
   NR         234
   PARTIAL
   RAWMSG     0004003f0e3202213400000015000100000018
   ReadTime   1482423245.4484
   STATE      Initialized
   SendRetries 0
   SendTime   1482423188.67693
   TYPE       ZWDongle
   WaitForAck 0
   ZW_Dongle_MSGCNT 7605
   ZW_Dongle_TIME 2016-12-22 17:14:05
   homeId     d79c8805
   nodeIdHex  01
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2016-12-22 09:25:30   caps            Vers:5 Rev:6 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2016-12-22 09:25:30   ctrlCaps        MEMBER PRIMARY SUC
     2016-12-22 09:25:30   homeId          HomeId:d79c8805 CtrlNodeIdHex:01
     2016-12-22 17:13:08   nodeList        ZW_Dongle WZOG_ZM1 WZOG_SENF XXDG_CO2TH_SENS01_FIBS EZOG_CopenVitrine XXXX_FIB_Stecker_14 XXDG_Tablet01_FIBS XXEG_ZM1 WZDG_LICHT_BALKM WGEG_ENTF WZDG_LICHT_BALKV FLEG_ZB FLOG_SIRENE WGEG_SENI XXOG_SIRENE XXEG_SIRENE WZOG_ZB XXEG_APB SZOG_ZB01 SZOG_LICHTDECKE WZOG_SLSB_00 WZOG_SLF_00 KUOG_GWSD_63 SZOG_SLL_00 EZEG_LICHT SZOG_GWSD_66 HZKG_WWZP ZWave_SENSOR_MULTILEVEL_93 WZEG_ZF EZEG_ZF GTEG_ZBK BKOG_MKS ZWave_SENSOR_MULTILEVEL_106 ZWave_SENSOR_MULTILEVEL_107 SZOG_ZF FLOG_FRM WZOG_TV_FIBS SZDG_ZF WZDG_ZF XXDG_FRM FLDG_FRM XXDG_SIRENE WZDG_LICHT_BALKH GTEG_SIRENE ZWave_THERMOSTAT_129 ZWave_SWITCH_BINARY_132 ZWave_SWITCH_BINARY_133 ZW_Dongle02_REMOTE ZWave_ENTRY_CONTROL_135
     2016-12-22 09:25:30   random          e017c218c1832ca0d3768508ae75d46845064d19333c42065841ae96194d1a37
     2016-12-22 09:25:30   state           Initialized
     2016-12-22 09:25:30   sucNodeId       1
     2015-11-19 21:51:45   version         Z-Wave 3.99 STATIC_CONTROLLER
   SendStack:
Attributes:
   group      IO_Devs
   homeId     d79c8805
   networkKey xyxyxyx
Sekundär-FHEM:

Code Auswählen Erweitern

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/serial/by-id/usb-0658_0200-if00@115200
   DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
   FD         16
   MaxSendRetries 3
   NAME       ZW_Dongle02
   NR         54
   PARTIAL
   ReadTime   1482422541.20127
   STATE      Initialized
   SendRetries 0
   SendTime   1482422541.19366
   TYPE       ZWDongle
   WaitForAck 0
   homeId     d79c8805
   nodeIdHex  86
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2016-12-22 17:02:14   caps            Vers:5 Rev:6 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2016-12-22 17:02:14   ctrlCaps        OTHER MEMBER
     2016-12-22 17:02:14   homeId          HomeId:d79c8805 CtrlNodeIdHex:86
     2016-12-22 09:29:41   nodeList        UNKNOWN_1 UNKNOWN_10 UNKNOWN_11 UNKNOWN_12 UNKNOWN_13 UNKNOWN_14 UNKNOWN_15 UNKNOWN_20 UNKNOWN_26 UNKNOWN_27 UNKNOWN_29 UNKNOWN_32 UNKNOWN_38 UNKNOWN_40 UNKNOWN_44 UNKNOWN_45 UNKNOWN_46 UNKNOWN_51 UNKNOWN_52 UNKNOWN_55 UNKNOWN_57 UNKNOWN_58 UNKNOWN_63 UNKNOWN_64 UNKNOWN_65 UNKNOWN_66 UNKNOWN_79 UNKNOWN_93 UNKNOWN_96 UNKNOWN_97 UNKNOWN_103 UNKNOWN_104 UNKNOWN_106 UNKNOWN_107 UNKNOWN_108 UNKNOWN_109 UNKNOWN_113 UNKNOWN_114 UNKNOWN_115 UNKNOWN_116 UNKNOWN_117 UNKNOWN_119 UNKNOWN_127 UNKNOWN_128 ZWave_THERMOSTAT_129 UNKNOWN_132 UNKNOWN_133 ZW_Dongle02 UNKNOWN_135
     2016-12-22 17:02:14   random          98cb88548f7acb7923c1d90cbecbde362740ba44f9415c3d762baaad9d16839c
     2016-12-22 17:02:14   state           Initialized
     2016-12-22 17:02:14   sucNodeId       1
   SendStack:
Attributes:
   group      IO_Devs
   homeId     d79c8805
   networkKey xyxyxyx

Und das List des Danfoss-Thermostats der beiden FHEM-Instanzen:
Primär-FHEM:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 129
   IODev      ZW_Dongle
   LASTInputDev ZW_Dongle
   MSGCNT     72
   NAME       ZWave_THERMOSTAT_129
   NR         718
   STATE      12.00 C heating
   TYPE       ZWave
   ZW_Dongle_MSGCNT 72
   ZW_Dongle_RAWMSG 00040081044608007f
   ZW_Dongle_TIME 2016-12-22 16:49:29
   ZWaveSubDevice no
   homeId     d79c8805
   isWakeUp   1
   lastMsgSent 1482420021.34309
   nodeIdHex  81
   Readings:
     2016-12-13 17:35:29   CMD             ZW_APPLICATION_UPDATE
     2016-12-22 16:49:28   battery         80 %
     2016-12-18 06:24:05   ccs             UNKNOWN 08007f07844992d9e82442
     2016-12-13 17:28:38   ccsChanged      00
     2016-12-22 16:49:29   ccsOverride     no, unused
     2016-12-13 17:27:08   ccs_fri         N/A
     2016-12-13 17:27:07   ccs_mon         N/A
     2016-12-13 17:27:08   ccs_sat         N/A
     2016-12-13 17:27:08   ccs_sun         N/A
     2016-12-13 17:27:07   ccs_thu         N/A
     2016-12-13 17:27:07   ccs_tue         N/A
     2016-12-13 17:27:07   ccs_wed         N/A
     2016-12-13 17:28:12   clock           tue 17:28
     2016-12-22 09:32:14   model           Danfoss Z Thermostat 014G0013
     2016-12-22 09:32:14   modelConfig     danfoss/z.xml
     2016-12-22 09:32:14   modelId         0002-0005-0004
     2016-12-13 18:07:19   neighborList    XXDG_CO2TH_SENS01_FIBS EZOG_CopenVitrine XXDG_Tablet01_FIBS WZDG_LICHT_BALKM WZDG_LICHT_BALKV FLOG_SIRENE XXOG_SIRENE XXEG_SIRENE WZOG_SLSB_00 KUOG_GWSD_63 SZOG_SLL_00 EZEG_LICHT SZOG_GWSD_66 HZKG_WWZP XXDG_SIRENE WZDG_LICHT_BALKH GTEG_SIRENE
     2016-12-13 18:01:29   neighborUpdate  failed
     2016-12-22 16:49:29   setpointTemp    12.00 C heating
     2016-12-11 11:47:52   state           wakeupInterval 86400 1
     2016-12-13 17:24:36   thermostatSetpointSupported heating
     2016-12-22 16:20:21   timeToAck       0.058
     2016-12-22 16:20:21   transmit        OK
     2016-12-22 16:20:19   wakeup          notification
     2016-12-15 11:04:03   wakeupReport    interval 1800 target 1
Attributes:
   IODev      ZW_Dongle
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   stateFormat setpointTemp
Sekundär-FHEM:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 129
   IODev      ZW_Dongle02
   NAME       ZWave_THERMOSTAT_129
   NR         55
   STATE      ???
   TYPE       ZWave
   ZWaveSubDevice no
   homeId     d79c8805
   nodeIdHex  81
Attributes:
   IODev      ZW_Dongle02
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD

Danke für jegliche Hinweise und viele Grüße,
Andreas

[krikan]

Hallo Andreas!

Thermostat:
Nimm bitte in das Attribut classes die Class ASSCOCIATION auf. Dann bitte Assoziationen auf den Primärcontroller setzen und wakeupInterval neu setzen.

- War das Einbinden eine zweiten UZB ZM1 wie oben beschrieben überhaupt korrekt?

Ja, grundsätzlich korrekt; bis auf eingeschaltetes autocreate.

- Wie kann "autocreate" (mit den dann folgenden problematischen associations) für ZWave-Devices bei einem Sekundärcontroller an einem zweiten Raspi verhindert werden,

autocreate ausschalten und Devices manuell anlegen.

ist es ggf. besser, den zweiten ZME UZB1 auch an der primären FHEM Instanz zu betreiben?

Befürchte eher neue Probleme. Warum muss der überhaupt gleichzeitig genutzt werden?

Für Backup-Zwecke bitte backupCreate und backupRestore verwenden. Ich denke, dass Dein Weg bei Defekt des Primärcontrollers nicht wirklich hilfreich ist. Du hast dann zwar einen funktionierenden Sekundärcontroller, aber wie bekommst Du einen neuen Primärcontroller? Hast Du das Szenario mal durchgespielt?

Gruß, Christian