Firmata+Arduino

[det.]

ich bring den Zähler am Montag auf die Post, sollte also spätestens Mittwoch bei Dir sein.

[ntruchsess]

Selbst das rereadcfg bewirkt einen Absturz von fhem.

den Absturz beim 'rereadcfg' habe ich grade gefixed und ins svn committed

Gruß,

Norbert

[ntruchsess]

Auch wenn das noch nicht Final ist, schick doch mal eine beta ;-)

Für alle, die mal einen Blick auf den aktuellen Arbeitsstand werfen oder (beta-)testen wollen habe ich die files mal auf github gelegt:

Der Branch 'refactoring' enthält den Stand, der mit den aktuellen OWxxxx.pm-Device-modulen zusammenarbeiten sollte:
https://github.com/ntruchsess/fhem_owx/tree/refactoring/fhem/FHEM

Dieser code ist schon recht stabil und enthält z.B. die Umbauten für den Reconnect eines OneWire Busmasters. Getested mit Arduino über USB und DS2480B Busmaster an einem FTDI-USB-adapter. Mit einem CUNO konnte ich diese Version selber nicht testen und pah hat im Moment auch ziemlich viel um die Ohren. Also wenn jemand einen CUNO und Lust auf Experimente hat...

Der Branch 'refactoring_async' enthält die Überarbeitung zur asynchronen Abfrage der OWxxx-devices:
https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM
bisher habe ich erst OWTHERM.pm umgestellt. Läuft bei mir hier mit Arduino/USB und DS2480B. Der Code für den CUNO ist noch gar nicht umgestellt...

Gruß,

Norbert

[det.]

Hallo Norbert,

Danke, Absturz ist weg!

[det.]

Der Branch 'refactoring_async' enthält die Überarbeitung zur asynchronen Abfrage der OWxxx-devices:
https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM
bisher habe ich erst OWTHERM.pm umgestellt. Läuft bei mir hier mit Arduino/USB und DS2480B. Der Code für den CUNO ist noch gar nicht umgestellt...

Hallo Norbert,
mit dem neuen OWTHERM liefern die DS1820 keine Werte und gehen auf present 0 obwohl sie vorher gefunden werden:

Code Auswählen Erweitern

OWX: 1-Wire devices found on bus OWX_0
28.F213DD030000      DS18B20        OWX_28_F213DD030000
28.AABDDA030000      DS18B20        OWX_28_AABDDA030000
28.467BDA030000      DS18B20        OWX_28_467BDA030000
28.EE81DA030000      DS18B20        OWX_28_EE81DA030000
28.A5A5DA030000      DS18B20        OWX_28_A5A5DA030000
28.1B7BDA030000      DS18B20        OWX_28_1B7BDA030000
12.4EF17B000000      DS2406/DS2507  OWX_12_4EF17B000000
OWX über Ardunio-USB angeschlossen

[ntruchsess]

ach so, das 'get XXX present' vom FRM_OWX, da muss ich noch mal ran, das geht nicht asynchron. Da muss ich noch was implementieren, dass es nicht nur einen Search auf dem Bus anstößt, sondern auch (synchron) auf das Ergebnis wartet.

Die Temperaturen werden bei mir aber gemessen. Stell doch mal das Interval auf 10 Sekunden und refreshe die 'Everything'-Übersicht. Das sollte deutlich besser antworten als bei der bisherigen synchronen Variante. Man darf das Intervall aber auch nicht zu kurz einstellen, weil OWTHERM gnadenlos Anfragen losschickt, die der Arduino auch nur ca. 1/sec abarbeiten kann (wegen der 1 Sekunde Pause zwischen Conversion und Abfrage).

Wenn Du ein 'get XXX temperature' aufrufst, dann wird im Device die Convertierung und das auslesen getriggert. Der angezeigte Wert ist aber (sofern schon vorhanden) noch der alte, da die Antwort ja asynchron (und daher erst nach Aufruf des get XXX temperature) vom Arduino empfangen wird. Da muss ich (analog zum get XXX present) noch ein synchrones Warten auf die asynchrone Antwort einbauen.

Soll auch erst mal der erste Wurf sein, der demonstriert, dass die zyklische Abfrage eben auch asynchron im Hintergrund geht.

Gruß,

Norbert

P.S. hab grade gemerkt, dass das 'reconnect' im Prinzip zwar geht, wenn man OWTHERM aber z.B. im 5 Sekunden Rythmus abfragen läßt, ist die Weboberfläche so lange lamgelegt, bis man den Arduino wieder verbunden hat, oder die 5 Errors pro DS18B20 erreicht sind, bei denen OWTHERM auf 999 Sekunden Interval umstellt. Die Baustellen gehen nicht aus ;-)

[kaizo]

Für alle, die mal einen Blick auf den aktuellen Arbeitsstand werfen oder (beta-)testen wollen habe ich die files mal auf github gelegt:

Der Branch 'refactoring' enthält den Stand, der mit den aktuellen OWxxxx.pm-Device-modulen zusammenarbeiten sollte:
https://github.com/ntruchsess/fhem_owx/tree/refactoring/fhem/FHEM

Dieser code ist schon recht stabil und enthält z.B. die Umbauten für den Reconnect eines OneWire Busmasters. Getested mit Arduino über USB und DS2480B Busmaster an einem FTDI-USB-adapter. Mit einem CUNO konnte ich diese Version selber nicht testen und pah hat im Moment auch ziemlich viel um die Ohren. Also wenn jemand einen CUNO und Lust auf Experimente hat...

Also Norbert,
da hat sich ja scheinbar einiges getan. Habe die "refactoring" seit gestern abend im Einsatz, seit dem läuft FHEM ohne Absturz durch!
Und die DS2423-(Fake)-Counter können ausgelesen werden!
rereadcfg geht auch wieder.

Super!

Jetzt noch asynchron, dann ist alles gut. Obwohl ich schon mit der dieser Version zufrieden bin, endlich keine Abstürze mehr

Werde mal weiter testen, auch was "save config" und ein Neustart angeht.

Gerade gemacht,.. und:
Den ersten Test hat das alles gut überstanden, nur die Zählerabfrage vom Counter hat bei einer gespeicherten Config mit FRM & OWX nicht mehr geklappt. Die Zählerstände werden scheinbar nur angezeigt, wenn ich beim FHEM-Start FRM und OWX manuell definiere und dann anzeigen lasse.


Gruß
Kai

[Yaku]

Ich weiss nicht wo ich aktuell am besten diese Frage stellen soll, allerdings passt der Titel und wenigstens ist das Thema im weitesten sinne auf Haustechnik bezogen.

Ich frage mich ob es möglich ist Funksteckdosen via Fimata over Ethernet zu steuern, die Sketches nutzen normalerweise die RC-Switch library und die sended dann die Impulse als digitalwrite auf den pin in abständen von z.B. 320 Mikrosekunden.
Kann man das dem Arduino so schnell via am ethernet angebundenem Firmata mitteilen ?

so ist der arduino aktuell verkabelt: http://www.homecontrol4.me/de/?id=bauanleitung
natuerlich mit dem entsprechenden sketch von homecontrol4, im firmata ethernet gebe ich ja eine feste ip direkt im sketch.

danke

Yaku

[ntruchsess]

mir ist nicht ganz klar, was Du machen möchtest. Daher erst mal, was ich meine verstanden zu haben:

Arduino mit Funkmodulen soll über Standard-Firmata angesteuert werden um Funksteckdosen zu steuern (ohne Verwendung der RC-Switch library)? Also alles was die Library macht z.b. nach Perl portieren und den Arduino nur als Firmata-IO-interface über Ethernet nutzen?
-> ich glaube nicht, dass das von Timing her zuverlässig geht. Da sollte man die RC-Switch-library in eine Firmata-Feature-Klasse wrappen (siehe 'configurable'-Firmata auf GitHub) und nur noch 'High-level' commands per Firmata an den Arduino schicken. Das exakte Timing würde dann der Microcontroller machen, Netzwerkverzögerungen wären dann unkritisch.

Gruß,

Norbert

[woody]

Hallo Leute,
habe refactoring ausprobiert. Leider findet er jetzt meine dvices nicht mehr.

