Somfy RTS / Signaldunio / Startprobleme nach Reboot

[LastOne]

Hallo zusammen,

ich fürchte ich komm hier einfach nicht mehr weiter, bevor ich als Anfänger wild rum probiere erhoffe ich mir das jemand von euch weiter weiß. 

Ich hab vor einigen Wochen FHEM auf einem Rapi 4 aufgesetzt um meine Somfy RTS Rolläden zu steuern und auch in HomeKit zu bringen. Orientiert hab ich mich an dieser Anleitung von Smart-Live.de
https://smart-live.net/somfy-rts-rolladen-ueber-fhem-in-homekit-einbinden/

Das hat grundsätzlich auch geklappt, ich kann meine Rolläden steuern wenn es erst mal läuft. ABER:
Sobald das System einmal rebooted werden muss (Strom weg, WLAN weg, Updates, was auch immer) muss ich x-mal öffnen/schließen bei jedem Rolladen drücken. Passieren tut genau gar nichts in dem Moment, erst nach XX Sekunden/Minuten kommen die Befehle an und er arbeitet sie alle ab (fährt ständig runter, bricht ab, hoch usw)

Sobald ich das einmal mit allen Rolläden gemacht hab läuft es wieder stabil, direkt auf Klick. Aber das kann ja nicht im Sinn des Erfinder sein? Außerdem dauert es jedesmal länger hab ich das Gefühl und macht mich nervös. Mittlerweile hab ich ne whitelist gemacht, der dunio soll nur noch SomfyRTS nutzen und hab alle devices die er bisher einfing gelöscht. Hat alles nichts gebracht. Anbei mal zwei Screens aus dem Webinterface eines Rollos und des Dunio. Wenn ihr mehr braucht, sagt es einfach. Bin echt etwas verzweifelt, besonders weil ich mir die handsender scheinbar umprogrammiert hab bei der Aktion und wenn ich das hier nicht sauber zum Laufen bekomm Wahlmöglich das frisch gemachte Wohnzimmer an den Wänden aufmachen muss zum neu aufsetzen (habe leider übersehen die Rolläden einzeln abzusichern he Raum)

Grüße & Danke für jeden Tipp

Edit: hier der Code Statt Screenshot

Dunio:

Code Auswählen Erweitern

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   FD         7
   FUUID      5f31c329-f33f-ac26-435e-09a1ea09655f5fe8
   LASTDMSG   nothing
   LASTDMSGID nothing
   NAME       dunio
   NR         15
   NR_CMD_LAST_H 3
   PARTIAL   
   STATE      opened
   TIME       1600612992
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
   versionProtocols 1.20
   versionmodul v3.4.4
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2020-09-20 17:03:28   cc1101_config   Freq: 433.000 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 3173.83 Baud
     2020-09-20 17:03:28   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2020-09-20 16:43:29   cc1101_patable  C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2020-09-20 22:31:31   ping            OK
     2020-09-20 16:43:27   state           opened
     2020-08-10 23:59:07   version         V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
   XMIT_TIME:
     1600626328
     1600626683
     1600626824
   additionalSets:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     43
   msIdList:
   muIdList:
Attributes:
   hardware   radinoCC1101
   whitelist_IDs 43

Rollo Küche

Code Auswählen Erweitern

Internals:
   ADDRESS    FF4A04
   DEF        FF4A04 AB 00DB
   FUUID      5f3432ac-f33f-ac26-ba75-05d3361d94641392
   IODev      dunio
   NAME       Rollo_Kueche
   NR         21
   STATE      closed
   TYPE       SOMFY
   move       on
   CODE:
     1          FF4A04
   READINGS:
     2020-09-20 20:31:23   enc_key         AB
     2020-09-20 20:31:23   exact           200
     2020-09-20 20:31:23   position        200
     2020-09-20 20:31:23   rolling_code    00DB
     2020-09-20 20:31:23   state           closed
     2020-09-20 20:31:23   userposition    0
Attributes:
   IODev      dunio
   alias      Küche
   autoStoreRollingCode 1
   devStateIcon closed:fts_shutter_100 open:fts_shutter_10 my:fts_shutter_50
   eventMap   on:ab off:auf go-my:my on:close off:open
   genericDeviceType blind
   group      Rolladen,
   homebridgeMapping clear CurrentPosition=userposition,minValue=0,maxValue=100,minStep=50 TargetPosition=userposition,minValue=0,maxValue=100,minStep=50,cmds=0:close;;50:my;;100:open
   model      somfyshutter
   positionInverse 1
   room       Küche,Alexa,Homekit,Somfy
   userReadings userposition {(ReadingsVal($NAME,"state","open") eq "open")?100:(ReadingsVal($NAME,"state","open") eq "go-my")?50:0}
   webCmd     auf:my:ab

[andies]

