Autor Thema: Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter  (Gelesen 459712 mal)

Offline nugat1

  • New Member
  • *
  • Beiträge: 15
Hallo, ich hatte auch am Sonntag ein update gemacht.
Nach dem Update war hinter "Save config" ein rotes Fragezeichen, hab mir nichts dabei gedacht, und gespeichert.
Montag ist mir aufgefallen, dass bei einem Schalter das Longpress nicht mehr funktionierte.
Dies sollte eigentlich durch ein notify eine Aktion ausführen.

Heute hab ich mir das mal genauer angeschaut:
Wieder ein Update durchgeführt, nachher kam eine Warnung zu allen HM Geräten, das .mID kein gültiges Attribut wäre.
Habe mal in die fhem.cfg geschaut - alle HM Geräte hatte ein .mID attribut definiert.
Dann ist mir aufgefallen, dass all meine Schalter mit CusomFirmware nur noch hab definiert waren - d.h. es existierte nur noch das Device als solche und die beiden Btn Devices.
-> Die Aktor Definitionen waren verschwunden (dies war sicherlich das "Save config" nach dem ersten Update.

Ich habe dann aus dem restoredir den Stand (Module und fhem.cfg) von vor dem Update (Sonntag 06.01.) zurückgespielt und dann funktionierte wieder alles.
Weiterhin habe ich grad eben noch ein Update gemacht - ohne das was kaputt gegangen ist.

ich hoffe das hilft jemanden weiter, der vielleicht auch ein Problem hatte, falls er am Sonntag ein Update gemacht hat.

Offline anfänger111

  • New Member
  • *
  • Beiträge: 17
Guten Tag,

"plötzlich" zeigt mein "Sw_02"-Device nicht mehr den aktuellen Status (on, off) an, wenn der Schalter manuell (also nicht über FHEM) betätigt wurde.

Könnte dies am Update liegen oder vlt an der Verwendung einer VCCU (statt direkt per HMLAN)?

Vielen Dank

Offline mike.d

  • Jr. Member
  • **
  • Beiträge: 62
ich habe heute auch einen meiner Schalter mit der alternativen firmware geflasht.

Wenn ich ihn jedoch paire werden die Kanäle nicht automatisch mit angelegt. Ich habe ausschließlich den <HM-LC-SW1PBU-FM_Device>. Damit kann ich auch nicht intern peeren und auch nicht schalten über FHEM.

Liegt es an der aktuellen CUL_HM?

Internals:
   DEF        29F26F
   FUUID      5c4e70ee-f33f-303b-09a3-511ac8529c8d2865
   HMLAN1_MSGCNT 7
   HMLAN1_RAWMSG E29F26F,0000,32911239,FF,FFC2,A5805E29F26F29A3CE0000000000000000000000
   HMLAN1_RSSI -62
   HMLAN1_TIME 2019-01-28 04:15:25
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     7
   NAME       HM_29F26F
   NOTIFYDEV  global
   NR         881
   NTFY_ORDER 50-HM_29F26F
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:A5 - t:5E s:29F26F d:29A3CE 0000000000000000000000
   protLastRcv 2019-01-28 04:15:25
   protRcv    7 last_at:2019-01-28 04:15:25
   rssi_at_HMLAN1 cnt:7 min:-62 max:-55 avg:-60.57 lst:-62
   READINGS:
     2019-01-28 04:03:11   CommandAccepted yes
     2019-01-28 04:03:10   D-firmware      1.5
     2019-01-28 04:03:10   D-serialNr      PS00000002
     2019-01-28 04:03:41   PairedTo        0x29A3CE
     2019-01-28 04:03:14   R-pairCentral   0x29A3CE
     2019-01-28 04:03:41   RegL_00.        00:00 02:01 05:00 0A:29 0B:A3 0C:CE 12:00
   helper:
     HM_CMDNR   165
     mId       
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +29F26F,00,00,00
       nextSend   1548645325.66934
       prefIO     
       rxt        0
       vccu       
       p:
         29F26F
         00
         00
         00
     mRssi:
       mNo        A5
       io:
         HMLAN1:
           -58
           -58
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN1:
         avg        -60.5714285714286
         cnt        7
         lst        -62
         max        -55
         min        -62
     tmpl:
Attributes:
   IODev      HMLAN1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.5
   model      unknown
   room       CUL_HM
   serialNr   PS00000002
   subType    1

Offline stefanpf

  • Full Member
  • ***
  • Beiträge: 133
alles schon so lange her.

wir reden vom selben file.
ich glaube, ich habe es mal umbenannt, da martin in cul_hm etwas geändert hatte. aber schon ewig lange her.
in cul_hm werden files beim start geladen, die mit hmconfig beginnen. selbes muster beim universalsensor von dirk.
später funktionierte allerdings auch wieder der 99er name.

im file wird ja der subType remoteAndSwitch definiert.

wenn es generell nicht mehr funktionieren würde, wäre hier wohl schon länger mehr unruhe, denke ich.

hat dein file die richtigen berechtigungen?
wird der schalter bei "get hminfo models" gelistet?


edit:
hier ist mein post von damals https://forum.fhem.de/index.php/topic,18071.msg326473.html#msg326473

Hatte ebenfalls keinen Status mehr und haufenweise Warnungen im Log.
Habe die 99_Ask... gelöscht, deine Datei unverändert  genommen und auf ein Getconfig aufgerufen: Subtype steht wieder auf remoteAndSwitch und der Status stimmt auch wieder.
Logs muss ich noch beobachten.
Danke für die Datei... auch wenn sie vielleicht nicht mehr benötigt wird hier hat es geholfen :)

