Peha 452 FU-EBIM JR o.T Anlernprobleme

[krikan]

Hallo Christian,
bist Du sicher, dass das Problem bei EnOcean bzw. dem Aktor zu suchen ist?
Ich würde eher auf ein DOIF-Problem tippen und da bin ich mir nicht sicher, ob Damian hier mitliest. Bei DOIF bin ich als Alt-FHEMler (noch) raus...
Gruß, Christian

[Spartacus]

Hi krikan,
das kann nicht an dem DOIF liegen, da nirgends in dem DOIF ein "shutter close"-Befehl verarbeitet ist. Das DOIF ist nur für das Öffnen verantwortlich. Deshalb gehe ich davon aus, dass es ein Protokollproblem ist. Der Aktor selber kann es auch nicht sein, da beide Aktoren den gleichen "shutdown" - Befehl verstanden haben.
Und außerdem kommt das ja auch nur sehr selten vor! Ist aber trotzdem ärgerlich, wenn man sich darauf nicht verlassen kann.

Christian

[Spartacus]

Hallo,
ich noch einmal!
Ich habe hier mal einen Auszug aus meinem Log von heute morgen. Ich verstehe nicht ganz, warum der Befehl hier mehrfach gesendet wurde. Liegt das an dem Attribut "observeCmdRepetition=2"? Und was bedeutet dann "observing EG.wz.RO.links failed"?  Hat der Aktor hier nicht quittiert und der Befehl "opens" ist nicht angekommen? Fakt ist, dass der Rolladen auch nicht hochgefahren ist.

Ich habe den linken Rolladen dann um 8:47 Uhr per Taster hochgefahren. im direkten Rolladen-Log finde ich den passenden Eintrag. Allerdings nichts in der fhem.cfg. Das ist doch sehr komisch, oder? Was ist hier los?

Code Auswählen Erweitern

2016.01.10 08:22:49 3: EnOcean set EG.wz.RO.links opens
2016.01.10 08:22:49 3: EnOcean set EG.wz.RO.rechts opens
2016.01.10 08:22:49 3: EnOcean set GA.ss.SA.Licht off
2016.01.10 08:22:50 3: EnOcean set EG.wz.RO.links opens
2016.01.10 08:22:51 3: EnOcean set EG.wz.RO.links opens
2016.01.10 08:22:52 2: EnOcean set EG.wz.RO.links opens observing EG.wz.RO.links failed

Spartacus

[krikan]

Hallo!

Du musst das doch genauso am Device eingestellt haben, da das mWn nicht automatisch geschieht. Beschrieben ist das in fhem.de/commandref#EnOcean unter Observing Functions. Da ich Deine Definition nicht kenne, kann ich nur vermuten, dass Du keine Aktion nach den gescheiterten Versuchen festgelegt hast.

Also: Kommando wurde von FHEM laut Deinen Einstellungen 2x wiederholt, da jeweils kein ACK kam. Nach dem 3 gescheiteren Versuch wurde aufgegeben und geloggt. Ursache: Aktor hat Signal nicht empfangen (Funkprobleme,...)

Allerdings nichts in der fhem.cfg.

Verstehe den Zusammenhang nicht. Was soll in der fhem.cfg stehen?

Gruß, Christian

[Spartacus]

Hallo Christian,
hier mal die Konfig. Ja, ich habe das Attribut bewußt gesetzt, mir war aber nicht klar, dass das so in der fhem.cfg protokolliert wird. Dann ist alles klar.

Was ich mit dem 2. Bsp. meinte ist, dass der Schaltbefehl über den enocean Taster eigentlich das Herauffahren der linken Rollade um 08:47 in der fhem.cfg hätte protokollieren müssen. Da gibt es aber keinen solchen Eintrag. Nur in der "EG.wz.RO.links.log". Das verwundert mich. Sonst werden die Befehle alle parallel in der fhem.cfg mitgeloggt.

Die Empfangsprobleme kann ich nicht nachvollziehen, da der Aktor für die rechte Rollade direkt neben dem linken steckt (2m). Deshalb fürchte ich, dass der Aktor ne Macke hat, da erschon öfter dieses Verhalten gezeigt hat. Peha sagte mir schon, dass sie nicht mehr direkt tauschen....da muss ich wohl über den Händler gehen und der schickt nichts im Voraus....also erst einmal einen Neuen kaufen und die Möhre umtauschen...

Allerdings erklärt das immer noch nicht, warum beide Aktoren einen "opens"-Befehl als "close" verstanden haben...

Code Auswählen Erweitern


Internals:
   CFGFN      Config/98-EnOcean.cfg
   CHANGED
   DEF        FFB8xxxx
   IODev      TCM310
   LASTInputDev TCM310
   MSGCNT     558
   NAME       EG.wz.RO.links
   NR         251
   NTFY_ORDER 50-EG.wz.RO.links
   STATE      0
   TCM310_DestinationID FFFFFFFF
   TCM310_MSGCNT 558
   TCM310_PacketType 1
   TCM310_RSSI -74
   TCM310_ReceivingQuality excellent
   TCM310_RepeatingCounter 1
   TCM310_SubTelNum 5
   TCM310_TIME 2016-01-10 21:23:29
   TYPE       EnOcean
   Readings:
     2016-01-10 21:23:29   alarm           off
     2016-01-10 21:23:29   endPosition     open
     2016-01-10 10:04:16   observeFailedDev
     2016-01-10 21:23:29   position        0
     2016-01-10 21:23:29   positionMode    normal
     2016-01-10 21:23:29   serviceOn       no
     2016-01-10 21:23:29   shutterState    stopped
     2016-01-10 21:23:29   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     FF94xxxx
   subType    shutterCtrlState.01
   subTypeSet gateway
   verbose    3
   webCmd     auf:ab:stop
Christian

[krikan]

Hallo Christian,
Ok, laut Deinem list hat FHEM genau das getan, was es bei fehlendem Bestätigungstelegramm machen sollte: insgesamt 3 Sendeversuche und danach aufgehört (s.o.).
Mit fhem.cfg meinst Du vermutlich das fhem.log!? Was, wie geloggt wird, liegt an Deinen Einstellungen, sollte aber doch nicht mit dem eigentlichen Problem zusammenhängen.
Aktorprobleme/-macken könnten natürlich sein. Ich habe auch einen PEHA EBIM, der eine zeitlang sporadisch nicht reagierte und wollte den schon austauschen. Nachdem ich den durch Sicherung raus mal stromlos gemacht hatte, ist das Problem weg.
Zum obigen "close" habe ich auch keine Ideen. Ich kann mir beim bestenm Willen nicht vorstellen, dass FHEM hier ohne entsprechenden Code Befehle verschickt...
Gruß, Christian

[Spartacus]

Hallo Christian,
tja, heute morgen fuhr der linke Rolladen wieder nicht hoch. Wieder wurde der Befehl nicht empfangen.

Ich habe heute mit peha gesprochen und auch hier wird ein technischer Defekt nicht ausgeschlossen. Leider tauscht peha nicht mehr direkt, seitdem es Honeywell ist und ich muss das Dingen über den Internet-Händler und dessen Großhändler einschicken. Das wird dann wohl ein paar Wochen dauern...schade, dass der Support inzwischen so schlecht geworden ist!

Aber leider gibt es zu diesem Aktor keine mir bekannte Alternative. Die eltako Dinger können die Laufzeit nicht messen und andere Aktoren sind mir auf dem deutschen Markt nicht bekannt.

Ich werde weiter berichten...

Christian