schwer zu sagen. Zwei Sachen fallen mir auf:

• Die Frequenz ist mE falsch. Aber das regelt der SIGNALduino von selbst, das kann es also nicht sein.
• Ich tippe auf Probleme beim rolling code.

Weisst Du, wie der rolling code funktioniert? Kann es sein, dass der neue Code nicht abgespeichert wurde und Du deshalb Probleme hast? Lies mal das hier https://forum.fhem.de/index.php/topic,89337.0.html, vielleicht hilft das.

[andies]

PS Bitte keine Screenshots, das ist nervig zu lesen. Am besten

Code Auswählen Erweitern

list <devicename>
und dann in Codetags, das ist der Button # oben.

[LastOne]

Danke, ich werde den Thread einmal lesen und probieren ob es hilft. Derweil hab ich den Code oben nun ergänzt

[andies]

wie viegener in dem anderen thread schon gesagt hat: autoStoreRollingCode=1 speichert deine rolling codes in der uniqueID. Nach einem Neustart werden sie erst dann ausgelesen, wenn du das erste Mal den Befehl ausführst (also nicht beim Neustart). Ich habe das nicht so eingestellt, aber in der Richt7ng würde ich weiter forschen.

[LastOne]

Hab in dem anderen thread schon dazu gepostet. Nach nem RasPi reboot läuft es doch normal. Bei Strom weg passen die Codes trotz des Attributs nicht mehr. Muss dann hoch/runter fahren (ohne das sich tatsächlich was bewegt) und meist bei der nächsten Runde läuft es dann. Das aber bei ALLEN Rolläden einmal.

[andies]

Ich kapiere das Problem nach wie vor nicht richtig und wenn das nicht nur mir so geht, wird dir hier nicht geholfen werden können. Das muss schon genauer sein.

Du schreibst

Sobald das System einmal rebooted werden muss (... was auch immer) muss ich x-mal öffnen/schließen

und dann

Nach nem RasPi reboot läuft es doch normal.

Ohne exakte Beschreibung kommen wir hier nicht weiter. Dann schreibst Du, Du hättest scheinbar (sicher "scheinbar"? Nicht "anscheinend"?) den Sender umprogrammiert? Wie?

Ansonsten

Code Auswählen Erweitern

attr Rollo_Kueche verbose 5
und dann mal schauen, was beim "normalen" senden passiert und was nach einem reboot/Absturz/Weltuntergang passiert. Du hast doch hoffentlich nicht den SIGNALduino über FHEM angelernt? Dann ist der rolling Code immer aus dem Takt. Rollo_Kueche muss  wie eine zweite Fernbedienung sein.

[LastOne]

Hi,

Sorry das war doof formuliert von mir.

-ich musste zuletzt x-mal in Fhem auf/ab drücken bis die Rollos wieder liefen nach nem Neustart -> Das Problem kann ich nicht mehr reproduzieren
-Wenn ich Sudo reboot beim pi mache, läuft tatsächlich alles sauber weiter
-ziehe ich den Stecker des pi, muss ich die Rollos hoch/runter fahren (in der Praxis tutbsich nix) und erst beim nächsten Lauf bewegt sich das Rollo wirklich -> hier scheint der Rolling Code veraltet

Den Punkt mit SignalDunio nicht in FHEM angelernt verstehe ich nicht. Ich hab die Rollos angelegt in Fhem, diese via handsender in den alernmodus gebracht, in Fhem den Prog Befehl gestartet. Alles wie oben im link meines ersten Beitrages. Das scheint sich soweit auch mit dem Wiki hier zu decken. Nur die Zeiten habe ich für hoch/runter etc nicht gestoppt.

Was genau macht der verbose Befehl bzw Attribut?

[viegener]

-Wenn ich Sudo reboot beim pi mache, läuft tatsächlich alles sauber weiter
-ziehe ich den Stecker des pi, muss ich die Rollos hoch/runter fahren (in der Praxis tutbsich nix) und erst beim nächsten Lauf bewegt sich das Rollo wirklich -> hier scheint der Rolling Code veraltet

Wieso sollte es bei unterschiedlichem Verhalten in diesen beiden Fällen am Rolling Code liegen. In beiden Fällen wird FHEM ja gleichgestartet und das Speichern des rolling code sollte auch bei Stromausfall bereits passiert sein (das kannst Du ja selber überprüfen).

Also vermute ich nicht, dass der ROllingcode veraltet ist, sondern vielleicht eher dass nach Stromausfal die Hardware sich anders verhält. Beim Reboot wird ja nicht unbedingt zwischendurch alle USB-Devices stromlos gemacht?

Wenn es um den Signalduino geht würde ich das vielleicht eher dort mal schildern.

Du kannst doch mal Deinen pi runterfahren, dann stromlos machen und dann neu starten - Vermutung - auch dann wird möglicherweise der erste Befehl nicht funtktionieren?

