[patch] Korrekter Status FSB61 "closed" statt "stop" bei position=100

Begonnen von jensb, 24 Oktober 2018, 21:00:36

Vorheriges Thema - Nächstes Thema

Stonemuc

Ich häng mich hier mal dran -. ich hab mit dem FSB14 das gleiche Problem, da die Fahrzeiten ja unterschiedlich sind für auf und ab und es da bei der Beschattung zu Problemen kommt, wenn ich das AutoShutters Modul nutzen möchte.
Hast du es mit deiner Lösung hinbekommen? Kann ich die 100 und die 0 einfach durch closes und opens ersetzen?
FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

jensb

Habe in dem Zusammenhang noch etwas anderes feststellen müssen: Man sollte nicht nur die Bestätigungstelegramme am Aktor aktivieren sondern auf jeden Fall auch, wie in der Wiki beschrieben, deren Auswertung für die obere Position mit model=Eltako_FSB_ACK. Nur so ist sicher gestellt, dass man z.B. auch nach Hochfahren über Taster ohne FHEM in FHEM das Reading position aktualisiert bekommt.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Stonemuc

Ist der Patch jetzt im EnOcean Modul schon hinterlegt? Oder müsste ich das, so wie ch.eick, noch händisch erledigen?
Ich meine die Änderung anstatt von 0 opens und 100 closes zu setzen...
FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

jensb

Würde davon ausgehen, dass es dafür noch keinen Patch gibt, da weder Christian noch Klaus etwas davon erwähnt haben. Vielleicht kann Christian seine Lösung hier posten.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Stonemuc

Das wär was...dann könnte ich vielleicht endlich auf das Autoshuttersmodul umsteigen...anstelle meiner DOIFS
FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

ch.eick

Hallo zusammen,

leider habe ich noch keine Umsetzung im Code machen können, da ich die richtige Stelle noch nicht gefunden habe und auch das Releload nicht so recht klappt. Ein kompletter Neustart von FHEM dauert bei mir halt auch etwas lange. Leider hat sich Klaus noch gar nicht zu diesem Thema gemeldet.

Es steht aber noch immer auf meinem Plan :-)

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

hubiuwe

Hallo zusammen.

Ich habe das FSB61 und nutze es zusammen mit ASC.

Das Prolem ist wirklich die Positionierung mit "set ... position 0".
Wenn das Rollo über mehrere Tage nicht manuell gefahren wird, und ASC Beschattet mit dem Rollo jeden Tag, bleibt das Rollo bei "position 0" jeden Tag weiter unten stehen.

Ich habe mir einen workaround gebaut:
attr AK_WZ_ROL eventMap { usr=>{'position 0'=>'opens'} }

Dadurch wird bei "position 0" immer "opens" gesteuert und das Rollo fährt sicher in die obere Endposition.
Der einzige Nachteil ist, ASC erkennt die eigene aufwärts Fahrt als manuelle Fahrt.

Anstelle "shading out" steht "manual" im Reading "ASC_ShuttersLastDrive"

In wie weit es die Steuerfunkton von ACS beeinflusst weiß ich noch nicht.

Warum wird nicht standardmäßig bei "set ... position 0" die Endlage mit "opens" angefahren???
Eine Differenzierung macht m.e. keinen Sinn.

Ganz oben ist schließlich ganz oben ;)

Gruß Uwe
Die beste Automatik ist die, die man abschalten kann!

Stonemuc

Eventuell müssten wir Klaus nochmal darauf aufmerksam machen
FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

ch.eick

Hallo hubiuwe,

ZitatWarum wird nicht standardmäßig bei "set ... position 0" die Endlage mit "opens" angefahren???
Eine Differenzierung macht m.e. keinen Sinn.

Das mit Position 0 wird im FSB61 anscheinend anders gehandhabt und halt mit Zeit ermittelt. Leider fährt ein schweres Rollo langsamer hoch als runter.
Der Befehl opens/closes fährt bis in die Endabschaltung und sendet dann noch ein ack als Quittung, was den Mangel des FSB61 korrigieren würde.

Gruß
Christian 
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin,

ich habe Klaus am Wochenende auf diesen Thread mit einer Nachricht aufmerksam gemacht.

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

klaus.schauer

Änderung ab 10_EnOvcean V19718:

Für das Profil manufProfile (Eltako shutter) kann jetzt über das Attribut calAtEndpoints beim dem Befehl set <name> position 0 oder set <name> position 100 ein Motorlauf mit der Fahrzeit shutTimeCloses ausgelöst werden. Damit ist sichergestellt, dass die Rollos immer in ihre Endpositionen fahren. Dies entspricht den Funktionen opens und closes.

ch.eick

Hallo Klaus,
ich gestehe, dass ich nicht klar komme :-)

Das 10-EnOcean.pm Module hat den Stand:
# $Id: 10_EnOcean.pm 19718 2019-06-27 04:18:00Z klaus.schauer $


defmod WO_S_Rollo_FSB61 EnOcean 019EDB5D
attr WO_S_Rollo_FSB61 userattr room_map structexclude
attr WO_S_Rollo_FSB61 IODev TCM_ESP3_0
attr WO_S_Rollo_FSB61 alias WO_S_Rollo_FSB61
attr WO_S_Rollo_FSB61 comMode confirm
attr WO_S_Rollo_FSB61 eep A5-3F-7F
attr WO_S_Rollo_FSB61 manufID 00D
attr WO_S_Rollo_FSB61 model Eltako_FSB_ACK
attr WO_S_Rollo_FSB61 room EnOcean,Rollos
attr WO_S_Rollo_FSB61 settingAccuracy high
attr WO_S_Rollo_FSB61 shutTime 18
attr WO_S_Rollo_FSB61 shutTimeCloses 20
attr WO_S_Rollo_FSB61 stateFormat position
attr WO_S_Rollo_FSB61 subDef FFBA2383
attr WO_S_Rollo_FSB61 subType manufProfile
attr WO_S_Rollo_FSB61 verbose 0
attr WO_S_Rollo_FSB61 webCmd opens:stop:closes



Eine fahrt mit "opens" um eine definierte Position für den Testbeginn zu haben
2019-06-30_16:46:19 WO_S_Rollo_FSB61 anglePos: 0
2019-06-30_16:46:19 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:46:19 WO_S_Rollo_FSB61 endPosition: open
2019-06-30_16:46:20 WO_S_Rollo_FSB61 endPosition: not_reached
2019-06-30_16:46:20 WO_S_Rollo_FSB61 up
2019-06-30_16:46:40 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:46:40 WO_S_Rollo_FSB61 anglePos: -90
2019-06-30_16:46:40 WO_S_Rollo_FSB61 endPosition: open_ack
2019-06-30_16:46:40 WO_S_Rollo_FSB61 open_ack

Nun mit position 100
2019-06-30_16:47:41 WO_S_Rollo_FSB61 endPosition: closed
2019-06-30_16:47:42 WO_S_Rollo_FSB61 anglePos: 90
2019-06-30_16:47:42 WO_S_Rollo_FSB61 position: 100
2019-06-30_16:47:43 WO_S_Rollo_FSB61 endPosition: not_reached
2019-06-30_16:47:43 WO_S_Rollo_FSB61 down
2019-06-30_16:48:01 WO_S_Rollo_FSB61 block: unlock
2019-06-30_16:48:01 WO_S_Rollo_FSB61 endPosition: closed
2019-06-30_16:48:01 WO_S_Rollo_FSB61 anglePos: 90
2019-06-30_16:48:01 WO_S_Rollo_FSB61 position: 100
2019-06-30_16:48:01 WO_S_Rollo_FSB61 closed
Das Rollo ist vollständig geschlossen.

