Firmata+Arduino

[ntruchsess]

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.[...]
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.[...]Wenn die Configurable Firmata Mikrosekunden kann wäre da perfekt

Richtig erkannt, nur ist die Firmata ohne eine dafür spezialisierte Feature-klasse gerade wegen Ihrer Flexibilität leider nicht tauglich Timing im Microsekunden-bereich zu machen. Wenn man den Firmata-scheduler benutzt, dann versucht die Firmata während der delays andere Messages oder Sensoren zu bedienen. Wenn das dann länger dauert als das gewünschte Delay ist das Timing futsch.

Das muss man dann so wie bei den genannten Gateways machen: Mit einer (oder mehreren) Firmata-message(s) das komplette Funk-kommando übertragen und dann in einem Rutsch abspielen lassen. Im Prinzip gar nicht mal so schwer - ich würde vorschlagen dafür die existierende rcswitch-library herzunehmen (oder substanziell Anleihen dort nehmen) und in eine Firmata-Feature-klasse zu kapseln. Ich benutze selber aber keine 433MHZ basierten Sensoren oder Aktoren und habe auch erst mal genug Baustellen, wenn Dich das also interessiert, dann müsstest Du auch programmieren lernen... Du könntest als Anfang auch erst mal ein Proposal für die zu verwendenen Firmata-messages machen (und ggf. auf Firmata.org veröffentlichen). Im saubernen Design des Protokolls steckt sicher genauso viel Arbeit, wie nachher in der eigentlichen Implementierung...

Gruß,

Norbert

[woody]

Hallo,
habe mal mit dem aktuellen refactoring getestet. Folgende fehlermeldung bekomme ich:

2013.05.18 16:20:57 3: Arduino: port 3030 opened
2013.05.18 16:20:57 1: Error:Modul 00_OWX deactivated:
 Unrecognized character \xC2; marked by <-- HERE after ing_async <-- HERE near column 66 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.18 16:20:57 0: Unrecognized character \xC2; marked by <-- HERE after ing_async <-- HERE near column 66 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.


Ist dieser Fehler schon bekannt?

Grüße

woody

[ThomasL]

Hallo zusammen,

ich hab folgendes Relaismodul:
http://www.ebay.com/itm/New-16-Channel-12V-Relay-Module-For-Arduino-UNO-MEGA-2560-R3-ATMEL-ATMEGA-1280-/281037857443?pt=LH_DefaultDomain_0&hash=item416f2962a3

an einem Arduino Mega 2560 angeschlossen.
Alle Relais funktionieren nur die an Pin 47,39,31 und 23 nicht:
z.B:
define KellerKuecheHoch FRM_OUT 47
define EGSpielHoch FRM_OUT 39

Ich hab aber in der Pinbelegung nicht besonders für diese Pins gefunden.
Könnte es ein Bug sein?
Die Pins scheinen auch irgendwie in Wechselwirkung mit dem Nachbarpin zu stehen,
wenn ich z.B. versuche Pin 39 zu schalten funktioniert Pin 38 (oder 40 weiß nicht mehr genau) nicht mehr.

Noch was,
die Relais-Platine ist Low-Level input .
Könnte man die Pins in der Arduinofirmware standradmäßig auf HIGh schalten?
Damit Sie nicht zuerst geschaltet werden?

Grüße
Thomas

[ntruchsess]

die Relais-Platine ist Low-Level input .
Könnte man die Pins in der Arduinofirmware standradmäßig auf HIGh schalten?

Hallo Thomas,

die Vorgabewerte kannst du im Configurable-Firmata Sketch ab Zeile 94 so ändern, wie Du es benötigst.
Wegen der nicht schaltbaren Pins habe ich auch erst mal keine Idee, aber auch keinen MEGA2560 um das auszuprobieren. Was taucht denn im FHEM-webclient in der Übersicht des Firmatadevices unter input-pins und output-pins auf?

Gruß,

Norbert

[ThomasL]

Hallo Norbert,

was muss ich denn da ergänzen?
So in etwa:

     // sets the output to 0, configures portConfigInputs
      Firmata.setPinMode(i, OUTPUT);
      digitalWrite(i, HIGH);

DAnke
Thomas

[ThomasL]

Hallo Norbert,

nachdem ich:
digitalWrite(i, HIGH);
eingefügt habe, funktioniert es schon besser,
aber noch nicht optimal.

Sobald nun die Verbindung mit FHEM hergestellt wurde,
gehen die Pins teilweise auf LOW und werden dann wieder korrekt auf HIGH gesetzt.
Das dauert aber einige Sekunden bei 32 Pins.

Kann man die Pins beim Initialiesieren auf High setzen?

Grüße
Thomas

[det.]

Hallo Norbert,
habe heute mal den Stand von https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEMeingespielt. Funktioniert prima mit 6 Stück DS18B20 im 5s Takt und einem DS2406. Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

[ntruchsess]

Kann man die Pins beim Initialiesieren auf High setzen?

Du meinst FRM-Seitig? Beim Wiederverbinden macht löst FRM erst mal einen SystemReset (Softwareseitig, nur die Firmata) auf dem Arduino aus. Anschließend werden alle Pins der Reihe nach wieder so konfiguriert, wie sie vorher waren.
Das kurz auf 'LOW' gehen passiert Arduino-seitig. In der DigitalOutputFirmata-feature-class, methode handlePinMode werden die Pins per Default auf Low gesetzt. D.h. da wenn Du es da änderst, dann kannst Du den 'digitalWrite' Aufruf aus der systemReset-methode der ConfigurableFirmata.ino wieder herausnehmen. Mach doch auf Github ein Issue auf und wünsch Dir, dass man den Default-wert in der DigitalOutputFirmata-klasse konfigurierbar machen soll, oder besser noch: Wenn Du das vernünftig implementierst (so dass man den Default aus dem Sketch heraus z.B. über den Constructor setzen kann), clone das Repository und mache einen pull-request mit den Änderungen gegen den 'configurable'-branch.

