Firmata+Arduino

ntruchsess · 08 März 2013, 10:23:11

Hallo Eddy,

danke für das Feedback :-)

Das sich der Arduino und FHEM nach einem Reconnect nicht selbstständig synchronisieren ist bekannt, da habe ich auch noch nichts implementiert. Bin ja erst mal schon froh, dass der Reconnect mittlerweile so reibungslos funktioniert.

Gruß,

Norbert

kaizo · 09 März 2013, 09:45:34

Hallo Norbert,

ist ja super. Werde das in den nächsten Tagen mal testen und Rückmeldung geben, leider ist meine freie Zeit augenblicklich sehr knapp.
Vielen Dank vorab schon mal, toll, daß Du Dich diesem Thema annimmst.

Gruß
Kai

ntruchsess · 12 März 2013, 01:03:15

ich habe jetzt eingebaut, dass die Module FRM_OUT, FRM_PWM und FRM_LCD den letzten bekannten Zustand nach einem Reconnect des Arduinos oder einem Restart von FHEM wiederherstellen. Kann man mit den Attributen 'restoreOnStartup' bzw. 'restoreOnReconnect' an oder abschalten (Default is an).
Das ist keine 'echte' Synchronisation, Der Arduino resettet erst mal alle Pins auf Output, LOW. Nach einem Reconnect bekommt er halt die letzbekannten Statuswerte wieder übertragen, vorher (d.h. auch wenn die Netzverbindung z.B. länger unterbrochen ist) bleiben die Pins auf LOW. (Dieses Verhalten des Arduinos kann man natürlich nur in der Firmware ändern). Eingabepins, an denen HIGH anliegt übertragen diesen Wert beim Reconnect auch sofort an FRM.

OneWire funktioniert im Prinzip auch über Ethernet, allerdings nur, wenn FRM vor dem Start des OWX-moduls schon zum Arduino verbunden hat. Das ist eine Limitierung des OWX, Peter (pah) ist da im Moment am refactoren, ich hoffe, dass wir den Reconnect in diesem Zuge auch hinkriegen. Zum Testen muss man ggf das OWX-device erst definieren, wenn FRM schon auf aktiv steht.

(Wenn der Arduino über USB angebunden ist und beim Start von fhem nicht angesteckt ist, gibts das Problem auch).

Viel Spaß damit,

Norbert

justme1968 · 18 März 2013, 22:09:09

hallo norbert,

kannst du abschätzen wie aufwändig es ist eines der ultraschall module per arduino und firmata an fhem anzubinden?

ich würde gerne versuchen das als tank sensor zu verwenden.

gruss
andre

ntruchsess · 18 März 2013, 23:36:49

nun, man muss halt den code von hier in eine FirmataFeature-klasse wrappen (analog zu meinem DHT11Firmata-Beispiel). Wenn ich dazu komme möchte ich ein generisches fhem-modul zum Empfang von solchen Sensordaten schreiben (man kann die Sysex-messages so einer CustomFeatureFirmata-klasse in der perl-firmata mit observe_sysex abonieren und selber parsen, die eingentliche Aufgabe ist, dass man nur einen sysex-observer per FirmataDevice abonieren kann, diese callback-function also im FRM-modul selbst liegen muss und die Messages dann an die eigentlichen - z.B. einem Pin zugeordneten Devices - verteilen muss). Das ist aber eigenlich auch nicht weiter schwer, das ginge analog zu dem FRM_IN oder FRM_AD-modulen. Hab nur ein paar Baustellen gleichzeitig am laufen (so ein Ultraschallsensor liegt hier übrigens schon da, den Gedanken das einzubinden hatte ich auch schon). Wenn Du Lust hast selber Hand anzulegen, dann schau Dir mal o.g. DHT11-example und eben FRM_IN bzw. FRM_AD als Vorlage an.

Gruß,

Norbert

justme1968 · 18 März 2013, 23:49:56

lust ja :) aber wie das so mit baustellen ist... gestern ein neues modul eingecheckt und heute schon wieder eins angefangen :)

da ich noch keinerlei infrastruktur oder komponenten für die ultraschall geschichte hier habe muß ich bei null anfangen und mich erst mal einlesen. es dauert also auf jeden fall bis ich dazu komme. aber endlich was in c++ zu machen wäre eine schöne abwechlsung. das liegt mir doch sehr viel mehr als perl.

ich denke ich werde mal hardware suchen und bestellen. bis das zeug dann da ist läuft das neue itunes modul hoffentlich und die gartenbewässerung muß eh warten bis es etwas wärmer.

gruss
andre

Wzut · 23 März 2013, 17:46:26

Zitat von: ntruchsess schrieb am Fr, 08 März 2013 10:23H Bin ja erst mal schon froh, dass der Reconnect mittlerweile so reibungslos funktioniert.

Hallo Norber, Danke für die Arbeit - läuft im Testbetrieb recht gut, beim Reset des Arduino ist diese sehr schnell wieder am fhem Server angemeldet. Starte ich aber fhem neu dauert es manchmal "ewig" bis er sich verbindet. Ich habe daher etwas gespielt und den Pin 13 (interne LED) geopfert und gleich hinter if (client.connected()) die LED auf HIGH
und im else Teil auf LOW gelegt. Fazit : der Arduino bekommt sehr schnell mit das fhem resetet wurde verbindet sich aber nicht.
Meine qick and dirty Lösung ist nun das ich 10 Sekunden warte und dann einen Arduino Softreset auslöse. Die Verbindung ist dann sofort wieder aufgebaut.
(Hardware : Arduino Mega 2560 mit Ethershield - beides China billig Teile)

Code Auswählen


#endif
#ifdef StepperFirmata_h
    stepper.update();
#endif
  
  } else {
    delay(10000);
    asm volatile ("  jmp 0");  
  }
}

ntruchsess · 24 März 2013, 00:45:24

hi Wzut,

Mir ist auch nicht so recht klar, warum das so lange braucht um wiederzuverbinden. Irgendwie hat die Arduino-Ethernetlib da Probleme mit. Aber coole Idee, den Reconnect einfach über einen Softreset zu triggern :-)

Dabei geht zwar der aktuelle Zustand verloren, das kann aber ja durchaus gewünscht (weil definiert und sicher) sein.

Gruß,

Norbert

Wzut · 24 März 2013, 19:29:23

Zitat von: ntruchsess schrieb am So, 24 März 2013 00:45Dabei geht zwar der aktuelle Zustand verloren, das kann aber ja durchaus gewünscht (weil definiert und sicher) sein.

Ist für mich auch so OK , da fhem ja den letzten Zustand nach dem Reconnect sofot wieder überträgt. Alternativ kann man natürlich vor dem SoftReset den Zustand der OUT Pins ins EEPROM schreiben und am Ende von Setup wieder auslesen und setzen.

justme1968 · 30 März 2013, 19:20:23

ich mache gerade meine aller ersten versuche mit einem arduino mega und beim kompilieren von OneWireSchedulerFirmata bekomme ich den folgenden fehler:

Code Auswählen

OneWireSchedulerFirmata.ino: In function 'void sysexCallback(byte, byte, byte*)':
OneWireSchedulerFirmata:485: error: 'INTERNAL' was not declared in this scope

kann es sein das

Code Auswählen

          case 1:
            analogReference(INTERNAL);
            break;

genau so in ein #ifdef INTERNAL gehört wie entsprechend case 2 und 3 danach?

gruss
andre

ntruchsess · 31 März 2013, 01:51:19

'INTERNAL' ist in den Board-spezifischen includes definiert, das sollte eigentlich nicht fehlen (Auf jeden Fall nicht bei einem mega). Hast Du das Board auch richtig in der IDE eingestellt?
Ansonsten nimm bitte den neuesten Stand: https://github.com/firmata/arduino/archive/configurable.zip, da sollte das eigentlich funktionieren.