Jetzt mit position 0
2019-06-30_16:48:57 WO_S_Rollo_FSB61 endPosition: open
2019-06-30_16:48:57 WO_S_Rollo_FSB61 anglePos: 0
2019-06-30_16:48:58 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:48:59 WO_S_Rollo_FSB61 endPosition: not_reached
2019-06-30_16:48:59 WO_S_Rollo_FSB61 up
2019-06-30_16:49:17 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:49:17 WO_S_Rollo_FSB61 anglePos: -90
2019-06-30_16:49:17 WO_S_Rollo_FSB61 endPosition: open_ack
2019-06-30_16:49:17 WO_S_Rollo_FSB61 open_ack
Jetzt schaut leider noch etwas vom Rollo raus.

Wieder ein reset mit opens, wie am Anfang.

Und nun mit closes
2019-06-30_16:52:14 WO_S_Rollo_FSB61 anglePos: 90
2019-06-30_16:52:15 WO_S_Rollo_FSB61 position: 100
2019-06-30_16:52:15 WO_S_Rollo_FSB61 endPosition: closed
2019-06-30_16:52:16 WO_S_Rollo_FSB61 endPosition: not_reached
2019-06-30_16:52:16 WO_S_Rollo_FSB61 down
2019-06-30_16:52:36 WO_S_Rollo_FSB61 position: 100
2019-06-30_16:52:36 WO_S_Rollo_FSB61 anglePos: 90
2019-06-30_16:52:36 WO_S_Rollo_FSB61 endPosition: closed
2019-06-30_16:52:36 WO_S_Rollo_FSB61 closed
Das Rollo ist vollständig geschlossen.

Jetzt wieder mit opens
2019-06-30_16:52:53 WO_S_Rollo_FSB61 anglePos: 0
2019-06-30_16:52:54 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:52:54 WO_S_Rollo_FSB61 endPosition: open
2019-06-30_16:52:55 WO_S_Rollo_FSB61 endPosition: not_reached
2019-06-30_16:52:55 WO_S_Rollo_FSB61 up
2019-06-30_16:53:15 WO_S_Rollo_FSB61 position: 0
2019-06-30_16:53:15 WO_S_Rollo_FSB61 anglePos: -90
2019-06-30_16:53:15 WO_S_Rollo_FSB61 endPosition: open_ack
2019-06-30_16:53:15 WO_S_Rollo_FSB61 open_ack
Hurra, das Rollo ist vollständig geöffnet.

Für mich sehen die Log Meldungen für "opens" oder "position 0" und "closes" oder "position 100" vergleichbar aus, jedoch ist
das Fahrergebnis nicht identisch. Ich hoffe das dieser Test aussagekräftig ist.


Zitat
Für das Profil manufProfile (Eltako shutter) kann jetzt über das Attribut calAtEndpoints beim dem Befehl set <name> position 0 oder set <name> position 100 ein Motorlauf mit der Fahrzeit shutTimeCloses ausgelöst werden. Damit ist sichergestellt, dass die Rollos immer in ihre Endpositionen fahren. Dies entspricht den Funktionen opens und closes.

"Eltaco FSB61" ist nicht "Eltako shutter" , kann ich das dann trotzdem für den FSB61 verwenden? Und wie muss ich das dann definieren?

Oder geht es bei diesem Fix um ein ganz anderes problem?

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

klaus.schauer


ch.eick

Moin,

bei

attr WO_S_FSB61 catAtEndpoint yes


kommt leider nur unknown attribute...
In der Oberfläche wird es auch nicht im attr Pulldown angeboten

Update: Wie so üblich hatte ich ein "shutdown restart" vergessen. Nun ist alles da und ich werde testen. Leider bin ich nicht vor Ort, um die Position zu sehen.
Update: Nachdem das aktualisierte Modul geladen wurde konnte catAtEndpoint gesetzt werden. Ein erster Test war positiv. Mit position 0 oder 100 wurden bei einem
      kritischen Rollo die Endpositionen sauber angefahren. Ein weiterer Test mit allen Rollos wird dann am WE folgen.

Vielen Dank an Klaus

Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick