Modul-Entwicklung: Somfy RTS

[viegener]

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.

Das longpoll-Verhlaten muss ich mal bei mir überprüfen.

Soweit ich readingsBulkUpdate richtig gelesen habe, wird dochanged (also der letzte Parameter) automatisch gesetzt wenn er nicht explizit übergeben wird. Deshalb werden ja alle BulkUpdates ohne changed parameter aufgerufen.

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.

OK wenn ich in den nächsten Tagen keine andere Meinung höre, kann ich das auch wieder entfernen.

3. 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.
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.
Alle vier Rolls sind aber auf offen gefahren, also auf pos 0, so als wäre der "stop" Befehl ausgeblieben.

Muss das ganze noch Mal nachstellen mit verbose 4.
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.

Das sollte ich auch bei mir nachstellen können, allerdings werden die Timer soweit ich das verstehe schon über den hash auseinandergesteuert.

Meinem Verständnis nach erzeugt ja jeder InternalTimer aufruf einen separaten Timer, nur beim RemoveInternalTimer wird anhand des übergebenen Arguments der richtige Timer ausgewählt. Da als arg $hash übergeben wird sollten eigentlich unterschiedliche Timer angestossen werden.

[Elektrolurch]

Hallo Johannes,

sorry, die Hitze war doch noch nicht so groß, so dass ich das mal im Detail nachgestellt habe und meinen Beitrag mit den Daten und einer Zusammenfassung der Ergebnisse "angereichert" habe. Ich hoffe, das das weiter hilft.
Ich bekomme teils sehr große Werte für den stop-Befehl.... -> siehe oben.

Elektrolurch

[viegener]

OK, ich muss dass mal in mehreren Abschnitten abhandeln:

Zuerst mal die einfach Erklärung:

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.

Der Log ist erwartungsgemäss und basiert NICHT auf dem alten Timer: Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet (da ja keine Bewegung erfolgen soll).

[viegener]

Und der nächste Teil:

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.

Ja, das ist in der Tat schlecht, über 20% Abweichung in der Zeit ist ein Problem. In meinen Logfiles gibt es Abweichungen von ungefähr 2% (zum Teil sogar nahe Null) in aboluten Werten ist das delta zwischen 0.02 und 0.05s.

Eine Möglichkeit wo ein Delta passieren kann ist zwischen Aufruf der update routine und neustarten des timers, denn dazwischen werden Readings aufgefrischt und damit kann (inbesondere bei vielen abhängigen Aktionen) einiges an Zeit vergehen.

Dieses Delta kann man verringern, in dem man den neuen Zeitstempel bereits am Anfang berechnet. Ich habe mal eine Somfy-Version zum Ausprobieren angehängt, kannst Du die mal speziell für diese Zeitdifferenz laufen lassen?
Bei mir ist damit das Delta auf 0 gegangen (also wenn alle drei sekunden aufgefrischt werden soll, wird auch nach genau 3.00 Sekunden neu berechnet).

Das beinhaltet aber keine Änderung für das Problem mit mehreren Bewegungen gleichzeitig,
Johannes

[viegener]

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.

OK, das Szenario habe ich bei mir jetzt mal mit mehreren Kombinationen durchgespielt und kann Dein Problem nicht nachstellen. Allerdings ist ja auch in Deinem Log erkennbar, dass entsprechend Stop-Befehle gesendet werden.

Die Vermutung ist also, dass möglicherweise diese Befehle durch Funk überlagert werden, oder aus anderen Gründen nicht empfangen werden.  Bei mir ist ein CUL433 nur für Somfy-senden zuständig in einem Holzhaus und da habe ich einen Rolladen im Dachgeschoss, der etwa jeden 10. Befehl nicht empfängt (bzw. nicht darauf reagiert).

Wenn das nicht die Ursache ist, müssten wir schauen, ob es andere gibt, die ebenfalls solche Probleme bei mehreren Rolladenbewegungen haben.

[Elektrolurch]

Hallo Johannes,

Zitat:
Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet

Wird das tatsächlich gesendet? Denn bei stehendem Rollo fährt das Stop-Kommando ja in die gespeicherte (mygo) - Position.
So einen Effekt hatte ich, wenn die drive-Attribute nicht korrekt sind und der Rolo schon oben oder unten ansteht und dann das "stop" kommt. Dann fährt er halt auf die gespeicherte Position.
stop sollte man also auf keinen Fall senden, wenn der Rollo schon an der gewünschten Positionsteht.
Ich hatte da ursprünglich in ser set-Routine ein return mit Ext, wenn die Position schon angefahren wurde und erneut angefahren werden sollte.

Die neue Version habe ich reloaded. Hier wieder das log für
set (Az|Bd)_FRolladen Sonnenschutz

Log
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :0:
2015.07.05 15:20:02 3: SOMFY_set: handled command pos --> move :on:  newState :0:
2015.07.05 15:20:02 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :0:
2015.07.05 15:20:02 3: SOMFY_set: handled command pos --> move :on:  newState :0:
2015.07.05 15:20:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:03 4: SOMFY Az_FRolladen on
2015.07.05 15:20:04 4: SOMFY Bd_FRolladen on
2015.07.05 15:20:05 4: SOMFY_TimedUpdate
2015.07.05 15:20:05 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 7.62 sec
2015.07.05 15:20:05 4: SOMFY_TimedUpdate
2015.07.05 15:20:05 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.29 sec
2015.07.05 15:20:08 4: SOMFY_TimedUpdate
2015.07.05 15:20:08 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 4.62 sec
2015.07.05 15:20:08 4: SOMFY_TimedUpdate
2015.07.05 15:20:08 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 4.29 sec
2015.07.05 15:20:11 4: SOMFY_TimedUpdate
2015.07.05 15:20:11 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 1.62 sec
2015.07.05 15:20:11 4: SOMFY_TimedUpdate
2015.07.05 15:20:12 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.21 sec
2015.07.05 15:20:12 4: SOMFY_TimedUpdate
2015.07.05 15:20:12 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY_TimedUpdate
2015.07.05 15:20:13 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY Az_FRolladen stop
2015.07.05 15:20:14 4: SOMFY Bd_FRolladen stop


Immer noch 12, statt 10.6 Sekunden.

Nun nur set Bd_FRolladen Sonnenschutz
2015.07.05 15:32:38 4: SOMFY Bd_FRolladen on
2015.07.05 15:32:39 4: SOMFY_TimedUpdate
2015.07.05 15:32:39 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.63 sec
2015.07.05 15:32:42 4: SOMFY_TimedUpdate
2015.07.05 15:32:42 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 4.63 sec
2015.07.05 15:32:45 4: SOMFY_TimedUpdate
2015.07.05 15:32:45 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.63 sec
2015.07.05 15:32:47 4: SOMFY_TimedUpdate
2015.07.05 15:32:47 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:32:48 4: SOMFY Bd_FRolladen stop


Wenn ich nur einen Roll verfahre, wird die Position exakt angefahren. Jetzt steht der Bd genau da, wo er soll.

Ich kann mir allerdings kaum vorstelllen, wo fhem bei zwei Rolos seine Zeit verschwendet, dass kann doch kaum in die Sekunden gehen...!?

Mir ist im übringe aufgefallen, dass in EXACT auch nur die gerundeten Werte stehen. Das spielt zwar nur dann eine Rolle, wenn man häufig positioniert und zwischen drin nicht auf die Endpositionen fährt.
Zur Berechnung: Ich hatte das so gemacht, dass nach Ablaufen der Zeit die Routine die tatsächlich vergangene Zeit benutzt und die Startzeit davon abzieht. Die Start- und Endezeiten habe ich genau kurz vor dem 'Senden des Somfy-Befehls ermittelt.


Zitat:
Die Vermutung ist also, dass möglicherweise diese Befehle durch Funk überlagert werden, oder aus anderen Gründen nicht empfangen werden.  Bei mir ist ein CUL433 nur für Somfy-senden zuständig in einem Holzhaus und da habe ich einen Rolladen im Dachgeschoss, der etwa jeden 10. Befehl nicht


