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
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
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
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
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
list DEVICENAME
Und ganz wichtig das Ergebnis bitte in Codetags hier einstellen. Dann ist es so wie oben der list zu sehen.
@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:
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
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)
Internals:
NAME Aussen_Licht_Eingang
NR 382
STATE ???
TYPE dummy
Attributes:
list 50_Aussen_Licht_Eingang (auf dem Master-Pi)
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)
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
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
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!
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)
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)
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)
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
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
IOList myHmUART,RM_HmUART_UGUnd 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
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