Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[hajo23]

Nein, dies funktioniert nicht über den Dbg-header.
Für WLAN gibts eine Firmware direkt auf das ESP32 DEVKIT V1 oder ESP32 D1 mini
https://forum.fhem.de/index.php?topic=83273.msg755123#msg755123

hmm, das meinte ich nicht.

Du hast in #1 dieses Bild für den SDuino angehängt:

Zeigt das nicht die Bridge über den D1 mini?

[Ralf9]

Das funktioniert nicht so gut wie die firmware direkt auf dem ESP32.
Das mit der Bridge ist recht zeitkritsch, das funktioniert nicht mit jeder Bridge.
Dafür gibts noch keine fertige Firmware.
Diese muss ich bei Bedarf erst noch erstellen.

[hajo23]

Also, an einem seriellen Zugang hätte ich schon Interesse, wenn der abgesehen von der Bridge keine weiteren Probleme macht.

Für WLAN gäbe es auch noch die Möglichkeit einen nrf24l01 alternativ zum LAN-Modul anzuschließen, aber wie gut das funktioniert weiß ich nicht.

Gruß Hajo

[Ralf9]

ich bin gerade an einer neuen Version V 4.2.3 da mache ich dann auch eine Firmware Maple_cul_serial

[Ralf9]

Ich bin gerade an einer neuen Version V 4.2.3 hier sind vorab schon mal die Neuerungen:

- Bug beim Speichern der SlowRf config behoben:
  wenn Modul A (868 MHz) und Modul B (433 MHz) für SlowRf verwendet wurde, wurde die config (MS=1;MU=1;MC=1;...) nicht getrennt gespeichert.
  Wenn z.B. bei Modul A die config nach (MS=1;MU=0;MC=0) geändert wurde, wurde diese config für beide Module gespeichert
  Es ist zu empfehlen (wenn Modul A + B SlowRf), wenn nicht benötigt, bei Modul A MC zu deaktivieren (config: A: MS=1;MU=1;MC=0;)

- bei get Version werden Module mit deaktivertem Empfang in Kleinbuchstaben dargestellt, z.B. (R: A1* b0)

- Beim raw Befehl WS kann nun auch das Modul (radio) angegeben werden, z.B. WSAD für WS3D auf Radio A

- Mit dem raw Befehl Cff kann die cc1101 Frequenz angezeigt werden.
  Mit dem raw Befehl TF kann die cc1101 Frequenz gesetzt werden, z.B. TF868.370
  Damit kann dann zum Testen ohne FHEM (z.B. im Seriellen Monitor oder im Telnet) die cc1101 Frequenz angezeigt und gesetzt werden.

- Bei manchen cc1101 Modulen, kann es vorkommen, daß beim Aktivieren des Empfängers der PLL Lock nicht klappt,
  dies kommt nur bei sehr wenigen cc1101 Modulen vor und ist auch von der Art der empfangenen FSK Nachricht abhängig.
  Dies kann durch auslesen des Registers Hex 25 festgestellt werden, bei HEX 3F hat der PLL Lock nicht geklappt.
  Es gibt dafür den raw Befehl TL.
  Mit TL wird nach jeder empfangenen FSK Nachricht das Register 0x25 auf 0x3F getestet und ggf z.B. bei Radio A "PLL0_r=A" ausgegeben.
  Mit TL0 wird der PLL Lock Test wieder deaktiviert.
  Mit TL[radio] kann angegeben werden, bei welchem radio das PLL Lock getestet wird und ggf duch erneutes calibrieren der PLL Lock wiederholt wird.

- Mit dem raw Befehl T kann beim Maple die STM32 Coreversion und beim ESP32 die ESP_IDF Version ausgegeben werden

- MAX Geräte werden nun auch unterstützt.

 

[Ralf9]

In der Anlage sind einige Firmware bin Files der V 4.2.3
Sie ist jetzt auch im meinem github.
Bei platformio wird bei LAN der aktuelle core 19.0.0 verwendet, da muß die SIGNALduinoAdv.ino in SIGNALduinoAdv.ino.cpp umbenannt werden.

[hajo23]

Hallo Ralf,

vielen Dank für die serielle Version.
Ich habe die Maple_cul_serial_423dev250214.bin geflasht und bekomme nach einiger Zeit einen Fehler:

Code Auswählen Erweitern

2025.03.15 16:15:41 4: Maple_Sduino_usb/msg READ: ␂MU;P0=-1640;P1=121;P2=-1027;P3=976;P4=-512;P5=411;P6=-14224;P7=552;CP=3;R=230;D=1232323232323232323232323232323452543452543234523232543452543234525434523232323232543452323254323452543232345254345232323254345254345254323452323254345232323232323232325432323452323232325434523254345232325434525432323232323234521670;e;␃
2025.03.15 16:15:41 4: Maple_Sduino_usb: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2025.03.15 16:15:41 4: Maple_Sduino_usb: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2025.03.15 16:15:41 4: Maple_Sduino_usb: Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
Undefined subroutine &main::SIGNALduinoAdv_compPattern called at ./FHEM/00_SIGNALduino.pm line 3072.
ERROR: Unexpected FHEM termination, waiting to reappear
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
/entry.sh: line 850: kill: (15492) - No such process
ERROR: FHEM did NOT reappear, Restarting FHEMDanach startet FHEM neu.

[Ralf9]