Wo ist eigentlich noch der alte 'OneWireSchedulerFirmata.ino'-sketch verlinkt? Nur hier im Anfang des threads (wo ich den link leider nicht mehr ändern kann :-( ), oder auch irgendwo im fhem-wiki?

Gruß,

Norbert

justme1968 · 31 März 2013, 14:26:30

hallo norbert,

ich glaube die war tatsächlich aus dem ersten post. inzwischen hatte ich eine OneWireSchedulerEthernetServer firmata aus dem git branch gefunden die ich ohne probleme kompilieren kann.

die version aus dem configurable.zip geht aber bei mir wieder nicht. ich habe das gefühl das er alles was mit utility zu tun hat nicht findet. wenn ich z.b. ConfigurableEthernetserver auf mache ist nur dieses eine file offen und nicht wie bei OneWireSchedulerEthernetServer aus dem branch mehrere. und beim compilieren bekomme ich das hier:

Code Auswählen

ConfigurableEthernetserver:38: error: 'DigitalInputFirmata' does not name a type
ConfigurableEthernetserver:41: error: 'DigitalOutputFirmata' does not name a type
ConfigurableEthernetserver:44: error: 'AnalogInputFirmata' does not name a type
ConfigurableEthernetserver:47: error: 'AnalogOutputFirmata' does not name a type
ConfigurableEthernetserver:51: error: 'ServoFirmata' does not name a type
ConfigurableEthernetserver:59: error: 'I2CFirmata' does not name a type
ConfigurableEthernetserver:62: error: 'OneWireFirmata' does not name a type
ConfigurableEthernetserver:65: error: 'StepperFirmata' does not name a type
ConfigurableEthernetserver:68: error: 'FirmataExt' does not name a type
ConfigurableEthernetserver:71: error: 'FirmataScheduler' does not name a type
ConfigurableEthernetserver.ino: In function 'void setup()':
ConfigurableEthernetserver:170: error: 'class FirmataClass' has no member named 'setPinMode'
ConfigurableEthernetserver:170: error: 'IGNORE' was not declared in this scope
ConfigurableEthernetserver:173: error: 'class FirmataClass' has no member named 'setPinMode'
ConfigurableEthernetserver:173: error: 'IGNORE' was not declared in this scope

oder muß das zip file an eine andere stelle entpackt werden als das original Firmata (auf dem mac .../Arduino.app/Contents/Resources/Java/libraries) ?

gruss
andre

ntruchsess · 31 März 2013, 17:55:19

wie das auf dem mac aussehen muss weiß ich leider nicht. Prinzipiell sollte es aber genauso gehen, wie auf den anderen Plattformen auch:
mit dem Inhalt des zip-files den Inhalt des libraries/Firmata Ordners ersetzen. Anschließend den sketch über 'Datei'->'Beispiele'->'Firmata'->'ConfigurableFirmata' laden und compilieren. Wichtig ist, dass der Ordner auch wirklich so wie das zugehörige cpp und header-file 'Firmata' heißt (und nicht so wie das zip-file 'arduino-firmata').
Eigentlich sollte die Arduino-ide den Inhalt des utility-verzeichnisses selbsttätig in den Build-pfad aufnehmen, auch wenn die Dateien nicht im Sketch sichtbar sind.
Stell doch mal unter 'Datei'->'Einstellungen'->'Ausführliche Ausgabe anzeigen während Compilierung' die Debug-ausgabe an, da sieht man genau mit welchen Pfaden der gcc tatsächlich aufgerufen wird.

Ansonsten kannst Du mal unter libraries/Wire oder libraries/Ethernet schauen. Diese libraries haben (unter Linux und Windows) auch Klassen im utility-Verzeichnis. Schau doch mal, wie das auf dem mac abgelegt ist.

Wenn ich mir die Fehlermeldungen allerdings so ansehe, dann habe ich das Gefühl, dass Du die original Firmata-library gar nicht ersetzt hast, sondern immer noch die mit der Arduino-ide ausgelieferte Version angezogen wird. (Das würdest Du mit vorgenannter Debug-einstellung beim compilieren auch genau sehen können).

Gruß,

Norbert

justme1968 · 31 März 2013, 18:29:59

du hast recht. ich war beim hin und her zwischen original und git version und branch mit den directories durcheinander gekommen.

die beispiele aus dem zip file compilieren jetzt. und auch die ConfigurableEthernetclient firmata.

sobald der ultraschall sensor da ist oder die zusätzlichen DS1820 kann ich dann mehr probieren als nur trockenübungen oder leds blinken lassen.

danke und gruss
andre

justme1968 · 01 April 2013, 20:59:58

hallo norbert,

die ersten versuche mit ein paar leds per ethernet client sind schon mal erfolgreich verlaufen. das ganze ist wirklich ein sehr schönes spielzeug.

dabei auch gleich ein vorschlag:

- ich denke es wäre schön wenn ein unsupported oder unconfigured mode nur eine Fehlermeldung produziert und nicht gleich fhem zum aussteigen bringt. (jeweils die die in is_supported_mode und is_configured_mode.

gruss
andre