Erweiterung CULFW um Somfy/Simu

[Gernott]

Versuche mal, ein "sleep 2 quiet" zwischen die Ansteuerung verschiedener Rollos einzufügen. Das hatte bei mir geholfen. Wenn man alle Befehle gleichzeitig raushaut, scheint sich der CUL zu verschlucken.

Gruß
G.

[thdankert]

Hallo zusammen,

zunächst Danke für das Modul!

Ich habe ein merkwürdiges Problem mit dem SOMFY Modul, das ich nicht lösen kann: Es laufen in der aktuelle Konfiguration etwa 12 Somfy RTS Motoren. Alle Motoren kann ich auch einzeln hervorragend ansteuern. Leider habe ich Probleme bei der Nutzung von Structures und Zeit-gesteuerten Befehlen (at). Häufig bewegen sich dann nur ein bis zwei der Rollos.

Hallo Markus,

das Problem habe ich selbst auch, vielleicht ist auch mein CULFW-Modul schuld, was zu lang zum Senden braucht, oder FHEM nicht korrekt mitteilt, das noch kein neuer Befehl abgeschickt werden kann.
Es gibt da mehrere Workarounds:

• Wie von Gernott geschrieben, ein "sleep" zwischen den einzelnen set-Befehlen
• Alternativ kann man die Rolläden auch direkt als Gruppe ansteuern: dazu am besten ein neues SOMFY-Device anlegen (mit neuer Addresse) und die Rolläden nacheinander an dieses neue Device anlernen. Dann bewegen sich mit einem Befehl aus FHEM mehrere Rollos gleichzeitig.

Hier folgt dem SOMFY_Send auch ein SOMFY_Parse. Ist dieses notwendig? Kann aus dem Fehlen des SOMFY_Parse geschlossen werden, dass etwas schiefgelaufen ist?

Der CUL schickt aktuell einfach den gesendeten Befehl wieder zurück an FHEM, SOMFY_Parse wertet es aus, und aktualisiert den Status des betreffenden Rolladen.
Das sollte eigentlich direkt nach einem Send geschehen, aber vielleicht dauert es einen Moment, bis FHEM die Antwort an das SOMFY-Modul weitergeleitet hat.

Hast du die Möglichkeit, das zu debuggen (einfach mal einen Breakpoint auf Somfy_Send und _Parse setzen)?
Der Fall ist bei mir noch nicht aufgetreten, das Parse wurde immer direkt nach einem Send aufgerufen, auch wenn sich nicht alle Rollos bewegt haben.

Grüße,
Thomas

[Elektrolurch]

Hallo,

Zitat:
Hier folgt dem SOMFY_Send auch ein SOMFY_Parse. Ist dieses notwendig? Kann aus dem Fehlen des SOMFY_Parse geschlossen werden, dass etwas schiefgelaufen ist?

Das Parse macht doch eigentlich nur Sinn, wenn der CUL auch Somfy-Befehle (z.B. von anderen Somfy FBs) empfangen könnte, was derzeit doch nicht der Fall ist?
Der Parse führt nämlich dazu, dass der Status des Rolladen, wenn der auf eine Position gefahren wird, falsch geschrieben wird.

1. Parse setzt dann sofort nach Absenden des Befehls den Rolladen auf Close oder open.
2. Über den set-Befehl wird aber ein Timer gestartet, der nach der berechneten Fahrtzeit des Rolladen den Status dann auf die (Korrekte) berechnete Position setzt.

Das scheint aber nicht immer zu klappen.
Da ich häufig auf Zwischenpositionen (Sonnenschutz, Dämmerung) die Rollos verfahren, sehe ich, dass diese manschmal dann doch auf close oder open stehen.

Gruß


Elektrolurch

[Romoker]

Hallo zusammen,

seit ein paar Tagen besitze ich einen CUL433 und bin über die neuen Möglichkeiten begeistert. Unter anderem kann ich jetzt meine Markise mit dem SOMFY-Modul ansteuern. Ein ganz großes Dankeschön an die Entwickler!

