Firmata Update für Firmware-Versionen ab 2.7

[jensb]

@Maista

Bei Gelegenheit versuche ich Async.

Das soll auch gehen, aber klemmt scheinbar auf dem OWX-Seite manchmal. Weiter vorn im Thread war eine Info dazu von @dirigent.

Grüße,
Jens

[abc2006]

Du empfängst (FRM:<) jede Sekunde einen analogen Messwert von Pin 0 (E0). Dein Firmata-Device reagiert also und scheinbar ist ein FRM_AD-Device für Pin 0 konfiguriert, was merkwürdig ist, da du ja OneWire machen willst. Ohne das Logging vor dem 1. "e01a02" kann man aber nicht herausfinden, woran das liegen könnte.

Ja. Ich hoffe, ich hatte oben schon erwähnt, dass ich (zusätzlich) einen AnalogIn definiert hatte, um feststellen zu können, ob ich Firmata-Verbindung habe.

Siehe hier und hier

Klasse,
danke, das hab ich schon ein paar mal gesucht. Dann beschäftige ich mich mal weiter damit und linke meine Frage mal zum one-Wire-Forum...

Danke erstmal für die Hilfe. Wenn ich noch was testen soll (grad hab ich den Aufbau noch da) sag Bescheid.
Grüße,
stephan

[Achim]

Hallo Jens,

ich bin gestern dazugekommen, mir nochmals deine neuen Versionen anzusehen/einzuspielen. Ich habe auch deine geänderte OWX_FRM installiert. Nach Löschen der Firmata Parameter im fhem.save und Neustart funktioniert es jetzt bei mir. Auch die Inputs gehen.
In meiner Signatur steht was alles an dem Firmata Arduino hängt.

Viele Grüße
Achim

[jensb]

@Achim
Danke für die Rückmeldung. Wenn du Teile der fhem.save löschen musstest, damit es funktioniert, hast du das gleiche Problem mit OWX_FRM wie einige andere. Das wird sich vermutlich hin- und wieder melden, bis die Ursache gefunden ist. In diesem Thread wird momentan danach gesucht.

Grüße,
Jens

[abc2006]

Hi,
hab jetzt mal die aktuellste Firmware (firmatabuilder.com) drauf.
Danke für die beiden Links, jetzt kann ich endlich mal verstehen, was da passiert.


#########################################################################################
##### EDIT: alle Fragen hinfällig ####################
###########################################################################
Dadurch ergibt sich auch die erste Frage:

2018.01.11 15:12:34 5: Arduino FRM:>f90000
2018.01.11 15:12:34 5: SW: f90000
2018.01.11 15:12:34 5: Arduino FRM:>f079f7
2018.01.11 15:12:34 5: SW: f079f7
2018.01.11 15:12:35 5: Arduino setup stage 1
2018.01.11 15:12:35 5: Arduino setup stage 1
2018.01.11 15:12:36 5: Arduino FRM:<f90206f079020a4f0057004600690072006d006100740061006200750069006c
2018.01.11 15:12:36 5: Arduino setup stage 1
2018.01.11 15:12:36 5: Arduino FRM:<00640065007200320030003100380030003100310031002e0069006e006f00f7
2018.01.11 15:12:36 5: Arduino setup stage 1
2018.01.11 15:12:36 3: Arduino Firmata Firmware Version: OWFirmatabuilder20180111.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.11 15:12:36 5: Arduino FRM:>f069f7
2018.01.11 15:12:36 5: SW: f069f7
2018.01.11 15:12:36 5: Arduino FRM:>f06bf7
2018.01.11 15:12:36 5: SW: f06bf7
2018.01.11 15:12:36 5: Arduino FRM:<f90206f079020a4f0057004600690072006d006100740061006200750069006c
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<00640065007200320030003100380030003100310031002e0069006e006f00f7
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<f07155006e00680061006e0064006c0065006400200073007900730065007800
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<200063006f006d006d0061006e006400f7f06c7f7f07017f07017f07017f0701
2018.01.11 15:12:36 3: received String_data: Unhandled sysex command

Wenn ich das richtig dekodiert habe, fragt FHEM den Arduino nach einem analogen mapping

Code Auswählen Erweitern


2018.01.11 15:12:36 5: Arduino FRM:>f069f7
f0 - Start SYSEX
69 - ANALOG_MAPPING_QUERY # warum fragt der hier nach analogen..
f7 - End SYSEX

Welches vom Arduino (verständlicherweise) mit HÄ? beantwortet wird:

Code Auswählen Erweitern

2018.01.11 15:12:36 5: Arduino FRM:<f07155006e00680061006e0064006c0065006400200073007900730065007800


