Hallo,
habe seit gestern einen Peha Rolladenaktor. Über einen Sender habe ich diesen auch schon eingelernt. Auch in fhem habe ich diesen mit
set Rollade teach angelernt und er hat auch die SUBDEF-Adresse bekommen. Hoch und runter fahren geht auch.
Allerdings raffe ich es nicht, wie man die Positions-Steuerung einrichtet. Im wiki steht:
set <name> runtimeSet <tu/s> <td/s>
Welche werte muss ich für tu und td ansetzten? Ich kann natürlich beliebige Zeiten wählen, aber dann wird die Position falsch berechnet.
Ich war davon ausgegangen, dass der Aktor selbständig die Zeit für das "Auf" und "Ab" misst und diese dann im Aktor selbst hinterlegt. Aber das scheint nicht der Fall zu sein.
Hat jemand einen Tipp für mich?
Spartacus
http://fhem.de/commandref#Blind%20Command%20Central:
ZitatRuntime Range: tu|td = 0 s ... 255 s
Select a runtime up and a runtime down that is at least as long as the shading element or roller shutter needs to move from its end position to the other position.
Also:
<tu/s> mit der entsprechenden Laufzeit in Sekunden zum Öffnen der Jalousie und
<td/s> mit der entsprechenden Laufzeit in Sekunden zum Schließen der Jalousie ersetzen
und Befehl "set <name> runtimeSet <tu/s> <td/s>" abschicken.
Nein, er misst die Laufzeit meiner Erkenntnis nach bei Gateway-Steuerung nicht selbst. Warum auch immer!? Da sind wir wieder bei der Frage: Was ist der Unterschied zw. EBI und EBIM?
Gruß, Christian
Hi Christian,
der EBIM hat einen Messchip und misst die Stromaufnahme. In der Anleitung steht:
Für den Empfänger ist eine Positionserkennung für Jalousinen, Rolladen und Markiesen einstellbar. Der Motor stoppt beim Erreichen der Endpositionen, unabhängig von den eingestellten Laufzeiten.
weiter heisst es
Die Positionserkennung ist nur durch einen kompletten "Selbstlauf" des Motors einzustellen! eine Unterbrechung führt zu einem Abbruch der Einstellung.
In der Parametertabelle der Anleitung steht dann:
Der Motor fährt mit der eingestellten Laufzeit ab. Wurde eine Positionserkennung durchgeführt, wird die entsprechende Position (in %) des Motors eingestellt.
Für mich bedeutet das, dass er die Laufzeiten automatisch errechnet. Vielleicht kann fhem diese nicht auslesen.
Alternativ:
ich mit einer Stoppuhr die Fahrzeit ermitteln und diese dann als Parameter setzen, korrekt?
Christian
Also ich habe es mit der automatischen Positionserkennung nur hin bekommen, so lange die Steuerung ausschliesslich per Taster erfolgte. Sobald eine Steuerung durch Fhem erfolgt, wurden die Werte geloescht. Einen Fehler in den Telegrammen kann ich nicht finden. Aber ich habe das nur mit der Aktor-Version mit Fehlern getestet. Neuere Version habe ich zwar im Austausch bekommen, aber nicht mehr eingebaut und getestet. Es gibt keinen Aktor, der mich mehr Zeit gekostet hat...
Also zumindest mit der alten Version musste man messen und manuell einstellen. Wenn Du einmal mit Fhem die Jalousie komplett hoch und heruntergefahren hast und keine prozentualen Jalousiestaende auftauchen, wird es immer noch so sein. Wenn Du einen Taster angelernt hast, probiere das mal mit einem Taster.
Gruss, Christian
Hallo krikan,
so, es funzt!
Ich hatte den Aktor zuerst mit einen Ersatzmotor auf dem Schreibtisch angesteuert. Das klappt aber nicht, da der "Mitläufer" offenbar für den Betrieb ds Motors arbeiten muss. Ich nehme an, er liefert die Umdrehungen an die Motor-Elektronik.
Jetzt habe ich den Aktor an eine "richtige" Rollade angeschlossen und das Dingen über fhem "auf"->"ab"->"auf" gefahren. Und siehe da, er meldet nun eine Position in den Readings.
Jetzt lässt er sich z.B. mit set <name> position 30 0 fahren. Auch wenn ich den Sender betätige, kommen laufend die Positionen in fhem an.
So hatte ich mir das gedacht!
Danke für die Tipps,
Christian
Verstehe ich das richtig:
Du musst nicht mit "runtimeSet" arbeiten, sondern nach hoch-/runterfahren klappt die Positionsanzeige?
Hast Du parallel einen Taster angelernt und damit auch gesteuert und die Positionsanzeige bleibt korrekt?
Hi,
ja, der Taster ist parallel eingelernt. Und richtig, Ich habe nicht mit "runtimeSet" gearbeitet.
Christian
Hallo,
ich habe noch ein Problem! Habe aus dem Wiki die Visualisierung eingebaut.
0:fts_shutter_100 100:fts_window_2w 1\d.*:fts_shutter_90 2\d.*:fts_shutter_80 3\d.*:fts_shutter_70 4\d.*:fts_shutter_60 5\d.*:fts_shutter_50 6\d.*:fts_shutter_40 7\d.*:fts_shutter_30 8\d.*:fts_shutter_20 9\d.*:fts_shutter_10 \d.*:fts_shutter_90
Aber irgendwie läuft das falsch herum. Wenn der Rolladen geöffnet ist, dann habe ich die Position "0" und im geschlossenen Zustand die position 100. Aber ist das Symbol "fts_shutter_100" mit Position "0" und "fts_window_2w" mit Position 100 verknüpft.
Habe ich jetzt den Aktor falsch angelernt, oder ist das ein Versehen im wiki?
Den Rest des attr. verstehe ich nicht ganz. Was genau berechnest Du mit "1\d.*, 2\d.*, usw.?
Spartacus
Hast Du "positionMode" wie im Wiki angegeben auf "inverse" gesetzt? Falls ja, einfach mal auf "normal" ändern.
Falsch angelernt hast Du nicht.
Wie im Wiki beschrieben hat das mit der alten, problembehafteten Aktorversion funktioniert; hatte ich getestet.
"1\d.*, 2\d.*" sind Regex für die Prozentangaben im Reading "position" und die entsprechende Zuordnung auf das Icon.
Hi,
danke für´s Feedback. Mein PositionMode scheint auf "normal"zu stehen, zumindest lese ich das in den Readings. Ich habe nichst gefunden, wie man das umstellen kann. Doofe Frage, wo ändert man das? Weder im Wiki noch in der peha Anleitung finde ich einen Hinweis darauf.
ein Attribut ist das auch nicht !
Christian
Du müsstest das mEn über den Befehl "set <device> positionLogic inverse" ändern können.
Alternativ drehst Du im Attribut devStateIcon die Zuordnung zwischen Regex und Icon in die andere Richtung um.
Hallo Christian,
danke! Genau diesen Befehl hatte ich schon mal abgesetzt. Hatte aber nicht funktioniert. Jetzt hat es aber geklappt! Wahrscheinlich beim 1. Mal ein Tippfehler!
Ganz lieben Dank für Deine tolle Unterstützung!
Gruß,
Christian
Hallo,
ich muss noch etwas ergänzen:
Ich habe den Aktor zurücksetzen müssen, da er plötzlich nicht mehr sauber auf fhem reagiert hat und Befehle nicht ankamen. Keine Ahnung was da passiert ist.
Das Problem war jetzt aber, das die Positionserkennung nicht mehr griff. Alle Versuche, diese neu einzulernen, scheiterten. Ein Anruf bei Peha brachte nichts, nur Ratlosigkeit. Ich habe dann den Aktor für 1min vom Stromnetz getrennt und siehe da, danach konnte die Positionserkennung mittels Wipptaster eingelernt werden. Nach einem Auf und Ab über fhem waren dann auch die Positionswerte wieder da. Ist wohl immer noch ein Fehler in der Firmware.
Eine Frage noch an die Experten.
Die Positionierung stellt man mit set device position <position> <Winkel> ein. Der Winkel ist bei mir immer "0". Wenn ich in fhem ein Dropdown mit Prozentwerten realisieren möchte, stört der Winkekparameter. Kann man den nicht irgendwie permanent auf "0" setzen und mit set device position <position> arbeiten?
Sparatcus
Hallo,
Ich muss noch mal fragen. Gibt es in den enocean Device Befehlen eine Möglichkeit, die Winkel Einstellung generell auf 0 einzustellen um die Positionen über ein einfaches dropdown anzufahren?
Mit eventmap Kriege ich das einfach nicht hin!
Christian
Das Profil Gateway/blindCmd ist jetzt geändert. Bei set <name> position <position> <angle> ist <angle> jetzt optional. Falls <angle> nicht angegeben wird, werden Standardwerte für den Winkel gesetzt:
- position = 0 >> angle = angleMax
- position = 100 >> angle = angleMin
- position > 0 und < 100 >> angle = angleMin + (angleMax - angleMin) / 2
Weiterhin ist jetzt ein "slider" für Position vorhanden. Ich hoffe, dass das Profil damit benutzerfreundlicher ist.
Bitte testen und kurze Rückmeldung geben, danke.
Hallo Klaus,
Wahnsinn! Was ist das denn für ein toller Service!
Ich habe das neue enocean Modul eingespielt und die Attribute angleMax und angleMin auf "0" gesetzt, da der Winkel sowieso immer "0" ist. Durch den Slider lässt sich das jetzt absolut perfekt bedienen!
Ganz lieben Dank für Deine Hilfe, das vereinfacht die Sache sehr!
Gruß,
Christian
Hallo,
Habe jetzt seit ein paar Tgen zwei Rollladen über den Aktor laufen. Was mir aufgefallen ist, ist, dass die Positionsansteuerung teilweise nicht funktioniert.
Wenn der Rollladen bspw. Geschlossen ist, und dann die Position 10 anfahren möchte, fährt er oft bis zum Endpunkt.
Im log werden die Positionen sauber zurückgezahlt, aber der Rollladen hält nicht an!.
TCM_RSSI liegt bei -83 bzw. -85.
Hat jemand eine Idee, an welcher Stellschraube ich noch drehen kann?
Internals:
CFGFN Config/98-EnOcean.cfg
DEF FFAC6280
IODev TCM310
LASTInputDev TCM310
MSGCNT 328
NAME EG.wz.RO.rechts
NR 253
NTFY_ORDER 50-EG.wz.RO.rechts
STATE 5
TCM310_DestinationID FFFFFFFF
TCM310_MSGCNT 328
TCM310_PacketType 1
TCM310_RSSI -83
TCM310_ReceivingQuality good
TCM310_RepeatingCounter 0
TCM310_SubTelNum 4
TCM310_TIME 2015-12-06 09:41:19
TYPE EnOcean
Readings:
2015-12-06 09:41:19 alarm off
2015-12-06 09:41:19 endPosition not_reached
2015-12-06 09:41:19 position 5
2015-12-06 09:41:19 positionMode normal
2015-12-06 09:41:19 serviceOn no
2015-12-06 09:41:19 shutterState stopped
2015-12-06 09:41:19 state not_reached
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_shutter_90
eep A5-38-08
eventMap opens:auf closes:ab
group 452 FU-EBIM
gwCmd blindCmd
manufID 001
room 98-EnOcean
stateFormat position
subDef FF94C084
subType shutterCtrlState.01
subTypeSet gateway
webCmd auf:ab:stop
Christian
Wird denn der Fahrbefehl richtig gesendet? Bitte mal mit verbose 5 die Sende- und Empfangstelegramme logen.
Hi Klaus,
bin nicht so der fhem Guru. Er schriebt mir alles ins fhem.log. Da hauen dann auch andere Einträge dazwischen...kann man das irgendwie separieren in ein eigens log?
Ich habe mal versucht, etwas zu extrahieren. Allerdings trat der o.a. Fehler nicht auf. Stattdessen ignoriert der Aktor manchmal die Befehle komplett und ich brauche mehrere Versuche bis überhapt etwas passiert.
2015.12.06 13:02:39 5: Cmd: >set EG.wz.RO.links position 5<
2015.12.06 13:02:39 3: EnOcean set EG.wz.RO.links position
2015.12.06 13:02:39 4: EnOcean EG.wz.RO.links sent PacketType: 1 RORG: A5 DATA: 0705004A SenderID: FF94C082 STATUS: 00 ODATA:
2015.12.06 13:02:39 5: TCM TCM310 sending ESP3: 55000A000180A50705004AFF94C082001A
2015.12.06 13:02:39 5: SW: 55000A000180A50705004AFF94C082001A
2015.12.06 13:02:39 5: TCM TCM310 RAW: 5500010002650000
2015.12.06 13:02:39 5: TCM TCM310 RESPONSE: OK
2015.12.06 13:02:39 5: TCM TCM310 RAW: 55000A0701EBA507
2015.12.06 13:02:39 4: FHEMWEB:192.168.1.50:1169 GET /fhem?detail=EG.wz.RO.links&fw_id=; BUFLEN:0
2015.12.06 13:02:39 5: EnOcean EG.wz.RO.links EnOcean_Get command: EG.wz.RO.links ?
2015.12.06 13:02:39 4: name: /fhem?detail=EG.wz.RO.links&fw_id= / RL:6586 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 13:02:39 5: TCM TCM310 RAW: 55000A0701EBA50705004AFF94C0820103FFFFFFFF5B0002
2015.12.06 13:02:39 4: TCM TCM310 Telegram from FF94C082 blocked.
2015.12.06 13:02:39 4: Connection closed for FHEMWEB:192.168.1.50:1157: EOF
2015.12.06 13:02:39 4: FHEMWEB:192.168.1.50:1169 GET /fhem?cmd={ReadingsVal(%22EG.wz.RO.links%22,%22position%22,%22%22)}&XHR=1; BUFLEN:0
2015.12.06 13:02:39 5: Cmd: >{ReadingsVal("EG.wz.RO.links","position","")}<
2015.12.06 13:02:39 4: name: /fhem?cmd={ReadingsVal(%22EG.wz.RO.links%22,%22position%22,%22%22)}&XHR=1 / RL:22 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 13:02:39 4: Connection accepted from FHEMWEB:192.168.1.50:1170
2015.12.06 13:02:39 4: FHEMWEB:192.168.1.50:1170 GET /fhem?cmd={AttrVal(%22EG.wz.RO.links%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.12.06 13:02:39 5: Cmd: >{AttrVal("EG.wz.RO.links","room","")}<
2015.12.06 13:02:39 4: name: /fhem?cmd={AttrVal(%22EG.wz.RO.links%22,%22room%22,%22%22)}&XHR=1 / RL:31 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 13:02:39 4: FHEMWEB:192.168.1.50:1170 GET /fhem?XHR=1&inform=type=status;filter=EG.wz.RO.links;since=1449403358;fmt=JSON&fw_id=1969×tamp=1449403302992; BUFLEN:0
.
wenn er dann fährt, sieht das so aus:
2015.12.06 12:56:50 5: Cmd: >set EG.wz.RO.links position 2<
2015.12.06 12:56:50 3: EnOcean set EG.wz.RO.links position
2015.12.06 12:56:50 4: EnOcean EG.wz.RO.links sent PacketType: 1 RORG: A5 DATA: 0702004A SenderID: FF94C082 STATUS: 00 ODATA:
2015.12.06 12:56:50 5: TCM TCM310 sending ESP3: 55000A000180A50702004AFF94C0820063
2015.12.06 12:56:50 5: SW: 55000A000180A50702004AFF94C0820063
2015.12.06 12:56:50 5: TCM TCM310 RAW: 5500010002650000
2015.12.06 12:56:50 5: TCM TCM310 RESPONSE: OK
2015.12.06 12:56:50 4: FHEMWEB:192.168.1.50:1155 GET /fhem?detail=EG.wz.RO.links&fw_id=; BUFLEN:0
2015.12.06 12:56:50 5: EnOcean EG.wz.RO.links EnOcean_Get command: EG.wz.RO.links ?
2015.12.06 12:56:50 4: name: /fhem?detail=EG.wz.RO.links&fw_id= / RL:6588 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 12:56:50 5: TCM TCM310 RAW: 55000A0701EBA50702004AFF94C0820103FFFFFFFF5C006B
2015.12.06 12:56:50 4: TCM TCM310 Telegram from FF94C082 blocked.
2015.12.06 12:56:50 4: Connection closed for FHEMWEB:192.168.1.50:1151: EOF
2015.12.06 12:56:50 4: FHEMWEB:192.168.1.50:1155 GET /fhem?cmd={ReadingsVal(%22EG.wz.RO.links%22,%22position%22,%22%22)}&XHR=1; BUFLEN:0
2015.12.06 12:56:50 5: Cmd: >{ReadingsVal("EG.wz.RO.links","position","")}<
2015.12.06 12:56:50 4: name: /fhem?cmd={ReadingsVal(%22EG.wz.RO.links%22,%22position%22,%22%22)}&XHR=1 / RL:23 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 12:56:50 4: FHEMWEB:192.168.1.50:1153 GET /fhem?cmd={AttrVal(%22EG.wz.RO.links%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.12.06 12:56:50 5: Cmd: >{AttrVal("EG.wz.RO.links","room","")}<
2015.12.06 12:56:50 4: name: /fhem?cmd={AttrVal(%22EG.wz.RO.links%22,%22room%22,%22%22)}&XHR=1 / RL:31 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.06 12:56:50 4: FHEMWEB:192.168.1.50:1153 GET /fhem?XHR=1&inform=type=status;filter=EG.wz.RO.links;since=1449403009;fmt=JSON&fw_id=1963×tamp=1449402954102; BUFLEN:0
Spartacus
Die Sendetelegramme sind in Ordnung; daran kann es nicht liegen. Das spricht eher für Empfangsprobleme.
Hallo Klaus,
danke für das Feedback. Empfangsprobleme kann ich mir eigentlich nicht vorstellen, da ich sonst keine Probleme auf dieser Etage habe.
Was bedeutet in diesem Zusammenhang "TCM TCM310 Telegram from FF94C082 blocked"?
Hat das was damit zu tun, dass der gesendete fhem - Befehl vom Aktor nicht verarbeitet wird und ich teilweise meine Befehle mehrfach senden muss? Wie kommt das zu Stande?
Christian
Die Meldung kommt, falls Fhem sein eigenes Telegramm empfängt, das durch einen Repeater erneut gesendet wird.
Hallo,
ja, das ist richtig! Es gibt einen Aktor, bei dem ich den Repeater freigeschaltet habe. Das dürfte aber nicht der "FF94C082" sein! Oder heißt das nur, dass fhem sein eigenes Telegramm an "FF94C082" von irgendeinem Repeater empfangen hat.
Siehst Du irgendeine Möglichkeit, wie ich einen sauberen Empfang meiner Aktoren überprüfen kann?
Christian
Zitat von: Spartacus am 07 Dezember 2015, 14:45:44
Es gibt einen Aktor, bei dem ich den Repeater freigeschaltet habe. Oder heißt das nur, dass fhem sein eigenes Telegramm von irgendeinem Repeater empfangen hat.
Genau
Zitat
Siehst Du irgendeine Möglichkeit, wie ich einen sauberen Empfang meiner Aktoren überprüfen kann?
Es gibt ein EnOcean-Feldstärkemessgerät. Habe das aber bisher nicht getestet.
Zitat von: klaus.schauer am 07 Dezember 2015, 15:32:10
Es gibt ein EnOcean-Feldstärkemessgerät. Habe das aber bisher nicht getestet.
Das hatte mir geholfen, den Einsatz von Repeatern zu reduzieren und festzustellen, dass Repeater in zu hoher Anzahl nicht helfen/kontraproduktiv sind.
Geht etwas ähnliches nicht mittlerweile auch mit den Aktoren selbst (Stichwort: EnOcean Service RLT (Slave))?
Hallo,
ja, die peha Dinger scheinen das zu können, ich wüsste jedoch nicht, wie das in Verbindung mit fhem zu testen wäre!
Der EnOcean Service RLT (RadioLinkTest) erlaubt ein Reichweitentest
zwischen einem Enocean Sender (z.B. Handsender 450
FU-HS 128) und einem Empfänger.
Die Auswertung des Reichweitentest erfolgt durch den Master.
Der Empfänger wird als Slave verwendet. Diese Funktion ist besonders
geeignet, um vor der Installation des Empfängers festzustellen,
ob der Installationsort geeignet ist.
Christian
Ich werde mir mal ansehen, ob und wie man den Radio Link Test (master) in Fhem einbauen könnte.
Hallo Klaus,
ich danke Dir!
In der Zwischenzeit werde ich mal den Repeater wechseln und einen anderen aktivieren.
Spartacus
NACHTRAG:
habe jetzt den Repeater getauscht und die "TCM310_ReceivingQuality" der Aktoren hat sich auf "exellent" verbessert. Der Fehler mit der Positionsansteuerung tritt aber immer noch auf!
Christian
siehe http://forum.fhem.de/index.php/topic,45810.0.html
Hallo zusammen,
ich habe von Zeit zu Zeit einen komischen Effekt mit dem Aktor:
morgens wird per DOIF der Rolladen hochgefahren:
([?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
Soweit klappt das auch.
Heute sind die beiden Rolladen korrekterweise um 08:00 hochgefahren. Da ich im DOIF ein "DO always" eingebaut habe, wird auch im zweiten Teil der Anweisung getriggert.
(... or
([{sunrise_abs("HORIZON=-2",0,"07:30","08:30")}])))
Das war heute um 08:23:xx Uhr, bei Sonnenaufgang.
Komischerweise haben sich beide Rolladen geschlossen. Das heisst:
Es wurde der Befehl "opens" gesendet und der Aktor hat "closed" verstanden. Kann sich das jemand erklären, wie es zu so einem Fehler kommen kann und wie man es künftig verhindern kann? Es ist jetzt zum 2. Mal innerhalb von 2 Monaten passiert.
Im Log log folgendes:
2016.01.08 08:00:00 3: EnOcean set EG.wz.RO.links opens
2016.01.08 08:00:00 3: EnOcean set EG.wz.RO.rechts opens
.........
2016.01.08 08:23:49 3: EnOcean set EG.wz.RO.links opens
2016.01.08 08:23:49 3: EnOcean set EG.wz.RO.rechts opens
Danke und Gruß,
Christian
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
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
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?
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
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,...)
Zitat
Allerdings nichts in der fhem.cfg.
Verstehe den Zusammenhang nicht. Was soll in der fhem.cfg stehen?
Gruß, Christian
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...
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
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
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