Dachte ich auch daran. Nun "wissenschaftlich" ausgetestet. Mehrfach wiederholt, warte jetzt drauf, dass die Nachbarn die Polizei geholt haben

Den Az_Roll kann ich von geschlossen auf Sonnenschutz fahren, klappt immer, wenn ich nur ihn verfahre.

Führe ich aber den Befehl immer gleichzeitig für zwei Rollos aus, dann bleibt der Az-Roll nicht bei Sonnenschutz stehen, sondern fährt auf offen.

Gemäß log würden die Sendebefehle ja wie folgt abgearbeitet:

Az -> offen
Bd -> offen
Az -> stop (Roll reagiert nicht, fährt auf offen)
Bd -> stop bleibt bei pos 80 stehen.

100 % reproduzierbar bei 5 Versuchen (ich höre schon das Tatütata.. ).

Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.

Hier noch mal das log:
2015.07.05 15:44:03 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :200:
2015.07.05 15:44:03 3: SOMFY_set: handled command pos --> move :off:  newState :200:
2015.07.05 15:44:03 4: SOMFY_sendCommand: Az_FRolladen -> cmd :off:
2015.07.05 15:44:03 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
2015.07.05 15:44:03 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos:  arg1 :80:  pos :200:
2015.07.05 15:44:03 3: SOMFY_set: handled command pos --> move :off:  newState :200:
2015.07.05 15:44:03 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :off:
2015.07.05 15:44:03 4: SOMFY_set: Bd_FRolladen -> stopping in 5.15 sec
2015.07.05 15:44:04 4: SOMFY Az_FRolladen off
2015.07.05 15:44:05 4: SOMFY Bd_FRolladen off
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
2015.07.05 15:44:08 4: SOMFY_TimedUpdate
2015.07.05 15:44:08 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:44:09 4: SOMFY_TimedUpdate
2015.07.05 15:44:09 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:44:09 4: SOMFY Bd_FRolladen stop
2015.07.05 15:44:10 4: SOMFY Az_FRolladen stop


Was mich aber verunsichert, sind die angegebenen Fahrzeiten für die Rollos, bei dem Bd sieht das ja plausibel aus, beim dem Az aber überhaupt nicht.
Oder ist die Log-Ausgabe nicht plausibel?
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
Das sind doch berechnete Zeiten, die nach Ablauf etwas tun sollen, also beim Az weit in der Zukunft liegen für das Stop...?


Elektrolurch

[viegener]

Zusammenfassung für den eiligen Leser
- Timing hat sich auch bei Elektrolurch durch meine Änderung siehe neues Somfy deutlich verbessert, ich schicke mal einen pull-request auf die Reise
- my-position / zusätzlich Stop hat wohl noch ein Problem, das bei mir nicht auftritt, da ich keine my-pos verwenden
- Vermutung meinerseits es gibt vielleicht ein Problem mit dem Senden, wenn Befehle sehr kurz hintereinander auftreten, hier müsste jemand mit CULFW know how helfen

Zitat:
Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet

Wird das tatsächlich gesendet? Denn bei stehendem Rollo fährt das Stop-Kommando ja in die gespeicherte (mygo) - Position.
So einen Effekt hatte ich, wenn die drive-Attribute nicht korrekt sind und der Rolo schon oben oder unten ansteht und dann das "stop" kommt. Dann fährt er halt auf die gespeicherte Position.
stop sollte man also auf keinen Fall senden, wenn der Rollo schon an der gewünschten Positionsteht.
Ich hatte da ursprünglich in der set-Routine ein return mit Ext, wenn die Position schon angefahren wurde und erneut angefahren werden sollte.

Ok, das ist neu für mich, da ich keine my-pos mehr an den Rolläden benutze. Soweit ich das verstanden hatte gibt es zwei verschiedene Kommandos 11 my-pos und 10 für stop. Also wenn Du über fhemweb ein Stop sendest bewegt sich der Rolladen zur my-pos, kannst Du das verifizieren? Es wäre sicher möglich das stop Kommando auszubauen.

