Firmata+Arduino

Rohan · 31 Januar 2013, 14:31:12

Mit Interesse habe ich kürzlich diesen Thread gelesen. Bei mir kam umgehend die Frage auf, ob dies nicht eine Alternative zu den AVR-Net-IOs sein kann.

Da ich als "Normalo" in dem gesperrten Bereich nur lesen kann, eröffne ich mal hier einen Thread.

Auf der Firmata.org-Seite habe ich dann versucht, Informationen darüber zu erhalten, wie es denn mit dem "Net" steht. Leider habe ich nichts zum Thema Netzwerkanbindung, also Ethernet, gefunden. Alles deutet darauf hin, dass die Kommunikation mit FHEM "nur" über USB erfolgen kann.

Ich hätte diese Frage auch per PN an den Modulersteller klären können, aber evtl. interessiert es ja den ein oder anderen hier auch.

Ergo ;) : Wie steht es mit einer Netzwerkkommunikation zwischen Arduino/Firmata und FHEM? Wenn z.Zt. nicht ... ist da was in der Planung?

Gruß
Thomas

ntruchsess · 31 Januar 2013, 16:07:33

Julian Gautier hat Ethernet-unterstützung für Firmata implementiert.
https://github.com/jgautier/arduino-1/tree/ethernetclient/examples/StandardFirmataEthernet
Damit sollte ohne weitere Änderungen alles gehen, was Firmata 2.3 unterstützt (digital/analog i/o, servos und i2c). Da meine FRM-module auf IODev aufsetzen sollten sie ohne Änderungen auch mit TCP-Verbindungen zusammenarbeiten. Verbindungsabbruch und wiederaufbau ist im Prinzip auch schon drin (aber mangels Ethernet-arduino nur mit USB getestet).

Wenn Du zusätzlich 1-Wire am Arduino brauchst, müsstest Du die Changes aus o.g. Branch mit meinem OneWireFirmata-branch mergen:
https://github.com/ntruchsess/arduino/tree/master/examples/OneWireSchedulerFirmata

Das sollte nicht allzu schwer sein, da die serielle Kommunikation und Ethernet beide mit cpp-Streams verwirklicht sind muss im Prinzip nur die Initialisierung der Firmata ausgetauscht werden, der eigentliche funktionelle code bleibt dabei unverändert. Wenn Interesse besteht (und mir jemand die Hardware zum testen leiht oder sponsort) könnte ich das natürlich auch machen. Selber habe ich derzeit keinen Bedarf sowas über Ethernet anzuschließen, mein FHEM-server steht nah genug zu allem, was ich mit einem über USB angebundenen Arduino messe.

Gruß,

Norbert

kaizo · 01 Februar 2013, 22:33:10

Hallo,

ist richtig, genau das interessiert mich auch. Arduino über Ethernet an Fhem. Habe bisher über "Umwege" den Arduino angesprochen, nun wird ein neuer Weg aufgezeigt.

Leider kann auch ich in diesem Forum/Thread nur bedingt schreiben, daher schließe ich mich dem Ersteller einfach mal an. Bitte weitere Info und weitere Entwicklung!!

MfG
Kai

Rohan · 01 Februar 2013, 22:41:25

Hallo Kai,

das Arduino mit den Standard-Arduino-Libs als HTTP-Server / -Client zu betreiben würde ich nicht als Umweg bezeichnen. Viel anders macht es nach dem Überfliegen des Codes die "StandardFirmataEthernet" auch nicht. Falls da jetzt kein "Alleinstellungsmerkmal" kommt, kann ich auch mit den bisherigen Möglichkeiten klar kommen. Ich messe an einem Arduino 5 Stck. DS18B20 und an anderen emontx-Shields über FHEM. Das funktioniert zu meiner Zufriedenheit.

Gruß
Thomas

ntruchsess · 02 Februar 2013, 10:59:56

Firmata verfolgt den Ansatz mit einer Standardfirmware die Ein/Ausgabemöglichkeiten des Arduino remote (z.B. auf einem über USB angeschlossenen Rechner) verfügbar zu machen ohne das der Nutzer hierfür Arduino-code schreiben muss. Rechnerseitig ist alles in einer Bibliotek verpackt, die die komplette Kommunikation wegkapselt. Man kann also z.B. als Perl-programmieren einfach einen Arduino mit der (in der Arduino-IDE mitgelieferten) Standardfirmata flashen und unmittelbar damit beginnen aus Perl heraus auf die Pins des Arduinos zuzugreifen.

Das geht natürlich auch uneingeschränkt mit eigenem Arduino-code. Den muss man halt erst mal schreiben. Nicht jeder kann (und will) das.

Die FHEM-anbindung an Firmata richtet sich primär an Nutzer, die sich nicht mit den Bits und Bytes der Implementierung befassen wollen. Also etwas so wie bei einem CUL, wo der Nutzer auch nur die (nicht selbstgeschriebene) Firmware draufflasht und schon kann er das Teil nutzen.

Wenn man den Arduino über Ethernet nutzen will ist das halt im Moment noch nicht so weit, da noch nicht in den Firmata-Standart aufgenommen.

Ich werde mal die EthernetFirmata mit meiner OneWireFirmata mergen, ich muss mir nur zum Testen noch einen EthernetArduino bestellen. Falls Interesse besteht kann das natürlich auch jeder andere testen sobald ich den gemergten code in Github hochgeladen habe.

Gruß,

Norbert

kaizo · 02 Februar 2013, 22:32:13

Hmm,

Firmata ist auf jeden Fall interessant. Ich belasse es zur Zeit mal bei meinem eigenen Code, werde mich aber auch mal in Firmata einlesen und testen.

Ist ja dann sehr ausbaufähig, vor allem wenn man sich mal die Funktionen und Möglichkeiten des Arduino ansieht.

Bei mir wird in absehbarer Zeit der Arduino eigene Daten sammeln und verarbeiten, diese werden dann von Fhem zyklisch abgefragt.

Gruß
Kai

ntruchsess · 03 Februar 2013, 00:20:47

Einen ganz wesentlichen Unterschied zwischen Firmata und einer Abfrage über Http habe ich noch gar nicht erwähnt:
Firmata pollt die Pins Arduino-seitig (setzbar über das Attribut 'sampling-interval' in 10_FRM.pm). Änderungen an als Eingang (sowohl digital als auch analog) konfigurierten Pins werden selbsttätig an den Rechner gesendet. Solange FHEM in der main-loop die Devices per select überwacht, kommen diese Änderungen auch unmittelbar in den konfigurierten FRM_IN/FRM_AD Geräten an und können dort Events auslösen.
Bei einer Abfrage der Messwerte über Http muss man FHEM-seitig zyklisches Pollen implementieren (oder mit dem Arduino FHEM per Http oder den FHEM-telnet-zugang updaten). In ersterm Fall skaliert das wegen des Http-overheads lange nicht so gut (Firmata kann mit einem minimalem Sampling-interval von 19ms Werte reporten), im zweiten Fall skaliert es wg. des Push-prinzips zwar schon besser, dafür muss man Arduino-seitig deutlich mehr implementieren.

von FRM_IN und FRM_AD kann man sich jetzt auch ganz bequem per alarm-reading (zusamen mit 'event-on-change-reading') benachrichtigen lassen, wenn vorher gesetzte Grenzwerte über- bzw. unterschritten werden (Link). Dadurch, dass diese Alarme per Push vom Arduino ausgelöst werden, kann FHEM darauf ziemlich unmittelbar reagieren (Reaktionszeiten ab ca. 20ms sind möglich, wenn der Rechner den perl-code schnell genug ausführt).

Das gilt nicht nur für die StandartFirmata über USB, sondern auch für die EthernetFirmata. Ist ja das gleiche Protokoll und die TCP-Verbindung bleibt bei der EthernetFirmata einfach offen.

Gruß,

Norbert

est · 08 Februar 2013, 22:35:11

Eine FHEM-Modul für Firmata über Ethernet wäre genau das was ich brauche.

Ein Arduino Mega + Wiznet-Shield stehen zum testen bereit. Der Sketch von https://github.com/jgautier/arduino-1.git ließ sich ohne Probleme auf das Board aufspielen.

Mit FHEM habe ich noch nicht viel Erfahrung, aber für meine 2 Homematic-Thermostate funktioniert die Darstellung der Grafiken. Die Installation ist also Einsatzbereit (Auf einer VM mit Ubuntu).

Viele Grüße

Eddy

ntruchsess · 11 Februar 2013, 20:32:06

Hallo Eddy,

mein FRM modul sollte so wie es ist auch mit der StandardFirmataEthernet (https://github.com/jgautier/arduino-1.git) zusammenarbeiten. Ich konnte es mangels EthernetShield selber leider noch nicht testen. Du musst nur in der define-Zeite anstelle der usb-schnittstelle die ip-addresse und den Port angeben:

define Firmata FRM 192.168.0.190:3030

(wenn Du eine andere ip-addresse oder Port benutzen willst, musst Du das im Sourcecode der StandardFirmataEthernet ändern, das findet sich ab Zeile 56:
byte mac[] = {0x90,0xA2,0xDA,0x0D,0x07,0x02};
byte ip[] = {192,168,0,190};
int port = 3030;)

Funktionieren sollten: Digital-i/o, analog-i/o, i2c und Servo. OneWire muss ich erst noch reinmergen, mal sehen ob ich die Tage dazukomme (bin die Woche im Skiurlaub, da sitze ich nicht ständig am Rechner, außerdem geht Internet hier grade nur über GSM...)

Viel Erfolg beim Testen!

- Norbert

est · 11 Februar 2013, 22:16:05

Ich mußte gerade feststellen das update und auch update fhem sich nicht für deine Dateien interessiert. Weder die readme noch der Ordner Devices ist bei mir angekommen.

Mach ich da etwas falsch oder ist das so normal?

Vielen Dank

PS.: Wenn es nicht Dein dringenster Wunsch war im Urlaub OneWire zu mergen, dann mach erstmal in Ruhe Urlaub. Zumindest bei mir kommt es auf ein oder zwei Wochen nicht drauf an.

est · 12 Februar 2013, 21:31:57

Ich habe den lib Ordner jetzt manuell kopiert.

Dann habe ich die folgende Zeile in meine .cfg eingefügt

Code Auswählen

define FIRMATA FRM 192.168.54.190:3030
Das gab dann folgende Fehler.

Code Auswählen

2013.02.12 07:23:05 1: reload: Error:Modul 10_FRM deactivated:
 Can't locate Device/Firmata/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_FRM.pm line 6, <> line 20.
BEGIN failed--compilation aborted at ./FHEM/10_FRM.pm line 6, <> line 20.

2013.02.12 07:23:05 0: Can't locate Device/Firmata/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_FRM.pm line 6, <> line 20.
BEGIN failed--compilation aborted at ./FHEM/10_FRM.pm line 6, <> line 20.

Das konnte ich (vermutlich total unfachmmenschlich) mit nur 1 Zeile am Anfang von 10_FRM.pm "ändern"

Code Auswählen

use lib ("./FHEM/lib");
Der Fehler kommt jetzt nicht mehr. Dann habe ich mich wieder meiner .cfg gewidmet und da noch

Code Auswählen

attr FIRMATA loglevel 1

define Firmata_OUT_13 FRM_OUT 13
attr Firmata_OUT_13 room Keller

ergänzt.
Jetzt mit größten Erwartungen auf on gekickt - aber - das antwortet leider nur mit:

Code Auswählen

Firmata_OUT_13, FIRMATA is not connected
im logfile hinterläßt die Aktion leider keine Spuren - egal ob loglevel 1 oder 6.

Achja, ein rereadcfg hinterläßt jetzt sowas im logfile:

Code Auswählen


2013.02.12 20:53:39 1: Firmata_OUT_13 is against deletion (2), continuing with rereadcfg anyway

Kann ich den Arduino oder FRM irgendwie einzeln testen (vielleicht gegen Putty oder sowas)?

Viele Grüße

Eddy

ntruchsess · 13 Februar 2013, 11:05:29

Erst mal danke fürs testen!
Und sorry - ich hätte das mal zum Testen selber frisch aus dem tar-file + update installieren sollen, mein fhem läuft hier auf dem svn-Verzeichniss. Der Inhalt des lib-ordners kommt beim fhem-seitigen update wirklich nicht mit (wenn die Datei nicht *.pm heißt und direkt in lib liegt). Muss wohl erst in die filelist von contrig/fhemupdate.pl aufgenommen werden. So wie das aussieht berücksichtigt es keine Unterverzeichnisse von 'lib' beim Hochladen der Änderungen im svn.

Den @INC-pfad erweitere ich im 10_FRM jetzt dynamisch (Deine 'use lib ./FHEM/lib'-direktive funktioniert nur, wenn der modpath nicht irgendwoanders hin gesetzt ist).

zum Testen kannst Du das globale Attribute 'verbose' mal auf 5 setzen, damit Du die Ausgabe von IODev.pm mitkriegst. (Wobei ich vermute, dass es den Arduino auf dem Netzwerk einfach nicht erreicht).
Das kannst Du von dem Rechner auf dem das fhem gestartet wird z.B. mit Telnet testen:

telnet 192.168.54.190 3030

man kann das Firmata-protokoll so zwar nicht bedienen (das ist ein binäres protokoll), aber wenn telnet auf dem port Verbindet, dann hat der EthernetClient auf dem Arduino auf die Verbindungsanfrage reagiert.

Falls telnet nicht verbindet: ist 192.168.54.190 überhaupt im gleichen Subnetz wie der fhem-server? Falls nicht, musst Du die ip-addresse im StandardFirmataEthernet.ino eben ändern. Benutzt Du einen Ethernet-Arduino oder ein originales Ethernet-shield? Die Ethernet-library unterstützt nämlich keine anderen Ethernet-chips.

Gruß,

Norbert

est · 14 Februar 2013, 17:56:57

Hi,

ich habe jetzt Deine aktuelle Version drauf.

attr global verbose 5 habe ich probiert. Homematic wird davon so gesprächg, das man mit dem Log kaum noch was anfangen kann. Von FRM finde ich relativ wenig:

Code Auswählen


CMD: >define FRM FRM 192.168.54.109:3030<
Loading ./FHEM/10_FRM.pm
Opening FRM device 192.168.54.109:3030
Can't connect to 192.168.54.109:3030: No route to host

später dann noch

Code Auswählen


CMD: >define FRM_OUT_13 FRM_OUT 13<
Loading ./FHEM/20_FRM_OUT.pm
CMD: >attr FRM_OUT_13 loglevel 5<
CMD: >attr FRM_OUT_13 room Keller<

Auf telnet reagiert der Arduino nicht. Auch nicht wenn ich die IP verwende, die ich in der Fritz-Box zu der beim Arduino eingetragenen MAC finde. Mein Netzwerk hat übrigens wirklich die 192.168.54.
Zur Hardware: Ich habe einen Arduino Mega 2560 + Ethernet-Shield mit Wiznet W5100 Controller (allerdings beides direkt aus China). Bis vor ein paar Tagen habe ich darauf an einem NTP-Sketch gebastelt der die gleiche Ethernetlib verwendet. Von daher sollte das also funktionieren.

Dann habe ich mir mal den Code angeschaut. Bei Perl konnte ich leider nur mit den Schultern zucken, den Kopf kratzen und feststellen das das Interessant aussieht. Den Arduino-Code kann ich recht gut verstehen.

Im Grunde macht der Sketch ja folgendes:
1. Firmata-Callbacks an eigene Funktionen zuweisen
2. Das Netzwerk mit einer IP-Adresse vom DHCP initialisieren
3. Eine TCP-Verbindung zu IP:Port aufbauen
4. Den daraus resultierenden Stream an Firmata übergeben
5. Solange die Verbindung steht, "Firmata machen (Ports auslesen, setzen etc)"
Sonst ab 2. neu beginnen.
Jetzt wissen wir schon mal warum telnet nicht funktionieren konnte und warum das Arduino nicht die erwartete IP hat.
FHEM ist der Server, zu dem Arduino als Client eine Verbindung aufbaut.

Beim FRM soll ich aber auch eine IP (die des Arduino) angeben. Das widerum sieht so aus als wäre FRM der Client der sich zu einem wartenden Aduino verbindet.
Was passiert wenn die Verbindung mal unterbrochen wird (oder beim Start von FHEM noch nicht da ist)?

Kannst Du bitte mal beschreiben wer von der Archtektur her Server und wer Client sein soll?

Ich installier mir in der Zwischenzeit extra für FRM einen FHEM-Test-Server. Wenn das Homematiczeug ständig dazwischenplapert sind mir die Log's sonst zu groß.

Eddy

ntruchsess · 14 Februar 2013, 22:53:54

ja, da hast Du natürlich recht, der StandardEthernetFirmata-sketch ist tatsächlich als Client implementiert. FRM aber leider auch (das liegt daran, das ich zu USB über die DevIO.pm-library verbinde und die die EthernetClient-funktionalität quasi 'umsonst' mitbringt).
Ich muss mir mal ansehen, wie schwer es ist in fhem für ein Device einen Serverport zu öffnen, das würde mir architektonisch fast besser gefallen. Wobei der Arduino dann noch sowas wie eine eindeutige ID mitbringen müsste, oder wenigstens eine feste IP-addresse bräuchte, sonst gäbe es Probleme, wenn man mehrere Arduinos mit EthernetFirmata im Netz hätte. Falls das FHEM-seitig zu kompliziert wird, schreibe ich den Sketch eben auf Server um, das ist im Prinzip ja nicht so schwer.

Wegen des Logings: Wenn DevIO keine Verbindung zum genannten Device aufbauen kann ('no route to host' in Deinem Log), dann gibt's ab da auch nicht mehr viel sinnvolles zu loggen. Falls die Verbindung zwischendrin abbricht, dann ist das (zumindestens beim über USB angeschlossenen Arduino) so implementiert, dass es sich bei Wiederverfügbarkeit des Arduinos wieder verbindet. Für Ethernet muss ich das aber noch mal genau unter die Lupe nehmen, da weiß ich nicht sicher, wie es sich verhält.
Die Änderungen mit denen man den Loglevel FRM-seitig hochstellen kann habe ich schon hier auf der Platte - muss ich aber noch ein bischen durchtesten bevor ich das ins SVN hochlade.

Gruß,

Norbert

est · 14 Februar 2013, 23:51:32

Ich habe gerade noch Deine Antwort gelesen.

Den Server auf FHEM-Seite zu setzen würde mir auch besser gefallen. Das mit der ID gefällt mir nicht wirklich. Was spricht gegen mehrere "Server", also unterschiedliche Ports je Arduino?

Wenn Arduino der Server wird, wäre die Frage wie FRM auf Verbindungsabbrüche reagier[t,en könnte] wichtig. Es ist ja auch nicht unbedingt sicher, das Arduino vor FHEM verfügbar ist.

Gruß

Eddy