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:
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
die readings sind doch von heute morgen.
was genau passt nicht?
Stimme Frank zu. Sieht aktuell aus. Oder bist in der Zwischenzeit schon gefahren?
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
das "attr subtype dimmer" ist zb falsch. wieso?
da muss "blindActuator" stehen.
Zitat von: balli1187 am 29 November 2018, 16:15:37
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?
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!
2018-06-17 22:49:15 motor stop:20
Zitat von: frank am 29 November 2018, 16:24:00
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
Zitat von: balli1187 am 29 November 2018, 19:24:06
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.
Aso....
Nein es bleibt alles wie es ist. Als hätte ich keine Aktion durchgeführt.
Gesendet von iPhone mit Tapatalk
mit subType dimmer wird dieser blindActor nie richtig funktionieren.
Zitat von: frank am 29 November 2018, 20:45:12
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
siehe commandref, oder schau ins modul
ZitatIf 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.
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
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.
FHEM hab ich bereits mehrfach neu gestartet. Passiert bei mir auch regelmäßig, da ich wöchentliche Backups der Systems mache.
Spannungsfrei schalten, werde ich morgen mal probieren. Heute Fummel ich nicht mehr am sicherungskasten rum.
Kann in deinem ersten Satz ein Fünckchen Wahrheit stecken??? Ich bin mir ziemlich sicher, dass es als Scherz gemeint war aber ich habe aktuell auch "Probleme" mit unknown Message Meldungen im Log, weil scheinbar jemand in meiner Nachbarschaft mit HMIP angefangen hat.
Gesendet von iPhone mit Tapatalk
fhem restart wegen der subtype umstellung.
es gibt auch neue fw 2.11.
Auch nach Neustart keine Änderung. Gleiches Verhalten, wie eben beschrieben.
Gesendet von iPhone mit Tapatalk
Also es wird quasi beim setzen auf den vorherigen Wert aktualisiert - nicht auf den aktuellen.
Also nur mal dass ich das richtig verstehe
Richtiger Ablauf wäre
Rollo steht auf on (100%)
set rollo 50
Anzeige wechselt auf set_50
dann wieder auf on (oder etwas kleiner 100%)
Rollo fährt , stopt
Anzeige auf 50
das wäre jetzt der richtige Ablauf.
Zitat von: fhem-hm-knecht am 30 November 2018, 13:02:07
Also es wird quasi beim setzen auf den vorherigen Wert aktualisiert - nicht auf den aktuellen.
Also nur mal dass ich das richtig verstehe
Richtiger Ablauf wäre
Rollo steht auf on (100%)
set rollo 50
Anzeige wechselt auf set_50
dann wieder auf on (oder etwas kleiner 100%)
Rollo fährt , stopt
Anzeige auf 50
das wäre jetzt der richtige Ablauf.
Genau, so unerwartet wäre der richtige Ablauf.
Bei mir ist es aber so:
- Rollo steht auf on (100%, richtiger wert, da nach statusRequest gezogen)
- set Rollo 50
- Anzeige wechselt kurz auf set_50, dann wieder auf on und bleibt dort
- Rollo fährt aber die gewünschte Position an
- set Rollo off
- Anzeige wechselt kurz auf set_off
- Eollo fährt gewünschte Position an
- Readings werden aktualisiert auf Wert 50
Gesendet von iPhone mit Tapatalk
Zitat- Rollo steht auf on (100%, richtiger wert, da nach statusRequest gezogen)
- set Rollo 50
- Anzeige wechselt kurz auf set_50, dann wieder auf on und bleibt dort
- Rollo fährt aber die gewünschte Position an
soweit fast ok. Das Rollo sollte anfangen zu fahren - meldet den aktuellen Level (immer noch "on") und sollte die Motorfahrrichgung anzeigen
Was fehlt ist die Statusmeldung nach Stillstand. Du könntest also erst einmal versuchen, ein statusRequest abzusetzen. Hier sollte (nach Stillstand) ein 50% kommen.
Was hast du in autoReadReg stehen? Zumindest ein "8" sollte es schon sein. Dann fragt FHEM nach, wenn es unklar erscheint. Ich empfehle wie immer ein "5".
Wer es abschaltet ist selbst schuld - kann ich nicht helfen.
Zitat von: martinp876 am 02 Dezember 2018, 17:59:35
soweit fast ok. Das Rollo sollte anfangen zu fahren - meldet den aktuellen Level (immer noch "on") und sollte die Motorfahrrichgung anzeigen
Was fehlt ist die Statusmeldung nach Stillstand. Du könntest also erst einmal versuchen, ein statusRequest abzusetzen. Hier sollte (nach Stillstand) ein 50% kommen.
Was hast du in autoReadReg stehen? Zumindest ein "8" sollte es schon sein. Dann fragt FHEM nach, wenn es unklar erscheint. Ich empfehle wie immer ein "5".
Wer es abschaltet ist selbst schuld - kann ich nicht helfen.
Genau so sieht es aus - der Status wird nach Stillstand nicht aktualisiert.
Wie bereits geschrieben, bringt ein statusRequest Abhilfe. Vorher war es jedoch so, dass dies automatisch passierte und bei meinen anderen beiden ist es nach wie vor so. Da will ich auch wieder hin.
Das autoReadReg steht auf "4_reqStatus". Da ich das nicht selbst gesetzt habe, nehme ich mal an, das ist die Standardeinstellung?!
Grüße, Stephan
Sicherung raus und wieder rein, hat das Phänomen behoben.
Kann zu.