Fhem Neustart configurable Firmata

Begonnen von Chris83, 16 März 2016, 23:09:56

Vorheriges Thema - Nächstes Thema

Chris83

Hallo Leute,
ich habe configurable Firmata auf einem Arduino Nano mit ENC28J60 Shield in Betrieb.
Das funktioniert in Verbindung mit Fhem erst mal sehr gut, aber wenn ich Fhem neu starte baut sich keine neue Kommunikation auf.
Wenn ich den Nano neu starte funktioniert alles wieder.
Hat Jemand eine Idee wo ran das liegen könnte?

Gruß
Chris

jensb

Hallo Chris83,

vielleicht ein bisschen spät, aber hier ist eine Antwort:

Je nachdem, was du Firmata zu tun gibst, kann sich der Arduino aufhängen, wenn er eine Zeit lang nicht verbunden ist, weil er seine Daten nicht los wird, z.B. wenn man analoge Eingänge abfragt. Eine relativ zuverlässige Lösung, wenn auch keine ganz einfache, ist hier beschrieben (die "basic"-Variante reicht). Wenn du das ausprobieren willst, musst du aber zuerst einen anderen Bootloader flashen, z.B. Optiboot, weil der Standard-Bootloader vom Nano nicht mit dem Watchdog zurecht kommt. Wie man das mit Hilfe eines 2. Arduinos macht, steht hier.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Spielmann

Hallo zusammen,
ich habe ebenfalls Probleme, dass sich der Arduino (configurable Firmata auf einem Arduino Mega mit W5100 Shield) zwischen mehrere Stunden und Tage aufhängt. OWcount mit DS2423 liefert zuerst ungültige Werte und nach 6 weiteren Versuchen geht das OWX_ASYNC auf disconnectet - das wars dann. Unterbreche ich kurz die Stromversorgung des Arduino verbindet sich dieser wieder automatisch und alles läuft wieder.
Ich kann jetzt entweder ein watchdog am Raspi einbauen, der mir die Stromversorgung am Arduino kurz unterbricht oder diesen Watchdog am Arduino einbauen- was ich bevorzugen würde.

Muss der Bootloader an einem Arduino Mega ebenfalls getauscht werden?
Die Beschreibung mit der Basic Variante verstehe ich nicht ganz. Ich weiß nicht, wie die Watchdog-Routine in die configurablen Firmata eingebaut wird. Hat jemand ein komplettes Beispiel Script der configurablen Firmata mit wdt ?

Gruß
Spielmann
FHEM mit Raspi (Zentrale)
Raspberrymatic (Heizung)
Siemens LOGO8 (Lichtsteuerung)
Philips HUE Gedöns
Diesel-Tankstelle mit fhem und ESP (eine ewige Baustelle)

jensb

@spielmann,

wäre natürlich am besten, wenn du herausfinden könntest, warum sich dein System aufhängt. Ein Watchdog ist dafür nicht die erste Wahl. Leider kann ich bei 1-Wire nicht konkret helfen. Typische Punkte sind:


  • Verbindungen, ggf. Schirmung
  • Versorgungsspannungsstablilität, ggf. anderes Netzteil, Kondensatoren
  • Ardunino IDE Version, ggf. Update

Die Arduinos sind per se stabil, gleiches gilt für Firmata. Man handelt sich die Problem meist selbst ein, z.B. durch eine fliegende Breadboard-Verkabelung. Bei verrauschten Signalen können sich z.B. die Treiber verlaufen und hängen bleiben.

