10_SOMFY.pm - Somfy RTS (und kompatible)

Begonnen von viegener, 12 Mai 2016, 21:06:46

Vorheriges Thema - Nächstes Thema

isy

#510
Die FB  Somfy Keytis 2 NS RTS und beide Garagentore sind natürlich von Somfy, Frequenz 433,42 MHz
So sieht sie aus:
https://www.1001telecommandes.com/telecommandes-par-marque/telecommande:SOMFY:KEYTIS-NS-2-RTS.html
Ein Weg wird erst zu einem Weg, wenn man ihn geht

nagelreo

Hallo Helmut,

dann wird es wohl so sein, die Sende Frequenz der FB (GX328 oder Keytis 2N RTS ?) ist vermutlich sehr breit und wird auch noch bei 433.92 MHz von deinem sduino433 erkannt. Das hängt zusätzlich von der am sduino eingestellten bWith ab.

Was mich jetzt noch wundert und etwas beunruhigen würde, ist, dass sich das Garagentor mit dem per autocreate angelegten device ohne Anmeldung steuern lässt.
Bei meinen Somfy Rollos muss das Fhem device am Rollo als FB angelernt werden.

Gruß Rolf

isy

Moin Rolf,

der Signalduino steht auf
Freq: 433.920 MHz, Bandwidth: 464 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
Die Empfänger in den Garagentoren sind wohl breitbandig genug.
-
Die älteren Steuerungen werden auf den Schalter angelernt, an dem kann man nichts einstellen. Die aktive Rolle geht also von der Fernbedienung aus, das jeweilige Garagentor muss im "Anlernmodus" (oder wie das heißt) stehen.

Wenn jetzt der Signalduino den Schalter simuliert (ich vermute die Parameter "ADDRESS", "enc_key" und "rolling_code" als relevant), dann merkt die Torsteuerung gar nicht, dass es sich nicht um die angelernte Fernbedienung handelt.

Ich habe 4 dieser Handsender, die alle mit den gleichen Tastenzuordnungen angelernt sind. Nur eine einzige Fernbedienung hat am Signalduino die Devices anlegen können. Die anderen erzeugen nur FM im Log.

Bedeutet anders herum, dass jeder, der sich auskennt (Sniffen des Datenstroms, wie bei einigen Autos) und den richtigen Code dann hat, mit einem beliebigen Handsender/Signalduino das Tor öffnen kann. Also auch der Nachbar oder eher weniger freundliche Zeitgenossen.

Gruß Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Ralf9

ZitatIch habe 4 dieser Handsender, die alle mit den gleichen Tastenzuordnungen angelernt sind. Nur eine einzige Fernbedienung hat am Signalduino die Devices anlegen können.
Bitte setze mal die Frequenz auf 433.42 und das sduino Attribut verbose auf 4.

Bitte drücke dann bei jedem Handsender ein paar mal die Tasten und Poste dann die empfangenen MC-Nachrichten.

Die MC-Nachrichten sehen ungefähr so aus:
MC;LL=-1307;LH=1266;SL=-674;SH=568;D=A2BC9C1721A611;C=635;L=56;

Kannst mir auch per pm schicken, wenn Du die Daten nicht veröffentlichen willst.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

isy

Hallo Ralf,
was willst du machen mit den Daten?
Ich würde ungern die Informationen zum Öffnen der Garagen verschicken.

VG Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht

andies

Er testet damit das Modul auf Fehler. Habe ich ihm auch schon geschickt, mach das per PM.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ralf9

hat sich inzwischen per PM geklärt, ist ein bekanntes Problem der firmware und dem 00_SIGNALduino.pm Modul von Sidey
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Diamant80

Hi Zusammen,

ich habe in meiner FHEM Umgebung meine drei Somfy RTS Markisen eingebunden und es funktioniert (fast) alles perfekt.
- Die Einzelsteuerung hoch/runter/stop funktioniert
- RawDevice hinterlegt -> FHEM registriert das Kommando und passt die Position der einzelnen Markise an --> Funktioniert