2015.07.05 15:20:02 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec

2015.07.05 15:20:12 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
Immer noch 12, statt 10.6 Sekunden.

Nein, wenn Du das Log genau anschaust, ist das Problem weg. Es läuft von :02 bis :12 bzw. :02 bis :13 also passend für die 10.64 sec

Das scheint also auch bei Dir Verbesserung zu bringen.

Mir ist im übringe aufgefallen, dass in EXACT auch nur die gerundeten Werte stehen. Das spielt zwar nur dann eine Rolle, wenn man häufig positioniert und zwischen drin nicht auf die Endpositionen fährt.

EXACT wird auch etwas gerundet, soweit ich weiss auf ganze Zahlen (oder ganze Zahlen). Ich wollte da keine Genauigkeit verwende, die so durch Zeitabläufe nicht erreichbar ist. Ich hatte mal bei unbelastetem System mal Serien gemacht 0-70-100-70-0-... und dabei waren jeweils an der Position 70 Fluktuation um die 10cm herausgekommen, die hatte ich für tolerabel gehalten, da sie sich bei mir nicht aufgeschaukelt hatten.

Zur Berechnung: Ich hatte das so gemacht, dass nach Ablaufen der Zeit die Routine die tatsächlich vergangene Zeit benutzt und die Startzeit davon abzieht. Die Start- und Endezeiten habe ich genau kurz vor dem 'Senden des Somfy-Befehls ermittelt.

So ähnlich wurde das auch gemacht, das Problem war, das sich die berechnete nächste Laufzeit auch auf den selben Zeitstempel bezog, aber nach dem BulkUpdate ein neuer Zeitstempel verwendet wurde. Es wurden also von da ab 3 Sek laufen gelassen und nicht 3 Sekunden seit der Berechnung (wie gesagt, das scheint ja jetzt bei Dir auch zu funktionieren).

Dachte ich auch daran. Nun "wissenschaftlich" ausgetestet. Mehrfach wiederholt, warte jetzt drauf, dass die Nachbarn die Polizei geholt haben

Den Az_Roll kann ich von geschlossen auf Sonnenschutz fahren, klappt immer, wenn ich nur ihn verfahre.

Führe ich aber den Befehl immer gleichzeitig für zwei Rollos aus, dann bleibt der Az-Roll nicht bei Sonnenschutz stehen, sondern fährt auf offen.

Gemäß log würden die Sendebefehle ja wie folgt abgearbeitet:

Az -> offen
Bd -> offen
Az -> stop (Roll reagiert nicht, fährt auf offen)
Bd -> stop bleibt bei pos 80 stehen.

100 % reproduzierbar bei 5 Versuchen (ich höre schon das Tatütata.. ).

Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.

Hier bin ich überfragt, das klingt wirklich nicht nach Funkübedeckung, da immer dasselbe Kommando fehlt. Da bräuchten wir jetzt HIlfe von den CULFW-Leuten, bzw. Thomas, der das ja meines Wissens für die CULFW implementiert hat. Was verwendest Du denn als Sender CUL433 oder CUL868 und läuft da noch was anderes drauf? Welche Repetition hast Du eingestellt, kannst Du die mal runtersetzen?

Was mich aber verunsichert, sind die angegebenen Fahrzeiten für die Rollos, bei dem Bd sieht das ja plausibel aus, beim dem Az aber überhaupt nicht.
Oder ist die Log-Ausgabe nicht plausibel?
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
Das sind doch berechnete Zeiten, die nach Ablauf etwas tun sollen, also beim Az weit in der Zukunft liegen für das Stop...?

Sorry das Problem verstehe ich nicht.
Von pos 200 nach 80 heisst Fahrzeit von 200 nach 100 und dann noch bis 80
Fahrzeit von 200 nach 100 --> bei AZ 3.18 und
plus Fahrzeit von 100 nach 80 also --> (100-80)/100 * (17.67-3.18) = 2.898
macht 6.07...
Also stimmt die Berechnung und auch Nachkommastellen werden herangezogen, das hatte ich ursprünglich gar nicht getestet 

