10_SOMFY.pm - Somfy RTS (und kompatible)

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

Vorheriges Thema - Nächstes Thema

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.  ;)
Cubietruck 3.4.107 / Debian GNU/Linux 7.8 (wheezy), verschiedene Homematic und Somfy Komponenten

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
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

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

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

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:
attr MYROLLLADEN symbol-length 1280
Wird im Logfile quittiert mit
2021.10.09 07:30:15 3: MyRFR: Unknown code Yt: 1280, help me!
oder
2021.10.09 07:30:06 3: MyCUL: Unknown code Yt: 1280, help me!

Kompletter Auszug für einen Rollladen:

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?
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

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:

   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.4

Ich habe Ralf9s Firmware überspielt, dabei aber nichts selbst kompiliert. Also angeschlossen und dann auf ,,set sduino flash" geklickt.
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

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
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

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

ZitatJetzt 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


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

gestein

Hallo,

ich wollte gerade die Funktion "manual" bei meinen SOMFY-Rollos testen.
Ein "set Rollo.GZ manual 90" ändert aber nix an der Position.

Folgende Einträge finden sich im log-File:
2022.06.03 10:00:10.081 4: SOMFY_set: Rollo.GZ -> entering with mode :virtual: cmd :manual:  arg1 :90:  pos :0:
2022.06.03 10:00:10.081 4: SOMFY_set: handled command manual --> move :manual:  newState :0:
2022.06.03 10:00:10.083 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2022.06.03 10:00:10.083 4: SOMFY_UpdateState: Rollo.GZ enter with  newState:0:   updatestate:<undef>:   move:manual:
2022.06.03 10:00:10.084 4: SOMFY_UpdateState: Rollo.GZ after conversions  newState:0:  rounded:0:  stateTrans:open:


Liegt das vielleicht am Attribut "positionInverse=0"?

Danke im Voraus
lg, Gerhard

Hier noch ein list des devices:
Internals:
   ADDRESS    12350F
   DEF        12350F
   FUUID      5c43b923-f33f-0b7a-733b-e08f389460e49ab7
   FVERSION   10_SOMFY.pm:v1.0.0-s22865/2020-09-27
   IODev      mySIGNALduino_WZ
   NAME       Rollo.GZ
   NR         1085
   STATE      open
   TYPE       SOMFY
   eventCount 1069
   move       manual
   CODE:
     1          12350F
   READINGS:
     2022-01-27 18:48:26   ASC_Enable      on
     2022-06-03 10:01:36   ASC_ShadingMessage INFO: current shading status is 'out' - next check in 2.5m
     2022-06-03 05:30:26   ASC_ShuttersLastDrive day open
     2022-06-03 05:30:05   ASC_Time_DriveDown 04.06.2022 - 03:46
     2022-06-03 05:30:05   ASC_Time_DriveUp 04.06.2022 - 05:30
     2022-05-31 18:40:12   IODev           mySIGNALduino_WZ
     2022-05-31 18:41:25   associatedWith  myASControl
     2022-06-03 05:30:16   enc_key         AF
     2022-06-03 10:03:34   exact           0
     2022-06-03 10:03:34   myBrightness    5395
     2022-06-03 10:03:34   myBrightnessForShadingCloudy 22000
     2022-06-03 10:03:34   myBrightnessForShadingSunny 55000
     2022-06-03 10:03:34   myShadingPASS_GreaterBrightnessSunny False
     2022-06-03 10:03:34   myShadingPASS_GreaterSunAzimuthLeft False
     2022-06-03 10:03:34   myShadingPASS_GreaterSunElevationMin True
     2022-06-03 10:03:34   myShadingPASS_GreaterTemperatureExternMin False
     2022-06-03 10:03:34   myShadingPASS_LastDrive day open
     2022-06-03 10:03:34   myShadingPASS_LowerBrightnessCloudy False
     2022-06-03 10:03:34   myShadingPASS_LowerSunAzimuthRight True
     2022-06-03 10:03:34   myShadingPASS_LowerSunElevationMax True
     2022-06-03 10:03:34   myShadingPASS_WindowState tilted
     2022-06-03 10:03:34   mySunAzimuth    111.02
     2022-06-03 10:03:34   mySunAzimuthLeft 220
     2022-06-03 10:03:34   mySunAzimuthRight 360
     2022-06-03 10:03:34   mySunElevation  47.28
     2022-06-03 10:03:34   mySunElevationForShadingMax 90
     2022-06-03 10:03:34   mySunElevationForShadingMin 5
     2022-06-03 10:03:34   myTemperatureExtern 17.5
     2022-06-03 10:03:34   myTemperatureExternForShadingMin 21
     2022-06-03 10:03:34   position        0
     2022-06-03 05:30:16   rolling_code    1262
     2022-04-02 14:46:57   rolling_code_old 118E
     2022-06-03 10:03:34   state           open
     2022-06-03 05:30:25   usrPos          0
   helper:
     bm:
       SOMFY_Attr:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        03.06. 09:59:37
         max        0.000190973281860352
         tot        0.000190973281860352
         mAr:
           set
           Rollo.GZ
           verbose
           5
       SOMFY_Set:
         cnt        1305
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        03.06. 01:24:44
         max        1.73457598686218
         tot        17.7249011993408
         mAr:
           HASH(0x533b600)
           Rollo.GZ
           manual
           90
Attributes:
   ASC        1
   ASC_BlockingTime_afterManual 1200
   ASC_BrightnessSensor TW.Helligkeit:brightness
   ASC_Closed_Pos 200
   ASC_ComfortOpen_Pos 40
   ASC_Down   time
   ASC_Drive_DelayStart 10
   ASC_GuestRoom on
   ASC_LockOut soft
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Partymode off
   ASC_Pos_Reading usrPos
   ASC_Shading_InOutAzimuth 220:360
   ASC_Shading_MinMax_Elevation 5:90
   ASC_Shading_Min_OutsideTemperature 21
   ASC_Shading_Mode always
   ASC_Shading_Pos { GetRolloDefPos("Rollo.GZ"); }
   ASC_Shading_StateChange_SunnyCloudy 55000:22000
   ASC_Shading_WaitingPeriod 300
   ASC_Sleep_Pos 95
   ASC_TempSensor OZW772:Aussentemperatur
   ASC_Time_Down_Early {my ($myHour,$myMin,$mySec) = split(":", sunrise(-1800,"03:00","05:00")); my $ret = ($myHour gt "23" ? $myHour-24:$myHour).":$myMin:$mySec"; return $ret;}
   ASC_Time_Up_Early 5:30
   ASC_Time_Up_WE_Holiday 7:00
   ASC_Up     time
   ASC_Ventilate_Pos 40
   ASC_Ventilate_Window_Open on
   ASC_WindProtection on
   ASC_WindowRec GZ.Drehgriff_Fenster
   ASC_WindowRec_subType threestate
   IODev      mySIGNALduino_WZ
   alias      Rollo Gästezimmer
   autoStoreRollingCode 1
   devStateIcon { GetRolloDefStateIcon($name);}
   drive-down-time-to-100 20
   drive-down-time-to-close 20
   drive-up-time-to-100 20
   drive-up-time-to-open 20
   eventMap   on:runter stop:stop go-my:my off:rauf
   fhem_widget_channels [{"filter":"public","alias":"Rollo\nGästezimmer","allowed_values":["0","20","40","60","80","100"],"order":201,"locations":["SIRI","APP","WIDGET"],"group":"Rollos","controlled_attribute":"position"}]
   finalPosReading usrPos
   group      Rolladenstatus
   model      somfyshutter
   positionInverse 0
   room       Zimmer->Gästezimmer,Z_System->Homekit,Rollos,Z_System->SOMFY,Z_System->fhemwidget2
   userReadings myBrightness {ascAPIget('BrightnessAverage',$NAME)},
myBrightnessForShadingCloudy {ascAPIget('ShadingStateChangeCloudy',$NAME)},
myBrightnessForShadingSunny {ascAPIget('ShadingStateChangeSunny',$NAME)},
myTemperatureExtern {ascAPIget('OutTemp',$NAME)},
myTemperatureExternForShadingMin {AttrVal("$NAME", "ASC_Shading_Min_OutsideTemperature","")},
mySunAzimuth {ascAPIget('Azimuth')},
mySunAzimuthLeft {ascAPIget('ShadingAzimuthLeft',$NAME)},
mySunAzimuthRight {ascAPIget('ShadingAzimuthRight',$NAME)},
mySunElevation {ascAPIget('Elevation')},
mySunElevationForShadingMin {ascAPIget('ShadingMinElevation',$NAME)},
mySunElevationForShadingMax {ascAPIget('ShadingMaxElevation',$NAME)},
myShadingPASS_GreaterBrightnessSunny {if (ReadingsNum("$NAME","myBrightness",0) > ReadingsNum("$NAME","myBrightnessForShadingSunny",0)) {"True"} else {"False"}},
myShadingPASS_LowerBrightnessCloudy {if (ReadingsNum("$NAME","myBrightness",0) > ReadingsNum("$NAME","myBrightnessForShadingCloudy",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunAzimuthLeft {if (ReadingsNum("$NAME","mySunAzimuth",0) > ReadingsNum("$NAME","mySunAzimuthLeft",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunAzimuthRight {if (ReadingsNum("$NAME","mySunAzimuth",0) < ReadingsNum("$NAME","mySunAzimuthRight",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunElevationMin {if (ReadingsNum("$NAME","mySunElevation",0) > ReadingsNum("$NAME","mySunElevationForShadingMin",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunElevationMax {if (ReadingsNum("$NAME","mySunElevation",0) < ReadingsNum("$NAME","mySunElevationForShadingMax",0)) {"True"} else {"False"}},
myShadingPASS_GreaterTemperatureExternMin {if (ReadingsNum("$NAME","myTemperatureExtern",0) > ReadingsNum("$NAME","myTemperatureExternForShadingMin",0)) {"True"} else {"False"}},
myShadingPASS_WindowState {ascAPIget('WinStatus',$NAME)},
myShadingPASS_LastDrive {ascAPIget('LastDrive',$NAME)}
   userattr   ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforeDayOpen ASC_BlockingTime_beforeNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_CommandTemplate ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_BetweenTheTime ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace,awning,EG_window ASC_SlatPosCmd_SlatDevice ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate room_map structexclude
   verbose    5
   webCmd     stop:my:runter:20:40:60:80:100:rauf

Ralf9

Liest hier jemand mit der eine Fernbedienung oder Windsensor hat deren Nachrichten eine Länge von 80 Bit haben?

Durch eine Änderung die es vor einiger Zeit in der fhem.pl gab, können diese Nachrichten nicht mehr vom 10_SOMFY.pm Modul verarbeitet werden.

Die Ursache ist eine fehlerhafte "$hash->{Match}" im 10_SOMFY.pm Modul.

Wenn das
$hash->{Match}  = "^Ys..............\$"
nach
$hash->{Match}  = "^Ys..............";
geändert wird, funktionierts wieder.

Wäre schön, wenn dies jemand im SVN ändern könnte.

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