Jetzt fehlt nur noch das Sahnehäubchen. Auf meiner Telis RTS habe ich einen Kanal, auf welchem zwei Markisen gleichzeitig angesteuert werden.
Der Befehl wird auch von FHEM erkannt und das Gerät angelegt. Unter attr rawDevice müsste ich nun einfach die zwei Markisen hinterlegen. Ich habe versucht beide Geräte mit einem Komma zu trennen (Gerät1,Gerät2), dass funktioniert nur leider nicht. Gibt es eine Möglichkeit auch zwei Geräte bei rawDevice zu hinterlegen?

Viele Grüße!

Diamant80

Habe es soeben heraufgefunden :-)
Ihr müsst die Devices einfach mit Leerzeichen trennen.
Also zb: 111111 222222

UliD

Habe mit meinen SOMFY RTS ein paar Probleme und suche Hilfestellung oder Tipps, wie ich weiter vorgehen kann.

Insgesamt steuere ich acht Rollläden an, von denen manche sporadisch die Befehle zum Öffnen oder Schließen entweder gar nicht annehmen, oder aber nur mit einem kurzen Anlaufen signalisieren, dass sie nicht weiter laufen wollen. Nach solch einem Zucken z.B. beim Hochfahren muss ich zunächst wieder den Befehl "Schließen" geben, anschließend funktioniert das Hochfahren wieder.
Ein- bis zweimal pro Woche steigt einer der Rollläden aus.

Hardware: Ich steuere vom RPi3 aus, original BUSWAR CUL Stick, aktuelle Firmware.

Probleme mit Sende- / Empfangsleistung schließe ich aus, nachdem ich die Gerätschaften inkl. Sendeantenne testweise bis auf wenige Meter an die betroffenen Rollläden positioniert habe und keinerlei Veränderung bemerken konnte. Tests hatte ich auch mit einem CUL RFR durchgeführt, keine Besserung.

Letztendlich habe ich für alle Rollläden das Attribute verbose auf 4 gesetzt und erhalten mehr Einträge im Logfile. Genau dabei ist mir Folgendes aufgefallen, was ich nicht erklären kann:

Bei ordnungsgemäßem Lauf sehe ich im Logfile insgesamt fünf Einträge, Beispiel:

2021.10.01 07:30:00 4: SOMFY_set: GZ.Rollo -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2021.10.01 07:30:00 4: SOMFY_set: handled command off --> move :off:  newState :open:
2021.10.01 07:30:00 4: SOMFY_sendCommand: GZ.Rollo -> cmd :off:
2021.10.01 07:30:00 4: SOMFY_send GZ.Rollo off: sAC200C76000001
2021.10.01 07:30:00 4: SOMFY Parse: GZ.Rollo msg: YsAC280C76010000  --> 20-off   --> io is CUL

Bei kurzen Anlauf oder aber wenn der Befehl gar keine Reaktion auslöst habe ich festgestellt, dass im Logfile die letzte Zeile (SOMFY Parse...) fehlt, also nur Folgendes steht:

2021.10.01 07:30:00 4: SOMFY_set: GZ.Rollo -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2021.10.01 07:30:00 4: SOMFY_set: handled command off --> move :off:  newState :open:
2021.10.01 07:30:00 4: SOMFY_sendCommand: GZ.Rollo -> cmd :off:
2021.10.01 07:30:00 4: SOMFY_send GZ.Rollo off: sAC200C76000001

Dies habe ich nun über längeren Zeitraum und für alle Fehlerfälle beobachtet.

Ob im Problemfall das Fehlen des Eintrags "SOMFY Parse... " auf gleicher Fehlerursache basieren oder aber das Fehlen auf die Ursache des Problems deutet erschließt sich mir nicht. Frage an die Experten, wo ich denn weitersuchen kann, um dem Fehler auf die Schliche zu kommen.

viegener

@UliD: Deine Erkenntnisse sehen interessant aus, aber die logfile-Einträge unten sind ja nur symbolisch, denn der zweite EIntrag ist ja nur um die zusätzliche Zeile gekürzt. Es wäre wirklich interessant einen Logausschnitt zu sehen, wenn das Senden gerade nicht funktioniert. Am besten mit verbose 5

Ausserdem wäre ein list des entsprechenden ROlladen-Device wichtig, denn so fehlt mir noch Kontext.

Wenn der Rolladen sich nur ein kurzes Stück bewegt, dann wird wohl ein Kommando gesendet, also ist die Frage, warum der Rolladen gleich wieder anhält. Kurzes Anlaufen passt entweder auf einen Prog-Befehl, der vom Rolladen quittiert wird oder darauf dass FHEM der Ansicht ist, dass der Rolladen die Zielposition bereits erreicht hat.
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

UliD

Okidoki, ich setze verbose auf 5 und warte auf den nächsten Störfall. Dann sende ich die gewünschten Daten.

Das mit dem kurzen Anlauf sehe ich nicht als Quittung des Rolladen. M.E. wird eine Quittung derart signalisiert, dass der Rolladen kurz in die eine Richtung, dann sofort kurz in die andere Richtung läuft. Das ist bei mir nicht der Fall.
Sobald hier ein Rolladen nur kurz anläuft muss ich ihn per Befehl (oder SOMFY Fernbedienung) zunächst in die entgegengesetzte Richtung starten, dann den ursprünglichen Befehl nochmals senden. Es scheint also, dass der Rolladen das Empfangssignal irgendwie als Endsignal interpretiert.

Und auch wenn es als Modulautor nicht deine direkte Baustelle ist: M.E. ist in der CUL FW ein Fehler. Beschrieben habe ich das hier: https://forum.fhem.de/index.php/topic,117898.msg1123228.html#msg1123228

Juergen27

@UliD: Ich kenne ein ähnliches Problem mit unseren Aussenrollos. Manchmal bleiben einige mittendrin (auch bei der Solaris Automatik, bzw. manuellen Fahren über die zugeordnete Fernbedienung) stehen und lassen sich nur weiterfahren wenn man kurz in die andere Richtung fährt. Es scheint also nicht unbedingt ein Fehler vom Modul, CUL oder FHEM sondern könnte auch ein Hardwarefehler sein. Wir haben das ein paar Mal mit dem Verkäufer, Installateur und auch einem Vertiebsmitarbeiter der Herstellerfirma "diskutiert", haben aber nur entgeisterte Gesichter und keine Lösung für das Problem bekommen.

Vielleicht hat Dein Verkäufer mehr Ahnung von der Materie. Wir haben uns damit abgefunden und wenn der erste Rolladen den Geist komplett aufgibt bzw. der Stoff wieder abgeht, wird auf eine andere Firma gewechselt.

Gruss Jürgen
Cubietruck 3.4.107 / Debian GNU/Linux 7.8 (wheezy), verschiedene Homematic und Somfy Komponenten

UliD

@Juergen2: Danke für's Mut machen  :-[. Mit den SOMFY Handfernbedienungen und TAHOMA habe ich über lange Zeit keinerlei Probleme gehabt und jetzt sind es auch nicht alle Rollläden, die gelegentlich aussteigen.  Mit scheint, dass in der SW irgendwo etwas "knapp auf Kante genäht" ist, doch ich komme der Ursache nicht auf die Schliche. Daher mein Hilfeschrei hier. Irgendwer hat bestimmt noch eine Idee.

UliD

@viegener: Heute früh hat einer der Kandidaten wieder den Dienst versagt. Es war kein kurzer Anlauf sondern nur "toter Mann spielen". Ich konnte der Rollladen zum Hochlauf bewegen, indem ich den Befehl ein zweites Mal absetzte. Zwar erst eine Stunde Später, aber egal.

Hier der Auszug aus dem Log: 

2021.10.07 07:30:35 4: SOMFY_set: WZ.Rollo -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2021.10.07 07:30:35 4: SOMFY_set: handled command off --> move :off:  newState :open:
2021.10.07 07:30:35 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2021.10.07 07:30:35 4: SOMFY_sendCommand: WZ.Rollo -> cmd :off:
2021.10.07 07:30:35 4: SOMFY_send WZ.Rollo off: sA9200C16000008
2021.10.07 07:30:35 5: SOMFY_send WZ.Rollo enc key : A9  rolling code : 0C16

WZ.Rollo fuhr 07:30:35 nicht hoch, erst 09:04.49 habe ich nachfolgenden Befehl abgesetzt. Vorheriges Fahren in entgegengesetzte Richtung war nicht notwendig,
auch erkennbar am Rolling Code und an der Ausgangsposition.

2021.10.07 09:04:49 4: SOMFY_set: WZ.Rollo -> entering with mode :send: cmd :off:  arg1 ::  pos :0:
2021.10.07 09:04:49 4: SOMFY_set: handled command off --> move :off:  newState :open:
2021.10.07 09:04:49 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2021.10.07 09:04:49 4: SOMFY_sendCommand: WZ.Rollo -> cmd :off:
2021.10.07 09:04:49 4: SOMFY_send WZ.Rollo off: sAA200C17000008
2021.10.07 09:04:49 5: SOMFY_send WZ.Rollo enc key : AA  rolling code : 0C17

Auffällig am Protokollauszug von gestern Abend: SOMFY Parse ist heute früh nicht drin, weder beim Fehlversuch noch beim nachgeschickten Befehl.

2021.10.06 19:09:51 4: SOMFY_set: WZ.Rollo -> entering with mode :send: cmd :on:  arg1 ::  pos :0:
2021.10.06 19:09:51 4: SOMFY_set: handled command on --> move :on:  newState :closed:
2021.10.06 19:09:51 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2021.10.06 19:09:51 4: SOMFY_sendCommand: WZ.Rollo -> cmd :on:
2021.10.06 19:09:51 4: SOMFY_send WZ.Rollo on: sA8400C15000008
2021.10.06 19:09:51 5: SOMFY_send WZ.Rollo enc key : A8  rolling code : 0C15
2021.10.06 19:09:51 4: SOMFY Parse: WZ.Rollo msg: YsA8460C15080000  --> 40-on   --> io is CUL_RFR

Bei meinen anderen Rollläden fehlt heute bei ALLEN Rollläden das SOMFY Parse, wenn die Rollläden über den CUL_RFR gesteuert werden. Diejenigen, die über den CUL angesprochen werden haben den SOMFY Parse Eintrag im Log.

Hier noch das list zum Rollo:

Internals:
   ADDRESS    000008
   DEF        000008
   FUUID      603f848a-f33f-4182-8008-3018350018d3b92f
   IODev      MyRFR
   LASTInputDev MyCUL
   MSGCNT     28
   MyCUL_MSGCNT 1
   MyCUL_RAWMSG YsAB2E0C18080000
   MyCUL_TIME 2021-10-07 09:16:51
   MyRFR_MSGCNT 27
   MyRFR_RAWMSG YsA8460C15080000
   MyRFR_TIME 2021-10-06 19:09:51
   NAME       WZ.Rollo
   NR         159
   STATE      open
   TYPE       SOMFY
   move       off
   CODE:
     1          000008
   READINGS:
     2021-10-07 09:16:50   enc_key         AB
     2021-10-07 09:16:50   exact           0
     2021-10-07 09:16:51   parsestate      off
     2021-10-07 09:16:50   position        0
     2021-10-07 09:16:51   received        20
     2021-10-07 09:16:50   rolling_code    0C18
     2021-10-07 09:16:50   state           open
Attributes:
   IODev      MyRFR
   autoStoreRollingCode 1
   devStateIcon open:fts_shutter_10@red:on closed:fts_shutter_100@green:off go-my:_fts_shutter_my@blue
   icon       fts_shutter
   loglevel   6
   model      somfyshutter
   room       Rollos
   verbose    5
   webCmd     on:go-my:off

Ich bekomme einfach keine Logik herein. Wenn dir etwas einfällt, dann lass mich wissen wo ich suchen kann oder was ist ausprobieren bzw. ändern soll.
Danke schon mal.