[gelöst] Hilfe benötigt: Optiboot Bootloader auf nanoCUL installieren

[Nookyx]

Hallo zusammen,

ich habe mir in der Bucht einen fertig zusammengebauten nanoCUL Stick gekauft um damit meine Somfy RTS Rolläden zu steuern.

Vorab: Ich verwende derzeit kein FHEM, hoffe aber dennoch, in diesem Forum Hilfe zu bekommen.
Mein Problem scheint mir unabhängig von der verwendeten Plattform (FHEM, OpenHAB, ioBroker, etc.) zu sein, da es auch in diesem Forum immer wieder beschrieben wird:

Der Stick ist an einen Raspberry Pi 4 (4GB) angeschlossen, darauf läuft OpenHAB2.5 und ein entsprechendes Binding für Somfy. Prinzipiell funktioniert die Steuerung der Rolläden auch.
Wenn ich z.B. alle Rolläden gleichzeitig anfunke oder verschiedene Befehle zu schnell hintereinander, blinkt eine LED am Funkmodul wie wild und es ist keine Steuerung mehr möglich. Das Problem wird auch hier im Forum in verschiedenen Threads beschrieben (Stichworte: Zusammenspiel Bootloader und Watchdog, "opened" Problematik, z.B. hier: https://forum.fhem.de/index.php?topic=86734.0)
Es hilft dann nur noch aus- und wieder einstecken des Sticks.

Mir scheint die einzig sinnvolle Lösung dafür ein alternativer Bootloader (Optiboot) zu sein. Leider finde ich keine leicht verständliche Anleitung, wie man einen alternativen Bootloader wie Optiboot installiert.
Kann mir jemand Schritt-für-Schritt erläutern, wie das Vorgehen dazu ist?
Üblicherweise bin ich durchaus der englischen Sprache mächtig, aber auch mit der Dokumentation auf https://github.com/Optiboot/optiboot weiß ich nicht so recht etwas anzufangen.
Was benötige ich, um einen anderen Bootloader zu installieren und wie werden die einzelnen Schritte durchgeführt? Benötige ich dafür zusätzliche "Hardware" oder kann ich das irgendwie direkt von meinem Windows PC oder meinem Raspberry Pi 4 (Raspbian Buster OS) aus bewerkstelligen? Muss ich danach noch weitere Dinge wieder neu installieren, wenn ja, was und wie?

Bei meinem Stick handelt es sich um
nanoCUL MINI-USB Nano V3.0 ATMEGA328P FT232RL FTDI
C1101 433 MHz Funkmodul
als Firmware installiert ist die culfw 1.67 (V1.67 nanoCUL433)

Wenn weitere Details benötigt werden, liefere ich diese gerne nach...

Vielen Dank vorab und viele Grüße

[Beta-User]

Na dann mal willkommen im Kreis der FHEM-Freunde . Falls du es dir anders überlegst, und die Signalduino-Firmware flashst (wie alle in dem bezogenen Thread, afai can see), kannst du auch Fernbedienungssignale auslesen (geht aber afaik nur in FHEM...).

Das liest sich für mich immer noch eher wie das "Test-PIN-"Problem, was bedeutet, dass du dem Verkäufer eines auf die Nase geben solltest (v.a. dann, wenn es mein besonderer Freund "Smart-Home-Komponente" ist...). Mehr zum Test-PIN findest du unter Arduino in unserem Wiki.

Ansonsten ist es so, dass Bootloader und firmware zusammenpassen müssen, du also ggf. die firmware selbst passend kompilieren mußt. Bootloader bekommt man nur mit zusätzlicher Hardware drauf (kann auch ein anderer Nano sein, Sketch wird mit Arduino ausgeliefert, sollte serieller Programmer oder so heißen).

[Nookyx]

Danke für die Begrüßung 

Tatsächlich ist der Verkäufer dein besonderer Freund Bekräftigt dich das in der "Test-PIN" These?
Für mich klangen meine Symptome nach einschlägiger Recherche im Internet (auch englischer Seiten) eher nach dem Bootloader/Watchdog Problem. Aber ich weiß auch nicht, ob und wie ich das zweifelsfrei feststellen könnte und bin in diesem Thema eher unbewandert.

Den Verkäufer habe ich auch schon kontaktiert. Er meinte es sei sicher ein Hardwarefehler des Funkmoduls und hat mir noch einen zweiten zum Test zugesandt.
Wie ich schon erwartet habe, hat das aber keine Besserung gebracht. Gleiches Problem, gleiches Symptom (schnell blinkende LED, wenn ich zu viele Signale in zu kurzer Zeit sende - wenn ich alles in 1-2 Sekunden Abstand mache, funktioniert es ohne größere Probleme).

Was wäre deine Empfehlung? Da die Module schon alle zusammengebaut sind, wird das mit dem zusammenlöten für mich schwierig (zumal ich mir ohnehin erst einen Lötkolben besorgen müsste)
Wie kann ich denn feststellen, "ob der TEST-Pin (26) auf Ground liegt"? Wenn ich das nachweisen könnte, könnte ich vielleicht einen Stick ohne dieses Problem von ihm einfordern. Oder ich suche mir einen anderen Händler..
Entschuldige bitte die Fragen - ich bewege mich sonst eher auf Serverterminals und in der Programmierung..

/edit: In einem anderen Thread zum Test-PIN Problem wurde diese Seite verlinkt, auf der das mit dem Löten auch erklärt wird: http://systemwork.in/index.php/technical-articles/33-how-to-fix-moody-arduino-nano
Dort ist allerdings davon die Rede, dass ein typisches Symptom ist, dass der Stick beim einstecken nicht immer richtig erkannt wird. Dieses Symptom ist bei mir bisher nie aufgetreten.

[Beta-User]

Moin.

Na ja, nach meiner Erfahrung mit "peterchen888" aka "smarty" hat er es nicht so mit Spezifikationen und brauchte erst einen deutlichen "Schubs", bis er eingesehen hat, dass es Sinn macht, die FTDI darauf zu prüfen, ob es fakes sind (an den Sinn von Spannungsteilern glaubt er afaik bis heute nicht, sinngemäß: "geht ja erfahrungsgemäß auch so...").

Daher vermute ich, dass er das Test-PIN-Thema vermutlich auch nicht auf dem Schirm hat, warum auch immer.
Was Erfahrungen angeht: Meine ist die, dass
- bei den paar echten FTDI-Nanos, die ich selbst in der Hand hatte, 100% der Platinen den Fehler hatten und dieser bei etwa 1/3 davon bereits vom Lieferanten gefixt war. Man kann das ja durch eine einfache Widerstandsmessung nachprüfen bzw. den Lötpunkt sehen, wenn er nachträchlich gemacht wurde;
- alle user hier, die den Fix nach entsprechendem Hinweis bei diversen Fällen angewendet hatten, in denen der Verdacht nahelag, danach praktisch alle berichteten, dass das Problem "gone" wäre. Kann natürlich auch sein, dass man das Problem in Software lösen (oder verkleinern) kann, aber alle Inidzien deuten darauf hin, dass die fehlende GND-Verbindung die eigentliche Ursache ist...

Also würde ich mal kritisch diese Stelle beäugen, wenn da nichts ist, unseren "Freund" gerne auf diesen Sachverhalt aufmerksam machen, denn: Wenn er es vor der Auslieferung fixt, müssen wir hier (und anderswo) nicht mehr support für ihn machen...

Ansonsten kannst du ja mal sehen, ob du hier über das Forum einen MapleCUL organisiert bekommst. Der wird von den Bastlern hier, die sowas verkaufen, "ordentlich" gemacht, gut supportet und hat dann - je nach Modell - auch die Option für noch ein paar Transceiver . Kann nur nicht sagen, ob dir das was hilft bei OpenHAB... (Mußt halt notfalls FHEM austesten und ggf. die Daten per MQTT auf deine gewohnte Umgebung schieben, falls du da bleiben willst...).

[Nookyx]

Danke für die Rückmeldung. Man sieht das leider im zusammengebauten Zustand nicht zweifelsfrei, aber es sieht eher nicht danach aus, als wären die beiden PINs zusammengelötet. Ich habe dem Verkäufer nochmal geschrieben und auf das Thema hingewiesen. Mal schauen, was rauskommt.

Wäre ein umflashen der Firmware auf Signalduino auch noch eine Alternative? Oder ist der Grund dafür, dass die Signalduinos keine Probleme machen nicht deren Firmware, sondern schlicht, dass das "PIN Problem" dort nicht besteht, also die Platine "richtig" gebaut wurde?

Kann ein Signalduino auch wie ein nanoCUL verwendet werden, oder bräuchte ich da wiederum andere Bindings in OpenHAB, damit der in meiner Konstellation funktionieren würde?

[Beta-User]

Signalduino ist "anders", der versucht nicht in gleichem Maß, die Daten zu dekodieren, sondern sendet "rohere" Daten raus, der Rest macht dann FHEM bzw. die Software hinter dem SDuino; zu OH kann ich in dem Zusammenhang nichts sagen, aber mMn. ist das sw-Decoding sehr eng mit FHEM verbandelt.

Die Hardware ist aber identisch! Es ist nur möglich, dass die interne Verarbeitung auf der MCU eben bei der CUL-firmware länger dauert und daher der watchdog zuschlägt.

Was du ggf. noch machen kannst: Verhau "smarty" auch gleich noch, weil er nicht die a-culfw mit seinen 433MHz-Dingern per default flasht/bewirbt... Die unterstützt nämlich sehr viel mehr 433-er Protokolle . (Kann aber wieder sein, dass OH die (auch & noch) nicht kennt...)

[smarty_111]

Wer die acul fw benötigt,  bekommt sie natürlich gern.

Ich schlechter Mensch

[Beta-User]

Du nicht schlechter Mensch, nur beratungsresistent...

Wer die acul fw benötigt,  bekommt sie natürlich gern.

Das ist schlicht der falsche Ansatz: Wer 433MHz "benötigt", sollte per default die a-culfw bekommen, denn die "benötigt" er (bzw. will er eigentlich haben, da die mehr "433" "kann"). Nur weiß er das in der Regel (noch) nicht, wenn er bei dir kauft, weil das machen nur noobs .

[Beta-User]

@smarty_111:

Vielleicht magst du besonders nett sein und dem User hier unter die Arme greifen?

(und evtl. mal deine aktuellen Nano-Bestände durchscannen, was dir die Chinesen da so geliefert haben...?).

Weitere Anmerkung noch: Die meisten (FHEM-) User "wollen" eigentlich die Signalduino-firmware (und wissen das leider meistens noch nicht). Die ist leider etwas schwieriger in der Handhabung unter FHEM, erkennt aber bei weitem die meisten 433-er Protokolle und kann (afaik) auch somfy korrekt empfangen. Falls du also nicht nur einfach schnell zusammengeschusterte - spezifikationswidrige - Hardware unter die Leute werfen willst, wäre also eine entsprechende "Nutzer- bzw. Käuferführung" für alle Beteiligten hilfreich .

[Nookyx]

jetzt sind wir hier ja alle vereint

Habe jetzt noch einen weiteren Stick bekommen, leider bekomme ich auch da noch das Fehlerbild mit schnell blinkender LED, wenn ich zu viele Befehle gleichzeitig (oder zu schnell hintereinander) sende.
Smarty hat mir netterweise die Lötbrücke gemacht (also PINs 25+26 zusammengelötet). Aber leider hilft scheinbar auch das nicht..

Was kann ich jetzt noch tun? Optiboot Bootloader wäre noch eine bisher nicht ausprobierte Variante, kann ich aber auch wieder nicht selbst machen..

P.S: Über mangelnde Unterstützung von Smarty kann ich mich bisher nicht beklagen, reagiert immer schnell auf meine Nachrichten, hat mir jetzt schon 3 Sticks zugesandt um verschiedene Fehlerquellen auszuschließen..
P.P.S: Die 433er Frequenz macht mir bisher mit der culfw keine Probleme mit den Somfy Rolläden, einzeln bzw. nicht zu schnell hintereinander sind die alle wunderbar steuerbar über den Stick, andere Geräte habe ich (bisher) nicht vor darüber zu steuern.

[Beta-User]

Hmm, schade, dass der Hardwarefix alleine nicht ausreicht...

(Es sollte trotzdem bei allen neu ausgelieferten Nanos sichergestellt sein, dass das Test-PIN-Problem nicht besteht! Ich gehe aber davon aus, dass diese Botschaft angekommen ist .)

Den Bootloader zu wechseln (und eine dazu passende eigene firmware-Variante von aculf zu backen) ist nicht sooo schwer, aber du brauchst mind. einen 2. Nano oder andere hardware, um den Bootloader erfolgreich auf den NanoCUL zu beamen. außerdem muß der Schrumpfschlauch weg, man braucht Zugang zu ein paar PINS (und ich weiß grade nicht, ob die nicht teilweise auch für den CC1101 genutzt werden, was auch schlecht wäre, da der keine 5V mag (die aber aus dem flasher/2. Arduino per default kommen... Ob das mit Levelschifter ginge?)).


Ist ein bißchen ein allgemeines Thema:
Optiboot ist bei den originalen Arduinos seit längerem der ausgelieferte Bootloader, mal sehen, wann die Chinesen auch das kopieren...
Na jedenfalls sollte man mAn. eigentlich mittlerweile alles auf Optiboot ausrichten, was bedeuten würde, dass in FHEM tendenziell beide Varianten der firmwares (betr. v.a. auch Signalduino) anzubieten wären, weil "Otto Normaluser" in der Regel kaum den Durchblick hat, was er denn jetzt warum wie an firmware selbst backen muß.
Würde aber einen allg. Konsens zu dem Thema voraussetzen...

Vorschlag an smarty_111 und Nookyx: Testet doch mal aus, ob das Problem mit dem Optiboot wirklich zu lösen wäre. Wenn ja, sollte dann ein neuer Thread gestartet werden. Ziel sollte sein, das zwischen allen von FHEM aus flashbaren Arduino-Projekten abzustimmen, also (afaik) neben culfw+aculfw auch Signalduino, (firmata?) und Arducounter.

[Ralf9]

Der nanocul ist eigentlich neu nicht mehr zu empfehlen, es gibt inzwischen mit dem Maplexxx einen Nachfolger.
Der verwendete Maple Mini ist viel leistungsfähiger und es sind keine Pegelwandler mehr notwendig, er kostet mit ca 3-5 Euro nur wenig mehr wie der nano.
Als Prozessor wird der STM32F103CBT6 mit 72 MHz verwendet (128 Kbytes Flash und  20 Kbytes SRAM)

Für den Selbstbau gibt es den
- MapleCUN (mit LAN)
- MapleCUL
- MapleSduino

Es gibt dafür die a-culw, die sduino Firmware ist gerade in Entwicklung
Die kleinste Variante ist die MapleSduino Hardware
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477

Gruß Ralf

[Nookyx]

Update: Da ich den Bootloader selbst nicht wechseln kann (fehlendes Wissen, fehlende Technik), habe ich mir Hilfe dafür gesucht und bei der Konkurrenz von "smarty" gefunden.
Ist ein netter Kollege der nicht weit entfernt von mir wohnt, sodass ich die 20 Minuten dorthin mit dem Rad gefahren bin und es gleich vor Ort von ihm machen lassen habe, d.h. ich habe nun Optiboot als Bootloader drauf und weiterhin die culfw 1.67 (433 MHz).
Nach seiner Erfahrung hilft bei diesem Problem auch nur der Bootloader. Er hat das Problem selbst schon oft beobachtet und bekommt manchmal aus China die CULs mit schon verlöteten PINs geschickt, die haben seiner Ansicht nach aber ohne Optiboot auch das Problem.

Nun ist mein Problem auch verschwunden, ich kann wild hin- und her steuern, egal in welcher Geschwindigkeit, oder auch mehrere Rolläden gleichzeitig anfunken. Hängt sich nichts mehr auf, die LED blinkt nicht mehr wild, ich muss den Stick nicht mehr aus dem Raspberry rausziehen, um ihn wieder funktionsfähig zu machen.

Kann also künftig jedem mit diesem Problem den Optiboot Bootloader nur ans Herz legen.

P.S: Der Name des Kollegen auf eBay ist ganz ähnlich wie der von smarty, endet nur mit -equipment anstatt -komponente

@Beta-User:
Falls du dazu einen neuen Thread aufmachen willst, um das Thema allgemein zu diskutieren - bitte gerne, nur zu.

[Beta-User]

Thx für den update.

Mal sehen wg. des Extra-Threads. Ist eigentlich nicht mein Thema - ich kann sowohl BL (Arduino und Maple) wechseln wie eigene Firmwares bauen. Das geht eher in die Richtung von @Ralf9.

Der nanocul ist eigentlich neu nicht mehr zu empfehlen, es gibt inzwischen mit dem Maplexxx einen Nachfolger.
Der verwendete Maple Mini ist viel leistungsfähiger und es sind keine Pegelwandler mehr notwendig, er kostet mit ca 3-5 Euro nur wenig mehr wie der nano.
Als Prozessor wird der STM32F103CBT6 mit 72 MHz verwendet (128 Kbytes Flash und  20 Kbytes SRAM)

Für den Selbstbau gibt es den
- MapleCUN (mit LAN)
- MapleCUL
- MapleSduino

Es gibt dafür die a-culw, die sduino Firmware ist gerade in Entwicklung
Die kleinste Variante ist die MapleSduino Hardware
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477

Gruß Ralf

Das ist eine gute Zusammenfassung, allerdings gebe ich zu Bedenken, dass der STM32 für echte "Selberlöter" schon eine etwas größere Hürde ist, und die nanoCUL-Hardware daher m.E. auch weiter ihre Daseinsberechtigung hat. Der Maple ist in der "Multi-Transceiver"-Variante auch schon ein ziemlich komplexes Device, das gerade für Einsteiger bei der Einrichtung in FHEM einige gedankliche Hürden bietet (und auch Signalduino ist gerade wegen der Universalität auch nicht ganz einfach (aber klasse!!!)).
Von daher wäre das mit der fertigen Optiboot-firmware weiter ein Punkt, über den man auch in Zukunft nachdenken sollte; der Aufwand ist ja überschaubar.

Just my2ct.

[RalfRog]

Hallo
In mehreren Forumsfragen wird immer wieder in unterschiedlichen Zusammenhängen von "hängenden nanoCUL" berichtet. Ursache sei oft der alte Bootloader beim ArduinoNano der einen Bootloader-Loop verursacht z.B. nach Watchdog-Reset.

Falls die damals Beteiligten hier nochmal reinlesen wäre meine Frage: Habe ich es richtig verstanden?
Zusammenfassend ==>
Der Optiboot-Bootloader kann wie z.B. hier beschrieben https://forum.fhem.de/index.php/topic,24436.msg1138317.html#msg1138317 "Firmware zu CUL, CUNX und Co. mit Timestamp..." neu geflasht werden und dann die bisherige (auch vorkompilierte) CUL-Firware (z.B. a-culfw) ohne Änderung (ausser Baudrate) geflasht werden.

Wenn man das Problem mit dem Bootloader testen will, könnte man per "set CUL raw B00" schauen ob der CUL danach hängt (state opened in FHEM).