10_SOMFY.pm - Somfy RTS (und kompatible)

[Juergen27]

@UliD: Sorry ich wollte keine Schwarzmalerei betreiben, sondern nur auf den möglichen worst case hinweisen. Ich drück die Daumen, dass es sich in der Software versteckt. 

[viegener]

@UliD: Mmmh - dabei entstehen jetzt wieder weitere Fragen, denn Du hast ja doch nicht nur einen Standard CUL sondern auch einen RFR_Cul. Ich hatte schon so eine Vermutung, denn eigentlich ist der Somfy_Parse eher eine Bestätigung dafür, dass der Befehl vom einem Cul beim anderen empfangen wird.

Das ist aber auch schonmal ein relevanter Teil: Also nach dem list hast Du 2 CULs einen RFR und einen direkt am Raspberry --> damit sind es natürlich bereits 3 verschiedene Funksituationen CUL->SOMFY  RFR_Cul->SOMFY CUL-->RFR_CUL

Meine erste Vermutung geht nicht zu einem Softwareproblem (weder auf dem CUL noch in FHEM), sondern dass vielleicht doch die Sendesituation in manchen Fällen gestört ist - entweder bei einem der beiden CULs oder durch dynamische Veränderungen (also Hindernisse oder andere Einflüsse). Leider ist das auch am schwersten zu lösen insbesondere da es unterschiedliche Rolläden betrifft.

Zum Thema kurzanlaufen: Wenn es keine Programmierbestätigung ist dann müsste ja ein expliziter Stopbefehl gesendet werden. Das würde sich im log finden . Also auf Softwareseite würde ich das eher ausschliessen. Wenn der Befehl gesendet wird (und im list unten ist nicht kennbar, dass Du mit Timings also expliziten POsitionen arbeitest) würde kein Stopbefehl direkt nach dem Befehl gesendet. Also wenn nicht Programmierbestätigung, dann liegt dieser Fehler vermutlich eher am Rolladen (vielleicht schlägt die automatische Abschlatung bei Blockieren oder ähnliches zu ?)

Anmerkung: Bitte setze doch lists und log einträge in "Code blocks" über den # button

[UliD]

@viegener: Ja, CUL und RFR_CUL sind beide im Einatz. Dies, um evtuelle Reichweiten-, Abschirmungs- oder Störquellenprobleme zu umgehen.
Bevor der RFR im Einsatz war hatte ich lange Zeit nur einen CUL am RPi3, dann für kurze Zeit testweise die Sendeleistung des CUL Stick nennenswert erhöht, jetzt ist seit ein paar Wochen der RFR im Einsatz. Das Verhalten ist immer das gleiche, keine Veränderung. Daher nehme ich erst einmal an, dass es nicht an der Umgebung liegt. Wäre auch äußerst schwierig zu untersuchen, da stimme ich dir zu und deshalb schaue ich ja zunächst bei den Baustellen, die ich leichter untersuchen kann um hier mögliche Fehler auszuschließen. Naja, soweit meine Möglichkeiten reichen.

Durch die Log Files sehe ich nun, dass die Befehlssequenzen an SOMFY wohl korrekt sind: Wenn ein Rollladen nicht läuft und ich schicke die gleiche Sequenz nochmals - mit angepasstem Rolling Code und Key - dann funktionierts ja. Somit wäre 10_SOMFY.pm erst einmal raus.

Nun tauche ich gerade etwas tiefer in die F/W des CUL ein.
In anderem Post schrieb ich ja bereits, dass die Frequenzeinstellung für SOMFY in der CUL F/W m.E. durch ein Copy&Paste Problem falsch eingestellt ist. Nicht massiv falsch, aber bei grenzwertigen Empfangsproblemen vielleicht relevant.

Ein paar Artikel zum SOMFY Protokoll habe ich noch im Netz gefunden, u.a. eine Patentschrift, in der Somfy sein RTS Protokoll beschreibt. In den Artikeln wird in inkonsistenter Weise über die Pulslänge des Somfy Signals diskutiert. Der eine sagt 1208ms, der andere spricht von Tippfehler und misst 1280ms, so wie es auch in der Patentschrift beschrieben ist. Auch Pilight (pilight.org) nutzt für SOMFY 1280ms und attestiert gute Funktionalität damit.
Soweit ich das bislang im Quellcode des CUL erkennen konnte wird hier 1240ms als Pulslänge verwendet, was ich noch gar nicht nachvollziehen kann. Wie gesagt, da tauche ich gerade ein und werde das mal untersuchen. Vielleicht sind noch andere Zeitkonstanten oder Verzögerungen zu berücksichtigen, die es dann wieder auf 1280ms bringen. Wie gesagt, ich habe gerade erst begonnen, hier reinzuschauen.

Wenn dir noch etwas einfällt, dann höre ich gerne davon. Danke schon mal bisher.

Sollte ich bei meinen Untersuchungen fündig werden, dann werde ich das hier posten. Und wenn nicht, stelle ich die Rollläden wieder auf Tahoma um....