Gruss,
Johannes

[Elektrolurch]

Hallo Johannes,

ja, das ist so
set Roll stop
verfährt den Roll auf die gespeicherte Position.

Zitat:
Sorry das Problem verstehe ich nicht.
Von pos 200 nach 80 heisst Fahrzeit von 200 nach 100 und dann noch bis 80
Fahrzeit von 200 nach 100 --> bei AZ 3.18 und
plus Fahrzeit von 100 nach 80 also --> (100-80)/100 * (17.67-3.18) = 2.898
macht 6.07...
Also stimmt die Berechnung und auch Nachkommastellen werden herangezogen, das hatte ich ursprünglich gar nicht getestet 


Sorry. Das ist mein Screenreader, der macht aus 6.010 sechstausendzehn, aus 6.12 sechskommazwölf.
Da habe ich mich ins Boxhorn jagen lassen.

Ich könnte mir einen Work-around bauen:
Nicht direkt das fhem - Kommando absetzen, sondern das über eine sub machen, die die Kommandos sammelt und dann im Abstand von 10 s sendet.
Damit wäre das Problem umgangen, leider aber nicht verstanden

Elektrolurch

[viegener]

Wenn das Zeitintervall bekannt wäre, in dem Befehle zu KOnflikten führen, könnte man natürlich auch eine entsprechende Verzögerung einführen indem Vor dem Senden auf Zeitablauf gewartet wird.

Nachteil: die exakte Positionierung geht dann natürlich verloren.

Das mit dem zusätzlichen stop-Befehl sollte ich also auch ausbauen, allerdings nehme ich an, das könnte an mehreren Stellen passiern. Das muss ich wohl heute abend mal anschauen.

[viegener]

Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.

Ich habe mal grob durchgeschaut in der culfw, es sieht nicht so aus, als ob eine Pause von 200ms bei Somfy-Kommandos in der CULFW vorkommt. Allerdings ist das Protokoll ansonsten vollständig d.h. es gib auch die Pause zwischen zwei Befehlen.

Interessant ist, dass bei Dir ja genau der Stop-Befehl Az, der kurz nach dem Stop von Bd gesendet wird. Das Spricht für die Vermutung, dass der zweite Befehl aus irgendeinem Grund nicht durchkommt, wenn kurz davor ein anderer Befehl gesendet wurde.

Damit wäre eine zentrale Pause im Somfy-Modul vielleicht wirklich eine Lösung, allerdings habe ich noch keine einfache Idee gehabt, wie man das implementieren könnte ohne aufwändige Queue- oder Timer-Verwaltung

[viegener]

Interessant ist, dass bei Dir ja genau der Stop-Befehl Az, der kurz nach dem Stop von Bd gesendet wird. Das Spricht für die Vermutung, dass der zweite Befehl aus irgendeinem Grund nicht durchkommt, wenn kurz davor ein anderer Befehl gesendet wurde.

Damit wäre eine zentrale Pause im Somfy-Modul vielleicht wirklich eine Lösung, allerdings habe ich noch keine einfache Idee gehabt, wie man das implementieren könnte ohne aufwändige Queue- oder Timer-Verwaltung

Ich habe mal durchgerechnet, bei Standardmässig 6 wiederholungen dauert das Senden eines Somfy-komandos etwa 300ms. Dazu kommen noch Übertragungen, Umschaltzeiten und die anderen CUL-Kommandos, die jeweils vorher gesendet werden, das kann eng werden. Allerdings erklärt das für mich die Probleme nicht.

[viegener]

Hallo Johannes,

ja, das ist so
set Roll stop
verfährt den Roll auf die gespeicherte Position.

@elektrolurch : Anbei ist eine aktualisierte Version, die kein Stop mehr schicken sollte, kannst Du die mal ausprobieren?

Danke,
Johannes

[thdankert]

@Johannes: Danke für deine Bemühungen! Ich habe gerade leider zu wenig Zeit, um mich richtig um das Somfy-Modul zu kümmern.

