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

[Reinhard.M]

Hallo Ralf,
für die Defines wollte ich auch schon eine eigene Header vorschlagen. Werde kommende Woche mal einen Vorschlag ausarbeiten. Falls nicht jemand anderes schneller ist 

[Telekatz]

@Telekatz hast Du dafür eine Erklärung?

Ich vermute mal, das sind irgendwelch gespeicherten Konfigurationseinstellungen, die beim Flashen einer neuen Firmwareversion nicht überschrieben werden. Hast du eine Factory Reset Funktion für die Konfigurationseinstellungen?

[Ralf9]

Ich vermute mal, das sind irgendwelch gespeicherten Konfigurationseinstellungen, die beim Flashen einer neuen Firmwareversion nicht überschrieben werden. Hast du eine Factory Reset Funktion für die Konfigurationseinstellungen?

Ich habe einen Befehl "e" zum zurücksetzen des gewählten cc1101 und der zugeordneten EEPROM Bank auf die SlowRF defaults,
und einen Befehl "eC" für die Factory Reset Funktion der Konfig im EEPROM.
Da locutus testweise auch die a-culw geflasht hatte, wurde dann durch die nicht mehr passende Versionswerte am Anfang des EEPROMs schon automatisch die Factory Reset Funktion ausgeführt.

Ich werde im Maple Signalduino Wiki am Ende ein Abschnitt "Debugging / weiteres" ergänzen und dort u.a. zum Factory Reset was schreiben.

für die Defines wollte ich auch schon eine eigene Header vorschlagen. Werde kommende Woche mal einen Vorschlag ausarbeiten. Falls nicht jemand anderes schneller ist

Ich denke es macht Sinn dafür ein neues Thema aufzumachen oder im Github zu schreiben.
Ich kann Vorschläge für einen Namen für die neue Header Datei gebrauchen.


Ich habe mal die Protocol ID Übersicht angeschaut, und geschaut bei welchen Protocol IDs der vergrößerte Messagepuffer deutliche Vorteile bringt:

- Bei der protocol-id 85 sendet der TFA 30.3222.02 sehr lange Nachrichten. Er sendet die Daten ca 6 mal mit jeweils 140 Pulsen. Dies ergibt eine Datengesamtlänge von über 800.
  Mit dem seitherigen maximalem messagepuffer von 254 würden sie nur einmal empfangen.

Von den folgenden Protocol IDs kann ich noch lange MU-Nachrichten gebrauchen

Code Auswählen Erweitern

"48"    => ## Joker Dostmann TFA 30.3055.01

"54" => ## TFA Drop 30.3233.01 - Rain gauge

"69" => ## Hoermann HSM2, HSM4, HS1-868-BS (868 MHz)

"82" => ## Fernotron shutters and light switches

"95" => # Techmar / Garden Lights Fernbedienung, 6148011 Remote control + 12V Outdoor receiver

"105" => # Remote control BF-301 (Roller shade system) from Shenzhen BOFU Mechanic & Electronic Co.

[Ralf9]

Es gibt eine neue Version meines angepassten 00_SIGNALduino.pm fhem Moduls
versionmodul: v3.4.5-dev_ralf_05.07.
versionprotoL: v3.4.5-dev_ralf_05.07.

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/RFFHEM/master/controls_signalduino.txt

https://github.com/Ralf9/RFFHEM/commits/master

Init für Maple Mini optimiert
perlcritic
Device specific help aktualisiert
neue  protocol ID 105 für remote control BF-301  (Roller shade system) von markisol

[FunkOdyssey]

Per Zufall bin ich auf diesen Thread gekommen und habe diesen kurz überflogen.
Ich habe einen 4-fach-MapleCUL von Locutus (https://forum.fhem.de/index.php/topic,80872.0.html).
Ich konnte das nicht auf Anhieb erkennen, aber kann man diese SIGNALDuino-Entwicklung nicht nur auf einem Maple Mini installieren, sondern auch auf ältere MapleCULs?

[Ralf9]

Ich habe einen 4-fach-MapleCUL von Locutus (https://forum.fhem.de/index.php/topic,80872.0.html).
Ich konnte das nicht auf Anhieb erkennen, aber kann man diese SIGNALDuino-Entwicklung nicht nur auf einem Maple Mini installieren, sondern auch auf ältere MapleCULs?

USB  "Maple_cul_USB_411dev200627.bin"
und WLAN "Maple_cul_serial_411dev200627.bin"
sollte eigentlich funktionieren.
Laut Schaltplan wird wie beim Maple Mini der STM32F103CBT6 verwendet.
Ich gehe mal davon aus, daß bei allen Varianten das zweite cc1101 Modul 433 MHz ist.

Gruß Ralf

[Ralf9]

So wies aussieht läufts inzwischen recht stabil.
Bei der USB Version habe ich eine uptime von 14 Tagen
Bei der LAN Version habe ich eine uptime von 15 Tagen.

Ich habe auch das 36_PCA301.pm Modul für den Signalduino erweitet
https://github.com/Ralf9/36_PCA301.pm

Liest hier jemand mit der einen WS 1600 (TX22) hat?

@nagelreo
Ich habe das Wiki und "erste Schritte" überarbeitet, ich hoffe, daß es so besser verständlich ist.

Was für eine Hoermann Fernbedienung hast Du?
Für Hoermann gibts die Protokol ID 69

Code Auswählen Erweitern

"69" => ## Hoermann HSM2, HSM4, HS1-868-BS (868 MHz)
Ich könnte einige raw Nachrichten (es müssten MU-Nachrichten sein) brauchen.

Gruß Ralf

[FunkOdyssey]

USB  "Maple_cul_USB_411dev200627.bin"
und WLAN "Maple_cul_serial_411dev200627.bin"
sollte eigentlich funktionieren.
Laut Schaltplan wird wie beim Maple Mini der STM32F103CBT6 verwendet.
Ich gehe mal davon aus, daß bei allen Varianten das zweite cc1101 Modul 433 MHz ist.

Ich habe große Lust, das auszuprobieren. Ich muss es nur leider mit der echten Umgebung ausprobieren.
An meinem MapleCUL habe ich noch einen HM-MOD-UART. Hat die neue Signalduino-Firmware Einfluss darauf?
Entschuldige, dass ich möglicherweise komische Fragen stelle.

[Ralf9]

An meinem MapleCUL habe ich noch einen HM-MOD-UART. Hat die neue Signalduino-Firmware Einfluss darauf?

Der Bezeichnung nach (MapleCUL) ist die Anbindung über USB.
Der HM-MOD-UART wird mit der Signalduino-Firmware nicht funktionieren. Eine serielle durchleitung über USB ist mit der Signalduino-Firmware wahrscheinlich nicht machbar.

[FunkOdyssey]

Schade. Ich möchte ungern wieder eine Vielzahl an CULs in Betrieb nehmen.
Ich mag Signalduino aufgrund seiner stetigen Weiterentwicklung und der Vielzahl an unterstützen Geräte. Nicht weil ich diese brauche, sondern einfach nur weil ich es könnte. 

Der Wechsel von MapleCUL (ja, USB) auf Maple-Signalduino wäre daher ganz mein Wunsch gewesen. Aber dann müsste ich mir für Homematic eine neue Lösung einfallen lassen.

Ich habe die Unterschiede nie so richtig verstanden:
- Signalduino decodiert in der Hardware/Firmware?
- Und MapleCxx überlassen das den FHEM-Modulen?

Sorry fürs offtopic.

[Ralf9]

Ich habe die Unterschiede nie so richtig verstanden:
- Signalduino decodiert in der Hardware/Firmware?
- Und MapleCxx überlassen das den FHEM-Modulen?

Nein umgekehrt, der Signalduino überträgt die raw Nachrichten zum FHEM-Modul, dort erfolgt dann die Decodierung mit Hilfe der Protocol IDs.
Beim Cul erfolgt die Decodierung in der Firmware.

[Ralf9]

Ich finde das Flashen des Bootloaders noch recht kompliziert, dies müsste doch evtl noch etwas einfacher gehen?
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen

Momentan ist entweder ein USB TTL Adapter oder die Arduino IDE mit dem passenden core notwendig.

Es müsste doch eigentlich auch ohne die Arduino IDE funktionieren, wenn die updater_stm32f1.ino compiliert wird und dann das bin File mit dem dfu-util geflasht wird
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/updater_stm32f1/updater_stm32f1.ino

Kann bitte mal jemand die updater_stm32f1.ino mit dem core von Roger und der upload method "bootloder orginal" compilieren und das bin File dann hier posten?
Ich möchte testen ob man damit auch den bootloader 2.0 flashen kann.

Es fehlt auch noch eine Beschreibung wie man erkennen kann ob auf dem Maple Mini der orginal Bootloader oder bereits der bootloader 2.0 drauf ist.

Gruß Ralf

[Ralf9]

Ich habe es mit der updater_stm32f1.bin mal getestet.

Eine Möglichkeit zum Testen ob bereits der Bootloader 2.0 drauf ist, ist einfach mal versuchen die Maple_sduino firmware zu flashen.
Dazu die reset Taste drücken und innerhalb einer Sekunde, folgenden Befehl ausführen:

Code Auswählen Erweitern


sudo ./dfu-util -v -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200627.bin -R

wenn das flashen erfolgreich war kommt ungefähr die folgende Ausgabe

Code Auswählen Erweitern

...
Download        [=========================] 100%        67404 bytes
Download done.
Sent a total of 67404 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode

Wenn das flashen der firmware nicht funktioniert, muß der Bootloader 2.0 geflasht werden.
Dazu die reset Taste drücken und innerhalb einer Sekunde, folgenden Befehl ausführen (updater_stm32f1.bin siehe Anlage)

Code Auswählen Erweitern

sudo ./dfu-util -v -d 1eaf:0003 -a 1 -D updater_stm32f1.bin

Danach die Resettaste drücken und den seriellen Monitor der Arduino IDE oder ein anderes serielles Terminal mit einer Baudrate von 9600 öffnen
Wenn die folgende Ausgabe kommt, "Y" senden.

Code Auswählen Erweitern

  Serial.println ("**************************************************************************************************");
  Serial.println ("*** This sketch will update the bootloader in the Maple Mini to the STM32duino bootloader     ****");
  Serial.println ("*** With this you can use up to 120KB of Flash and 20KB of RAM for a Sketch                   ****");
  Serial.println ("*** Uploading is also considerably faster on OSX (and possibly faster on Linux)               ****");
  Serial.println ("***                                                                                           ****");
  Serial.println ("***                      Only use with Maple mini boards                                      ****");
  Serial.println ("***                                                                                           ****");
  Serial.println ("*** WARNING. If the update fails your Maple mini may not have a functional bootloder.         ****");
  Serial.println ("***                                                                                           ****");
  Serial.println ("***                            YOU UPDATE AT YOUR OWN RISK                                    ****");
  Serial.println ("***                                                                                           ****");
  Serial.println ("***                         To confirm and proceed, enter Y                                   ****");


Wenn die folgende Ausgabe kommt, war das Flashen des Bootloader 2.0 erfolgreich und es kann mit den o.g. Befehl die Maple_sduino firmware geflasht werden

Code Auswählen Erweitern

Writing flash page 1 of 7
Writing flash page 2 of 7
Writing flash page 3 of 7
Writing flash page 4 of 7
Writing flash page 5 of 7
Writing flash page 6 of 7
Writing flash page 7 of 7

Update completed successfully. - Please test by uploading a different sketch


Wenn aber die Meldung "WARNING, Update Failed!!..." kommt hat das flashen nicht geklappt.
Die ursache kann z.B. eine "flash read-protection sein", dann funktioniert das flashen des Bootloader 2.0 nur mit einem USB TTL Adapter, siehe hier
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
https://wiki.fhem.de/wiki/MapleCUN#Firmware_flashen:


Hat jemand Erfahrung wie oft das vorkommt, daß bei einem neuen MapleMini eine "flash read-protection" drin ist?

Gruß Ralf

[Ralf9]

Inzwischen läufts bei mir stabil.
Ich habe produktiv eine LAN Version mit 2 cc1101 Modulen und einer uptime von fast 29 Tagen.

Auf einem Testsystem auf einem BananaPi hängt eine USB Version mit 3 cc1101 Modulen und einer uptime von 28 Tagen
Ein "get sduino cmdBank s" siehe Anlage.
Mit dem cc1101 B empfange ich meine WH3080 und 7 Temperatursensoren
Mit dem cc1101 A empfange ich ca alle 5 sec ein Technoline TX29 DTH-IT und schreibe die Temperatur alle 10 Min in ein Filelog, es sind keine Aussetzer erkennbar.
Mit dem cc1101 C mache alle 10 Min ein Statusrequest einer PCA301 Steckdose und speichere die Power in einem Filelog, es sind auch keine Aussetzer erkennbar.


Ich habe in der ersten Nachricht eine Beschreibung ergänzt
"einfacher SIGNALduino mit nur einem cc1101 Modul"

Gruß Ralf

[meier81]

Hey und guten Morgen,

hab mal ne Frage bezüglich dem SIGNALduino V4. Ich nutze zur Zeit in meinem Produktivsystem noch einen SIGNALduino mit einem Arduino nano, FW-Version V 3.3.2.1-rc9, SW-Version v3.4.4.

Ich steuere hier meine Jarolift-Rollläden über den SIGNALduino mittels Rollo-Modul und AutoShuttersControl. Jetzt ist mir aufgefallen das meine Rollläden nicht ganz in die Beschattungsstellung fahren, was sich auf die Fahrzeit zurückführen lässt. Das Rollo-Modul gibt die Anweisung zum fahren des Rollos und startet den Timer für die Fahrzeit, mein Rollladen fährt aber erst evtl. 2 Sekunden später los, was natürlich für den Stand des Rollladens schon falsch ist.

Das ASC-Modul setzt bei mir 7 Rollläden gleichzeitig auf "Beschattung", dieses gibt die Fahrbefehle an das Rollo-Modul weiter, das verarbeitet diese auch zeitgleich und gibt sie an den SIGNALduino weiter, diese kommen laut Log auch zeitgleich an:

Code Auswählen Erweitern

2020.07.29 08:44:54 3: SIGNALduino: JaroLift set down 10
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 9
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 8
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 5
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 6
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 7
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 3

Kann das sein das der SIGNALduino da eine Schleife für die Befehle eingebaut hat, z.B. Abarbeitung alle Sekunde oder so? Oder kann das am Arduino selbst liegen das dieser so langsam ist?

Hab mir vor einiger Zeit mal einen MapleCUL zusammen gebaut mit einem Maple Mini, müsste mal die FW aktualisieren und den testen, vielleicht könnt ihr mir aber im Vorfeld schon einmal was dazu sagen.

Gruß und mercy

Markus