Modul-Entwicklung: Somfy RTS

[Elektrolurch]

Hallo Johannes,

für wahr, sehr heiß.
Schau mal in den set - Befehl: Da gibt es ja
set roll pos <ein Wert>
Üblicherweise wird doch, so habe ich fhem verstanden, die Option "pos" als reading betrachtet und das Ergebnis von
set roll pos <Wert>
in das reading pos gespeichert.
Wenn Du set roll ? eingibst, so sollte ja bei einer bestimmten Option auch die Liste der möglichen Werte erscheinen, also für pos:0,10,20...,100 damit die Detailansicht auch korrekt angezeigt wird.
Eigentlich hatte ich das auch so drin, ist aber jetzt wohl weg.

Schaut dann so ungefähr so aus:

%sets = (
'on' => '',
'off' => '',
'pos' => '0,10,20,... 100',
usw

und am Ende der set-Routine für ? oder unbekannte Optionen habe ich dann so was:

else
{
my @cList;
# overwrite %sets with setList
my $atts = AttrVal($name,'setList',undef);
my %setlist = split("[: ][ ]*", $atts);


foreach my $k (sort keys %sets)
{
my $opts = undef;
$opts = $sets{$k};
if (defined($opts))
{
$opts = $setlist{$k} if(exists($setlist{$k}));
push(@cList,$k . ':' . $opts);
}
else
{
push (@cList,$k);
}
} # end foreach

return "Unknown argument $rd, choose one of " . join(" ", @cList);
} # if $rd

Damit bekommt "pos" automatisch das gewünschte Menü, kann aber per setList durch einen slider bspw. auch überschrieben werden.

Wenn ich das pos-Menü benutze, dann muss pos auch anschliessend per readingsBuldUpdate($hash,'pos',$newpos,1);
aktualisiert werden, damit der ausgewählte Menüeintrag auch beim nächsten Screenrefresh wieder angezeigt wird.

Ich bin mir da nicht mehr so sicher, müsste die alte Versionen wieder aus dem Archiv holen, aber "pos" war die auf 10er-Schritte gerundete Version und "position" die exakte Position.

Das der state jetzt "50" statt "pos 50" enthält, ist für mich nicht weiter störend, man muss halt die Definition für das devStateIcon anpassen, scheint aber zumindest bei einem User wieder zur Reaktion geführt zu haben: Geht nicht, muss update abwarten, statt mal ein wenig mitzudenken,.

Sollte man ev. gem. Code vielleicht mal beschreiben, dass state

open,10,20...closed als Werte annehmen kann.

Jezt höre ich auf, da zerfliesse, Büro ist unterm Dach...

Elektrolurch

[viegener]

Hallo Elektrolurch,
ok, jetzt habe ich mehr verstanden.

Der Teil mit dem Ergebnis von set ... ? war ja weiterhin enthalten, allerdings steht es am Anfang der set Routine und bei mir erzeugt fhemweb auch entsprechende Controls.

Was fehlte ist die Möglichkeit mit setList zu übersteuern, die habe ich mal in meinem Repository hinzugefügt und las pull request an Thomas weitergeschickt. Wenn Du testen willst: https://github.com/viegener/somfy-rts-fhem

Die Änderung das Reading von position auf pos zu ändern möchte ich so erstmal nicht machen, denn das würde sicher bei anderen Nutzern, die sich auf position verlassen (inklusive mir) zu Problemen führen. Vielleicht könnte man den Namen konfigurierbar machen (oder zumindest zentral im Kopf definiert)?

Gruss,
Johannes

[Elektrolurch]

Hallo Johannes,

mit der Ergänzung um setList war ein Wunsch eines Nutzers, der seine Markise über einen slider steuern wollte. Vermutlich gibt es da noch eine zweite Variante mit widgetOverwrite, aber da habe ich noch ad hoc kein Programmierbeispiel gefunden, wie das in einem Modul mit einzubauen ist oder ob überhaupt?

Mein Workaround:
in der Somfy_updateState habe ich an den zwei Stellen, an denen readingsBulkUpdate($hash,'position'...
aufgerufen wird, einfach das um
readingsBulkUpdate($hash,'pos'..
ergänzt und gut war.

Zitat:
Die Änderung das Reading von position auf pos zu ändern möchte ich so erstmal nicht machen, denn das würde sicher bei anderen Nutzern, die sich auf position verlassen (inklusive mir) zu Problemen führen. Vielleicht könnte man den Namen konfigurierbar machen (oder zumindest zentral im Kopf definiert)?

Der Workaround löst das... s.o.

Übrigens: Das mit den sich aktualisierenden Icons während des Verfahrens der Rollos ist natürlich sehr "effektvoll" und überzeugt auch den letzten Gegner von Hausautomatisierung!!!!
Da der Aufwand für so was durchaus überschaubar ist ( a bisserl InternalTimer...) überlege ich schon, was man noch so blinken lassen könnte....

Gruß


Elektrolurch

[rudolfkoenig]

Vermutlich gibt es da noch eine zweite Variante mit widgetOverwrite, aber da habe ich noch ad hoc kein Programmierbeispiel gefunden, wie das in einem Modul mit einzubauen ist oder ob überhaupt?

Fuer widgetOverride braucht man im Modul nichts zu tun, siehe http://fhem.de/commandref.html#widgetOverride

[Elektrolurch]

Zitat:
Fuer widgetOverride braucht man im Modul nichts zu tun, siehe http://fhem.de/commandref.html#widgetOverride

Stimmt. Habe es gerade ausprobiert. Hatte es aber schon mal an dem Somfy getestet und da ging es nicht. Vielleicht hatte ich mich allerdings auch vertipp:
widgetOverwrite -> widgetOverride (Screenreader machts ungefähr gleich)

@Johannes: Die Ergänzung mit setList ist damit an für sich überflüssig.
Vielleicht die zwei Zeilen mit readingsBulkdUpdate($hash,'pos'...
einfügen, damit die Versionen nicht wieder auseinander laufen.. :-D

Elektrolurch

[Skusi]

Hi,
ich habe nun einige Tage mit der V1.6 rumprobiert.
Mein System ist seit dem ich die 1.6 drauf habe sehr oft abgeschmiert.

Im Log ist mir dann folgendes aufgefallen:

Code Auswählen Erweitern

SOMFY_set: handled command on --> move :on:  newState :10:
Illegal division by zero at ./FHEM/10_SOMFY.pm line 1104.

Diese Meldung ist die letzte die vor einem Absturz im Log steht.
Komischer Weise passier der Crash nicht bei jedem Fahrbefehl. Dieser kam zustande als meine Rolladen gestern Abend runter fahren sollten.
Dies passiert über eine Structure mit einem async delay von 3 sek. Dies habe ich eingefügt weil sich mein NanoCul ab und zu mal aufhängt wenn er alle Somfys gleichzeitig besenden soll. Keine Ahnung woran das liegt, aber mit dem Delay funktionierte es seit langem.

Nun habe ich wieder die 1.5 eingespielt, und alles ist gut.
Die letzte Version die probiert hatte war die seit Gesten morgen eingeckeckte.

Schade, ich war guter Dinge das es nun alles mit der 1.6 funktioniert. Vielen Dank auch an dieser Stelle für den tollen support.

Kann bitte mal jemand nachforschen warum das Modul mein Fhem immer killt.

--Skusi

[Elektrolurch]

Das hatte ich gestern auch.
Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.
Das passiert, wenn über die Position 100 hinaus gefahren wird, also von Sperrposition auf geschlossen.
Wir müssen das noch fixen, ich habe gestern abend auf die schnelle (es war zu heiß)
eine Abfrage auf gleiche Werte eingebaut und gebe eine FEhlermeldung aus.
Aber das muss noch korrekt berechnet werden.

Elektrolurch

[viegener]

Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.
Das passiert, wenn über die Position 100 hinaus gefahren wird, also von Sperrposition auf geschlossen.

Aua und ich kann nicht mal sagen es war zu heiss, den Code habe ich ja schon vor Wochen geschrieben.
Ich schaue mir das an.

Die Änderung mit setList könnte man drin lassen, da sie vielleicht andere verwenden wollen?

pos und position finde ich an sich nicht schön, ich würe das lieber über ein Attribut schaltbar machen:

Code Auswählen Erweitern

additiionalPosReading <name of additional attribut for pos reading>

[Skusi]

OK,
ich hab eben mal alle Zeiten neu gestoppt und die drive-to-100 eine skunde kleiner als die to-down gesetzt.
Dann per Update das aktuelle Somfy Modul installiert.
Erste Tests liefen super. Mal sehen ob das System nun auch morgen noch stabil bleibt.

Das mit den to-100 und to-close Zeiten habe ich nie richtig begriffen. Warum muß man diese unterschiedlichen Positionen angeben. Meine Rolladen sind doch zu wenn sie zu sind. Welche Position soll denn die to-100 sein ?

Die Lüftungsposition mache ich über die go-my Position.

Egal, cool das ich nun die 1.6 wieder testen kann...

--Skusi

[viegener]

Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.

Zur Erklärung: Die Zeiten sind so gedacht, dass die Position 100 den Zustand bei Rolläden beschreibt, wenn der Rolladen zwar bis unten gefahren ist, aber noch nicht vollständig gesperrt. Close ist der Zustand wenn wirklich alles komplett geschlossen ist. Insofern ist drive-down-time-to-100 kleiner als drive-down-time-to-close. Ausserdem ist üblicherweise drive-up-time-to-100 relativ klein und drive-up-time-to-open sogar noch grösser.

Die relativ komplexe Neuberechnung der Position basiert auf genau diesen Annahmen und Voraussetzungen.

Eigentlich hatte ich den Fall den Ihr beschreibt ja vorgesehen, allerdings ist die Bedingung etwas strikt. Im Falle das drive-down-time-to-100 und drive-down-time-to-close den gleichen Wert haben müsste eigentlich drive_up-time-to-100 den Wert 0 haben, denn das ist ja die umgekehrte Bewegung. Dann müsste die entsprechende Bedingung eigentlich zutreffen. Also könntet Ihr diesen Wert mal auf 0 setzen und schauen ob die Meldung dann auch bei Euch weg ist?

Ich werde das aber trotzdem noch anpassen,
Johannes

[viegener]

Also ich habe nochmals ein paar Änderungn vorgenommen:

- timing-Attribute werden auf konsistente Werte überprüft ansonsten wird eine Log-nachricht geniert und die timing daten werden ignoriert!
- Keine Division durch 0 und Vermeidung anderer perl Warnings
- Neues Attribut um weiteres pos reading zu ermöglichen additionalPosReading

Anbei eine aktualisiert Fassung und natürlich auch in github...

Rückmeldungen von tests sind willkommen,
Johannes

[justme1968]

ist setList hier wirklich sinnvoll?

einem modul eine andere kommando liste unterzuschieben auf die es nicht vorbereitet ist führt doch nur zu Problemen. und für die ursprüngliche anfrage einen slider zu konfigurieren ist es nicht nötig. dafür gibt es einen fhem weiten mechanismus der für alle module gleich und automatisch vorhanden ist.

gruss
  andre

[viegener]

Das Thema setList oder nicht überlasse ich den erfahrenen Entwicklern. Ich benötige es nicht und verstehe auch die Argumente von Andre es nicht zu unterstützen. Also wenn es gewünscht wird kann ich das gerne rausnehmen.

Ich habe aber noch einige Änderungen wg. der Fehlermeldungen und Abstürze (division durch 0) entfernt.
Bei der zweiten testrunde heute nachmittag habe ich dann noch eine Kokrrektur für den Fall position = 100 und befehl down gemacht.

Bis auf die letzte Korrektur sind meine pull requests auch schon von Thomas in sein Repository übernommen worden und werden wohl dann auch demnächst über update verfügbar sein.

Johannes

[thdankert]

Bis auf die letzte Korrektur sind meine pull requests auch schon von Thomas in sein Repository übernommen worden und werden wohl dann auch demnächst über update verfügbar sein.

Hallo Johannes,

ich habe gerade auch deinen letzten Pull Request akzeptiert und lade nachher die neue Version ins FHEM-Repository.
Grüße,
Thomas

[Elektrolurch]

Hallo Thomas und Johannes,

so a bisserl was habe ich noch gefunden:

1. Das mit dem zusätzlichen reading per Attribut (pos) funktioniert. Das einzige, was meiner Meinung nach fehlt, ist das Update für den Bildschirm. Ich habe da eine Auswahlliste, die set roll pos <Wert> genäeriert und somit auf das reading "pos" gebunden wird.
Wird eine Position über das Menü eingestellt, fährt der Roll auch da hin, aber der Wert der Liste wird nicht per longpoll aktualisiert. Baut man den Screen neu auf, dann steht der Wert der neuen Position korrekt drin.
In der Routine SOMFY_UpdateState wird
    readingsBulkUpdate($hash,$addtlPosReading,$rounded) if ( defined($addtlPosReading) );

ohne den DoTrigger-Wert aufgerufen.

Am Schluss steht zwar:
   readingsEndUpdate($hash,$doTrigger);

Ich habe das aber so verstanden, dass nur jene Werte dann per longpoll aktualisiert werden, die auch beim readingsBulkUpdate mit DoTrigger = 1 gesetzt wurden. Ev. irre ich auch.

2. Mit setList bin ich auch "meinungslos", da ja widgetOverride nun funktioniert und das set - Commando ja für "set roll pos <Wert>" ja schon von Hause aus eine Auswahlliste anbietet.

3.  Es gibt da wohl noch ein Berechnungsproblem für die Fahrtzeiten, da wird 10.6 Sekunden berechnet, der stop - Befehl kommt aber erst nach 13 Sekunden (zwei Rolls wurden verfahren).
Und in einem Fall bekomme ich eine stop-Zeit von 6000 / 3000 s.
Außerdem sieht es so aus, dass ein Positionierungsbefehl, der eine Position enthält, auf der der Roll bereits steht, dazu führt, dass ein "stop" Befehl (also gomy) gesendet wird.

Hier die Details:


Heute morgen hatte ich folgende Situation: Vier Rolls auf der Ostseite standen auf "pos 100". Um 8:12 Uhr hat sich der Sonnenschutz aktiviert, da es auf der Fassade schon über 28 Grad war. Sonnenschutz heißt, dass die Rolls auf "pos 80" gefahren werden.

Für einen einzelnen Rolladen funktioniert das auch einwandfrei, wenn alle auf "offen" stehen, funktionierte das auch (mit meiner "privaten" Version, nun habe ich ja die aus fhem wieder eingespielt).
Die Beschattungssteuerung gibt vier Befehle hintereinander aus:
set roll1 Sonnenschutz
set roll2 Sonnenschutz
..

Sonnenschutz ist per eventMap "pos 80".

Alle vier Rolls hätten also nur ein kurzes Stück von pos 100 auf pos 80 fahren sollen, also Up und kurz darauf stop.
die meisten  Rolls sind aber auf offen gefahren, also auf pos 0, so als wäre der "stop" Befehl ausgeblieben.

Frage: Die Timer für die Fahrtzeit werden doch schon rolladenweise, und nicht global verwaltet?

Normalerweise für die Rolladenautomatik verfahre ich die Rollos einzeln im Abstand von 10 Sekunden.
Die Beschattungssteuerung setzt die Fahrbefehle direkt hintereinander ab. Nicht das dadurch ein timing-Problem entsteht.

Ok. Nun doch getestet:

Situation:
Zwei Rolladen von offen auf pos 80 gefahren.
set (Az|Bd)_FRolladen Sonnenschutz
Der erste fährt korrekt an die pos, der zweite schließt ganz.

Daten:

2015.07.05 10:42:50 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :0:
2015.07.05 10:42:50 3: SOMFY_set: handled command pos --> move :on:  newState :0:
2015.07.05 10:42:50 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 10:42:50 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :0:
2015.07.05 10:42:50 3: SOMFY_set: handled command pos --> move :on:  newState :0:
2015.07.05 10:42:50 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 10:42:52 4: SOMFY Az_FRolladen on
2015.07.05 10:42:52 4: SOMFY Bd_FRolladen on
2015.07.05 10:42:53 4: SOMFY_TimedUpdate
2015.07.05 10:42:54 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 7.62 sec
2015.07.05 10:42:54 4: SOMFY_TimedUpdate
2015.07.05 10:42:54 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.3 sec
2015.07.05 10:42:57 4: SOMFY_TimedUpdate
2015.07.05 10:42:57 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 4.27 sec
2015.07.05 10:42:57 4: SOMFY_TimedUpdate
2015.07.05 10:42:57 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 3.83 sec
2015.07.05 10:43:00 4: SOMFY_TimedUpdate
2015.07.05 10:43:00 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 0.810000000000001 sec
2015.07.05 10:43:00 4: SOMFY_TimedUpdate
2015.07.05 10:43:01 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 0.520000000000001 sec
2015.07.05 10:43:01 4: SOMFY_TimedUpdate
2015.07.05 10:43:01 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 10:43:02 4: SOMFY_TimedUpdate
2015.07.05 10:43:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 10:43:02 4: SOMFY Az_FRolladen stop
2015.07.05 10:43:03 4: SOMFY Bd_FRolladen stop



Hier die Auffälligkeit:
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 10:43:03 4: SOMFY Bd_FRolladen stop

Differenz: 13 Sekunden, statt berechnete 10.6 s.
Daher ist der zweite Roll auch ganz zu.


Nun habe ich beide auf "geschlossen" (pos 200) gefahren und dann mit
set (Az|Bd)_FRolladen Sonnenschutz
auf erneut auf pos 80 gefahren (Diesmal also in Gegenrichtung).

Der Az-Rolladen ist ganz aufgefahren, der Bd hat diesmal die richtige Position erreicht.
Hier das log:

2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :200:
2015.07.05 11:11:22 3: SOMFY_set: handled command pos --> move :off:  newState :200:
2015.07.05 11:11:22 4: SOMFY_sendCommand: Az_FRolladen -> cmd :off:
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
2015.07.05 11:11:22 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :200:
2015.07.05 11:11:22 3: SOMFY_set: handled command pos --> move :off:  newState :200:
2015.07.05 11:11:22 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :off:
2015.07.05 11:11:22 4: SOMFY_set: Bd_FRolladen -> stopping in 5.15 sec
2015.07.05 11:11:24 4: SOMFY Az_FRolladen off
2015.07.05 11:11:24 4: SOMFY Bd_FRolladen off
2015.07.05 11:11:25 4: SOMFY_TimedUpdate
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.048 sec
2015.07.05 11:11:26 4: SOMFY_TimedUpdate
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.77 sec
2015.07.05 11:11:28 4: SOMFY_TimedUpdate
2015.07.05 11:11:28 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 11:11:29 4: SOMFY_TimedUpdate
2015.07.05 11:11:29 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 11:11:29 4: SOMFY Bd_FRolladen stop
2015.07.05 11:11:30 4: SOMFY Az_FRolladen stop

Die Zeile:
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
und dann:
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.048 sec


ist merkwürdig, aber am Schluß wäre ja der korrekte stop-Befehl doch gesendet worden, trotzdem furh das Az-Rollo ganz auf.

Hier die drive-Werte für Az:
drive-down-time-to-100 13.3
drive-down-time-to-close 16.9
drive-up-time-to-100 3.18
drive-up-time-to-open 17.67

und der etwas schnellere Bd (obwohl baugleich)
drive-down-time-to-100 13.3
drive-down-time-to-close 15.75
drive-up-time-to-100 2.3
drive-up-time-to-open 16.55


Ich habe überprüft: Beide Rolls haben den STATE 80
Wenn ich aber jetzt erneut:
set (Az@BD)_FRolladen Sonnenschutz
eingebe, sollte ja eigentlich nichts passieren. Aber: Der Bd bleibt auch auf "Sonnenschutz", der Az (mit STATE 80, aber von eben noch auf offen) fährt los und schliesst ganz.
Beide haben aber den STATE 80 weiterhin.
Hier das log dazu:

2015.07.05 11:22:39 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :80:
2015.07.05 11:22:39 3: SOMFY_set: handled command pos --> move :stop:  newState :80:
2015.07.05 11:22:39 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 11:22:40 4: SOMFY Az_FRolladen stop


Das schaut für mich so aus, als wäre da noch der timer mit
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec


aktiv gewesen und daher wurde dast stop-Commando gesendet.

Gruß und noch schönes Schwitzen

Elektrolurch