Hab zwar noch ca. tausend weitere Fragen, aber vielleicht beantworten sich durch diese Info einige davon;)
Grüße,
stephan

edit: Tippfehler

edit: ich verlänger das gleich mal ein bisschen:
auf die 6b(CAPABILITY_QUERY) antwortet der Arduino:

Code Auswählen Erweitern


f06c7f7f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f7f7ff7


Was übersetzt heisst:
Alle meine Pins (ausser 1,2,20,21 und 22) können OneWire (07) und DigitalOut(01)

So, hab jetzt grade mal ne halbe stunde gesucht, wie die Pins zugeordnet sind. Dachte, ich hätte das mal irgendwo gesehen.
Ich gehe mal davon aus, Pin 1 = TX, Pin 2= RX, Pin  3 = D2 [...] Pin 14 = D13 ( also eigentlich der letzte OW-Pin), Pin 15= A0, Pin 16 = A1 [...] Pin 22 = A7; anders macht es nicht viel Sinn.

Code Auswählen Erweitern



Arduino FRM:>f07a6807f7
f0
7a setze analoge polling zeit
68 auf .. 1896 ms
07
f7



Meine Haupt-Frage: Warum fragt FRM nach Analog-Werten, wenns doch anscheinend erkannt hat, dass der Arduino gar kein Analog unterstützt ( kein Internal "analog-pins" und warum zeigt Firmata keine Digital-Pins an, wenn doch der Arduino (fälschlicherweise?!?) behauptet, er könne es?

Hab ich was übersehen? [/s]

#########################################################################################
##### /EDIT: alle Fragen hinfällig ####################
###########################################################################

Nach einem reboot des Raspberry läufts. ab-, und anstecken des Arduino, als auch ein "shutdown restart" sind NICHT ausreichend!


Grüße,
Stephan

[jensb]

Hallo Stephan,

Meine Haupt-Frage: Warum fragt FRM nach Analog-Werten, wenns doch anscheinend erkannt hat, dass der Arduino gar kein Analog unterstützt ( kein Internal "analog-pins"

Die bisherigen FRM-Versionen wollten auch dann die Verbindung zum Firmata-Device herstellen, wenn irgendetwas bei den Capability-Abfragen schief geht und haben es der Anwender-Konfiguration überlassen, ob es plausibel war oder nicht. Es gab bis zum Update Anwender von FRM, die keine "xxx_pins/resolution" Internals angezeigt bekommen haben (siehe z.B. hier). Natürlich könnte man das bei der neuen Version verriegeln. Auch beim Setzen des Sampling-Intervals könnte automatisch eine 0 senden, wenn weder analoge Eingangspins bzw. I2C-Pins gemeldet werden. Das ist aber alles Kategorie "nice to have" und könnte einige experimentierfreudige Anwender stören. Das nächste geplante Update von FRM_IN wird übrigens tatsächlich von den Capabilities Gebrauch machen, um den Pin-Mode PULLUP abwärtskompatibel unterstützen zu können.

... und warum zeigt Firmata keine Digital-Pins an, wenn doch der Arduino (fälschlicherweise?!?) behauptet, er könne es?

Woraus schließt du "behauptet"? Aus "f06c7f7f07017f07017f07017f0701..."? Ja, diese Antwort ist auf den 1. Blick merkwürdig, bedeutet aber Pin 0: -, Pin 1: -, Pin 2: OneWire, Pin 3: OneWire, ... - da ist nichts mit INPUT oder OUTPUT dabei. "0701" bedeutet nicht OneWire + INPUT sondern OneWire mit resolution=1.

Nach einem reboot des Raspberry läufts. ab-, und anstecken des Arduino, als auch ein "shutdown restart" sind NICHT ausreichend!

Schön dass es läuft, aber trotzdem ein bisschen merkwürdig. FHEM selbst kennt keinen Unterschied zwischem Neustart (/etc/init.d/fhem stop/start bzw. "shutdown restart") und Booten. Wenn man wirklich booten muss, um ein Problem zu lösen, dann liegt die Ursache im Bereich Betriebssystem (z.B. I/O-Recourcen) oder Hardware (z.B. Netzteil Spannungsstabilität).

Grüße,
Jens

[abc2006]

"0701" bedeutet nicht OneWire + INPUT sondern OneWire mit resolution=1.

Ahhh... das war mein Fehler. Dann hat der Arduino ja alles richtig gemacht.
Hab ich im Protokoll tatsächlich übersehen.

die Verbindung zum Firmata-Device herstellen[...]Anwender-Konfiguration

Wenn ich das richtig verstehe, glaubte Firmata, dass ich noch einen Analogen PIN abfragen wollte?
Meine Anwender-Konfiguration sagt aber nichts (mehr) von analog. Spätestens nachdem ich FHEM neu gestartet habe, müssten alle Überreste des Analogen Inputs weg sein (dachte ich zumindest).
Gut, legen wir das solange zu den Akten, bis mir einfällt, wie ich das reproduzieren könnte.

Wenn man wirklich booten muss, um ein Problem zu lösen, dann liegt die Ursache im Bereich Betriebssystem (z.B. I/O-Recourcen) oder Hardware (z.B. Netzteil Spannungsstabilität).

Stimme ich dir zu, und ich vermute auch eher das Betriebssystem (/dev/ttyUSBx) als Ursache.
Allerdings weiss das Betriebssystem nix von FRM und AnalogPins...
Und ich erwarte von meinem Raspian, dass beim entfernen des USB-Steckers von einem Gerät sämtliche Kernelmodule entladen werden, bis es das nächste mal verbunden wird...

Grüße,
Stephan

[JensS]

Hallo Jens,

heute konnte ich das Reading ausmachen, welches die OWX-Abfrage blockt.
Wenn man set OWX reopen ausführt, wird das OWX-Device in den STATE disconnected versetzt und ändert dies nicht mehr.
Sobald setreading OWX state Initialized ausgeführt wird, klappt es wieder mit der Abfrage.

Gruß Jens

[jensb]

Hallo Jens,

hattest du "reopen" manuell ausgelöst?

Habe mir das in 00_OWX.pm angesehen: bei "reopen" wird DevIo_OpenDev aufgerufen. Aber diese Funktion ist nur für "echte" Betriebssystem-Devices wie serielle Schnittstellen gedacht und funktioniert nicht mit FHEM-internen IODev-Schnittstellen wie FRM. DevIo_OpenDev verändert die Verknüpfung zwischen dem FHEM-Kern und dem OWX-Device und setzt den State von OWX auf "disconnected", da DevIo_OpenDev kein OS-Device öffnen kann. OWX prüft periodisch mit OWX_Init auf neue Devices, aber wenn der State auf "disconnected" steht natürlich nicht mehr.

Um das zu verhindern müsste pah Anpassungen an OWX und den anderen OWX-Modulen machen, indem der "reopen"-Ablauf schnittstellenspezifisch umgesetzt wird. Bei FRM sollte ein "reinit" reichen.

Aktuell ist es das Beste, die Finger von "reopen" zu lassen, wenn man OWX mit FRM verwendet.

Grüße,
Jens

[JensS]

Ja, das hatte ich manuell ausgelöst, in der Annahme, dass passiert, was da steht.   
Wenn man dann get OWX devices aufruft, werden diese angezeigt - seltsam...

Gruß Jens

[jensb]

Wenn man dann get OWX devices aufruft, werden diese angezeigt - seltsam...

Zum Glück nachvollziehbar, denn diese Funktion ist in OWX einerseits schnittstellenspezifisch umgesetzt und prüft andererseits nicht den State.

Grüße,
Jens

[JensS]

Hallo Jens,

wollte nur mal den aktuellen Stand mitteilen:
FRM und 11_OWX_FRM.pm laufen in allen Installationen tadellos.

Gruß Jens

[JensS]

Hallo Jens,

das Update vom 17.01. habe ich verpasst. Mein voriger Beitrag bezieht sich also auf die Vorversion. Nun habe ich die neue Version eingespielt und bekomme folgenden Fehler:

Code Auswählen Erweitern

2018.01.21 10:28:12 5: Cmd: >define in1 FRM_IN 3<
2018.01.21 10:28:12 5: Loading ./FHEM/20_FRM_IN.pm
2018.01.21 10:28:12 1: reload: Error:Modul 20_FRM_IN deactivated:
Bareword "PIN_PULLUP" not allowed while "strict subs" in use at ./FHEM/20_FRM_IN.pm line 97, <$fh> line 39.
2018.01.21 10:28:12 0: Bareword "PIN_PULLUP" not allowed while "strict subs" in use at ./FHEM/20_FRM_IN.pm line 97, <$fh> line 39.

Gruß Jens

[jensb]

Hallo Jens,

vermute, dass du perl-firmata noch nicht aktualisiert hast (z.B. mit FHEM Update). Die neue Version des Moduls FRM_IN braucht auch die neue Version 0.64 von perl-firmata, da es die Konstante "PIN_PULLUP" bis 0.63 nicht gegeben hat. Habe gerade die Abhängigkeitshinweise im 1. Post korrigiert.

Grüße,
Jens

[JensS]

Danke und sorry, ich hatte perl-firmata noch in exlude_from-update drin.
Peinlich

Jetzt läuft FRM_IN.

Gruß Jens