Wenn du den Watchdog ausprobieren willst, dann nimm das "#include" und die beiden "wdt_xxxx()" Zeilen aus dem Beitrag auf github und kopiere sie an die gleichen Stellen in deinem Sketch, die "#ifdef/#endif" kannst du sogar weglassen. Da ist wirklich nicht mehr dran. Wenn du testen willst, ob du einen anderen Bootloader brauchst, dann schalte das "wdt_reset()" in "loop()" über eine digitalen Eingang vorübergehend aus, bis nach 8 Sekunden der Watchdog auslöst. Wenn der Arduino dann mit wieder eingeschaltetem "wdt_reset()" trotzdem immer wieder bootet, brauchst du einen angepassten Bootloader. Um da wieder raus zu kommen, musst du den Mega spannungsfrei machen und per Reset dafür sorgen, dass er bis zum flashen nicht den Sketch startet, sonst beginnt das Ganze von vorn. Den Optiboot-Bootloader zu installieren hat übrigens noch einen Vorteil: du hast hinterher noch ein paar Byte extra frei zu programmieren.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Spielmann

Danke für die Tipps,
es könnte tatsächlich an der Stromversorgung liegen. Ich versorge mein Ethernet Shield und meine Relais und LED aus den internen 5V (kann ja lt. Datenblatt 1A). Manchmal schaltet das Relais verzögert zur LED, die vor dem Optokoppler auf dem Relais Board sitzt - was eigentlich nicht sein kann und auf einer schlechten Stromversorgung hindeutet. Ich werde den Relais mal ein extra Spannungsregler spendieren und evl. eine Drossel davor einbauen. Zudem ist mir aufgefallen, dass die LEDs am Ethernet-Shield reagieren, sobald ich am Shield herumdrücke. Hier kann es nicht schaden die Stecker durch eine feste Lötverbindung zu ersetzen.
Mit dem Watchdog werde ich mal die neuste IDE installieren und mal am Wochenende testen.

Gruß
Spielmann
FHEM mit Raspi (Zentrale)
Raspberrymatic (Heizung)
Siemens LOGO8 (Lichtsteuerung)
Philips HUE Gedöns
Diesel-Tankstelle mit fhem und ESP (eine ewige Baustelle)

Spielmann

Hallo zusammen,
ist jetzt schon ein Monat her, jedoch habe ich inzwischen ein stabiles System. Folgendes habe ich getan:

Stromversorgung:
Ich hatte einen schlechten Kontakt an der Klinkenbuchse des Arduinos -> Netzteil (7,5V) direkt an den Pins der Klinkenbuchse angelötet.
Meiner Huckepackplatine habe ich einen zusätzlichen Spannungsregler (7805 + 100nF + 10µF ausgangsseitig) spendiert. Der Spannungsregler wird direkt vom Netzteil versorgt (Leitung zwischen dem Pin der Klinkenbuchse und Spannungsregler angelötet). Dieser Spannungsregler versorgt dann auf der Huckepackplatine meine zwei Relais und die Ansteuerung für die Tastaturbeleuchtung (70mA).

Watchdog:
Ich habe dem Watchdog wie Jens beschrieben in die configurable Firmata eingebaut und funktioniert. Ich habe die Relais angesteuert und das Netzwerkkabel abgezogen -> nach ca 10s fallen die Relais ab -> Reset wurde ausgeführt.
Beim originalen Arduino Mega funktioniert der Watchdog ohne den Bootloader zu tauschen. Bei meinem SaintSmart Mega funktionierte der Watchdog nicht. Ich habe allerdings hier nicht weiter gemacht und den SaintSmart Mega mit dem Optiboot Loader getestet.

Ethernet Shield:
Ich hatte Probleme bei einem von meinen zwei Ethernet-Shields (beide mit W5100). Bei einem Shield musste ich mehrmals die Stromversorgung trennen bis sich wieder eine Netzwerkverbindung aufbaute. Der Grund war, dass bei diesem Shield der Reset Baustein schlichtweg nicht bestückt wurde (absichtlich?). Siehe Bilder.

Netztraffic vermindert / verteilt:
Ich hatte auch das subjektive Gefühl, dass bei mehreren hintereinander abgesetzten 1-Wire Befehlen sich der Arduino aufgehängt hat. Die Abfrageintervalle habe ich minimiert und die Befehle verzögert abgesetzt (mit attr wait im DOIF geht das ganz gut). Wie schon gesagt kann ich diese Maßnahme nicht bestätigen.

Das System läuft jetzt stabil und bei provozierten Netzwerk- und Stromausfällen verbindet sich alles wieder automatisch.

Gruß
Spielmann

FHEM mit Raspi (Zentrale)
Raspberrymatic (Heizung)
Siemens LOGO8 (Lichtsteuerung)
Philips HUE Gedöns
Diesel-Tankstelle mit fhem und ESP (eine ewige Baustelle)

joachimm

Hallo,

ich habe das gleiche Problem. Ist der Lösungsansatz (Watchdog) noch so zu empfehlen? Oder hat sich dahin gehend schon wieder etwas getan?

Mir ist aufgefallen, das die gleiche Konstellation Johnny-Five/ Firmata dieses Problem nicht hat. Da scheint Johnny-five etwas anders zu machen.

Oder ganz anderer Ansatz. Würde eine Verbindung über einen USB-Extender besser funktionieren?
fhem,
RS485, Homematic, Synology, 1-wire

jensb

Zitat von: joachimm am 23 Mai 2019, 07:18:12
ich habe das gleiche Problem ... Oder hat sich dahin gehend schon wieder etwas getan?
Meinst du damit, dass sich dein Arduino nach einem Neustart von FHEM nicht wieder verbindet? Wenn ja, dann nein. Einen Verbindungsabbruch muss der TCP Client erkennen und dann die Verbindung neu aufbauen. Tut er das nicht, kann man von der Server-Seite (FHEM) nichts machen, und ein Arduino, der sich aufgehängt hat, der tut nichts mehr. Welchen Anteil daran das Arduino-Framework hat und welches Firmata ist schwer zu sagen. Habe selbst vor allem Probleme bei den Netzwerkkarten, deren Treibern, deren Verkabelung mit dem Arduino, deren Spannungsversorgung und deren Kühlung als konkrete Ursachen feststellen können - also Aspekte, die überwiegend mit dem eigenen Aufbau zu tun haben.

Was Johnny Five anders macht, kann ich nicht beurteilen. USB-Extender sind auch nicht problematisch und gibt es sie in sehr unterschiedlichen Qualitäten und zu sehr unterschiedlichen Preisen. Ethernet gab es schon vor USB und es ist im Gegensatz zu USB wirklich dazu gedacht, Distanzen von mehr als 1 Meter zu überwinden.

Manchmal gelingt es halt nicht herauszufinden, warum sich ein System aufhängt - oder die ermittelte Ursache abzustellen. Dann kommt z.B. der Watchdog ins Spiel. Dieser Ansatz ist nicht ideal, kann aber helfen, vor allem wenn der Watchdog nicht alle paar Minuten eingreifen muss.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

joachimm

Danke für die Info. Das mit dem Watchdog funktioniert. Mit einer ordentlichen Stromversorgung steht die Verbindung jetzt schon mal 12h ohne Verbindungsabbruch. Das ist schon mal ein riesen Fortschritt. Aber da geht sicher noch was. Die Konstellation FirmataEthernet - Fhem ist halt für mein Projekt genau das Richtige.. Es muss einfach stabil laufen....
fhem,
RS485, Homematic, Synology, 1-wire

jensb

Überprüfe mal die Temperatur des W5100 - der wird z.B. bei kontinuierlichem Datendurchsatz gut warm. Wenn das bei dir auch so ist, kannst du ihm einen Kühlkörper oder einen Lüfter (oder beides) spendieren. Der W5100 steigt aus, wenn ihm zu warm wird. Dann kann der Arduino nichts mehr machen, da der Software-Reset über SPI nicht mehr ankommt. Das Problem tritt u.U. eher auf, wenn man einen 5V-Arduino verwendet, denn der W5100 wird im Normalfall mit 3,3 V betrieben und muss dann die Überspannung an den SPI-Eingangspins wieder loswerden.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb