Firmata over Ethernet: Einbindung in Arduino

[ntruchsess]

Wenn Du Dich am Entwickeln beteiligen willst: Hier kannst Du Proposals für Protokollerweiterungen (als Pull-request) einsteuern. Und hier dann den dazu passenden Implementierungsvorschlag.
Ein Keep-alive feature sollte idealerweise mit dieser Anforderung nach einem Verbindungsneuaufbau festellen zu können, ob der Arduino neu konfiguriert werden muss zusammenspielen.

Gruß,

Norbert

[matthias soll]

set FIRMATA reset 
Danke Norbert.!!
Das sollte mein Problem erstmal lösen erreichbar ist der arduino eigentlich , habe nur das Problem dass er nach ein paar tagen ohne reboot wild irgendwelche Ausgänge schaltet. Hatte das Problem schon jemand?

[T.ihmann]

Wenn Du Dich am Entwickeln beteiligen willst: Hier kannst Du Proposals für Protokollerweiterungen (als Pull-request) einsteuern.

Oh je, da habe ich ja was angestoßen. Ich habe mir mal die Links angeschaut und hätte noch ein paar Fragen: Das Firmata Protokoll ist so angelegt, daß immer der Host (Raspi o.ä.) die Kommunikation beginnt und der Arduino darauf reagiert ?

Config message

Code Auswählen Erweitern


0  START_SYSEX      (0xF0)
1  Keep-alive Command  (0x81)
2  config command   (0x41)
3  keep-alive on/off   (0x00|0x01) 0x00 = off, 0x01 = on
4 intervall              (0-127)  interval in s
5  END_SYSEX (0xF7)


Keep-alive message (vom Arduino zum Host)

Code Auswählen Erweitern


0  START_SYSEX      (0xF0)
1  Keep-alive Command  (0x81)
2  keep-alive request   (0x11)
3  END_SYSEX (0xF7)


Keep-alive message (vom Host zum Arduino)

Code Auswählen Erweitern


0  START_SYSEX      (0xF0)
1  Keep-alive Command  (0x81)
2  keep-alive confirm   (0x21)
3  END_SYSEX (0xF7)


Wäre dies so möglich und sinnvoll ?

[ntruchsess]

Das Basisprotokoll an sich legt nicht fest, ob eine bestimmte Seite die Kommunikation anstößt. Es ist in dem Sinne kein Request/Response-protokoll. Digital- und Analog-input arbeiten ja auch nicht so - die werden einmal durch Nachrichten vom Host aus konfiguriert und ab dann sendet der Arduino selbstständig. Es ist auch nicht auf Protokollebene festgelegt, dass eine Antwort unmittelbar auf eine Response hin gesendet werden muss - der Host muss durchaus damit rechnen nach Absenden einer Message noch andere Messagetypen zu empfangen, bevor die erwartete Antwort zurückkommt.

An sich ist es egal, welche Seite das Keep-alive-protokol steuert. Macht es der Host, dann muss der Arduino beim Ausbleiben von Messages davon ausgehen, dass die Verbindung abgebrochen ist. Sendet der Arduino die Requests, dann beim Ausbleiben der Antworten. Und wie gesagt, dass muss überhaupt nicht Request/Response sein, man kann auch festlegen, dass beide Seiten unabhängig voneinander regelmäßig eine Keep-alive-nachricht schicken, wenn sonst nichts anderes ansteht. Ansonsten würde das Keep-alive-protokoll Anwendungsszenarien bei denen es auf Bandbreite ankommt und sowieso dauernd messages über die Leitung gehen behindern.
Ich würde es für sinnvoll halten, dass man die Semantik über das reine Erkennen eines Verbindungsabbruchts hinaus noch etwas ausbaut: Das Problem bei einem Verbindungsabbruch ist ja, dass man nicht wissen kann, ob die Gegenseite wärend des Abbruchs die Konfiguration wg. Neustart verloren hat. Aus diesem Grund wird aktuell immer alles zurückgesetzt und neu konfiguriert. Das führt halt leider dazu, dass bei einem Verbindungsneuaufbau z.B. ein Digital-eingang systematisch erst mal einen Schaltvorgang signalisiert, wenn der Pullup beim Reset erst ab und später wieder dazu schaltet wird. Ein unnötiges Neukonfigurieren wäre also beim Verbindungsneuaufbau zu vermeiden. Dazu müsste man im Keep-alive protokoll z.B. eine SessionId setzen und übermitteln können, an der ein bestimmter Konfigurationsstand (wiedererkannt) werden kann.

Gruß,

Norbert

[T.ihmann]