2013.05.16 21:37:58 3: Arduino: port 3030 opened
2013.05.16 21:37:59 1: reload: Error:Modul 00_OWX deactivated:
 Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.16 21:37:59 0: Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.16 21:37:59 3: Please define 1Wire first
2013.05.16 21:37:59 1: define: OWTHERM: Warning, no 1-Wire I/O device found for OWX_10_E2EE54020800.

Kennt jemand das Problem?

Grüße
woody

[Yaku]

Arduino mit Funkmodulen soll über Standard-Firmata angesteuert werden um Funksteckdosen zu steuern (ohne Verwendung der RC-Switch library)?
Also alles was die Library macht z.b. nach Perl portieren und den Arduino nur als Firmata-IO-interface über Ethernet nutzen?
-> ich glaube nicht, dass das von Timing her zuverlässig geht.

Das war mein Gedanke da wenn es so funktioniert hätte man immer neue Sensoren anstecken hätte können ohne was am Arduino zu ändern :), aber ich dachte mir schon fast das es nicht ganz so einfach ist.

Da sollte man die RC-Switch-library in eine Firmata-Feature-Klasse wrappen (siehe 'configurable'-Firmata auf GitHub) und nur noch 'High-level' commands per Firmata an den Arduino schicken. Das exakte Timing würde dann der Microcontroller machen, Netzwerkverzögerungen wären dann unkritisch.

Das hoert sich sinnvoll an aber in dem Fall ist es evtl. Interessanter einen Gateway fuer die Signale ohne RC-Switch zu benutzen da es 2 so wie ich es verstanden habe freie Oberflächen gibt die eine Art Standart benutzen in dem Sie den Code ohne RC-Switch direkt an das Gateway schicken und nur noch angeben wieviele Microsekunden zwischen den bit´s liegen.
Ich weis nur nicht ob man das einfach so einen gateway wie beim http://www.hmb-tec.de/HMB-TEC/House_Control.html, usw. einbauen darf, es gibt schon 3 Verschiedene Gateways(Intertechno,hcgw und conn-air) die das so machen und prinziprell sieht das auch aus wie die Ausgabe der RC-Switch library bevor sie den digitalwrite(); auf den datenpin macht...

Die Befehle sehen eigentlich ganz Simpel aus die Interpretiert werden müssen. Von perrpf im power-switch.eu Forum.

Code Auswählen Erweitern

TXP:0,0,6,0,360,25,1,3,1,3,1,3,3,1,1,3,1,3,1,3,1,3,1,3,3,1,1,3,1,3,1,3,3,1,1,3,3,1,1,3,1,3,1,3,3,1

Für mich ist das alles eine Gedankenspielerei, wäre schön wenn man diese Apps nutzen könnte mit dem Arduino und zumindest power-switch scheint auch open source zu werden beim release.
http://power-switch.eu

naja, wäre halt schoen bestehendes mitnutzen zu können, da hab ich gestern auch mit jemandem im Powerswitch Forum drüber gesprochen: http://forum.power-switch.eu/viewtopic.php?f=8&t=79

gruß

Yaku

[ntruchsess]

Hallo Yaku,

Sehe ich das richtig, das Timing spielt sich im 1-3ms Bereich ab? Remote bit für bit über das Netzwerk klappt das garantiert nicht, das ist schneller als übliche Ping-zeiten, wenn man nicht grade per cross-over-kabel direkt verbunden ist.

Mit der configurable-Firmata https://github.com/firmata/arduino/tree/configurable könnte man das im Prinzip schon machen - da kann man eine Serie von digitalOut-befehlen mit delays im ms-Bereich als Tasks speichern und in einem Rutsch abspielen. Die Länge der Bitfolge wird dabei nur durch das RAM des Arduinos begrenzt (allerdings mehrere Bytes pro Bit, da ja für jede Zustandsänderung ein Firmata-kommando abgelegt wird). So ein Task kann dabei jeweils ein- oder mehrfach nacheinander laufen. Wenn er nur einmal laufen soll, ist der Speicher direkt im Anschluss daran wieder frei. Da die gesammte Bitfolge vor dem Abspielen komplett übertragen wird, spielt das Netzwerk für das Timing keine Rolle mehr.

