Hauptmenü

Firmata+Arduino

Begonnen von Rohan, 31 Januar 2013, 14:31:12

Vorheriges Thema - Nächstes Thema

ntruchsess

Hi Eddy,

ich habe grade mal auf die Schnelle den Arduino zum 'Server' gemacht:
https://github.com/ntruchsess/arduino/tree/ethernetserver/examples/StandardFirmataEthernetServer

(mangels Hardware nicht getestet, nach der Doku sollte es aber so gehen und compilieren tut's auch...)

Wenn fhem den Server spielt, dann kann man nicht generell ausschließen, dass mal mehrere Arduinos auf dem gleichen Port verbinden (und sei es nur, weil der Anwender die Doku nicht gelesen hat). Das muss FRM dann zuverlässig erkennen können um die reale Welt nicht durcheinanderzubringen. Es könnte ja auch ein Arduino verbunden sein und die Verbindung verlieren, wärend ein zweiter parallel auf die Übernahme 'lauert' oder just in dem Moment aktiv wird.
Ansonsten spricht natürlich nichts gegen einen Port pro Arduino und FRM-Device.

Wenn FRM der Client ist, dann können natürlich auch potentiell mehrere Arduinos mit der gleichen IP-addresse im Netz sein (wenn der Anwender den Sketch einfach unverändert auf mehrere flashed). Das wäre dann fast das gleiche Problem und in FRM selbst praktisch gar nicht zu erkennen. Irgendwie habe ich da noch kein Konzept, wie man damit umgehen sollte. Eventuell bräuchte die Firmata dafür noch eine Erweiterung, mit der beim ersten Verbinden eine eindeutige ID ins EEPROM geschrieben wird oder so was in der Art. Die Mac-addresse mus ja auch auf jedem Gerät eine andere sein...

Naja - wäre lieb, wenn Du erst mal meinen o.g. Sketch testen könntest. Wenn das funktioniert, dann sind wir sowieso schon mal einen großen Schritt weiter ;-)

Gruß,

Norbert

Gruß,
while (!asleep()) {sheep++};

est

So, vor der Arbeit schnell noch getestet. Es redet miteinander aber der FHEM startet nicht mehr.
Im Log steht folgendes:

2013.02.15 07:22:16 5: Cmd: >define FRM_Device FRM 192.168.54.190:3030<
2013.02.15 07:22:16 5: Loading ./FHEM/10_FRM.pm
2013.02.15 07:22:16 3: Opening FRM_Device device 192.168.54.190:3030
2013.02.15 07:22:16 3: FRM_Device device opened
2013.02.15 07:22:16 5: >ff
2013.02.15 07:22:16 5: SW: ÿ
2013.02.15 07:22:16 5: >f0,79,f7
2013.02.15 07:22:16 5: SW: ðy÷
2013.02.15 07:22:26 5: >ff
2013.02.15 07:22:26 5: SW: ÿ
2013.02.15 07:22:26 5: >f0,79,f7
2013.02.15 07:22:26 5: SW: ðy÷
2013.02.15 07:22:36 5: >ff
2013.02.15 07:22:36 5: SW: ÿ
2013.02.15 07:22:36 5: >f0,79,f7
2013.02.15 07:22:36 5: SW: ðy÷
2013.02.15 07:22:46 5: >ff
2013.02.15 07:22:46 5: SW: ÿ
2013.02.15 07:22:46 5: >f0,79,f7
2013.02.15 07:22:46 5: SW: ðy÷
2013.02.15 07:22:56 5: >ff
2013.02.15 07:22:56 5: SW: ÿ
2013.02.15 07:22:56 5: >f0,79,f7
2013.02.15 07:22:56 5: SW: ðy÷
2013.02.15 07:23:06 5: >ff
2013.02.15 07:23:06 5: SW: ÿ
2013.02.15 07:23:06 5: >f0,79,f7


Aber jetzt muß ich los.
Bis heute Abend.
FHEM unter Ubuntu Server aus ESXi 5
1 HM-LAN, 3 HM-CC-RT-DN, 3 HM-CC-TC, 4 HM-CC-VD
1 Arduino verbindet die Vitodens + oneWire + sonstigen Heizungskram über Ethernet mit dem telnet-Port von FHEM

erwin

Hi all,

wär das nicht die Lösung, 2 Telnet Clients miteinander zu verbinden? (zumindest zum Testen).

http://forum.fhem.de/index.php?t=msg&goto=56972&rid=115&srch=telnet+client#msg_56972

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

ntruchsess

Hallo Eddy,

im Log sieht man das FRM erfolgreich zum Socket des Arduino connected hat und versucht diesen zu initialisieren. (die Logzeilen, die mit '>' anfangen sind ausgehende Firmata-messages). Antwort vom Arduino bleibt leider aus (das wären sonst Zeilen mit '<' am Anfang.

Keine Ahnung warum der Sketch nicht antwortet, im Prinzip ist das so wie z.B. im Webserver-example implementiert (der prinzipielle Unterschied ist, dass der Firmata-sketch die EthernetClient-Verbindung über die loop()-methode hinaus offen hält, solange EthernetClient.connected() true zurückgibt. Das Webserver-example schließt die Verbindung nach jedem Request wieder.

Du könntest den Arduino ja mal parallel per USB verbinden und im Sketch ein paar debug-ausgaben über das Serial-device schicken um zu sehen, ob der EthernetServer eine Client-verbindung zurückgibt und ob es überhaupt über die 'if (client)'-Zeile in den eigentlichen Firmata-code reinkommt.

Das FRM bei ausbleibender Antwort FHEM komplett blockiert, habe ich grade gefixed.

Gruß,

Norbert
while (!asleep()) {sheep++};

ntruchsess

Hallo Erwin,

was kann ich denn mit 2 verbundenen Telnetclients in dem Zusammenhang anfangen?

Gruß,

Norbert
while (!asleep()) {sheep++};

gravy

Hallo,

Mein Ziel ist einen S0 Reader zum Zählen des Gaszählers zu bauen und die Daten dann in fhem einzulesen.
Das Zählen mit dem Arduino funktioniert schon und die Daten sind über eine simple Webseite auslesbar.

Auf der Suche nach einer Schnittstelle zur Anbindung an fhem habe ich Deine Firmatalösung gesehen, die vielversprechend klingt.

Ich habe gerade versucht deinen Sketch "StandardFirmataEthernetServer.ino" zu kompilieren. Leider bricht der Job ab:

'class FirmataClass' has no member named write.

Ich habe die nochmal die aktuelle Arduinoversion 1.0.3 aufgespielt. Das Beispiel StandardFirmata lässt sich kompilieren. Werden weitere Libraries gebraucht?

Ich stehe gerne für weitere Tests zur Verfügung.

Viele Grüße,

Dirk



ntruchsess

Hallo Dirk,

zum compilieren musst Du den ganzen Branch (inklusive Firmata.h/Firmata.cpp und Boards.h) herunterladen und damit den Firmata-ordner im Arduino-libraries Verzeichniss ersetzen. Sonst nimmt die Arduino-IDE immer die installierte Firmata-bibliotek und da fehlt die Firmata.write()-methode halt noch.

Gruß,

Norbert
while (!asleep()) {sheep++};

erwin

re: was kann ich denn mit 2 verbundenen Telnetclients in dem Zusammenhang anfangen?

Norbert,

ein paar Einträge weiter oben wurde von der Client- Implementation von Firmata-Ethernet gesprochen und dass auch FRM den Client mode implementiert hat.
Wenn ich TCP-Tee richtig verstehe, ist das ein proxy server, der 2 clients transparent miteinander verbindet, nicht beschränkt auf telnet-protokoll, sondern im raw-mode.

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

gravy

Danke Norbert,

ich musste fhem auch auf den Development-Stand heben.

Jetzt läuft die Kommunikation.

Viele Grüße,

Dirk

ntruchsess

Hallo Erwin,

re: Wenn ich TCP-Tee richtig verstehe, ist das ein proxy server, der 2 clients transparent miteinander verbindet,

stimmt, das könnte funktionieren. (Wenn man den code nicht ändern will oder kann)
Als Entwickler beider Clients schreibe ich meinen code aber lieber so um, dass es ohne 'Hilfsmittel' einfach so läuft.

Gruß,

Norbert
while (!asleep()) {sheep++};

ntruchsess

Hallo Dirk,

freut mich, dass es bei Dir so schnell läuft :-)
Hast Du am StandardFirmataEthernetServer-sketch (abgesehen von der ip-addresse) irgendwas ändern müssen um es zum Laufen zu bekommen? Eddy könnte da sicher auch noch einen Tip brauchen...

Die OneWire-funktionalität (um FRM als OneWire-busmaster für OWX zu benutzen) habe ich übrigens grade mit dem EthernetServer-code gemerged:

https://github.com/ntruchsess/arduino/tree/onewire_scheduler_ethernetserver/examples/OneWireSchedulerEthernetServer

Gruß,

Norbert
while (!asleep()) {sheep++};

ntruchsess

Hallo Eddy,

ich glaube ich habe jetzt verstanden, warum meine EthernetServer-firmata bei Dir nicht antwortet. Wenn die systemReset-methode der Firmata aufgerufen wird, dann werden alle Pins auf Ihre Default-konfiguration zurückgesetzt, inklusive der SPI-pins zum W5100-Ethernet-chip. Beim Verbindungsaufbau von FRM wird halt auch systemReset aufgerufen um den angeschlossenen Arduino in einen definierten Zustand zu bringen. Und schon ist die IP-Verbindung Arduino-seitig abgerissen ohne das es FRM gleich mitkriegen würde...

Ich mach mich gleich mal dran das firmataseitig zu fixen.

Gruß,

Norbert
while (!asleep()) {sheep++};

kaizo

Hallo,

heute wollte ich Firmata mit Ethernet einmal testen. Hab den "OneWireSchedulerEthernetServer" komplett als Paket runtergeladen, im Verzeichnis "libraries/Firmata" alles damit ersetzt.

Erstes Problem: Die Beispiele werden nicht angezeigt, es bleibt bei den alten FIRMATA-Beispielen. Neustart hat nicht genutzt (Arduino-Umgebung 1.5.2)

Wenn ich das in ein eigenes Verzeichnis setze und kompiliere, dann ist das 2. Problem:
OneWire\OneWire.cpp.o: In function `OneWire::depower()':
D:\Program Files\Arduino\libraries\OneWire/OneWire.cpp:269: multiple definition of `OneWire::depower()'
OneWire.cpp.o:C:\Users\kazo\AppData\Local\Temp\build9057078034995441674.tmp/OneWire.cpp:274: first defined here
d:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
....

Der Compiler läuft nur durch, wenn ich das #include <OneWire.h> auskommentiere.

Kann das include auskommentiert bleiben?

Gruß
Kai

FHEM 6.x  auf i3
1x Maplecun FS20, HM, 1x CUL f. WMbus
1x Arduino Nano für Lacrosse, 1x für Empfang WH1080,
1x Arduino Uno+Ethernet-Shield & Firmata für 1Wire
1x Raspberry Pi für Einbindung Junkers-Heizgerät mit HT3-Schnittstelle, div. Sonoff+EspEasy+Tasmota über MQTT

ntruchsess

Hallo Kai,

wenn es ohne das <OneWire.h> compiliert, dann lass es raus - das ist nur drin, weil die Arduino-IDE 1.0.3 bei mir Probleme machte die OneWireFirmata.cpp zu compilieren, wenn es toplevel nicht includiert war. Zwischenzeitlich habe ich die OneWire-lib eh in den Sketch mit aufgenommen (ich habe eine Methode zum Suchen nach Devices im Alarmed-state hinzugefügt).

War die OneWire-library im Arduino-1.5.2 denn schon von Haus aus mit drin?

Edit: hab das <OneWire.h> include bei mir auch rausgeworfen - seit OneWire Bestandteil des Sketches ist compiliert es auch bei mir ohne.

Vom OneWire_Scheduler_EthernetServer-sketch habe ich grade ein Update committed, das dafür sorgt, das die SPI-pins (über die die Ethernet-kommunikation geht) von Firmata ignoriert werden. Das sollte das Problem des Verbindungsabbruchs beim systemReset beheben. Außerdem kann man nicht mehr versehendlich einen SPI-pin für etwas anderes konfigurieren.

Gruß,

Norbert
while (!asleep()) {sheep++};

kaizo

Hallo Norbert,

danke für die Info. Werde das ganze jetzt mal in der aktuellen, gerade von Dir geänderten Version testen.
Bin gespannt, ob das ganze besser "integriert" in Fhem ist als meine "simple" Version über http. Meine aktuelle Version hat noch den Vorteil, das ich zur Zeit die DHT11-Sensoren abfragen und übertragen kann.

Gruß
Kai
FHEM 6.x  auf i3
1x Maplecun FS20, HM, 1x CUL f. WMbus
1x Arduino Nano für Lacrosse, 1x für Empfang WH1080,
1x Arduino Uno+Ethernet-Shield & Firmata für 1Wire
1x Raspberry Pi für Einbindung Junkers-Heizgerät mit HT3-Schnittstelle, div. Sonoff+EspEasy+Tasmota über MQTT