Das Raus- und Reinfahren funktionierte auf Anhieb. Aber wo Licht ist, ist auch Schatten. Ich möchte gerne auch Zwischenpositionen anfahren, aber es gelingt mir nicht mit dem pos-Befehl auf Dauer sauber die gewünschte Position anzufahren.

Die Auf- und Abzeiten sind bei mir wie folgt definiert:

Code Auswählen Erweitern

attr Markise drive-down-time-to-100 37
attr Markise drive-down-time-to-close 40
attr Markise drive-up-time-to-100 3
attr Markise drive-up-time-to-open 43

Folgendes Szenario führt zu einer falsch berechneten Position:
- Ausgangslage: Markise geschlossen (pos 0)
- Markise ausfahren: set Markise on führt zu state = on und position = 108.081978831979; soweit noch alles gut. Die Markise ist komplett ausgefahren.
- Markise einfahren: set Markise off führt zu state = pos 50 und position = 48.0569788319788, die Markise ist aber komplett eingefahren.

Korrekt wäre pos 0.

Habe ich die drive-up- und drive-down Attribute falsch konfiguriert oder berechnet das Modul die Position falsch?

[Elektrolurch]

Hallo,

ich glaube, Du hast das falsch verstanden. Ein Rolladen hat eine Sperrposition, d.h. die untere Kante des Rollos berührt die Fensterbank, alle Lamellen sind aber noch gedehnt, so dass durch die Schlitze Lüftung sichergestellt ist. Dies ist die Position 100. 'Close' ist der Endanschlag, wenn das Rollo völlig geschlossen ist und es dunkel im Zimmer ist.
Bei einer Markise gibt es das nicht. Pos 100 = close

Wenn dann müssten Deine Attribute so heißen:

attr Markise drive-down-time-to-100 40
attr Markise drive-down-time-to-close 40
attr Markise drive-up-time-to-100 0
attr Markise drive-up-time-to-open 40


Ansonsten funktioniert das mit der Positioniererei  eigentlich ganz leidlich und reproduzierbar. Ich nutze Zwischenpositionen, die per eventMap "Sonnenschutz" (pos 80) und 'Dämmerung' (pos 90) heißen und auch von fhem regelmäjßig angefahren werden.

Elektrolurch

[Romoker]

Hallo Elektrolurch,

danke für die schnelle Antwort. Mein Verständnis der Attribute entspricht Deiner Beschreibung. Mir ist schon klar, dass eine Lüfterstellung bei einer Markise keinen Sinn macht. Aber Fhem weiß ja nicht, ob es sich um eine Markise oder um eine Rolllade handelt. Also müsste meine Konfiguration grundsätzlich funktionieren.
Dein Konfigurationsvorschlag war auch mein erster Konfigurationsversuch, nur daß meine Hochfahrzeit 3 Sekunden länger als die Ausfahrzeit ist. Aber Dein Vorschlag lässt sich in Fhem v5.6 (letztes Update vor einer Woche) so nicht konfigurieren. Beim Versuch drive-up-time-to-100 auf 0 zu setzen kommt die Fehlermeldung: SOMFY_attr: value must be >0 and <= 100. Demnach ist 0 nicht zulässig. Ich habe stattdessen mit 0.1 experimentiert. Das ist zwar konfigurierbar, die Position wird aber ebenso falsch berechnet (siehe Szenario 2).

Szenario 2 mit folgenden Attributeinstellungen:

Code Auswählen Erweitern

attr Markise drive-down-time-to-100 40
attr Markise drive-down-time-to-close 40.1
attr Markise drive-up-time-to-100 .1
attr Markise drive-up-time-to-open 43

- Ausgangslage: Markise geschlossen (pos 0)
- Markise ausfahren: set Markise on führt zu state = on und position = 100.25; Die Markise ist komplett ausgefahren.
- Markise einfahren: set Markise off führt zu state = pos 40 und position = 42.0681818181818, die Markise ist aber komplett eingefahren.

Hier der Logauszug:

Code Auswählen Erweitern

2015.02.13 17:11:13 3: SOMFY_set: Markise -> state update in 40.1 sec
2015.02.13 17:11:13 2: SOMFY set Markise on: sAC40005C000001
2015.02.13 17:13:56 3: SOMFY_set: Markise -> state update in 25.0625 sec
2015.02.13 17:13:56 2: SOMFY set Markise off: sAD20005D000001


Herunterfahren in 40.1 Sekunden ist korrekt. Für das Hochfahren mit off-Kommando werden 25 Sekunden ausgewiesen. Korrekt wären 40.1 Sekunden.

Die Endlagenkommandos on und off fahren korrekt in Endlage. Es scheint so zu sein, dass bei konfigurierten Fahrzeiten größer 25 Sekunden die Fhem-Position nicht korrekt ist.

Viele Grüße
Romoker

[Romoker]

Hallo Elektrolurch,

ich habe mir den Quellcode in 10_SOMFY.pm (Version 6645 vom 2014-10-01 07:55:26) angeschaut und den Fehler gefunden. Die beiden Attributnamen in Zeile 472 sind falsch spezifiziert:

Statt

Code Auswählen Erweitern

$updatetime = (AttrVal($name,'drive-up-time-open',25) - AttrVal($name,'drive-up-time-100',0)) * $oldpos / 100;

muss es

Code Auswählen Erweitern

$updatetime = (AttrVal($name,'drive-up-time-to-open',25) - AttrVal($name,'drive-up-time-to-100',0)) * $oldpos / 100;

heissen.

Da ich kein Perl-Spezialist bin kann ich mich auch irren, aber in Zeile 391 ist mir ein noch ein Fehler aufgefallen, der aber anscheinend keine Auswirkungen hat:

Code Auswählen Erweitern

$newpos = 100 if($newpos > 100), # driven only short between close and pos 100!

Das Komma muss durch ein Semikolon ersetzt werden.

Mit der obigen Korrektur kann ich jetzt korrekt meine Markisenpositionen anfahren.

Mein aktuelles SOMFY-Modul ist: # $Id: 10_SOMFY.pm 6645 2014-10-01 07:55:26Z thomyd $

Die Korrekturen sollten dann auch in das offizielle Modul einfließen.

Viele Grüße
Romoker

[Elektrolurch]

Hallo,

danke für den Hinweis. Habe das gefixed.
Da ich derzeit an Bedienungsoberflächen für die Rolladen mit mehreren Ikonen und Menü für die Position arbeite, habe ich noch ein paar andere Bugfixes beseitigt.
DA war noch ein Fehler in "set name ?", so dass attr name setList ... nicht korrekt funktionierte und das Updaten der Position auf dem Screen war auch noch nicht korrekt.

Ich hänge mal zu Testzwecken die aktuelle Version an. (Achtung: SOMFY_Parse ist deaktiviert, was aber nur bei fhem-2-fhem wohl eine Rolle spielen sollte).

@Thomas: Falls ok, bitte einchecken.

Edit:
15.2.2015: Neue Version hochgeladen. slider dürfte jetzt gehen und kann auch per setList überschrieben werden. Habs doch rausgefunden!!!
slider bekommt man jetzt mit:
webCmd Pos oder pct
Mit webCmd pos bekommt man eine Auswahllliste.
Gruß

Elektrolurch

[Romoker]

Hallo Elektrolurch,

super. Fhem macht wirklich Spaß, vor allem, wenn man sieht, mit welchem Engagement die Leute hier unterwegs sind.

Ein Slider hätte als nächstes auf meiner Wunschliste gestanden.  Leider habe ich dazu das setList-Kommando vermisst. Könnte damit der Slider definiert werden?

Deine neue Version habe ich getestet. "set name ?" scheint aber noch nicht zu funktionieren. Das setList-Kommando steht als Attribut noch nicht zur Verfügung bzw. es wird mit "webCmd pct" kein Slider angezeigt.

Viele Grüße
Romoker

[Elektrolurch]

Hallo,

pct sagt mir jetz sowieso nichts.
Wenn Du
webCmd state:pos
machst, dann bekommst Du eine Auswahlliste für die Positionen.
Ich würde ja gerne auch den slider anbieten, leider hat mir aber hier niemand im Forum eine Antwort darauf gegeben, wie oder was ich in das Modul noch hineinprogrammieren muss, damit auch ein slider geht, bzw. wie ich "pos" via setList mit einem slider "überschreiben" kann.
Wenn ich setList pos:slider,0,10,100
definiere, kommt leider immer noch das default - Menü für pos.

Ein neuer Versuch: Wenn jemand das liest und es weiß, her mit der Info...

Ich habe schon alle Modul-Entwicklungs-Einsteiger-... Dokus gelesen, es steht da nicht drin.


Alternativ geht das natürlich immer über eine readingsGroup.
Habe mir für jeden Raum eine rg definiert, mit Heizkörperthermostat, Fensterstatus und Ikonen für verschiedne Rolladenpositionen und dem Menü (welches auch durch einen slider ersetzt werden könnte)


Elektrolurch

[_Markus_]

Hi thdankert,

klar, ich kann gerne debuggen wenn du mir kurz einen Hinweis richtung IDE gibst ; )
Ich hatte schon ein paar Logs eingefügt, z.B. direkt nach dem Aufruf von SOMFY_Parse. Daher meine ich ausschließen zu können, dass es aufgerufen wird.

Soweit ich die Protokoll Doku vom RTS richtig gelesen habe, sendet der RTS durchaus ACKs nach erhalt von Befehlen, richtig? Hast du einen kurzen Tipp, wie ich in das Reverse-Engineering und FW-Development einsteigen kann? Oder bist du hier schon auf Probleme gestoßen?

Gruß
Markus

[thdankert]

Hallo Romoker,

danke für die Bugfixes, das ist mir noch gar nicht aufgefallen (ich nutze "pos" nur zum runterfahren, nicht hoch)!

Code Auswählen Erweitern

$updatetime = (AttrVal($name,'drive-up-time-to-open',25) - AttrVal($name,'drive-up-time-to-100',0)) * $oldpos / 100;


Code Auswählen Erweitern

$newpos = 100 if($newpos > 100), # driven only short between close and pos 100!

Das Komma muss durch ein Semikolon ersetzt werden.

Die Korrekturen sollten dann auch in das offizielle Modul einfließen.

Ist gerade geschehen, ab morgen ist es dann per FHEM update verfügbar.

Grüße,
Thomas

[thdankert]

Hallo Elektrolurch,

Da ich derzeit an Bedienungsoberflächen für die Rolladen mit mehreren Ikonen und Menü für die Position arbeite, habe ich noch ein paar andere Bugfixes beseitigt.
DA war noch ein Fehler in "set name ?", so dass attr name setList ... nicht korrekt funktionierte und das Updaten der Position auf dem Screen war auch noch nicht korrekt.

Ich hänge mal zu Testzwecken die aktuelle Version an. (Achtung: SOMFY_Parse ist deaktiviert, was aber nur bei fhem-2-fhem wohl eine Rolle spielen sollte).

@Thomas: Falls ok, bitte einchecken.

ohje, jetzt ist leider passiert, was ich befürchtet habe... du hast die Updates auf deiner Version (noch nicht fhem-2-fhem fähig) gemacht,
und jetzt sind beide Entwicklungsstränge auseinandergelaufen.

Ich habe die Bugfixes von Romoker ins Modul eingebaut, und würde auch gern deine restlichen Änderungen übernehmen.
Ich will aber ungern auf IOWrite verzichten und wieder das alte CUL_SimpleWrite nehmen...

Können wir das in einem separaten Thread noch weiter besprechen? Oder per PM wenn du willst.

Grüße,
Thomas

[Elektrolurch]

Hallo Thomas,

siehe PN zum Entwicklungsstand.
Habe den Anhang in Beitrag 442 noch Mal ausgetauscht.  Slider sollten jetzt gehen (Pos oder pct für webCmd). Lassen sich nun auch per setList überschreiben durch andere Widgets.

Elektrolurch

[Romoker]

Hallo zusammen,

das nimmt ja jetzt richtig Geschwindigkeit auf

Ich warte mit dem Update solange, bis die beiden Stränge wieder zusammengelaufen sind und offiziell zur Verfügung stehen.

Nochmal vielen Dank für den super Support!

Viele Grüße
Romoker