Natürlich könnte man damit nur präzise senden. Wenn man Funk-kommandos empfangen wollte, müsste man das Timing auf dem Arduino aufschlüsseln. Die Firmata Digital-in-messages würden zwar vermutlich schnell genug generiert, allerdings ohne jede timing-information, also für diesen Anwendungsfall wertlos.

Ein Beispiel, wie man so einen Task mit der perl-firmata zusammenbaut findet sich (für 1-Wire-kommunikation) hier (ab Zeile 44): https://github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire.pl#L44

Wenn Du Dich daran versuchen willst und ggf. ein auf FRM basierendes FHEM-modul basteln möchtest, gebe ich Dir gerne alle nötigen Tipps.

Gruß,

Norbert

[ntruchsess]

habe refactoring ausprobiert[...]
 Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

00_OWX.pm line 9 ist ja im Anfangskommentar der Datei, da steht überhaupt kein code der Fehler haben könnte. Irgendwie scheint die beim Übertragen kapput gegangen zu sein? Auf welcher Plattform läuft das?

Gruß,

Norbert

[ntruchsess]

Jetzt noch asynchron, dann ist alles gut.

So ein kleines Update:
Ich habe am refactoring_async weitergearbeitet und einige Bugs gefixed, so dass OWTHERM jetzt tatsächlich asynchron geht. Beim letzten Update ist mir ein Fehler unterlaufen, da habe ich eine gar nicht laufähige Version von OWTHERM commitet (aber gegen eine andere getestet, die den fehlerhaften asynchronen code noch gar nicht aktiv benutzt hat). Naja - dafür läufts jetzt, und man kann seine DS18B20 auch im 5-Sekunden-rythmus abfragen (ok, ich habe es mit 2 Stück getestet, da ging das problemlos. Mit dem synchronen OWX war bei 5-Sekunden Abfrage-intervall das Webinterface auch mit 2 DS18B20 schon ziemlich zäh).

Alles wie gehabt auf GitHub: https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM

Die Firmata-firmware hat auch ein Update bekommen. Damit das ganze nicht aus dem Tritt kommt, wenn viele Devices am 1-Wire-bus hängen und die Requests der verschiedenen Module sich überschneiden wird jetzt mit jedem Firmata-request eine correlation-id mitgeschickt:

https://github.com/ntruchsess/arduino/tree/onewire_id