Vermutlich passen bei Dir die Versionen vom 00_SIGNALduino und signalduino_protocols.pm nicht zusammen.
Bitte poste mal die Internals versionmodul und versionprotoL.
Aktuell ist v3.5.3-ralf_13.02.25

versionmodul und versionprotoL müssen die gleiche Version haben, das Datum darf unterschiedlich sein.

v3.4.17 ist die letzte Version als 00_SIGNALduino.pm.
Ab v3.5.x habe ich 00_SIGNALduino.pm in 00_SIGNALduinoAdv.pm umbenannt

[hajo23]

versionmodul
   
v3.4.17-ralf_07.11.23
versionprotoL
   
v3.5.3-ralf_13.02.25

[Ralf9]

Die verschiedenen Versionen sind der Grund warums nicht richtig funktioniert.

Ich habe nun das 00_SIGNALduino.pm in 00_SIGNALduinoAdv.pm umbenannt. Es war im Code recht viel umzubenennen. Ich habe es noch nicht komplett getestet.
Dadurch hat sich auch der TYPE in SIGNALduinoAdv geändert
z.B.

Code Auswählen Erweitern

define sduino SIGNALduinoAdv /dev/serial/by-id/usb...
versionmodul v3.5.3-ralf_...
versionprotoL v3.5.3-ralf_...

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/SIGNALduinoAdv_FHEM/master/controls_ralf9_signalduino.txt

Wenn Du das 00_SIGNALduinoAdv.pm Modul verwenden möchstest, dann musst Du bei der sduino Definition den Type in SIGNALduinoAdv ändern.

Entweder in der fhem.cfg umbenennen oder die sduino Definition löschen und neu anlegen

[hajo23]

Klar, beim Anlegen habe ich das übersehen. Ich habe das Gerät nun neu definiert und dieser Fehler ist weg. Leider läuft der Maple-Cul gar nicht rund.

Ich habe habe 3 Radios (A-C 868 MHz) und 3 Bänke (0-2) konfiguriert:
A0 LC (M1), B1 SlowRF und C2 Bresser als Zielkonfiguration.

Auf A0 bzw. C2 sollte ich ständig Daten von 7 TX29 und einer 7in1 empfangen. Auf B1 gibt es nur ab und an eine FS20 Nachricht von einer Fernbedienung.

Ich kann FS20 (B1) senden und empfangen. Senden über A1 (FS20) geht nicht, empfangen geht. Senden über C habe ich nicht getestet. Die Daten über A0 und C2 ebben nach kurzer Zeit ab. Daten von A0 sehe ich dann nur noch alle 10-20 Minuten. C liefert aber gar nichts mehr. Empfange ich eine FS20 Nachricht (B1), liefert auch C2 wieder für kurze Zeit Daten. Nach einem Reset wiederholt das sich Ganze.

Der Maple-Cul hängt seriell über einen FTDI-Adapter an einem PI. Die Verbinung zum FTDI ist stabil. Über die Verbindung vom FTDI zum Maple kann ich nicht viel sagen. Ich denke aber, dass die Anbindung insgesamt stabil ist, weil ich die FS20 Nachrichten immer sofort empfange.

Ich habe mal ein paar log-Daten (maple_cul) angehängt. Am Ende sieht man nur noch keepalives. Das geht dann noch so 10-20 min weiter. Und zum Vergleich ein log aus einem maple-sduino. Der sduino steht fast daneben, hat aber Magnetfußantennen. Der Empfang sollte dadurch etwas besser sein, als beim cul.

Eine V 4.2.3 Maple-Cul USB habe ich nicht gefunden und deshalb nicht getestet.

Was mir noch aufgefallen ist:
Nach einem rfmode slowRF wird immer 433 MHz ausgegeben. Das Radio empfängt aber trotzdem auf 868 MHz. Wenn ich die Frequenz dann explizit auf 868.35 MHz setzte, macht es also keinen Unterschied, ist aber gut fürs Auge.
Bei rfmode Lacrosse_mode1 wird die Frequenz auf 868.30 MHz eingestellt. Die TX29 empfange ich aber nur bei 868.35 MHz.

[Ralf9]

SlowRF funktioniert nur auf Modul A und B
Für das Senden von SlowRF auf Modul A gibts das Attribut sendSlowRF_A_IDs
"Hier können komma getrennt die protocolId angegeben bei denen das cc1101 Modul A zu senden verwendet wird."

Es gibt 868 MHz Module wo die Frequenz nicht genau passt, evtl hast Du so ein Modul.
Du kannst mal testen ob es besser wird, wenn Du die Frequenz ein klein wenig änderst.

Wenn beim cc1101 der Empfänger aktiviert wird dauert es kurz bis die eingestellte Frequenz erreicht wird.
Wenn die eingestellte Frequenz nicht genau passt, kann es sein, dass die Frequenz am Anfang kurz passt.

Nach einem rfmode slowRF wird immer 433 MHz ausgegeben. Das Radio empfängt aber trotzdem auf 868 MHz. Wenn ich die Frequenz dann explizit auf 868.35 MHz setzte, macht es also keinen Unterschied, ist aber gut fürs Auge.

Da kenne ich mich nicht aus, hängt evtl mit Oberwellen zusammen.
Wenn der cc1101 auf 433 eingestellt ist müssten die 868 Nachrichten aber mit sehr schwachen RSSI Werten empfangen werden.