Hallo,
ich bin dabei meine FHEM Installation vom Banana auf einen RPI4 umzuziehen.
Was habe ich bisher gemacht und was funktioniert.
- RPI4 bootet von SSD ein aktuelles Raspbian.
- Busware SCC ist aufgesteckt und blinkt rythmisch im Sekundentakt
FHEM läuft
Den Wandtaster kann ich pairen mit HMpair. Ist mit einer VCCU gepaired.
Dann erstelle ich einen virtuellen Aktor und will den mit den Tasten verbinden.
Er bleibt im cmd_pending hängen.
Der virtuelle Aktor ist gepeert, der TasterButton aber nicht.
List vom Taster
DEF 72443F
FUUID 5fdb16dd-f33f-ff73-f623-ed4c7211735f6ecb
IODev SCC
LASTInputDev SCC
MSGCNT 15
NAME HM_72443F
NOTIFYDEV global
NR 40
NTFY_ORDER 50-HM_72443F
SCC_MSGCNT 15
SCC_RAWMSG A0BF8A04072443F1234570272::-34.5:SCC
SCC_RSSI -34.5
SCC_TIME 2020-12-17 10:36:04
STATE HM_72443F_Btn_02 Short
TYPE CUL_HM
channel_01 HM_72443F_Btn_01
channel_02 HM_72443F_Btn_02
channel_03 HM_72443F_Btn_03
channel_04 HM_72443F_Btn_04
channel_05 HM_72443F_Btn_05
channel_06 HM_72443F_Btn_06
lastMsg No:F8 - t:40 s:72443F d:123457 0272
protCmdPend 11 CMDs pending
protLastRcv 2020-12-17 10:36:03
protRcv 7 last_at:2020-12-17 10:36:03
protResnd 2 last_at:2020-12-17 10:32:19
protSnd 4 last_at:2020-12-17 10:32:13
protState CMDs_pending
rssi_at_SCC cnt:15 min:-44.5 max:-28.5 avg:-34.76 lst:-34.5
READINGS:
2020-12-17 10:32:13 D-firmware 1.2
2020-12-17 10:32:13 D-serialNr REQ0863094
2020-12-17 10:23:30 PairedTo 0x000000
2020-12-17 10:23:30 RegL_00. 00:00 02:00 0A:00 0B:00 0C:00 18:00
2020-12-17 10:36:03 battery ok
2020-12-17 10:23:25 cfgState updating
2020-12-17 10:32:19 commState CMDs_pending
2020-12-17 10:36:03 state HM_72443F_Btn_02 Short
cmdStack:
++A00131057572443F01040000000001
++A00131057572443F0103
++A00131057572443F02040000000001
++A00131057572443F0203
++A00131057572443F03040000000001
++A00131057572443F0303
++A00131057572443F04040000000001
++A00131057572443F0403
++A00131057572443F05040000000001
++A00131057572443F0503
++A00131057572443F06040000000001
++A00131057572443F0603
helper:
HM_CMDNR 248
cSnd 0131057572443F01040000000001,0131057572443F01040000000001
mId 00A9
peerFriend
peerOpt -:remote
regLst 0
rxType 28
supp_Pair_Rep 0
ack:
123457 HM_72443F_Btn_02:F8
cmds:
TmplKey :no:1608197538.85251
TmplTs 1608197538.85251
cmdKey 0:1:0::HM_72443F:00A9: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) [-peerChn-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +72443F,02,00,00
nextSend 1608197764.55178
rxt 2
vccu VCCU
p:
72443F
00
00
00
prefIO:
SCC
mRssi:
mNo F8
io:
SCC:
-26.5
-26.5
prt:
bErr 0
sProc 2
wuReSent 3
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rssi:
at_SCC:
avg -34.7666666666667
cnt 15
lst -34.5
max -28.5
min -44.5
shadowReg:
tmpl:
Attributes:
IODev SCC
IOgrp VCCU:SCC
autoReadReg 4_reqStatus
expert rawReg
firmware 1.2
model HM-PB-6-WM55
room CUL_HM
serialNr REQ0863094
subType remote
webCmd getConfig:clear msgEvents
Wenn ich einfach die alte config vom Banana nehme, dann empfängt der FHEM nur einmal und bleibt dann regungslos auf Homematic Funk.
Mit der jetzigen config meldet er und will auch ausführen, das Lämpchen am Taster bleibt aber rot.
Any Ideas?
Danke
Martin
Nach einem getConfig für den taster füllt sich die Liste der CMDs pending.
LastMsg sieht verdächtig aus, da kann ich aber ncihts mit anfangen.
lastMsg
No:FD - t:00 s:72443F d:000000 1200A95245513038363330393440060000
Teilweise gelöst:
Habe die Firmware am SCC auf 1.67 aktualisiert und dann die alte config genutzt.
Jetzt geht die alte config und der Taster antwortet auch (blinkt grün).
Ich vermute ich habe die Taster vorher nicht unpeered (also garantiert nicht).
Wie kann ich einen Taster unpeeren ohne die Ursprungs-SCC im Zugriff zu haben?
Ich hätte jetzt sonst auch alles von vorne aufgebaut.
Nu denn läuft, ich bin aber nicht zufrieden, weil ich es nicht so ganz verstehe.
Grüße
Martin
du solltest dich mal mit den unterschiedlichen kommunikations verfahren deiner devices beschäftigen.
über get deviceInfo siehst du die vom device unterstützten modes.
ein weiterer cmd (getconfig) verringert keine pending cmds.
im gegenteil, es kommen weitere dazu. ganz ans ende der cmd queue.
eigentlich logisch, oder nicht?
erst das knöpfchen drücken (last msg) hat dein device geweckt, wodurch die cmd queue (teilweise) abgearbeitet werden konnte.
da dein scc wahrscheinlich kein timing beherscht (unpassendes gateway mit schlechter fw), wird die queue, wenn überhaupt, nur häppchenweise, abgearbeitet.
also öfter mal aufs knöpfchen drücken.
ps:
es wäre schön, wenn du deine list mit code tags formatieren würdest.
tipp:
1. mit hm.js (die "test" version über den link in meiner sig) kannst du den aktuellen kommunikationsstatus sehr "anschaulich" live verfogen.
2. mit hminfotools.js (angepinnter thread) bekommst du eine "schöne" tabelle aller devices, die hminfo mit problemen identifiziert hat.
Hallo Frank,
und Danke für deine Antwort.
Zitat von: frank am 17 Dezember 2020, 11:54:01
du solltest dich mal mit den unterschiedlichen kommunikations verfahren deiner devices beschäftigen.
über get deviceInfo siehst du die vom device unterstützten modes.
ein weiterer cmd (getconfig) verringert keine pending cmds.
im gegenteil, es kommen weitere dazu. ganz ans ende der cmd queue.
eigentlich logisch, oder nicht?
Logisch.
Das Device lief im RFMode Homematic, seit Jahren am Banana mit FW 1.63.
Zitat von: frank am 17 Dezember 2020, 11:54:01
da dein scc wahrscheinlich kein timing beherscht (unpassendes gateway mit schlechter fw), wird die queue, wenn überhaupt, nur häppchenweise, abgearbeitet.
also öfter mal aufs knöpfchen drücken.
Das bekomme ich nicht hintereinander.
Das Timing am Busware Stackable SCC meinst du?
Ich habe in der zwischnezeit, das Timing für den RASPI noch auf eine definierten Wert gesetzt. Kann auch daran liegen, das es jetzt mit der alten config funktioniert.
"core_freq=250" in der /boot/config.txt
Hier könnte ich den Gegenversuch starten, wenn ich das einfach wieder entferne.
Testergebnis: nö, daran lage es nicht. Habe Es gerade entfernt und neu gebootet. Funktioniert noch.
Dann kann es nur die neue Firmware sein.
Bleibt meine Frage, warum ich dann nicht mit der neuen config peeren konnte?
Können wir das nochmal beleuchten?
Zitat von: frank am 17 Dezember 2020, 11:54:01
ps:
es wäre schön, wenn du deine list mit code tags formatieren würdest.
Das versuche ich jetzt.
Danke
Martin
es geht um das timing der bidirektionalen kommunikation, quasi mit "handshake" (ack).
antworten müssen in einem bestimmten "fenster" erfolgen.
homematic io sind "intelligent", da sie viele antworten selber senden. natürlich zum perfekten zeitpunkt.
cul/scc sind "doof", da sie das nicht können.
alle latenzen und verarbeitungszeiten vom empfang am cul bis zum senden der antwort durch den cul haben hier einfluss und sind grösstenteils unbekannt.
manchmal auch viel zu lang. dann schlafen batterie devices gleich wieder ein.
es gibt eine tsculfw von noansi, die einige probleme verbessern kann. ob auch für scc verfügbar weiss ich nicht.
also geduldig bleiben und immer auf cmds_done achten, bevor neue cmds gesendet werden.
edit:
devices löschen und reseten ist natürlich kontraproduktiv, da immer alle daten erneut ausgelesen werden müssen.
Hallo Martin, hallo Frank,
Zitates gibt eine tsculfw von noansi, die einige probleme verbessern kann. ob auch für scc verfügbar weiss ich nicht.
Sie ist für SCC verfügbar. Siehe https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466 (https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466) ff
Gruß, Ansgar.
Hallo zusammen,
vermutlich lag es an der Firmware zusammen mit dem schnellen RPI 4.
Vorher hatte ich Firmware 1.63 mit einem BananaPI 1, da lief es.
Mit RPI 4 und 1.63 lief es nicht so toll.
Jetzt mit RPI4 und 1.67 geht es erstmal.
Ich warte mal was sich so tut und ob ich die andere culfw benötige.
Danke euch
scc verkaufen und einen HM-MOD-RPI-PCB draufstecken.
vom gewinn schön essen gehen, oder gleich einen zweiten als fallback besorgen. ;)
Nun ja,
ich habe noch einen NanoCUL in SlowRF 868 laufen mit FW 1.64.
, das wäre meine nächste Option gewesen.
Irgendwie muss ich mal gucken ob ich die alten Geräte mal unpairen kann und dann wieder einbinden.
Eigentlich nur um zu gucken ob es geht.
Ich habe noch zwei HM BidCos Thermostate rumliegen, mit denen teste ich das Pairing an der VCCU (SCC ist in der Device List).
Keine Ahnung warum, aber heute meldet er sich wieder mit rotem Blinken zurück, schaltet aber trotzdem. Was mache ich denn jetzt?
Ich habe mal ein HMinfo configcheck gemacht.
Sieht nach einer ziemlichen Baustelle aus.
configCheck done:
missing register list
Bad_Hzg_Wand: RegL_00.
Bad_Hzg_Wand_Clima: RegL_01.,RegL_07.
Bad_Hzg_Wand_ClimaTeam: RegL_01.
Bad_Hzg_Wand_Climate: RegL_01.
Bad_Hzg_Wand_Weather: RegL_01.
Bad_Hzg_Wand_WindowRec: RegL_01.
Bad_Hzg_Wand_remote: RegL_01.
CUL_HM_HM_CC_RT_DN_2C949E: RegL_00.
CUL_HM_HM_CC_RT_DN_2C949E_Clima: RegL_01.,RegL_07.
CUL_HM_HM_CC_RT_DN_2C949E_ClimaTeam: RegL_01.
CUL_HM_HM_CC_RT_DN_2C949E_Climate: RegL_01.
CUL_HM_HM_CC_RT_DN_2C949E_Weather: RegL_01.
CUL_HM_HM_CC_RT_DN_2C949E_WindowRec: RegL_01.
CUL_HM_HM_CC_RT_DN_2C949E_remote: RegL_01.
HM_6F08EF: RegL_00.
HM_6F08EF_Btn_01: RegL_01.,RegL_04.peerUnread
HM_6F08EF_Btn_02: RegL_01.
HM_6F08FA: RegL_00.
HM_6F08FA_Btn_01: RegL_01.,RegL_04.peerUnread
HM_6F08FA_Btn_02: RegL_01.
HM_6F0905: RegL_00.
HM_6F0905_Btn_01: RegL_01.,RegL_04.peerUnread
HM_6F0905_Btn_02: RegL_01.
HM_72443F: RegL_00.
HM_72443F_Btn_01: RegL_01.,RegL_04.virtuellerAktorMultitasterKueche_Btn1
HM_72443F_Btn_02: RegL_01.,RegL_04.virtuellerAktorMultitasterKueche_Btn2
HM_72443F_Btn_03: RegL_01.
HM_72443F_Btn_04: RegL_01.
HM_72443F_Btn_05: RegL_01.
HM_72443F_Btn_06: RegL_01.
HzgSZ: RegL_00.
HzgSZ_Clima: RegL_01.,RegL_07.
HzgSZ_ClimaTeam: RegL_01.
HzgSZ_Climate: RegL_01.
HzgSZ_Weather: RegL_01.
HzgSZ_WindowRec: RegL_01.
HzgSZ_remote: RegL_01.
Ritter_Hzg: RegL_00.
Ritter_Hzg_Clima: RegL_01.,RegL_07.
Ritter_Hzg_ClimaTeam: RegL_01.
Ritter_Hzg_Climate: RegL_01.
Ritter_Hzg_Weather: RegL_01.
Ritter_Hzg_WindowRec: RegL_01.
Ritter_Hzg_remote: RegL_01.
hmTasterRitterZimmer: RegL_00.
hmTasterRitterZimmer_Kanal_1: RegL_01.,RegL_04.peerUnread
hmTasterRitterZimmer_Kanal_2: RegL_01.,RegL_04.peerUnread
peer list incomplete. Use getConfig to read it.
incomplete: HM_6F08EF_Btn_01: peerUnread
incomplete: HM_6F08EF_Btn_02:
incomplete: HM_6F08FA_Btn_01: peerUnread
incomplete: HM_6F08FA_Btn_02:
incomplete: HM_6F0905_Btn_01: peerUnread
incomplete: HM_6F0905_Btn_02:
incomplete: hmTasterRitterZimmer_Kanal_1: peerUnread
incomplete: hmTasterRitterZimmer_Kanal_2: peerUnread
peer not verified. Check that peer is set on both sides
HM_72443F_Btn_01: p:virtuellerAktorMultitasterKueche_Btn1
HM_72443F_Btn_02: p:virtuellerAktorMultitasterKueche_Btn2
no IO device assigned
HM_6F08FA:
PairedTo missing/unknown
Bad_Hzg_Wand:
CUL_HM_HM_CC_RT_DN_2C949E:
HM_6F08EF:
HM_6F0905:
HzgSZ:
Ritter_Hzg:
hmTasterRitterZimmer:
PairedTo mismatch to IODev
HM_72443F: paired:0x000000 IO attr: 310575.
Hat wer einen Hinweis für mich, wo ich anfangen kann?
Danke
Martin
Jetzt scheint es gelöst.
Das Homematic Modul hatte wohl einen Bug und zusätzlich hat mein busware scc gezickt.
Habe meinen nano868 zum HomeMatic Device ernannt und den scc zum SlowRF degradiert.
jetzt scheint es zu funktionieren.
Hallo Martin,
es ist wohl nur eine Frage der Zeit, bis Du auch mit dem nano auf Standard Firmware Probleme bekommst.
Im Grunde hast Du nun bezüglich Kommunikation zum CUL nicht wirklich viel verändert, denn auch der nano, obwohl physikalisch via USB an Deinen Pi angeschlossen, ist doch nur via USB nach Seriell Schnittstelle angeschlossen.
Was über die Firmwareversion nun möglicherweise zum Tragen kommt oder auffällt, ist ein früherer Sendeversuchsabbruch bei CCA (check auf Funkstille vor dem Senden), was nach der 1.64 für HM hinzu gekommen ist. Wenn Dein Pi4 zu sehr auf 868.3MHz stört, oder Du am Pi4 eine Störquelle hast (auch schon Schaltnetzteile in der Nähe können ein Problem darstellen), dann kann es sein, dass mit dem SCC deswegen häufiger mal nicht gesendet wurde. Zum Pi4 habe ich dazu keine eigenen Erfahrungwerte.
Da beim nano mit 1.64 Firmware im Gegensatz zur 1.67 Firmware vor dem Senden einer Nachricht "ewig" auf einen freien Kanal gewartet wird, würde ein recht lang "besetzter" Kanal im Watchdog Reset des nano enden (ewig -> ~2s). Und wenn ich das richtig im Kopf habe und nichts daran getan wurde, merkt das Dein FHEM dann gar nicht und Dein nano läuft nach dem Watchdig Reset im SlowRF -> kein HM Empfang mehr. Eventuell leidet der nano nu aber nicht so unter CCA relevanten Funkstörungen wie der SCC auf dem Pi, da weiter entfernt, so dass es erst mal besser zu gehen scheint.
Unabhängig von möglichen Funkstörungen, das Antworttiming passt mit der Standardfirmware häufig nicht, nebst weniger Wiederholung nicht erfolgreich abgesetzter Funktelegramme, so dass eine einigermaßen stabile Kommunikation auch bei besten funktechnischen Bedingungen nicht zu erwarten ist. Das ist wie ein Blinker, Du glaubst erst mal freudig, dass es geht, ... geht doch mal wieder was nicht ...
Franks Rat zum Wechsel auf ein geeigneteres IO zu folgen wird Dir bezüglich Timing und stabilerem Betrieb sicherlich eher helfen.
Mit dem SCC hättest Du zumindest eine der geeignetsten Hardwarebasen im Bezug auf SRAM-Speicher für die tsculfw, ist aber kein standard Weg und auch nicht via FHEM Update versorgt. Wenn der Pi4 den SCC allerdings funktechnisch stört und das auch mit abgesetzter Antenne und Entstörmaßnahmen und/oder Pfostensteckerverlängerung nicht weg zu bekommen ist, wirst Du auch damit nicht glücklich. Zumindest kann man so was mit der tsculfw eher via Logging aufdecken und man kann bei der tsculfw CCA auch konfigurieren entsprechend den Möglichkeiten des Funkchips.
In dem Falle von Funkstörungen durch den Pi4 wäre allerdings auch ein HM-MOD-RPI-PCB zumindest ebenso den Störungen ausgesetzt. Vielleicht vor einem Kauf mal im Forum intensiver stöbern nach Usererfahrungen mit Pi4 und HM-MOD-RPI-PCB.
Gruß, Ansgar.
Hallo Ansgar,
vielen Dank für deine ausführliche Antwort.
Mit den IOs muss ich wirklich mal gucken.
Vermutlich passt der busware CUL wirklich nicht mehr so toll zum RPI 4, wober er auf dem Banana PI eigentlich ganz ok war.
Weil der RPI 4 einen passiven Kühler montiert hat habe ich ein paar Pfostenstecker als Riser dazu gepackt, das kann natürlich auch stören.
Evtl. wäre ein 40 poliges Kabel ganz hilfreich.
Ich muss mal gucken ob ich da nochmal ran will.
Der NanoCul läuft tatsächlich mit der FW 1.66 (sorry wegen 1.64). Gefühlt antwortet er 1a und auch echt flotter als der busware cul.
Der NanoCul steckt an einem USB-Hub mit einem extra Kabel (vom Hub zum NanoCul).
Er empfängt auch eine Menge Daten (vermutlich von noch nicht wieder gepairten Devices), aber er meckert keine CCA Errors an.
Deinen Hinweis mit dem Loop werde ich auf jeden Fall im Auge behalten.
Vielleicht ist es eine gute Idee sich einen HM-MOD-RPI-PCB auf Halde zu legen.
Die tsculfw gucke ich mir nochmal an. Schön wäre es ja wirklich, wenn ich zwei HomeMatic CULs in der VCCU hätte die funktionieren.
Das die nicht standardmäßig aktualisiert wird im FHEM ist für mich kein Show stopper.
Den SlowRF brauche ich tatsächlich nur für ein Rollo.
Ich werde zunächst mal versuchen die HomeMatic Help Me's im Log zu identifizieren und zu eliminieren.
Beste Grüße
Martin