Probleme bei serieller Kommunikation zw. Raspberrry Pi (FHEM) und Arduino

[csb13]

Hallo zusammen,

ich möchte eine serielle Kommunikation zwischen FHEM (läuft auf einem Raspberrry Pi 4) und einem Arduino implementieren.
Leider habe ich das Problem, dass bei jedem Aufruf der Perl-Funktion aus FHEM der Arduino resettet wird. Das erkenne ich daran, dass eine LED, die mindestens 10 Sekunden leuchten sollte, manchmal gar nicht oder nur kurz leuchtet – je nachdem in welchem Intervall die Funktion aufgerufen wird. Das habe ich mal über AT sowie über DOIF ausprobiert und in beiden Fällen dasselbe Verhalten. Rufe ich den Perl-Code über ein Perlskript auf, funktioniert alles wie gewünscht.

Ist jemand dieses Verhalten bekannt und hat eine Idee, woran das liegen könnte?

Den Source Code habe ich angehängt.

Ich habe auch die Perl-Module Device::SerialPort::Arduino und RPi::Serial ausprobiert, aber überall dasselbe Verhalten festgestellt.

Liebe Grüße,
Claudia

[rudolfkoenig]

Wird die serielle Schnittstelle von einem FHEM-Modul bereits verwendet?
Die standard fhem.cfg scannt nach neuen Geraeten beim Startup per "usb create".
/dev/ttyACM* wird von 8 unterschiedlichen FHEM-Modulen getestet, indem bestimmte Zeichen gesendet werden, und auf eine spezifische Antwort gewartet wird.

Da das hier vermutlich ein Testprojekt ist, will ich gar nicht bemaengeln, dass sleep() "unerwuenscht" ist und serielle Kommunikation in FHEM anders geloest werden muss

[Beta-User]

Neuverbindung setzt MCU zurück? Lieber keyValueProtocol oder ECMD (?)?

[csb13]

Danke für die Rückmeldungen!

Wird die serielle Schnittstelle von einem FHEM-Modul bereits verwendet?
Die standard fhem.cfg scannt nach neuen Geraeten beim Startup per "usb create".
/dev/ttyACM* wird von 8 unterschiedlichen FHEM-Modulen getestet, indem bestimmte Zeichen gesendet werden, und auf eine spezifische Antwort gewartet wird.

Da das hier vermutlich ein Testprojekt ist, will ich gar nicht bemaengeln, dass sleep() "unerwuenscht" ist und serielle Kommunikation in FHEM anders geloest werden muss

Ich habe kein FHEM-Modul diesbezüglich konfiguriert. Ein Abschalten von "usb create" löst das Problem leider nicht.
Meinst du das sleep() im Perl-Code? Das war eine Verzweiflungstat, die ich aus einem Arduino-Forumsbeitrag übernommen habe. Werde ich entfernen, falls der Perlcode für die Lösung überhaupt noch notwenig ist.
Wie soll die serielle Kommunikation denn in FHEM umgesetzt werden? So wie unten erwähnt via ECMD bzw. keyValueProtocol oder hast du noch einen anderen Vorschlag? DevIo vielleicht?

Neuverbindung setzt MCU zurück? Lieber keyValueProtocol oder ECMD (?)?

Ja, aber komischerweise eben nur beim Perl-Funktion via FHEM. keyValueProtocol oder ECMD hatte ich nicht auf dem Schirm. ECMD habe ich mir mal angeschaut. Wenn ich hier das Senden ebenfalls über eine Perl-Funktion mache, scheint die MCU ebenfalls resettet zu werden. Gibt es noch eine andere Möglichkeit, in einem festen Intervall via ECMD Daten zu verschicken? Wenn ich das ECMD-Device aktiviere, kommen hier bereits Daten vom Arduino an, aber in einem falschen Intervall, weshalb sie unvollständig sind. Ankommen sollte Folgendes: 66.07 82.23 81.28 75.15
Zu keyValueProtocol habe ich nichts gefunden, das mir die Nutzung beschreibt... Die Referenz auf https://wiki.fhem.de/wiki/Arduino ist nicht sehr hilfreich.

[Beta-User]

Sorry, hatte erst angenommen, dass du nur Daten empfangen willst.
Das geht jedenfalls mit KeyValueProtocol relativ einfach, der Arduino wird dabei als Jeelink definiert, mit ECMD kenne ich mich selbst nicht aus, da mein Einstieg in die Arduino-Welt MySensors war. Damit  würde ich auch das hier - wie alles bidirektionale - lösen, das erfordert aber etwas mehr Einarbeitung, weil man die Sende- und Empfangsdaten jeweils entsprechend "verpacken" (und ggf. auf der Arduino-Seite auswerten) muss.

[rudolfkoenig]

Wie soll die serielle Kommunikation denn in FHEM umgesetzt werden?

Ich habe vor vielen Jahren ein Beispielmodul geschrieben: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/00_TAHR.pm
Das ist zwar nicht mehr ganz mustergueltig, koennte aber trotzdem als Ausgangspunkt dienen, da es nicht mit dem Ballast eines "richtigen" Moduls ueberfrachtet ist.

[csb13]

Ich habe mir keyValueProtocol und DevIo angeschaut. Dabei schien mir ein FHEM-Modul auf Basis von DevIo die bessere bzw. einfachere Lösung zu sein. Habe es ausprobiert und es hat funktioniert. Vielen Dank für eure Hilfe!