[ERLEDIGT] Rollladenaktor aktualisiert Readings nicht

[balli1187]

Mahlzeit,

ich habe seit einiger Zeit das Problem, dass einer meiner drei Rollladenaktoren (HM-LC-Bl1PBU-FM) seiner Funktion zwar tadellos nachkommt, d.h. Befehl am Schalter und per Protokoll werden umgesetzt, aber die Readings in FHEM zum Großteil nicht aktualisiert werden.
Aufgefallen ist es mir nur deshalb weil ich am zugehörigen Fenster (eigentlich eine Terrassentür) auch einen optischen HM-Fensterkontakt habe, über den ein bisschen Logik läuft. ist beispielsweise das Fenster geöffnet, soll der Aktor gesperrt werden, sodass ich nicht durch automatisches Herunterfahren ausgesperrt werden kann, wenn ich mal kurz in den Garten renne.

Der Aktor ist seit etwa 1,5 Jahren im Einsatz.
Hier das List des Aktors:

Code Auswählen Erweitern


Internals:
   DEF        507545
   IODev      VU_nanoCUL
   LASTInputDev VU_nanoCUL
   MSGCNT     6
   NAME       Wz.RollladenLinks
   NOTIFYDEV  global
   NR         122
   NTFY_ORDER 50-Wz.RollladenLinks
   STATE      on
   TYPE       CUL_HM
   VU_nanoCUL_MSGCNT 6
   VU_nanoCUL_RAWMSG A0ED5A410507545AB03100601C80036::-54:VU_nanoCUL
   VU_nanoCUL_RSSI -54
   VU_nanoCUL_TIME 2018-11-29 07:02:04
   lastMsg    No:D5 - t:10 s:507545 d:AB0310 0601C80036
   protLastRcv 2018-11-29 07:02:04
   protRcv    6 last_at:2018-11-29 07:02:04
   protSnd    7 last_at:2018-11-29 07:02:04
   protState  CMDs_done
   rssi_VU_nanoCUL cnt:6 min:-57 max:-54 avg:-55.33 lst:-54
   rssi_at_VU_nanoCUL cnt:6 min:-55.5 max:-54 avg:-54.41 lst:-54
   READINGS:
     2018-11-29 07:01:23   CommandAccepted yes
     2018-06-17 12:03:14   D-firmware      2.8
     2018-06-17 12:03:14   D-serialNr      NEQ1601382
     2017-05-22 10:34:29   PairedTo        0xAB0310
     2017-05-22 10:34:30   R-driveDown     29.9 s
     2017-05-22 10:34:30   R-driveTurn     1 s
     2017-05-22 10:34:30   R-driveUp       29.9 s
     2017-05-22 10:34:29   R-pairCentral   0xAB0310
     2017-05-22 10:34:30   R-powerUpAction off
     2017-05-22 10:34:30   R-sign          off
     2017-05-22 10:34:29   RegL_00.        02:01 0A:AB 0B:03 0C:10 15:FF 18:00 00:00
     2017-05-22 10:34:30   RegL_01.        08:00 09:00 0A:00 0B:01 0C:2B 0D:01 0E:2B 0F:0A 10:00  30:06 57:24 56:00 00:00
     2018-11-29 07:02:04   deviceMsg       on (to VCCU)
     2018-11-29 07:02:04   dim             stop:on
     2018-11-22 08:22:48   inhibit         set_off
     2018-11-29 07:02:04   level           100
     2018-11-16 18:37:58   level_old       45.5
     2018-06-17 22:49:15   motor           stop:20
     2018-11-29 07:02:04   overheat        off
     2018-11-29 07:02:04   overload        off
     2018-11-29 07:02:04   pct             100
     2017-05-21 00:07:18   powerOn         2017-05-21 00:07:18
     2018-11-29 07:02:04   recentStateType info
     2018-11-29 07:02:04   reduced         off
     2018-11-29 07:02:04   state           on
     2018-11-29 07:02:04   timedOn         off
   helper:
     HM_CMDNR   213
     cSnd       11AB03105075450201C80320FFFF,01AB0310507545010E
     dlvlCmd    ++A011AB03105075450201C80320FFFF
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +507545,00,00,00
       nextSend   1543471324.92432
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         507545
         00
         00
         00
     mRssi:
       mNo        D5
       io:
         CUNO:
         HMUSB:
         VU_nanoCUL:
           -48
           -48
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         VU_nanoCUL
       flg        A
       ts         1543471324.82544
       ack:
         HASH(0x2acf3c0)
         D58002AB031050754500
     rssi:
       VU_nanoCUL:
         avg        -55.3333333333333
         cnt        6
         lst        -54
         max        -54
         min        -57
       at_VU_nanoCUL:
         avg        -54.4166666666667
         cnt        6
         lst        -54
         max        -54
         min        -55.5
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      CUNO
   IOgrp      VCCU
   alexaName  Rollladen links
   alexaRoom  Wohnzimmer
   autoReadReg 4_reqStatus
   comment    EG_Rollladen
   devStateIcon on:fts_window_2w 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100 off:fts_shutter_100
   eventMap   1
   expert     2_raw
   firmware   2.8
   genericDeviceType light
   group      Fenster EG
   icon       shutter_3
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Alexa,Home,Wohnzimmer
   serialNr   NEQ1601382
   sortby     1
   subType    dimmer
   webCmd     statusRequest:toggleDir:on:off:up:down:stop

Woran kann das liegen? An der Konfiguration wurde in letzter Zeit nichts wissentlich geändert.

Grüße, Stephan

[frank]

die readings sind doch von heute morgen.
was genau passt nicht?

[CoolTux]

Stimme Frank zu. Sieht aktuell aus. Oder bist in der Zwischenzeit schon gefahren?

[balli1187]

Dann hab ich wohl gerade einen ungünstigen Moment erwischt...

Es ändert sich zum Beispiel kein Reading aus dem die Position des Aktors hervorgeht.
Bsp.:
- nachts fahre ich auf 20% herunter.
- morgens auf 100%
- in den Readings bleibt aber alles bei 20% stehen (state, pct, motor:20%)

Dabei ist es egal ob ich von Hand schalte oder über FHEM.


Gesendet von iPhone mit Tapatalk

[frank]

das "attr subtype dimmer" ist zb falsch. wieso?
da muss "blindActuator" stehen.

[CoolTux]

Dann hab ich wohl gerade einen ungünstigen Moment erwischt...

Es ändert sich zum Beispiel kein Reading aus dem die Position des Aktors hervorgeht.
Bsp.:
- nachts fahre ich auf 20% herunter.
- morgens auf 100%
- in den Readings bleibt aber alles bei 20% stehen (state, pct, motor:20%)

Dabei ist es egal ob ich von Hand schalte oder über FHEM.


Gesendet von iPhone mit Tapatalk

Quittiert er denn den Fahrbefehl?

[LuckyDay]

Code Auswählen Erweitern

2018-11-29 07:02:04   dim             stop:on
hatte mich schon etwas gewundert, wieso bei dir das dim reading existiert
und noch schlimmer , das motor reading nicht aktuell bei dir ist!

Code Auswählen Erweitern

2018-06-17 22:49:15   motor           stop:20

[balli1187]

das "attr subtype dimmer" ist zb falsch. wieso?
da muss "blindActuator" stehen.

Das ist absichtlich gesetzt, wegen des Alexa-FHEM Moduls. Alexa-FHEM kennt (noch) keinen blindActuator und nur als "dimmer" lässt sich über die Echo-App ein Prozentwert einstellen.
Den workaround nutze ich seit einem Dreiviertel Jahr und bisher hat das keine Probleme gemacht. Bei den anderen beiden Aktoren ist es ebenso gesetzt - ohne probleme.

@CoolTux: was verstehst du unter quittieren? Ich höre/sehe, dass der rollladen läuft aber in der FHEM-Oberfläche passiert nichts.

@fhem-hm-knecht: genau dieses nicht-aktualisieren z.b. des Motor-Readings ist mein Problem.


Gesendet von iPhone mit Tapatalk

[CoolTux]

Das ist absichtlich gesetzt, wegen des Alexa-FHEM Moduls. Alexa-FHEM kennt (noch) keinen blindActuator und nur als "dimmer" lässt sich über die Echo-App ein Prozentwert einstellen.
Den workaround nutze ich seit einem Dreiviertel Jahr und bisher hat das keine Probleme gemacht. Bei den anderen beiden Aktoren ist es ebenso gesetzt - ohne probleme.

@CoolTux: was verstehst du unter quittieren? Ich höre/sehe, dass der rollladen läuft aber in der FHEM-Oberfläche passiert nichts.

@fhem-hm-knecht: genau dieses nicht-aktualisieren z.b. des Motor-Readings ist mein Problem.


Gesendet von iPhone mit Tapatalk

Von HM Schaltaktoren kenne ich das so das wenn Du ein set DEVICE on sendest er zu erst im Reading state schreibt set_on und erst wenn der Aktor quittiert hat das er auch den Befehl ausgeführt hat er im Reading state on schreibt.

[balli1187]

Aso....
Nein es bleibt alles wie es ist. Als hätte ich keine Aktion durchgeführt.


Gesendet von iPhone mit Tapatalk

[frank]

mit subType dimmer wird dieser blindActor nie richtig funktionieren.

[balli1187]

mit subType dimmer wird dieser blindActor nie richtig funktionieren.

Wie gesagt.... seit ca. einem 3/4 läuft es aber, soweit ich beurteilen kann, ohne Probleme und mit den anderen beiden laufen nach wie vor damit. Aber ich werde trotzdem mal testen und die Attribute rausnehmen.

Kannst du kurz erklären warum das Probleme machen sollte?


Gesendet von iPhone mit Tapatalk

[frank]

siehe commandref, oder schau ins modul

If you cannot use autocreate, then you have to specify:
the <6-digit-hex-code>or HMid+ch <8-digit-hex-code>
It is the unique, hardcoded device-address and cannot be changed (no, you cannot choose it arbitrarily like for FS20 devices). You may detect it by inspecting the fhem log.
the subType attribute
which is one of switch dimmer blindActuator remote sensor swi pushButton threeStateSensor motionDetector keyMatic winMatic smokeDetector
Without these attributes fhem won't be able to decode device messages appropriately.

Notes
If the interface is a CUL device, the rfmode attribute of the corresponding CUL/CUN device must be set to HomeMatic. Note: this mode is BidCos/Homematic only, you will not receive FS20/HMS/EM/S300 messages via this device. Previously defined FS20/HMS etc devices must be assigned to a different input device (CUL/FHZ/etc).
Currently supported device families: remote, switch, dimmer, blindActuator, motionDetector, smokeDetector, threeStateSensor, THSensor, winmatic. Special devices: KS550, HM-CC-TC and the KFM100.
Device messages can only be interpreted correctly if the device type is known. fhem will extract the device type from a "pairing request" message, even if it won't respond to it (see hmPairSerial and hmPairForSec to enable pairing). As an alternative, set the correct subType and model attributes, for a list of possible subType values see "attr hmdevice ?".

subType darf nicht angefasst werden.

[balli1187]

Hab's rausgenommen bzw. abgeändert. Keine Änderung! Hab mehrere Befehle abgesetzt.
Dabei ist mir aber aufgefallen, dass meine fehlerbeschreibung nicht ganz stimmt. Die readings hängen eine Aktion hinterher.
Also es wird quasi beim setzen auf den vorherigen Wert aktualisiert - nicht auf den aktuellen.
Dies geschieht auch so mit den bisherigen Attributen für genericDeviceTyp und subType.

Das Motor-Reading wurde dabei garnicht aktualisiert.


Gesendet von iPhone mit Tapatalk

[frank]

vielleicht hat fhem dem falschen dimmer auch falsche messages gesendet. nun rächt er sich. 

ich würde mal fhem "durchstarten".
und falls sich nichts ändert, den aktor resetten, neu pairen und wieder konfigurieren. eventuell vorher noch eine zeitlang spannungsfrei schalten.