Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[frank]

lang, lang, lang ist es her...
ich versuchs mal.

config short blitzt und macht nix.
du hast nicht lang genug gedrückt, wenn es blitzt.
pairforsec solte funktionieren.

die pm datei installiert?
hast du den namen der pm datei geändert? "HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm", dann restart, dass cul_hm sie einliesst.

[Pfriemler]

Richtig - "HM_Config_" hat erst nicht funktioniert, mit "HMConfig_" dann - siehe Logauszug aus meinem Post!
Ich habe mal sehr viel länger gedrückt, da kamen dann ein paar kurze Blitze hintereinander. Den üblichen 5+5-Sekunden-Rhythmus gibt es jedenfalls nicht (ebenso wie den 0,4s-Long-Rhythmus, das kommt deutlich seltener).
Ich versuche es nochmal mit länger, aber nicht mehr heute... Edith ergänzt das morgen.

[frank]

bei 1. config long kommt nix.
wenn es mehrfach blitzt, war es reset, also das 2. long nacheinander.
um den reset zu vermeiden, habe ich immer mal ein short eingeworfen.

ca seite 75 hatte ich mal ein bessere routine für den taster gepostet.

[frank]

sicher, dass die pm datei richtig ist?

[Pfriemler]

sicher, dass die pm datei richtig ist?

Also ich habe alles aus dem gleichen Repo von "Verkehrsrot" gezogen - siehe hier im Feb 2020. Die .pm hat drei Routinen
Asksin_HM_LC_Sw1PBU_FM_CustomFW_Initialize
registerHM_LC_Sw1PBU_FM_CustomFW()
CUL_HM_ParseremoteAndSwitch

Code Auswählen Erweitern

InternalTimer(gettimeofday()+10,"registerHM_LC_Sw1PBU_FM_CustomFW","nothing", 0);
interpretiere ich in meiner perlerischen Einfalt so, dass 10s nach dem Laden der .pm die Routine aufgerufen wird, die die modelID "F0A9" dem System bekannt macht.

Code Auswählen Erweitern

registerHM_LC_Sw1PBU_FM_CustomFW()
{
  {$HMConfig::culHmModel{"F0A9"} = {name=>"HM-LC-Sw1PBU-FM-CustomFW",st=>'remoteAndSwitch',cyc=>'',rxt=>'',lst=>'1,3:3p.4p,4:1p.2p',chn=>"Btn:1:2,Sw:3:4"}}
  {$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW00"}{fwUpdate} ="<filename>"};
  {$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW01"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
  {$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW02"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
  {$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW03"} = $HMConfig::culHmSubTypeSets{"switch"}};
  {$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW04"} = $HMConfig::culHmSubTypeSets{"switch"}};
  {$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW01"}  = $HMConfig::culHmRegType{remote}};
  {$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW02"}  = $HMConfig::culHmRegType{remote}};
  {$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW03"}  = $HMConfig::culHmRegType{switch}};
  {$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW04"}  = $HMConfig::culHmRegType{switch}};
  #Log(1, "Registered F0A9");
}

Wenn ich sie händisch aufrufe, bekomme ich einen Hashwert als Rückgabe (mit dem ich nichts anfangen kann).

Immerhin: Wenn es mir gelingt, pairing und power on so zu kombinieren, dass ein Gerät angelegt wird, bekommt es ja die .mID F0A9 und auch die korrekte model-Bezeichnung zugewiesen ("HM-LC-Sw1PBU-FM-CustomFW". Das Gerät wird also zumindest teilweise bereits "verarbeitet". Aber es werden keine Kanäle definiert, obwohl dank der o.g. Routine FHEM eigentlich alles bekannt sein müsste.
Fehlermeldungen im Log gibt es auch keine.
Der Abstand zum HMUMART ist 2m, das Device kommt also recht "laut" herein. Das sollte sich aber auf die Kommunikation auswirken, nicht jedoch auf den Mechanismus, mit dem FHEM das Gerät und die Kanäle anlegt.

Ich habe eben nochmal mit dem Device gespielt: Also dem Configbutton kann ich überhaupt keine vernünftige Reaktion entlocken außer dem Reset nach 10s. Wärhend vccu hmPairForSec 60 lief, hat das Gerät nicht auf den Config-Tastendruck, sondern auf einen normalen Buttondruck hin eine DEVINFO gesendet, woraufhin FHEM dieses Gerät angelegt hat. So eine Reaktion hätte ich bei einem Sensor im Zusammenhang mit einem WAKEUP vermutet, aber die Reaktion von VCCU wurde nicht aufgezeichnet. Warum also hier die DEVINFO kam ...?

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        29F2CA
...
   HMUART_RSSI -32
...
   HMWLAN1_RSSI -42
   HMWLAN1_TIME 2020-06-07 12:27:42
   IODev      HMUART
   LASTInputDev HMWLAN1
   MSGCNT     24
   NAME       HM_29F2CA
   NOTIFYDEV  global
   NR         22782
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:0A - t:40 s:29F2CA d:000000 0206
   protCmdPend 3 CMDs_pending
   protLastRcv 2020-06-07 12:27:41
   protRcv    5 last_at:2020-06-07 12:27:41
   protState  CMDs_pending
   rssi_at_HMUART cnt:13 min:-37 max:-31 avg:-33.3 lst:-32
   rssi_at_HMWLAN1 cnt:12 min:-46 max:-36 avg:-41 lst:-42
   .attraggr:
   .attrminint:
   READINGS:
     2020-06-07 12:23:16   .D-devInfo      410100
     2020-06-07 12:23:16   .D-stc          10
     2020-06-07 12:27:41   .protLastRcv    2020-06-07 12:27:41
     2020-06-07 12:23:16   D-firmware      1.7
     2020-06-07 12:23:16   D-serialNr      LEQ0234206
     2020-06-07 12:23:16   R-pairCentral   set_0x1411AB
     2020-06-07 12:27:41   trigDst_broadcast noConfig
     2020-06-07 12:27:41   trigger         Short_6
     2020-06-07 12:27:41   trigger_cnt     6
   cmdStack:
     ++A0011411AB29F2CA00050000000000
     ++A0011411AB29F2CA000802010A140B110CAB
     ++A0011411AB29F2CA0006
   helper:
     BNO        6
     BNOCNT     1
     HM_CMDNR   10
     mId        0000
     peerFriend
     peerOpt    -:-
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1591525663.15899
       prefIO     
       vccu       
     mRssi:
       mNo        0A
       io:
         HMUART:
           -24
           -24
         HMWLAN1:
           -42
           -42
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_HMUART:
         avg        -33.3076923076923
         cnt        13
         lst        -32
         max        -31
         min        -37
       at_HMWLAN1:
         avg        -41
         cnt        12
         lst        -42
         max        -36
         min        -46
     shadowReg:
       RegL_00.    02:01 0A:14 0B:11 0C:AB
     tmpl:
Attributes:
   .mId       F0A9
   IODev      HMUART
   IOgrp      vccu:HMUART
   model      HM-LC-Sw1PBU-FM-CustomFW
   room       autocreated
   subType    virtual

Man sieht: .mID und model wurden korrekt gesetzt. DEF und serialNr stimmen auch.
Aus dem allem schließe ich, dass das geflashte Device immerhin korrekt zu arbeiten scheint.

Mit stillgelegtem HMUART wird es nicht anders. Aktuell gelingt es mir wieder nicht, irgendein Pairing anzustoßen.

P.S.: Die Probleme sehen doch genauso aus wie hier:
https://forum.fhem.de/index.php/topic,18071.msg880849.html#msg880849

Bin da auch noch über eine seltsame Differenz gestolpert: In einer HMConfig... stehen die Routinen, die die oben zitierte Routine ausführt, direkt (also als main) zur Ausführung. Lauftechnisch dürfte das doch egal sein, wenn sie über eine 99_xxx zeitverzögert als SUB abgehandelt werden? oder ist es sinnvoller, dass CUL_HM diese Defs "am Stück" einarbeitet"?
Es ist doch so, dass eine 99_ .*.pm in jedem Fall abgearbeitet wird, eine HMConfig.*.pm von CUL_HM - und eine "HM_Config" gar nicht - oder doch, weil mit HM beginnt?

edit: nä. Tatsächlich wird beim Start neben "HMConfig.pm" auch jede vorhandene "HMConfig_xxx.pm" abgearbeitet, nicht aber z.B. eine "HMConfig (alte version).pm".
Davon habe ich nämlich tatsächlich ein paar alte im FHEM stehen und die haben noch nie Probleme gemacht...
Jede hinzugefügte HMConfig_xxx.pm kann man an einem entsprechenden Eintrag im Log sehen.

Egal ob so oder so - am Inhalt "meiner" .pm und der aus "99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm" aus https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/blob/master/fhem/99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm unterscheidet sich nichts - Habe die .pm aus einer anderen Quelle nochmal geladen und finde keine Unterschiede - außer dass meine bisherige CR+LF als Zeilenende hatte, was aber für FHEM kein Problem darstellen sollte...?

[frank]

attr subType muss "remoteAndSwitch" sein.

in der geposteten funktion aus der pm datei fehlt ein semicolon am ende der ersten zeile denke ich.

[Pfriemler]

Habe meinen Post gerade noch ergänzt, guckst Du am Ende bitte nochmal?

wie ich schon sagte: subType kann ich nicht (mehr) manuell setzen seit Martins Umstrickereien mit .mID etc. ... Und in modelForce wird der CustomFW-Typ nicht angeboten.

Inzwischen kriege ich das Scheißding überhaupt nicht mehr zum Konfigurieren, egal was ich aufrufe.

Vielleicht sollte ich mir von jemandem einfach eine funktionierende Konfig eines switches mal schicken lassen und ausnahmsweise mal direkt in die fhem.cfg reinpfriemeln.

Achso: FHEM kennt den Typ prinzipiell, die Initialisierung ist da - aktuell über die 99_...

Code Auswählen Erweitern

remoteAndSwitch  HM-LC-Sw1PBU-FM-CustomFW F0A9 normal                         1,3.4p,1p.2p 1-2 Btn, 3-4 Sw,

edit: das Semikolon fehlt in allen mir bekannten Quellen.

edit2: Irgendwie habe ich es geschafft, dass das Ding autocreated wurde nach hmPairForSec und einem Einstromen und Button drücken.
die .mID ist 0
modelForce bietet das Modell nicht an, aber man kann es händisch auf der Zeile setzen: "attr HM_29FAC2 modelForce HM-LC-Sw1PBU-FM-CustomFW"
Und siehe da:
Es hat vier Kanäle, trennt die Button-Events. Jetzt fehlt nur noch das Pairing...

Der halbangelegte Dummy hatte zudem auch kein IODev und kein IOgrp. Dies nachgetragen ... und schwupps, der Aktor lässt sich schalten. Das Pairing wurde durchgeführt.
getConfig arbeitet auch ab bis CMDs_done - aber ich bekomme keine Register für das Device geliefert. Da ist noch der Wurm drin...
in den Kanälen funktioniert es.
Jetzt arbeite ich mich in das Peering ein. Da passiert aber noch ganz erschreckend viel Kleinholz. Besonders ein peerChan dual auf den Kanal 3 (phys. Relais) (Originalverhalten) peert zwar beide Buttons, setzt aber alle Aktionen von self01 auf "no" die CtValxx auf 0.
Was würde ich bloß ohne hm.js machen

[frank]

anbei mal meine pm datei.

der vorgang des ladens dieser externen config dateien hat sich irgendwann in cul_hm geändert. daraufhin habe ich den namen angepasst und den inhalt geändert, denke ich.


aber auch ich habe gerade festgestellt, dass subtype und model nun in keiner auswahlliste mehr auftauchen, wenn für die devices eine eigene pm datei existiert. auch bei einem universalsensor.
das ist sicher seit modelforce der fall.
sieht also nach weiteren anpassungen aus.

trotzdem kann ich meinen switch und sensor konfigurieren, und templates habe ich letztens auch erfolgreich mit dem regtool bei beiden gesetzt.
auch peeren hat letzte woche noch beim switch funktioniert.


schreib mal subtype, model und co direkt in die fhem.cfg.
und lösche dieses modelforce.

Code Auswählen Erweitern

Internals:
   DEF        266EA5
   FUUID      5c4ce2ea-f33f-09c4-522e-5f67979f1d577b95
   IODev      hmlan1
   LASTInputDev hmlan1
   MSGCNT     17286
   NAME       SwitchPBU01
   NOTIFYDEV  global
   NR         359
   NTFY_ORDER 50-SwitchPBU01
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 SwitchPBU01_Btn_01
   channel_02 SwitchPBU01_Btn_02
   channel_03 SwitchPBU01_Sw_01
   channel_04 SwitchPBU01_Sw_02
   cul868_MSGCNT 8704
   cul868_RAWMSG A1486805E266EA51ACE1F0000000000000003000000::-43.5:cul868
   cul868_RSSI -43.5
   cul868_TIME 2020-06-07 15:38:06
   hmlan1_MSGCNT 8582
   hmlan1_RAWMSG E266EA5,0000,100F162E,FF,FFC1,86805E266EA51ACE1F0000000000000003000000
   hmlan1_RSSI -63
   hmlan1_TIME 2020-06-07 15:38:06
   lastMsg    No:86 - t:5E s:266EA5 d:1ACE1F 0000000000000003000000
   protCmdDel 45
   protLastRcv 2020-06-07 15:38:06
   protRcv    8728 last_at:2020-06-07 15:38:06
   protResnd  418 last_at:2020-06-07 15:11:38
   protResndFail 43 last_at:2020-06-07 14:11:01
   protSnd    180 last_at:2020-06-07 15:11:23
   protState  CMDs_done
   rssi_at_cul868 cnt:8704 min:-62 max:-40.5 avg:-44.4 lst:-43.5
   rssi_at_hmlan1 cnt:8582 min:-86 max:-48 avg:-63.85 lst:-63
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     1900-01-01 00:00:01   .D-devInfo      410100
     1900-01-01 00:00:01   .D-stc          10
     2020-06-07 15:38:06   .protLastRcv    2020-06-07 15:38:06
     2020-06-06 08:29:02   Activity        alive
     2020-06-01 11:15:02   CommandAccepted yes
     from archivexx        D-firmware      1.0
     from archivexx        D-serialNr      KEQ1110003
     2019-11-14 11:12:44   PairedTo        0x1ACE1F
     2019-10-22 15:08:46   R-pairCentral   0x1ACE1F
     2019-11-14 11:12:43   RegL_00.        00:00 02:00 05:00 0A:1A 0B:CE 0C:1F 12:00
     2020-06-01 23:29:39   battery         ok
     2020-06-07 15:11:42   commState       CMDs_done
     2020-06-07 15:11:42   state           CMDs_done
   helper:
     HM_CMDNR   134
     cSnd       011ACE1F266EA5030E,011ACE1F266EA5040E
     mId        F0A9
     peerFriend
     peerOpt    -:remoteAndSwitch
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     tmplChg    0
     cmds:
       TmplKey    :1591370244.2392:1591370250.55269
       TmplTs     1591370250.55269
       cmdKey     :0:1:0::F0A9:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         fwUpdate:<filename>
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         tplDel:tmplt
         unpair:
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +266EA5,00,00,00
       nextSend   1591537086.44967
       rxt        0
       vccu       ccu
       p:
         266EA5
         00
         00
         00
       prefIO:
         hmlan1
     mRssi:
       mNo        86
       io:
         cul868:
           -43.5
           -43.5
         hmlan1:
           -59
           -59
         hmuart1:
         hmusb1:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_cul868:
         avg        -44.4044117647059
         cnt        8704
         lst        -43.5
         max        -40.5
         min        -62
       at_hmlan1:
         avg        -63.8502680027966
         cnt        8582
         lst        -63
         max        -48
         min        -86
     shadowReg:
     tmpl:
Attributes:
   .mId       F0A9
   IODev      hmuart1
   IOgrp      ccu:hmlan1
   actCycle   000:10
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading .*
   expert     251_anything
   firmware   1.0
   group      Beleuchtung
   model      HM-LC-Sw1PBU-FM-CustomFW
   room       10_WZ
   serialNr   KEQ1110003
   subType    remoteAndSwitch
   webCmd     getConfig:clear msgEvents

[Pfriemler]

Danke für die .pm. Ich hatte den Mechanismus gerade selbst erfolgreich so umgebaut (also die sub zur Initialisierung weg und die #define direkt rein, mit dem ; am ersten Zeilenende.
Unsere beiden Versionen sind soweit identisch.
Habe fhem.cfg angepasst und neu gestartet. Jetzt sieht es "ordentlich" aus.

a) getConfig auf das Device funktioniert noch immer nicht. Ich bekomme keine aktualisierten readings.
Auch pairedTo wird regelmäßig als 0x00000 gemeldet - obwoh die Telegramme vom Aktor eindeutig an die Zentrale gehen und er sich auch steuern lässt.

b) Das Ding hat bei manchen speziellen Registeränderungen das gesamte Peering vergessen, ich musste es neu machen. Dabei führt "peerChan dual" vom Btn1 auf den Sw1 reproduzierbar zu einem stillgelegten Btn1 (alle SwJt "no", alle Val "0", actions "off"). Man kommt schneller zum Ziel, wenn man beide Buttons mit peerSmart koppelt und dann nur noch die jmpTable ändert auf dual-Betrieb.

c) gepeerte Buttons senden keine Message mehr an die Zentrale, es folgt nur die Rückmeldung des Aktorstatus. Das entspricht dem Originalverhalten, war aber nicht Sinn der ganzen Aktion. Es wird zwaar ein Funkprotokoll gesendet (was der AskSinAnalyzer auch zeigt (29F2CA an 29F2CA), aber das erzeugt (logischerweise) kein Event in FHEM.
Erst wenn man die beiden Buttons zusätzlich mit einem virtuellen Button bspw. der VCCU peert, gibt es auch wieder korrekte Trigger an FHEM. Allerdings - und das ist die nächste Sch..e: Die Liste wird sortiert abgearbeitet, vermute ich mal. So liegt 1411AB der Zentrale vor 29F2CA des Aktors. Das Gerät sendet nun also zuerst an FHEM und dann erst an den internen Switch. Der ohnehin schon höhere Lag der lokalen Schaltaktion wird noch größer. Da kann ich eigentlich auch gleich auf das Peering verzichten.

d) Die Rückmeldung des Aktorstatus ist nach dem Peeren fehlerhaft. Wenn ich den Aktor aus FHEM ein- und ausschalte, gibt es eine prompte Reaktion und korrekte Rückmeldung.
Bei einer lokalen Schaltaktion wird aber offenbar nicht der Status nach, sondern VOR Vollzug der Aktion gemeldet.
Schalte ich den Sw1 aber nun am lokalen self02 ein, zieht zwar das Relais an, aber in FHEM bleibt der Aktor aus.
Drückt man den Button ein zweites Mal, bleibt das Relais an, aber der Status in FHEM wird korrekt.
Gleiches beim Ausschalten: Einmal drücken = physisch aus, in FHEM noch an - erst zweites Drücken = korrekt.

Code Auswählen Erweitern

2020.06.07 17:27:40 1: **************************** HM-Logging für HM_29F2CA gestartet
2020.06.07 17:27:40 1: HM_29F2CA  model     HM-LC-Sw1PBU-FM-CustomFW
2020.06.07 17:27:40 1: HM_29F2CA  firmware  1.7
2020.06.07 17:27:40 1: HM_29F2CA  serialNr  LEQ0234206
2020.06.07 17:27:51.828 0: HMUARTLGW HMWLAN1 recv: 01 05 00 00 25 msg: 4C B0 40 29F2CA 1411AB 0210
2020.06.07 17:27:51.840 0: HMUARTLGW HMWLAN1 send: 01 0629F2CA010000
2020.06.07 17:27:52.025 0: HMUARTLGW HMWLAN1 added peer: 29F2CA, aesChannels: FFFFFFFFFFFFFFFF
2020.06.07 17:27:52.029 0: HMUARTLGW HMWLAN1 send: 01 0629F2CA010000
2020.06.07 17:27:52.088 0: HMUARTLGW HMWLAN1 added peer: 29F2CA, aesChannels: FFFFFFFFFFFFFFFF
2020.06.07 17:27:52.885 0: HMUARTLGW HMWLAN1 recv: 01 05 01 00 26 msg: 4C B0 40 29F2CA 1411AB 0210
2020.06.07 17:27:53.596 0: HMUARTLGW HMWLAN1 recv: 01 05 00 00 26 msg: 4D 80 02 29F2CA 29F2CA 0103004000
2020.06.07 17:28:04.306 0: HMUARTLGW HMWLAN1 recv: 01 05 01 00 26 msg: 4E B0 40 29F2CA 1411AB 0211
2020.06.07 17:28:04.908 0: HMUARTLGW HMWLAN1 recv: 01 05 00 00 26 msg: 4F 80 02 29F2CA 29F2CA 0103C80000
2020.06.07 17:28:23.182 0: HMUARTLGW HMWLAN1 recv: 01 05 01 00 25 msg: 50 B0 40 29F2CA 1411AB 0119
2020.06.07 17:28:23.387 0: HMUARTLGW HMWLAN1 recv: 01 05 00 00 26 msg: 51 80 02 29F2CA 29F2CA 0103C84000
2020.06.07 17:28:31.505 0: HMUARTLGW HMWLAN1 recv: 01 05 01 00 25 msg: 52 B0 40 29F2CA 1411AB 011A
2020.06.07 17:28:32.221 0: HMUARTLGW HMWLAN1 recv: 01 05 00 00 25 msg: 53 80 02 29F2CA 29F2CA 0103000000
2020.06.07 17:28:38 1: **************************** HM-Logging beendet

Folglich ist der Status auch beim direkten Schalten falsch:
Alles aus: ein lokaler Druck auf self02: Licht geht an, FHEM zeigt "aus". Ein lokaler Druck auf self01: Licht geht aus, FHEM zeigt "an".

Und bevor die Frage kommt: Ja, die Lampe hängt an Ausgang 2 und leuchtet bei angesteuertem Relais.
Schalte ich per FHEM direkt, kommt die Rückmeldung richtig:

Code Auswählen Erweitern

2020.06.07 18:06:21 1: **************************** HM-Logging für HM_29F2CA gestartet
2020.06.07 18:06:21 1: HM_29F2CA  model     HM-LC-Sw1PBU-FM-CustomFW
2020.06.07 18:06:21 1: HM_29F2CA  firmware  1.7
2020.06.07 18:06:21 1: HM_29F2CA  serialNr  LEQ0234206
2020.06.07 18:06:26.303 0: HMUARTLGW HMWLAN1 send: 01 02 00 00 00 msg: 6C A0 11 1411AB 29F2CA 0203C80000
2020.06.07 18:06:26.414 0: HMUARTLGW HMWLAN1 recv: 01 04 03 00 27 msg: 6C 80 02 29F2CA 1411AB 0103C80000
2020.06.07 18:06:32.056 0: HMUARTLGW HMWLAN1 send: 01 02 00 00 00 msg: 6D A0 11 1411AB 29F2CA 0203000000
2020.06.07 18:06:32.304 0: HMUARTLGW HMWLAN1 recv: 01 04 03 00 26 msg: 6D 80 02 29F2CA 1411AB 0103000000
2020.06.07 18:06:47 1: **************************** HM-Logging beendet




Sw2, so hatte ich verstanden, zieht intern dem tatsächlichen Stromfluss nach. Default ist dem Ding aber sogar eine 75-W-Birne zu wenig dazu. Da tut sich nichts.
Aber dafür gibt es eine Schwelle in der Firmware, die muss ich dann mal tunen.
Warum man den aus FHEM direkt schalten kann, entzieht sich komplett meinem Verständnis.
Habe verstanden: mit Sw_01 schaltet man das Gerät direkt, mit Sw_02 bestimmt man, ob der Verbraucher an sein soll - wichtig für Wechselschaltungen mit dem Relais.
Aber trotzdem: Wenn man über Sw_02 ein- und ausschaltet, sollte doch ein aktualisierter Relaisstatus (in Sw_01) zu sehen sein. Hier wird der Status des Relais, also Sw_01, in keinster Weise geändert.
Schalte ich also den Aktor über Sw2 ein und am lokalen Button self01 aus, sind anschließend BEIDE Sw in FHEM "an".

Das ist doch komplett unbrauchbar so...

edit:
Und schon wieder: "set HM_29F2CA_Sw_01 pressS self01" -> keine Reaktion, alles tot.
Nach kurzen "Stromausfall": Alle peerings weg.
Ich geb's auf mit dem Peeren. Dann geht's eben über FHEM und Notify.

edit2:
Die "Stromschwelle" ist doch, wenn ich das richtig gesehen habe, "const unsigned long minImpulsLength = 500;" in der .ino (bzw. der äquivalenten .cpp bei platformio).

Den Stromsensor habe ich jeweils auf 500 gestellt. Damit decke ich bei mir von einer 3W LED bis zu einer 60W Lampe den Bereich zuverlässig ab.

Wird hier komplett ignoriert.
Nein, wird nicht! Testweise die Lampe an 1 angeschlossen - leuchtet beim Einstromen auf - und wird über Sw_02 sauber ein- und ausgeschaltet.
Es scheint mir eher so, dass beim Schalten von Sw_02 zunächst kurz geprüft wird, ob schon ein Strom fließt (oder keiner mehr), nur wenn das Ergebnis nicht dem Wunsch entspricht, wird das Relais gekippt...
Allerdings sehe ich von der definierten 20-sekündlichen Überprüfung des Status hier leider gar nichts.
Habe das gerade im Test in einer Wechselschaltung laufen, der Status ändert sich nicht.

[frank]

hast du chn2 mit chn3 gepeert?

das ist jedenfalls mein peering zum schalten des eigenen aktors mit toggle auf short.

an meinem aktor hängt ein klassischer wechselschalter. diese wechselschaltung schaltet eine lampe.
damals bei inbetriebnahme 60W glühbirne, irgendwann 12W energiesparlampe und jetzt vermutlich 8W led.
chn4 zeigt current: 275-457 bei on und 3 bei off (ich sehe gerade das steigt je länger die led leuchtet).
strom messages alle 20s bei on und off.
abhängig vom leuchtmittel gab es immer entsprechende stromwerte.

status chn3 zeigt immer korrekt das relais an, egal ob per button oder per fhem. jeder short toggelt sauber.

mit wechselschalter muss man für den lampenstatus den strom chn4 nutzen.
seit längerem wird hier unreachable im state gezeigt, was auch alle 30min einen automatischen statusrequest erzeugt.
früher war das mal anders. ob korrekt ist die frage.

zusätzlich ist an chn2 ein virtueller aktor gepeert, um mit long im notfall die rauchmelder auszuschalten.
ich weiss gar nicht ob der für die rm nötig war. vielleicht anfänglich nur zum testen eines virtuellen aktors, da diese buttons meine einzigen peerbaren homematic buttons sind.

chn1 habe ich mit einem dimmer gepeert: short für toggle und long mit toggledim.

alles läuft vielleicht 4 jahre unauffällig und zuverlässig, keine peers oder einstellungen verloren.

messages vom button müsste ich erst schauen.

jetzt habe ich doch noch was kurioses entdeckt:
1. relais und wz.lampe sind aus, strom ~ 0.
2. wz.lampe am wechselschalter eingeschaltet, strom 300, relais aus.
3. jetzt wz.lampe am aktor ausgeschaltet, relais an und strom bleibt bei über 300.

ich bin gerade total verwirrt. 

[Pfriemler]

hast du chn2 mit chn3 gepeert?

Jein. Mein gewünschtes Setup ist eigentlich eine normale Schaltung mit short up/down zum Schalten einer Raumlampe, zusätzlich brauche ich eigentlich nur ein long auf up, um den Rolladen im Zimmer morgens herauffahren zu können. Ich könnte diese Aufgabe sogar mit einem Werksaktor machen nach der bekannten und üblichen Methode: Die Beleuchtung auf long up für 1 Minute einzuschalten würde reichen - timedOn = running als Auslösebedingung triggert ein notify, das den Rolladen öffnet, fertich ist die Laube.
Eine Wechselschaltung ist nicht nötig, also direkte Steuerung über ch3 = Sw_01.
Also war das erste Setup das dual peeren der beiden Buttons. Habe ich hinbekommen.
Wenn man die Sachen schon trennen kann, dann war das Begrenzen des Schaltens auf short und die ausschließliche Steuerung des Rollades mit long das Mittel der Wahl. Beim Setzen von lgActionType auf "off" ist der Aktor 2x abgeschmiert, wie auch beim "pressS self01".
Eine weitere Option war das Überwachen der Stromaufnahme: Verwendet wird eine schaltdimmbare E27-LED, die nach Aus immer mit 100% startet und mit kurzen Unterbrechungen auf auf 50% bzw. 10% dimmt. Über die Stromaufnahme hätte FHEM ein Indiz dafür, welche Dimmstufe gerade aktiv ist, und könnte andere Dimmstufen mit entsprechenden Schaltaktionen gezielt ansteuern.

status chn3 zeigt immer korrekt das relais an, egal ob per button oder per fhem. jeder short toggelt sauber.

So hätte ich das auch gern.

seit längerem wird hier unreachable im state gezeigt,

das wollte ich auch noch anmerken (bei mir in in chn3 und chn4). Ist die nächste unschöne Sache.

Mir fehlen noch immer sämtliche speziellen Readings des Devices (confBtnTime, intKeyVisib (sind zumindest im Sketch definiert), sowie current im chn4), kenne ich nur vom "Hörensagen".
Ob die Firmware nur halbkomplett ist? Du hast FW 1.0, ich 1.7 gemeldet. Die Anpassungen von Verkehrsrot (Arduino -> platformio) belaufen sich neben der anderen Namensgebung auf diverse Umsortierungen und Kommentareinfügungen und abgeänderte Compilerbefehle, funktionale Abweichungen habe ich bisher absolut keine gefunden. Die .ino kriege ich auf meinem PC wegen diverser ungelöster Bibliotheksabhängigkeiten mit anderen Projekten von mir ums Verrecken nicht compiliert, insofern bin ich froh, mit VisualStudio und dem platformio-Plugin überhaupt endlich eine funktionierende Lösung gefunden zu haben.

Die Herkunft der Steuerplatine ist zudem unklar, keine Neuware. Es könnte sich also auch um einen Defekt auf dem Board handeln. Ich hatte die Platine außer zum Testen nicht länger im Einsatz. Jetzt sitzt sie auf einem reparierten Powerboard (noch ohne den 8,2V-Hack, ich muss erst welche bestellen, vorher komme ich auch bei den Dim1TPBU nicht weiter) mit nicht deaktivierter Stromsensor-Hardware. Und wie gesagt: Ich habe die Platine gestern zweimal geflasht (1x mit eingetragener "CCU-ID", einmal "000000", beide Male lieferte das Board anfangs sehr regelmäßige Powerevents, die vielleicht auch ein Störfaktor bei den gestrigen Pairversuchen gewesen sein könnten.

Schlau werde ich auch nicht aus der Configbutton-Auswertung. Laut Quellcode bleibt ein kurzes Drücken bis auf einen kurzen LED-Blitzer funktionslos,
was ist mit "time out for a double long" gemeint (was das Pairing auslösen soll) - ein sehr langer Tastendruck führt hingegen sicher zum Reset des Aktors wie Du beschreibst (das 3x kurze Blinken kommt aus HM::reset in der AskSin.cpp). Anscheinend prellt der Config-Taster ohne dass ich es merke.

Zum Schluss noch ein Sniff vom getConfig auf den chn4. Ich bin da völlig überfragt, was da in den Registern mitkommt. Das muss ja auch zu der Registerdefinition passen. Vielleicht ist das Parsen der betreffenden Message in meiner .pm gar nicht definiert. Allerdings hast Du ja praktisch die gleiche.
current wird nur durch das zyklische PowerEvent aktualisiert. Dass dieses bei mir komplett ausbleibt, ist auch der Grund, warum chn4 bei mir nicht nach Stromfluss aktualisiert.

Noch überwiegt die Neugier über den Frust.

Code Auswählen Erweitern


2020.06.07 20:03:23 1: **************************** HM-Logging für HM_29F2CA gestartet
2020.06.07 20:03:23 1: HM_29F2CA  model     HM-LC-Sw1PBU-FM-CustomFW
2020.06.07 20:03:23 1: HM_29F2CA  firmware  1.7
2020.06.07 20:03:23 1: HM_29F2CA  serialNr  LEQ0234206
2020.06.07 20:03:52.797 0: HMUARTLGW HMUART send: 01 0729F2CA
2020.06.07 20:03:52.817 0: HMUARTLGW HMUART remove peer: 29F2CA
2020.06.07 20:04:07.970 0: HMUARTLGW HMUART send: 01 0629F2CA010000
2020.06.07 20:04:07.979 0: HMUARTLGW HMUART added peer: 29F2CA, aesChannels: FFFFFFFFFFFFFFFF
2020.06.07 20:04:07.984 0: HMUARTLGW HMUART send: 01 0629F2CA010000
2020.06.07 20:04:07.991 0: HMUARTLGW HMUART added peer: 29F2CA, aesChannels: FFFFFFFFFFFFFFFF
2020.06.07 20:04:07.993 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 5C A0 01 1411AB 29F2CA 04040000000001
2020.06.07 20:04:08.270 0: HMUARTLGW HMUART recv: 01 05 01 00 2D msg: 5C A0 10 29F2CA 1411AB 0282008300840085008600870088008900
2020.06.07 20:04:08.753 0: HMUARTLGW HMUART recv: 01 05 01 00 2D msg: 5D A0 10 29F2CA 1411AB 028A008B008C000000
2020.06.07 20:04:09.053 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 5E A0 01 1411AB 29F2CA 0403
2020.06.07 20:04:09.460 0: HMUARTLGW HMUART recv: 01 05 01 00 2D msg: 5E A0 10 29F2CA 1411AB 0100000000
2020.06.07 20:04:09.757 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 5F A0 01 1411AB 29F2CA 04040000000001
2020.06.07 20:04:10.173 0: HMUARTLGW HMUART recv: 01 05 01 00 2D msg: 5F A0 10 29F2CA 1411AB 0282008300840085008600870088008900
2020.06.07 20:04:11.452 0: HMUARTLGW HMUART recv: 01 05 01 00 2B msg: 5F A0 10 29F2CA 1411AB 0282008300840085008600870088008900
2020.06.07 20:04:11.559 0: HMUARTLGW HMUART recv: 01 05 01 00 2C msg: 60 A0 10 29F2CA 1411AB 028A008B008C000000
2020.06.07 20:04:11.856 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 61 A0 01 1411AB 29F2CA 0403
2020.06.07 20:04:12.264 0: HMUARTLGW HMUART recv: 01 05 01 00 2B msg: 61 A0 10 29F2CA 1411AB 0100000000
2020.06.07 20:04:25 1: **************************** HM-Logging beendet


[frank]

hast du eventuell in den 4 channeln noch nicht das passende attr model gesetzt?

[Pfriemler]

hast du eventuell in den 4 channeln noch nicht das passende attr model gesetzt?

Aber ja, das hat modelForce schon korrekt gesetzt. Musste nur .mId auf 50A9 setzen, modelForce löschen und in den Kanälen noch attr expert nachtragen.
Also im Aktor läuft noch was unrund.
Erstens die Sache mit dem Unreachable: ein manuelles getConfig läuft trotz extremer Nähe zum HMUART >95% mit CMDs_done durch. Nach welchen Kriterien CUL_HM die beiden Aktorkanäle "unreachable" betrachtet, habe ich noch nicht begriffen - Fakt ist, dass Schaltanforderungen aus FHEM immer und sofort bedient werden. Der Aktor ist also tatsächlich immer erreichbar.
Zweitens: Die Stromerkennung funktioniert prinzipiell, denn chn4 hier im Testsetup mit manuellem Wechselschalter schaltet immer zuverlässig korrekt.
Drittens: Die zeitabhängigen zyklischen Routinen im loop des Sketches funktionieren nicht. (Die Tasten werden ja anscheinend nur in dieser Routine gepollt, also müsste loop prinzipiell laufen.) Dadurch fehlen aber die zyklische Rückmeldung des Powerstatus (und damit die Übermittlung von current) ebenso wie die halbsekündliche Prüfung des Powerzustandes und entsprechende Aktualisierung und Statusmeldung von Chn4, wenn sich da was geändert hat (externer Wechselschalter gekippt, Lampe durchgebrannt )
Viertens: Die parse-Routine im .pm muss auch laufen, sonst würden die button-Events nicht den beiden Kanälen zugeordnet werden, oder?
Ich versuche es jetzt nochmal mit Reset und Neuflashen.

edit1:
1) ein Reset (set Sw1CFW (wie er inzwischen heißt) reset) kommt an, die Kombination 3xkurz blinkt auf der LED. Ein getConfig wird anschließend abgearbeitet und liefert das Pairing mit 0x000000 zurück. Auch lässt sich der Aktor schalten. Akzeptiert die alternative Firmware alle Steuerbefehle? getConfig auf ungepairte Aktoren geht normalerweise nicht.
2) Dieses Reset erweckt aber das Gerät nicht unbedingt zu neuem Leben. Was hängt, hängt weiter.
3) Auch ein Neuflashen der alten Firmware scheint nichts zu ändern, vor allem nicht an den Einstellungen.
4) Erst wenn ich eine geänderte Firmware flashe (habe nur das Zyklussendeintervall auf 30s geändert) ... KOMMEN WIEDER POWER_EVENTS!
Irgendwas lag kurz später dem Aktor wieder schräg, vielleicht hat er das Pairing (hmPairSerial scheint zu funktionieren, wenn man anschließend ein Button Event auslöst) nicht vertragen
5) Intervall wieder auf 20s und die HMID meiner Zentrale gleich eingetragen, erspart das Pairing ...
so, seither
- getConfigs laufen fehlerfrei durch (gibt allerdings immer noch kein Register im Device)
- Power_Events kommen regelmäßig alle 20s
- current wird laufend aktualisiert (ziemlich schleppend, es ist wie ein Zähler für die Zykluszeit - je länger an, umso höher)
- Status Sw_02 wird je nach Schaltzustand des externen Wechslers fast sofort aktualisiert
auf deutsch alles so wie es soll. Aber ich habe noch kein einziges Register programmiert seit dem Flashen!
Mal sehen, wie lange es anhält.

[frank]

hast du eigentlich den ota-fähigen bootloader geflasht?
4k oder 8k?

zur besseren bedienung des config tasters empfehle ich:
https://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891

ich würde mal die zyklische powermessage (805E) untersuchen:

Code Auswählen Erweitern

E266EA5,0000,13E48AE7,FF,FFC6,84805E266EA51ACE1F0000000000000003000000

das byte 03 kurz vorm ende zeigt mit current=3 an.

grundsätzlich immer alle 20s.
kommt sie überhaupt noch?
wenn ja, muss sie das current reading in chn4 erzeugen.
das sollte in der parse funktion der pm datei geschehen.
eventuell mal eine log meldung einbauen.

grundsätzlich könnte man auch mal einen serialmonitor an rx/tx der controler platine anschliessen.
bin aber unsicher, ob dazu erst ein debug-define freigeschaltet werden müsste.

unreachable sollte von chn4 kommen, da fhem ein statusrequest an chn3 und chn4 sendet, aber chn4 den befehl nicht kennt (meine fw).
mit autoreadreg=0 sollten die requests verschwinden, denke ich.

[papa]

Schau mal der Jerome hatte schon mal das ganze mit der AskSin++ Library nachgebaut. Allerdings ohne die Strommessung.
https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HB-LC-Sw1PBU-FM
Vielleicht geht es damit besser. FHEM-Integration ist hier mit drin:
https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM