Hallo zusammen,
wie schon in einem anderen Thread berichtet, habe ich ein Problem mit zwei Rolladenaktoren der Fa. Peha (PEHA 452 FU-EBIM JR o.T.).
Obwohl offenbar ein "opens"-Befehl von fhem gesenet wird, fahren beide Aktoren den Rolladen hinunter. Das tritt nur sporadisch auf.
Ein Empfangsproblem kann ausgeschlossen werden, da der enocean-rPi in unmittelbarer Nähe der Aktoren steht.
Ein Fehler in den DOIF Anweisungen wurde auch mit Hilfe des Forums nicht erkannt.
Ich habe daraufhin alle DOIFs mit "close" Befehl deaktiviert und nur meine "opens"-Steuerung aktiv gelassen und trotzdem sind bei Rolladen heute morgen um 08:17: wieder geschlossen worden, nachdem sie richtigerweise um 08:00 Uhr geöffnet wurden.
Es kann jetzt m.E. nur noch zwei mögliche Ursachen haben:
1. Es gibt ein generelles Softwareproblem in den Peha Aktoren (das schließt der Hersteller nach Rücksprache aber aus),
2. Fhem steuert den Rolladen mit einen falschen Befehl an (möglicherweise tritt das nur unter bestimmten Umständen auf!)
Hier mal die Konfiguration meines Aktors:
Internals:
CFGFN Config/98-EnOcean.cfg
CHANGED
DEF FFB81080
IODev TCM310
LASTInputDev TCM310
MSGCNT 1505
NAME EG.wz.RO.links
NR 251
NTFY_ORDER 50-EG.wz.RO.links
STATE 0
TCM310_DestinationID FFFFFFFF
TCM310_MSGCNT 1505
TCM310_PacketType 1
TCM310_RSSI -71
TCM310_ReceivingQuality excellent
TCM310_RepeatingCounter 1
TCM310_SubTelNum 9
TCM310_TIME 2016-01-18 08:46:52
TYPE EnOcean
Readings:
2016-01-18 08:46:52 alarm off
2016-01-18 08:46:52 endPosition open
2016-01-18 08:16:50 observeFailedDev
2016-01-18 08:46:52 position 0
2016-01-18 08:46:52 positionMode normal
2016-01-18 08:46:52 serviceOn no
2016-01-18 08:46:52 shutterState stopped
2016-01-18 08:46:52 state open
2015-11-12 16:05:41 teach 4BS teach-in sent
Helper:
Attributes:
IODev TCM310
alias Wohnzimmer Rollade links
angleMax 0
angleMin 0
comMode confirm
comment PEHA 452 FU-EBIM JR o.T.
devStateIcon 100:fts_shutter_100 0:fts_window_2w 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \d.*:fts_window_2w
eep A5-38-08
event-on-change-reading .*
eventMap opens:auf closes:ab
group 452 FU-EBIM
gwCmd blindCmd
manufID 001
observe on
observeCmdRepetition 2
room 98-EnOcean
stateFormat position
subDef FF94C082
subType shutterCtrlState.01
subTypeSet gateway
verbose 3
webCmd auf:ab:stop
Der zweite Aktor ist identisch konfiguriert.
Das DOIF mit dem ich ansteuere:
Internals:
CFGFN Config/01-Wohnzimmer.cfg
DEF ([?switch.di.02.EG.wz.RO.dum] eq "on" and
(([{sunrise_abs("HORIZON=-2",0,"06:30","08:00")}|12345] and
![?state.NRW.Ferien.dum] and [?hl.01.Feiertag:today] eq "none") or
([{sunrise_abs("HORIZON=-2",0,"07:30","08:30")}])))
(set EG.wz.RO.*:FILTER=STATE!=open auf)
DOELSEIF
([switch.di.02.EG.wz.RO.dum] eq "off")
DOELSE
NAME di.02.EG.wz.RO
NR 859
NTFY_ORDER 50-di.02.EG.wz.RO
STATE on
TYPE DOIF
Readings:
2016-01-18 08:16:50 cmd_event timer_2
2016-01-18 08:16:50 cmd_nr 1
2016-01-18 08:16:50 state on
2016-01-18 08:00:00 timer_1_c1 19.01.2016 08:00:00|12345
2016-01-18 08:16:50 timer_2_c1 19.01.2016 08:15:52
Condition:
0 InternalDoIf('switch.di.02.EG.wz.RO.dum','STATE','') eq "on" and ((DOIF_time_once($hash,$hash->{timer}{0},$wday,"12345") and !InternalDoIf('state.NRW.Ferien.dum','STATE','') and ReadingValDoIf('hl.01.Feiertag','today','') eq "none") or (DOIF_time_once($hash,$hash->{timer}{1},$wday,"")))
1 InternalDoIf('switch.di.02.EG.wz.RO.dum','STATE','') eq "off"
Days:
0 12345
Devices:
1 switch.di.02.EG.wz.RO.dum
all switch.di.02.EG.wz.RO.dum
Do:
0:
0 set EG.wz.RO.*:FILTER=STATE!=open auf
1:
0
2:
0
Helper:
globalinit 1
last_timer 2
sleeptimer -1
Internals:
1 switch.di.02.EG.wz.RO.dum:STATE
all switch.di.02.EG.wz.RO.dum:STATE
Itimer:
Readings:
Realtime:
0 08:00:00
1 08:15:52
State:
Time:
0 {sunrise_abs("HORIZON=-2",0,"06:30","08:00")}
1 {sunrise_abs("HORIZON=-2",0,"07:30","08:30")}
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0 1
Attributes:
alias autom. Rolladen öffnen
cmdState on|off|on
devStateIcon .*on:general_an@lightgreen .*off:general_aus@red
do always
group Scripte
icon fts_shutter_up
room 01-Wohnzimmer
sortby 01
Auszug fhem.log:
2016.01.17 07:12:35 3: EnOcean set EI.ss.SA.Licht on
2016.01.17 07:12:35 3: EnOcean set EI.ss.SA.Licht on
2016.01.17 07:12:36 3: EnOcean set EI.ss.SA.Licht on
2016.01.17 07:12:36 3: EnOcean set EI.ss.SA.Licht on
2016.01.17 07:12:37 3: EnOcean set EI.ss.SA.Licht on
2016.01.17 07:14:37 3: EnOcean set EI.ss.SA.Licht off
2016.01.17 08:00:00 3: EnOcean set GH.ss.SA.Licht on
2016.01.17 08:17:45 3: EnOcean set EG.wz.RO.links opens
2016.01.17 08:17:45 3: EnOcean set EG.wz.RO.rechts opens
2016.01.17 08:17:45 3: EnOcean set GA.ss.SA.Licht off
2016.01.17 08:18:45 3: EnOcean set EI.ss.SA.Lichtschranke off
2016.01.17 08:30:00 3: EnOcean set KG.ss.SA.ZirkuPumpe on
Es wäre schön, wenn jemand eine Idee hätte, wie man dem Fehler auf die Schliche kommt. Laut Logs wird definitiv zu jeder Zeit ein "opens" gesendet.
Vielen Dank und Gruß,
Christian
Hallo Christan,
kannst Du das Problem nicht mal mit global verbose 5 loggen? Glaube kaum, dass aufgrund der bisherigen Logs sinnvolle Aussagen möglich sind. Ich behaupte immer noch: Liegt nicht an den EnO-Modulen. Vielleicht erkennt man anhand der ausführlichen Logs dann auch sofort die Ursache.
Gruß, Christian
Hallo Christian,
ich habe, wie oben beschrieben, alle "close"- Befehle in fhem deaktiviert.Und heute, Freitag, fährt das Teil tatsächlich wieder herunter!
Leider habe ich verbose nicht auf 5 stehen...
Zum Spaß (auch wenn er mir inzwischen vergangen ist) habe ich dann mein "open"DOIF so abgeändert, dass nicht auf "sunrise", sondern auf eine Uhrzeit getrigger wird.
([?switch.di.02.EG.wz.RO.dum] eq "on" and
(([{sunrise_abs("HORIZON=-2",0,"06:30","08:00")}|12345] and
![?state.NRW.Ferien.dum] and [?hl.01.Feiertag:today] eq "none") or
([8:57])))
(set EG.wz.RO.*:FILTER=STATE!=open auf)
DOELSEIF
([switch.di.02.EG.wz.RO.dum] eq "off")
DOELSE
Habe das zig mal mit verbose 5 und anderen Zeiten laufen lassen. Ich habe keine Fehlfunktion feststellen können.
Also,
das Problem besteht weiterhin und ich werde am nächsten Donnerstag Abend das verbose 5 mal einschalten....es bleibt ein Rätsel!
Christian
Hallo Christian.
ich habe etwas herausgefunden:
Ich habe gerade diesen Befehl in der Command-Zeile von fhem abgesendet, und der Rolladen führ herunter!!!
set EG.wz.RO.*:FILTER=STATE!=open auf
Ich kann es bisher leider nicht reproduzieren. Und es fuhr auch nur eine Rollade herunter und nicht beide! Ich werde jetzt den Log-Level auf 5 lassen und weiter testen....
Aber eines sollte jetzt klar sein:
Es liegt nicht an meinen DOIFs, sondern hängt tatsächlich mit der Device-Ansteuerung zusammen!
Siehst Du das auch so?
Christian
NACHTRAG:
ich habe es geschafft, hier das Log:
2016.01.22 18:57:57 3: EnOcean set EG.wz.RO.links opens
2016.01.22 18:57:57 5: TCM TCM310 sending ESP3: 55000A000180A507000028FF94C082005A
2016.01.22 18:57:57 5: SW: 55000A000180A507000028FF94C082005A
2016.01.22 18:57:57 5: TCM TCM310 RAW: 5500010002650000
2016.01.22 18:57:57 5: TCM TCM310 RESPONSE: OK
2016.01.22 18:57:57 5: TCM TCM310 RAW: 55000A0701EBA507
2016.01.22 18:57:57 5: TCM TCM310 RAW: 55000A0701EBA507000028FF94C0820104FFFFFFFF4A0016
2016.01.22 18:57:57 4: TCM TCM310 own telegram from FF94C082 blocked.
2016.01.22 18:57:58 3: EnOcean set EG.wz.RO.links opens
2016.01.22 18:57:58 5: TCM TCM310 sending ESP3: 55000A000180A507000028FF94C082005A
2016.01.22 18:57:58 5: SW: 55000A000180A507000028FF94C082005A
2016.01.22 18:57:58 5: TCM TCM310 RAW: 5500010002650000
2016.01.22 18:57:58 5: TCM TCM310 RESPONSE: OK
2016.01.22 18:57:58 5: TCM TCM310 RAW: 55000A0701EBA507
2016.01.22 18:57:58 5: TCM TCM310 RAW: 55000A0701EBA507000028FF94C0820101FFFFFFFF4A00BC
2016.01.22 18:57:58 4: TCM TCM310 own telegram from FF94C082 blocked.
2016.01.22 18:57:59 5: TCM TCM310 RAW: 55000A0701EBA50A
2016.01.22 18:57:59 5: TCM TCM310 RAW: 55000A0701EBA50A008708FFAC62800105FFFFFFFF4A002A
2016.01.22 18:57:59 5: TCM310 dispatch EnOcean:1:A5:0A008708:FFAC6280:01:05FFFFFFFF4A00
2016.01.22 18:57:59 4: EnOcean received via TCM310: EnOcean:1:A5:0A008708:FFAC6280:01:05FFFFFFFF4A00
2016.01.22 18:57:59 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 0A008708 SenderID: FFAC6280 STATUS: 01
2016.01.22 18:57:59 5: Triggering EG.wz.RO.rechts (1 changes)
2016.01.22 18:57:59 5: Notify loop for EG.wz.RO.rechts position: 10
2016.01.22 18:57:59 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.01.22 18:57:59 2: EnOcean set EG.wz.RO.links opens observing EG.wz.RO.links failed
2016.01.22 18:57:59 5: Triggering EG.wz.RO.links (1 changes)
2016.01.22 18:57:59 5: Notify loop for EG.wz.RO.links observeFailedDev: EG.wz.RO.links
2016.01.22 18:57:59 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.01.22 18:58:01 5: TCM TCM310 RAW: 55000A0701EBA514
2016.01.22 18:58:01 5: TCM TCM310 RAW: 55000A0701EBA514008708FFAC62800106FFFFFFFF4A0070
2016.01.22 18:58:01 5: TCM310 dispatch EnOcean:1:A5:14008708:FFAC6280:01:06FFFFFFFF4A00
2016.01.22 18:58:01 4: EnOcean received via TCM310: EnOcean:1:A5:14008708:FFAC6280:01:06FFFFFFFF4A00
2016.01.22 18:58:01 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 14008708 SenderID: FFAC6280 STATUS: 01
2016.01.22 18:58:01 5: Triggering EG.wz.RO.rechts (1 changes)
2016.01.22 18:58:01 5: Notify loop for EG.wz.RO.rechts position: 20
2016.01.22 18:58:01 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.01.22 18:58:04 5: TCM TCM310 RAW: 55000A0701EBA51E
2016.01.22 18:58:04 5: TCM TCM310 RAW: 55000A0701EBA51E008708FFAC62800106FFFFFFFF4A0064
2016.01.22 18:58:04 5: TCM310 dispatch EnOcean:1:A5:1E008708:FFAC6280:01:06FFFFFFFF4A00
2016.01.22 18:58:04 4: EnOcean received via TCM310: EnOcean:1:A5:1E008708:FFAC6280:01:06FFFFFFFF4A00
2016.01.22 18:58:04 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 1E008708 SenderID: FFAC6280 STATUS: 01
2016.01.22 18:58:04 5: Triggering EG.wz.RO.rechts (1 changes)
2016.01.22 18:58:04 5: Notify loop for EG.wz.RO.rechts position: 30
2016.01.22 18:58:04 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000707017AF670
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000707017AF670002C7E463106FFFFFFFF4A000E
2016.01.22 18:58:05 5: TCM310 dispatch EnOcean:1:F6:70:002C7E46:31:06FFFFFFFF4A00
2016.01.22 18:58:05 4: EnOcean received via TCM310: EnOcean:1:F6:70:002C7E46:31:06FFFFFFFF4A00
2016.01.22 18:58:05 5: EnOcean received PacketType: 1 RORG: F6 DATA: 70 SenderID: 002C7E46 STATUS: 31
2016.01.22 18:58:05 4: EnOcean Unknown device with SenderID 002C7E46 and switch telegram, activate learning mode.
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000A0701EBA522
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000A0701EBA522008508FFAC62800105FFFFFFFF4C00C9
2016.01.22 18:58:05 5: TCM310 dispatch EnOcean:1:A5:22008508:FFAC6280:01:05FFFFFFFF4C00
2016.01.22 18:58:05 4: EnOcean received via TCM310: EnOcean:1:A5:22008508:FFAC6280:01:05FFFFFFFF4C00
2016.01.22 18:58:05 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 22008508 SenderID: FFAC6280 STATUS: 01
2016.01.22 18:58:05 5: Triggering EG.wz.RO.rechts (2 changes)
2016.01.22 18:58:05 5: Notify loop for EG.wz.RO.rechts position: 34
2016.01.22 18:58:05 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000707017AF600002C7E462107FFFFFFFF4A009C
2016.01.22 18:58:05 5: TCM310 dispatch EnOcean:1:F6:00:002C7E46:21:07FFFFFFFF4A00
2016.01.22 18:58:05 4: EnOcean received via TCM310: EnOcean:1:F6:00:002C7E46:21:07FFFFFFFF4A00
2016.01.22 18:58:05 5: EnOcean received PacketType: 1 RORG: F6 DATA: 00 SenderID: 002C7E46 STATUS: 21
2016.01.22 18:58:05 4: EnOcean Unknown device with SenderID 002C7E46 and switch telegram, activate learning mode.
2016.01.22 18:58:05 5: TCM TCM310 RAW: 55000A0701EBA522008508FFAC62800105FFFFFFFF4A00B7
2016.01.22 18:58:05 5: TCM310 dispatch EnOcean:1:A5:22008508:FFAC6280:01:05FFFFFFFF4A00
2016.01.22 18:58:05 4: EnOcean received via TCM310: EnOcean:1:A5:22008508:FFAC6280:01:05FFFFFFFF4A00
2016.01.22 18:58:05 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 22008508 SenderID: FFAC6280 STATUS: 01
Habe den Rolladen dann per FT55 gestoppt.
Ich sehe nur 2 (gleiche) Befehle, die Fhem verschickt:
2016.01.22 18:57:57 5: SW: 55000A000180A507000028FF94C082005A
Und 1 Sekunde später noch einmal den Gleichen. Das ist mMn ein Öffnen-Befehl, wie angefordert.
Bin aber bei den Raw-Codes ein wenig aus der Übung, also bitte auf Klaus warten, ob dem noch etwas auffällt.
Gruß, Christian
PS: Bei Edits besteht die Gefahr, dass per Mail Mitlesende Dein Log nicht mitbekommen haben.
Hi Christian,
ok. danke! Dann hoffe ich mal, das Klaus hier mitliest!
Christian
Zitat von: krikan am 22 Januar 2016, 19:58:17
Ich sehe nur 2 (gleiche) Befehle, die Fhem verschickt:
2016.01.22 18:57:57 5: SW: 55000A000180A507000028FF94C082005A
Und 1 Sekunde später noch einmal den Gleichen. Das ist mMn ein Öffnen-Befehl, wie angefordert.
Die Sendebefehle sind in Ordnung!
Hallo zusammen,
Wenn korrekt gesendet wird, die Aktoren aber falsch reagieren, dann haben die wohl einen Softwarefehler in der Firmware!
Allerdings funktionieren sie über die eingekerbten Richtungstaster völlig korrekt!
Kann das damit zusammenhängen fhem hier nicht als Richtungstaster arbeitet?
Inzwischen zeigt ein neu erworbener dritter Aktor die selbe Fehlfunktion mit fhem.
Christian
Zitat von: Spartacus am 23 Januar 2016, 08:42:36
Wenn korrekt gesendet wird, die Aktoren aber falsch reagieren, dann haben die wohl einen Softwarefehler in der Firmware!
Allerdings funktionieren sie über die eingekerbten Richtungstaster völlig korrekt!
Kann das damit zusammenhängen fhem hier nicht als Richtungstaster arbeitet?
Fhem verwendet ein anderes EEP als ein Richtungstaster.
Ich würde "observe" mal abschalten bzw. das "observeInterval" größer machen, als die Laufzeit des Rolloaktors. U. U. stört das erneute Senden eines zweiten gleichen Befehls während der Laufzeit den Aktor. Das sollte normalerweise nichts ausmachen, aber...
Hallo Klaus,
Da habe ich auch schon dran gedacht! Alternativ könnte man auch mit "Position 0"ansteuern,
Wenn ich den Hersteller auf das Problem aufmerksam mache, kann der mit den RAW-Codes etwas anfangen? Dann hat er einen Anhaltspunkt das Fehlverhalten zu zu grenzen...
Denn Umtausch geht wohl nicht mehr!
Christian
Warum sollte es für den Hersteller nützlich sein, sich das Datentelegramm anzusehen, wenn es richtig ist? Es kommt allenfalls auf den Zusammenhang mit dem Empfangszeitpunkt zu dem noch nicht abgeschlossenen Fahrbefehl an.
Ich kann nur nochmals empfehlen, für die Fehlereingrenzung alle überflüssigen Optionen zu entfernen und diese nach und nach einzeln zu testen.
Hi Klaus,
ok, ich hoffe ich habe es richtig verstanden:
- Als erstes werde ich das observe abschalten und prüfen, ob der Fehler wieder auftritt!
- danach "observe" wieder reinnehmen und "observeInterval" z.B. auf 2s erhöhen.
in der aktuellen Situation ist es ja so, dass der Rolladen geöffnet ist und im Abstand von 1s der "auf"-Befehl 2 x gesendet wird. Nach meinem Verständnis kann der Fahrbefehl dürfte nach dem ersten Senden kein Fahrbefehl ausgeführt werden, da der Rolladen bereits in der Endposition ist.
Ist meine Überlegung denn korrekt, dass die Fehlfunktion mit dem Befehl "position 0" bzw. "position 100" ausbleiben könnte, oder mache ich hier einen Gedankenfehler!
Danke und Gruß,
Christian.
Hallo,
habe folgenden Test gemacht:
Beide Rolladen geöffnet in Endposition:
linker Rolladen: observe=off
rechter Rolladen: observe = off
define Test at +*{5}00:00:10 set EG.wz.RO.*:FILTER=STATE!=open auf
Beide Rolladen fahren nach ein paar Ansteuerungen herunter. Ich kann mir nicht vorstellen, dass das Zeitinterval von 10s zu kurz ist
Am "observe" liegt es also nicht! Das Attribut "observeCmdRepetition" habe ich nicht entfernt. Sollte aber keine Auswirkungen haben.
Im fhem log sieht man, das der Befehl nur 1x pro Rolladen gesendet wird:
2016.01.23 17:41:36 3: EnOcean set EG.wz.RO.links opens
2016.01.23 17:41:36 3: EnOcean set EG.wz.RO.rechts opens
2016.01.23 17:41:46 3: EnOcean set EG.wz.RO.links opens
2016.01.23 17:41:46 3: EnOcean set EG.wz.RO.rechts opens
2016.01.23 17:41:56 3: EnOcean set EG.wz.RO.links opens
2016.01.23 17:41:56 3: EnOcean set EG.wz.RO.rechts opens
2016.01.23 17:42:06 3: EnOcean set EG.wz.RO.links opens
2016.01.23 17:42:06 3: EnOcean set EG.wz.RO.rechts opens
2016.01.23 17:42:16 3: EnOcean set EG.wz.RO.links opens
2016.01.23 17:42:16 3: EnOcean set EG.wz.RO.rechts opens
Nachtrag:
das scheint zu funktionieren...
define Test at +*{5}00:00:10 set EG.wz.RO.*:FILTER=position>0 0
Christian
Sorry, das ist mir alles zu viel auf einmal. Warum alles immer gleichzeitig und mit etlichen Zusatzoptionen, wie z. B. FILTER?
1. "nur" set <Name> open und observe ganz ausschalten
2. observeinterval größer als die Gesamtfahrzeit des Rolloaktors wählen, damit immer sichergestellt ist, dass der Aktor bei einem Sendebefehl im Ruhezustand ist. Deine Aktoren werden doch wohl mehr als 2 s von geschlossen bis voll geöffnet brauchen.
Hallo Klaus,
ich habe das jetzt so gemacht, wie Du gesagt hast. Die Rolladen werden nun so angesteuert:
set EG.wz.RO.* opens
Das Aktor setting sieht aktuell bei beiden Geräten so aus:
Internals:
CFGFN Config/98-EnOcean.cfg
CHANGED
DEF FFAC6280
IODev TCM310
LASTInputDev TCM310
MSGCNT 450
NAME EG.wz.RO.rechts
NR 258
NTFY_ORDER 50-EG.wz.RO.rechts
STATE 0
TCM310_DestinationID FFFFFFFF
TCM310_MSGCNT 450
TCM310_PacketType 1
TCM310_RSSI -68
TCM310_ReceivingQuality excellent
TCM310_RepeatingCounter 1
TCM310_SubTelNum 6
TCM310_TIME 2016-01-26 09:13:33
TYPE EnOcean
Readings:
2016-01-26 09:13:33 alarm off
2016-01-26 09:13:33 endPosition open
2016-01-24 08:19:26 observeFailedDev
2016-01-26 09:13:33 position 0
2016-01-26 09:13:33 positionMode normal
2016-01-26 09:13:33 serviceOn no
2016-01-26 09:13:33 shutterState stopped
2016-01-26 09:13:33 state open
2015-11-11 17:48:09 teach 4BS teach-in sent
Helper:
Attributes:
IODev TCM310
alias Wohnzimmer Rollade rechts
angleMax 0
angleMin 0
comMode confirm
comment PEHA 452 FU-EBIM JR o.T.
devStateIcon 100:fts_shutter_100 0:fts_window_2w 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \d.*:fts_window_2w
eep A5-38-08
event-on-change-reading .*
eventMap opens:auf closes:ab
group 452 FU-EBIM
gwCmd blindCmd
manufID 001
observe off
observeCmdRepetition 2
room 98-EnOcean
stateFormat position
subDef FF94C084
subType shutterCtrlState.01
subTypeSet gateway
webCmd auf:ab:stop
Bis gestern Abend gab es auch keinen Fehler! Heute morgen sind beide Rolladen um 08:00 korrekterweise hochgefahren und um 08:07 Uhr wieder herunter, obwohl ein "opens" Befehl gesendet wurde.
Ich habe echt keine Ahnung mehr, was hier abgeht! Laut Log wird der Befehl nur einmalig gesendet. Es gibt auf der Etage einen Repeater, der das Signal vom Server weiterreicht. Den kann ich aber nicht abschalten, da das Ersgeschoss dann nicht mehr im Empfangsbereich des Enocean Servers liegt.
Hier das ungekürzte Log von heute morgen bei verbose=3 (5 habe ich derzeit deaktiviert, kann ich aber gerne noch einmal einschalten und auf den Fehler warten)
2016.01.26 07:56:39 3: EnOcean set EI.ss.SA.Licht on
2016.01.26 07:56:39 3: EnOcean set EI.ss.SA.Licht on
2016.01.26 08:00:00 3: EnOcean set EG.wz.RO.links opens
2016.01.26 08:00:00 3: EnOcean set EG.wz.RO.rechts opens
2016.01.26 08:00:00 3: EnOcean set GH.ss.SA.Licht on
2016.01.26 08:00:01 3: EnOcean set EI.ss.SA.Licht off
2016.01.26 08:05:51 3: EnOcean set EI.ss.SA.Licht on
2016.01.26 08:07:55 3: EnOcean set GA.ss.SA.Licht off
2016.01.26 08:07:55 3: EnOcean set EG.wz.RO.links opens
2016.01.26 08:07:55 3: EnOcean set EG.wz.RO.rechts opens
2016.01.26 08:08:12 3: EnOcean set EI.ss.SA.Licht off
2016.01.26 08:08:55 3: EnOcean set EI.ss.SA.Lichtschranke off
2016.01.26 08:15:00 3: EnOcean set KG.ss.SA.ZirkuPumpe off
Christian
Hallo,
auch auf die Gefahr hin, dass ich mit meinem Problem lästig werde, aber ich habe keine Idee mehr, wo ich noch suchen soll! Das Problem ist immer noch da!
Hier noch einmal das DOIF:
Das erste sunrise schaltet korrekterweise um 08:00. Da ist die Welt noch in Ordnung und der Rolladen fährt hoch und der Rolladen ist in Endposition "open".
Das 2. Sunrise dient als alternative Schaltzeit zu einem späteren Zeitpunkt z.B. an WE und soll den Rolladen auch öffnen. Aber da ist offenbar der Wurm drin. Der DOIF-Code ist richtig, da habe ich im DOIF-Bereich schon nachgefragt!
Internals:
CFGFN Config/01-Wohnzimmer.cfg
DEF ([?switch.di.02.EG.wz.RO.dum] eq "on" and
(([{sunrise_abs("HORIZON=-2",0,"06:30","08:00")}|12345] and
![?state.NRW.Ferien.dum] and [?hl.01.Feiertag:today] eq "none") or
([{sunrise_abs("HORIZON=-2",0,"07:30","08:30")}])))
(set EG.wz.RO.* opens)
DOELSEIF
([switch.di.02.EG.wz.RO.dum] eq "off")
DOELSE
NAME di.02.EG.wz.RO
NR 859
NTFY_ORDER 50-di.02.EG.wz.RO
STATE on
TYPE DOIF
Readings:
2016-01-27 08:06:37 cmd_event timer_2
2016-01-27 08:06:37 cmd_nr 1
2016-01-27 08:06:37 state on
2016-01-27 08:00:00 timer_1_c1 28.01.2016 08:00:00|12345
2016-01-27 08:06:37 timer_2_c1 28.01.2016 08:05:17
Condition:
0 InternalDoIf('switch.di.02.EG.wz.RO.dum','STATE','') eq "on" and ((DOIF_time_once($hash,$hash->{timer}{0},$wday,"12345") and !InternalDoIf('state.NRW.Ferien.dum','STATE','') and ReadingValDoIf('hl.01.Feiertag','today','') eq "none") or (DOIF_time_once($hash,$hash->{timer}{1},$wday,"")))
1 InternalDoIf('switch.di.02.EG.wz.RO.dum','STATE','') eq "off"
Days:
0 12345
Devices:
1 switch.di.02.EG.wz.RO.dum
all switch.di.02.EG.wz.RO.dum
Do:
0:
0 set EG.wz.RO.* opens
1:
0
2:
0
Helper:
globalinit 1
last_timer 2
sleeptimer -1
Internals:
1 switch.di.02.EG.wz.RO.dum:STATE
all switch.di.02.EG.wz.RO.dum:STATE
Itimer:
Readings:
Realtime:
0 08:00:00
1 08:05:17
State:
Time:
0 {sunrise_abs("HORIZON=-2",0,"06:30","08:00")}
1 {sunrise_abs("HORIZON=-2",0,"07:30","08:30")}
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0 1
Attributes:
alias autom. Rolladen öffnen
cmdState on|off|on
devStateIcon .*on:general_an@lightgreen .*off:general_aus@red
do always
group Scripte
icon fts_shutter_up
room 01-Wohnzimmer
sortby 01
Im Anhang noch mal das Log auf verbose 5. Ich kann nicht erkennen, wie der 2. opens-Befehl den Rolladen schließt (im Log ab Zeile 382).
And btw. Ich habe jetzt mehrfach hintereinander diesen Befehl abgesetzt.
define Test at +*{5}00:00:15 set EG.wz.RO.* opens
Damit kann ich bei ausgeschaltetem "observe" keinen Fahrfehler provozieren. Aber halt nur damit!
Kann Zufall sein, oder auch nicht.
Kann es ggf. mit dem enocean-Repeater zu tun haben? Wer kann mir hier noch einen Rat geben?
Christian
Hallo,
hat niemend mehr eine Idee? Dieses einfache DOIF funktioniert nicht.
Rolladen ist geöffnet in Endposition:
Um 09:56 wurde geschaltet, Beide Rolladen blieben geöffnet.
Um 10:00 führen beide Rolladen herunter.
(([09:56|12345] and
![?state.NRW.Ferien.dum] and [?hl.01.Feiertag:today] eq "none") or
([10:00]))
(set EG.wz.RO.* opens)
Christian
Hallo Christian!
Es ist schwierig für mich Dir zu folgen; einfach zu viele Infos.
Hattest Du jetzt alle Tests, die Klaus vorschlägt, gemacht? Das führt nicht zu fehlerfreien Reaktionen der Aktoren? Sie fahren zumindest laut Deinem vorvorletzten Post trotzdem fehlerhaft!?
Ich verstehe alle Deine Aussagen bisher so, dass es nicht am EnO-Modulen liegt, also beim Aktor suchen.
Hast Du die Aktoren mal resetet und neu angelernt? Keine Besserung?
Repeater können mMn nicht die Ursache sein.
Sorry, Christian
Hallo Krikan,
danke für Dein Feedback.
Ja, ich habe alle Tests gemacht, die Klaus empfohlen hat und die entsprechenden Testszenarien in meinen Posts berichtet.
Es bringt leider nichts. Die Rolladen fahren bei einem "opens" - Befehl sporadisch herunter. Auch der alternative Befehl "position 0" führt zu dem Ergebnis, dass teilweise ein "closes" -Befehl verstanden wird. Ich habe bereits einen neuen Aktor bestellt und angelernt. Auch dieser zeigt das gleiche Phänomen.
Es gibt m.E. nur zwei Möglichkeiten:
1. Aktoren haben einen generellen Softwarefehler
2. Fehler im enocean Modul oder Inkompatibilität zu den peha Aktoren.
Wenn Punkt 2 ausgeschlossen werden kann, dann muss ich mit dem Hersteller in Diskussion gehen. Dazu muss ich aber wissen, bzw. beweisen, dass fhem hier korrekt arbeitet. Dazu wäre es gut zu wissen welche Befehle fhem an die Aktoren schickt, damit er das im Labor nachstellen kann.
FT55-Taster arbeiten übrigens einwandfrei!
Eine Rückgabe der Aktoren wird wohl nur möglich sein, wenn der Hersteller seinen Fehler erkennt, aber so wie es aussieht, habe ich die Kohle wohl in den Sand gesetzt!
Christian
Hallo Christian!
Zitat von: Spartacus am 28 Januar 2016, 11:11:33
FT55-Taster arbeiten übrigens einwandfrei!
Das beweist leider nichts, da FHEM mit anderem EEP ansteuert.
Zitat
1. Aktoren haben einen generellen Softwarefehler
2. Fehler im enocean Modul oder Inkompatibilität zu den peha Aktoren.
1. ist möglich.
Ehrlicherweise kann ich aber auch 2. nicht definitiv ausschließen; auch wenn ich es nicht erkenne.
Da ich den Aktor aus Dir bekannten Gründen nicht mehr einsetze, kann ich bei der Analyse leider nicht praktisch helfen.
Um 2. auszuschließen, kannst Du Dir das genutzte EEP http://www.enocean-alliance.org/eep/ "Blind Central Command" mal anschauen und mit den versandten Telegrammen vergleichen. Vielleicht siehst Du ein Problem und kannst Lösungen testen bzw. experimentierst einfach mit verschiedenen Telegrammvarianten, die Dir sinnvoll erscheinen. Anders habe ich damals auch nicht getestet.
Ansonsten fällt mir nur ein:
Wenn ich alles richtig verstehe, fährt der Aktor doch nur (fälschlich) herunter, wenn er oben ist und Du schickst noch einen opens-Befehl. Also musst Du dies vermeiden. Das würde ich aber sowieso grundsätzlich vermeiden und sollte auch mit DOIF realisierbar sein (Damian fragen).
Gruß, Christian
hallo Krikan,
danke für Dein ausführliches Feedback.
Ich verstehe noch nicht ganz, wie ich mit den Telegrammen in fhem spielen kann. Wie stelle ich das konkret ein? Ich nehme an über SubType und SubTypeSet und mit Hilfe der Doku in der Commandref!
Ich habe parallel bei peha ein Support-Ticket aufgemacht, das geht jetzt an die Entwickler und man will mich zurückrufen. Mal gucken, ob ich denen etwas sinnvolles erzählen kann. Man hat mir auch angeboten vorbeizukommen um sich die Sache vor Ort anzusehen. Ist nur doof, da ich den Fehler nicht sicher provozieren kann.
ZitatAnsonsten fällt mir nur ein:
Wenn ich alles richtig verstehe, fährt der Aktor doch nur (fälschlich) herunter, wenn er oben ist und Du schickst noch einen opens-Befehl. Also musst Du dies vermeiden. Das würde ich aber sowieso grundsätzlich vermeiden und sollte auch mit DOIF realisierbar sein (Damian fragen).
Das kann ich gar nicht genau sagen ob das immer zutrifft. In allen Fällen war es bislang so, dass der Rolladen in der Endposition war. Das wäre ein neuer Ansatzpunkt.
Ich bleibe am Ball und hoffe weiter auf Eure und Deine Unterstützung.
Ach noch was: Wie interpretiere ich die gesendeten Befehle korrekt? Ich nehme an, das der "opens"-Befehl "55000A000180A507000028FF94C082005A" codiert ist.
Danke und Gruß,
Christian
Hallo,
peha war schnell! Haben bereits zurückgerufen. Es sind offenbar Probleme mit diesem Verhalten bekannt. Man schickt mir nun einen Aktor mit einer brandneuen Firmware zu. Das soll ich mal mit fhem testen und Feedback geben....warten wir das mal ab!
Christian
Zitat von: Spartacus am 28 Januar 2016, 12:56:51
peha war schnell! Haben bereits zurückgerufen. Es sind offenbar Probleme mit diesem Verhalten bekannt.
Na, dann warten wir mal auf die "brandneue" Firmware und hoffen, dass es damit gelöst ist. Du hattest doch bereits die "neue" 24er Firmware !?
Halte uns bitte auf dem Laufenden.
Hallo,
ja, die 24er hatte ich drauf. Es gibt aber bereits eine 28er. Die ist noch nicht in der Produktion, aber freigegeben und soll viele Fehler beheben.
Ich hoffe mal, dass "mein" Fehler dann behoben ist...das Paket soll heute noch raus gehen.
Bis bald,
Christian
...aber trotzdem würde mich mal interessieren, wie sich die gesendeten Daten zusammensetzten.
55000A000180A507000028 FF94C084 0024
|Aktoradresse|????
Christian
Serielles Protokoll siehe http://www.enocean.com/esp
Hallo Klaus, hallo Christian,
ich habe Kontakt zu den peha Entwicklern. Der Aktor mit der neuen FW ist eingebaut, zeigt aber andere Schwächen, die es zusammen mit peha zu lösen gibt. Die Positionserkennung ist jetzt nur noch in einem bestimmten Modus (Modus 2) möglich und unterstützt zwei Betriebsarten (blind+shutter).
In der Betriebsart "shutter" funktioniert die Positionierung einwandfrei. In der Betriebsart "blind" werden nur die "auf" und "ab" Telegramme akzeptiert.
Ich peha zwar mein fhem-log geschickt, aber so richtig kommen sie nicht damit klar.
Bevor ich als Laie nun eine falsche Aussagen treffe, möchte ich Dich/Euch um Unterstützung bitten.
Peha möchte genau verstehen, welche Standard-Telegramme für die Positionsansteuerung bzw. für "auf" und "ab" gesendet werden.
Kannst Du dazu etwa sagen, oder was kann ich hier am Besten referenzieren?
Danke und Gruß,
Christian
Ich verstehe nicht, warum ein log nicht die notwendigen Informationen liefert:
2016.02.03 15:15:18 3: EnOcean set test9 position
2016.02.03 15:15:18 4: EnOcean test9 sent PacketType: 1 RORG: A5 DATA: 07005A4A SenderID: xxxxxxxx STATUS: 00 ODATA:
2016.02.03 15:15:27 3: EnOcean set test9 position
2016.02.03 15:15:27 4: EnOcean test9 sent PacketType: 1 RORG: A5 DATA: 0732004A SenderID: xxxxxxxx STATUS: 00 ODATA:
2016.02.03 15:15:30 3: EnOcean set test9 position
2016.02.03 15:15:30 4: EnOcean test9 sent PacketType: 1 RORG: A5 DATA: 0764DA4A SenderID: xxxxxxxx STATUS: 00 ODATA:
2016.02.03 15:15:40 3: EnOcean set test9 opens
2016.02.03 15:15:40 4: EnOcean test9 sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: xxxxxxxx STATUS: 00 ODATA:
2016.02.03 15:15:46 3: EnOcean set test9 closes
2016.02.03 15:15:46 4: EnOcean test9 sent PacketType: 1 RORG: A5 DATA: 07000038 SenderID: xxxxxxxx STATUS: 00 ODATA:
Das DATA-Feld enthält die Zeichensequenz, wie sie im EEP A5-38-08 (Profil "gateway/blindCmd") beschrieben ist. Ich finde, das ist eindeutig und nachvollziehbar.
Hallo Klaus,
nochmals vielen Dank für Deine Hilfe. Wir sind immer noch dran, den Fehler zu finden, kommen aber nicht wirklich weiter.
Der "auf", "ab" und "position" Befehl, der gesendet wird, wurde auch von peha als korrekt bestätigt. Aber leider fährt der Rolladen immer noch bei dem "auf" Befehl herunter.
Ich versuche gerade das Quittierungs-Signal aus dem Datenstrom zu filtern.
Lese ich das so korrekt?
Sendebefehl:
1.Zeile fhem Befehl
2.Zeile Sendepakete im Klartext
3.Zeile Sendebefehl im RAW-Format
2016.02.04 21:16:41 3: EnOcean set EG.wz.RO.rechts opens
2016.02.04 21:16:41 4: EnOcean EG.wz.RO.rechts sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C084 STATUS: 00 ODATA:
2016.02.04 21:16:41 5: TCM TCM310 sending ESP3: 55000A000180A507000028FF94C0840024
Quittung:
1.Zeile Empfangspaket im RAW-Format
2.Zeile Empfangspaket vom Aktor im Klartext
2016.02.04 21:16:41 4: EnOcean received via TCM310: EnOcean:1:A5:00008908:FFAC6280:01:06FFFFFFFF4600
2016.02.04 21:16:41 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FFAC6280 STATUS: 01
Wenn ich das korrekt interpretiere, dann quittiert der Aktor auch den korrekten Fahrbefehl. In der Praxis jedoch fuhr der Rolladen herunter.
Danke für´s Feedback,
Christian
Hm,
irgendwie stimmt das noch nicht ganz. Es werden offenbar zwei Sequenzen vom Aktor gesendet.
DATA: 00008908
und zwei Zeilen tiefer
DATA: 00008608
Was quittiert der Aktor da mit 8908 bzw. 8608
Hier noch einmal die gefilterte Testsequenz 2:
2016.02.04 21:16:41 5: exec at command Test
2016.02.04 21:16:41 5: Cmd: >set EG.wz.RO.rechts opens<
2016.02.04 21:16:41 3: EnOcean set EG.wz.RO.rechts opens
2016.02.04 21:16:41 4: EnOcean EG.wz.RO.rechts sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C084 STATUS: 00 ODATA:
2016.02.04 21:16:41 5: TCM TCM310 sending ESP3: 55000A000180A507000028FF94C0840024
2016.02.04 21:16:41 5: SW: 55000A000180A507000028FF94C0840024
2016.02.04 21:16:41 5: redefine at command Test as +*{3}00:00:15 set EG.wz.RO.rechts opens
2016.02.04 21:16:41 5: Triggering Test (1 changes)
2016.02.04 21:16:41 5: Notify loop for Test Next: 21:16:56
2016.02.04 21:16:41 5: TCM TCM310 RAW: 550001000265000055000A0701EBA507000028FF94C0840103FFFFFFFF4600E855000A0701EBA500008908FFAC62800106FFFFFFFF4600C955000A0701EBA500008608FFAC62800106FFFFFFFF460041
2016.02.04 21:16:41 5: TCM TCM310 RESPONSE: OK
2016.02.04 21:16:41 4: TCM TCM310 own telegram from FF94C084 blocked.
2016.02.04 21:16:41 5: TCM310 dispatch EnOcean:1:A5:00008908:FFAC6280:01:06FFFFFFFF4600
2016.02.04 21:16:41 4: EnOcean received via TCM310: EnOcean:1:A5:00008908:FFAC6280:01:06FFFFFFFF4600
2016.02.04 21:16:41 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FFAC6280 STATUS: 01
2016.02.04 21:16:41 5: TCM310 dispatch EnOcean:1:A5:00008608:FFAC6280:01:06FFFFFFFF4600
2016.02.04 21:16:41 4: EnOcean received via TCM310: EnOcean:1:A5:00008608:FFAC6280:01:06FFFFFFFF4600
2016.02.04 21:16:41 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 00008608 SenderID: FFAC6280 STATUS: 01
2016.02.04 21:16:41 5: Triggering EG.wz.RO.rechts (3 changes)
2016.02.04 21:16:41 5: Notify loop for EG.wz.RO.rechts endPosition: not_reached
2016.02.04 21:16:41 5: rg.01.EG.wz.RO: not on any display, ignoring notify
2016.02.04 21:16:42 5: TCM TCM310 RAW: 55000A0701EBA500
2016.02.04 21:16:42 5: TCM TCM310 RAW: 55000A0701EBA500008908FFAC62800107FFFFFFFF470003
2016.02.04 21:16:42 5: TCM310 dispatch EnOcean:1:A5:00008908:FFAC6280:01:07FFFFFFFF4700
2016.02.04 21:16:42 4: EnOcean received via TCM310: EnOcean:1:A5:00008908:FFAC6280:01:07FFFFFFFF4700
2016.02.04 21:16:42 4: EnOcean EG.wz.RO.rechts received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FFAC6280 STATUS: 01
2016.02.04 21:16:42 5: Triggering EG.wz.RO.rechts (3 changes)
2016.02.04 21:16:42 5: Notify loop for EG.wz.RO.rechts endPosition: open
2016.02.04 21:16:42 5: rg.01.EG.wz.RO: not on any display, ignoring notify
Christian
Das ist EEP A5-11-03 (Seite 64,65 in obigem Dokument). Für meine eigene Übung mal übersetzt (hoffe es passt):
00008908
00: Position 0
00: Angle 0
89: binär-> 10001001 = Position 0, Angle 0, blind fully open, blind ist stopped
00008608
00: Position 0
00: Angle 0
86: binär-> 10000110 = Position 0, Angle 0, no endposition reached, blind opens
Christian,
Danke Di!. Du musst entschuldigen, für mich ist das als Technil-Laie sehr schwer mich indem Dokument zurechtzufinden und es nachzuvollziehen. Deine Anleitung hilft dabeiseht!
Zum Thema:
Die Quittierung aber Öle zeigen demnach, dass der Aktor die richtigen Befehle empfängt und quittiert, aber dennoch teilweise in die falsche Richtung fährt. Komisch an der ganzen Sache ist nur, dass alle Aktoren gleichermaßen reagieren. Das heißt auch im Fehlerfall.
Peha hat inzwischen einen Versuchsaufbau gemacht und sie versuchen, den Fehler nachzustellen! Sind sehr bemüht, aber bislang gibt es keinen Erfolg! Ich bleibe dran...(habe ja auch keine Chance, da ich die Dinger sonst verschrotten könnte!)
Christian
Zitat von: Spartacus am 05 Februar 2016, 07:42:16
Zum Thema:
Die Quittierung aber Öle zeigen demnach, dass der Aktor die richtigen Befehle empfängt und quittiert, aber dennoch teilweise in die falsche Richtung fährt. Komisch an der ganzen Sache ist nur, dass alle Aktoren gleichermaßen reagieren. Das heißt auch im Fehlerfall.
Das wundert mich auch. Ich kann aber, wie geschrieben, keinen Fehler in den Telegrammen und Deinen Logs feststellen. Gleiches Reagieren aller Aktoren bedeutet auch, dass es einen grundsätzlches Problem ist; also hilft das bei der Suche nach der Ursache. Hast Du eine saubere Testumgebung; d.h. nur einen Aktor eingebunden oder testet Du das aus Deinem normalen Produktiv-FHEM? Letzteres fände ich nicht so optimal.
Die letzte 08 in Deinen Telegrammen habe ich nicht "übersetzt" und müsstest Du Dir mal anschauen. Evtl. hat der Positionsmodus "normal/invers" Wechselwirkungen; hier sehe ich bei Dir aber auch kein Problem.
Hat PEHA Dir denn bestätigt, dass Befehl und Quittierung in FHEM im Fehlerfall korrekt sind?
Gruß, Christian
Hallo Christian,
nein ich habe leider keine separate Testumgebung. Dafür benötige ich dann einen weiteren Pi mit enocean Stick und einen Rolladenmotor. Den Motor habe ich zwar, allerdings schaltet der willkürlich, da dieser ohne Welle keinen Endabschaltpunkt findet.
Ich habe einen weiteren Aktor mit 24er FW. Den werde ich mit zwei Glühlampen bestücken und mein Testscript laufen lassen. Allerdings muss ich dafür wohl auch mein prod. System nehmen.
define Test at +*{5}00:00:15 set EG.wz.RO.rechts opens
Damit kann ich den Fehler ja eindeutig reproduzieren. Nicht beim ersten durchlauf, aber wenn ich den Befehl oben 2-3 Mal absetze, kommt er garantiert.
Peha hat bislang nur die Sendebefehle bestätigt. Die Empfangsprotokolle habe ich noch nicht weitergeleitet. Ich war mir nicht sicher, ob ich die richtigen Daten extrahiert habe. Nochmals danke dafür!
Christian
Zitat von: krikan am 04 Februar 2016, 22:36:06
00008908
89: binär-> 10001001 = Position 0, Angle 0, blind fully open, blind ist stopped
00008608
86: binär-> 10000110 = Position 0, Angle 0, no endposition reached, blind opens
Sehe gerade, dass ich obiges falsch kopiert habe. So sollte es richtig sein:
0000890889: binär-> 10001001 =
Position available, Angle not available, no error, blind fully open, blind is stopped
0000860886: binär-> 10000110 =
Position available, Angle not available, no error, no endposition reached, blind opens
Hallo Krikan,
nochmals Besten Dank. Mit Deiner Anleitung habe ich die Datenbytes nachvollziehen können. Wenn ich das Byte "DB0" richtig übersetze, dann bedeutet "08" das es sich um ein Data Telegramm handelt und nicht um ein "LRN" Telegramm.
BTW.
Hast Du eine Idee, wie ich im Loglevel 5 nur das Log des betroffenen Enocean Device monitoren kann? In der fhem.log ist sehr viel los und man kann das nur schwer auseinander halten.
Chrstian
ZitatWenn ich das Byte "DB0" richtig übersetze, dann bedeutet "08" das es sich um ein Data Telegramm handelt und nicht um ein "LRN" Telegramm.
Ja. Um genau zu sein auch noch: serivce mode = normal mode und position mode = normal mode
ZitatHast Du eine Idee, wie ich im Loglevel 5 nur das Log des betroffenen Enocean Device monitoren kann?
verbose 5 nicht am TCM-Device, sondern nur am betroffenen Aktor-Device setzen. Die von Dir als "Klartext" bezeichneten Telegramme werden dann nur von diesem Device geloggt. Rest solltest Du eigentlich nicht brauchen, wenn es keine Seiteneffekte gibt.
Gruß, Christian
Hallo zusammen,
so richtig haben meine Tests nichts gebracht. Irgendwie will der Aktor keine Telegramme mehr senden. Die Positionierungswerte bleiben aus.
2016.02.07 18:18:22 3: EnOcean set EG.wz.RO.Test opens
2016.02.07 18:18:22 4: EnOcean EG.wz.RO.Test sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.07 18:18:25 3: EnOcean set EG.wz.RO.Test closes
2016.02.07 18:18:25 4: EnOcean EG.wz.RO.Test sent PacketType: 1 RORG: A5 DATA: 07000038 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.07 18:18:40 3: EnOcean set EG.wz.RO.Test opens
2016.02.07 18:18:40 4: EnOcean EG.wz.RO.Test sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.07 18:19:01 5: EnOcean EG.wz.RO.Test EnOcean_Get command: EG.wz.RO.Test ?
Fhem meldet "EnOcean_Get command: EG.wz.RO.Test ?[". weiß jemand was das bedeutet?
Danke Christian
Hallo,
Kommando zurück! Irgendwie hat sich fhem wohl verschluckt.
Aktor gelöscht, neu eingelernt und die Werte kommen wieder. Jetzt muss ich nur noch den Fehler provozieren...
Christian
Hallo,
ich habe nun das ganze Wochenende diverse Tests an einer kleinen Testumgebung im Keller durchgeführt und einen separaten neuen Rademacher Rolladenmoter sowie zwei verschiedenfarbige Glühlampen mit separater fhem-Ansteuerung getestet. Ich konnte den Fehler sowohl mit dem neuen Motor als auch mit den Glühlampen nachstellen.
Heute habe ich Post von peha bekommen. Auch dort konnte der Fahrfehler inzwischen reproduziert werden. Bislang gibt es aber noch keine Lösung. Die Entwicklung arbeitet daran. Lustigerweise quittiert der Aktor bei falscher Fahrt die von fhem korerkt gesendetn Fahrbefehle (die Tests beim Hersteller bestätigen dies auch).
Allerdings habe ich noch eine Frage zu dem letzten Log mit verschiedenen Testbefehlen, welches ich hier gefiltert anfüge:
Logfile-Auszug gefiltert, peha-Aktor mit FW 28
#
#
# sende "opens" in Endstellung "open"
#
2016.02.08 18:33:09 3: EnOcean set EG.wz.RO.Keller opens
2016.02.08 18:33:09 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:09 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:10 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
#
# sende "opens" in Endstellung "open"
#
2016.02.08 18:33:11 3: EnOcean set EG.wz.RO.Keller opens
2016.02.08 18:33:11 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:11 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
#
# close
#
2016.02.08 18:33:31 3: EnOcean set EG.wz.RO.Keller closes
2016.02.08 18:33:31 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000038 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:31 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:31 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008B08 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:31 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 01008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:31 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 05008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:32 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 0A008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:32 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 0F008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:33 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 14008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:33 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 19008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:34 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 1E008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:34 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 23008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:35 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 28008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:36 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2D008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:36 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 32008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:37 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 37008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:38 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 3C008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:38 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 41008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:39 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 46008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:40 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 4B008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:41 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 50008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:42 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 55008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:43 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 5A008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:44 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 5F008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:45 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 64008D08 SenderID: FF9E0780 STATUS: 00
#
# open
#
2016.02.08 18:33:46 3: EnOcean set EG.wz.RO.Keller opens
2016.02.08 18:33:46 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:47 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 64008D08 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:47 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 64008E08 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:47 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 63008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:47 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 5F008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:48 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 5A008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:49 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 55008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:50 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 50008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:51 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 4B008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:52 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 46008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:53 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 41008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:54 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 3C008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:54 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 37008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:55 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 32008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:56 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2D008608 SenderID: FF9E0780 STATUS: 00
#
# Stop
#
2016.02.08 18:33:56 3: EnOcean set EG.wz.RO.Keller stop
2016.02.08 18:33:56 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000018 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:56 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2C008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:56 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2C008508 SenderID: FF9E0780 STATUS: 00
#
# Open
#
2016.02.08 18:33:57 3: EnOcean set EG.wz.RO.Keller opens
2016.02.08 18:33:57 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000028 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:33:58 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2C008508 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:58 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 2C008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:58 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 28008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:59 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 23008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:33:59 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 1E008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:00 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 19008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:00 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 14008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:01 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 0F008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:01 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 0A008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:02 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 05008608 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:02 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008A08 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:02 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:05 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
#
# sende Position 2%
#
2016.02.08 18:34:10 3: EnOcean set EG.wz.RO.Keller position
2016.02.08 18:34:10 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 0702004A SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:34:10 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
2016.02.08 18:34:10 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008908 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:10 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 00008B08 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:10 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 01008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:10 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 02008508 SenderID: FF9E0780 STATUS: 00
#
# sende Position 6%
#
2016.02.08 18:34:44 3: EnOcean set EG.wz.RO.Keller position
2016.02.08 18:34:44 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 0707004A SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:34:45 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
2016.02.08 18:34:45 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 02008508 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:45 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 02008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:45 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 05008708 SenderID: FF9E0780 STATUS: 00
2016.02.08 18:34:45 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 06008508 SenderID: FF9E0780 STATUS: 00
#
# sende "closes" in Endstellung "closed"
#
2016.02.08 18:40:07 3: EnOcean set EG.wz.RO.Keller closes
2016.02.08 18:40:07 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000038 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:40:08 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
2016.02.08 18:40:08 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 64008D08 SenderID: FF9E0780 STATUS: 01
#
# sende "closes" in Endstellung "closed"
#
2016.02.08 18:40:11 3: EnOcean set EG.wz.RO.Keller closes
2016.02.08 18:40:11 4: EnOcean EG.wz.RO.Keller sent PacketType: 1 RORG: A5 DATA: 07000038 SenderID: FF94C086 STATUS: 00 ODATA:
2016.02.08 18:40:11 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
2016.02.08 18:40:11 4: EnOcean EG.wz.RO.Keller received PacketType: 1 RORG: A5 DATA: 64008D08 SenderID: FF9E0780 STATUS: 01
Die Zeile
2016.02.08 18:34:10 5: EnOcean EG.wz.RO.Keller EnOcean_Get command: EG.wz.RO.Keller ?
taucht hier öfters auf. Was genau bedeutet das hier?
Danke und Gruß,
Christian
P.S. Der Aktor hat in diesem Test keinen Fahrfehler gezeigt.
Hallo Christian,
schön, dass die Ursache (Aktorfehler) eingegrenzt und bestätigt ist. Könntest Du bitte in Deinem Eröffnungsbeitrag den Titel des Thema abändern. Das liest sich bisher nach Fehler in FHEM, was ja definitiv nicht zutrifft. Danke.
Die Logzeile mit ? gibt mMn an, dass FHEM die zur Verfügung stehenden get-Kommandos des angegebenen Gerätes ermittelt. Detailinfos dazu müsste ein Developer geben, wenn Du die brauchst.
Gruß, Christian
Hallo,
alles klar! Habe ich geändert:Hier noch eine Information von peha (falls nicht sowieso Standard/bekannt):
- Die Rückmeldung des Aktors erfolgt nach dem EEP A5-11-03.
- Bei nur kleinen Änderungen der Positionen reagiert der Aktor noch nicht. Die Werte müssen in Abhängigkeit von der Laufzeit
ca. 5% auseinander liegen.
Das heißt dann wohl auch, dass man nur in 5% Schritte ansteuern sollte. Allerdings habe ich auch kleinere Werte ansteuern können, so wie im obigen Log zu sehen ist.
Christian
Hallo,
ich möchte zu diesem Thema ein kleines Update geben.
Nach mehr als einem Jahr und vielen, vielen Mails mit dem peha Support sieht es aktuell so aus:
- Peha hat die HW der Aktoren komplett überarbeitet
- Prototypen laufen seit ca. 2 Monaten bei mir an zwei Rolladen
- der Fehler (unbabsichtigter Richtungswechsel) ist behoben
- Die derzeit verbaute FW hat noch einen Bug, d.h. die Positionen werden nicht korrekt übermittelt (Position bei Endabschaltung >100%, dadurch keine genaue Positionierung möglich)
Anfang Januar habe ich von peha die Info bekommen, dass das Problem mit der Positionierung inzwischen gefixt ist und die FW in Kürze freigegeben werden soll. Ich werde berichten...
Christian