Edit: schade, im Laufe einiger Stunden wechselt der Status auf unreachable. Nach dem Schalten iSt er zwar sofort wieder da, aber....
« Letzte Änderung: 08 März 2019, 06:49:11 von stefanpf »

Offline Y. Lee

  • Newbie
  • Beiträge: 1
Tut mir leid, aber bei mir greifen die angesprochenen Lösungsvorschläge nicht.

Zu meinem aktuellen Status:
  • Ich habe die Custom Firmware auf 4 HomeMatic Schaltern drauf und es hat bis letzte Woche funktioniert. Habe schon länger kein Update mehr gemacht und letzte Woche wollte ich einen Sonoff mit Tasmota einbinden und daher ein Update durchgeführt.
  • Das File "99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm" habe ich auch im Verzeichnis fhem/FHEM liegen und die Berechtigungen passen.
  • Als "subType" habe ich "switch" eingetragen.
  • Ich habe seit neuestem auch immer eine Zeile "setuuid" für jedes Device dabei.

Hat jemand eine Idee was ich machen kann?

Vielen Dank vorab,
Y. Lee

Offline frank

  • Hero Member
  • *****
  • Beiträge: 7396
subtype ist falsch => remoteAndSwitch.
FHEM: 5.8(SVN) => Pi3(jessie)
IO: CUL433_V3.3(1.00.01B53)|CUL868_V3.3(1.58)|HMLAN(0.965)|HMUSB2(0.967)|HMUART(1.4.1)
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500

Offline stefanpf

  • Full Member
  • ***
  • Beiträge: 133
Bei mir hat es sich wieder berappelt nachdem ich die Schritte aus dem oben verlinkten Beitrag mit der dort aufgeführten Datei durchgeführt habe.
Das unreachable war dann nach zwei Tagen verschwunden.
Durch das manuelle Verstellen des Subtype ist es allerdings bei mir eher schlimmer geworden bzw. das klappte erst garnicht (da musste ich ein weiteres Attribut setzen, dass das erst erlaubte).
Hatte dann ne Sicherung wiederhergestellt .

Offline Haecksler

  • Full Member
  • ***
  • Beiträge: 168
Irgendetwas scheint hier aber schon schief gelaufen zu sein...meine beiden Schalter sind nach dem letzten Update auch nicht mehr zuverlässig in ihrer Funktion.

Ich habe festgestellt, dass beide keinen subType mehr haben, weiterhin ist das subType "remoteAndSwitch" in der Dropdownauswahl auch nicht mehr verfügbar.

Nachtrag: Nach einem manuellen reload von 10_CUL_HM war das Problem behoben.... Scheint also ein Timing-Problem beim Start zu sein.
« Letzte Änderung: 19 März 2019, 22:14:44 von Haecksler »

Offline frank

  • Hero Member
  • *****
  • Beiträge: 7396
Zitat
Nachtrag: Nach einem manuellen reload von 10_CUL_HM war das Problem behoben.... Scheint also ein Timing-Problem beim Start zu sein.

nach dem reload ist der subtype remoteandswitch im pulldown enthalten?
FHEM: 5.8(SVN) => Pi3(jessie)
IO: CUL433_V3.3(1.00.01B53)|CUL868_V3.3(1.58)|HMLAN(0.965)|HMUSB2(0.967)|HMUART(1.4.1)
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500

Offline Haecksler

  • Full Member
  • ***
  • Beiträge: 168
nach dem reload ist der subtype remoteandswitch im pulldown enthalten?

Nach dem reload war der subType wieder automatisch auf remoteAndSwitch.

Offline knueppler

  • Full Member
  • ***
  • Beiträge: 125
Guten Morgen,

ähnliches bei mir. Habe gestern mal wieder einen Update durchgeführt und hatte dann Probleme:
Schalter konnten zwar über fhem bedient werden, aber es gab keine Rückmeldung, current etc wurde nicht ausgelesen.
Manuelles nachladen von 10_CUL_HM hat es dann behoben.
Status wieder da, Current etc wird wieder ausgelesen.

Ciao Christian

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 12154
  • schon mal restore trainiert?
    • Otto's Technik Blog
Habe gestern mal wieder einen Update durchgeführt und hatte dann Probleme:
...
Manuelles nachladen von 10_CUL_HM hat es dann behoben.
Hallo Christian,

wie muss man das denn verstehen? Du hast das System aktualisiert und hattest nach einem alten FHEM update kein shutdown restart gemacht?
Du hast dann 10_CUL_HM aus dem restoredir geholt und einen alten Stand wieder hergestellt?
Du hast 10_CUL_HM separat aktualisiert?

Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline knueppler

  • Full Member
  • ***
  • Beiträge: 125
Hi Otto,

also, update, shutdown restart, und da waren sie, die Probleme...
Dann in der Kommandozeile von fhem reload 10_CUL_HM eingegeben, voila.

Ciao Christian

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 12154
  • schon mal restore trainiert?
    • Otto's Technik Blog
aha klingt eigenartig. Mehr reload als beim restart geht doch eigentlich nicht?

Was passiert denn bei einem zweiten reload? Komisch ...
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline stefanpf

  • Full Member
  • ***
  • Beiträge: 133
Meines Erachtens hat das mit der Ladereihenfolge der Module zu tun.
Die 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm wurde noch nicht geladen wenn die 10_CUL_HM.pm bereits geladen wurde. Entsprechend steht "remoteAndSwitch" noch nicht zur Verfügung.

Im Quelltext der 10_CUL_HM werden Erweiterungen aus allen Dateien geladen, deren Dateiname mit HM_Config beginnt....
foreach my $m (grep /^HMConfig_(.*)\.pm$/,readdir(DH)) {
Wenn man die abgewandelte Datei (mit dem geänderten Dateinamen) aus https://forum.fhem.de/index.php/topic,18071.msg326473.html#msg326473 
anstelle der 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm verwendet wird man der Ladereihenfolge gerecht

Es wäre cool, wenn das im ersten Beitrag vermerkt wäre, da das Problem ja anscheinend schon lange bekannt und behoben ist.
Der ursprüngliche Author scheint aber nicht mehr aktiv zu sein :-(

P.S.: nicht auf meinem Mist gewachsen - ich habe mir nur die Infos aus Forum und Quelltext zusammengepuzzelt .-)
« Letzte Änderung: 23 März 2019, 10:43:15 von stefanpf »
Informativ Informativ x 2 Liste anzeigen