Kurz zum Verhalten: Die Ingenieure bei Somfy waren so schlau, Stop und Go-My auf den gleichen Funkbefehl zu legen, d.h. schicke ich "stop" an einen Rolladen, der schon steht, geht der auf die "my" Position.

Ich habe intern im Modul 2 Befehle daraus gemacht (10 und 11), um zu unterscheiden, was der User geschickt hat.

Zum Protokoll: ein Frame ist ca. 80ms lang + 30ms Pause, also 110ms. Macht bei 6 Wiederholungen 660ms, das merkt man schon deutlich.
Der Code in der CULFW macht allerdings den HW-Sync zu kurz, vielleicht ist das ein Problem, wenn die Kommandos schnell hintereinander kommen.
Am Wochenende habe ich Zeit und kann mit meinen Rollos (und den Frame-Zeiten) spielen, vielleicht kann ich das auch hier nachstellen.

Grüße,
Thomas

[Elektrolurch]

Hallo,

habe jetzt erst einmal einen kleinen Workaround gebastelt:
Die Aurfrufe der Somfy-Befehle laufen über eine sub. Das hatte ich immer schon so, denn darin wird geprüft, ob noch jemand auf der Terrasse ist und das Rollo wird später heruntergefahren, wenn keiner mehr draussen ist.
Insofern war es dann einfach, die restlichen direkten Somfy-Aufrufe (der Beschattungssteuerung) auszubauen und auch über diese sub zu leiten.
Die schreibt die Befehle in ein array und startet einen internen Timer, der den Puffer alle 10 Sekunden um einen Befehl leert.
Damit ist das Problem des Sendetimings erst einmal umgangen und die Rollos fahren auch wieder genau dahin, wo sie auch sollen.

Das mit dem stop-Befehl ist solange ein Problem, solange man nicht genau weiß, wo der Rolladen exakt steht. Wird er z.B. über eine FB verfahren, so weiß fhem ja nichts davon. Soll dann über die Kombi aus moveup(oder down) und stop eine genaue Position angefahren werden, kann das dann schon mal schief gehen. Der Rollo erreicht vor dem stop-Befehl eine Endposition. Kommt dann der stop, so fährt der Rollo auf die go-my Position.
Auf die Weise habe ich mit besagter Terrassentür schon einige Sprints einlegen müssen, um mich nicht auszusperren.

Elektrolurch

[viegener]

Das mit dem stop-Befehl ist solange ein Problem, solange man nicht genau weiß, wo der Rolladen exakt steht. Wird er z.B. über eine FB verfahren, so weiß fhem ja nichts davon. Soll dann über die Kombi aus moveup(oder down) und stop eine genaue Position angefahren werden, kann das dann schon mal schief gehen. Der Rollo erreicht vor dem stop-Befehl eine Endposition. Kommt dann der stop, so fährt der Rollo auf die go-my Position.
Auf die Weise habe ich mit besagter Terrassentür schon einige Sprints einlegen müssen, um mich nicht auszusperren.

Elektrolurch

OK, eine generelle Lösung Pausen zwischen den Befehlen zu erreichen werde ich jetzt erstmal nicht angehen. Wenn ich das richtig verstehe, befindet sich Deine sub ausserhalb des 10_Somfy-Moduls?

Den zusätzlichen Stop-Befehl habe ich ausgebaut (Version oben), gibt es dazu Erfahrungswerte?

Das mit der zusätzlichen manuellen Bedienung durch eine Fernbedienung habe ich bei mir durch einen fhemduino gelöst, der diese Befehle empfängt und auch als Somfy-Modul weitergibt. Dadurch wird die Positionierung auch im Falle der manuellen Bedienung korrekt. Bei mir geht es sogar, dass ich in fhem von ganz offen auf Pos 50 fahren lasse und frühzeitig stop auf der manuellen FB drücke sodass der Rolladen stoppt und die Position in fhem korrekt aktualisiert wird (z.B: bei 30). Das ist bei uns auch nötig, da immer noch mehr als die Hälfte der Befehle über die Fernbedienungen erfolgt.

Johannes