(gelöst) Peering von 6-Wach Taster an RPI4 mit Busware SCC will nicht ganz

[betonkelle]

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

Code Auswählen Erweitern


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

[betonkelle]

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

[betonkelle]

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

[frank]

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.

[frank]

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.

[betonkelle]

Hallo Frank,

und Danke für deine Antwort.

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.

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?

ps:
es wäre schön, wenn du deine list mit code tags formatieren würdest.

Das versuche ich jetzt.

Danke
Martin

[frank]

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.

[noansi]

Hallo Martin, hallo Frank,

es 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 ff

Gruß, Ansgar.

[betonkelle]

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

[frank]

scc verkaufen und einen HM-MOD-RPI-PCB draufstecken.
vom gewinn schön essen gehen, oder gleich einen zweiten als fallback besorgen. 

[betonkelle]

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).

[betonkelle]

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.

Code Auswählen Erweitern

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

[betonkelle]

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.

[noansi]

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.

[betonkelle]

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