RaZberry2 als secondary Controller

[Martin Fischer]

Moin Zusammen,

kann mir bitte mal jemand erklären wie ich einen RaZberry2 im Mesh einbringen kann und diesen als Router bzw. als secondary Controller einsetzen kann? Irgendwie sind die Informationen, die ich fand, etwas spärlich oder beziehen sich daraf einen Controller durch einen neuen abzulösen.

Konkret will ich folgendes Szenario umsetzen:
FHEM Instanz 1:
Z Wave Dongle, Primary. Die Instanz besteht schon seit langem, auch in Kombination mit Z Wave. Diese soll unverändert bleiben.

FHEM Instanz 2:
RaZberry2. Neu hinzu gekommen. Soll das Mesh "in der Mitte" als Router "verstärken".

Viele Grüße
Martin

[rudolfkoenig]

Soll das Mesh "in der Mitte" als Router "verstärken".

Ich tippe darauf, dass sowas vom Z-Wave nicht vorgesehen ist, in FHEM habe ich dafuer auch nichts getan.

[Martin Fischer]

Öhm... wenn ich das Z Wave Konstrukt richtig verstehe, dann ist jeder mit dauerhaft Spannung anliegende Teilnehmer, besser gesagt, alle Geräte die nicht mit Batterien betrieben werden, immer auch gleichzeitig Router.

So steht es zumindest überall geschrieben. Letztlich möchte ich in der zweiten FHEM Instanz einen "dummen" RaZberry2 betreiben, der halt nichts weiter machen soll, also Nachrichten entgegen zu nehmen und weiter zu verteilen.

Du meinst, das geht so nicht?

[rudolfkoenig]

Vielleicht habe ich was falsch verstanden, und mit secondary controller kenne ich mich auch nicht aus.
Aber wenn ich das Firmware programmiert haette, waere ich nicht auf die Idee gekommen.

[krikan]

Wenn der secondary-razberry nur als Router arbeiten soll, sollte es funktionieren. Würde diesen aber nicht in Geraetekonfiguration und -steuerung eingreifen lassen. autocreate würde ich auf der Secondary-FHEM-Instanz auf jeden Fall ausschalten und createNode mit Vorsicht behandeln.

Viel mehr als dort https://forum.fhem.de/index.php?topic=53240.0 habe ich nicht getestet.

[Martin Fischer]

Vielleicht habe ich was falsch verstanden, und mit secondary controller kenne ich mich auch nicht aus.
Aber wenn ich das Firmware programmiert haette, waere ich nicht auf die Idee gekommen.

Vielleicht verstehe ich ja auch was falsch! Ich zitiere mal von (u.a.) zwave.de:
"220V-betriebene Aktoren und Sensoren sind immer aktiv (daher Router), während Sensoren mit Batterien nur aktiv sind, wenn sie aufgeweckt werden."

[Martin Fischer]

Viel mehr als dort https://forum.fhem.de/index.php?topic=53240.0 habe ich nicht getestet.

Ja, das habe ich dann gestern auch gefunden... aber das fruchtet bei mir irgendwie nicht..

Gehe ich bei meiner ersten FHEM Instanz auf "addNode on" oder "onNw", dann ist der STATE dort "learnMode active" (oder "enabled", weiss ich eben nicht mehr..). Bei der zweiten FHEM Instanz mit dem RaZberry2 gehe ich auf "learnMode on" oder "onNw" und es passiert (scheinbar) genau nichts.. zumindest nichts für mich ersichtlches... habe allerdings auch nicht in die Logs geschaut

Was ich so gelesen habe, sollte eigentlich dann bei der 2. Instanz die homeId übernommen werden und ein ctrlCaps sollte ein Secondary (o.ä.) liefern.. Die homeId bleibt unverändert, ctrlCaps liefert PRIMARY. In der 1. Instanz steht der Dongle im STATE mit "learnMode disable" und in der Nodelist tauchen 2 "UNKNOW_nn" Geräte auf.

Es scheit so, als wenn hier etwas nicht so läuft wie es sollte bzw. wie ich es verstanden habe:
1. Dongle 1 in "addNode on" (oder "onNw") Modus versetzen
2. Dongle 2 in "learnMode on" (oder "onNw") Modus versetzen
3. Dongle 2 "sollte" die Konfig (und homeId?) von Dongle 1 übernehmen
4. Dongle 1 beendet selbstständig "addNode" Modus

So habe ich das verstanden...

In der zweiten Instanz soll in der Tat nichts geschaltet oder gesteuert werden. Theoretisch könnte ich den RaZberry2 auch mit der z-wave me Software "initialisieren" und ihn dann einfach nur "routen" lassen (sofern das überhautp nach Rudis Antwort möglich ist).

Aber ihn in FHEM zu "parken" ist doch auch was Schönes

[krikan]

1. Dongle 1 in "addNode on" (oder "onNw") Modus versetzen
2. Dongle 2 in "learnMode on" (oder "onNw") Modus versetzen
3. Dongle 2 "sollte" die Konfig (und homeId?) von Dongle 1 übernehmen
4. Dongle 1 beendet selbstständig "addNode" Modus

Liest sich richtig. Dongle 2 muss automatisch homeId von Dongle 1 bekommen. Schritt 3 hatte in meinen Tests relativ lange gedauert. Ablauf kannst Du am Besten verfolgen, wenn Du in beiden FHEM-Instanzen den Event-Monitor bei der Inklusion des Dongle 2 öffnest.

Wenn ich es schaffe, teste ich heute abend selbst noch mal. Dann kann ich Dir evtl. mehr schreiben.

Rudis Zweifel kann ich nachvollziehen; ein einfacher Zwischenstecker o.ä. ist sicherlich einfacher, aber weniger spannend.  Ich erinnere mich nur, dass der Secondary nachher in den Routen -soweit sinnvoll- enthalten war. Bei der Problematik des Routenabgleichs zwischen Primary und Secondary bin ich gerade zweifelnd. Primary muss mMn zum SUC gemacht werden, wenn er es noch noch nicht ist.

[Martin Fischer]

So, mal 'nen Statusupdate..

Liest sich richtig. Dongle 2 muss automatisch homeId von Dongle 1 bekommen.

Habe jetzt mal die Methode mit dem Holzhammer gewählt: Alles abgelernt, beide Dongles factory reset. Und siehe da:

Code Auswählen Erweitern

Internals:
   CFGFN      /etc/fhem/conf.d/01_iodevices.cfg
   CallbackNr 1
   Clients    :ZWave:
   DEF        /dev/zwave@115200
   DeviceName /dev/zwave@115200
   FD         17
   MaxSendRetries 3
   NAME       ZWAVE
   NR         144
   PARTIAL
   ReadTime   1504446209.43429
   STATE      ZW_SET_LEARN_MODE done
   SendRetries 0
   SendTime   1504446209.43232
   TYPE       ZWDongle
   WaitForAck 0
   homeId     c1ad7892
   nodeIdHex  01
   nrNAck     0
   MatchList:
     1:ZWave    .*
   READINGS:
     2017-09-03 15:39:25   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
     2017-09-03 15:42:08   ctrlCaps        PRIMARY
     2017-09-03 15:43:29   homeId          HomeId:c1ad7892 CtrlNodeIdHex:01
     2017-09-03 15:42:12   nodeList        ZWAVE UNKNOWN_2
     2017-09-03 15:39:25   random          db7d5e8a0e306623f1c607e120d4085a873f593e0001e598b931b87c7b395b5a
     2017-09-03 15:41:22   state           ZW_SET_LEARN_MODE done
     2017-09-03 15:39:25   sucNodeId       no
   SendStack:
   addCL:
     Authenticated 0
     BUF
     FD         56
     FW_ID      3083
     LASTACCESS 1504446233.79413
     NAME       WEB.DEFAULT_192.168.1.2_58220
     NR         3083
     PEER       192.168.1.2
     PORT       58220
     SNAME      WEB.DEFAULT
     SSL
     STATE      Connected
     TEMPORARY  1
     TYPE       FHEMWEB
     canAsyncOutput 1
Attributes:
   group      IO-Device
   homeId     c1ad7892
   room       Server
   verbose    4


und

Code Auswählen Erweitern

Internals:
   CallbackNr 1
   Clients    :ZWave:
   DEF        /dev/ttyAMA0@115200
   DeviceName /dev/ttyAMA0@115200
   FD         9
   MaxSendRetries 3
   NAME       ZWAVE
   NR         46
   PARTIAL
   RAWMSG     005001060200
   ReadTime   1504446198.29353
   STATE      Initialized
   SendRetries 0
   SendTime   1504446198.29128
   TYPE       ZWDongle
   WaitForAck 0
   ZWAVE_MSGCNT 2
   ZWAVE_TIME 2017-09-03 15:41:25
   homeId     c1ad7892
   nodeIdHex  02
   nrNAck     0
   MatchList:
     1:ZWave    .*
   READINGS:
     2017-09-03 15:39:47   caps            Vers:5 Rev:4 ManufID:0147 ProductType:0400 ProductID:0002 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
     2017-09-03 15:42:23   ctrlCaps        SECONDARY OTHER
     2017-09-03 15:43:18   homeId          HomeId:c1ad7892 CtrlNodeIdHex:02
     2017-09-03 15:42:30   nodeList        ZWAVE UNKNOWN_2
     2017-09-03 15:39:48   random          55ee02ca22620e9fe8b49fdd62d02714697dc344481df48ab5414678ec8341ba
     2017-09-03 15:39:48   state           Initialized
     2017-09-03 15:39:47   sucNodeId       no
   SendStack:
Attributes:
   group      IO-Device
   homeId     c1ad7892
   room       Server


Ich erinnere mich nur, dass der Secondary nachher in den Routen -soweit sinnvoll- enthalten war. Bei der Problematik des Routenabgleichs zwischen Primary und Secondary bin ich gerade zweifelnd. Primary muss mMn zum SUC gemacht werden, wenn er es noch noch nicht ist.

Obwohl ich nun schon seit ~1.5 Jahren Z-Wave Komponenten nutze, habe ich mich nicht tiefer eingearbeitet... SUC sagt mir also im Moment nichts, auch nicht wie ich den Primary zu solchem mache

Wenn ich nun wieder alle Aktoren inkludiere, muss ich dann noch "irgendetwas" mit dem Secondary anstellen oder weiß der dann automatisch von den anderen Geräten? Bzw. muss er das überhaupt wissen: Zur Erinnerung er soll ja "nur routen" (sofern möglich).

[krikan]

Sollte eigentlich auch ohne Holzhammer funktionieren. Bei meinen damaligen Experimenten habe ich einen Primary mit mehreren inkludierten Nodes genutzt. Aber Dein Weg hat ja funktioniert.

SUC ist so ein nebulöses Thema, da die technische Doku fehlt und die anderen Infos recht oberflaechlich sind.
Hier die von openhab zusammengetragenen Infos: https://github.com/cdjackson/HABmin/wiki/ZWave-SUC-Controller-Mode
Ich selbst konnte den Nutzen eines SUCs mit FHEM trotz intensiverer Experimente nie feststellen. Habe aber auch nur Geraete mit Explorer Frames Unterstützung.

Dir ist hoffentlich klar, dass das alles ein wenig "experimentell" und hier mWn wenig erforscht ist:
Dongle 1 zum SUC machen:

Code Auswählen Erweitern

set <Dongle1> sucNodeId 1 1 0
Testen, ob erfolgreich:

Code Auswählen Erweitern

get <Dongle1> sucNodeId

Dongle 2 über SUC informieren:

Code Auswählen Erweitern

set <Dongle1> sucSendNodeId 2
Testen an Dongle2, ob erfolgreich:

Code Auswählen Erweitern

get <Dongle2> sucNodeId

Bei Routenaenderungen (Inklusionen?) Dongle1 von Dongle2 aus nach Routenupdate fragen:

Code Auswählen Erweitern

set <Dongle2> sucRequestUpdate 1

Ob das wirklich notwendig ist: ? Eigentlich warte ich auf Deinen Erfahrungsbericht und versuche kurzfristig ein wenig mitzuexperimentieren. 

edit: sucSendNodeId-Befehlszeile korrigiert.

[Martin Fischer]

Hallo Christian,

Ob das wirklich notwendig ist: ? Eigentlich warte ich auf Deinen Erfahrungsbericht und versuche kurzfristig ein wenig mitzuexperimentieren. 

da muss ich Dich leider enttäuschen; zumindest für den Moment.

Aus zeitlichen Gründen musste ich den Aufbau abbrechen. Ich habe so viele (für den Moment) nicht nachvollziehbare Seiteneffekte gehabt, die auch trotz mehrmaligem "Werksreset" des RaZBerry2 als auch des ZME E UZB1 Dongles sowie bei diversen Aktoren, nicht behebbar waren. So konnte ich z.B. erst den RaZberry2 nicht als secondary Controller einbinden (ich berichtete). Nach dem das dann irgendwann klappte, konnte ich keine Aktoren über den primary Controller mehr inkludieren. Dann hatte ich irgendwelche (vermeintlichen) Reichweitenprobleme.

Letztlich "flog" der RaZberry2 und der ZME E UZB 1 Dongle nach einem letztmaligem "factory reset" raus und ein noch jungfreulicher, neuer ZME E UZB 1 kam zum Einsatz. Und dann musste ich halt das Mesh wieder neu aufbauen und alle Aktoren neu (ebenfalls nach "reset") inkludieren. Nun läuft es wieder wie seit langem. Nur das zwei neue Aktoren in der "Mitte" hinzukamen. Dort wo ich eigentlich den RaZBerry2 sah. Nun wurden halt zwei Homematic Aktoren gegen Z Wave getauscht...

Wenn ich die Zeit finde, baue ich das Szenario mal in einer Testumgebung nach und berichte... allerdings sieht es bei mir zeitlich im Moment mau aus..

[Martin Fischer]

Nachtrag:

Was mir noch so "hängen geblieben" ist; nicht weiter verifiziert und was durchaus auch am "Bediener" liegen könnte

Es schien, als wenn manche Aktionen am ZWDongle erst nach einem reopen übernommen wurden bzw. so funktionierten, wie man es erwartet hatte.

Bei "get" Aktionen werden die Ergebnisse in FHEMWEB angezeigt. Um ggf. aktualisierte Werte anzuzeigen, müssen danach die Readings manuell "reloaded" werden. Ggf. könnten die Werte auch direkt übernommen und angezeigt werden. Gesetzt sind sie ja.

Bei den "get" Anzeigen sollte ein "sinnvoller" Zeilenumbruch in der Darstellung gesetzt werden. Gilt aber auch für andere "Overlays" innerhalb von FHEMWEB. Beispiel hier: "get caps" oder "get nodeList" bei > 12 Nodes. Bis man an den OK Button kommt, darf man dann nach ganz rechts scrollen. Wenn kein Zeileneinbruch eingebaut wird, dann wäre es vielleicht snnvoll den Button an den linken Rand zu setzen.

[krikan]

Hallo Martin!

Auch wenn es Dir nicht mehr hilft, habe ich aus Neugierde einmal getestet:

Testhardware an 2 FHEM-Instanzen auf Win:
1. Instanz: Controller UZB1 (Primary mit 3 Nodes ohne SUC)
2. Instanz ohne autocreate: Vision  ZU 1401 EU (SDK 6) (Primary ohne Nodes; soll Secondary werden)
ZWave-Gerät für Inklusionstest: Philio PST02-1A

1. Controller: addNode on
2. Controller: learnMode on
-> 2. Controller wurde erfolgreich als Secondary am 1. Controller angelernt und nodeList übertragen

Inklusion an Primary: addNode on
Philio in Inklusionsmodus
-> Node wurde ohne Probleme an Primary inkludiert und Secondary-Instanz zeigt entsprechende UNDEFINED Events (aber 3x; verstehe ich nicht)

Zu den Routen: Secondary ist in der neigborList vom Philio (Philio ist örtlich näher am Secondary als am Primary), aber routeFor liefert als letzte Route eine Direktverbindung.

Kann also auf die Schnelle in FHEM keine direkten Funktionsprobleme erkennen, was aber angesichts des Minimaltests wenig bedeutet.

Bei den "get" Anzeigen sollte ein "sinnvoller" Zeilenumbruch in der Darstellung gesetzt werden. Gilt aber auch für andere "Overlays" innerhalb von FHEMWEB. Beispiel hier: "get caps" oder "get nodeList" bei > 12 Nodes. Bis man an den OK Button kommt, darf man dann nach ganz rechts scrollen. Wenn kein Zeileneinbruch eingebaut wird, dann wäre es vielleicht snnvoll den Button an den linken Rand zu setzen.

Das verstehe ich nicht. Bei mir findet immer ein Zeilenumbruch anhand der Bildschirmgröße statt. Anhängend ein Screenshot von "get caps".

Gruß, Christian

[Martin Fischer]

Hallo Christian,

danke für Deine weiteren Tests...

[...]
-> Node wurde ohne Probleme an Primary inkludiert und Secondary-Instanz zeigt entsprechende UNDEFINED Events (aber 3x; verstehe ich nicht)

Nun, soweit war ich ja auch schon... aber nachdem ich den Secondary inkludiert hatte, gab es "komische" Seiteneffekte. So gelang es mir nicht, bzw. erst nach einigen Anläufen weitere Nodes aufzunehmen. Die Inklusion ging natürlich vom Primary aus und Secondary hatte kein Autocreate an. Dann konnte ich keine Nodes löschen, etc.

Zu den Routen: Secondary ist in der neigborList vom Philio (Philio ist örtlich näher am Secondary als am Primary), aber routeFor liefert als letzte Route eine Direktverbindung.

Und was schliesst Du daraus? Das der, bzw. ein Secondary nicht als Router verwendet werden kann?

Kann also auf die Schnelle in FHEM keine direkten Funktionsprobleme erkennen, was aber angesichts des Minimaltests wenig bedeutet.

Weiß der Geier was bei mir gerade nicht stimmte...

Das verstehe ich nicht. Bei mir findet immer ein Zeilenumbruch anhand der Bildschirmgröße statt. Anhängend ein Screenshot von "get caps".

Siehe Anhang... wobei wir unterschiedliche Themes benutzen.. daher evtl. die Unterschiede... müsste man mal testen..

[krikan]

Und was schliesst Du daraus? Das der, bzw. ein Secondary nicht als Router verwendet werden kann?

War erst mal eine Sachverhaltsbeschreibung.
Habe weiterprobiert:
Mit "set routeFor" eine Route vom Primary über Secondary zum Philio vorgegeben.
get-Abfrage an Philio verschickt und erfolgreich Antwort bekommen.
Abfrage "get-routeFor" liefert als letzte Route den zuvor mit "set routeFor" festgelegten Weg zurück und (wackeliger) ZWCUL-Mitschnitt bestätigt dies im x-ten Versuch.
-> Secondary ist bei meinem Test also Router.

Ob der Secondary allerdings auch ohne Vorgabe einer Route automatisch als Router dienen kann, ist damit aber immer noch nicht klar. Test wäre umfangreicher.
Der Philio kommuniziert ohne Routenvorgabe im ganzen Haus direkt mit dem Primary statt einen Router zwischenzuschalten. Bei den Empfangsbedingungen ist ein Router wohl nicht notwendig.