Hallo zusammen,
vor kurzem habe ich mir einen Raspberry Pi und SIGNALduino bestellt, um damit über FHEM und Homebridge meine Somfy RTS Rollläden in HomeKit einzubinden. Leider bin ich bei der Einrichtung des SIGNALduino auf ein Problem gestoßen. Nachdem ich Homebridge und FHEM erfolgreich installiert hatte, bin ich den folgenden Anleitungen gefolgt:
https://wiki.fhem.de/wiki/SIGNALduino
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino
Zuerst hat auch alles problemlos funktioniert und ich konnte einen Rollladen über FHEM steuern. Aber nachdem ich den zweiten Rollladen eingelernt habe, hat gar nichts mehr funktioniert. Ich konnte die Rollläden nicht mehr steuern und auch das neue Einlernen mit ,,set Rollladen prog" in FHEM ging nicht mehr (die Rollläden ruckten nicht mehr auf und ab zur Bestätigung und man konnte sie auch nicht steuern).
Auch ein neues Aufsetzen des Raspberry Pi und FHEM hat nicht geholfen.
Hier im Forum (https://forum.fhem.de/index.php/topic,47151.0.html) habe ich gelesen, dass man eventuell zu viele Sender an den Rollladen anlernen kann. Bis jetzt war zwar nur ein Sender angelernt, allerdings ist die Somfy-Anlage auch schon ca. 15 Jahre alt. Habe ich durch meine vielen Versuche vielleicht etwas kaputt gemacht?
Da ich noch sehr neu in diesem Gebiet bin, weiß ich nicht mehr weiter. Habt ihr vielleicht einen Tipp oder eine Idee, was das Problem ist und wie man es lösen könnte?
Vielen Dank schon im Voraus!
Hallo capcom,
ich habe ebenfalls eine Markise mit somfy über SIGNALduino am Laufen. Wenn es bei mir einmal hakt, dann liegt es meistens am rolling-code. Dieser wird beim Senden hochgezählt und kommt manchmal aus dem Tritt, weil die Markise einen anderen code erwartet als den, der vom SIGNALduino gesendet wird. Ich behelfe mir dann meistens damit, dass ich den code mit
setreading <device> rolling_code <4-stelliger code> auf einen früheren als den angezeigten setze und dann immer wieder auf öffnen/schließen klicke, bis die Markise wieder reagiert.
Da du schreibst, dass du fhem neu aufgesetzt hast, stimmt der code sicherlich nicht, allerdings hätte ein erneutes Anlernen eigentlich klappen müssen.
Da einer deiner Rollläden schon funktioniert hat, gehe ich von einer richtigen Firmware für den SIGNALduino (Protokoll -Y einkommentiert) aus und davon, dass du
ZitatAnlernen des Rollos an FHEM
Als nächser Schritt muss der "FHEM Sender" and den Rolladen angelernt werden. Dazu wird ein SOMFY Sender (z.B. Handsender) benötigt. Auf der Rückseite des Senders befindet sich in der Regel eine kleine Vertiefung (Loch) mit einem Taster, der z.B. über ein Streichholzende für 0,5 sec gedrückt werden muss. Danach fährt der Rolladen zur Quittierung kurz nach unten und wieder zurück (ruckt). Unmittelbar danach ist in FHEM das Kommando
set RolloOben prog
abzusetzen. Zur Quittierung "ruckt" der Rolladen wieder. Danach kann der Rolladen über die Kommandos "up" "stop" "down" aus der FHEM Oberfläche gesteuert werden.
Bitte erst die Rolläden ein Stück weit runterfahren und erst dann die Programmiertaste auf der Fernbedienung drücken; in der Endposition reagieren die Rolläden manchmal nicht. Das steht auch so in der Bedienungsanleitung von Somfy.
entsprechend befolgst.
Bist du dir sicher, dass der SIGNALduino nach dem neuen Aufsetzen des Raspi und auch von fhem richtig funktioniert? Empfängt/sendet er etwas?
In Bezug auf deine Angst, zu viele Fernbedienungen angelernt zu haben, schau doch mal hier https://www.somfy.de/hilfe-center/faq/warum-kann-ich-meinen-motor-nicht-auf-werkseinstellungen-zuruecksetzen (https://www.somfy.de/hilfe-center/faq/warum-kann-ich-meinen-motor-nicht-auf-werkseinstellungen-zuruecksetzen). Vielleicht hilft das?
Beste Grüße
Bönne
PS: Mir fällt gerade ein, dass der SIGNALduino manchmal Probleme hat, wenn ich in einer gewissen Zeit zu viele Befehle an ein device schicke. Ich weiß aber gerade nicht genau, ab wann er das macht. Ich hatte mal ein script laufen, dass alle 5s einen Befehl sendet, damit der code hochgezählt wird und ich nicht immer klicken musste. Das mochte er gar nicht :o
Hallo,
vielen Dank für die schnelle Antwort!
Leider hat es noch nicht geklappt und ich habe noch ein paar Fragen.
Zuerst mal zu den Rolling Codes:ZitatWenn es bei mir einmal hakt, dann liegt es meistens am rolling-code. Dieser wird beim Senden hochgezählt und kommt manchmal aus dem Tritt, weil die Markise einen anderen code erwartet als den, der vom SIGNALduino gesendet wird. Ich behelfe mir dann meistens damit, dass ich den code mit
Code: [Auswählen]
setreading <device> rolling_code <4-stelliger code>
auf einen früheren als den angezeigten setze und dann immer wieder auf öffnen/schließen klicke, bis die Markise wieder reagiert.
Das habe ich probiert, aber es hat nichts geholfen. Der gemeinte Rolling Code ist der, der in FHEM beim Rollladen unter ,,Readings" angezeigt wird, oder?
Wie weit muss ich den denn zurückstellen bzw. wie oft muss ich ungefähr klicken, bis es funktioniert? Ich habe ja auch nicht endlos Zeit, da der Rollladen den Lernmodus wieder verlässt.
Ich habe auch das am Ende erwähnte Skript versucht, das half bei mir auch nichts.
ZitatDa du schreibst, dass du fhem neu aufgesetzt hast, stimmt der code sicherlich nicht, allerdings hätte ein erneutes Anlernen eigentlich klappen müssen.
Und warum könnte das erneute Anlernen nicht geklappt haben?
Als nächstes zur Firmware:ZitatDa einer deiner Rollläden schon funktioniert hat, gehe ich von einer richtigen Firmware für den SIGNALduino (Protokoll -Y einkommentiert) aus und davon, dass du ... entsprechend befolgst.
Ich denke auch, dass ich die richtige Firmware habe. Aber woran würde ich erkennen, ob ich die richtige habe, also an welchem Y? Ist das folgende ausreichend?
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:
2021-07-20 17:59:29 ping OK
2021-07-20 17:50:23 rolling_code 0000
2021-07-20 17:19:29 state openedZum Neuaufsetzen:ZitatBist du dir sicher, dass der SIGNALduino nach dem neuen Aufsetzen des Raspi und auch von fhem richtig funktioniert? Empfängt/sendet er etwas?
Da der Signalduino in FHEM als opened angezeigt wird und er beim Klicken auf up/down in FHEM blinkt, gehe ich davon aus, dass er korrekt funktioniert. Stimmt doch, oder muss ich noch etwas anderes überprüfen?
Und dann noch eine Frage:ZitatIn Bezug auf deine Angst, zu viele Fernbedienungen angelernt zu haben, schau doch mal hier https://www.somfy.de/hilfe-center/faq/warum-kann-ich-meinen-motor-nicht-auf-werkseinstellungen-zuruecksetzen. Vielleicht hilft das?
Leider hab ich da den Zusammenhang zu meinem Problem nicht ganz verstanden, tut mir echt leid! Kannst du vielleicht nochmal genauer erklären, was du damit meinst?
Ich weiß, viele dieser Fragen scheinen dumm, aber ich weiß es leider nicht besser. Ich bin noch ganz neu bei FHEM und hab mir das etwas einfacher vorgestellt. Ich hoffe, dass ihr mir trotzdem helfen könnt!
Vielen Dank für die Hilfe!
Hi capcom,
ich arbeite deine Fragen mal in gleicher Reihenfolge ab ;)
Rolling-Codes (RC):
Das Problem mit den Rollin-Codes tritt nur bei einem laufenden System auf. Bei mir reagiert die Markise manchmal nicht auf den gesendeten Befehl. Das ganze findet ja unidirektional statt, will heißen, SIGNALduino sendet den Befehl, fhem protokolliert das artig und geht davon aus, das der Befehl ausgeführt wurde. Die Markise selbst bestätigt das aber nie. Andere Aktoren, z.B. von homematic etc. melden noch einmal zurück, dass sie den Befehl erhalten und ausgeführt haben (bidirektional). Fhem zählt also den RC aufwärts, die Markise hat aber den letzten verpasst. Es funktioniert nichts mehr. In diesem Fall müsste ich nun per genanntem Befehl den RC kleiner machen und so lange Befehle senden, bis der passende wieder dran ist. Je dichter man beim Zurücksetzen dran war, desto schneller geht es natürlich.
Beim neuen Anlernen spielt dies alles keine Rolle, weil der erste RC dabei festgelegt wird. Deswegen schrieb ich "[...] allerdings hätte ein erneutes Anlernen eigentlich klappen müssen." ;)
firmware
Erst einmal sorry, das genannte "Y" spielt hier keine Rolle, da hatte ich den 433Mhz cul im Kopf.
Dein Auszug sieht gut aus, denn unter 15 wird das SOMFY-Protokoll angegeben.
Zum Neuaufsetzen:
Dass der SIGNALduino blinkt, ist schon mal ganz gut. Aber setze doch einmal das Attribut verbose auf "3". Dann kannst du auch im fhem-log sehen, was er sendet/empfängt.
attr SIGNALduino verbose 3
zu deiner letzten Frage:
Ich hatte dich so verstanden, dass du annimmst, dass fhem/SIGNALduino nicht mehr an das Rollo angemeldet werden können, weil bereits zu viele "Fernbedienungen" angelernt wurden. Wenn du nun das Rollo "auf Werkseinstellungen zurücksetzt" dann sind keine Fernbedienungen mehr angelernt und es müsste wieder gehen.
Ich hoffe, wir kommen der Sache (gemeinsam) auf die Spur ;)
Beste Grüße
Bönne
schau mal, das ist komisch:
2021-07-20 17:50:23 rolling_code 0000
Hallo,
vielen Dank für die Antworten!
Rolling CodesZitatFhem zählt also den RC aufwärts, die Markise hat aber den letzten verpasst. Es funktioniert nichts mehr. In diesem Fall müsste ich nun per genanntem Befehl den RC kleiner machen und so lange Befehle senden, bis der passende wieder dran ist. Je dichter man beim Zurücksetzen dran war, desto schneller geht es natürlich.
Das mit den Rolling Codes habe ich jetzt zumindest schon etwas besser verstanden, danke schonmal dafür. Allerdings weiß ich nicht, was ich jetzt dann machen soll.
Muss ich wirklich alle Rolling Codes durchprobieren oder gibt es bestimmte, bei denen ich starten sollte?
Muss ich dann jedes Mal den Rollladen in den Anlernmodus bringen und in FHEM mit "set Rollladen prog" starten und dann durchklicken oder sind diese Schritte schon falsch?
Ich weiß ja auch gar nicht, ob der SIGNALduino schon angelernt ist oder nicht.
ZitatBeim neuen Anlernen spielt dies alles keine Rolle, weil der erste RC dabei festgelegt wird. Deswegen schrieb ich "[...] allerdings hätte ein erneutes Anlernen eigentlich klappen müssen."
Und nochmal zum neuen Anlernen: Habt ihr eine Idee, warum das nicht geklappt haben könnte?
FirmwareZitatDein Auszug sieht gut aus, denn unter 15 wird das SOMFY-Protokoll angegeben.
Das ist ja schonmal gut und beruhigt mich!
NeuaufsetzenZitatDass der SIGNALduino blinkt, ist schon mal ganz gut. Aber setze doch einmal das Attribut verbose auf "3". Dann kannst du auch im fhem-log sehen, was er sendet/empfängt.
Das habe ich gemacht, allerdings wird im normalen Logfile (unter dem Menüpunkt Logfile ganz unten) und auch im Raspberry über SSH direkt nichts angezeigt, wenn ich klicke. Liegt vielleicht da schon der Fehler oder hab ich nur das Logfile falsch eingerichtet? Es ist momentan als
./log/fhem-%Y-%m.log fakelogdefiniert.
SOMFY HandsenderZitatIch hatte dich so verstanden, dass du annimmst, dass fhem/SIGNALduino nicht mehr an das Rollo angemeldet werden können, weil bereits zu viele "Fernbedienungen" angelernt wurden. Wenn du nun das Rollo "auf Werkseinstellungen zurücksetzt" dann sind keine Fernbedienungen mehr angelernt und es müsste wieder gehen.
Danke für die Erklärung, jetzt habe ich es verstanden! Allerdings denke ich dann nicht, dass darin das Problem liegt, denn selbst wenn ich einen SIGNALduino mehrfach anlerne, müsste er doch nur als ein Sender zählen, oder nicht?
Auch möchte ich bei einem Zurücksetzen nicht riskieren, dass der normale Handsender nicht mehr funktioniert und ich den Rollladen dann gar nicht mehr steuern kann. Oder ist dieses Risiko gering?
Noch zu @andiesZitatschau mal, das ist komisch:
Code: [Auswählen]
2021-07-20 17:50:23 rolling_code 0000
Was genau ist an dem Rolling Code komisch? Ich habe den mit dem Befehl
setreading <device> rolling_code <4-stelliger code>auf 0000 gesetzt. Ist das ein Fehler? Eigentlich ist das doch der erste Rolling Code, oder?
Eigene IdeenBei den Readings des Rollladens in FHEM steht bei exact und position 200. Könnte das noch ein Problem sein?
Vielen Dank nochmal für die bisherigen Antworten. Ich freue mich sehr über eure Hilfe!
Position ist die (FHEM-intern) gespeicherte Position. Wenn du parallel einen Handsender einsetzt, ist das wenig hilfreich, weil FHEM nicht merkt, dass der Handsender bedient wurde. Wenn Du den Rolling Code selbst heruntergesetzt hast, erklärt das viel. Jetzt mehrfach mit FHEM versuchen den Rolladen zu bewegen. Jedes Mal zählt er hoch. Wenn der Rolladen intern beispielsweise 000A gespeichert hat, musst Du insgesamt 11 mal drücken (ich hoffe, ich habe mich selbst nicht verzählt), bis die Codes übereinstimmen und dann das Ding läuft. Etwas Zeit zwischen dem Drücken lassen, also nicht durchmarschieren.
Ich speichere nach jedem Drücken die Datei mit den Codes extern, so dass ich sie im Zweifel immer zurücksetzen kann. Das geht so (für später, wenn es bei Dir geht):
defmod Rolladen_Code_Sicherung notify Rolladen.* {WriteStatefile()};; {fhemsaveInMediaKopieren()}
Bei mir heißen alle Rolladen irgendwie Rolladen_Wohnzimmer, Rolladen_Schlafzimmer usw. Wird dort etwas bewegt (dafür Rolladen.*), werden zwei externe Befehle ausgelöst (die in den runden Klammern). Diese externen Befehle müssen teilweise in eine 99_myUtils.pm eingetragen werden. WriteStatefile() ist bereits in FHEM definiert, da muss nix hin (hier wird der RollingCode und zwar genauer werden alle Readings in den Statefile fhem.save gesichert).
Mein Problem war noch, dass der Statefile immer noch im Raspberry ist und wenn der abstürzt, ist der auch weg. Also wollte ich den extern sichern. Das geschieht nun mit
sub fhemsaveInMediaKopieren(){
#Ausloesezeitpunkt holen
my $neuer_zeitpunkt = POSIX::strftime("%Y-%m-%dT%H:%M:%S",localtime(time+3));
fhem("defmod fhemsaveSichern at ".$neuer_zeitpunkt." {system('cp /opt/fhem/log/fhem.save /media')} ");
}
Es wird ein paar Sekunden gewartet (weil ich manchmal drei Rolladen hintereinander lade) und dann wird ein Kopierbefehl in FHEM definiert, bei dem eine Datei in ein bestimmtes Verzeichnis geschrieben wird. Dieses Verzeichnis ist in Wirklichkeit eine externe Festplatte.
Hallo,
vielen Dank für die Antwort.
ZitatWenn Du den Rolling Code selbst heruntergesetzt hast, erklärt das viel. Jetzt mehrfach mit FHEM versuchen den Rolladen zu bewegen. Jedes Mal zählt er hoch. Wenn der Rolladen intern beispielsweise 000A gespeichert hat, musst Du insgesamt 11 mal drücken (ich hoffe, ich habe mich selbst nicht verzählt), bis die Codes übereinstimmen und dann das Ding läuft. Etwas Zeit zwischen dem Drücken lassen, also nicht durchmarschieren.
Heißt das, dass ich z.B. mit dem Skript
define testrollingcodes at +*00:01:00 set Rollladen onjede Minute in FHEM klicke, bis der Rollladen sich bewegt? Und das im normalen Modus, also
nicht im Anlernmodus?
Das würde ja dann bedeuten, dass ich meiner Rechnung nach ca. 50.000 Kombinationen, also 50.000 Minuten warten muss!
Noch eine Frage:
Sieht der SIGNALduino nach erneutem Flashen der SIGNALduino-Firmware und Neuaufsetzen von FHEM für den Rollladenempfänger eigentlich "gleich" aus (also ist er dann immer noch angelernt) oder wird er wieder als neuer, unbekannter Sender angelernt?
Davon hängt nämlich ab, ob ein Zurücksetzen des Rollladenempfängers Sinn machen würde, da doch dann der Rolling Code auf jeden Fall wieder gesynct sein müsste, oder? Allerdings gehe ich damit vielleicht das Risiko ein, den Rollladen auch mit dem normalen Handsender nicht mehr steuern zu können, oder kann das nicht passieren?
Auf eure Antworten zu diesen Gedanken und Fragen bin ich sehr gespannt!
Vorsicht mit dem Skript, mach das besser per Hand. Ich zeige Dir mal mein Somfy, die haben nach drei Jahren
setstate RolladenAlle 2021-07-21 09:04:11 rolling_code 0232
Also nichts mit 50.000! Ich denke, Du bist bestenfalls bei rolling_code 000A oder so was. Und wenn du das so machst, wird viel zu schnell gesendet und ständig wackelt das Rollo, wie willst du das stoppen?
Nach erneutem Flashen muss nicht neu angelernt werden. Im Rolladen-device ist die "Kennung" des Rolladen gespeichert, hier
defmod RolladenAlle SOMFY 000100
und hier
setstate RolladenAlle 2021-07-21 09:04:11 enc_key A5
Das ändert sich beim flashen des signalduino nicht.
Guten Morgen capcom,
hat es geklappt oder hakt es noch immer?
LG
Bönne
Hallo zusammen,
tut mir leid für die späte Antwort.
Ich habe ein paar Mal in FHEM geklickt, allerdings habe ich nochmal ein paar Fragen bevor ich weitermache.
ZitatIch zeige Dir mal mein Somfy, die haben nach drei Jahren
Code: [Auswählen]
setstate RolladenAlle 2021-07-21 09:04:11 rolling_code 0232
Also nichts mit 50.000! Ich denke, Du bist bestenfalls bei rolling_code 000A oder so was. Und wenn du das so machst, wird viel zu schnell gesendet und ständig wackelt das Rollo, wie willst du das stoppen?
Leider hab ich noch nicht ganz verstanden und auch im Internet nichts dazu gefunden, wie genau der Rolling/Hex Code hochgezählt wird. Also warum kommt 0232 vor 000A? Kann mir das vielleicht jemand kurz erklären?
Und wie oft muss ich denn dann klicken? Und in welchen Zeitabständen? Denn schließlich muss ja die 1%-Regel eingehalten werden, das heißt ich kann ja kaum mehr als 90x pro Stunde klicken. Da bin ich doch Stunden beschäftigt, oder verstehe ich etwas falsch?
ZitatNach erneutem Flashen muss nicht neu angelernt werden. Im Rolladen-device ist die "Kennung" des Rolladen gespeichert.
Ist der SIGNALduino nach Flashen und Neu-Aufsetzen auch am echten Rollladen noch angelernt (also nicht nur am FHEM-device)? Würde dann eventuell doch das Zurücksetzen des Rollladenempfängers und damit "Ablernen" aller Sender etwas bringen? Aber welche Risiken hat das?
Es tut mir leid, dass ich leider gar nicht weiterkomme! Ich hoffe trotzdem, dass ihr mir weiterhelft.
Viele Grüße!
Zitat von: capcom am 26 Juli 2021, 09:47:29
Leider hab ich noch nicht ganz verstanden und auch im Internet nichts dazu gefunden, wie genau der Rolling/Hex Code hochgezählt wird.
25. Juli, morgens 8:10 Rolladen hoch geklickt (RollingCode 0231)
25. Juli, abends 22:15 Rolladen runter geklickt (RollingCode 0232)
25. Juli, noch was vergessen, also 22:20 wieder Rolladen hoch (RollingCode 0233)
25. Juli, 22:30 Rolladen wieder runter, dabei versehentlich auf "hoch" geklickt (RollingCode 0235)
25. Juli, 22:30 Rolladen jetzt richtig runter geklickt (RollingCode 0236)
26. Juli, morgens 8:00 Rolladen wieder rauf (RollingCode 0237)
usw usf.
Zitat von: capcom am 26 Juli 2021, 09:47:29
Ist der SIGNALduino nach Flashen und Neu-Aufsetzen auch am echten Rollladen noch angelernt (also nicht nur am FHEM-device)?
Ja, weil die für das Anlernen wichtigen Infos nicht im SIGNALduino gespeichert werden, sondern im Somfy-Gerät.
Zitat25. Juli, morgens 8:10 Rolladen hoch geklickt (RollingCode 0231)
25. Juli, abends 22:15 Rolladen runter geklickt (RollingCode 0232)
25. Juli, noch was vergessen, also 22:20 wieder Rolladen hoch (RollingCode 0233)
25. Juli, 22:30 Rolladen wieder runter, dabei versehentlich auf "hoch" geklickt (RollingCode 0235)
25. Juli, 22:30 Rolladen jetzt richtig runter geklickt (RollingCode 0236)
26. Juli, morgens 8:00 Rolladen wieder rauf (RollingCode 0237)
Ok gut, vielen Dank! Aber mir bringt das ja relativ wenig. Wenn ich nur 5 Mal am Tag klicke, komme ich ja nie zu meinem Rolling Code.
Kann ich es nicht doch mit dem Skript
define testrollingcodes at +*00:01:00 set AlleRollladen onprobieren? So klickt es ja "nur" 1 Mal pro Minute, die 1%-Regel wird eingehalten, es geht schneller und ich kann das Ganze noch rechtzeitig stoppen, wenn der richtige Code erreicht ist. Oder sehe ich das falsch?
Nein, das bringt nichts.
- Du startest in FHEM ein neues device. Das hat dann automatisch RollingCode 0000.
- Dann benutzt du das, beispielsweise wie ich, zwei Jahre lang. Dann hat es ungefähr RollingCode 0232.
- Jetzt gibt es irgendwo ein Problem. Du musst den neuen Rolling Code finden. Dann fängst du aber nicht bei 0000 an und selbst wenn Du das tun würdest, bräuchtest Du nicht Jahre, sondern bestenfalls Stunden.
- Vielmehr sagst Du Dir "pro Tag, sagen wir mal, drei Schritte im Rolling Code" und also sagst Du FHEM "jetzt nimm mal großzügig Rolling Code 0232-5=022D" und stellst also das als Rolling Code ein, klickst fünf Mal (wahrscheinlich weniger) und löst das Problem.
Du hast irgendeine andere Situation im Kopf und siehst ein Problem, wo keines ist.
Hallo zusammen,
ZitatDu hast irgendeine andere Situation im Kopf und siehst ein Problem, wo keines ist.
Ich glaube, die andere Situation bzw das Problem ist, das capcom sich gar nicht 100%ig sicher ist, dass sein SIGNALduino und das Rollo richtig miteinander kommunizieren. Bis auf die Tatsache, dass es vor der kompletten Neuinstallation einmal funktioniert hat, ist das auch für mich noch nicht ganz geklärt ;)
Dass sich das Rollo nicht noch einmal neu (als komplett neues device) anlernen lässt, finde ich zumindest komisch.
Beste Grüße
Bönne
Hallo,
Zitat von: andies am 26 Juli 2021, 16:34:34
Du hast irgendeine andere Situation im Kopf und siehst ein Problem, wo keines ist.
prinzipiell verstehe ich was du meinst, aber meiner Meinung nach ist deine Rechnung etwas zu optimistisch. Nach 18 Jahren Benutzung kann ich den Rolling Code auf keinen Fall auf 5 genau schätzen, sondern nur auf ein paar tausend genau. Ich habe bereits ca. 700 Codes getestet und noch nichts gefunden. Wenn man die 1%-Regel einhalten will, kann man meiner Meinung nach nur ca. 120x pro Stunde klicken. Wenn ich die Codes von 10.000 (HEX:2710) bis 20.000 (HEX:4E20) testen will, bedeutet das mindestens 4 Tage ständiges Klicken.
Deshalb auch von mir nochmal die Frage, ob es nicht an etwas anderem liegen könnte (siehe @Boenne) bzw. ob ein Zurücksetzen des Rollladens und damit Ablernen aller Sender vom Rollladen und ein anschließendes Neuanlernen (https://sowero.freshdesk.com/support/discussions/topics/6000010201) Sinn machen würde, wenn dabei das Risiko eines kompletten "Kontrollverlusts" nicht zu hoch ist?
Vielen Dank!
Zitat von: capcom am 20 Juli 2021, 14:26:31
vor kurzem habe ich mir einen Raspberry Pi und SIGNALduino bestellt, um damit über FHEM und Homebridge meine Somfy RTS Rollläden in HomeKit einzubinden.
HALT. Es gibt bei Dir jetzt ZWEI (sogar bis zu sieben, glaube ich) Rolling Codes in jeder Steuerung des Motors. Der Rolling Code ist an eine konkrete Steuerung gebunden. Du hast einmal das ursprüngliche Sendegerät, das du seit 18 Jahren oder so benutzt. Rolling Code irgendwas. Der ist auch uninteressant, weil Du den gar nicht nehmen darfst: Denn sendet FHEM den, erfährt das ursprüngliche Sendegerät davon nichts, kommt aus dem Takt und kann nicht mehr benutzt werden. FHEM hat mit dem Somfy Device einen
eigenen, neuen Rolling Code, der ebenfalls im Somfy Motor (genauer der Steuerung im Motor) gespeichert ist. Den musst Du herausfinden.
Zitat von: andies am 29 Juli 2021, 13:13:16
FHEM hat mit dem Somfy Device einen eigenen, neuen Rolling Code, der ebenfalls im Somfy Motor (genauer der Steuerung im Motor) gespeichert ist. Den musst Du herausfinden.
Achso, gut. Und wie mache ich das? Also beginnt dieser neue Rolling Code bei 0001 oder irgendwo anders?
Code 0000
Danke nochmal! Ich habe jetzt über 100x ab Rolling Code 0000 geklickt, aber der Rollladen bewegt sich einfach nicht. Höher kann der Code eigentlich fast nicht sein, da ich, als es noch funktioniert hat, nur ein paar Mal geklickt habe.
Zitat von: andies am 29 Juli 2021, 13:13:16
FHEM hat mit dem Somfy Device einen eigenen, neuen Rolling Code, der ebenfalls im Somfy Motor (genauer der Steuerung im Motor) gespeichert ist. Den musst Du herausfinden.
Wenn es zwei Rolling Codes gibt, hätte der von FHEM/SIGNALduino gesendete aber doch eigentlich nie den Takt verlieren dürfen. Denn es gab ja schon eine Verbindung, da es nach der Einrichtung kurz funktioniert hat. Warum hat es dann trotzdem plötzlich nicht mehr funktioniert?
Hat es vielleicht etwas mit "enc_key" zu tun? Der ändert sich auch bei jedem Klicken.
Oder damit, dass der Timestamp von bestimmten Werten (exact, position, state) nach dem Klicken rot wird?
Oder doch mit dem Neuaufsetzen des Raspis/Neuflashen des SIGNALduinos?
Oder kann das
Zitat von: andies am 29 Juli 2021, 13:13:16
Du hast einmal das ursprüngliche Sendegerät, das du seit 18 Jahren oder so benutzt. Rolling Code irgendwas. Der ist auch uninteressant, weil Du den gar nicht nehmen darfst: Denn sendet FHEM den, erfährt das ursprüngliche Sendegerät davon nichts, kommt aus dem Takt und kann nicht mehr benutzt werden.
auch umgekehrt, also mit dem SIGNALduino, passiert sein?
Vielen Dank schon im Voraus!
Also der enc_key ändert sich NICHT! Eventuell liegt da der Fehler? Und 100 mal ist zuviel, der Fehler liegt also woanders. Die rote Farbe entsteht, wenn aktualisiert wird (und verschwindet nach einer Minute, ist das korrekt @Profis?). Das ist also harmlos.
Also wir sind wieder am Anfang. Kann ich mal ein listing des somfy sehen (list <Devicename>, bitte in den #Knöpfen posten, nicht als screenshot)? Und ein listing des signalduino.
Ok, das ist zumindest mal ein Hinweis! Hier das Listing des Somfy:
Internals:
ADDRESS 000006
DEF 000006
FUUID 60f6ef47-f33f-95c0-c270-68d3c048c51489ac
IODev sduino
NAME RolloZimmer
NR 16
STATE open
TYPE SOMFY
move off
CODE:
1 000006
READINGS:
2021-07-27 23:17:07 IODev sduino
2021-07-29 19:58:20 enc_key AD
2021-07-29 19:58:20 exact 0
2021-07-29 19:58:20 position 0
2021-07-29 19:58:20 rolling_code 0072
2021-07-29 19:58:20 state open
Attributes:
IODev sduino
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
eventMap on:down stop:stop off:up
model somfyshutter
room GoogleAssistant
webCmd down:stop:up
Und hier das des SIGNALduino:
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-SHK_SIGNALduino_433-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0@57600
FD 7
FUUID 60f6811c-f33f-95c0-4c93-f8ab49b15106d978
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino
NR 15
NR_CMD_LAST_H 2
PARTIAL
STATE opened
TIME 1627420627
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.1-dev SIGNALduino - compiled at Apr 20 2017 21:06:32
versionProtocols 1.20
versionmodul v3.4.4_dev+14042020
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:
2021-07-29 19:59:58 ping OK
2021-07-21 16:28:33 rolling_code 0030
2021-07-27 23:17:15 state opened
XMIT_TIME:
1627581496
1627581500
additionalSets:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
Attributes:
verbose 3
Der SIGNALduino hat keinen rolling_code. Nur somfy hat einen. Hast du etwa den eingestellt:
2021-07-21 16:28:33 rolling_code 0030
Das würde einiges erklären. Du hättest den auf 000 stellen müssen:
2021-07-29 19:58:20 rolling_code 0072
Allerdings hat der vom SIGNALduino den richtigen Zeitpunkt (heute verändert).
Kannst du erklären, wieso sduino einen Code hat? Oder ist das ein früher falscher Versuch?
Zitat von: andies am 29 Juli 2021, 21:13:55
Der SIGNALduino hat keinen rolling_code. Nur somfy hat einen. Hast du etwa den eingestellt:
Eigentlich nicht, ich habe immer den Rolling Code von Somfy mit
setreading RolloZimmer rolling_code 0000geändert.
ZitatDas würde einiges erklären. Du hättest den auf 000 stellen müssen:
Welchen hätte ich auf 0000 stellen müssen, den von SOMFY oder den des SIGNALduino?
ZitatAllerdings hat der vom SIGNALduino den richtigen Zeitpunkt (heute verändert).
Sicher? Meiner Meinung nach hat der vom SIGNALduino sich zuletzt am 21.07. verändert, und der von SOMFY gestern.
ZitatKannst du erklären, wieso sduino einen Code hat? Oder ist das ein früher falscher Versuch?
Bewusst habe ich da keinen eingestellt. Vielleicht mal früher aus versehen. Wie kann ich das rückgängig machen bzw. was muss ich tun, um das Problem zu lösen?
Lösche mal den rolling code vom signalduino. Das hier war richtig:
setreading RolloZimmer rolling_code 0000weil dort der rolling Code hingehört.
OK, also am Anfang gab es da ein Kuddelmuddel. Wir müssen leider bei null anfangen, sonst kommen wir da nicht weiter.
- Wie viele Rollos hast du jemals bei FHEM angelernt? Bitte bei jedem das listing posten.
- Wann ging welches von diesen Rollos wie lange?
- Wie oft hast du welches von den Rollos angelernt? Wann? Mit welchem Ergebnis?
Ok, ich habe jetzt den Rolling Code des sduino gelöscht. Soll ich jetzt nochmal ab SOMFY 0000 hochklicken?
Zitat1. Wie viele Rollos hast du jemals bei FHEM angelernt? Bitte bei jedem das listing posten.
Insgesamt habe ich aktuell 2 Rollos angelernt. Davor hatte ich auch schon welche, die hab ich aber wieder gelöscht bzw. durch das Neuaufsetzen verloren. Hier die Listings der aktuell aktiven SOMFY-devices:
Internals:
ADDRESS 000006
DEF 000006
FUUID 60f6ef47-f33f-95c0-c270-68d3c048c51489ac
IODev sduino
NAME RolloZimmer
NR 16
STATE open
TYPE SOMFY
move off
CODE:
1 000006
READINGS:
2021-07-27 23:17:07 IODev sduino
2021-07-29 21:14:34 enc_key AE
2021-07-29 21:14:34 exact 0
2021-07-29 21:14:34 position 0
2021-07-30 11:21:45 rolling_code 0000
2021-07-29 21:14:34 state open
Attributes:
IODev sduino
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
eventMap on:down stop:stop off:up
model somfyshutter
room GoogleAssistant
webCmd down:stop:upInternals:
ADDRESS 000007
DEF 000007
FUUID 60ffc13c-f33f-95c0-60ab-03f7b8d69ef6bdd9
IODev sduino
NAME RolloAufgang
NR 22
STATE open
TYPE SOMFY
move off
CODE:
1 000007
READINGS:
2021-07-27 23:17:07 IODev sduino
2021-07-29 21:14:32 enc_key A9
2021-07-29 21:14:32 exact 0
2021-07-29 21:14:32 position 0
2021-07-30 11:21:59 rolling_code 0000
2021-07-29 21:14:32 state open
Attributes:
IODev sduino
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
eventMap on:down stop:stop off:up
model somfyshutter
room GoogleAssistant
webCmd down:stop:upZitat2. Wann ging welches von diesen Rollos wie lange?
Die haben beide nicht lange funktioniert, höchsten 3-5 Minuten nach Anlernen. Kurz nachdem ich das 2. Rollo angelernt habe, gingen beide nicht mehr.
Zitat3. Wie oft hast du welches von den Rollos angelernt? Wann? Mit welchem Ergebnis?
Ich hab beide Rollos ein paar Mal (ca. 10x) in FHEM gelöscht und wieder neu erstellt und dann mit "set RolloZimmer prog" versucht anzulernen. Am 21.07. habe ich das gemacht, danach auch noch ein paar Mal. Beim ersten Anlernen hat es problemlos geklappt, danach nie mehr (Der Rollladen ruckte nicht mehr auf und ab zur Bestätigung).
Ich hoffe, das hilft!
Also das wird jetzt schwierig. Ich würde zuerst einmal ab 0000 hochklicken, beim somfy device. In den FHEM Geräten sehe ich nichts auffälliges. Aber Du schreibst
Zitat von: capcom am 30 Juli 2021, 11:32:43
Ich hab beide Rollos ein paar Mal (ca. 10x) in FHEM gelöscht und wieder neu erstellt und dann mit "set RolloZimmer prog" versucht anzulernen.
Wenn man den von Dir genannten Befehl das erste Mal eingibt, wird das Rollo angelernt. Beim zweiten Mal wird es abgelernt. Beim dritten Mal wieder angelernt usw usf.
Wenn Du zwischendurch aber die
ADDRESS 000006in der Definition des FHEM-Gerätes
geändert hast, dann wird ein neues Gerät angelernt, das alte verbleibt im Speicher des Motors. Der wiederum kann mW maximal zwölf verschiedene Handsender/FHEM Geräte aufnehmen, das steht hier https://www.rollorieper.de/images/rolladen/beschreibung_rolladenmotor_oximo_rts.pdf (https://www.rollorieper.de/images/rolladen/beschreibung_rolladenmotor_oximo_rts.pdf). Es könnte also im worst case sein, dass der Speicher des Motors voll ist und deshalb die Anlernbefehle nicht mehr funktionieren. Dann müsste der Motor komplett zurückgesetzt werden und ich habe die Jungs bei mir gesehen, wie die das gemacht haben. Das war Schwerstarbeit (vielleicht waren das auch nicht die hellsten, keine Ahnung), mit Anruf bei Somfy etc pp. Hier bräuchte ich also nochmal Infos.
Hallo, also ich hab jetzt wieder 50x bei beiden Rollladen geklickt, es hat sich nichts bewegt.
ZitatWenn man den von Dir genannten Befehl das erste Mal eingibt, wird das Rollo angelernt. Beim zweiten Mal wird es abgelernt. Beim dritten Mal wieder angelernt usw usf.
Dann hätte es aber doch spätestens beim dritten Anlernen wieder funktionieren müssen, wenn ein neuer Platz belegt wird nach An-, Ab- und wieder Anlernen, oder? Allgemein finde ich das mit dem An- und Ablernen aber eher komisch/unwahrscheinlich, da es ja auch beim dritten Mal nicht zur Bestätigung geruckt hat.
ZitatWenn Du zwischendurch aber die ADDRESS in der Definition des FHEM-Gerätes geändert hast, dann wird ein neues Gerät angelernt, das alte verbleibt im Speicher des Motors. Der wiederum kann mW maximal zwölf verschiedene Handsender/FHEM Geräte aufnehmen. Es könnte also im worst case sein, dass der Speicher des Motors voll ist und deshalb die Anlernbefehle nicht mehr funktionieren.
Meiner Meinung nach habe ich es sicher nicht so oft geändert, dass der Speicher voll ist, vielleicht nur 4x komplett neu (Sonst habe ich immer ohne Löschen "set RolloZimmer prog" gemacht). Da davor nur 1 Sender angelernt hat, ist eine Überbelegung meiner Meinung nach unwahrscheinlich, eben auch weil es direkt nach dem ersten Anlernen nie mehr wie bei einem neuen Anlernen auf- und ab geruckt hat.
Zitatich habe die Jungs bei mir gesehen, wie die das gemacht haben. Das war Schwerstarbeit (vielleicht waren das auch nicht die hellsten, keine Ahnung), mit Anruf bei Somfy etc pp.
Damit ist ein Zurücksetzen auf jeden Fall raus, das möchte ich mir nicht antun.
Welche Infos bräuchtest du denn noch bzw. hast du noch eine andere Idee, an der es liegen könnte? Kann es nicht doch etwas mit enc_key zu tun haben, der ändert sich nämlich immer noch.
Nach Aussage dieses Posts ist der enc_key unproblematisch
https://forum.fhem.de/index.php/topic,53319.msg786652.html#msg786652 (https://forum.fhem.de/index.php/topic,53319.msg786652.html#msg786652)
PS FHEM ist aktuell?
Zitat von: andies am 02 August 2021, 10:01:41
Nach Aussage dieses Posts ist der enc_key unproblematisch
https://forum.fhem.de/index.php/topic,53319.msg786652.html#msg786652 (https://forum.fhem.de/index.php/topic,53319.msg786652.html#msg786652)
Ok, gut!
FHEM ist aktuell, ich habe es die ganze Zeit regelmäßig aktualisiert.
Was machen wir dann jetzt?
Mir gehen langsam die Ideen aus. Du hast ein Rollo angelernt, das ging. Dann hast du ein zweites Rollo angelernt. Ging das zweite? Nach dem ersten Post ging das zweite nicht und das erste auf einmal auch nicht.
Ich hätte darauf getippt, dass die Definition des zweiten Rollos die Bedienung des ersten beeinflusst hat. Das wäre dann der Fall, wenn zB die Adressen gleich sind. Das ist aber nach dem listing beider Geräte nicht der Fall (einmal 6 und einmal 7).
Dann hast du das mehrfach nochmal probiert. Welche Adressen hast du da genommen? jeweils unterschiedliche? Oder wieder 6 und 7?
Dann habe ich mir den sduino nochmal angeschaut. Da lese ich
LASTDMSG nothing
LASTDMSGID nothing
was ich nur bedingt verstehe (evtl empfängt der nichts). Die Readings müsste ich auch mal sehen, Bandbreite und so.
ZitatDu hast ein Rollo angelernt, das ging. Dann hast du ein zweites Rollo angelernt. Ging das zweite?
Ja, kurz gingen beide, aber dann ging auf einmal keins mehr.
ZitatIch hätte darauf getippt, dass die Definition des zweiten Rollos die Bedienung des ersten beeinflusst hat. Das wäre dann der Fall, wenn zB die Adressen gleich sind.
Dann hast du das mehrfach nochmal probiert. Welche Adressen hast du da genommen? jeweils unterschiedliche? Oder wieder 6 und 7?
Ich bin mir relativ sicher, dass ich auch am Anfang zwei verschiedene Adressen verwendet habe. Ganz sicher bin ich mir aber auch nicht mehr. Am Anfang hatte ich auch noch andere Adressen, ich hab von 000001 bis 000007 alle Adressen durch und zwischendurch auch mal 12345F probiert.
ZitatDann habe ich mir den sduino nochmal angeschaut. Da lese ich ... was ich nur bedingt verstehe (evtl empfängt der nichts). Die Readings müsste ich auch mal sehen, Bandbreite und so.
Hier das sduino Reading, oder meinst du ein anderes?
Readings
[b]ping[/b]
OK
2021-08-03 15:42:55
[b]state[/b]
opened
2021-08-02 10:08:34Was bedeutet dein eingefügter Code bzw. was heißt, dass der sduino nichts empfängt? Er blinkt ja, sobald man auf up oder down klickt, aber im Logfile steht tatsächlich nichts. Kann da der Fehler liegen?
Zitat von: capcom am 03 August 2021, 15:48:33
Ja, kurz gingen beide, aber dann ging auf einmal keins mehr.
Merkwürdig. Sehr merkwürdig. Dann hat das Anlernen geklappt und ich tippe jetzt eher auf den sduino. Dass auf einmal der Rolling Code nicht geht, ist unplausibel.
Zitat von: capcom am 03 August 2021, 15:48:33
Am Anfang hatte ich auch noch andere Adressen, ich hab von 000001 bis 000007 alle Adressen durch und zwischendurch auch mal 12345F probiert.
Wenn der sduino in der Zeit ging, wäre der Speicher des Motors vermutlich voll.
Zitat von: capcom am 03 August 2021, 15:48:33
Hier das sduino Reading, oder meinst du ein anderes?
Nein, mache mal
list sduinound poste alles, was da steht. Danach vielleicht auch noch "verbose 5" beim sduino und dann einmal bitte das Rollo ansteuern ("RolloZimmer up" oder was auch immer), ich will das mal mit meinen Ausgaben vergleichen. Gibt es andere Geräte, die auf 433 MHz funken und die du empfangen kannst? Ich will sehen, ob der sduino etwas empfängt.
Was ist das für ein sduino? Selbst gebaut? Wo gekauft etc pp.? Wer hat den geflasht?
Hallo,
hier das Listing des sduino:
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-SHK_SIGNALduino_433-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0@57600
FD 7
FUUID 60f6811c-f33f-95c0-4c93-f8ab49b15106d978
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino
NR 15
PARTIAL
STATE opened
TIME 1628049045
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.1-dev SIGNALduino - compiled at Apr 20 2017 21:06:32
versionProtocols 1.20
versionmodul v3.4.4_dev+14042020
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:
2021-08-08 14:01:20 ping OK
2021-08-04 05:50:52 state opened
additionalSets:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
Attributes:
verbose 3Hier das Logfile mit verbose 5:
2021.08.08 14:06:57 3: sduino: Attr, setting Verbose to: 5
2021.08.08 14:07:09 5: sduino: Write, sending via Set sendMsg P43#AF8B8BCACCCCCC#R6
2021.08.08 14:07:09 5: sduino: Set_sendMsg, msg=P43#AF8B8BCACCCCCC#R6
2021.08.08 14:07:09 5: sduino: Set_sendMsg, Preparing manchester protocol=43, repeats=0, clock=645 data=AF8B8BCACCCCCC
2021.08.08 14:07:09 5: sduino: AddSendQueue, sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC; (1)
2021.08.08 14:07:09 4: sduino: Set_sendMsg, sending : SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:09 4: sduino: HandleWriteQueue, called
2021.08.08 14:07:09 4: sduino: SendFromQueue, called
2021.08.08 14:07:09 5: sduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:09 4: sduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:10 4: sduino: Read, msg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:10 5: sduino: Parse, noMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:10 5: sduino: Read, msg: regexp=.* cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:10 4: sduino: CheckSendrawResponse, sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF8B8BCACCCCCC;
2021.08.08 14:07:11 4: sduino: HandleWriteQueue, called
2021.08.08 14:07:11 4: sduino: HandleWriteQueue, nothing to send, stopping timerZitatGibt es andere Geräte, die auf 433 MHz funken und die du empfangen kannst? Ich will sehen, ob der sduino etwas empfängt.
Es gäbe noch eine Hörmann-Garage/Empfänger, aber die funkt ja eigentlich nicht die ganze Zeit. Vielleicht kommt auch noch was von den Nachbarn. Woran sieht man, ob der sduino etwas empfängt?
ZitatWas ist das für ein sduino? Selbst gebaut? Wo gekauft etc pp.? Wer hat den geflasht?
Ich habe den sduino hier gekauft: https://www.smart-home-komponente.de/nano-cul/nano-cul-433/
und selber mit dieser Firmware geflasht: https://www.smart-home-komponente.de/support/firmware/ (SIGNALDuino_nanoCC1101.hex)
Zitat von: capcom am 08 August 2021, 14:11:38
hier das Listing des sduino:
Bitte einmal
get sduino ccconfund
get sduino ccpatable
Also ich habe auch mal verbose 5 gemacht und meinen Code im Logfile mit Deinem verglichen. Ich sehe da keinen großen Unterschied (bis auf die Adressen), sonst aber nicht. Wenn ich die beiden Auszüge aus dem vorigen Post habe, kann ich auch sehen, ob vielleicht die Sendestärke zu gering ist, das war bei mir mal.
Du kannst den Empfang beim sduino testen, indem du mal verbose 5 für eine Weile offen lässt. Da erscheinen dann Sachen wie
2021.08.08 14:31:10 4: sduino: Parse_MS, Matched MS protocol id 0.5 -> weather (v6)
2021.08.08 14:31:10 5: sduino: Parse_MS, Starting demodulation at Position 2
2021.08.08 14:31:10 5: sduino: Read, RAW rmsg: Ms;��;��;�ށ;��;Dag`````gg`gg`gg`````````g````````g`g`;C6;S1;REF;e;m1;
2021.08.08 14:31:10 4: sduino: Read, msg READredu: MS;P0=-2023;P1=-9061;P6=478;P7=-4065;D=61676060606060676760676760676760606060606060606067606060606060606067606760;CP=6;SP=1;R=239;e;m1;
2021.08.08 14:31:10 4: sduino: Parse_MS, Matched MS protocol id 0.3 -> weather (v4)
2021.08.08 14:31:10 5: sduino: Parse_MS, Starting demodulation at Position 2
2021.08.08 14:31:10 5: sduino: Parse_MS, dispatching bits: 1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 with 4 Paddingbits 0
2021.08.08 14:31:10 4: sduino: Parse_MS, Decoded matched MS protocol id 0.3 dmsg s836C0100A000 length 40 RSSI = -82.5
2021.08.08 14:31:10 5: sduino: Dispatch, s836C0100A000, test gleich
2021.08.08 14:31:10 4: sduino: Dispatch, s836C0100A000, Dropped due to short time or equal msg
2021.08.08 14:31:10 4: sduino: Parse_MS, Matched MS protocol id 0.5 -> weather (v6)
2021.08.08 14:31:10 5: sduino: Parse_MS, Starting demodulation at Position 2
das ist ein Regen- oder Windmesser, zum Beispiel.
PS Noch eine Idee. Du hast eine sehr alte Version
version
V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
da könnte man ein update probieren. Mit
get sduino availableFirmware
zum Beispiel.
ZitatBitte einmal get sduino ccconf und get sduino ccpatable
Ich habe die Befehle gerade probiert, aber ich bekomme leider den Fehler "This command is only available with a cc1101 receiver", obwohl mein SIGNALduino eigentlich einen CC1101 Receiver haben sollte. Was habe ich falsch gemacht?
Zitatda könnte man ein update probieren
Das mit dem Firmwareupdate hat irgendwie auch nicht geklappt, ich habe jetzt eine Version von 2017:
version V 3.3.1-dev SIGNALduino - compiled at Apr 20 2017 21:06:32ZitatDu kannst den Empfang beim sduino testen, indem du mal verbose 5 für eine Weile offen lässt.
Verbose 5 habe ich eine Weile laufen lassen, da erscheint immer nur
2021.08.08 16:58:20 4: sduino: KeepAlive, not ok, retry = 1 -> get ping
2021.08.08 16:58:20 5: sduino: AddSendQueue, sduino: P (1)
2021.08.08 16:58:20 4: sduino: HandleWriteQueue, called
2021.08.08 16:58:20 4: sduino: SendFromQueue, called
2021.08.08 16:58:20 5: sduino: SimpleWrite, P
2021.08.08 16:58:20 4: sduino: Read, msg: OK
2021.08.08 16:58:20 5: sduino: Parse, noMsg: OK
2021.08.08 16:58:20 5: sduino: Read, msg: regexp=^OK$ cmd=ping msg=OK
2021.08.08 16:58:20 4: sduino: HandleWriteQueue, called
2021.08.08 16:58:20 4: sduino: HandleWriteQueue, nothing to send, stopping timer
Da ist was bei Deinem signalduino falsch eingerichtet. OK, dann haben wir wenigstens etwas. (Ich erinnere mich übrigens, dass ich auch so einen CUL hatte, der aber bei mir nie funktionierte. Ich habe den immer noch, aber nicht im Betrieb.)
Zuerst einmal müsste die Hardware richtig eingestellt sein, wenn ich das korrekt erinnere:
https://forum.fhem.de/index.php?topic=66294.0 (https://forum.fhem.de/index.php?topic=66294.0)
Wobei ich vermute, du musst diese Reihenfolge einhalten:
https://forum.fhem.de/index.php/topic,87107.msg795456.html#msg795456 (https://forum.fhem.de/index.php/topic,87107.msg795456.html#msg795456)
Mach das mal und berichte dann, am besten wieder mit einem kompletten list.
Als nächstes fragen wir Ralf9, der kennst sich besser aus. Ich denke, wir haben das Problem zumindest identifiziert. Es sollte am sduino liegen. Der empfängt ja auch nix.
Das Senden von Somfy RTS sollte eigentlich mit jeder Firmware funktionieren.
Beim Empfangen gibts einiges wo passen muss:
Die Frequenz 433.420 MHz
Welche Fernbedienung soll mit dem sduino empfangen werden.
Mit der firmware und 00_Signalduino Modul von Sidey können nicht alle Fernbedienungen empfangen werden und es sind sehr gute Empfangsbedingungen erforderlich.
https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881
Gruß Ralf
Stimmt, das ist noch eine Idee. Wenn das mit dem flashen durch ist, bitte verbose 5 und einmal die Somfy-Fernbedienung drücken. Da müsste im Log was zu sehen sein. Wichtig: bei autocreate bitte attribut "disable 1" setzen, sonst wird ein Gerät angelegt und da kommt FHEM dann der normalen Fernbedienung in die Quere.
Hallo, tut mir leid für die späte Antwort!
ZitatZuerst einmal müsste die Hardware richtig eingestellt sein, wenn ich das korrekt erinnere:
https://forum.fhem.de/index.php?topic=66294.0
Das hilft mir glaube ich wenig, da mein SIGNALduino/Arduino mit einem Schrumpfschlauch ummantelt ist. Ich komme nicht an die Kontakte/Pins ran. Es sieht zwar von außen alles sauber und gut verlötet aus, aber einen Hardware-Defekt kann ich natürlich nicht ausschließen. Ist es möglich, dass, nachdem es kurz funktioniert hat, direkt ein Hardwareteil kaputt gegangen ist?
ZitatWobei ich vermute, du musst diese Reihenfolge einhalten:
https://forum.fhem.de/index.php/topic,87107.msg795456.html#msg795456
Mach das mal und berichte dann, am besten wieder mit einem kompletten list.
Auch nach
attr sduino hardware nanoCC1101funktionieren
get sduino ccconfund
get sduino ccpatablenicht, auch ein Neustart von FHEM hat das nicht geändert.
set sduino flashvon hier: https://forum.fhem.de/index.php/topic,87107.msg795456.html#msg795456
geht auch nicht, da bekomme ich
ERROR: argument failed! flash [hexFile|url]Ich habe leider keine Ahnung, ob ich damit jetzt irgendwas geflasht oder geändert habe. Sagt bitte, wenn ich noch was anderes probieren soll.
Hier trotzdem das List:
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-SHK_SIGNALduino_433-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0@57600
FD 7
FUUID 60f6811c-f33f-95c0-4c93-f8ab49b15106d978
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino
NR 15
PARTIAL
STATE opened
TIME 1629030668
TYPE SIGNALduino
sendworking 0
version V 3.3.1-dev SIGNALduino - compiled at Apr 20 2017 21:06:32
versionProtocols 1.21
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:
2021-08-15 14:35:10 ping OK
2021-08-15 14:31:10 state opened
additionalSets:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
Attributes:
debug 1
hardware nanoCC1101
verbose 5Nun zum nächsten Post von @Ralf9:
ZitatWelche Fernbedienung soll mit dem sduino empfangen werden.
Der Rollladenempfänger/-motor ist ein SOMFY Platine RTS (https://www.somfy.de/downloads/de/ga_platine__rts_rev_02_04_2007_vm.pdf), die Fernbedienung eine alte Telis 1-RTS (http://www.handsender-esma.com/handsender-somfy-telis-1-rts-old/). Die Fernbedienung ist genau die, die hier (https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881) fast vernachlässigt wurde.
ZitatMit der firmware und 00_Signalduino Modul von Sidey können nicht alle Fernbedienungen empfangen werden und es sind sehr gute Empfangsbedingungen erforderlich.
Natürlich kann ich andere Funkeinstrahlungen von Nachbarn etc. nicht beurteilen, aber an der Reichweite sollte es nicht liegen. Erstens hat es ja schonmal funktioniert und inzwischen beträgt der Abstand zwischen Sender und Empfänger noch maximal 3 Meter ohne Hindernisse.
Zitathttps://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881
Was müsste ich den machen/installieren, wenn es hieran liegt? Also was bedeutet das mit den Bits?
Nun noch zum letzten Post:
ZitatWichtig: bei autocreate bitte attribut "disable 1" setzen, sonst wird ein Gerät angelegt und da kommt FHEM dann der normalen Fernbedienung in die Quere.
Kann es sein, dass autocreate schon davor für Probleme gesorgt hat, da ich es nie deaktiviert hatte? Ich habe mal was im Zusammenhang von autocreate und der Installation des SIGNALduino gelesen: https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino#Definition_des_SOMFY_Devices_sowie_setzten_der_Attribute:_Kein_Autocreate.21
Bewusst aktiv benutzt habe ich Autocreate aber eigentlich nicht.
ZitatWenn das mit dem flashen durch ist, bitte verbose 5 und einmal die Somfy-Fernbedienung drücken. Da müsste im Log was zu sehen sein.
Leider ist bei mir im Logfile nichts zu sehen, außer das normale:
2021.08.15 14:49:10 4: sduino: Read, msg: OK
2021.08.15 14:49:10 5: sduino: Parse, noMsg: OK
2021.08.15 14:49:10 5: sduino: Read, msg: regexp=^OK$ cmd=ping msg=OK
2021.08.15 14:49:11 4: sduino: HandleWriteQueue, called
2021.08.15 14:49:11 4: sduino: HandleWriteQueue, nothing to send, stopping timer
2021.08.15 14:50:10 4: sduino: KeepAlive, ok, retry = 0
2021.08.15 14:51:10 4: sduino: KeepAlive, not ok, retry = 1 -> get ping
2021.08.15 14:51:10 5: sduino: AddSendQueue, sduino: P (1)
2021.08.15 14:51:10 4: sduino: HandleWriteQueue, called
2021.08.15 14:51:10 4: sduino: SendFromQueue, called
2021.08.15 14:51:10 5: sduino: SimpleWrite, P
2021.08.15 14:51:10 5: sduino: Read, RAW: /OKWahrscheinlich liegt das noch am Fehlerhaften Flashen (siehe oben).
Ich bin auf eure Ideen, wie man das noch lösen soll, gespannt.
Also, ich bin mir sicher, dass das nichts mit somfy zu tun hat. Der sduino funktioniert nicht (richtig). Ich hatte auch mal so einen wie Du, der ging mir einen Tag und dann nicht wieder. Ich habe gerade nachgeschaut, ich habe den nichts mehr.
Eine Option ist jetzt, das Attribut hardware zu verändern und daran herumzuspielen. Da du das gekauft hast: kannst du da nachfragen wie man das flash? Das scheint mir der Knackpunkt zu sein.
Ich habe nur eine alte Lötplatine, aber ohne Bestückung - wenn die funktionsfähig gewesen wäre, hätte ich Dir die mal geschickt, einfach zum ausprobieren. Wenn du den gekauft hast, frage wegen Garantie nochmal nach. Ansonsten würde ich ein neues Gerät probieren.
Alles klar, vielen Dank!
Wenn sich wirklich alle sicher sind, dass es sich um ein Hardwareproblem handelt, frage ich nochmal beim Verkäufer nach.
Ich melde mich dann wieder, wenn es etwas Neues gibt.
Der "DevState initialized" bedeutet, das "get version" und "get ping" funktioniert,
dann müsste auch ein "get ccconf" funktionieren.
Hast Du das "get sduino ccconf" in der Kommandozeile eingegeben?
Oder wie normalerweise üblich über das get Pulldownmenü?
Gruß Ralf
ZitatHast Du das "get sduino ccconf" in der Kommandozeile eingegeben?
Oder wie normalerweise üblich über das get Pulldownmenü?
Ich hab es über die Kommandozeile eingegeben, im Pulldownmenü kann man bei mir "ccconf" nicht auswählen.
Ich habe im Pulldown-Menü mal "config" ausgewählt, da kommt
config: MS=1;MU=1;MC=1
version V 3.3.1-dev SIGNALduino - compiled at Apr 20 2017 21:06:32
Wenn bei version "cc1101" nicht enthalten ist, dann hat der sduino keinen cc1101 oder es wurde kein cc1101 erkannt.
Bitte mach mal ein Foto von Deinem sduino.
Gruß Ralf
Alles klar, hier die Fotos.
Beim 1. Foto sehen die Lötstellen gut aus.
Beim 2. Foto sehen ganz rechts die 2. und 3. Lötstellen von unten nicht sauber gelötet aus.
Dein sduino hat eine recht alte Firmware, mit dieser wird der somfy Empfang wahrscheinlich nicht funktionieren.
Ich hab mal testweise meine Firmware V 3.3.2.1-rc9 auf einen nano ohne cc1101 geflasht
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nanoCC1101_3321rc9.hex
Da bekomme ich dann nach einem reset des nano in fhem mit verbose 4 oder mit einem seriellen Monitor (z.B. die Arduino IDE) die folgenden Meldungen:
Using sFIFO
Reading values from eeprom
CCInit no CC11xx found! ccVer=0 ccPartnum=0
Starting timerjob
receiver enabled
Gruß Ralf
Hi Ralf, aber ist das nicht ein CC1101? Steht zumindest auf der Platine?
Beim 2.Foto lassen sich an der Stiftleiste des CC1101 Moduls einige unsaubere Lötstellen erkennen, dies kann der Grund sein warum der cc1101 nicht erkannt wird.
Wenn bei der Initialisierug der cc1101 nicht erkannt wird, gibt meine Firmware folgendes aus:
CCInit no CC11xx found! ccVer=0 ccPartnum=0
wenn der cc1101 erkannt wird dann wird "CCInit ok ..." ausgegeben und bei "get version" ist in der version "cc1101" enthalten
Alles klar, aber soll ich dann jetzt den Verkäufer kontaktieren oder nur die aktuellere Firmware flashen?
Wenn ich mir die Lötstellen anschaue, kann ich eigentlich dort wo Ralf sagt nichts Unsauberes erkennen (siehe nochmal 3. Foto). Höchstens von der Seite (siehe 1. + 2. Foto).
Du kannst mal meine Firmware flashen:
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nanoCC1101_3321rc9.hex
und dann ein log Auszug mit sduino verbose 4 posten, wenn Du den sduino einsteckst
Ok, ich habe die Firmware geflasht, aber "get sduino ccconf" und so funktionieren immer noch nicht (Fehlermeldung: "This command is only available with a cc1101 receiver")
Hier aber der Log-Auszug mit Verbose 4, sieht aus als wäre kein CC1101 erkannt worden:
2021.08.22 16:56:15 3: sduino: Attr, setting Verbose to: 4
2021.08.22 16:56:35 3: Setting sduino serial parameters to 57600,8,N,1
2021.08.22 16:56:35 1: sduino: DoInit, /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0@57600
2021.08.22 16:56:35 1: /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0 reappeared (sduino)
2021.08.22 16:56:36 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2021.08.22 16:56:36 4: sduino: Read, msg: Using sFIFO
2021.08.22 16:56:36 4: sduino: Read, msg: Reading values from eeprom
2021.08.22 16:56:37 4: sduino: Read, msg: CCInit no CC11xx found! ccVer=0 ccPartnum=0
2021.08.22 16:56:37 4: sduino: Read, msg: Starting timerjob
2021.08.22 16:56:37 4: sduino: Read, msg: receiver enabled
2021.08.22 16:56:37 3: sduino: StartInit, get version, retry = 0
2021.08.22 16:56:37 4: sduino: Read, msg: V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 20:18:01
2021.08.22 16:56:37 2: sduino: CheckVersionResp, initialized v3.4.4
2021.08.22 16:56:37 3: sduino: CheckVersionResp, enable receiver (XE)
Kann es auch daran liegen, dass die neuen Bootloader 115200 statt wie früher 57600 als Rate haben und das falsch eingestellt ist? Flashen musste ich nämlich mit 115200, sonst ging es nicht.
Flashen des Arduino ging übrigens auch nicht in FHEM direkt (Terminalfeld und Pulldown-Menü), sondern nur extern am PC über XLoader.
Und noch ein List des sduino, falls es hilft:
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-SHK_SIGNALduino_433-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-SHK_SIGNALduino_433-if00-port0@57600
FD 10
FUUID 60f6811c-f33f-95c0-4c93-f8ab49b15106d978
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino
NR 15
PARTIAL
STATE opened
TIME 1629629240
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 20:18:01
versionProtocols 1.21
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:
2021-08-19 16:10:57 config MS=1;MU=1;MC=1
2021-08-22 16:58:37 ping OK
2021-08-22 16:56:37 state opened
additionalSets:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
Attributes:
debug 1
hardware nanoCC1101
verbose 4
ZitatOk, ich habe die Firmware geflasht, aber "get sduino ccconf" und so funktionieren immer noch nicht (Fehlermeldung: "This command is only available with a cc1101 receiver")
Diese Befehle funktionieren nur wenn die Firmware einen cc110x erkannt hat.
2021.08.22 16:56:37 4: sduino: Read, msg: CCInit no CC11xx found! ccVer=0 ccPartnum=0Die Firmware hat bei der Initialisierung den cc1101 nicht erkannt. Eine Ursache könnte eine nicht sauber gelötete Lötstelle oder ein defektes cc1101 Modul sein.
ZitatKann es auch daran liegen, dass die neuen Bootloader 115200 statt wie früher 57600 als Rate haben und das falsch eingestellt ist? Flashen musste ich nämlich mit 115200, sonst ging es nicht.
Das flashen mit dem neuen optiboot sollte eigentlich auch mit dem 00_Signalduino Modul ab der Version v3.4.4 funktionieren:
if ($hardware =~ "^nano" && $^O eq 'linux') {
$hash->{logMethod}->($name ,5, "$name: PrepareFlash, try additional flash with baudrate 115200 for optiboot");
$hash->{helper}{avrdudecmd} = $hash->{helper}{avrdudecmd}." || ". $hash->{helper}{avrdudecmd};
$hash->{helper}{avrdudecmd} =~ s/\Q[BAUDRATE]\E/$baudrate/;
$baudrate=115200;
}
Ok, dann frage ich jetzt den Verkäufer, oder?
Ich habe die Lötstellen an der Stiftleiste des cc1101 Moduls im Verdacht, Du kannst mal versuchen ob es was bringt, wenn Du vor dem Einstecken des sduinos etwas am cc1101 Modul wackelst
Das hat leider nichts geholfen, der CC1101 wird immer noch nicht erkannt. Ich werde dann wohl den Verkäufer fragen.
https://forum.fhem.de/index.php/topic,122608.msg1171683.html#msg1171683 (https://forum.fhem.de/index.php/topic,122608.msg1171683.html#msg1171683)
Hallo zusammen,
der neue Stick ist da und tatsächlich: Es funktioniert!!! Ich kann die Rolläden wieder steuern.
Vielen Dank an alle für die kompetente und geduldige Hilfe!
Das einzige was jetzt noch fehlt ist eine gute Anpassung an HomeKit und Google Assistant. Mit dem Google Assistant fährt der Rollladen momentan in die falsche Richtung, bei Homebridge wird er als Schalter angezeigt. Und stoppen kann man ihn so auch nicht.
Diese Anpassung heißt doch Homebridge-Mapping, oder?
Hat irgendjemand Tipps oder Forumsbeiträge, in denen das erklärt wird?
Vielen Dank nochmals für die Hilfe!
Zitat von: capcom am 07 September 2021, 17:57:43
Das einzige was jetzt noch fehlt ist eine gute Anpassung an HomeKit und Google Assistant. Mit dem Google Assistant fährt der Rollladen momentan in die falsche Richtung, bei Homebridge wird er als Schalter angezeigt. Und stoppen kann man ihn so auch nicht.
Diese Anpassung heißt doch Homebridge-Mapping, oder?
Hat irgendjemand Tipps oder Forumsbeiträge, in denen das erklärt wird?
Soll ich dafür ein neues Thema öffnen?
ja, ist besser
Alles klar, vielen Dank nochmal!