P.S.: es gibt mal wieder ein Update: im refactoring_async branch geht jetzt 'get <owx_device> present' und 'get <owx_busmaster_device> alarms'

Gruß,

Norbert

[ntruchsess]

Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

Danke für das Feedback. So allmählich reift die Sache...
Hab grade gemerkt, dass pah irgendwann das 'buspower'-attribut entfernt hat, da kann OWX_FRM das natürlich auch nicht mehr setzen. Und ohne Buspower geht der Bus zwischen den Anfragen auf Low, d.h. die DS18B20 gehen nach dem Triggern der Konvertierung erst mal wieder aus so dass beim Auslesen kein aktualisierter Wert da sein kann.

Gruß,

Norbert

[ThomasL]

Du meinst FRM-Seitig? Beim Wiederverbinden macht löst FRM erst mal einen SystemReset (Softwareseitig, nur die Firmata) auf dem Arduino aus. Anschließend werden alle Pins der Reihe nach wieder so konfiguriert, wie sie vorher waren.
Das kurz auf 'LOW' gehen passiert Arduino-seitig. In der DigitalOutputFirmata-feature-class, methode handlePinMode werden die Pins per Default auf Low gesetzt. D.h. da wenn Du es da änderst, dann kannst Du den 'digitalWrite' Aufruf aus der systemReset-methode der ConfigurableFirmata.ino wieder herausnehmen. Mach doch auf Github ein Issue auf und wünsch Dir, dass man den Default-wert in der DigitalOutputFirmata-klasse konfigurierbar machen soll, oder besser noch: Wenn Du das vernünftig implementierst (so dass man den Default aus dem Sketch heraus z.B. über den Constructor setzen kann), clone das Repository und mache einen pull-request mit den Änderungen gegen den 'configurable'-branch.

Hallo Norbert,

ich kenne mich noch nicht so gut aus.
Die Stelle hatte ich vorher schon gefunden und mal geändert.
Dann mit Ardunio 1.0.4 den Sketch neu überprüft und geladen.
Hat aber nicht geändert.
Muss ich die anderen Klassen auch irgendwie neu kompilieren?
Oder passiert dies automatisch mit?

Danke
Thomas

[cberl]

Hallo Norbert,

erstmal vielen Dank für die super Arbeit. Ich habe über ethernet / firmata meine Alarmanlage angeknubbelt. Das funktioniert prima.
Ich habe im Haus fünf DHT21 verstreut, welche ich auch gerne über firmata auslesen würde. Wirst Du das weiter entwickeln?

Grüße Chris

[ntruchsess]

Muss ich die anderen Klassen auch irgendwie neu kompilieren?
Oder passiert dies automatisch mit?

Man kann ein komplettes Neucompilieren erzwingen, indem man in der Konfiguration ein anderes Board auswählt, baut und wieder zum eigentlich gewünschten Board zurückwechselt.

Gruß,

Norbert

[ntruchsess]

Ich habe im Haus fünf DHT21 verstreut, welche ich auch gerne über firmata auslesen würde. Wirst Du das weiter entwickeln?

für den DHT11 habe ich vor ein paar Wochen ein Firmata-Custom-feature geschrieben, Ein Perl-Beispiel, wie man damit kommuniziert findet sich hier. Vieleicht magst Du beides auf den DHT21 umschreiben? Dann könnte ich das recht fix in ein FRM-Client-modul packen.
Ich hab selber keine DHT21 und bin auch grade mit dem Refactoring vom OWX hinreichend ausgelastet.

Gruß,

Norbert

[ntruchsess]

Hallo Norbert,
habe heute mal den Stand von https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEMeingespielt. Funktioniert prima mit 6 Stück DS18B20 im 5s Takt und einem DS2406. Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

so, wieder mal ein Update an gleicher Stelle...

OWCOUNT geht jetzt asynchron - konnte ich mit dem ATiny-basiertem Board das det mir freundlicherweise geschickt hat erfolgreich testen. Mit diesem Board gibt es zwar (noch) Fehlermeldungen, die allerdings daher kommen, das die ATiny-emulation nur den Zähler, aber nicht das 1K-memory des DS2423 emuliert.

Kann das jemand mit einem 'richtigen' DS2423 testen?

OWTHERM hat auch ein paar Fixes abbekommen und geht jetzt weitestgehen. Nur die Messwerte hängen hin und wieder eine Messung hinterher (weil das asynchrone Auslesen öfter mal die Konvertierung überholt).

Gruß,

Norbert

[eppi]

Hallo zusammen
Ich habe soeben meine ersten Gehversuche mit einem Arduino UNO R3(Standard Firmata) gemacht und ihn problemlos als USB Device mit FHEM verbunden.
Ich würde den UNO R3 gerne über Ethernet ansprechen, damit ich meinen Klingeltaster einbinden kann. Am UNO R3 hängt ein ENC28J60 EthernetShield.

Meine Frage dazu:
Gibt es schon einen Firmata-Sketch, der meinen ENC28J60 EthernetShield ansprechen kann? Den bisherigen (falls überhaupt möglich) zu übersetzen, traue ich mir mangels Kentnissen (noch) nicht zu.

Danke für die Hilfe.
Gruss Dani