[gefixed] Heutiges CUL_HM update defekt

[Burny4600]

Ich habe heute ein Update durchgeführt.
Bei den virtuellen Sensoren fehlt noch ein Attribut.

Code Auswählen Erweitern

2019.01.11 10:35:20.229 3: set OG1_STH_HZG_TC_Weather_vT_S virtTemp 18.9 : Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.230 3: at_OG1_STH_HZG_TC_Weather_vt: Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.335 3: set OG1_WC_HZG_TC_Weather_vT_S virtTemp 18.2 : Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet
2019.01.11 10:35:20.336 3: at_OG1_WC_HZG_TC_Weather_vt: Unknown argument virtTemp, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet


Der OG1_STH_HZG_TC_Weather_vT_S bekommt die richtige Temperatur übermittelt.
Die virtuelle Temperatur von OG1_WC_HZG_TC_Weather_vt wird trotz vorhandenem Peering nicht an den HM-CC-RT-DN übergeben.
Ebenso beim OG1_STH_HZG_TC_Weather.

list OG1_STH_HZG_TC_Weather_vT_S

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
   DEF        AAA00101
   NAME       OG1_STH_HZG_TC_Weather_vT_S
   NOTIFYDEV  global
   NR         3358
   NTFY_ORDER 50-OG1_STH_HZG_TC_Weather_vT_S
   STATE      set_virtTemp 19.4
   TYPE       CUL_HM
   chanNo     01
   device     OG1_STH_HZG_TC_Weather_vt
   peerList   EG_STH_HZG_RT_Weather,OG1_STH_HZG_RT_Weather,
   READINGS:
     2019-01-11 15:31:10   peerList        EG_STH_HZG_RT_Weather,OG1_STH_HZG_RT_Weather,
     2019-01-11 15:50:34   state           set_virtTemp 19.4
     2019-01-11 15:50:34   temperature     19.4
   helper:
     fkt        virtThSens
     virtTC     00
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       cmd        8470AAA001000000
       idh        3212320
       idl        256
       msgCnt     8
       msgRed     0
       next       1547218349.21848
       nextM      1547218349.21848
       typ        2
       val        00C2
       vin        19.4
Attributes:
   alias      OG1 Stiegenhaus - Heizung - Raumtemperatur Weather
   cyclicMsgOffset 250
   group      .Sensoren Temperatur Virtuell
   icon       temp_temperature
   model      VIRTUAL
   peerIDs    00000000,613F9E01,6391C201,
   room       OG1-Stiegenhaus
   sortby     03
   webCmd     press short:press long
Möglicher Weise hängt dieser Fehler am Attribut model VIRTUAL.
Bei der Durchsicht dieses Attribut gibt es keine Definition für Model mit VIRTUAL.

list OG1_STH_HZG_RT_Weather

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
   CHANGED   
   DEF        6391C201
   NAME       OG1_STH_HZG_RT_Weather
   NOTIFYDEV  global
   NR         3343
   NTFY_ORDER 50-OG1_STH_HZG_RT_Weather
   STATE      Raumtemperatur: 20.8 °C
   TYPE       CUL_HM
   chanNo     01
   device     OG1_STH_HZG_RT
   peerList   OG1_STH_HZG_TC_Weather_vT_S,
   READINGS:
     2018-12-07 05:59:40   CommandAccepted no
     2018-11-03 14:39:41   R-sign          off
     2018-12-17 20:08:29   RegL_01.        00:00 08:00
     2019-01-11 15:50:29   measured-temp   20.8
     2019-01-11 15:31:10   peerList        OG1_STH_HZG_TC_Weather_vT_S,
     2019-01-11 15:50:29   state           20.8
   helper:
     regLst     ,1
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
     tmpl:
Attributes:
   alias      OG1 Stiegenhaus - Heizung - Raumthermostat Weather
   devStateStyle style="text-align:left;;font-weight:bold;;"
   event-on-change-reading .*
   group      OG1 Stiegenhaus - Heizung
   icon       hc_wht_regler
   model      HM-CC-RT-DN
   peerIDs    00000000,AAA00101,
   room       Heizung,OG1-Stiegenhaus,_HM
   sortby     05.04
   stateFormat {sprintf(
"Raumtemperatur: %.1f °C",
ReadingsVal("$name","measured-temp",0))}

[curt]

Nun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist.

Nach dem Update gab es massiv der beschriebenen Fehlermeldung "HM_5A6737: unknown attribute .mId. Type 'attr HM_5A6737 ?' for a detailed list.". Außer dem unschönen "autosave deactivated" fiel mir erstmal nichts auf.

Nach einem weiteren Update kommt das nicht mehr. Allerdings werden nun meine Tür/Fenstermelder in FHEM überhaupt nicht mehr angezeigt. Als wenn sie nicht da wären. Kein Protokoll, kein SVG.

Bei mir sind alle diese Melder nicht in fhem.cfg. Sie werden via include aus einer weiteren Datei geladen.

[JWRu]

Wenn man das so liest, sollte man wohl vorerst mal auf Updates verzichten, wenn man so wie ich einiges an Homematic hat.

[FunkOdyssey]

Nein. Alles wieder in Ordnung.

[Udomatic]

Bei mir funktioniert soweit alles wieder, wie es sein soll. Ich bin dem Entwickler jedenfalls dankbar, dass er weiterhin Updates anbietet und sich kümmert, all die Probleme zu lösen. Ich finde es schon Wahnsinn, wie viel Zeilen Code in diesem Modul stecken.

Allerdings wird seit dem Update in meinen Fensterkontakten ein Channel angezeigt, der nun die gepeerten Devices führt. Das verstehe ich nicht?

Code Auswählen Erweitern


Internals:
   DEF        5D3DE9
   IODev      myHmUART
   NAME       Bad_Fenster
   NOTIFYDEV  global
   NR         77
   NTFY_ORDER 50-Bad_Fenster
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Bad_Fenster_Win

Das hat auch zur Folge, dass der STATE nun nicht mehr direkt in den Internals des Device angezeigt wird sondern im neuen "channel_01 Bad_Fenster_Win"

Das ist bei allen bestehenden Fenster Kontakten. Bei einem heute neu hinzu gefügten Fensterkontakt ist das nicht der Fall und so, wie ich es von den anderen bisher kannte

Code Auswählen Erweitern


Internals:
   DEF        594C6E
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     15
   NAME       Kueche_Fenster
   NOTIFYDEV  global
   NR         248
   NTFY_ORDER 50-Kueche_Fenster
   STATE      closed
   TYPE       CUL_HM


Gibt es noch mehr Anwender bei denen das so ist? Wie soll es richtig sein?

[Fredi69]

Nein. Alles wieder in Ordnung.

D.h. man man kann wieder gefahrlos ein Update machen?

[Udomatic]

Bei mir funktioniert soweit alles wieder, wie es sein soll. Ich bin dem Entwickler jedenfalls dankbar, dass er weiterhin Updates anbietet und sich kümmert, all die Probleme zu lösen. Ich finde es schon Wahnsinn, wie viel Zeilen Code in diesem Modul stecken.

Allerdings wird seit dem Update in meinen Fensterkontakten ein Channel angezeigt, der nun die gepeerten Devices führt. Das verstehe ich nicht?

Code Auswählen Erweitern


Internals:
   DEF        5D3DE9
   IODev      myHmUART
   NAME       Bad_Fenster
   NOTIFYDEV  global
   NR         77
   NTFY_ORDER 50-Bad_Fenster
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Bad_Fenster_Win

Das hat auch zur Folge, dass der STATE nun nicht mehr direkt in den Internals des Device angezeigt wird sondern im neuen "channel_01 Bad_Fenster_Win"

Das ist bei allen bestehenden Fenster Kontakten. Bei einem Heute neu hinzu gefügten Fensterkontakt ist das nicht der Fall und so, wie ich es von den anderen bisher kannte

Code Auswählen Erweitern


Internals:
   DEF        594C6E
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     15
   NAME       Kueche_Fenster
   NOTIFYDEV  global
   NR         248
   NTFY_ORDER 50-Kueche_Fenster
   STATE      closed
   TYPE       CUL_HM


Gibt es noch mehr Anwender bei denen das so ist? Wie soll es richtig sein?

[curt]

@martinp876

Zu den Devices: Man muss nichts neu Pairen, peeren, oder Register setzen. FHEM /CUL_HM setzt ohne User Kommando NIE diese Einstellungen.

Das ist mein Trostpflaster, ich hoffe das sehr. Im Moment aber ...

Die alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm

Ich habe eine Komplettsicherung des Verzeichnisses /opt/fhem vom 2018-12-23. Dazu später.

Das eigentliche System ist völlig aktuell. Meine Tür/Fensterkontakte werden NICHT angezeigt und auch nicht von FTUI verarbeitet.

Ich habe 10_CUL_HM.pm und HMConfig.pm von der o.g. Sicherung eingespielt. Neustart. Keine Änderung. Update, beide werden geupdatet. Neustart. Keine Änderung.

Bei mir sind alle Kontakte in einer ReadingsGruop zusammengefasst, da fiel mir dann doch etwas auf:

Code Auswählen Erweitern

model HASH(0x48b14f8)

Ok, dann kann so einiges nicht funktionieren.

Ich kann gerne lists veröffentlichen, Kommandos ausführen. Mir bitte aber konkret schreiben, was ich tun soll (ich habe im Moment Angst, alles noch schlimmer zu machen - sooo firm bin ich nicht.).

[MadMax-FHEM]

@Curt: vielleicht ist dein Problem dasselbe wie von Udomatic!?
(Einen Beitrag über deinem)

Gruß, Joachim

[curt]

@MadMax-FHEM
Ich kann die Frage nicht beantworten.

Ich habe -wie ich mit Schrecken sehe- auch einen Fensterkontakt, der "RESPONSE TIMEOUT:RegisterRead" sagt - obwohl er antwortet.

Ich kann gern alle Kontakte auflisten (gern als Anlage). Nur müsste mir bitte jemand genau sagen, was ich in die FHEM-Kommandozeile eingeben muss.

[MadMax-FHEM]

Code Auswählen Erweitern

list Gerätename

Von beispielsweise dem mit dem Timeout...
...und dann hier in Code-Tags posten...

Gruß, Joachim

[curt]

list Dachfenster (das ist der mit dem Timeout)

Code Auswählen Erweitern


Internals:
   CFGFN      ./FHEM/z-include-fenster.cfg
   DEF        578BD4
   IODev      SCC
   LASTInputDev SCC
   MSGCNT     2
   NAME       Bad_Dachfenster
   NOTIFYDEV  global
   NR         62
   NTFY_ORDER 50-Bad_Dachfenster
   SCC_MSGCNT 2
   SCC_RAWMSG A0C318641578BD4000000010C00::-75:SCC
   SCC_RSSI   -75
   SCC_TIME   2019-01-11 22:57:04
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:31 - t:41 s:578BD4 d:000000 010C00
   protLastRcv 2019-01-11 22:57:04
   protRcv    2 last_at:2019-01-11 22:57:04
   rssi_at_SCC cnt:2 min:-75 max:-69.5 avg:-72.25 lst:-75
   READINGS:
     2019-01-11 22:36:31   Activity        alive
     2018-12-15 23:27:09   CommandAccepted yes
     2018-12-15 23:27:08   D-firmware      1.0
     2019-01-10 11:19:08   D-serialNr      OEQ0395024
     2018-07-28 02:39:04   PairedTo        0xFF1312
     2018-07-28 02:39:03   R-cyclicInfoMsg on
     2018-07-28 02:39:03   R-eventDlyTime  0 s
     2018-12-15 23:27:08   R-pairCentral   set_0xFF1312
     2018-07-28 02:39:03   R-sabotageMsg   on
     2018-07-28 02:39:03   R-sign          on
     2019-01-10 14:12:01   RegL_00.       
     2018-12-15 23:27:09   aesCommToDev    ok
     2018-12-15 23:27:09   aesKeyNbr       00
     2019-01-09 02:03:13   alive           yes
     2019-01-09 02:03:13   battery         ok
     2019-01-09 02:03:13   contact         closed (to VCCU)
     2019-01-10 11:19:12   powerOn         2019-01-10 11:19:12
     2019-01-11 22:27:39   recentStateType info
     2019-01-09 02:03:13   sabotageError   off
     2019-01-10 11:19:38   state           RESPONSE TIMEOUT:RegisterRead
     2018-07-29 02:16:42   trigDst_FF1312  noConfig
     2019-01-11 22:57:04   trigger_cnt     12
   helper:
     HM_CMDNR   49
     mId       
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +578BD4,00,00,00
       nextSend   1547243824.26376
       rxt        0
       vccu       VCCU
       p:
         578BD4
         00
         00
         00
       prefIO:
         SCC
     mRssi:
       mNo        31
       io:
         SCC:
           -73
           -73
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_SCC:
         avg        -72.25
         cnt        2
         lst        -75
         max        -69.5
         min        -75
     tmpl:
Attributes:
   Fenster_Status structure_Fenster
   IODev      SCC
   IOgrp      VCCU:SCC
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_roof_open_2@red closed:fts_window_roof@green
   expert     2_raw
   firmware   1.0
   fp_Hauptseite 376,651,1,structure_Fenster
   model      HASH(0x48b14f8)
   peerIDs    00000000,
   room       Unsorted
   serialNr   OEQ0395024
   subType    1
   userattr   Fenster_Status Fenster_Status_map structexclude


[MadMax-FHEM]

Du arbeitest mit "verteilter" Config!?

   CFGFN      ./FHEM/z-include-fenster.cfg

Da weiß ich nicht, ob da immer alles so tut wie gewollt/gesollt...
...wozu das?

Manuell editieren soll man ja tunlichst nicht!?
Wozu also die Aufteilung...


Die Einträge sind eigenartig (widerspricht sich ein wenig: gepaired aber trotzdem set_).
Evtl. wegen dem Timeout?

     2018-07-28 02:39:04   PairedTo        0xFF1312
...
     2018-12-15 23:27:08   R-pairCentral   set_0xFF1312

Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...


Das kann nicht stimmen:

   model      HASH(0x48b14f8)

Was für ein Typ ist es denn?
HM-SEC-SC-2
oder
HM-SEC-SCo

Wie ist denn deine readingsGroup definiert?
Oder gibt es da kein Problem bis auf die "komische" Anzeige bzgl. model?

Gruß, Joachim

[curt]

Du arbeitest mit "verteilter" Config!?
Da weiß ich nicht, ob da immer alles so tut wie gewollt/gesollt...
...wozu das?
Manuell editieren soll man ja tunlichst nicht!?
Wozu also die Aufteilung...

Ich habe, als sie fertig waren, alle ausgelagert. Ich kann die auch gern alle zurück ins Reich holen. Aber wir verzetteln uns.

Die Einträge sind eigenartig (widerspricht sich ein wenig: gepaired aber trotzdem set_).
Evtl. wegen dem Timeout?

Das kann ich nicht beurteilen.
Vergleichsweise ein Sensor ohne diese Fehlermeldung:

Code Auswählen Erweitern


Internals:
   CFGFN      ./FHEM/z-include-fenster.cfg
   DEF        30D87D
   IODev      SCC
   NAME       Gaeste_Fenster_Strasse
   NOTIFYDEV  global
   NR         69
   NTFY_ORDER 50-Gaeste_Fenster_Strasse
   STATE      closed
   TYPE       CUL_HM
   READINGS:
     2019-01-11 22:36:31   Activity        alive
     2017-06-20 21:07:37   CommandAccepted yes
     2018-07-28 02:06:49   D-firmware      2.4
     2018-07-28 02:06:49   D-serialNr      LEQ1091622
     2018-07-28 02:06:49   PairedTo        0xFF1312
     2018-07-28 02:06:49   R-cyclicInfoMsg off
     2018-07-28 02:06:49   R-eventDlyTime  0 s
     2018-07-28 02:06:49   R-pairCentral   0xFF1312
     2018-07-28 02:06:49   R-sabotageMsg   on
     2018-07-28 02:06:49   R-sign          off
     2018-07-28 02:06:49   RegL_00.        02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06 00:00
     2018-07-28 02:06:49   RegL_01.        08:00 20:60 21:00 22:64 30:06 00:00
     2018-07-28 02:07:09   alive           yes
     2019-01-09 00:45:38   battery         ok
     2019-01-09 00:45:38   contact         closed (to VCCU)
     2017-07-28 23:50:38   powerOn         2017-07-28 23:50:38
     2018-07-28 02:07:09   recentStateType info
     2018-07-28 02:07:09   sabotageError   off
     2019-01-09 00:45:38   state           closed
     2018-07-29 02:17:49   trigDst_FF1312  noConfig
     2019-01-11 13:21:37   trigger_cnt     127
   helper:
     HM_CMDNR   50
     mId       
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +30D87D,00,00,00
       rxt        0
       vccu       VCCU
       p:
         30D87D
         00
         00
         00
       prefIO:
         SCC
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   Fenster_Status structure_Fenster
   IODev      SCC
   IOgrp      VCCU:SCC
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_tilt@red closed:fts_window_1w@green
   expert     2_raw
   firmware   2.4
   fp_Hauptseite 376,651,1,structure_Fenster
   model      HASH(0x48b14f8)
   peerIDs    00000000,
   room       Unsorted
   serialNr   LEQ1091622
   subType    1
   userattr   Fenster_Status Fenster_Status_map structexclude


Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...

Ich komme vom Fach, also nicht HM-Fach, sondern IT-Fach. Erste Regel: Wenn was schief geht, Nerven bewahren. NICHT wild rumklicken! Das macht alles nur noch schlimmer!
Neh Du, ich mache das im Moment lieber nicht.

Das kann nicht stimmen:

Code Auswählen Erweitern

model      HASH(0x48b14f8)

Tritt bei sämtlichen Kontakten auf.

Was für ein Typ ist es denn?
HM-SEC-SC-2

Viele davon. Sowie einmal der -wie heißt der- der mit der Lichtschranke. Der mit der Lichtschranke ist der, der den response-timeout wirft! Nachtrag: Das ist ein HM-SEC-SCo

Wie ist denn deine readingsGroup definiert?
Oder gibt es da kein Problem bis auf die "komische" Anzeige bzgl. model?

So hier - da geht selbstredend der Filter schief, wir haben ja kein model, nur einen hash ... woher auch immer der kommt:

Code Auswählen Erweitern


define rdg_Fenster_Tueren readingsGroup .*:FILTER=model=HM-SEC-SC(.*):battery,sabotageError,state
attr rdg_Fenster_Tueren alias Fenster und Türen
attr rdg_Fenster_Tueren room 11 Fenster Tür,Unsorted
attr rdg_Fenster_Tueren valueIcon { 'state' => '%devStateIcon', 'sabotageError.on' => 'time_manual_mode@red', 'sabotageError.off' => 'security@green', 'battery.ok' => 'measure_battery_100@green', 'battery.low' => 'measure_battery_0@red' }
attr rdg_Fenster_Tueren valueStyle style="text-align:right"


Aber auch alle Anzeigen in FTUI gehen schief. Für jeden Kontakt so eine Definition. Die leider derzeit auch nicht tut - was ich so interpretiere, dass state nicht aktualisiert wird.

Code Auswählen Erweitern


<div data-type="symbol"
        data-device="Terrassentuer"
        data-on-color="#A00000"
        data-off-color="#00A000"
        data-states='[open,closed]'
        data-icon="ftui-window"
        data-get-on="open"
        data-get-off="closed"
        class="bigger compressed-50">
</div>



P.S: HM-SEC-SCo konkretisiert.

[MadMax-FHEM]

Ich habe, als sie fertig waren, alle ausgelagert. Ich kann die auch gern alle zurück ins Reich holen. Aber wir verzetteln uns.

Ja, war ja nur eine Frage/Feststellung und Anmerkung, dass eben bei verteilten cfgs auch gerne mal was nicht so läuft wie es soll/gedacht.
Bei vielen Dingen ist die Reihenfolge entscheidend: IODev VOR Device (eh klar) etc.

Ich komme vom Fach, also nicht HM-Fach, sondern IT-Fach. Erste Regel: Wenn was schief geht, Nerven bewahren. NICHT wild rumklicken! Das macht alles nur noch schlimmer!
Neh Du, ich mache das im Moment lieber nicht.

Tja dann lass es halt.
Aber wenn die notwendigen Infos nicht zurückgelesen werden (getConfig) dann wird der Zustand halt "halbseiden" bleiben...

Und: mal ein getConfig (wenn man [was ich getan habe] zusieht, dass keine msgPending sind) ist kein Problem...
...und hat nichts mit "wild rumklicken" zu tun...

Tritt bei sämtlichen Kontakten auf.

Viele davon. Sowie einmal der -wie heißt der- der mit der Lichtschranke. Der mit der Lichtschranke ist der, der den response-timeout wirft! Nachtrag: Das ist ein HM-SEC-SCo

So hier - da geht selbstredend der Filter schief, wir haben ja kein model, nur einen hash ... woher auch immer der kommt:

Tja woher das kommt weiß ich auch nicht...
...aber solange das model nicht passt wird vieles nicht so gehen wie es soll.

Und ja das mit der Lichtschranke ist der HM-SEC-SCo...


Bzgl. FTUI kann ich nichts sagen, nutze ich nicht und kenne ich daher gerade mal dem Namen nach

Gruß, Joachim