[andies]

verbose 5 sorgt für einen sehr ausführlichen Log.

viegener ist der Profi: sollte vielleicht die ganze Startphase mit verbose=5 gelogged werden?

[australien]

Hi,

Sorry das war doof formuliert von mir.

-ich musste zuletzt x-mal in Fhem auf/ab drücken bis die Rollos wieder liefen nach nem Neustart -> Das Problem kann ich nicht mehr reproduzieren
-Wenn ich Sudo reboot beim pi mache, läuft tatsächlich alles sauber weiter
-ziehe ich den Stecker des pi, muss ich die Rollos hoch/runter fahren (in der Praxis tutbsich nix) und erst beim nächsten Lauf bewegt sich das Rollo wirklich -> hier scheint der Rolling Code veraltet

Den Punkt mit SignalDunio nicht in FHEM angelernt verstehe ich nicht. Ich hab die Rollos angelegt in Fhem, diese via handsender in den alernmodus gebracht, in Fhem den Prog Befehl gestartet. Alles wie oben im link meines ersten Beitrages. Das scheint sich soweit auch mit dem Wiki hier zu decken. Nur die Zeiten habe ich für hoch/runter etc nicht gestoppt.

Was genau macht der verbose Befehl bzw Attribut?

Hallo LastOne und auch alle anderen,

ich kann Dir nur zustimmen, kenne das gleiche Problem seit mehreren Jahren und hab noch keine andere Lösung gefunden, ausser das bis zu 20x rauf/runter senden.

Ist nervig.

Seit dem letzten DOIF Update kommt noch das Problem, dass ca alle Minute das Kommando neu abgesetzt wird, obwohl sich die Readings nicht ändern. Somit fahren die Rollos dauernd, bzw wird der sduino mit den Sendeaufträgen überschüttet und daduch das ganze fhem.

[andies]

Ist das ein signalduino-somfy Problem oder taucht das auch woanders auf? Und wann genau passiert das, das habe ich immer noch nicht kapiert.

[LastOne]

Du kannst doch mal Deinen pi runterfahren, dann stromlos machen und dann neu starten - Vermutung - auch dann wird möglicherweise der erste Befehl nicht funtktionieren?

Gute Idee! Das habe ich einmal über den shutdown Befehl probiert. Auch danach lief alles direkt wieder an, nachdem ich den Stecker wieder eingesteckt habe.

Aber: ziehe ich ohne Warnung den Stromstecker, verhält er sich trotzdem anders. Das Problem mit Rolling Code veraltet habe ich via Screenshot verifiziert. Vorm Stecker zIehen Code abgeknippst. Nach dem Neustart steht dort ein anderer, derzeit eins ,tiefer'

Ich vermute das er bei einem regulären shutdown / reboot irgend eine Datei sauber speichert, was er nicht tut beim Stecker ziehen ohne Vorwarnung?

@andies Das von Australien geschilderte Problem hatte ich so zeitweise auch, passiert auch nach Stromverlust. Nur bei mir ist es aktuell mit einmal schalten getan. Vor ein paar Tagen musste ich noch x mal fahren, nicht nur einmal. Welcheänderung das nun so bewirkt hat das einmal reicht weiß ich nicht. Aber derzeit arbeite ich ohne den zigbee Stick. Den werd ich nun aber wieder anstecken und noch mal testen ob einmal oder x mal schalten nach stromverlust nötig ist

[LastOne]

Verifiziert und reproduziert: Habe ich den Conbee2 Stick mit am Pi, muss ich öfter neu schalten. Die Abweichung des RollingCodes ist dann größer als ohne Conbee2 - wie und warum... da hab ich keine Ahnung.

So, und nochmal ohne Conbee - Schlafzimmer war bei 00D8 und nach Neustart war der Code 00CB. Hab das zwei mal wiederholt. Alles chaos wieder. Nächster Schritt: Alle Rolläden einmal sauber steuern und nen echten reboot.

So, nach dem alle wieder ansteuerbar waren (also auf drücken im FHEM) auch sich real bewegten, hab ich einen sudo reboot gemacht. Lief alles weiter. Strom gekappt. Musste wieder einmal ansteuern, danach ging's.

Was ich gelernt hab: Der Conbee verschlimmert das Problem. Wie auch immer. Wenn er weg ist, muss ich trotzdem einmal einen sauberen reboot machen.

Wird ne Datei nicht geschrieben? Hat es was mit den USB devices zu tun? Hinweis: außer den beiden (und jetzt nur der eine) ist nichts am Pi angeschlossen.

Danke auf jeden Fall schon mal das ihr mich bei der Fehler Lösung anleitet.

[andies]

Wo werden die rolling codes physisch gespeichert: in der uniqueID oder in fhem.save? Kannst Du diese Datei beobachten?