Und wie gesagt, dass muss überhaupt nicht Request/Response sein, man kann auch festlegen, dass beide Seiten unabhängig voneinander regelmäßig eine Keep-alive-nachricht schicken, wenn sonst nichts anderes ansteht. Ansonsten würde das Keep-alive-protokoll Anwendungsszenarien bei denen es auf Bandbreite ankommt und sowieso dauernd messages über die Leitung gehen behindern.

Aber wie erkennt man dann, ob eine Verbindung abgebrochen ist, wenn das Keep-alive nicht irgendwie mittels Request / Response bestätigt wird ?

[ntruchsess]

man erkennt einen Verbindungsabbruch am Ausbleiben von Nachrichten. Jedesmal, wenn (irgendeine Nachricht) kommt, setzt man einen Timer zurück. Ist der Timer abgelaufen, geht man davon aus, dass die Gegenseite nicht mehr verbunden ist. Jedesmal wenn man eine (irgendeine) Nachricht schickt setz man (einen zweiten) Timer zurück. Wenn dieser zweite Timer abgelaufen ohne dass man eine Nachricht schicken musste (die den Timer ja zurücksetzen würde), schickt man eine Keepalive-message.

Das kann jede Seite nach dem gleichen Muster machen. Ein explizites Request/Response Verfahren ist dafür nicht zwingend nötig.

[matthias soll]

Hallo zusammen, gibt es eigentlich eine Empfehlung wie man firmata an fhem anbindet damit es so stabil läuft wie möglich. Ich überlege ob ich per USB oder mit w5100 Ethernet shield weniger Probleme mit der Erreichbarkeit und Zuverlässigkeit hätte.
Gruß
Matthias

[strauch]

Also ich hab es sowohl per Ethernet als auch per USB bei mir macht USB keine Probleme. Ethernet fällt schon mal aus.

Gesendet von meinem Nexus 4 mit Tapatalk

[matthias soll]

Erstmal danke für die schnelle Antwort. Hast du es per USB an einer fritzbox? Mit standard firmata?
Bzw. Funktioniert das an einer fritzbox überhaupt oder hat die keinen ftdi Treiber.

[strauch]

Das sollte an einer fritzbox gehen aber ich nutze ein macmini mit Debian.

Gesendet von meinem Nexus 4 mit Tapatalk

[Achim]

Hallo,

bei mir läuft Firmata auf einem Ardunio Nano mit ENC28J60 seit einem Jahr stabil. Im Betrieb keine Unterbrechungen oder Abstürze, weder auf der Arduino Seite noch auf der FHEM (RPi) Seite. Ich habe auf der Arduino Seite Digitale Ein/Ausgänge und 1-Wire konfiguriert, feste IP-Adresse etc, alles laut den "Konfigurationsvorschlägen" von Norbert.

Ich habe nur ab und zu das Problem beim Neustart von FHEM. Da funktioniert dann ab und zu die Kommunikation zwischen FHEM und Arduino nicht mehr. Bei "normalen" Update / shutdown restart trat dieses Problem bisher nicht auf. Das kommt meist nach Änderungen in FHEM wenn ich es öfters neu starte. Manchmal hilft dann ein Neustart des Arduino (reset), meist muss aber auch der RPi neu (nicht nur FHEM) gestartet warden (Shutdown RPi, Reset Arduino, Start RPi mit FHEM). Nicht schön, aber der Aufwand dem Problem auf die Spur zu kommen ist mir zu hoch gegenüber einem Neustart des RPi.

Viele Grüße
Achim

[matthias soll]

Danke für die Erfahrungsberichte, ich muss den arduino ca. Alle 4 Tage neu starten weil er sonst nicht ansprechbar ist oder wild irgendwelche Ausgänge schaltet. Arduino mega mit enc28, onewire und ca.60 Ausgängen.

[digital.arts]

Hallo,

das sporadische "Aussetzen" eines Firmata-Nano (ist im Heizungskeller zum 1wire-Temperaturmessen...) mit dem ENC28 habe ich auch;
mein Trick: die Stromversorgung des Nano (Steckernetzteil) über eine billige mechanische Schaltuhr, die einmal am Tag (in der Nacht) für 5 Minuten den Nano "kaltstartet".
Ein zweiter Firmata-Nano mit W5100 funktioniert sauber, ohne Tricks... da muss auch nicht soviel bei den Protokollen gespart werden wg Flashplatzmangel...

VG
Karl

[matthias soll]

Das mit den Protokollen beim w5100 war auch meine idee ich habe mir erstmal ein w5100 shield bestellt um zu testen ob das zuverlässiger läuft. Alternativ könnte ich auch auf usb umrüsten. Erstmal danke für eure Erfahrungen.

[hexenmeister]

Habe Arduino mit Firmata per USB sein mehreren Monaten ohne Neustart. Alles stabil