Homematic : RESPONSE TIMEOUT:RegisterRead

Begonnen von Charity, 22 Dezember 2016, 11:40:52

Vorheriges Thema - Nächstes Thema

Otto123

Hallo Martin,

der tut dumm weil es nicht regnet  :D :D :D

Ich sehe keine rssi Werte im list (gelöscht?) wäre mein erster Gedanke -> Funkproblem.

Mein zweiter Gedanke ist: wann wacht der auf bzw. sendet der was? Ich habe den leider nicht.

Viele Batteriegeräte senden ja nicht sofort sondern erst nach einiger Zeit, bzw. wenn sie sowieso etwas übertragen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dadoc

Danke Otto ;)
Zitat von: Otto123 am 25 Juli 2018, 14:53:46

der tut dumm weil es nicht regnet  :D :D :D
Ja, der sieht wohl keinen Sinn mehr in seiner Existenz ;)
Zitat
Ich sehe keine rssi Werte im list (gelöscht?) wäre mein erster Gedanke -> Funkproblem.
Nein, gelöscht habe ich die nicht. Wenn keine Funkverbindung bestünde: Dürfte er dann überhaupt irgendetwas antworten? Was genau bedeutet es denn, wenn das Thema rssi im List garnicht auftaucht? Funkmodul hinüber oder nur Störung auf der Verbindungsstrecke?
Zitat
Mein zweiter Gedanke ist: wann wacht der auf bzw. sendet der was? Ich habe den leider nicht.

Viele Batteriegeräte senden ja nicht sofort sondern erst nach einiger Zeit, bzw. wenn sie sowieso etwas übertragen.
Der ist ja (wg. Sensorheizung) nicht batterie-, sondern Netzteil-Betrieben. Wenn nichts passiert (d.h. kein Regen und keine krassen Temperaturänderungen, die die Sensorheizung aktivieren würden), sendet er lt. Logs so zwischen 25 und 40 x pro 24h.
Werde heute Abend aber mal das Funkthema checken.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Otto123

Hallo Martin,

na normalerweise gibt es in den internals Werte wie NameDesIo_RSSI oder rssi_NameDesIo

Du hast clear gemacht, dabei kann es sein die alten Werte sind gelöscht und es gibt erstmal keine Neuen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dadoc

Yo, aber immer noch kein Lebenszeichen. Werde heute Abend, wenn ich wieder vor Ort bin, auch mal Netzteil/Stromversorgung checken.
Würden denn das List so aussehen wie oben geposted, wenn das ganze Teil keinen Saft mehr hat?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Zitat von: dadoc am 25 Juli 2018, 17:35:46
Werde heute Abend, wenn ich wieder vor Ort bin, auch mal Netzteil/Stromversorgung checken.
Das war's, hat wohl wegen der Hitze die Grätsche gemacht. Jetzt ist auch der ganze RSSI-Kram wieder da. Für die Akten, so sieht das List aus, wenn der Sensor Strom bekommt:
Internals:
   DEF        24E2F3
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     16
   NAME       Regensensor
   NOTIFYDEV  global
   NR         821
   NTFY_ORDER 50-Regensensor
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Regensensor_Regen
   channel_02 Regensensor_Heizung
   hmusb_MSGCNT 16
   hmusb_RAWMSG RD3365C36,0001,01998810,FF,FFBE,02800224E2F3424242010200003D
   hmusb_RSSI -66
   hmusb_TIME 2018-07-25 22:51:52
   lastMsg    No:02 - t:02 s:24E2F3 d:424242 010200003D
   protCmdDel 11
   protLastRcv 2018-07-25 22:51:52
   protResnd  12 last_at:2018-07-25 20:10:01
   protResndFail 4 last_at:2018-07-25 20:10:05
   protSnd    20 last_at:2018-07-25 22:51:52
   protState  CMDs_done
   rssi_at_hmusb cnt:16 min:-73 max:-66 avg:-71.25 lst:-66
   rssi_hmusb cnt:3 min:-77 max:-61 avg:-67.33 lst:-61
   READINGS:
     2018-05-02 10:08:48   D-firmware      1.4
     2018-05-02 10:08:48   D-serialNr      KEQ1070896
     2018-07-25 20:44:55   PairedTo        0x424242
     2018-05-02 17:03:40   R-pairCentral   0x424242
     2018-07-25 20:44:55   RegL_00.          02:01 0A:42 0B:42 0C:42 14:06 18:00 00:00
     2018-07-25 20:44:51   powerOn         2018-07-25 20:44:51
     2018-07-25 22:51:52   state           CMDs_done
   helper:
     HM_CMDNR   2
     PONtest    0
     cSnd       1142424224E2F30202000000,1142424224E2F30202000000
     mId        00A7
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +24E2F3,00,01,00
       nextSend   1532551912.39203
       prefIO     
       rxt        0
       vccu       
       p:
         24E2F3
         00
         01
         00
     mRssi:
       mNo        02
       io:
         hmusb:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
       at_hmusb:
         avg        -71.25
         cnt        16
         lst        -66
         max        -66
         min        -73
       hmusb:
         avg        -67.3333333333333
         cnt        3
         lst        -61
         max        -61
         min        -77
     shadowReg:
     tmpl:
Attributes:
   IODev      hmusb
   alias      Regensensor
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-Sen-RD-O
   room       CUL_HM,Wetter
   serialNr   KEQ1070896
   subType    sensRain
   webCmd     getConfig:clear msgEvents

Danke Otto & Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Noch eine damit verbundene Frage hätte ich, nachdem ich einen Monat lang nicht bemerkt hatte, das der Regensensor, der bei Regen ein Fenster schließen soll, ausgefallen war: Wie detektiert man einen solchen Ausfall am Besten? Ich würde das in diesem Fall jetzt so mit einem DOIF machen:
([Fenster] ne "off" and [Regensensor_Regen] eq "rain" or [Regensensor] =~ "TIMEOUT" or [Regensensor] =~ "ACK")
(set Fenster off)

Aber vielleicht gibt es ja einen besseren/allgemeingültigen Weg?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Otto123

Da gibt es sicher unterschiedliche Ansätze.
HM hat doch auch den ActionDetector?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dadoc

Zitat von: Otto123 am 26 Juli 2018, 12:13:09
HM hat doch auch den ActionDetector?
Stimmt, den habe ich immer mal wieder auftauschen sehen, hatte ihn aber nicht als aktiv nutzbare Funktion begriffen.

Habe das jetzt, in Anlehnung (aka Abkuperfung) an https://forum.fhem.de/index.php?topic=70042.0 mal so versucht:
(["^ActionDetector$:^status_.*(unknown|dead)"])
({DebianMail("name\@domain.de","Homematic-Geraet in der x-strasse ausgefallen","$EVENT","") })

Das sollte zumindest die HM-Geräte abdecken. Für meine zahlreichen FS20-Altlasten muss ich mir dann noch etwas anderes einfallen lassen.
A propos "unknown": Nachdem ich gestern das neue Netzteil angelötet hatte und den Sensor wieder eingestöpselt habe, verharrte er bis heute Mittag im Activity-Status "unknown" und hat auch nicht gesendet.
Nach clear msgEvents und getConfig gings dann wieder.
Danke & Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

frank

ohne attr actCycle wird das device nicht überwacht. fehlt in deinem list.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

dadoc

Ja, das stimmt, als ich das List geposted hatte, kannte ich den ActionDetector bzw. dessen Attribute noch nicht, daher erscheint es dort nicht.
Ich habe ihn auf 3 h gesetzt (hoffe, die Schreibweise mit führenden Nullen ist korrekt: 003:00) und werde dem Sensor heute Abend mal den Stecker ziehen, um zu sehen, ob das alles so tut wie erwartet...
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Hallo zusammen,
Mit dem ActionDetector klappt das leider nicht, die Sachlage verwirrt mich etwas.
Der Sensor existiert ja einerseits als Device, andererseits existieren seine beiden Kanäle Regen (ja/nein) und Sensorheizung (ein/aus).
Der Regenkanal sendet lt. Log regelmäßig; das Device - nur das kann ja vom ActionDetector überwacht werden - dagegen nicht, weshalb es nach der vorgegebenen Zeit (z.B. 3 h) als dead markiert wird, obwohl seine Kanäle weiter senden.
Den statusRequest-Befehl kennt der Sensor nicht, sodass actAutoTry auch nicht hilft
Kriegt man den Sensor doch irgendwie unter die Kontrolle des ActionDetectors? Alle paar Stunden ein getconfig laufen zu lassen ginge ja vielleicht, erscheint mir aber nicht eben als elegante Lösung.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

frank

#41
es sendet immer nur das device, auch die chn infos.
hast du eventuell das attr actCycle fälschlicherweise im channel gesetzt?

edit: poste mal je ein aktuelles list vom device und actiondetektor.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

dadoc

Zitat von: frank am 29 Juli 2018, 09:54:51
es sendet immer nur das device, auch die chn infos.
Was mich wundert ist, dass die beiden Kanäle unter der Kategorie CUL_HM gelistet werden, das Device aber nicht, sondern als Kategorie sensRain.

Zitathast du eventuell das attr actCycle fälschlicherweise im channel gesetzt?
Nein, das quittiert fhem ja mit einer Fehlermeldung, wenn man es über das WebUI macht.
Zitat
edit: poste mal je ein aktuelles list vom device und actiondetektor.

Internals:
   DEF        24E2F3
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     30
   NAME       Regensensor
   NOTIFYDEV  global
   NR         821
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Regensensor_Regen
   channel_02 Regensensor_Heizung
   hmusb_MSGCNT 30
   hmusb_RAWMSG RE533C512,0001,1396F5C7,FF,FFB4,18800224E2F34242420102000047
   hmusb_RSSI -76
   hmusb_TIME 2018-07-29 10:42:12
   lastMsg    No:18 - t:02 s:24E2F3 d:424242 0102000047
   protLastRcv 2018-07-29 10:42:12
   protSnd    30 last_at:2018-07-29 10:42:12
   protState  CMDs_done
   rssi_at_hmusb cnt:30 min:-77 max:-64 avg:-70.13 lst:-76
   rssi_hmusb cnt:16 min:-76 max:-61 avg:-64.31 lst:-71
   READINGS:
     2018-07-29 02:21:55   Activity        dead
     2018-05-02 10:08:48   D-firmware      1.4
     2018-05-02 10:08:48   D-serialNr      KEQ1070896
     2018-07-26 21:46:34   PairedTo        0x424242
     2018-05-02 17:03:40   R-pairCentral   0x424242
     2018-07-26 21:46:34   RegL_00.        02:01 0A:42 0B:42 0C:42 14:06 18:00 00:00
     2018-07-26 21:46:30   powerOn         2018-07-26 21:46:30
     2018-07-29 10:42:12   state           CMDs_done
   helper:
     HM_CMDNR   24
     cSnd       1142424224E2F30202C80000,1142424224E2F30202000000
     mId        00A7
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +24E2F3,00,01,00
       nextSend   1532853732.52667
       prefIO     
       rxt        0
       vccu       
       p:
         24E2F3
         00
         01
         00
     mRssi:
       mNo        18
       io:
         hmusb:
           -74
           -74
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
       at_hmusb:
         avg        -70.1333333333333
         cnt        30
         lst        -76
         max        -64
         min        -77
       hmusb:
         avg        -64.3125
         cnt        16
         lst        -71
         max        -61
         min        -76
     tmpl:
Attributes:
   IODev      hmusb
   actCycle   003:00
   actStatus  dead
   alias      Regensensor
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-Sen-RD-O
   room       CUL_HM,Wetter
   serialNr   KEQ1070896
   subType    sensRain
   webCmd     getConfig:clear msgEvents


Internals:
   CHANGED   
   DEF        000000
   NAME       ActionDetector
   NOTIFYDEV  global
   NR         322
   STATE      alive:19 dead:1 unkn:0 off:0
   TYPE       CUL_HM
   READINGS:
     2018-07-29 10:41:57   state           alive:19 dead:1 unkn:0 off:0
     2018-07-29 10:41:57   status_HM_38EE12 alive
     2018-07-29 10:41:57   status_HT_AZ    alive
     2018-07-29 10:41:57   status_HT_BAD_FEN alive
     2018-07-29 10:41:57   status_HT_Hall  alive
     2018-07-29 10:41:57   status_HT_KUE_LI alive
     2018-07-29 10:41:57   status_HT_KUE_RE alive
     2018-07-29 10:41:57   status_HT_WC    alive
     2018-07-29 10:41:57   status_HT_WZ_LI alive
     2018-07-29 10:41:57   status_HT_WZ_RE alive
     2018-07-29 10:41:57   status_Rauchmelder_Hall alive
     2018-07-29 10:41:57   status_Rauchmelder_Heizung alive
     2018-07-29 10:41:57   status_Rauchmelder_Kammer alive
     2018-07-29 10:41:57   status_Rauchmelder_SZ alive
     2018-07-29 10:41:57   status_Rauchmelder_Speicher alive
     2018-07-29 10:41:57   status_Rauchmelder_WZ alive
     2018-07-29 10:41:57   status_Regensensor dead
     2018-07-29 10:41:57   status_THERMOSTAT_Bad alive
     2018-07-29 10:41:57   status_THERMOSTAT_Kueche alive
     2018-07-29 10:41:57   status_THERMOSTAT_WZ alive
     2018-07-29 10:41:57   status_reedcontrol alive
   helper:
     HM_CMDNR   178
     actCycle   600
     peers      24E2F3,315940,36716C,3679E4,37F824,37F82C,389EDA,38E037,38E057,38E49B,38EB2E,38EC14,38EE12,391C84,592DCB,592E19,592EC9,5930CE,5930DE,593742
     24E2F3:
       start      2018-07-27 16:21:45
       try        99
     315940:
       start      2018-07-27 16:21:45
     36716C:
       start      2018-07-27 16:21:45
     3679E4:
       start      2018-07-27 16:21:45
     37F824:
       start      2018-07-27 16:21:45
     37F82C:
       start      2018-07-27 16:21:44
     389EDA:
       start      2018-07-27 16:21:45
     38E037:
       start      2018-07-27 16:21:45
     38E057:
       start      2018-07-27 16:21:45
     38E49B:
       start      2018-07-27 16:21:44
     38EB2E:
       start      2018-07-27 16:21:44
     38EC14:
       start      2018-07-27 16:21:45
     38EE12:
       start      2018-07-27 16:21:44
     391C84:
       start      2018-07-27 16:21:45
     592DCB:
       start      2018-07-27 16:21:45
     592E19:
       start      2018-07-27 16:21:45
     592EC9:
       start      2018-07-27 16:21:45
     5930CE:
       start      2018-07-27 16:21:45
     5930DE:
       start      2018-07-27 16:21:45
     593742:
       start      2018-07-27 16:21:45
     io:
       prefIO     
       vccu       
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
Attributes:
   actAutoTry 1_on
   event-on-change-reading .*
   model      ActionDetector
   room       Settings


Und hier noch Channel 1

Internals:
   DEF        24E2F301
   NAME       Regensensor_Regen
   NOTIFYDEV  global
   NR         824
   STATE      dry
   TYPE       CUL_HM
   chanNo     01
   device     Regensensor
   READINGS:
     2018-05-02 17:03:41   R-sign          off
     2018-07-26 21:46:35   RegL_01.        08:00 22:64 23:00 30:06 87:0B 88:54 8B:0B 8C:22  8F:85 91:82 00:00
     2018-07-28 22:46:41   lastRain        2018-07-28 22:39:39
     2018-07-28 22:46:41   recentStateType info
     2018-07-28 22:46:41   state           dry
     2018-07-28 22:46:41   timedOn         off
   helper:
     regLst     ,1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   model      HM-Sen-RD-O
   peerIDs    00000000,
   room       Terrassen,Wetter
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

frank

ich kann nichts auffälliges erkennen. im gegenteil scheint es sogar plausibel zu sein.
die readings haben einen timestamp von gestern abend kurz vor 11. ca 3,5 std später wurde das reading Activity im device auf dead gesetzt. die halbe stunde verzögerung kommt zb durch das aktualisierungsinterval des actiondetector plus actautotry versuch.

aktuell unter protLastRcv im device internal wurde etwas vom device empfangen. daher sollte in kürze wieder mit verzögerung alive gemeldet werden.

meinst du mit kategorien etwa gruppen in der raumansicht? das ist normal da nach attr subtype gruppiert wird. das attribut existiert aber immer nur im device.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

dadoc

Du hast Recht, Frank, ich habe mich beim Vergleich der Logs verheddert und daher vermutet, dass "dead" auch eintritt, obwohl channel1 Daten liefert. Das ist nicht der Fall.
Bleibt mir noch die Frage, ob es - außer einer handgestrickten Lösung - eine Möglichkeit gibt, den Ausfall des Sensors (d.h. Sensor, Netzteil, Funkverbindung...) kurzfristig zu detektieren und nicht nur durch ein extrem langes actcycle. Letzteres ist bei einem Sensor, der bei einsetzendem Regen Fenster schließen soll, nicht praktikabel. M.a.W.: Könnte man nicht etwas periodisch in angemessenen Abständen an den Sensor schicken, damit der ein Lebenszeichen gibt und den ActionDetector somit auf "live" belässt, ohne den Gesamtverkehr zu sehr zu belasten?
Zitatmeinst du mit kategorien etwa gruppen in der raumansicht? das ist normal da nach attr subtype gruppiert wird. das attribut existiert aber immer nur im device.
Ja, bzw. in der "everything"-Ansicht. War mir bisher noch nicht aufgefallen, dass es diese Gruppierung gibt.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods