Hallo zusammen,
auf grund zu großer Distanzen habe ich einen Raspi3(Buster) als "netzwerk"CUL aufgesetzt. Also ser2net installiert und die /etc/ser2net.conf editiert:
4000:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
Auf dem FHEM-Server Raspi4-Buster) habe ich diese CUL so eingebunden:
defmod HMLanGateway.Kino CUL 192.168.178.48:4000 0000
attr HMLanGateway.Kino group Gateways
attr HMLanGateway.Kino hmId 628CCA
attr HMLanGateway.Kino rfmode HomeMatic
Jetzt sollten sich doch die HMDevices, die sich in unmittelbarer Nähe des NetzwerkCUL befinden, sich mit diesem Verbinden? Oder?
Ich bekomme aber ein "unreachable", obwohl die Device und die CUL sich fast berühren.
Wie kann ich testen, ob der CUL richtig funktioniert bzw. wo der Fehler ist?
Gruß
Thomas
1. wird der buswareSCC am Raspi erkannt?
2. läuft ser2net sauber auf dem Raspi und hat FHEM drauf Zugriff (Netzwerk)?
3. ich würde einen wesentlich höheren port als 4000 (https://de.wikipedia.org/wiki/Well_Known_Ports#Registrierte_Ports:_1024%E2%80%9349151) nehmen
4. wie weist du den HM-Devices das IODev zu? Eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU) ist zu empfehlen.
5. Mit HMInfo (https://wiki.fhem.de/wiki/HomeMatic_HMInfo) lässt sich alles viel besser analysieren
Hallo yersinia,
das sind alles die Fragen, die ich mir auch stelle. Wie erkenne ich, ob ser2net sauber läuft?
FHEM sagt mir "Initialized"
Wenn FHEM "initialized" als Status hat, dann scheint die Verbindung zu funktionieren.
Testhalber kannst du mal die uptime oder die firmware-version des BuswareSCC auslesen.
get HMLanGateway.Kino uptime
get HMLanGateway.Kino versionWenn es da eine sinnvolle Antwort gibt, dann läufts wohl.
Dann würde ich bei
Zitat von: yersinia am 11 April 2021, 15:44:044. wie weist du den HM-Devices das IODev zu? Eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU) ist zu empfehlen.
5. Mit HMInfo (https://wiki.fhem.de/wiki/HomeMatic_HMInfo) lässt sich alles viel besser analysieren
weiter machen.
Ich kann die Version auslesen.
Ich habe eine VCC angelegt:
defmod VCCU CUL_HM 628CCA
attr VCCU .mId FFF0
attr VCCU IODev SCC
attr VCCU IOList SCC,HMLanGateway.Kino
attr VCCU IOgrp VCCU
attr VCCU expert defReg,rawReg
attr VCCU group Gateways,VCCU
attr VCCU model CCU-FHEM
attr VCCU room Hardware
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Beispiel eines HMDev:
defmod Relais.Kino.1 CUL_HM 667285
attr Relais.Kino.1 .mId 00D0
attr Relais.Kino.1 IODev SCC
attr Relais.Kino.1 IOgrp VCCU
Was solli ch bei HMINfo analysieren?
Zitat von: derHeimwerker am 11 April 2021, 16:05:48Beispiel eines HMDev:
defmod Relais.Kino.1 CUL_HM 667285
attr Relais.Kino.1 .mId 00D0
attr Relais.Kino.1 IODev SCC
attr Relais.Kino.1 IOgrp VCCU
Also haben alle relevanten HM-Devices eine IOgrp zugewiesen bekommen (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#IOgrp_bei_nachtr.C3.A4glicher_Einrichtung_einer_VCCU)?
Zitat von: derHeimwerker am 11 April 2021, 16:05:48Was solli ch bei HMINfo analysieren?
get [HMinfo Device] rssizeigt dir die Empfangswerte zwischen der Devices und deinem IODev. Zu weit weg und zu nah dran ist jeweils driss. Du kannst noch mit preferred IO (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Dynamisches_IO) der VCCU dein Wunsch-IO mitteilen.
Ansonsten einfach etwas warten und ggf die bisher unerreichbaren Devices mal anfragen, mit einem getconfig o.ä.
hmmm .... ein get [HMinfo Device] rssi zeigt mir die maßgeblichen Devices gar nicht an ??!!
wie heisst denn dein HMinfo Device?
schlicht und ergreifend "hm"
Ich meinte ein "get hm rssi" zeigt diese Devices nicht an
get hm update
ein paar Minuten warten und dann
get hm rssi
keine Veränderung
Ein configCheck sagt u.A. folgendes :
missing register list
Dimmer.Kino.Deckenfries: RegL_01.
Dimmer.Kino.Deckenfries_Device: RegL_00.
Dimmer.Kino.Deckenfries_Device_Dim_V_01: RegL_01.
ZitatIch bekomme aber ein "unreachable", obwohl die Device und die CUL sich fast berühren.
wenn dir einer ins ohr schreit, verstehst du auch nicht viel. ;)
besser 1-2 meter abstand.
im "Corona-bewährtem" Abstand von 1,5m augestellt. immer noch keinen Kontakt
Hallo Thomas,
ich kann noch nicht erkennen das der CUL / SCC überhaupt läuft?
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Prozesse_vor_dem_FHEM_Start_ausf.C3.BChren und der Link dort ins Forum
Überhaupt gemacht und erst mal lokal getestet?
Gruß Otto
Hallo Otto,
ja die SCC ist sowohl auf dem remoteRaspi als auch auf dem FhemRaspi installiert.
das war irgendwie nicht meine Frage - oder schlimmer? Du betreibst auf dem Pi3 ein FHEM welches den SCC benutzt?
Ich betreibe einen Raspi4 auf dem Fhem läuft. Auf dem sitzt eine stackable SCC. Darüber hinaus habe ich einen Raspi (3) auf dem ebenfalls eine busware stackable SCC sitzt. Diese "netzwerk"SCC ist bzw. soll über ser2net mit dem Fhem-Raspi sprechen.
Und bei beiden habe ich deine Verlinkungen angewendet.
Ok, dann weißt Du was zu tun ist, das wollte ich nur sicher stellen.
Aber trotzdem nochmal gefragt:
Auf dem Pi3 greift lokal nichts auf den SCC / die HMUART Schnittstelle zu (außer ser2net) ? Weil: ser2net ist kein Sharing! Das ist ne exklusiver "Strippe"
Und hast Du dort mal getestet, dass der SCC wirklich funktioniert? Also erstmal lokal ansprechbar ist (wobei ich nicht sagen wie das bei einem SCC / CUL überhaupt geht - ich habe keinen :) )
Weil scheinbar ist doch der Stand immer noch der: Der Remote CUL redet nicht mit HM? Solange das so ist ist es ja müßig irgendwas in HM zu versuchen.
Mal ein list HMLanGateway.Kino also von dem FHEM device welches auf den remote CUL zugreift? Sieht man da nicht das die miteinander reden?
Sieht das vergleichbar mit dem lokalen SCC FHEM Device aus?
Mich wundert, dass der remote SCC auf "initialized" im FHEM steht und er uptime & version auslesen kann. Es gibt zumindest eine rudimentäre lesende Verbindung von FHEM->ser2net SCC.
Wie könnte man überprüfen ob der remote SCC senden/empfangen kann? VCCU ist auch eingerichtet.
Kann man von dem unreachable Device auch ein senden erzwingen? Quasi Knöpchen drücken? Vielleicht zusammen mit einem getconfig des betroffenen Devices?
[glaskugel]Evtl mal FHEM neu starten (apropos: fhem aktuell?)?[/glaskugel]
Ja. Ist alles aktuell. Fhem und Buster!
Mich würde auch interessieren, wie man eine Testkommunikation zwischen FHEM ud REMOTE aufbauen könnte.
Ich habe gerade versucht ein neues Pairing zwischen der VCC und einem Device herzustellen. Das Device hat nicht erkannt, dann es eine RemoteCUL gibt. Und der FHEM-Server ist halt zu weit weg.
Wenn ich den Status des ser2net services mittel
sudo systemctl status ser2net
überprüfe, bekomme ich folgendes
Apr 11 20:26:13 culkino systemd[1]: Starting LSB: Allows network connections to serial ports...
Apr 11 20:26:13 culkino ser2net[896]: Unable to create network socket(s) on line 77
Apr 11 20:26:13 culkino ser2net[896]: ser2net startup
Apr 11 20:26:13 culkino ser2net[891]: Starting Serial port to network proxy: ser2net.
Apr 11 20:26:13 culkino systemd[1]: Started LSB: Allows network connections to serial ports.
Hast Du meinen Beitrag #17 nicht gelesen?
Da habe ich nicht verstanden, was ich machen soll.
Ach ja, und nach einem reboot ist die Fehlermeldung "unable tocreate network socket" auch wieder verschwunden.
Das list Kommando was ich geschrieben habe kopierst Du in die FHEM Kommandozeile und drückst enter.
Die Ausgabe kopierst Du wieder und schreibst sie in Codetags in einen Post ::)
:-) war nicht so schwer.
Internals:
CMDS mBbCFiAZGMYRTVWXef*ltux
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF 192.168.178.48:40000 0000
DeviceName 192.168.178.48:40000
FD 31
FHTID 0000
FUUID 5e1b26db-f33f-0f85-afbb-88b091c731210a08
HMLanGateway.Kino_MSGCNT 95
HMLanGateway.Kino_TIME 2021-04-11 13:52:17
NAME HMLanGateway.Kino
NR 59
PARTIAL
RAWMSG A0FE98610319BB90000000A88B90B0000D2
RSSI -97
STATE Initialized
TYPE CUL
VERSION V 1.61 CSM868
initString X21
owner_CCU VCCU
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2021-04-11 13:52:22 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2021-04-11 20:44:12 cmds m B b C F i A Z G M Y R T V W X e f * l t u x
2021-04-11 20:44:12 state Initialized
2021-04-11 20:51:27 uptime 0 00:08:21
2021-04-11 20:44:19 version V 1.61 CSM868
helper:
290CEA:
QUEUE:
29AE7F:
QUEUE:
29AE83:
QUEUE:
2AD604:
QUEUE:
319B9E:
QUEUE:
319CC7:
QUEUE:
32163A:
QUEUE:
Attributes:
group Gateways
hmId 628CCA
rfmode HomeMatic
room Hardware
verbose 0
Den Port habe ich auf beiden "Seiten" auf 40000 geändert.
ok sieht gut aus. Scheint so als ob der remote SCC erreichbar ist. ;)
Und jetzt mal ein list der VCCU und ein list eine Devices mit dem der Remote SCC reden soll.
VCCU
Internals:
DEF 628CCA
FUUID 5e1628cb-f33f-0f85-61d3-2a27878537b0d5a2
IODev SCC
NAME VCCU
NOTIFYDEV global
NR 63
NTFY_ORDER 50-VCCU
STATE SCC:opened,HMLanGateway.Kino:ok
TYPE CUL_HM
assignedIOs HMLanGateway.Kino,SCC
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
READINGS:
2021-01-31 22:13:10 CommandAccepted yes
2021-04-11 17:27:26 IOopen 1
2021-04-11 16:58:39 cfgState ok
2020-01-13 14:18:30 recentStateType ack
2021-04-11 17:27:26 state SCC:opened,HMLanGateway.Kino:ok
2020-09-20 12:37:07 unknown_130224 received
2020-09-20 14:55:04 unknown_13D816 received
2020-09-20 12:26:53 unknown_14071C received
2020-04-14 08:54:01 unknown_218991 received
2021-01-31 19:25:38 unknown_260670 received
2020-11-15 10:42:46 unknown_321632 received
2021-01-31 06:30:00 unknown_34773D received
2021-01-31 19:39:05 unknown_4048AB received
2020-01-13 19:47:34 unknown_530446 received
2021-01-31 18:08:15 unknown_5BE9F4 received
2021-03-18 11:52:51 unknown_620753 received
2021-01-31 23:18:36 unknown_AFFEF8 received
2021-01-31 20:50:21 unknown_B56851 received
2020-12-08 08:58:54 unknown_BD9225 received
helper:
HM_CMDNR 157
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
ack:
cmds:
TmplKey :no:1618136795.83186
TmplTs 1618136795.83186
cmdKey 0:1:1::VCCU:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerSmart -peerOpt-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt Aussenlicht.Haustuer,Aussenlicht.TerrasseDoerte,Aussenlicht.TerrasseGartenKueche,Aussenlicht.TerrasseGartenWohnen,Dimmer.Kino.Deckenfries,Dimmer.Kino.Deckenfries_Device_Dim_V_01,Dimmer.Kino.Deckenfries_Device_Dim_V_02,Fenster.BadGiebel,Fenster.GaesteWC,Fenster.HWR,Fenster.Kueche,Fenster.Kueche_tod,Fenster.Milo,Fenster.Schlafen,Fenster.WohnzimmerDoert,Fenster.WohnzimmerSonnenterrasse,Fenster.WohnzimmerStrasseLinks,Fenster.WohnzimmerStrasseRechts,Fenster.WohnzimmerTerrasseGarten,Funkschalter.Kino.Subwoofer,HM_Handsender.light,HM_Handsender_lock,HM_Handsender_open,HM_Handsender_unlock,Relais.Kino.1.AVR,Relais.Kino.1.Beamer,Relais.Kino.1.Deko,Relais.Kino.1.LichtBar,Schalter.ZirkulationspumpeHWR,Thermostat.BadHandtuch_WindowRec,Thermostat.BadHandtuch_remote,Thermostat.FlurUnten_WindowRec,Thermostat.FlurUnten_remote,Thermostat.KinoGarten_WindowRec,Thermostat.KinoGarten_remote,Thermostat.KinoStrasse_WindowRec,Thermostat.KinoStrasse_remote,Thermostat.Kueche_WindowRec,Thermostat.Kueche_remote,Thermostat.WohnzimmerGarten_WindowRec,Thermostat.WohnzimmerGarten_remote,Thermostat.WohnzimmerStrasseLinks_WindowRec,Thermostat.WohnzimmerStrasseLinks_remote,Thermostat.WohnzimmerStrasseRechts_WindowRec,Thermostat.WohnzimmerStrasseRechts_remote,Tuer.HWRGarage,Wandthermostat_WindowRec.Wohnzimmer,Wandthermostat_remote.Wohnzimmer
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
SCC
HMLanGateway.Kino
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev SCC
IOList SCC,HMLanGateway.Kino
IOgrp VCCU
expert defReg,rawReg
group Gateways,VCCU
model CCU-FHEM
room Hardware
subType virtual
webCmd virtual:update
Relais
Internals:
DEF 667285
FUUID 5ce03bcd-f33f-0f85-0caf-62a9ce9b30c8085b
IODev SCC
NAME Relais.Kino.1
NOTIFYDEV global
NR 576
NTFY_ORDER 50-Relais.Kino.1
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 Relais.Kino.1.Beamer
channel_02 Relais.Kino.1.AVR
channel_03 Relais.Kino.1.Deko
channel_04 Relais.Kino.1.LichtBar
protCmdDel 100
protResnd 78 last_at:2021-04-11 21:12:06
protResndFail 26 last_at:2021-04-11 21:12:11
protSnd 26 last_at:2021-04-11 21:11:52
protState CMDs_done_Errors:1
READINGS:
2019-05-18 19:08:12 CommandAccepted yes
2019-05-18 19:07:26 D-firmware 2.4
2019-05-18 19:07:26 D-serialNr PEQ0085691
2020-06-20 21:09:12 PairedTo 0x629CDA
2019-05-18 19:13:25 R-pairCentral 0x629CDA
2021-04-11 21:11:52 cfgState updating
2021-04-11 21:12:11 commState CMDs_done_Errors:1
2019-12-01 12:37:33 powerOn 2019-12-01 12:37:32
2020-04-28 21:52:54 sabotageAttack_ErrIoAttack cnt 1
2021-04-11 21:12:11 state RESPONSE TIMEOUT:RegisterRead
RegL_00.:
VAL
helper:
HM_CMDNR 95
cSnd 01629CDA66728500040000000000,01629CDA66728500040000000000
mId 0003
peerFriend
peerOpt -:switch
regLst 0
rxType 1
cfgChk:
idRc01 RegL_00.
cmds:
TmplKey :no:1618140771.15445
TmplTs 1618140771.15445
cmdKey 0:1:0::Relais.Kino.1:0003:00:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
pair noArg
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +667285,00,00,00
prefIO
rxt 0
vccu VCCU
p:
667285
00
00
00
mRssi:
mNo
io:
HMLanGateway.Kino:
SCC:
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev SCC
IOgrp VCCU
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.4
group Relais
model HM-LC-SW4-DR-2
room Devices
serialNr PEQ0085691
subType switch
webCmd getConfig:clear msgEvents
Auf dem Remote habe ich überprüft, ob ser2net funktioniert:
netstat -na | grep 40000
Antwort:
tcp6 0 0 :::40000 :::* LISTEN
tcp6 0 0 192.168.178.48:40000 192.168.178.222:42466 VERBUNDEN
Schaut ja vom Grunde gut aus. Allerdings ist das eine IP6 Verbindung. Sollte da nicht eine IP4 Verbindung stehen?
Na ditte kann nüschts werdn:
Zitat von: derHeimwerker am 11 April 2021, 21:42:11Internals:
2020-06-20 21:09:12 PairedTo 0x629CDA
2019-05-18 19:13:25 R-pairCentral 0x629CDA
Zitat von: derHeimwerker am 11 April 2021, 21:07:53
hmId 628CCA
Die HmId sollte überall gleich sein, oder?
Du hast einen grundlegenden Fehler?!
Relais
PairedTo 0x629CDA
VCCU
DEF 628CCA
Warum hast DU die VCCU mit einer anderen hmId definiert? Das funktioniert so nicht!
da ist beim Kopieren wohl etwas durcheinander geraten. Die HmID ist überall gleich.g
Guten Morgen,
daran glaube ich nicht. Das list Deiner VCCU und deines Relais ist für mich eindeutig. Es sei denn es sind nicht Deine Lists und Du hast sie irgendwo her kopiert.
Nochmal: Dein Relais ist mit einer Zentrale 0x629CDA gepairt, deine VCCU ist aber mit 628CCA definiert. Damit kann das nicht funktionieren und die Fehler in den Readings sind mMn eindeutig.
Gruß Otto
Also noch einmal. List vom Relais sagt:
2020-06-20 21:09:12 PairedTo 0x629CDA
2019-05-18 19:13:25 R-pairCentral 0x629CDA
von der VCCU
DEF 629CDA
und vom HMLanGateway.Kino
hmId 629CDA
rfmode HomeMatic
das scheint zu stimmen.
Eine Verbingung zwischen den beiden Raspi;s ist ebenfalls vorhanden.
Die FWVersion kann angezeigt werden:
VERSION V 1.61 CSM868
Ist es möglich, dass die SCC einfach irgnedwo noch "hängt" oder einfach kaputt ist?
Kannst Du dann bitte nochmal ein list der echten VCCU machen? Weil dein list der falschen ? VCCU aus #26 einhält überhaupt keine RSSI Werte, es sieht aus als hat die noch nie mit irgend jemandem geredet - auch nicht lokal :o
Internals:
DEF 629CDA
FUUID 5e1628cb-f33f-0f85-61d3-2a27878537b0d5a2
HMLanGateway.Kino_MSGCNT 1
HMLanGateway.Kino_RAWMSG AVRBOOT08?SYY�V 1.61 CSM868
HMLanGateway.Kino_TIME 2021-04-12 09:57:15
IODev SCC
LASTInputDev HMLanGateway.Kino
MSGCNT 1
NAME VCCU
NOTIFYDEV global
NR 63
NTFY_ORDER 50-VCCU
STATE SCC:opened,HMLanGateway.Kino:ok
TYPE CUL_HM
assignedIOs HMLanGateway.Kino,SCC
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
READINGS:
2021-01-31 22:13:10 CommandAccepted yes
2021-04-11 17:27:26 IOopen 1
2021-04-11 16:58:39 cfgState ok
2020-01-13 14:18:30 recentStateType ack
2021-04-11 17:27:26 state SCC:opened,HMLanGateway.Kino:ok
2020-09-20 12:37:07 unknown_130224 received
2020-09-20 14:55:04 unknown_13D816 received
2020-09-20 12:26:53 unknown_14071C received
2020-04-14 08:54:01 unknown_218991 received
2021-01-31 19:25:38 unknown_260670 received
2020-11-15 10:42:46 unknown_321632 received
2021-01-31 06:30:00 unknown_34773D received
2021-01-31 19:39:05 unknown_4048AB received
2020-01-13 19:47:34 unknown_530446 received
2021-01-31 18:08:15 unknown_5BE9F4 received
2021-03-18 11:52:51 unknown_620753 received
2021-04-12 09:57:15 unknown_?SYY� received
2021-01-31 23:18:36 unknown_AFFEF8 received
2021-01-31 20:50:21 unknown_B56851 received
2020-12-08 08:58:54 unknown_BD9225 received
helper:
HM_CMDNR 157
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
ack:
cmds:
TmplKey :no:1618136795.83186
TmplTs 1618136795.83186
cmdKey 0:1:1::VCCU:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerSmart -peerOpt-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt Aussenlicht.Haustuer,Aussenlicht.TerrasseDoerte,Aussenlicht.TerrasseGartenKueche,Aussenlicht.TerrasseGartenWohnen,Dimmer.Kino.Deckenfries,Dimmer.Kino.Deckenfries_Device_Dim_V_01,Dimmer.Kino.Deckenfries_Device_Dim_V_02,Fenster.BadGiebel,Fenster.GaesteWC,Fenster.HWR,Fenster.Kueche,Fenster.Kueche_tod,Fenster.Milo,Fenster.Schlafen,Fenster.WohnzimmerDoert,Fenster.WohnzimmerSonnenterrasse,Fenster.WohnzimmerStrasseLinks,Fenster.WohnzimmerStrasseRechts,Fenster.WohnzimmerTerrasseGarten,Funkschalter.Kino.Subwoofer,HM_Handsender.light,HM_Handsender_lock,HM_Handsender_open,HM_Handsender_unlock,Relais.Kino.1.AVR,Relais.Kino.1.Beamer,Relais.Kino.1.Deko,Relais.Kino.1.LichtBar,Schalter.ZirkulationspumpeHWR,Thermostat.BadHandtuch_WindowRec,Thermostat.BadHandtuch_remote,Thermostat.FlurUnten_WindowRec,Thermostat.FlurUnten_remote,Thermostat.KinoGarten_WindowRec,Thermostat.KinoGarten_remote,Thermostat.KinoStrasse_WindowRec,Thermostat.KinoStrasse_remote,Thermostat.Kueche_WindowRec,Thermostat.Kueche_remote,Thermostat.WohnzimmerGarten_WindowRec,Thermostat.WohnzimmerGarten_remote,Thermostat.WohnzimmerStrasseLinks_WindowRec,Thermostat.WohnzimmerStrasseLinks_remote,Thermostat.WohnzimmerStrasseRechts_WindowRec,Thermostat.WohnzimmerStrasseRechts_remote,Tuer.HWRGarage,Wandthermostat_WindowRec.Wohnzimmer,Wandthermostat_remote.Wohnzimmer
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
SCC
HMLanGateway.Kino
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev SCC
IOList SCC,HMLanGateway.Kino
IOgrp VCCU
expert defReg,rawReg
group Gateways,VCCU
model CCU-FHEM
room Hardware
subType virtual
webCmd virtual:update
Also wenn Du mich fragst... : Dein lokaler SCC arbeitet nicht. Der steht nur auf opened und nicht auf ok. Hier steht auch nur eine 1 - die sich offenbar auf den remote CUL bezieht.
2021-04-11 17:27:26 IOopen 1
Allerdings scheint es remote nicht störungsfrei, solche Zeichen sind komisch: 2021-04-12 09:57:15 unknown_?SYY� received
Funktioniert jetzt aktuell überhaupt etwas?
wow. ... da war irgendwas völlig ausser kontrolle geraten. So jetzt funkt wenigstens der lokale SCC wieder.
Sooo.. nach einer komoletten Neuinstallation beider Raspi, kommt nun ein vernünftiger Kontakt zustande. Leider hat mein HM Dimmer wohl ein kleines Problem und ich bekomme nach einem ersten Pairen ein " RESPONSE TIMEOUT:RegisterRead".
Aber das scheint ein anderes Thema zu sein.
Vielen dank für die Hilfe!
Du darfst eins nicht vergessen: Ein CUL - also ein IO nicht speziell für Homematic - ist ein Kompromiss. Die Geräte mit mehreren Channels (Dimmer gehören dazu) sind nicht unproblematisch in der Kommunikation.
Ich weiß nicht wie Du drauf gekommen bist zwei CULs (SCCs) einzusetzen, zwei hiervon (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) wären wesentlich besser und vielleicht sogar billiger gewesen.
Das waren noch Relikte aus der Vergangenheit und waren für den ersten Einstieg gedacht.
Da ich von diesen Dimmern ohnehin schwer genervt bin, wollte ich schon auf wired umsteigen. Darüber laufen 13 Rollläden wunderbar.
Fensterkontakte von HM sind mit der CUL auch wohl unproblematisch.
Bin mit der Lötspitze jetzt nicht so auf DU und Du :-) Bekommt man den Bausatz denn zusammengebraten ?
Ich habe auch schon über den HMLan Adapter nachgedacht.
Was wäre da aus der Sicht die bessere Wahl ?
Naja ist halt die Frage ob man für diese quasi beendete Generation Homematic noch was anschafft.
Der Bausatz sind ca. 20 notwendige Lötstellen im normalen Bereich - die Lötspitze war aber auch jahrelang mein Beruf ;)
Das Lan Gateway ist einfach fertig, da brauchst Du den abgesetzten Pi nicht.
Die Kombination von HomeMatic und HomeMaticIP funktioniert ja noch nicht so richtig, wenn ich das so oberflächlich mitbekommen habe. Und bei einer "alten" RS485 Verbindung kann man wenig kaputt machen :-)
Ich habe jetzt mal 2 von den HM-MOD-RPI-PCB bestellt. Mal sehen, ob ich damit zu recht komme.
Läuft die softwaremäßige Anbindung analog zum SCC? Also GPIO Port freischalten / Bluetooth umlegen ...?
Bluetooth umlegen ja, GPIO frei (Pin17?) schalten nein. Den extra Dienst oder das Script für den SCC kannst Du quasi totlegen.
Naja wenn man jetzt mit HM Ip weiter machen will, würde ich stand heute wahrscheinlich aus dem Raspberry eine CCU3 bauen, alles (also auch das alte Homematic) dort anlernen und die FHEM Anbindung mit dem HMCCU Modul machen (hätte vor einem Jahr nicht gedacht, dass ich das mal sage).
Zitathätte vor einem Jahr nicht gedacht, dass ich das mal sage
verräter?
Für meine Installation bedeutet das, da ich eine VCCU definiert habe, dass ich diese um die beiden neuen HM-MOD-RPI-PCB erweitere und die bisherigen löschen kann, oder ?
Da ich die VCCU erst später eingerichtet habe, macht es da mehr Sinn alle HM Sensoren (13 Türsensoren, 10 Thermostate, 4 Lichtschalter und 2 Steckdosen) neu mit der VCCU zu pairen ?
So ist es: Du erweiterst die VCCU, nimmst die neuen in Betrieb und die alten fliegen raus.
pairen ist ein Vorgang, da wird die hmId der Zentrale in das Gerät geschrieben. Wenn gepairt braucht man nicht neu pairen. Aufgrund deines Kuddelmuddels hier beim posten mit VCCUs mit unterschiedlicher Definition, bin ich nicht sicher auf welchem Stand Du bist. Bei der späteren Einrichtung der VCCU wird normal die vorhandene hmId genommen, die vorher dem IO zugeordnet war. Insofern ist neu pairen nicht nötig.
Zitat von: Otto123 am 13 April 2021, 12:27:29
Aufgrund deines Kuddelmuddels hier beim posten mit VCCUs mit unterschiedlicher Definition
Das habe ich händisch verbockt :-( Die reale Installation ist aber sauber.
Ich warte jetzt mal auf die Lieferung.
Vielen Dank für deine Unterstützung und Hilfe!!
Soo . die Hardware ist da :-) Löten wurde mir abgenommen !
Leider hört es aber auch schon wieder auf.
Ich habe die Firmaware geflasht
und das SCC - Script / Dienst abgeschaltet.
sudo systemctl stop scc.service
eine list der neuen CUL zeigt:
Internals:
AssignedPeerCnt 0
CNT 27
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 27
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 4
FUUID 6076f3a0-f33f-0f85-2647-4bed387f71cde3c4
LastOpen 1618410633.67451
NAME CUL.HWR
NOTIFYDEV global
NR 684
NTFY_ORDER 50-CUL.HWR
PARTIAL
RAWMSG 040200
RSSI -53
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
owner 629CDA
owner_CCU VCCU
Helper:
CreditTimer 12
FW 66049
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.00320100784301758
loadLvl:
lastHistory 1618410636.20821
MatchList:
1:CUL_HM ^A......................
Peers:
READINGS:
2021-04-14 16:30:36 D-HMIdAssigned 629CDA
2021-04-14 16:30:36 D-HMIdOriginal 71CE25
2021-04-14 16:30:36 D-firmware 1.2.1 (outdated)
2021-04-14 16:30:36 D-serialNr REQ0913151
2021-04-14 16:26:55 D-type HM-MOD-UART
2021-04-14 16:30:36 cond ok
2021-04-14 16:30:36 load 0
2021-04-14 16:30:36 loadLvl low
2021-04-14 16:30:33 state opened
Attributes:
hmId 629CDA
room Hardware
Sieht doch eigentlich ganz gut aus, oder?
Zitat
2021-04-14 16:30:36 D-firmware 1.2.1 (outdated)
Solltest (nein musst) du auf jeden Fall ändern! ;)
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Firmware_Update_des_UART-Moduls_mit_FHEM
Wichtig: nicht die neueste FW sondern genau die genannte!
Gruß, Joachim
hm .. der Link auf der Seite führt mich aber zu dieser Version?!
Zwei/drei Befehle in der FHEM Kommandozeile:
"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3"
{qx(ls -lha ./FHEM/firmware)}
set CUL.HWR updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3Einzeln!
Dann den IO in die IOlist der VCCU eintragen.
ZitatIch habe die Firmaware geflasht
Was genau hast Du gemacht? Schritt für Schritt?
Zitat von: derHeimwerker am 14 April 2021, 16:45:03
hm .. der Link auf der Seite führt mich aber zu dieser Version?!
?
Welcher Link auf welcher Seite führt zu welcher Version?
Gruß, Joachim
... jetzt ist es die 1.4.1 :-)