Firmata Seriell/USB in 98_autocreate.pm integriert

Begonnen von CaptBlaubaer, 24 Oktober 2013, 01:44:30

Vorheriges Thema - Nächstes Thema

CaptBlaubaer

Hallo liebe FHEM Freunde,

ich habe die autocreate Funktion für StandardFirmata Geräte mit der seriellen/USB Schnittstelle auf meinem Raspberry Pi integriert.
Ich kann leider nicht überprüfen, ob ich dabei die Geräteerkennung der anderen Geräte beeinflußt habe. Vielleicht kann das jemand mit diesen Geräten testen.

Sollte Interesse bestehen, stelle ich die Datei gerne zur Verfügung (Bitte mit Tip wie).

Die Arduino (1.5.4b) StandardFirmata Software führt bei einem Neustart eine Ausgabe der Versionnummern auf der LED PIN 13 durch. Das dauert aktuell, einschließlich Reset, mehr als 2 Sekunden.
Ich habe deshalb einen neuen Hashkey (Timeout) eingeführt um dem Rechnung zu tragen.

Es gibt aber auch die Möglichkeit das Blinken zu unterbinden, wenn man statt
  Firmata.begin(57600);

wie in der StandardFirmata.ino

  Serial.begin(57600);
  Firmata.begin(Serial);

verwendet. Dabei wird kein Blinken mehr durchgeführt und es muss nur die Resetzeit berücksichtigt werden.

Viele Grüße,
CaptBlaubaer (CBR)

FHEM Raspberri Pi B
FHEM Fritzbox 7390  (ToDo)
Gembird USB Steckdosenleiste (SISPM)
Gembird LAN Steckdosenleiste (EGPM2LAN)
Diverse Arduinos (ToDo)
Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

rudolfkoenig

> Sollte Interesse bestehen, stelle ich die Datei gerne zur Verfügung (Bitte mit Tip wie).

Die Aenderungen als Patch hier anhaengen.

CaptBlaubaer

#2
Originale Datei

# $Id: 98_autocreate.pm 3957 2013-09-25 06:21:02Z rudolfkoenig $

und die Patches mit den Änderungen


