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/ (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:
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
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
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 (https://forum.fhem.de/index.php/topic,89337.0.html), vielleicht hilft das.
PS Bitte keine Screenshots, das ist nervig zu lesen. Am besten
list <devicename>
und dann in Codetags, das ist der Button # oben.
Danke, ich werde den Thread einmal lesen und probieren ob es hilft. Derweil hab ich den Code oben nun ergänzt
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.
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.
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
Zitat von: LastOne am 20 September 2020, 17:39:39
Sobald das System einmal rebooted werden muss (... was auch immer) muss ich x-mal öffnen/schließen
und dann
Zitat von: LastOne am 21 September 2020, 22:20:42
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
attr Rollo_Kueche verbose 5und 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.
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?
Zitat von: LastOne am 22 September 2020, 23:08:25
-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?
verbose 5 sorgt für einen sehr ausführlichen Log.
viegener ist der Profi: sollte vielleicht die ganze Startphase mit verbose=5 gelogged werden?
Zitat von: LastOne am 22 September 2020, 23:08:25
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.
Ist das ein signalduino-somfy Problem oder taucht das auch woanders auf? Und wann genau passiert das, das habe ich immer noch nicht kapiert.
Zitat von: viegener am 23 September 2020, 00:05:52
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
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.
Wo werden die rolling codes physisch gespeichert: in der uniqueID oder in fhem.save? Kannst Du diese Datei beobachten?
Zitat von: LastOne am 23 September 2020, 13:01:29
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'
Das mit dem Screenshot hilft nicht, denn wenn Du "autoStoreRollingCode" gesetzt hast (wie oben gesagt) - dann wird zwar der Wert in uniqueID gespeichert aber erst bei der ersten Betätigung aus der uniqueID gelesen - im Reading steht aber nach dem Neustart der Wert aus fhem.save und der ist vermutlich veraltet
Aber ich habe mir die ganze Logik nochmal angeschaut, ich denke ich habe eine Erklärung gefunden was beim Neustart ohne Runterfahren passiert und ich vermute es erfordert doch etwas Umbau um das zu verhindern
@andies Soweit ich das versteh in der uniqueID durch den autorollingcode
@viegener, ah ok. Ich dachte nur weil sie beim ersten betätigen nur im Web aber nicht real fährt issue nicht synchron und zählt hoch und passt dann wieder. Und was wäre da an Umbau zu tun? Erklärt das auch den Einfluss des Conbee?
Zitat von: LastOne am 23 September 2020, 16:35:26
@andies Soweit ich das versteh in der uniqueID durch den autorollingcode
@viegener, ah ok. Ich dachte nur weil sie beim ersten betätigen nur im Web aber nicht real fährt issue nicht synchron und zählt hoch und passt dann wieder. Und was wäre da an Umbau zu tun? Erklärt das auch den Einfluss des Conbee?
Nein das sollte keinen Einfluss bzgl conbee haben - heir ist einfach ein Fehler in der Logi, denn im historischen Teil des Moduls wird die aktuelle Definition des Devices immer angepasst und das muss ich ändern, das hebelt den Mechanismus über die uniqueID aus. Hätte mir vorher auffallen müssen.
Ich habe eine Testversion in github bereitgestellt:
https://github.com/viegener/Telegram-fhem/blob/master/Somfy/10_SOMFY.pm (https://github.com/viegener/Telegram-fhem/blob/master/Somfy/10_SOMFY.pm)
Zum Ausprobieren die Datei (raw) herunterladen und ins FHEM-Verzeichnis (vorher existierende Date sichern) - Danach FHEM neustarten
Super, teste ich morgen direkt und gebe dir Feedback :)
Ich brauche dabei doch leider noch mal deine Hilfe. Ich habe zwar schon Dateien auf dem editiert, aber ich bekomme die Datei via ftp über den pi User nicht ausgetauscht. Er sagt ich habe nicht die nötigen Rechte. Wie geht man hier normal vor?
Zitat von: LastOne am 24 September 2020, 19:04:38
Wie geht man hier normal vor?
ssh zum Pi und dann
sudo chmod 666 <Dateiname>oder, was vermutlich harmloser ist
sudo chown fhem:dialout <Dateiname>
So, Datei getestet. Am Verhalten hat sich leider nichts geändert.
Heisst das DU musstest wieder zweimal betätigen oder hast Du überprüft, dass der Rollingcode nicht übernommen wurde?
Nur zur Sicherheit - Raspbi neugestartet und vor dem Stecker ziehen den Device auch mind einmal betätigt?
Kannst Du mir ein list des Somfydevices machen?
Ich habe das ganze heut zur Sicherheit nocheinmal gemacht. Keine Veränderung.
Zur Klarstellung: Ivh musste zwei mal betätigen. Den Rollingcode hatte ich nicht überprüft. Bevor ich das nun zu, auf welcher weise soll ich ihn prüfen? Damit ich nicht wieder halbe Infos liefere
Zum List
Internals:
ADDRESS FF4A04
DEF FF4A04
FUUID 5f3432ac-f33f-ac26-ba75-05d3361d94641392
IODev dunio
NAME Rollo_Kueche
NR 21
STATE open
TYPE SOMFY
move off
CODE:
1 FF4A04
READINGS:
2020-09-25 20:08:39 enc_key AA
2020-09-25 20:08:39 exact 0
2020-09-25 20:08:39 position 0
2020-09-25 20:08:39 rolling_code 010F
2020-09-25 20:08:39 state open
2020-09-25 20:08:39 userposition 100
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
Und hier noch mal der List nach Stecker ziehen am Pi. Ohne irgendwas gedrückt zu haben.
Internals:
ADDRESS FF4A04
DEF FF4A04
FUUID 5f3432ac-f33f-ac26-ba75-05d3361d94641392
IODev dunio
NAME Rollo_Kueche
NR 21
STATE open
TYPE SOMFY
move stop
CODE:
1 FF4A04
READINGS:
2020-09-25 07:01:01 enc_key A8
2020-09-25 07:01:01 exact 0
2020-09-25 07:01:01 position 0
2020-09-25 07:01:01 rolling_code 010D
2020-09-25 07:01:01 state open
2020-09-25 07:01:01 userposition 100
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
um 07:01 ist rolling code 10D und dann drückst du zweimal und er wechselt auf 10F. Das ist dann der Stand um 20:08. Passt perfekt zur Beschreibung.
Gut das du auf die Uhrzeit hinweist. Die hab ich vorhin nicht beachtet. 7:01 kann das erste öffnen am Morgen gewesen sein. Danachhab ich das mit Stecker ziehen zwei oder drei mal getestet. Er ist also immer auf die Daten zurück gesprungen.
OK - ich habe jetzt das bei mir Nachstellen können (per "kill -9"). Ich habe wieder in github eine neue Testversion bereitgestellt. Diese sollte zumindest die korrekten rollingcodes beim Senden nach Neustart verwenden.
Es gibt aber weiterhin eine Einschränkung: Das Reading wird nach dem Neustart immer noch zuerst auf dem alten Wert stehen, das wird dann automatisch bei der ersten Betätigung korrigiert.
Hintergrund; Das Setzen des Readings aus dem Statefile (fhem.save) kann ich nicht abfangen und im statefile steht zu diesem Zeitpunkt ja der falsche Wert und eine verzögerte Korrektur würde nur ein weiteres Problem eröffnen, wenn direkt nach dem Neustart ein Kommando abgesetzt werden soll
Also es wäre toll, wenn Du nochmal bei Dir testen könntest
Aber natürlich, sehr gern sogar. Mache ich heut Abend noch :)
So, Datei ist drauf, hab ihn mit Stecker ziehen gekillt. Und es läuft danach ohne Probleme weiter. Vielen vielen Dank :) :) :) Bin total begeistert!
Danke fürs Testen und Danke fürs Fehler finden!
Dann werde ich die Version auch ins SVN fürs normale update geben
Darf ich noch eine Frage anhängen? Gibt es eigentlich auch eine Möglichkeit die normalen Handsender weiter zu nutzen? Wenn ich damit steuere verändert sich ja auch der Rollingcode nehm ich an. Bekommt der dunio das irgendwie mit?
Zitat von: LastOne am 27 September 2020, 00:01:26
Gibt es eigentlich auch eine Möglichkeit die normalen Handsender weiter zu nutzen?
Zitat von: andies am 22 September 2020, 07:22:39
Rollo_Kueche muss wie eine zweite Fernbedienung sein.
Der sduino könnte das nur mitbekommen, wenn er auf die Frequenz vom somfy eingestellt wäre. Die ist nämlich nicht 433.92, sondern irgendwas mit 433.42 MHz. Da die meisten den sduino für andere Sachen mitnutzen, kommt das dann gar nicht in Frage.
Eventuell musst Du in den threads des sduino fragen. Ich glaube, das wurde schon mal diskuiert. Einfacher ist aber, den sduino als zweiten Handsender zu nutzen.
Das hattest du weiter vorn schon angesprochen. Wo ist denn da der Unterschied? Ich mein von der config her? Ich nutz den dunio für nichts anderes. Die Frequenz wär also nicht das Thema. Erst mal möchte ich aber den anderen Ansatz verstehen. Vorallem weil ich dachte er wäre nun ein weiterer handsender. Ist er aber nicht. Hab ich nun auch verstanden.
Nee, mein Plädoyer war ja, FHEM als einen weiteren Handsender zu definieren - und nicht FHEM und den Handsender wie eine Fernbedienung zu behandeln. Denn das mitzählen scheint problematisch zu sein.
Das läuft wohl technisch so ab, wenn ich das richtig kapiert habe. Du sendest "Rollo Küche hoch" und das übersetzt sich in eine Bitfolge. Die Bitfolge enthält einen rolling code. Der Motor erhält das Signal, versteht es und sendet zurück "verstanden" und zählt seinen internen rolling code hoch. Daraufhin empfängt sduino das "verstanden" und zählt wiederum seinen internen rolling code hoch.
Beim sduino ist das intern programmiert. Wenn jetzt ein Handsender hinzukommt, müsste der sduino auf 434.3 fest eingestellt werden und kann nichts anderes empfangen. Würde sich dann ein Handsender melden, würde der sduino mithören, auf das "ok" warten und dann intern hochzählen. Ich denke, dass das technisch geht. ABER: Das macht ihn wiederum für 90% der Nutzer unattraktiv, weil die die feste Frequenz nicht gebrauchen können (der sduino ist ja für 99% des Tages lahmgelegt, weil zu dieser Zeit keine Rollos fahren). Also werden weder sidey noch Ralf9 das so programmieren. Vermute ich mal.
Wenn der sduino eine eigene Fernbedienung ist, muss er nur beim senden kurz die Frequenz umschalten und eine bestimmte Zeit auf Antwort auf dieser Frequenz warten. Danach kehrt er zu 433.92 zurück. Und wenn Du das so einstellst, nutzt Du die "0815-Variante" (sorry sidey und Ralf9) aus dem Forum. Die Motoren können mW bis zu neun Handsender einprogrammiert haben.
Wenn Du das aber wie im Wiki gemacht hast, ist FHEM ein weiterer Handsender und hört gerade nicht auf die Fernbedienung. Also das musst Du uns nochmal genauer erklären.
Zitat von: andies am 27 September 2020, 09:30:45
Nee, mein Plädoyer war ja, FHEM als einen weiteren Handsender zu definieren - und nicht FHEM und den Handsender wie eine Fernbedienung zu behandeln. Denn das mitzählen scheint problematisch zu sein.
Das läuft wohl technisch so ab, wenn ich das richtig kapiert habe. Du sendest "Rollo Küche hoch" und das übersetzt sich in eine Bitfolge. Die Bitfolge enthält einen rolling code. Der Motor erhält das Signal, versteht es und sendet zurück "verstanden" und zählt seinen internen rolling code hoch. Daraufhin empfängt sduino das "verstanden" und zählt wiederum seinen internen rolling code hoch.
Beim sduino ist das intern programmiert. Wenn jetzt ein Handsender hinzukommt, müsste der sduino auf 434.3 fest eingestellt werden und kann nichts anderes empfangen. Würde sich dann ein Handsender melden, würde der sduino mithören, auf das "ok" warten und dann intern hochzählen. Ich denke, dass das technisch geht. ABER: Das macht ihn wiederum für 90% der Nutzer unattraktiv, weil die die feste Frequenz nicht gebrauchen können (der sduino ist ja für 99% des Tages lahmgelegt, weil zu dieser Zeit keine Rollos fahren). Also werden weder sidey noch Ralf9 das so programmieren. Vermute ich mal.
Wenn der sduino eine eigene Fernbedienung ist, muss er nur beim senden kurz die Frequenz umschalten und eine bestimmte Zeit auf Antwort auf dieser Frequenz warten. Danach kehrt er zu 433.92 zurück. Und wenn Du das so einstellst, nutzt Du die "0815-Variante" (sorry sidey und Ralf9) aus dem Forum. Die Motoren können mW bis zu neun Handsender einprogrammiert haben.
Wenn Du das aber wie im Wiki gemacht hast, ist FHEM ein weiterer Handsender und hört gerade nicht auf die Fernbedienung. Also das musst Du uns nochmal genauer erklären.
Nicht vollständig korrekt: Somfy RTS ist leider nur uni-direktional. Der Antrieb (Rolladen etc) empfängt nur und sendet nichts. Die Handsender können nur senden und nichts empfangen.
Also jeder Handsender hat eine eigene Adresse und einen eigenen Rolling Code, der bei jeder Betätigung mitgesendet wird. Im Motor gibt es für jeden angelernten Handsender auch einen Zähler, der mit jedem empfangenen Befehl ebenfalls hochgezählt wird. Es gibt im Motor ein gewisses Toleranzfenster da ja nicht immer jeder Befehl empfangen wird. Trotzdem kann es passieren, dass Handsender und Motor sich auseinander bewegen.
Für FHEM sollte der FHEM-Device für die Betätigung auf eine eigene Adresse gesetzt werden. Ansonsten gibt es das Problem, dass der Handsender ja nicht hochzählt, wenn aus FHEM betätigt wird.
Wenn man Handsender und ROlladenstatus synchronisieren will geht das auf anderem Weg - Dazu gibt es auch einige Threads hier im Forum
Danke für die Info, ich wusste nicht, dass das unidirektional abläuft. Vor der Synchronisation kann ich eigentlich nur warnen. Ich lese da mit und es scheint ein ziemliches Gefrickel zu sein!
Ok, danke noch mal für euer Feedback. Dann lasse ich das mit dem handsender lieber.