[andies]

Das kennst du https://pushstack.wordpress.com/somfy-rts-protocol/?

[UliD]

@andies: Ja, kenn ich.
Blätter dort mal zu den nachfolgenden "80 thoughts..."  bis zum Eintrag von "Johannes von FEBRUARY 28, 2015 AT 11:22 PM". Er bemerkt, dass 1208ms nicht gut funktionieren.
Oder auch in Patent No. US 8.189.620 B2, Seite 8, Spalte 8, Zeile 8: Dort wird ebenfalls von 1280ms Symbollänge gesprochen.
Und bei pilight.org werden auch 1280ms Symbollänge genutzt.
Selbst der Creator der CUL Erweiterung auf Somfy RTS stellt in der F/W im Kommentar fest, dass es bei 1208ms nicht gut funktioniert und er hat 1240ms gesetzt. Will da nix Böses unterstellen, aber 1240ms erscheinen mir etwas aus der Luft gegriffen. Nur weil's bei einigen Rollläden funktioniert muss es ja nicht allgemeingültig sein. 

Ich setze jetzt versuchsweise die Symbollänge auf 1280ms und schau mal, was meine Rollläden in den kommenden Wochen davon halten.

Apropos Symbollänge im CUL setzen:

Code: [Auswählen]

attr MYROLLLADEN symbol-length 1280 Wird im Logfile quittiert mit

Code: [Auswählen]

2021.10.09 07:30:15 3: MyRFR: Unknown code Yt: 1280, help me!oder

Code: [Auswählen]

2021.10.09 07:30:06 3: MyCUL: Unknown code Yt: 1280, help me!
Kompletter Auszug für einen Rollladen:

Code: [Auswählen]

2021.10.09 07:30:15 4: SOMFY_set: SZ.Rollo -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2021.10.09 07:30:15 4: SOMFY_set: handled command off --> move :off:  newState :open:
2021.10.09 07:30:15 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2021.10.09 07:30:15 4: SOMFY_sendCommand: SZ.Rollo -> cmd :off:
2021.10.09 07:30:15 5: SOMFY_send set symbol-length: t1280 for MyRFR
2021.10.09 07:30:15 4: SOMFY_send SZ.Rollo off: sA4200D16000004
2021.10.09 07:30:15 5: SOMFY_send SZ.Rollo enc key : A4  rolling code : 0D16
2021.10.09 07:30:15 5: SOMFY_send set symbol-length back: t1240 for MyRFR
2021.10.09 07:30:15 3: MyRFR: Unknown code Yt: 1280, help me!
2021.10.09 07:30:15 3: MyRFR: Unknown code Yt: 1240, help me!

Das hat nichts mit dem verwendeten RFR zu tun, denn auch bei den Rollläden, die direkt über einen CUL gesteuert werden ist diese Meldung vorhanden.
Nun weiß ich nicht, ob der CUL die Änderung der Symbollänge akzeptiert hat oder nicht. Weiß da jemand mehr?

[andies]

Ich nutze ja Signalduino in der Version von Ralf9 und habe da nie Probleme gehabt. Vielleicht istbdas eine Lösung?

[UliD]

Danke für den Tipp. Ich schau mir das mal an.

[UliD]

@andies: So, hab jetzt endlich einen SIGNALduino auf dem Tisch. Welche F/W Version nutzt du? Will ja nicht experimentieren sondern die Version nutzen, die bei dir keine Probleme macht.
Weitere Frage: Den Quellcode zur F/W gibt's vermutlich auf Github, doch dort finde ich eine Menge an Teilprojekten, keins einzelnes mit dem kompletten Code. Mich interessiert nur der Code, der SOMFY betrifft. Hast du einen Tipp wie ich da am besten heran komme?
Mit Suchen hab ich schon eine gute Zeit verbracht, dreh mich aber irgendwie im Kreis. Hilfe willkommen. Danke!

   

[andies]

Ich schreibe mal schnell meine Werte rein:

Code: [Auswählen]

   DEF        ESP-Signalduino.fritz.box:23
   DMSG       sD4680000D000
   DevState   initialized
   DeviceName ESP-Signalduino.fritz.box:23@57600
   FD         33
   FUUID      5e403ab8-f33f-1115-2890-d401c76b3f55795f
   FVERSION   00_SIGNALduino.pm:v3.4.2-s22409/2020-07-16
   IDsNoDispatch 2,72.1,82
   ITClock    250
   LASTDMSG   sD4680000D000
   LASTDMSGID 0.3
   MSGCNT     491441
   NAME       sduino
   NR         346
   NR_CMD_LAST_H 4
   PARTIAL   
   RAWMSG     MS;P1=481;P2=-3984;P3=-2006;P4=-8937;D=14121213121312131313121213121313131313131313131313131313131313131312121312;CP=1;SP=4;R=246;s=6;e;m3;
   RSSI       -79
   STATE      opened
   TIME       1635258845.58082
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   version    V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
   versionProtocols 1.21
   versionmodul v3.4.4Ich habe Ralf9s Firmware überspielt, dabei aber nichts selbst kompiliert. Also angeschlossen und dann auf „set sduino flash“ geklickt.

[UliD]

Jo danke. Habe auch bereits den SIGNALduino mit Firmware bestückt und kann Rollläden steuern. Das klappt nach erstem Test. Dauerbetrieb steht noch aus.
Nehmen wir an diese Firmware ist besser und alles funktioniert, dann interessiert mich immer noch, warum die FW des CUL so Probleme macht. Da ich ja eine Lösung habe wäre das ein akademisches Problem, aber eben ein Problem, dem ich auf die Schliche kommen will. Da Sendemodule gleich sind liegt's meiner Meinung nach an der Firmware. Und ich denke, dass ich aus dem Quellcode des SIGNALduino Einiges entnehmen kann. Ist ja alles offen, nur finde ich nicht DAS EINE ZIP File, in dem alles enthalten ist. Wenn du da etwas sagen kannst, wäre das prima. 

[andies]

Leider weiß ich das nicht, da musst du Ralf9 fragen.

Wenn ich das richtig erinnere (und kapiere), besteht der grundsätzliche Unterschied darin, wo die Auswertung des Funksignals erfolgt: Beim CUL wohl intern, während der Signalduino die Sequenz an das Modul weiterreicht und FHEM auswerten lässt. Ich habe zum Beispiel beobachtet, dass bei hoher Rechenleistung des arduino dann auf einmal die Flanken nicht sauber erkannt werden und es deshalb zu einer Fehlerkennung der Signal kommt. Irgend so etwas stelle ich mir hier auch vor. Deswegen geht ja zum Beispiel ein Signalduino auf dem ESP nicht, das ist einfach nicht sauber.

Ich habe mir das vor Jahren mal bei einem 433MHz-Modul angeschaut: https://forums.raspberrypi.com/viewtopic.php?f=28&t=164177#p1060285

[UliD]

Bei CUL im "SOMFY-MODE" geht es nur um's Senden, Empfang wird nicht unterstützt und ist auch unerheblich, da SOMFY-RTS keine Quittung sendet. Daher vermute ich hier erst einmal kein Problem.
Ich nutze den CUL nur für Rollläden und zwei IT Lampen, aber die Lampen werden nicht gesteuert wenn Rollläden aktiv werden. Gut, es könnte immer noch ein Timing Problem aufgrund eines Houskeepings im CUL sein, aber das halte ich auch erst mal für sekundär. Zu viele Gründe sprechen für mich dagegen.

Meine ursprünglich angemerkte falsche Frequenzeinstellung beim CUL für SOMFY ist beim SIGNALduino korrekt. Daran sollte es nicht mehr liegen. Jetzt geht es mir daher um's Timing.

Beim CUL lässt sich die Pulslänge als Parameter übergeben und ist damit von außen einstellbar, doch das ist leider nur die halbe Miete. Pulslängen für Synchronpuls und Pausen sind im CUL hartkodiert, sind also durch Parameter nicht beeinflussbar. Mit Verlaub kein besonders guter Stil in der Kodierung, da Synchronpulse Vielfache der Basispulslänge sind. Änderungen sind hier allemal notwendig.
Bevor ich aber die Firmware im CUL abändere will ich erst mal nachlesen, wie die es machten, bei denen soweit keine Probleme bekannt sind.

Wie schon erwähnt: Pilight verwendet Pulslängen, die ich aus allen Dokumentationen (nach Korrektur eines vermuteten Vertippsers) herauslesen kann. Jetzt interessieren mich die Zeiten, die für SIGNALduino verwendet werden.

@Ralf9: Solltest du hier mitlesen, dann gib mir bitte einen Tipp, wo ich das Modul finden kann, in dem das Sende-Timing für SOMFY abgelegt ist. Solltest du nicht mitlesen belästige ich dich demnächst mit einer PM ;-)

Und dir, andies, danke für Hilfestellung soweit. Sobald ich eine Lösung für den CUL habe werde ich das hier mal posten.

[Ralf9]

Jetzt interessieren mich die Zeiten, die für SIGNALduino verwendet werden.

Die Zeiten stehen in den Protokolldefinitionen

Bei der offiziellen Version von Sidey stehen sie in:
FHEM/lib/SD_ProtocolData.pm
Bei meiner 00_SIGNALduino.pm Version stehen sie in:
FHEM/lib/signalduino_protocols.pm

Es ist die Protokolldefinition Nr 43
Der Sendeclock ergibt sich aus "clockrange     => [610,680],"
Clock = (610 + 680) / 2

Es wird als manchester gesendet.
Da gibt es
SL (short low) = -clock
SH (short high) = clock
LL (long low) = -clock * 2
LH (long high) = clock * 2

Gruß Ralf