Installation wie gehabt (bestehendes Firmata-library Verzeichnis komplett ersetzen (inkl. utility-unterverzeichnis). Dann in der Arduino-IDE den Sketch unter Beispiele->Firmata->ConfigurableFirmata auswählen und auf den Arduino hochladen.

Meldet sich mit 'ConfigurableFirmata V_2_05' (Vorher war V_2_04).

Das update der perl-firmata ist abwärtskompatibel und schon ins fhem-svn committet. Der 'refactoring_async'-branch arbeitet mit beiden Firmwareversionen zusammenarbeiten (mit der V_2_05 sollte es aber stabiler laufen).

Über Feedback würde ich mich freuen.

Gruß,

Norbert

P.S.: Um OWCOUNT konnte ich mich noch nicht kümmern, erst musste der asynchrone Modus mal stabil laufen...

[Yaku]

Hallo Yaku,

Sehe ich das richtig, das Timing spielt sich im 1-3ms Bereich ab?

Leider nein, im Mikrosekundenbereich als Beispiel aus HC4M: https://github.com/xkonni/homecontrol4me/blob/master/sketchbook/homecontrol4me_v_1_1/homecontrol4me_v_1_1.pde#L217

Da wird der Delay auf 0,35ms gestellt.

und die RC-Switch baut den Sendecode zusammen mit den anderen Parametern was es für eine Steckdose ist.

https://github.com/r10r/rcswitch-pi/blob/master/RCSwitch.cpp#L347  

hab die RPi lib gelinkt da ich nicht weis wie ich die RC-Switch für Arduino hier verlinken könnte: http://code.google.com/p/rc-switch/downloads/list

Diese Gateways scheinen wenn ich es richtig Verstanden habe auch nur den Delay ein paar Parameter und dann die Codeausgabe die die RC-Switch sonst Onboard generiert zu empfangen.

Remote bit für bit über das Netzwerk klappt das garantiert nicht, das ist schneller als übliche Ping-zeiten, wenn man nicht grade per cross-over-kabel direkt verbunden ist.

Mit der configurable-Firmata https://github.com/firmata/arduino/tree/configurable könnte man das im Prinzip schon machen - da kann man eine Serie von digitalOut-befehlen mit delays im ms-Bereich als Tasks speichern und in einem Rutsch abspielen. Die Länge der Bitfolge wird dabei nur durch das RAM des Arduinos begrenzt (allerdings mehrere Bytes pro Bit, da ja für jede Zustandsänderung ein Firmata-kommando abgelegt wird). So ein Task kann dabei jeweils ein- oder mehrfach nacheinander laufen. Wenn er nur einmal laufen soll, ist der Speicher direkt im Anschluss daran wieder frei. Da die gesammte Bitfolge vor dem Abspielen komplett übertragen wird, spielt das Netzwerk für das Timing keine Rolle mehr.

Natürlich könnte man damit nur präzise senden. Wenn man Funk-kommandos empfangen wollte, müsste man das Timing auf dem Arduino aufschlüsseln. Die Firmata Digital-in-messages würden zwar vermutlich schnell genug generiert, allerdings ohne jede timing-information, also für diesen Anwendungsfall wertlos.

Ein Beispiel, wie man so einen Task mit der perl-firmata zusammenbaut findet sich (für 1-Wire-kommunikation) hier (ab Zeile 44): https://github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire.pl#L44

Wenn Du Dich daran versuchen willst und ggf. ein auf FRM basierendes FHEM-modul basteln möchtest, gebe ich Dir gerne alle nötigen Tipps.

Gruß,

Norbert

Interessiert bin ich an beidem, nen Sketch um den Arduino als einen 433mhz gateway laufen zu lassen kompatibel mit dem HCGW,Connair,Intertechno Gateway als auch Firmata Ethernet.

Was auch interessant wäre für FHEM diese Gateways zu unterstützen, momentan habe ich selbst noch keinen 24/7 Server für FHEM allerdings werde ich wenn ich fest in Schweden lebe meinen Mele a2000 dazu machen, http://romanrm.ru/en/a10 , ich hoffe FHEM läuft auf Debian.

Firmata Ethernet ist ja viel universeller und wenn es mit Firmate möglich wäre die Codes so zu Senden und Sensoren auszuprobieren ohne Ständig den Arduino neu mit sketchen bespielen zu müssen wäre das die flexibelste Lösung.

Ich würde wirklich gerne selbst etwas zu den Projekten beisteuern für die ich mich aktuell interessiere, allerdings kann ich bisher nur ein paar Elemente im Code ändern aber selbst nichts schreiben, evtl. hilft es einigen wenn ich meine Chinashoppinglinks zeige da man wenn man die 4-6 Wochen Lieferzeit(Schweden meist nur 2,damn Zoll) abwarten kann günstigst an die Komponenten kommt.

Transmitter: http://www.ebay.com/itm/New-1pcs-433Mhz-RF-Transmitter-And-Receiver-Kit-For-Arduino-Project-WST-/390562575788?
Arduino Uno: https://www.fasttech.com/products/0/10000015/1001700-arduino-uno-r3-rev3-development-board
Ethernetshield: https://www.fasttech.com/products/0/10000007/1000701-ethernet-shield-with-wiznet-w5100-ethernet-chip
Dupontkabel Male-Female: http://www.ebay.com/itm/350769139083

Wenn die Configurable Firmata Mikrosekunden kann wäre da perfekt, erstmal bis man Funkwetterstationen empfangen möchte(braucht ja den Rückkanal) ohne für 200€ für die rxfcom lan :P, aber jetzt wird das zuviel im Post... (gestern auf dieses Projekt gestossen: http://wmrx00.sourceforge.net/index.html)
mit diesem shield: http://www.osengr.org/WxShield/Web/WxShield-V1.html

gruß

Yaku