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
Hab dein Patch ohne Aenderungen nach kurzen (syntax-)Test eingecheckt.
ZitatWarum 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.
ZitatDie 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.
ZitatNach "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 :)
Zitat von: rudolfkoenig am 10 Mai 2016, 22:33:11
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.
ZitatEigentlich 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.
ZitatZWDongle_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...
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:
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:
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:
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:
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
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.
Zitat- War das Einbinden eine zweiten UZB ZM1 wie oben beschrieben überhaupt korrekt?
Ja, grundsätzlich korrekt; bis auf eingeschaltetes autocreate.
Zitat- 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.
Zitatist 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