14,17d13
< # Changes:
< # - added Firmata Serial/USB detection; CaptBlaubaer 2013-10-23 CBR
< # - changed output, device is shown only once; CaptBlaubaer 2013-10-23 CBR
<
363,371d358
<     { NAME      => "FRM",
<       matchList => ["cu.usbserial(.*)", "cu.usbmodem(.*)",
<                     "ttyUSB(.*)", "ttyACM(.*)", "ttyAMA(.*)"],
<       DeviceName=> "DEVICE\@57600",
<       init      => pack("H*", "F9"),   # Reset
<       Timeout   => 2.5,
<       request   => pack("H*", "F079F7"),   # Query firmware version and filename START_SYSEX (0xF0), queryFirmware (0x79), END_SYSEX (0xF7)
<       response  => "^\xF0\x79(.*)\xF7",    # Response Sysex xF0 x78 (2 Byte version) (n Byte filename) Endsysex xF7
<       define    => "FRM_PARAM FRM DEVICE\@57600", },
386,387d372
<   my $newDeviceFlag;    # CaptBlaubaer (CBR)
<
422d406
<         $newDeviceFlag = 1;
425c409
<        if($dev =~ m/$ml/) {
---
>         if($dev =~ m/$ml/) {
429,433c413,415
<           if ($newDeviceFlag) { # show dev only once in the list
<                       $msg = "\n### $dev:";
<                       Log3 undef, 4, $msg; $ret .= $msg . "\n";
<                       $newDeviceFlag = 0;
<                 }
---
>           $msg = "### $dev: checking if it is a $name";
>           Log3 undef, 4, $msg; $ret .= $msg . "\n";
>
439c421
<               $msg = "    already used by the fhem device $d ";
---
>               $msg = "already used by the $d fhem device";
444,445d425
<           $msg = "    checking if it is a    $name";
<           Log3 undef, 4, $msg; $ret .= $msg . "\n";
462,466c442
<              if(defined($thash->{Timeout})) {
<                 DevIo_TimeoutRead($hash, $thash->{Timeout});   # eg. StandardFirmata blink takes time
<              } else {
<                 DevIo_TimeoutRead($hash, 0.5);
<              }
---
>             DevIo_TimeoutRead($hash, 0.5);
472,475d447
<
<           $msg = "    request <".unpack("H*", $thash->{request}).">";
<           Log3 undef, 4, $msg; $ret .= $msg . "\n";
<
480,482d451
<           $msg = "    reponse <".unpack("H*", $answer).">";
<           Log3 undef, 4, $msg; $ret .= $msg . "\n";
<
484c453
<             $msg = "    got wrong answer for a $name";
---
>             $msg = "got wrong answer for a $name";
492c461
<           $msg = "    create as a fhem device with: define $define";
---
>           $msg = "create as a fhem device with: define $define";

Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

ntruchsess

#3
Zitat von: CaptBlaubaer am 24 Oktober 2013, 13:14:57
und die Patches mit den Änderungen

<


hab's gerade ausprobiert. Der Timeout von 2.5 Sekunden ist bei einem UNO zu kurz, mit 5 Sekunden gings dann :-)

- Norbert

P.S.: Du darfst bei einem Patch nicht die trailing spaces entfernen sonst akzeptiert das patch-kommando die '<'-Zeilen nicht.
P.P.S: welchen Zweck hat es die messages mit 4 vorgestellten Spaces zu versehen?
P.P.P.S: in den aktuellen SVN-stand integrierte Datei liegt hier: https://github.com/ntruchsess/fhem-mirror/blob/autocreate/fhem/FHEM/98_autocreate.pm @rudolfkoenig: soll ich das grade mal in den SVN-trunk committen?
while (!asleep()) {sheep++};

rudolfkoenig

Das commit uebernehme ich.

Ich mache mir Sorgen ueber die 5 Sekunden Timeout: bei mehreren stummen seriellen Geraeten koennten die Benutzer wegen des Wartens verunsichert werden.

Das geaenderte Einruecken hat mich auch stutzig gemacht, ich habs aber noch nicht getestet, um zu sehen wie es aussieht.

CaptBlaubaer

#5
Hallo Norbert, liebe FHEM Freunde,

vielen Dank fürs Testen. Ich hoffe es sind keine Nebenwirkungen bei anderen Geräten wie CUL, CUM, CUN und CUQ eingetreten.

Die 4 SPACES stammen aus der buddhistischen Mythologie

### ttyACM0:
    checking if it is a    CUL
    request <560a>
    reponse <>
    got wrong answer for a CUL
    checking if it is a    TCM310
    request <5500010005700838>
    reponse <>
    got wrong answer for a TCM310
    checking if it is a    FRM
    request <f079f7>
    reponse <f07902035300740061006e0064006100720064004600690072006d006100740061002e0069006e006f00f7>
    create as a fhem device with: define FRM_0 FRM /dev/ttyACM0@57600

### ttyACM1:
    already used by the fhem device mega2

### ttyAMA0:
    checking if it is a    CUL
    request <560a>
    reponse <>
    got wrong answer for a CUL
    checking if it is a    TCM310
    request <5500010005700838>
    reponse <>
    got wrong answer for a TCM310
    checking if it is a    FRM
    request <f079f7>
    reponse <>
    got wrong answer for a FRM

### ttyUSB0:
    checking if it is a    TCM310
    request <5500010005700838>
    reponse <5500010005700838>
    got wrong answer for a TCM310
    checking if it is a    TCM120
    request <a55aab5800000000000000000003>
    reponse <a55aab5800000000000000000003>
    create as a fhem device with: define TCM120_0 TCM 120 /dev/ttyUSB0@9600


Ich habe sie eingeführt um die für mich wichtigen Geräte schneller zu finden.
Die Ausgabe von request und response habe ich eingefügt, da ich keine Ahnung von Perl habe und auch nicht weiß wie ich hier debuggen kann.

Meine Arduino Megas und mein Nano laufen mit den 2.5 Sekunden und eingeschaltetem Versionsnummer Blinken.

Ohne Blinken genügte auch ein Timeout von 0.5s.

ZitatEs gibt aber auch die Möglichkeit das Blinken zu unterbinden, wenn man statt
  Firmata.begin(57600);

wie in der StandardFirmata.ino

  Serial.begin(57600);
  Firmata.begin(Serial);

verwendet. Dabei wird kein Blinken mehr durchgeführt und es muss nur die Resetzeit berücksichtigt werden.


Viele Grüße,
CaptBlaubaer (CBR)
Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

ntruchsess

Zitat von: CaptBlaubaer am 25 Oktober 2013, 11:44:34
Ich hoffe es sind keine Nebenwirkungen bei anderen Geräten wie CUL, CUM, CUN und CUQ eingetreten.

hab es grade mal den CUL vom Produktivsystem abgezogen und noch mal getestet. CUL und FRM-device wurden einwandfrei angelegt.

Zitat von: CaptBlaubaer am 25 Oktober 2013, 11:44:34
Firmata.begin(Serial);

hihi.... wer hat's erfunden: https://github.com/firmata/arduino/blame/master/Firmata.cpp#L79

Gruß,

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

CaptBlaubaer

Fein gemacht!!!

Zitathihi.... wer hat's erfunden: https://github.com/firmata/arduino/blame/master/Firmata.cpp#L79

Jetzt brauchen wir nur noch einen stabilen TelnetServer für die Arduinos, damit wir die auch "richtig herum" (damit meine ich FHEM als Telnet Client) einbinden können.
Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

ntruchsess

#8
FHEM als TelnetClient? Sag mal genauer, was Du damit meinst.
Wenn Du Firmata über Ethernet meinst - das gibt's längst:
https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L50
while (!asleep()) {sheep++};

CaptBlaubaer

#9
Hallo Norbert, liebe FHEM Freunde,

für mich ist ein Firmata Gerät ein Server, der Daten liefert. D.h. ein Client, in diesem Fall FHEM greift über eine Schnittstelle mittels eines Protokolls darauf zu.

Bitte korrigier mich falls ich die FoE (Firmata over Ethernet) anders interpretiere als sie implementiert ist.
Ich habe es so verstanden, dass das FoE Gerät eine Verbindung zum Controller, z.B. FHEM aufbaut.
Das bedeutet, dass die Controller IP jedesmal neu programmiert werden muss.

Ich bin leider egoistisch und faul und will mich mit dem ganzen *Programmierkrams" eigentlich gar nicht beschäftigen, muss es aber weil es noch keine funktionierende Enduser (DAU) Lösung gibt die ich verwenden kann.

Als DAU ist für mich nur eine Lösung akzeptabel, die nach der "Fertigung" nur noch konfiguriert aber nicht mehr programmiert werden muss.
D.h., wenn ich bei einem Freund ein Firmata Gerät installieren möchte, dann will ich höchstens noch seine FHEM Konfiguration anpassen aber nicht mehr den Firmata auf die IP Verhältnisse der anderen Umgebung programmieren.

Deshalb muss die Client -Server Architektur unter Firmata IMHO noch umgedreht werden um eine breitere Akzeptanz zu gewinnen.
Sprich - nicht nur Programmierer sondern auch Anwender haben ihren Spaß mit Firmata -

Update:
Habe gerade gesehen, daß es diese Lösung anscheinend schon gibt.
ZitatArduinoCommander
Setzt auf Firmata auf allerdings als Server und bietet auch ein Android Interface, das als Ethernet Client fungiert.

Leider bekomme ich weder FoE noch die ArduinoCommander Version ans laufen. Aber vielleicht hat ja schon jemand Erfahrung damit.
Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

ntruchsess

ach so, also nix mit telnet (das ist eine Anwendung zum interaktien Login) - Du meinst einfach nur wer hier die Verbindung initiiert.

Im Prinzip läßt sich der Serverport auch auf dem Arduino öffnen, so dass FHEM die Verbindung aufbauen würde. Das wären auf beiden Seiten nur wenige Zeilen Programmcode und ab Verbindungsaufbau vom Verhalten her exakt das gleiche.

Als wir das vor ein paar Monaten hier im Forum diskutiert haben, wurde halt eher die jetzt implementierte Lösung gewünscht. Hat was damit zu tun, dass die Arduinos so Ihre IP-addresse unkompliziert per dhcp bekommen können und es dabei auch nichts macht, wenn die Addresse sich mal ändert. Wenn der Arduino Server ist, dann muss man entweder eine statische IP einstellen, oder dafür sorgen, dass der dhcp-server der mac-addresse des Arduinos immer die gleiche Addresse zuweist (Geht mit den meißten Dhcp-servern). Aber auch dann kriegst Du die Arduinos nicht völlig ohne Programmieren 'gebacken' - mindestens musst Du dafür sorgen, dass jeder seine eigene Mac-addresse bekommt. Aber Du hast schon recht - wenn der Arduino der Server ist braucht die Arduinos nicht umzuflashen, wenn der FHEM-server mal eine andere ip-addresse bekommt.

Wo hängt's denn bei der FoE-Version?

Gruß,

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

CaptBlaubaer

#11
Hallo Norbert,

Zitatach so, also nix mit telnet (das ist eine Anwendung zum interaktien Login) - Du meinst einfach nur wer hier die Verbindung initiiert.
Nein, telnet ist nicht nötig, hab's auch erst später gesehen, TCP reicht auch schon.

Das Verhalten der IP-Adressen und die Konfiguration der Zuweisung wäre immerhin bei allen IP-Geräten (IP-Steckdosen, Web-Servern, Firmatas, ...) einheitlich (IMHO nach Standard) und könnte ohne neue Programmierung geändert werden.

Zur MAC-Adressen Programmierung hätte ich den Vorschlag diese durch ein Firmata Kommando ins EEProm zu schreiben und bei jedem Neustart zu lesen und zu verwenden. Das Gleiche könnten wir dann auch mit den IP Parametern machen. Alternativ hätt ich noch ein paar andere Ideen dazu. Die sind aber vielleicht off-topic.

ZitatWo hängt's denn bei der FoE-Version?
Irgendwie an Allem. Ich komm nicht durch die Anleitung. Fehler 99 - Benutzer austauschen.

Viele Grüße,
CaptBlaubaer (CBR)

Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270

rudolfkoenig

Habs eingecheckt, allerdings ohne die Mythologie.

ntruchsess

#13
Ok, es gibt 2 Gründe die gegen den Server auf dem Arduino sprechen:

1. Speicherbedarf (der Client spart sich das EthernetServerObjekt im Flash und RAM)

2. Wiederverbinden beim Neustart (Reset) des Arduinos. FHEM bekommt nämlich gar nicht mit, wenn man die Verbindung physikalisch hart unterbricht (Kabel am Arduino absteckt, oder diesen resettet). Das liegt am TCP-protokoll, das ein ausbleiben von Paketen erst mal nicht als Fehler ansieht und noch etliche Minuten bis Stunden (je nach Betriebssystem und Kerneleinstellungen) versucht die ausstehenden Pakete immer wieder zu senden. Ist der Arduino der Client, dann verbindet er sich zumindestens bei einem Reset sofort wieder. (Andersherum gilt das natürlich auch, aber in der Regel schaltet man seinen FHEM-server nicht einfach aus, sondern stoppt den FHEM-prozess. Hierbei werden die offenen Socketverbindungen zuverlässig geschlossen, auch wenn man den Prozess einfach killt).

Die IP-addresse des FHEM-servers könnte man übrigens genauso gut im EEPROM ablegen. Die Idee ist nicht neu, es muss sie nur mal jemand implementieren.

Genauso bräuchte es noch sowas wie ein keep-alive Protokoll (also Nachrichten, die nur dafür hin- und hergehen, dass man weiß, wann die Gegenstelle zuletzt lebend gesehen wurde. Wenn man keine AD-pins konfiguriert hat, oder 1-Wire devices pollt, kommt vom Arduino ja ggf. auch lange gar nix). Bei Firmata über USB ist das verzichtbar - wenn man den USB abstöpselt, dann erkennt FHEM das sofort.

Wenn Du Hilfe brauchst, Firmata über Ethernet ans Laufen zu kriegen, dann frag einfach (geziehlt, mit Info darüber, was genau Du gemacht hast, und an welchem Punkt du nicht weiterkommst) nach.

Gruß,

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

CaptBlaubaer

Hallo Norbert,

vielen Dank für Dein Angebot
Zitat von: ntruchsess am 26 Oktober 2013, 13:22:59
Wenn Du Hilfe brauchst, Firmata über Ethernet ans Laufen zu kriegen, dann frag einfach (geziehlt, mit Info darüber, was genau Du gemacht hast, und an welchem Punkt du nicht weiterkommst) nach.
Ich habe mich nur noch nicht getraut, weil ich die Kopfschmerzen durch den Off-Topic Hammer gefürchtet habe. Evtl. über PM oder in einem anderen Forum?

ad 1. Speicherbedarf:
kann ich nicht nachvollziehen, meine ($20) Megas sollten laufen, Nano habe ich nur am USB

ad 2. Wiederverbinden beim Neustart der FirmataIP Geräte
Ich bin noch am Grübeln, wo der Unterschied (FoE als Server) z.B. zu einem FB_CALLMONITOR ist.
FHEM läuft bei mir auf einen Himbeerchen und die FB ist übers LAN angebunden.
Wenn diese Verbindung unterbrochen oder die FB resetet wird habe ich IMHO dasselbe Verhalten wie bei einem FoE-Server. Auch können mehrere FBen eingebunden werden.
Ich gehe aktuell davon aus, dass es funktioniert auch wenn ich mir die Internals des FB_CALLMONITORs noch nicht angeschaut habe.

Ich bin klein und gemein, bitte erklär mir mal wie Du das bei einem fabrikneuen FoE-Client, remote machen möchtest:
ZitatDie IP-addresse des FHEM-servers könnte man übrigens genauso gut im EEPROM ablegen. Die Idee ist nicht neu, es muss sie nur mal jemand implementieren.
Wenn das mit dem Server funktioniert schau ich mal ob ich das mit dem EEPROM hinbekomme. (hab nur schon wieder eine viel zu perfekte Lösung im Kopf)

Viele Grüße,
CaptBlaubaer (CBR)
Best regards und viele Gruesse,
CaptBlaubaer (CBR)
_________________________________
FHEM 5.5 Raspberry Pi (B), IOMEGA iConnect, Firmata Arduinos USB/LAN, Gembird USB/LAN, ToDo: FHEM auf FritzBox 7390, 7270