[gelöst] FHEM2FHEM HomeMaticSchaltaktor im RAW-Modus spiegeln

CottonIJo · 30 März 2018, 21:31:01

Hallo Forum, nachdem ich hier durch mitlesen und ausprobieren schon so manches Problem lösen konnte, komme ich jetzt nicht weiter.

Folgende Aufgabenstellung:
Auf einem Slave-Raspi <192.168.178.37> mit fhem soll ein HomeMatic 1-Kanal-Schaltaktor über FHEM2FHEM vom Master-Raspi <192.168.178.35> aus bedienbar sein.
Auf dem Master-Raspi läuft FHEM2FHEM bereits im Log-Modus vom gleichen Slave einwandfrei, telnet funktioniert also.
Mein Ansatz war jetzt, den Schaltaktor über den Raw-Mode vom Slave auf den Master zu spiegeln.
Grund ist eine unsichere Funkverbindung vom Installationsort des Schaltaktors zum Master-Raspi.
Ich bin kein Programmierer, also bitte Nachsicht wenn ich nicht jede Syntax verstehe.,

Ich kriege es aber nicht hin, egal was ich mache, ich kann den Schaltaktor vom Master aus nicht schalten.
Die Funktion des Schaltaktors ist auf dem Slave einwandfrei.

Auf beiden Raspis ist ein HM-MOD-RPI-PCB mit Firmware 1.4.1 als Kommunikations-Modul installiert.
Alle mit dem Master-Raspi und Slave-Raspi direkt verbundenen HomeMatic-Module funktionieren einwandfrei.

Was muß ich auf dem Master-Raspi konfigurieren damit ich den Schaltaktor wie auf dem Slave bedienen kann?

Anbei meine Konfiguration des Schaltaktors auf dem Master-Raspi (auf dem ich den Schaltaktor spiegeln möchte):
#
define Aussen_Licht_Eingang CUL_HM 5BCD7F
attr 50_Aussen_Licht_Eingang dummy 1
define 50_Aussen_Licht_Eingang FHEM2FHEM 192.168.178.37:7073 RAW:Aussen_Licht_Eingang

Anbei meine Konfiguration des Schaltaktors auf dem Slave-Raspi (mit dem ist der Schaltaktor verbunden):

Internals:
DEF 5BCD7F
IODev myHmUART_UG
LASTInputDev myHmUART_UG
MSGCNT 3
NAME Aussen_Licht_Eingang
NOTIFYDEV global
NR 51
STATE off
TYPE CUL_HM
lastMsg No:E2 - t:02 s:5BCD7F d:584885 0101000058
myHmUART_UG_MSGCNT 3
myHmUART_UG_RAWMSG 04030053E280025BCD7F5848850101000058
myHmUART_UG_RSSI -83
myHmUART_UG_TIME 2018-03-30 20:50:53
protLastRcv 2018-03-30 20:50:53
protSnd 4 last_at:2018-03-30 20:50:53
protState CMDs_done
rssi_at_myHmUART_UG lst:-83 min:-83 avg:-82 cnt:3 max:-81
rssi_myHmUART_UG max:-84 avg:-86.66 min:-88 cnt:3 lst:-88
READINGS:
2018-03-30 20:50:53 CommandAccepted yes
2018-03-30 20:10:12 D-firmware 2.8
2018-03-30 20:10:12 D-serialNr OEQ0569807
2018-03-30 20:10:23 PairedTo 0x584885
2018-03-30 20:10:17 R-pairCentral 0x584885
2018-03-30 20:10:18 R-powerUpAction off
2018-03-30 20:10:18 R-sign off
2018-03-30 20:10:23 RegL_00. 02:01 0A:58 0B:48 0C:85 15:FF 18:00 00:00
2018-03-30 20:10:24 RegL_01. 08:00 30:06 57:24 56:00 93:11 94:3A 00:00
2018-03-30 20:50:53 deviceMsg off (to vccu)
2018-03-30 20:50:53 level 0
2018-03-30 20:50:53 pct 0
2018-03-30 20:50:53 recentStateType ack
2018-03-30 20:50:53 state off
2018-03-30 20:50:53 timedOn off
helper:
HM_CMDNR 226
cSnd 115848855BCD7F0201C80000,115848855BCD7F0201000000
dlvlCmd ++A0115848855BCD7F0201000000
mId 00F0
regLst ,0,1,3p
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5BCD7F,00,00,00
nextSend 1522435853.38145
rxt 0
vccu vccu
p:
5BCD7F
00
00
00
prefIO:
myHmUART_UG
mRssi:
mNo E2
io:
myHmUART_UG:
-81
-81
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
at_myHmUART_UG:
avg -82
cnt 3
lst -83
max -81
min -83
myHmUART_UG:
avg -86.6666666666667
cnt 3
lst -88
max -84
min -88
tmpl:
Attributes:
IODev myHmUART_UG
IOgrp vccu:myHmUART_UG
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-Sw1-DR
peerIDs 00000000,
room Untergeschoss
serialNr OEQ0569807
subType switch
webCmd statusRequest:toggle:on:off

Otto123 · 30 März 2018, 22:37:04

Hallo,

ich denke was Du willst geht so nicht:

ZitatRAW
Bei diesem Verbindungstyp werden unaufbereitete Ereignisse (raw messages) des remote FHEM-Geräts devicename genau so empfangen, als wäre das Gerät lokal verbunden.
Einschränkungen: nur Geräte, welche die "Dispatch-Funktion" unterstützen (CUL, FHZ, CM11, SISPM, RFXCOM, TCM, TRX, TUL) erzeugen raw messages, und für jedes entfernte Gerät muss ein eigenes FHEM2FHEM Objekt erzeugt werden.

Da steht nichts von Homematic Geräten.

Du kannst aber selbstverständlich im LOG Modus arbeiten und steuern.
Du kannst auch das HM-MOD-RPI-PCB auf dem Slave raspi Remote anbinden, das klingt mir für Deinen Fall sinnvoller.
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Remoteanbindung_-_Pi_.2B_RPI_Modul_.3D_LAN_Modul

Gruß Otto

CottonIJo · 30 März 2018, 23:12:13

Hallo Otto,

danke für die schnelle Antwort.
Die Remote-Anbindung vom HM-MOD-RPI-PCB wäre auszuprobieren, braucht sicherlich etwas Zeit, verstehe auf die Schnelle noch nicht alles.

Deine Aussage, ... im LOG Modus arbeiten und steuern ... irritiert mich etwas, ich hatte das bisher so verstanden, dass im LOG Modus nur pull von Daten möglich ist.

Hintergrund meines Vorhabens ist, dass ich über die Web-Oberfläche von meinem Master-Raspi alle Geräte, sowohl vom Master als auch von den Slaves, steuern möchte.
Der Schaltaktor schaltet das Außenlicht am Eingang, sollte also über Web-Oberfläche ein/aus schaltbar sein. Auch das DOIF für die Zeitsteuerung möchte ich vom Master generieren, einfach aus Verwaltungsgründen.

Wie kann ich im LOG Modus das steuern?

Gruß Joachim

Otto123 · 31 März 2018, 00:20:00

Hallo Joachim,

mal nur kurz zum LOG Modus steuern. Ja, das ist nicht ganz so geradlinig wie die andere Richtung. Und die Remote Anbindung des IO ist deutlich simpler im Handling. Ich würde Dir unbedingt dies empfehlen!
Letztendlich kannst Du in der Hauptinstanz einen Event erzeugen, den empfängt die Slave Instanz über FHEM2FHEM und wertet diesen aus.

Mehrere FHEM Instanzen und dann von "allen" "alles" sehen und steuern ist aus meiner Sicht der falsche Ansatz. Ich betreibe mehrere Instanzen und jede hat ihre spezielle Aufgabe. Manche Werte werden zur Darstellung und Auswertung in die Hauptinstanz übertragen. Manche Werte in die andere Richtung.

Versuch die Remote Anbindung, eigentlich ist es simpler als es aussieht und es steht alles in dem Wiki Link. Frag einfach nach.

Gruß Otto

CoolTux · 31 März 2018, 07:26:21

Guten Morgen,

Ich habe mir mal eben den Code von den Homematic Modulen etwas angeschaut. Der Dispatcher wird da verwendet, es sollte also möglich sein den Raw Modus zu nehmen.
Joachim Du müsstest bitte einmal im Wiki schauen wie man das genau machen muss und es dann entsprechend anlegen. Solltest Du Probleme haben brauchen wir ein list der FHEM2FHEM definition

Code Auswählen

list DEVICENAME

Und ganz wichtig das Ergebnis bitte in Codetags hier einstellen. Dann ist es so wie oben der list zu sehen.

CottonIJo · 31 März 2018, 23:56:43

@Otto, Deiner Empfehlung folgend habe ich jetzt den Slave-Raspi einmal remote angebunden (eigene SD-Karte).
Entsprechend dem Wiki-Artikel ohne jegliche fhem Installation auf dem Slave (Remote-Instanz).
Auf dem Master-Raspi ist der HM-MOD-RPI-PCB vom Slave wie folgt definiert:

define RM_HmUART_UG HMUARTLGW uart://192.168.178.37:2000
attr RM_HmUART_UG hmId 584885
# 584885 ist die ID des HM-MOD-RPI-PCB vom Slave
Damit ergibt sich ein list:

Code Auswählen

 Internals:
   AssignedPeerCnt 0
   CFGFN      
   CNT        125
   Clients    :CUL_HM:
   DEF        uart://192.168.178.37:2000
   DEVCNT     78
   DevState   99
   DevType    UART
   DeviceName 192.168.178.37:2000
   FD         54
   LastOpen   1522529884.54847
   NAME       RM_HmUART_UG
   NR         411
   PARTIAL    
   RAWMSG     05000033BC86104DA7D70000000A90BE0C0000
   RSSI       -51
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 1
   msgLoadHistory 0/0/0/0/1/-/-/-/-/-/-/-
   msgLoadHistoryAbs 1/1/1/1/1/0/-/-/-/-/-/-/-
   owner      584885
   Helper:
     CreditTimer 109
     FW         66561
     Initialized 1
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         logdb:
           TIME       1522529929.65246
           VALUE      584885
       D-HMIdOriginal:
         logdb:
           TIME       1522529887.18398
           VALUE      584885
       D-firmware:
         logdb:
           TIME       1522529887.3453
           VALUE      1.4.1
       D-serialNr:
         logdb:
           TIME       1522529887.47579
           VALUE      OEQ0309703
       cond:
         logdb:
           TIME       1522529887.97709
           VALUE      ok
       loadLvl:
         logdb:
           TIME       1522529887.97709
           VALUE      low
       state:
         logdb:
           TIME       1522531508.80214
           VALUE      UNKNOWNCODE A0FA486104CF2C30000000AA0DA0B1300::-81:RM_HmUART_UG
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.0173799991607666
     loadLvl:
       lastHistory 1522531387.74689
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2018-03-31 22:58:49   D-HMIdAssigned  584885
     2018-03-31 22:58:07   D-HMIdOriginal  584885
     2018-03-31 22:58:07   D-firmware      1.4.1
     2018-03-31 22:58:07   D-serialNr      OEQ0309703
     2018-03-31 22:58:04   D-type          HM-MOD-UART
     2018-03-31 22:58:07   cond            ok
     2018-03-31 23:03:09   load            1
     2018-03-31 22:58:07   loadLvl         low
     2018-03-31 22:58:04   state           opened
Attributes:
   hmId       584885
   room       CUL_HM

Um die Alternative FHEM2FHEM nicht unnötig zu komplizieren, wurde ein Heizungsthermostat HM-CC-RT-DN angelernt, list des devices anbei

Code Auswählen

 Internals:
   CFGFN      
   DEF        63A734
   IODev      myHmUART
   LASTInputDev RM_HmUART_UG
   MSGCNT     4
   NAME       HM_63A734
   NOTIFYDEV  global
   NR         452
   RM_HmUART_UG_MSGCNT 2
   RM_HmUART_UG_RAWMSG 0500002101840063A7340000001400954F4551313731393634375900FFFF
   RM_HmUART_UG_RSSI -33
   RM_HmUART_UG_TIME 2018-03-31 23:09:33
   STATE      ???
   TYPE       CUL_HM
   channel_01 HM_63A734_Weather
   channel_02 HM_63A734_Climate
   channel_03 HM_63A734_WindowRec
   channel_04 HM_63A734_Clima
   channel_05 HM_63A734_ClimaTeam
   channel_06 HM_63A734_remote
   lastMsg    No:01 - t:00 s:63A734 d:000000 1400954F4551313731393634375900FFFF
   myHmUART_MSGCNT 2
   myHmUART_RAWMSG 0500004201840063A7340000001400954F4551313731393634375900FFFF
   myHmUART_RSSI -66
   myHmUART_TIME 2018-03-31 23:09:33
   protLastRcv 2018-03-31 23:09:33
   rssi_at_RM_HmUART_UG max:-33 lst:-33 min:-33 avg:-33 cnt:2 
   rssi_at_myHmUART lst:-66 max:-64 min:-66 avg:-65 cnt:2 
   Helper:
     DBLOG:
       Activity:
         logdb:
           TIME       1522530543.44315
           VALUE      alive
       D-firmware:
         logdb:
           TIME       1522530538.46408
           VALUE      1.4
       D-serialNr:
         logdb:
           TIME       1522530538.46408
           VALUE      OEQ1719647
   READINGS:
     2018-03-31 23:09:03   Activity        alive
     2018-03-31 23:08:58   D-firmware      1.4
     2018-03-31 23:08:58   D-serialNr      OEQ1719647
   helper:
     HM_CMDNR   40
     PONtest    1
     mId        0095
     regLst     ,0,1
     rxType     140
     supp_Pair_Rep 1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +63A734,00,00,00
       nextSend   1522530573.40278
       prefIO     
       rxt        2
       vccu       
       p:
         63A734
         00
         00
         00
     mRssi:
       mNo        01
       io:
         RM_HmUART_UG:
           -33
           -33
         myHmUART:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     rssi:
       at_RM_HmUART_UG:
         avg        -33
         cnt        2
         lst        -33
         max        -33
         min        -33
       at_myHmUART:
         avg        -65
         cnt        2
         lst        -66
         max        -64
         min        -66
     shRegW:
       07         04
     tmpl:
Attributes:
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   OEQ1719647
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

Soweit so gut, Kommunikation funktioniert wohl, nur, es fehlen z. Bsp. im Clima Kanal die kompletten Readings, autocreate war beim pairen eingeschaltet.
Ist hier mehr Hand anzulegen als wenn ich das Gerät normal am Master-Pi paire?
Hätte ich für den HM-MOD-RPI-PCB vom Slave vorher mehr Parameter eingeben müssen? Wenn ja, welche?

@CoolTux
So sieht die Konfiguration von FHEM2FHEM in der fhem.cfg vom Master-Pi aus:
# Schaltaktor von 192.168.178.37 über FHEM2FHEM an die Master-Fhem Instanz spiegeln
#
define Aussen_Licht_Eingang dummy
define 50_Aussen_Licht_Eingang FHEM2FHEM 192.168.178.37:7073 RAW:Aussen_Licht_Eingang
attr 50_Aussen_Licht_Eingang room 50_Aussenbereich
#
list Aussen_Licht_Eingang (auf dem Master-Pi)

Code Auswählen


Internals:
   NAME       Aussen_Licht_Eingang
   NR         382
   STATE      ???
   TYPE       dummy
Attributes:

list 50_Aussen_Licht_Eingang (auf dem Master-Pi)

Code Auswählen


Internals:
   Clients    
   DEF        192.168.178.37:7073 RAW:Aussen_Licht_Eingang
   FD         49
   Host       192.168.178.37:7073
   NAME       50_Aussen_Licht_Eingang
   NR         383
   PARTIAL    
   STATE      connected
   TYPE       FHEM2FHEM
   informType RAW
   rawDevice  Aussen_Licht_Eingang
Attributes:
   room       50_Aussenbereich

list Aussen_Licht_Eingang (auf dem Slave-Pi)

Code Auswählen

 Internals:
   DEF        5BCD7F
   IODev      myHmUART_UG
   LASTInputDev myHmUART_UG
   MSGCNT     34
   NAME       Aussen_Licht_Eingang
   NOTIFYDEV  global
   NR         51
   NTFY_ORDER 50-Aussen_Licht_Eingang
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:41 - t:02 s:5BCD7F d:584885 010100004A
   myHmUART_UG_MSGCNT 34
   myHmUART_UG_RAWMSG 040300394180025BCD7F584885010100004A
   myHmUART_UG_RSSI -57
   myHmUART_UG_TIME 2018-03-31 22:08:51
   protCmdDel 9
   protErrIoAttack 12 last_at:2018-03-31 21:43:53
   protErrIoId_4C3DF4 12 last_at:2018-03-31 21:43:53
   protLastRcv 2018-03-31 22:08:51
   protResnd  12 last_at:2018-03-31 21:46:17
   protResndFail 4 last_at:2018-03-31 21:46:22
   protSnd    24 last_at:2018-03-31 22:08:51
   protState  CMDs_done
   rssi_4C3DF4 min:-62 max:-62 avg:-62 lst:-62 cnt:1 
   rssi_at_myHmUART_UG max:-48 avg:-55.4 min:-71 lst:-57 cnt:22 
   rssi_myHmUART_UG avg:-65.2 max:-61 min:-74 cnt:5 lst:-74 
   READINGS:
     2018-03-31 22:08:51   CommandAccepted yes
     2018-03-31 21:46:34   D-firmware      2.8
     2018-03-31 21:46:34   D-serialNr      OEQ0569807
     2018-03-31 21:46:39   PairedTo        0x584885
     2018-03-31 21:46:39   R-pairCentral   0x584885
     2018-03-30 20:10:18   R-powerUpAction off
     2018-03-30 20:10:18   R-sign          off
     2018-03-31 21:46:39   RegL_00.          02:01 0A:58 0B:48 0C:85 15:FF 18:00 00:00
     2018-03-31 21:46:40   RegL_01.         08:00  30:06 57:24 56:00 93:11 94:3A 00:00
     2018-03-31 22:08:51   deviceMsg       off (to vccu)
     2018-03-31 22:08:51   level           0
     2018-03-31 22:08:51   pct             0
     2018-03-31 22:08:51   recentStateType ack
     2018-03-31 21:43:53   sabotageAttackId_ErrIoId_4C3DF4  cnt:12
     2018-03-31 21:43:53   sabotageAttack_ErrIoAttack cnt 12
     2018-03-31 22:08:51   state           off
     2018-03-31 22:08:51   timedOn         off
   helper:
     HM_CMDNR   65
     cSnd       115848855BCD7F0201C80000,115848855BCD7F0201000000
     dlvlCmd    ++A0115848855BCD7F0201000000
     mId        00F0
     peerIDsRaw ,00000000
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5BCD7F,00,00,00
       nextSend   1522526931.34368
       rxt        0
       vccu       vccu
       p:
         5BCD7F
         00
         00
         00
       prefIO:
         myHmUART_UG
     mRssi:
       mNo        41
       io:
         myHmUART_UG:
           -51
           -51
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       4C3DF4:
         avg        -62
         cnt        1
         lst        -62
         max        -62
         min        -62
       at_myHmUART_UG:
         avg        -55.4090909090909
         cnt        22
         lst        -57
         max        -48
         min        -71
       myHmUART_UG:
         avg        -65.2
         cnt        5
         lst        -74
         max        -61
         min        -74
     shadowReg:
     tmpl:
Attributes:
   IODev      myHmUART_UG
   IOgrp      vccu:myHmUART_UG
   autoReadReg 4_reqStatus
   devStateIcon on:light_on-for-timer@red off:light_on-for-timer@green
   expert     2_raw
   firmware   2.8
   icon       light_on-for-timer
   model      HM-LC-Sw1-DR
   peerIDs    00000000,
   room       Untergeschoss
   serialNr   OEQ0569807
   subType    switch
   webCmd     statusRequest:toggle:on:off

Wie gesagt, auf dem Slave funktioniert der Schalter so wie er soll, gespiegelt auf dem Master kann ich keine Aktion durchführen.

Danke euch Beiden für das Interesse an dem Thema und angenehme Osterfeiertage.
Gruß Joachim

Otto123 · 01 April 2018, 10:04:30

Hallo Joachim,

ist 0x584885 auch Deine HMID auf der Hauptinstanz?

der Thermostat ist zwar angelegt, aber nicht vollständig. Ist der mit anderer HMID noch an der Hauptinstanz angelernt?
Ihm fehlen vor allem diese Readings

Code Auswählen

PairedTo        0x584885
R-pairCentral   0x584885

Wenn Du das so betreiben willst (was sehr sinnvoll ist) brauchst du in der Hauptinstanz lediglich eine VCCU und Dur ordnest den RM_HmUART dieser unter. Damit läuft alles wie bisher und sauber.

Gruß Otto

Im Übrigen: Kann selbstverständlich auf deinem zweiten Raspi auch FHEM laufen (für was auch immer) es darf bloß das RPI Modul nicht im Zugriff sein!

CottonIJo · 01 April 2018, 11:30:28

Hallo Otto,

