Hallo liebe Forengemeinde,
mit viel Hilfe von euch habe ich nun ein SIGNALduino auf mein ESP32-Devboard bekommen und ein 868Mhz CC1101 angeschlossen. Es funktioniert erheblich besser als ich erwartet habe! Ich hatte ursprünglich vor meinen neuen 433MHz-Deckenventilator versuchen zu schalten, wozu ich mir gestern aus China extra noch 3 verschiedene 433MHz CC1101-Module bestellt habe. Ein 868Mhz Modul habe ich schon länger hier, bin aber nie dazu gekommen mal mit FHEM zu "spielen". Damit wollte ich jetzt eigentlich nur mal üben: Ich habe im ganzen Haus FS20 Aktoren verbaut und steuere diese bisher über meine eigene Lösung an (diverse Umsetzer mit PIC16).
Nun gefällt das so gut, dass ich eigentlich komplett auf FHEM umstellen möchte. Das verrückte dabei: Der SIGNALduino mit 868MHz CC1101 startet in Grundstellung im 433MHz-Modus. Obwohl es eigentlich ein 868MHz Modul ist, konnte ich direkt 3 verschiedene Wetterstationen meiner Nachbarn empfangen und der 433MHz-Deckenventilator im Nachbarzimmer lässt sich auch einwandfrei mit SD_UT steuern.
Nur meine FS20 Komponenten ließen sich erst erkennen und dann auch einwandfrei schalten, wenn ich zuvor die Frequenz umstelle:
set mycc cc1101_freq 868.35
So werden aber die Wetterstationen nicht mehr erkannt und auch mein Ventilator lässt sich nicht schalten. Zurückschalten in 433MHz-Grundstellung geht dabei ohne Wertangabe: set mycc cc1101_freq
=> Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5.60 kBaud
Jetzt aber meine konfiguriertechnische Anfängerfrage, zu der ich nach intensiver Suche im Forum leider nichts finden konnte: Kann man FHEM so konfigurieren, dass er nur zum reinen Senden von FS20-Befehlen die Frequenz des CC1101 automatisch kurz auf 868MHz umschaltet und nach Aussendung direkt wieder automatisch auf 433MHz zurückschaltet? Denn FS20 Befehle möchte ich RX-mäßig gar nicht überwachen. Ich habe da eh keine Sensoren im Einsatz, die eine Überwachung irgendwie sinnvoll machen würden.
Danke im Voraus,
Dominik
ZitatKann man FHEM so konfigurieren, dass er nur zum reinen Senden von FS20-Befehlen die Frequenz des CC1101 automatisch kurz auf 868MHz umschaltet und nach Aussendung direkt wieder automatisch auf 433MHz zurückschaltet?
Die SIGNALduino Firmware kann zum Senden kurz die Frequenz wechseln, dies wird aber vom FS20 FHEM-Modul nicht unterstützt.
Wenn mit set sendmsg gesendet wird, gibts eine Frequenz Option.
Dazu muss zuerst das sduino verbose auf 5 gesetzt werden, und dann ein FS20-Befehl gesendet werden.
Im Log steht dann z.B.
2023.06.22 12:59:14.420 3: FS20 set FS20_7c4b01 on
2023.06.22 12:59:14.420 5: sduinoA/write: sending via Set sendMsg P74#00000000000010111110010100101100000000110001000101101111110P#R3
2023.06.22 12:59:14.420 5: sduinoA: sendmsg msg=P74#00000000000010111110010100101100000000110001000101101111110P#R3Bei dem sendmsg muss dann #Fxxxxxx angehängt werden
#F21656a für 868.3 MHz
#F2165e8 für 868.35 MHz
Dies kann dann mit set sendmsg gesendet werden.
z.B.
set sduino sendmsg P74#00000000000010111110010100101100000000110001000101101111110P#R3#F21656aEine andere Möglichkeit ist ein 868 und ein 433 MHz cc1101 Modul zu verwenden.
Gruß Ralf
Zitat von: Ralf9 am 22 Juni 2023, 14:01:27Die SIGNALduino Firmware kann zum Senden kurz die Frequenz wechseln, dies wird aber vom FS20 FHEM-Modul nicht unterstützt.
Wenn mit set sendmsg gesendet wird, gibts eine Frequenz Option.
Dazu muss zuerst das sduino verbose auf 5 gesetzt werden, und dann ein FS20-Befehl gesendet werden.
Im Log steht dann z.B.
2023.06.22 12:59:14.420 3: FS20 set FS20_7c4b01 on
2023.06.22 12:59:14.420 5: sduinoA/write: sending via Set sendMsg P74#00000000000010111110010100101100000000110001000101101111110P#R3
2023.06.22 12:59:14.420 5: sduinoA: sendmsg msg=P74#00000000000010111110010100101100000000110001000101101111110P#R3Bei dem sendmsg muss dann #Fxxxxxx angehängt werden
#F21656a für 868.3 MHz
#F2165e8 für 868.35 MHz
Dies kann dann mit set sendmsg gesendet werden.
z.B.
set sduino sendmsg P74#00000000000010111110010100101100000000110001000101101111110P#R3#F21656a
Dank Dir Ralf für den Tipp. Leider will der bei mir einfach nicht: Ich habe den sendMsg (Das "M" in sendMsg muss übrigens zwingend Großbuchstabe sein) Befehl extrahiert. Er funktioniert einwandfrei, wenn die Frequenz vorher auf 868,35MHz gesetzt wurde. Auch mit der o.g. trailer für die Frequenz #F2165e8 oder alternativ #F21656a funktioniert der Befehl dann. Doch sobald ich den Signalduino auf 433MHz zurückschalte, funktioniert es leider nicht mehr. Weder mit #F2165e8 noch mit #F21656a am Ende.
ZitatEine andere Möglichkeit ist ein 868 und ein 433 MHz cc1101 Modul zu verwenden.
Das geht dann aber nur mit 2 separaten Signalduinos? Oder kann der (original) Signalduino auch mehrere CC1101 Module? Dann benötige ich die inoffizielle advanced Version. Das Pinout des ESP32 ist dort leider völlig anders (müsste auch das 1.Modul komplett neu verlöten), aber schon machbar. Viel mehr Probleme macht mir das Aufspielen der FW. Ich war ja froh, dass ich die des orignal-Signalduino irgendwann zum Laufen gebracht habe. Dann muss fhem noch darauf gepatched werden und ist dann wohl auch nicht mehr einfach updatebar. Ich weiß nicht, ob ich mir das alles als Anfänger wirklich zutrauen kann/sollte?
Die email Benachrichtigung bei neuen Nachrichten funktioniert anscheinend nicht immer. Ich habe keine email Benachrichtigung bekommen.
ZitatEr funktioniert einwandfrei, wenn die Frequenz vorher auf 868,35MHz gesetzt wurde. Auch mit der o.g. trailer für die Frequenz #F2165e8 oder alternativ #F21656a funktioniert der Befehl dann. Doch sobald ich den Signalduino auf 433MHz zurückschalte, funktioniert es leider nicht mehr. Weder mit #F2165e8 noch mit #F21656a am Ende.
Ich habs bei mir mal getestet, da ich keinen FS20 Empfänger habe, habe ich einen zweiten SIGNALduino (sduinoE 868 MHZ) verwendet.
Den sduinoA habe ich auf 433 MHz gesetzt.
Ich habe dann dies gesendet:
set sduinoA sendMsg P74#00000000000010111110010100101100000000110001000101101111110P#R3#F21656aMit verbose 4 habe ich die folgende Antwort bekommen
2023.06.25 15:05:42.516 4: sduinoA/read sendraw answer: SR;R=3;P0=600;P1=-600;P2=400;P3=-400;P4=-10000;D=232323232323232323232323012301010101012323012301232..ccreg write back 10B071Diesen Schaltbefehl habe ich erfolgreich am 868 MHz sduinoE empfangen.
Ich habe dies mit meiner Firmware getestet, mit der offiziellen Firmware müsste es genauso funktionieren.
Vielleicht kann dies mal jemand testen der die offizielle Firmware verwendet und FS20 Empfänger hat.
Du kannst auch mal die Anzahl der repeats (#R3) von 3 auf 10 erhöhen.
ZitatDas Pinout des ESP32 ist dort leider völlig anders (müsste auch das 1.Modul komplett neu verlöten),
Bei meiner Firmware ist das cc1101 Modul B das Standard Modul, dies hat die selbe Belegung wie die offizielle Firmware.
Normalerweise ist Modul B 433MHz und Modul A 868MHz, es funktioniert aber auch umgekehrt.
Gruß Ralf
Danke vielmals für die ganze Mühe Ralf! Ich hatte es mittlerweile auch am Laufen und nun mein fhem leider zerlegt. :(
Ich habe die fhem-6.2.deb Direkt von der https://fhem.de Startseite installiert. Damit habe ich mit sendMsg genau das verhalten, dass es NICHT funktioniert wie zuvor beschrieben, wenn die vie 'set sduino cc1101 freq' gesetzte Frequenz nicht übereinstimmt.
Dann wollte ich heute morgen einen maple mini probieren, den ich vor einigen Jahren dafür mal bestellt habe. Ich habe dann wie in dem Wiki https://wiki.fhem.de/wiki/Maple-SignalDuino angegeben auf die Advanced-Version upgedated via:
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/dev/controls_dev_ralf9_signalduino.txt
Heute abend, nach Deiner Antwort, habe ich es noch mal probiert und nun funktionierte tatsächlich das sendMsg-Kommando wie gewünscht. Wollte zur Gegenprobe dann noch mal auf das Original zurück wie im Wiki angegeben mit
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
Damit habe ich mir dann was zerschossen, dass der Signalduino gar nicht mehr lief. Nun das .deb wieder drübergejagt und ich kann das Verhalten von gestern reproduzieren. Es schein also, dass es nur mit den advanced Modul funktioniert und nicht mit den originalen aus fhem 6.2
Nun überlege ich, ob ich mit dem Workaround lebe. Gerade wenn man noch fs20 timer nutzen wöllte, wäre das FS20-Modul schon schöner.
Auf dem Maple Mini habe ich heute morgen nach langem Kampf die Firmware Maple_sduino_USB_422dev20220712 aufspielen können: Die Firmware ließ sich via dfu-util nicht einspielen, da der Bootloader zu alt. Der Bootloader ließ sich nicht updaten: Mit dfu-util konnte ich die updater_stm32f1.bin zwar einspielen, aber Beim aufrufen der seriellen Konsole /dev/ttyACM0 hing sich der Maple Mini immer etwa be cai 3/4 der Textausgaben auf. Ich habe verschiedene Terminal-Emulatoren (putty, minicom, arduino serial), 2 Rechner und verschiedene USB-Kabel probiert. Gleicher Fehler, allerdings an unterschiedlichen Textstellen im Terminal. Die LED des Maple Mini erlöscht dabei auch (blinkt nicht mehr). Ein blinder "Y" im Terminal brachte auch kein Bootloader update. Neben dfu-util konnte ich (vermutliche das gleiche) Bootloader Update auch erfolgreich über arduino kompilieren und flashen via "updater_stm32f1.ino".
Erst als ich extern mit einem 3,3V USB-TTL-Adapter entsprechend verbunden, boot1 gegroundet und stm32flash_linux die maple_mini_boot20.bin direkt einspielen.
Danach klappte das Flashen der Maple_sduino_USB_422dev20220712 mit dfu-util problemlos und auf /dev/ttyACM0 meldet sich signalduino auch brav. Ich habe CC1101 Modul A mit CREA aktiviert und Modul B mit CRDB deaktiviert, da ich noch kein 433MHz Modul habe. Modul B war ja standardmäßig aktiviert. Funktioniert das überhaupt ohne Modul B? Muss B überhaupt zwingend 433MHz sein, oder darf man die beiden auch vertauschen (also A 433MHz und B 868MHz)?
Allerdings konnte ich mich bei den Temperaturen hier heute, absolut nicht mehr zum Löten motivieren. Nun noch weniger, da Dein "Workaround" mit sendMsg tatsächlich läuft. Dann meine ich noch zusätzlich irgendwo gelesen zu haben, dass man mit 2 CC1101 Modulen an einem Signalduino gar nicht beide Frequenzen gleichzeitig permanent überwachen zu können (also für autocreate und überhaupt). Ist das richtig? Wären zwei völlig seperate Signalduinos dann doch vorteilhafter (bis auf den Strom- und Portverbrauch)?
Dank Dir noch mal für die Mühe und Antwort,
Dominik
PS: Achja, das Pinout für Port B ist tatsächlich identisch. Ich habe mich da wohl verschaut, bzw. GPIO mit PIN verwechselt. Sorry!
ZitatIch habe CC1101 Modul A mit CREA aktiviert und Modul B mit CRDB deaktiviert, da ich noch kein 433MHz Modul habe. Modul B war ja standardmäßig aktiviert. Funktioniert das überhaupt ohne Modul B? Muss B überhaupt zwingend 433MHz sein, oder darf man die beiden auch vertauschen (also A 433MHz und B 868MHz)?
Kurze Antwort, da ich morgen für ein paar Tage in die Berge fahre, etwas ausfühlicher dann später.
Es gibt 2 Einschränkungen, ASK/OOK (slowrf) funktioniert nur auf Modul A und B. WMBUS funktioniert nur auf einem Modul und nicht auf Modul D.
Es sollte auch ohne Modul B funktionieren.
Modul A 433 und Modul B 868 funktioniert auch.
Gruß Ralf
Dank Dir noch mal Ralf.
Ich habe nun endlich 433MHz CC1101 Module bekommen. Ich habe den Maple Mini erst mal wieder beiseite gelegt und heute Deine FW ESP32_sduino_devkitV1_422dev20220712 erfolgreich auf meinen funktionierenden ESP32 gespielt mit esptool.py. Das hat diesmal glücklicherweise auf Anhieb funktioniert. Ein 433Modul habe ich zusätzlich als Modul A angelötet. Eingerichtet nach Wiki-Anleitung mit:
get ESP raw CREA #aktiviert Radio A
get ESP cmdBank A0 #selektiert Radio A und aktiviert Speicherbank 0
set ESP rfmode SlowRF_CCFactoryReset
set ESP cc1101_freq 433.92
get ESP cmdBank A0W
get ESP raw CREB #aktiviert Radio B
get ESP cmdBank B1 #selektiert Radio B und aktiviert Speicherbank 1
set ESP rfmode SlowRF_CCFactoryReset
set ESP cc1101_freq 868.35
get ESP cmdBank B1W
get ESP cmdBank r
cmdBank:
A: b=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
B* b=1 freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Empfangsmäßig funktioniert es auch. Ich empfange sowohl 868 als auch 433Mhz Nachrichten. Nur fehlt mir irgendwie noch das Verständnis, wie das mit dem Senden funktioniert. Er sendet offensichtlich immer nur mit Modul B auf 868MHz. Auch wenn ich mit "get ESP cmdBank A0" die erste Bank auswähle. Das Sternchen wandert dann an Modul A -> (R: A0* B1).
Die FS20-Aktoren lassen sich weiterhin steuern. Mein 433MHz SD_UT Gerät leider nicht. Also mit der Original-FB kann ich es bedienen und sehe die empfangenden Befehle sogar im SD_UT log. Nur aussenden geht nicht. Ich muss dem SD_UT Gerät doch irgendwie mitteilen, welches Modul es von Signalduino zum Senden nutzen soll?
Nochmal tausend Dank für die Hilfe,
Dominik
Hallo Dominik,
zum Senden von slowrf über Modul A gibts das Attribut "sendSlowRF_A_IDs"
ZitatNur für MapleSduino Firmware ab V 4.12
Hier können komma getrennt die protocolId angegeben bei denen das cc1101 Modul A zu senden verwendet wird.
Bei Modul B wird zum Senden das Standard raw Kommando SR verwendet "set sduino raw SR;..."
Bei Modul A wird zum Senden das raw Kommando SRA verwendet "set sduino raw SRA;..."
Gruß Ralf
Hallo Ralf,
danke mal wieder für Deine superschnelle Antwort. Leider habe ich da wohl Verständnisprobleme:
Zitat von: Ralf9 am 02 Juli 2023, 23:22:43zum Senden von slowrf über Modul A gibts das Attribut "sendSlowRF_A_IDs"
Danke, ich habe das Attribut gesetzt und sehe es auch in http://localhost:8083/fhem?detail=ESP unter Attributes:
sendSlowRF_A_IDs Ven deleteattr
Nur ob es gesetzt ist oder nicht macht offenbar keinen Unterschied. Beides funktioniert nach wie vor nicht und mit verbosity 5 sehe ich keinen unterschied im log:
ESP: Ven set light_on_off
ESP SW: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP SendrawFromQueue: msg=SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/msg READ: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/noMsg Parse: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/msg READ: regexp=^S(R|C|M|N); cmd=sendraw msg=SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/read sendraw answer: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/HandleWriteQueue: nothing to send, stopping timer
ESP Attr: sendSlowRF_A_IDs enabled: Ven
ESP: Ven set light_on_off
ESP SW: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP SendrawFromQueue: msg=SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/msg READ: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/noMsg Parse: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/msg READ: regexp=^S(R|C|M|N); cmd=sendraw msg=SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/read sendraw answer: SR;R=5;P0=-11725;P1=335;P2=-670;P3=-335;P4=670;D=01343434343421212121212134;
ESP/HandleWriteQueue: nothing to send, stopping timer
ZitatBei Modul B wird zum Senden das Standard raw Kommando SR verwendet "set sduino raw SR;..."
Bei Modul A wird zum Senden das raw Kommando SRA verwendet "set sduino raw SRA;..."
Leider verstehe ich den Wink nicht: Das sollte mit dem o.g. sendSlowRF_A_IDs Attribut dann automatisch gehen oder muss ich dazu direkt in der 14_SD_UT.pm den Sendebefehl anpassen?
Kann es sein, dass mein 433MHz Modul defekt oder verkehrt angeschlossen ist und die SPI-Kommunikation nicht richtig funktioniert? Der Empfang scheint ja zu funktionieren. Kann es also sein, dass MOSI nicht da ist?
Danke,
Dominik
Nachtrag: Jetzt klappt es: ID ist nicht der Name, sondern irgendwas Internes. Auf der Seite http://localhost:8083/fhem?detail=Ven finde ich:
Internals
DEF RH787T 0
ESP_DMSG P83#07E
ESP_DMSGequal 5
ESP_MSGCNT 19
ESP_Protocol_ID 83
Die 83 gesetzt (attr ESP sendSlowRF_A_IDs 83) und schon funktioniert es! Ich lasse mein Irrtum mal so stehen, falls noch jemand das Problem hat und die Suchfunktion nutzt
Mit ID ist die Protokoll ID gemeint, siehe auch in der Protokollliste:
https://ralf9.github.io/SD_Device_Proto.html
ZitatBei Modul B wird zum Senden das Standard raw Kommando SR verwendet "set sduino raw SR;..."
Bei Modul A wird zum Senden das raw Kommando SRA verwendet "set sduino raw SRA;..."Leider verstehe ich den Wink nicht: Das sollte mit dem o.g. sendSlowRF_A_IDs Attribut dann automatisch gehen oder muss ich dazu direkt in der 14_SD_UT.pm den Sendebefehl anpassen?
Das ist nur eine Hintergrundinfo falls mal direkt ein raw Sendebefehl zum sduino gesendet werden soll.
Die Wandlung in den raw Befehl macht das fhem Modul automatisch