Aktorfehler: PEHA 452 FU-EBIM JR o.T

[Spartacus]

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!

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[Spartacus]

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.

Code Auswählen Erweitern

(([09:56|12345] and
  ![?state.NRW.Ferien.dum] and [?hl.01.Feiertag:today] eq "none") or
([10:00]))
(set EG.wz.RO.* opens)

Christian

[krikan]

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

[Spartacus]

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

[krikan]

Hallo Christian!

FT55-Taster arbeiten übrigens einwandfrei!

Das beweist leider nichts, da FHEM mit anderem EEP ansteuert.

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

[Spartacus]

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.

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).

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

[Spartacus]

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

[krikan]

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.

[Spartacus]

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

[Spartacus]

...aber trotzdem würde mich mal interessieren, wie sich die gesendeten Daten zusammensetzten.

Code Auswählen Erweitern

55000A000180A507000028 FF94C084     0024
                      |Aktoradresse|????

Christian

[klaus.schauer]

Serielles Protokoll siehe http://www.enocean.com/esp

[Spartacus]

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

[klaus.schauer]

Ich verstehe nicht, warum ein log nicht die notwendigen Informationen liefert:

Code Auswählen Erweitern


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.

[Spartacus]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[Spartacus]

Hm,
irgendwie stimmt das noch nicht ganz. Es werden offenbar zwei Sequenzen vom Aktor gesendet.

Code Auswählen Erweitern

DATA: 00008908
und zwei Zeilen tiefer

Code Auswählen Erweitern

DATA: 00008608

Was quittiert der Aktor da mit 8908 bzw. 8608

Hier noch einmal die gefilterte Testsequenz 2:

Code Auswählen Erweitern

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