es bleibt kompliziert für mich, vielleicht denke ich auch nur mit einem Knoten im Gehirn

Die HMID 0x584885 gehört zu dem RM_HmUART auf dem Slave-Pi der über socat am Master-Pi angebunden ist.
Der HmUART auf dem Master-Pi hat die HMID 0x4C3DF4 und ist zum pairen des HM-CC-RT-DN nicht benutzt worden.

Mein Ansatz war, die Anbindung des Thermostaten an den Slave-Pi (0x584885) wegen besserer Funkverbindung und dann Daten über socat an den Master holen bzw. über socat das Device verwalten. Der Gedanke ist, der RM_HMUART wirkt wie ein zweites Funkmodul, nur eben physikalisch auf einem zweiten Pi.
Deinen Ansatz verstehe ich nicht ganz, wenn ich den Thermostaten an die Hauptinstanz (0x4C3DF4) anlerne, brauche ich den Slave ja nicht mehr?
Leider ist mir die Verwaltung über eine VCCU auch nicht ganz klar, ich habe auf dem Master-Pi eine VCCU angelgt aber nur um z. Bsp. Fremdgeräte aus dem Log auszuschliessen.

Falls Du mir hier ein Beispiel geben könntest, würde mir das wohl weiterhelfen.

Danke und Grüße Joachim

Anbei ein paar Listings um die Installation zu verdeutlichen:
list myHmUART (HM-MOD-UART physikalisch auf dem Master-Pi)

Code Auswählen

 Internals:
   AssignedPeerCnt 30
   CNT        210
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     210
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         11
   LastOpen   1522529634.07984
   NAME       myHmUART
   NR         21
   PARTIAL    
   RAWMSG     04020A
   RSSI       -62
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 5
   msgLoadHistory 0/1/0/0/1/0/0/0/0/0/0/0
   msgLoadHistoryAbs 5/5/4/4/4/3/3/3/3/3/3/3/3
   owner      4C3DF4
   owner_CCU  vccu
   Helper:
     CreditTimer 2967
     FW         66561
     Initialized 1
     SendCnt    448
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         logdb:
           TIME       1522529639.74101
           VALUE      4C3DF4
       D-HMIdOriginal:
         logdb:
           TIME       1522529639.75061
           VALUE      4C3DF4
       D-firmware:
         logdb:
           TIME       1522529639.76502
           VALUE      1.4.1
       D-serialNr:
         logdb:
           TIME       1522529639.78013
           VALUE      NEQ0605362
       cond:
         logdb:
           TIME       1522529639.82167
           VALUE      ok
       loadLvl:
         logdb:
           TIME       1522529639.82167
           VALUE      low
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     PendingCMD:
     RoundTrip:
       Delay      0.00280404090881348
     loadLvl:
       lastHistory 1522574039.79474
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     30E2B9     +30E2B9,00,00,00
     30E2C0     +30E2C0,00,00,00
     4BE19E     +4BE19E,00,00,00
     4BE1A1     +4BE1A1,00,00,00
     4CE3C2     +4CE3C2,00,00,00
     4DA7D7     +4DA7D7,00,00,00
     4DA7F0     +4DA7F0,00,00,00
     4DA7F3     +4DA7F3,00,00,00
     4DA7F4     +4DA7F4,00,00,00
     4DA7F5     +4DA7F5,00,00,00
     4E72A5     +4E72A5,00,00,00
     4E81EC     +4E81EC,00,00,00
     4EBFFA     +4EBFFA,00,00,00
     4F96E0     +4F96E0,00,00,00
     51E0FC     +51E0FC,00,00,00
     51F811     +51F811,00,00,00
     51FBA9     +51FBA9,00,00,00
     52CD6A     +52CD6A,00,00,00
     533B1B     +533B1B,00,00,00
     55028D     +55028D,00,00,00
     5708C4     +5708C4,00,00,00
     570936     +570936,00,00,00
     5E8BE7     +5E8BE7,00,00,00
     62F750     +62F750,00,00,00
     6344ED     +6344ED,00,00,00
     63A734     +63A734,00,00,00
     63A815     +63A815,00,00,00
     63A93C     +63A93C,00,00,00
     63A946     +63A946,00,00,00
     63A950     +63A950,00,00,00
   READINGS:
     2018-03-31 22:53:59   D-HMIdAssigned  4C3DF4
     2018-03-31 22:53:59   D-HMIdOriginal  4C3DF4
     2018-03-31 22:53:59   D-firmware      1.4.1
     2018-03-31 22:53:59   D-serialNr      NEQ0605362
     2018-03-31 22:53:54   D-type          HM-MOD-UART
     2018-03-31 22:53:59   cond            ok
     2018-04-01 11:13:39   load            5
     2018-03-31 22:53:59   loadLvl         low
     2018-03-31 22:53:54   state           opened
   helper:
Attributes:
   hmId       4C3DF4
   icon       cul_868
   room       CUL_HM
   verbose    4

list RM_HmUART_UG (HM-MOD-UART über socat angebunden, physikalisch auf dem Slave-Pi)

Code Auswählen

 Internals:
   AssignedPeerCnt 0
   CFGFN      
   CNT        159
   Clients    :CUL_HM:
   DEF        uart://192.168.178.37:2000
   DEVCNT     220
   DevState   99
   DevType    UART
   DeviceName 192.168.178.37:2000
   FD         54
   LastOpen   1522529884.54847
   NAME       RM_HmUART_UG
   NR         411
   PARTIAL    
   RAWMSG     0500004C7486534EBFFA000000804101F64201BF43003744FFC9
   RSSI       -76
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 1
   msgLoadHistory 0/0/0/1/0/0/0/0/0/0/0/0
   msgLoadHistoryAbs 1/1/1/1/0/0/0/0/0/0/0/0/0
   owner      584885
   Helper:
     CreditTimer 2959
     FW         66561
     Initialized 1
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         logdb:
           TIME       1522529929.65246
           VALUE      584885
       D-HMIdOriginal:
         logdb:
           TIME       1522529887.18398
           VALUE      584885
       D-firmware:
         logdb:
           TIME       1522529887.3453
           VALUE      1.4.1
       D-serialNr:
         logdb:
           TIME       1522529887.47579
           VALUE      OEQ0309703
       cond:
         logdb:
           TIME       1522529887.97709
           VALUE      ok
       loadLvl:
         logdb:
           TIME       1522529887.97709
           VALUE      low
       state:
         logdb:
           TIME       1522574206.51672
           VALUE      UNKNOWNCODE A0CF3867054BE4D000000009238::-79:RM_HmUART_UG
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.0174911022186279
     loadLvl:
       lastHistory 1522573987.74689
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2018-03-31 22:58:49   D-HMIdAssigned  584885
     2018-03-31 22:58:07   D-HMIdOriginal  584885
     2018-03-31 22:58:07   D-firmware      1.4.1
     2018-03-31 22:58:07   D-serialNr      OEQ0309703
     2018-03-31 22:58:04   D-type          HM-MOD-UART
     2018-03-31 22:58:07   cond            ok
     2018-04-01 10:57:51   load            1
     2018-03-31 22:58:07   loadLvl         low
     2018-03-31 22:58:04   state           opened
Attributes:
   hmId       584885
   room       CUL_HM

list vccu (eingerichtet auf dem Master-Pi)

Code Auswählen

  Internals:
   DEF        4C3DF4
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     2607
   NAME       vccu
   NOTIFYDEV  global
   NR         40
   RM_HmUART_UG_MSGCNT 777
   RM_HmUART_UG_RAWMSG 0500004B53A0114C3DF44E81EC0201000000
   RM_HmUART_UG_RSSI -75
   RM_HmUART_UG_TIME 2018-04-01 11:18:15
   STATE      myHmUART:ok,
   TYPE       CUL_HM
   assignedIOs myHmUART
   lastMsg    No:53 - t:11 s:4C3DF4 d:4E81EC 0201000000
   myHmUART_MSGCNT 1830
   myHmUART_RAWMSG 0500003DFE86703F7AD900000000CD28
   myHmUART_RSSI -61
   myHmUART_TIME 2018-04-01 11:18:56
   protLastRcv 2018-04-01 11:18:15
   rssi_at_RM_HmUART_UG cnt:777 avg:-71.81 max:-67 lst:-75 min:-77 
   READINGS:
     2018-04-01 11:18:07   CommandAccepted yes
     2018-04-01 00:34:34   recentStateType ack
     2018-03-31 22:54:02   state           myHmUART:ok,
     2018-04-01 11:18:56   unknown_3F7AD9  received
     2018-04-01 10:25:09   unknown_464246  received
     2018-01-28 15:18:36   unknown_4BE19E  received
     2018-04-01 10:25:09   unknown_4C3F6D  received
     2018-04-01 11:16:30   unknown_4CF2C3  received
     2018-04-01 11:17:52   unknown_4CF35C  received
     2018-04-01 11:17:45   unknown_4CF6A1  received
     2018-03-29 20:39:08   unknown_4DA7D7  received
     2018-04-01 11:17:51   unknown_520C72  received
     2018-04-01 11:16:46   unknown_54BE4D  received
     2018-04-01 10:32:34   unknown_56A84D  received
     2018-04-01 10:58:52   unknown_56A891  received
     2018-04-01 10:57:41   unknown_584885  received
     2018-03-31 22:08:51   unknown_5BCD7F  received
     2018-01-21 17:03:11   unknown_62F750  received
     2018-01-13 17:15:00   unknown_6344ED  received
     2018-03-31 23:05:13   unknown_63A734  received
     2018-01-14 21:42:40   unknown_63A815  received
     2018-01-13 23:42:41   unknown_63A93C  received
     2018-01-13 21:19:26   unknown_63A946  received
     2018-01-13 22:52:46   unknown_63A950  received
     2018-04-01 11:04:29   unknown_650E91  received
     2017-12-24 22:51:48   unknown_9215ED  received
     2018-03-31 21:20:28   unknown_F10000  received
   helper:
     HM_CMDNR   83
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1522574295.90737
       prefIO     
       vccu       
       ioList:
         myHmUART
     mRssi:
       mNo        53
       io:
         RM_HmUART_UG:
           -75
           -75
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_RM_HmUART_UG:
         avg        -71.8133848133849
         cnt        777
         lst        -75
         max        -67
         min        -77
Attributes:
   IODev      myHmUART
   IOList     myHmUART
   event-on-change-reading .*
   model      CCU-FHEM
   room       VCCU
   subType    virtual
   webCmd     virtual:update

Otto123 · 01 April 2018, 12:08:49

Zitatich habe auf dem Master-Pi eine VCCU angelgt aber nur um z. Bsp. Fremdgeräte aus dem Log auszuschliessen.

das ist quasi nur eine Funktion der VCCU.
Hier ist doch eigentlich alles gut erklärt -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Die VCCU arbeitet einheitlich als Zentrale mit den IOs, wieviel Du hast und "wo auf der Welt" die verteilt sind spielt keine Rolle.
Der IO regelt die Funkverbindung zum Gerät.
Die Zentrale (VCCU) verwaltet die IOs und regelt über welchen IO welches Gerät erreichbar ist. Von sich aus würde sie die Funkverbindung (rssi Wert) als Kriterium nehmen.
Die VCCU skaliert damit deinen Funkbereich für Homematic, die VCCU muss die IOs nur über ein Netzwerk erreichen.

ZitatDer Gedanke ist, der RM_HMUART wirkt wie ein zweites Funkmodul, nur eben physikalisch auf einem zweiten Pi.

absolut richtig. Die VCCU bedient sie beide für Dich eigentlich transparent.
Du erweiterst nur diese Attribute

Code Auswählen

IOList myHmUART,RM_HmUART_UG
Und lernst die Geräte in Zukunft an der VCCU und nicht am IO an.

Vorhandene Geräte stellst Du durch das attr IOgrp um.
Deinen Aussen_Licht_Eingang musst Du neu pairen mit der VCCU.

Gruß Otto

CottonIJo · 01 April 2018, 22:56:00

Hallo Otto, vielen Dank, dein Ansatz mit der VCCU war die Lösung! (jetzt verstehe ich auch den/einen Vorteil einer VCCU)

Die Anbindung des Raspi-UG mit socat und dann an die VCCU ist genau die Lösung, die hier zielführend ist.
Alles hat funktioniert wie von Dir vorgeschlagen, mit dem positiven Nebeneffekt, dass ich jetzt bei einigen Devices ein besseres rssi habe als vorher.
Die Beschreibung der VCCU im Wiki ist hier sehr verständlich und hilfreich.

Ich werde meinen Raspi im Dachgeschoss jetzt auch auf socat umstellen und ihn über die VCCU anbinden, damit kann ich dann alle Geräte über eine Oberfläche und eine fhem Installation bedienen, super.

Grüße Joachim