http://wiki.fhem.de/w/api.php?action=feedcontributions&user=Ntruchsess&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-28T21:28:17ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8570DevelopmentReadingsAPI2014-11-24T12:17:56Z<p>Ntruchsess: /* Anforderungen an das API */ Anmerkung 'CommandSetReading'</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? (Warum gibt es ein 'CommandSetReading' in der bestehenden fhem-api?). Welchen Anwendungsfall gibt es dafür?<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen? <- Wenn beide Seiten einer Schnittstelle jeweils ihrem eigenen Standard genügen, dann muss man dazwischen übersetzen.<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wie wäre es, erst die Zugriffsmethoden zu definieren? Z.B. RUnit, RValue, RValue(..., $unit), RType, ...? Das macht es griffig. Ich meine damit, dass die Kunden sagen, was sie brauchen, und wir daraus das API definieren.<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.<br />
* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8569DevelopmentReadingsAPI2014-11-24T10:16:06Z<p>Ntruchsess: /* Anforderungen an das API */</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? Welchen Anwendungsfall gibt es dafür?<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen? <- Wenn beide Seiten einer Schnittstelle jeweils ihrem eigenen Standard genügen, dann muss man dazwischen übersetzen.<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wie wäre es, erst die Zugriffsmethoden zu definieren? Z.B. RUnit, RValue, RValue(..., $unit), RType, ...? Das macht es griffig. Ich meine damit, dass die Kunden sagen, was sie brauchen, und wir daraus das API definieren.<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.<br />
* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8555DevelopmentReadingsAPI2014-11-21T22:51:49Z<p>Ntruchsess: /* Erste Überlegungen */</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bidirektional eineindeutig ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern.<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich) -> ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehre Sets von Abildungsvorschrifen konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet.<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, websocket (z.B. SmartVisu) sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8554DevelopmentReadingsAPI2014-11-21T22:44:58Z<p>Ntruchsess: /* Zielsetzung */ pro-Argumente für Attribute und Internals</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bidirektional eineindeutig ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern.<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich) -> ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehre Sets von Abildungsvorschrifen konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet.<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8553DevelopmentReadingsAPI2014-11-21T22:36:17Z<p>Ntruchsess: /* Anforderungen an das API */ -> Anforderung mehre parallele Konfiguration zu unterstützen hinzugefügt</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Gehören Attribute und Internals wirklich hierher?<br />
* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.<br />
* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bidirektional eineindeutig ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern.<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich) -> ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.<br />
#* Es soll möglich sein mehre Sets von Abildungsvorschrifen konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet.<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8550DevelopmentReadingsAPI2014-11-21T22:02:22Z<p>Ntruchsess: /* Anforderungen an das API */ -> Verallgemeinerung der Anforderungen auf Attribute und Internals</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen<br />
#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.<br />
#* Sofern die Abbildevorschrift bidirektional eineindeutig ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern.<br />
#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).<br />
#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich).<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* das API soll abwärtskompatibel sein und einen (bidirektionalen) Zugriff auf bestehende Module ermöglichen.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8549DevelopmentReadingsAPI2014-11-21T21:47:26Z<p>Ntruchsess: /* Zielsetzung */ Attribute und Internals hinzugefügt</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll sich die Bedeutung eines Readings ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich).<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=DevelopmentReadingsAPI&diff=8548DevelopmentReadingsAPI2014-11-21T21:46:30Z<p>Ntruchsess: /* Ausgangssituation */ Attribute und Internals ergänzt</p>
<hr />
<div>[[Kategorie:Development]]<br />
<br />
== Abstract ==<br />
<br />
Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion. <br />
<br />
Ausgangspunkt ist [http://forum.fhem.de/index.php/topic,21247.0.html dieser Thread].<br />
<br />
== Ausgangssituation ==<br />
<br />
In FHEM besitzen Geräte sogenannte Readings (Anzeigewerte). Diese bestehen aus einem Zeitstempel und einem Wert. Die Änderung eines Readings wird in der Regel durch einen Event daran interessierten Geräten über die NotifyFn mitgeteilt. Die Werte von Readings sind Zeichenketten. Sie können beim Herunterfahren in einer eigenen Datei (fhem.save) gesichert und beim Neustarten von FHEM wiederhergestellt werden. Readings sind von der Natur her schnellveränderlich.<br />
<br />
Geräte können Attribute besitzen. Attribute besitzen nur einen Werte ohne Zeitstempel. Sie sind in der Regel un- bzw. langsamveränderlich und dienen typischerweise zur Konfiguration. Attribute werden persistent in der Konfiguration abgelegt. Änderungen an Attributen werden auch analog zu Reading-änderungen durch Events distributiert. Auch Attribute sind Zeichenketten.<br />
<br />
Geräte besitzen interne Werte (sog. Internals). Auch diese besitzen nur einen Werte ohne Zeitstempel. Internals können perl-skalare oder Referenztypen (z.B. hashes oder Arrays) sein. Änderungen an Internals werden nicht per Event weitergegeben, die Werte werden nicht persistiert.<br />
<br />
Readings, Attribute und Internals genügen keiner festgelegten Syntax: es gibt bezüglich der Werte keine Vorgaben zur Standardisierung. Diese können z. B. Zahlenwerte, Kombinationen aus Zahlen und physikalischen Einheiten oder Texte enthalten. Beispielsweise können Readings, die Temperaturen darstellen, die Temperatur in Celsius-Graden oder Kelvin-Graden mit oder ohne Einheitensymbol enthalten. Das erschwert die Weiterverarbeitung. Soll beispielsweise eine Temperatur in einer graphischen Benutzeroberfläche mit einem Thermometer-Widget dargestellt werden, müssen für jede Geräteklasse individuelle Transformationsregeln von der Darstellung im Reading auf den Eingangsparameter im Widget transformiert werden.<br />
<br />
Keine Semantik: Es gibt kein API, anhand dessen eine Funktion erkennen kann, was das Reading inhaltlich darstellt. Eine graphische Benutzeroberfläche kann beispielsweise nicht ermitteln, ob für ein bestimmtes Reading ein Thermometer-Widget oder eine Lampe dargestellt werden soll.<br />
<br />
== Zielsetzung ==<br />
<br />
Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings erlaubt.<br />
<br />
Frühere Ansätze sind [[DevelopmentInterfaces|Interfaces]] und [[DevelopmentGuidelines|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].<br />
<br />
== Anforderungen an das API ==<br />
<br />
# Funktionale Anforderungen<br />
#* Es soll sich die Bedeutung eines Readings ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).<br />
#* Es sollen sich bei physikalischen Größen Wert und Einheit ermitteln lassen.<br />
#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).<br />
#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.<br />
#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich).<br />
# Nichtfunktionale Anforderungen<br />
#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.<br />
#* Das API soll nur unwesentlichen Overhead bzgl. Speicherverbrauch und Verarbeitungszeiten erzeugen.<br />
#* Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature) (das war früher einmal eine Forderung).<br />
<br />
== Erste Überlegungen ==<br />
<br />
* Einheiten alleine genügen nicht, es sollte die physikalische Größe bekannt sein, die von dem Reading repräsentiert wird (Temperatur, Druck, ...).<br />
* Dazu eine Regel, in welcher Einheit diese physikalische Größe vorliegt.<br />
* Es bringt keinen Zusatznutzen, die physikalische Größe am Reading verfügbar zu haben.<br />
* Stattdessen meldet das Device, dass es einem Standard gehorcht (ein Interface implementiert, z.B "temperature").<br />
* Ein GUI weiß dadurch, was es anzuzeigen hat. <br />
* KEINE Einheiten im {readings}{VAL}. Das muß bei wirklich jeder anderen Verwendung außer "Anzeige für Mensch mit selben Locale wie Entwickler." gestrippt werden.<br />
* An jedes Reading werden Metainformationen geklebt. Welche?<br />
* Die Metainformationen könnten Zeiger in eine hierarchische Liste standardisierter Beschreibungen sein. Sind die [[DevelopmentInterfaces|Interfaces]] modellhaft?<br />
* Es ist klar, dass die Bedeutung eine Vereinbarung darstellt, die außerhalb des Systems liegt. GGf. kann man die Implementierung aber ihre eigene Dokumentation enthalten lassen.<br />
* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.<br />
* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").<br />
* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB und DBLog sind Kunden.<br />
* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:Ntruchsess&diff=3496Benutzer Diskussion:Ntruchsess2013-11-12T22:33:19Z<p>Ntruchsess: /* Aktuelle Aktivitäten im Themenbereich Arduino / Firmata */</p>
<hr />
<div>== Aktuelle Aktivitäten im Themenbereich Arduino / Firmata ==<br />
<br />
Hallo Norbert,<br />
die Liste der letzten Änderungen deutet an, dass Du gerade im genannten Themenbereich recht aktiv bist... aber ich habe den Eindruck, dass Dir noch das Konzept fehlt, wie das Ganze am Ende aussehen soll.<br />
<br />
Du hast beispielsweise eine ganze Reihe von neuen Wiki-Seiten angelegt, die derzeit noch leer sind, für die ich aber nicht wirklich die Berechtigung einer eigenen Seite sehe. Hier evtl. auch (wie unten für die Kategorie beschrieben) die Löschkandidat-Vorlage benutzen, damit ein Administrator die wieder entfernen kann (oder zumindest einen kurzen Hinweis einfügen, was für die jeweilige Seite geplant ist).<br />
<br />
Außerdem hast Du neue Kategorien angelegt ([[:Kategorie:Arduino|Arduino]]: ok, ich denke das passt; [[:Kategorie:Arduino Firmata|Arduino Firmata]]: ich denke, das sollte alles unter die Arduino Kategorie passen; einen Bedarf für eine eigene Kategorie sehe ich hier nicht). Da Du die Arduino Firmata Kategorie schon überall wieder entfernt hast, nehme ich an, dass die wieder gelöscht werden kann. Falls ja, füge doch einfach '''<nowiki>{{Löschkandidat|Nicht mehr benötigt/versehentlich angelegt/sonstiger Grund}}</nowiki>''' in die Kategorieseite ein.<br />
<br />
Abschließend noch: ich habe gesehen, dass Du reichlich html-Tags verwendet hast (z.B. alle Absätze mit <nowiki><p></p></nowiki> erzwungen hast). Dazu möchte ich nochmal vorschlagen, dass wir uns auch hier im Fhem-Wiki an den allgemeinen wikipedia Vorschlägen (siehe https://de.wikipedia.org/wiki/Hilfe:Textgestaltung) orientieren, d.h. Leerzeile für einen neuen Abschnitt, etc. - zudem damit auch der Quelltext leichter lesbar wird/bleibt.<br />
<br />
Bitte nicht falsch verstehen: das ist alles nur als (Diskussions-)Anregung zu verstehen - ich bin hier auch "nur" Gast / normaler Benutzer.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:00, 10. Nov. 2013 (CET)<br />
<br />
Danke für die Anregungen, grade das mit den Löschkandidaten muss ich mir mal ansehen. Die Seiten sind leer, weil ich das Arduino-Thema etwas durchstruckturieren wollte, dann aber gemerkt habe, dass das doch Quatsch ist und löschen kann man selber ja nicht mehr...</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3449Arduino2013-11-09T13:09:09Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
<br />
=== mit eigenem Arduino-Sketch ===<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
=== mit vorgefertigem Firmata-Sketch ===<br />
Zur Anbindung des Arduinos mit dem Firmata-Protocol und vorgefertigtem Sketch siehe: [[Arduino_Firmata]]<br />
<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_Firmata&diff=3448Arduino Firmata2013-11-09T13:01:49Z<p>Ntruchsess: links zur CommandRef</p>
<hr />
<div>== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata.[[http://firmata.org]]. Mit der perl-firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul [[FRM]] in FHEM eingebunden. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
<br />
siehe auch: [http://fhem.de/commandref.html#FRM CommandRef FRM]<br />
=== 20_FRM_IN.pm ===<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
siehe auch: [http://fhem.de/commandref.html#FRM_IN CommandRef FRM_IN]<br />
=== 20_FRM_OUT.pm ===<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
siehe auch: [http://fhem.de/commandref.html#FRM_OUT CommandRef FRM_OUT]<br />
=== 20_FRM_AD.pm ===<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
siehe auch: [http://fhem.de/commandref.html#FRM_AD CommandRef FRM_AD]<br />
=== 20_FRM_PWM.pm ===<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<nowiki>define Firmata_ANALOG FRM_PWM 10 # definiert Arduino Pin 10 als analogen Ausgang</nowiki><br />
siehe auch: [http://fhem.de/commandref.html#FRM_PWM CommandRef FRM_PWM]<br />
=== 20_FRM_SERVO.pm ===<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<nowiki>define Firmata_ANALOG FRM_AD 9 # definiert Arduino Pin 9 als analogen Eingang</nowiki><br />
siehe auch: [http://fhem.de/commandref.html#FRM_SERVO CommandRef FRM_SERVO]<br />
=== 20_FRM_I2C.pm ===<br />
<p>Erlaubt das Auslesen von über I2C angeschlossenen ICs</p><br />
siehe auch: [http://fhem.de/commandref.html#FRM_I2C CommandRef FRM_I2C]<br />
=== Arduino mit OneWireFirmata ===<br />
<p>die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.</p><br />
siehe auch: [http://fhem.de/commandref.html#OWX CommandRef OWX]<br />
<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3447Kategorie:Arduino2013-11-09T12:47:27Z<p>Ntruchsess: </p>
<hr />
<div>[[Kategorie:Hardware]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_Firmata&diff=3445Arduino Firmata2013-11-09T12:46:03Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata.[[http://firmata.org]]. Mit der perl-firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul [[FRM]] in FHEM eingebunden. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== 20_FRM_IN.pm ===<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
=== 20_FRM_OUT.pm ===<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
=== 20_FRM_AD.pm ===<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
=== 20_FRM_PWM.pm ===<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
=== 20_FRM_SERVO.pm ===<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
=== 20_FRM_I2C.pm ===<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3444Arduino2013-11-09T12:45:29Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
siehe: [[Arduino_Firmata]]<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3443Kategorie:Arduino2013-11-09T12:44:52Z<p>Ntruchsess: Die Seite wurde geleert.</p>
<hr />
<div></div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3442Kategorie:Arduino2013-11-09T12:44:13Z<p>Ntruchsess: </p>
<hr />
<div>[[Kategorie:Hardware]]<br />
[[Kategorie:Other_Components]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3434Arduino2013-11-09T12:36:09Z<p>Ntruchsess: Arduino_Firmata in eigene Seite ausgelagert</p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
siehe: [[Arduino_Firmata]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3433Arduino mit OneWireFirmata2013-11-09T12:32:46Z<p>Ntruchsess: </p>
<hr />
<div>= OneWireFirmata (ConfigurableFirmata) =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige ConfigurableFirmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata DS2482-Firmata] benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_Firmata&diff=3432Arduino Firmata2013-11-09T12:32:21Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata.[[http://firmata.org]]. Mit der perl-firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul [[FRM]] in FHEM eingebunden. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== 20_FRM_IN.pm ===<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
=== 20_FRM_OUT.pm ===<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
=== 20_FRM_AD.pm ===<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
=== 20_FRM_PWM.pm ===<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
=== 20_FRM_SERVO.pm ===<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
=== 20_FRM_I2C.pm ===<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3431Arduino mit OneWireFirmata2013-11-09T12:22:17Z<p>Ntruchsess: </p>
<hr />
<div>= OneWireFirmata (ConfigurableFirmata) =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige ConfigurableFirmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata DS2482-Firmata] benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:Arduino_Firmata]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_Firmata&diff=3415Arduino Firmata2013-11-09T11:57:45Z<p>Ntruchsess: Die Seite wurde neu angelegt: „== Arduino mit Firmata == Für den Arduino gibt es ein StandardProtokoll Firmata.http://firmata.org. Mit der perl-firmata[https://github.com/ntruchsess/per…“</p>
<hr />
<div>== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata.[[http://firmata.org]]. Mit der perl-firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul [[FRM]] in FHEM eingebunden. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
[[Kategorie:Arduino_Firmata]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3412Kategorie:Arduino2013-11-09T11:33:47Z<p>Ntruchsess: </p>
<hr />
<div>[[Kategorie:Arduino_Firmata]]<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Other_Components]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3411Kategorie:Arduino2013-11-09T11:33:14Z<p>Ntruchsess: </p>
<hr />
<div>[[Kategorie:Arduino_Other]]<br />
[[Kategorie:Arduino_Firmata]]<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:Other_Components]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3410Kategorie:Arduino2013-11-09T11:29:08Z<p>Ntruchsess: </p>
<hr />
<div>[[Kategorie:Hardware]]<br />
[[Kategorie:Other_Components]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3409Arduino2013-11-09T11:27:20Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Arduino]]<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Kategorie:Arduino&diff=3408Kategorie:Arduino2013-11-09T11:26:41Z<p>Ntruchsess: Die Seite wurde neu angelegt: „Kategorie:Hardware“</p>
<hr />
<div>[[Kategorie:Hardware]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3407Arduino2013-11-09T11:16:27Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Interface]]<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3406Arduino2013-11-09T11:13:26Z<p>Ntruchsess: </p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Interface]]<br />
[[Kategorie:Other_Components]]<br />
[[Kategorie:Hardware]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3405Arduino mit OneWireFirmata2013-11-09T11:10:30Z<p>Ntruchsess: </p>
<hr />
<div>= OneWireFirmata (ConfigurableFirmata) =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige ConfigurableFirmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata DS2482-Firmata] benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3240Arduino2013-10-27T16:33:13Z<p>Ntruchsess: Installation ConfigurableFirmata hinzugefügt</p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== Installation ConfigurableFirmata ===<br />
Die ConfigurableFirmata <b>ersetzt</b> die vorhandene Firmata-library <b>komplett</b>. Die mitgelieferte Firmata befindet sich typischerweise:<br />
<br />
<nowiki><br />
Arduino 1.0.x:<br />
Mac OSX: /Applications/Arduino.app/Contents/Resources/Java/libraries/Firmata<br />
Windows: c:/Program\ Files/arduino-1.x/libraries/Firmata<br />
Linux: ~/arduino-1.x/libraries/Firmata<br />
<br />
Arduino 1.5.x:<br />
Mac OSX:<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/libraries/Firmata<br />
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/libraries/Firmata<br />
<br />
Windows:<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
/Program\ Files/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata<br />
<br />
Linux:<br />
~/arduino-1.5.x/hardware/arduino/avr/libraries/Firmata<br />
~/arduino-1.5.x/hardware/arduino/sam/libraries/Firmata</nowiki><br />
<br />
Dieses Verzeichniss 'Firmata' also <b>löschen oder umbenennen</b> und die Configurable-firmata aus der [https://github.com/firmata/arduino/archive/configurable.zip zip-Datei] an die gleiche Stelle (also in ein neues Verzeichniss 'Firmata') entpacken. Nachher muss sich alles wie vorher im Verzeichniss Firmata befinden. Also so:<br />
<br />
<nowiki><br />
<Arduino-Direktory>/libraries/Firmata/Firmata.h<br />
<Arduino-Direktory>/libraries/Firmata/Firmata.cpp<br />
<Arduino-Direktory>/libraries/Firmata/Boards.h<br />
<Arduino-Direktory>/libraries/Firmata/utility/...usw...</nowiki><br />
<br />
alternativ zur Zip-datei kann man die Configurable-Firmata natürlich auch direkt aus Github heraus clonen. Dazu im Verzeichniss <Arduino-Direktory>/libraries/ folgendes eingeben:<br />
<nowiki>'git clone https://github.com/firmata/arduino.git Firmata'</nowiki><br />
anschließend ins von clone neu erstellte Verzeichnis wechseln und dort eingeben:<br />
<nowiki>'git checkout configurable'</nowiki><br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Raspberry_Pi_und_1-Wire&diff=3199Raspberry Pi und 1-Wire2013-10-21T09:21:15Z<p>Ntruchsess: /* Software */</p>
<hr />
<div>'''ACHTUNG, DIESE SEITE IST NOCH IN DER ENTWICKLUNG'''<br />
Der [[:Kategorie:Raspberry Pi|Raspberry Pi]], abgekürzt RPi ist ein Einplatinencomputer der [http://www.raspberrypi.org/ Raspberry Pi Foundation], der unter Linux läuft und über eine Vielzahl von Anschlüssen verfügt.<br />
<br />
FHEM läuft auf allen Modell des Raspberry Pi. Während [[:Kategorie:Raspberry Pi|hier]] die Installation von FHEM beschrieben wird, soll sich diese Seite nur mit dem Anschluss von 1-Wire Devices an den RPi befassen.<br />
<br />
== Hardware ==<br />
Bereits von der Hardware her bietet der RPi verschiedene Möglichkeiten zum Anschluss von 1-Wire-Devices<br />
<br />
=== USB-Port ===<br />
Über einen der USB-Ports des RPi mit entsprechendem Adapter. Hierbei sollte, wenn es sich nicht nur um wenige 1-Wire-Devices handelt, ein USB-Hub mit eigener Stromversorgung zwischengeschaltet werden. Mit USB-Extendern lässt sich dies bequem auch bis zu 20m entfernt vom RPi bewerkstelligen.<br />
<br />
Alle bekannten USB/1-Wire Adapter arbeiten mit dem RPi. Allerdings ist es möglicherweise (nur, wenn Fehler auftreten&#160;!) nötig, dafür ein Kernel-Update durchzuführen, da in manchen älteren Versionen des Linux-Kernels für den RPi Fehler im USB-Stack enthalten sind.<br />
<br />
=== COC-Modul ===<br />
Anschluss über ein COC-Modul des Herstellers [http://busware.de busware.de]. Siehe hierzu im Detail [[COC und 1-wire]]].<br />
<br />
=== RPI2-Modul ===<br />
Anschluss über ein RPI2-Modul des Herstellers [http://www.sheepwalkelectronics.co.uk/RPI2.shtml Sheepwalk Electronics]. Dieses Modul wird direkt auf den internen I2C-Bus des RPi aufgesteckt. Im Kaufzustand bietet es für den 1-Wire-Bus sowohl eine RJ45-Buchse, als auch einen Schraubklemmenanschluss. Diese sind leider beide so hoch, dass das Modul nicht mehr in das RPi-Gehäuse passt. Hier kann aber leicht abgeholfen werden (to be continued).<br />
<br />
Zur Ansteuerung ist auf dem RPi zunächst das Starten zweier Kernelmodule nötig, dazu als root ausführen<br />
<br />
<nowiki>modprobe i2c-bcm2708<br />
modprobe i2c-dev</nowiki><br />
Der automatische Start dieser beiden Module kann in der Datei /etc/modules eingetragen werden. Bei Vorhandensein des Paketes i2c-tools wird dann die korrekte Erkennung des Adapters mit dem Befehl<br />
<br />
<nowiki>i2cdetect -y 1</nowiki><br />
überprüft, der 1-Wire-Busmaster DS2482-100 sollte als I2C-Device mit der ID 0x18 gefunden werden.<br />
<br />
=== GPIO4-Port ===<br />
Anschluss direkt am GPIO-Port des RPi<br />
<br />
=== UART-Schnittstelle ===<br />
Der RPi verfügt auch über eine UART-Schnittstelle, an diese kann direkt ein Serielles 1-Wire Interface angeschlossen werden (IN VORBEREITUNG)<br />
<br />
== Software ==<br />
Die Ansteuerung des 1-Wire Bus auf dem RPi kann durch unterschiedliche Software-Systeme erfolgen. Verbreitet mit FHEM sind<br />
<br />
* '''OWX''' sowie die zugehörigen Frontendmodule OWAD, OWCOUNT, OWID, OWLCD, OWMULTI, OWSWITCH und OWTHERM. Das '''OWX'''-Modul operiert direkt auf der jeweiligen Hardware (USB bzw. Seriell) oder liest die Daten über Netzwerk (COC/CUNO/Arduino) und reicht sie an spezialisierte Frontendmodule weiter.<br />
* '''OWServer''', ein Modul, welches die vorhergehende Installation des Softwarepaketes [http://www.owfs.org"&gt;OWFS erfordert. OWFS startet einen speziellen Server, der die Kommunikation mit der Hardware übernimmt und die Daten dann an '''OWServer''' weiterleitet. Zu OWServer passt ein generisches Frontendmodul OWDevice, siehe hierzu<br />
<br />
Nachfolgend ist die Kompatibilität dieser Softwaresysteme mit den einzelnen Hardware-Möglichkeiten aufgeführt.<br />
<br />
{| class="wikitable" <br />
! Anschluss <br />
! Gerät <br />
! Unterstützte 1-Wire Devices <br />
! Besonderheit <br />
! Stromversorgung 1-Wire Bus<br />
|- <br />
| Direkt an USB <br />
| DS9490 Adapter <br />
| <br />
| <b>funktioniert nicht</b>, weil der enthaltene Chip DS2490 derzeit nur über <br /><i>libusb</i> ansteuerbar ist. Abhilfe ist in Arbeit. <br />
| &#160;??<br />
|- <br />
| Direkt an USB <br />
| USB9097 Adapter<br />
| rowspan="8" | Alle von OWX unterstützten Devices, d.h. <br /><p>DS18x20, DS1822 Temperatursensor <br /> DS2406, DS2408, DS2413 Schalter <br /> DS2423 Zähler <br />DS2438 Multisensor <br /> DS2450 4 Kanal ADC <br />LCD-Controller von [http://www.fuchs-shop.com/de/shop/6/1/13372316/ Louis Swart]<br />Alle anderen 1-Wire Devices: Nur ID<br />
</p><br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ch341.ko</i> findet man [https://sites.google.com/site/fhemarduino/file-cabinet/ch341.ko?attredirects=0&amp;d=1 hier]<br />
| Ja, 5V<br />
|- <br />
| Direkt an USB <br />
| Eigenbau, <br /> mit FT232RL und DS2480 Bus-Master <br />
| <b>funktioniert</b>, Fertiggeräte eventuell bei EBay erhältlich, <br />siehe auch [[Interfaces für 1-Wire]]<br />
| Ja, 5V<br />
|- <br />
| Direkt an USB <br />
| LinkUSBi Adapter <br />
| <b>funktioniert</b>, verwendet das FTDI Kernelmodul.<br />Achtung: Es kann zu Timing-Problemem kommen. <br /> Erhältlich z.B. [http://www.fuchs-shop.com/de/shop/17/1/13372210/ hier]<br />
| Ja, 5V an Pin2 (limited to 50mA)<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit Winchiphead CH341-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ch341.ko</i> findet man [https://sites.google.com/site/fhemarduino/file-cabinet/ch341.ko?attredirects=0&amp;d=1 hier]<br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit Prolific PL2303-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>pl2303.ko</i> findet man [https://groups.google.com/group/fhem-users/attach/1c0530caa5d8a864/pl2303.ko?part=2&amp;authuser=0 hier]<br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit FTDI RL232-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ftdi_sio.ko</i> ist auf der <br /> FritzBox vorhanden <br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Direct an USB<br />
| Arduino mit USB-Anschluss (UNO, Mega, Nano...)<br />
| rowspan="2"| 1-Wire Bus direkt am Arduino (reine Softwarelösung) oder (stabiler im Betrieb) in Verbindung mit DS2482-Busmaster (am I2C des Arduinos). Mit DS2482-100 ist 1 1-Wire-Bus (optional mit Strong-pullup über externen MosFET), mit DS2482-800 sind 8 busse (nur mit internem Strong-pullup) an 1 Arduino gleichzeitig möglich.<br />
| rowspan="2"| Ja, 3,3V oder 5V je nach Arduino-modell.<br />
|-<br />
| Über Netzwerk<br />
| Arduino mit Ethernetshield, Arduino mit ENC28J60-shield, Arduino Ethernet <br />
|-<br />
| Über Netzwerk und CUNO<br />
| CUNO <br />
| Mit OWX: Alle von OWX unterstützten Devices <br /> Ohne OWX: Nur DS18x20, DS1822 Temperatursensor <br />
| <b>funktioniert</b> mit gewissen Einschränkungen, siehe [[CUNO und 1-wire]]<br />
| Ja, aber nur 3,3 V. <br /> Kann allerdings zu 5V modifiziert werden<br />
|- <br />
| Über Netzwerk und <br /> Ethersex-Gerät<br />
| AVR-Net-IO oder ähnliches <br />
| DS18x20, DS1822 Temperatursensor <br /> DS2502 EEPROM <br />DS2450 4 Kanal ADC <br />
| <b>funktioniert</b>, siehe [[FHEM und 1-Wire]]und [[AVR-NET-IO]]<br /><br />
| &#160;??<br />
|}<br />
<br />
= Links =<br />
* [http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html Neubert &amp; Vollmar EDV-Dienstleistungen]<br />
[[Kategorie:Raspberry Pi]]<br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Raspberry_Pi_und_1-Wire&diff=3198Raspberry Pi und 1-Wire2013-10-21T09:20:17Z<p>Ntruchsess: /* Software */</p>
<hr />
<div>'''ACHTUNG, DIESE SEITE IST NOCH IN DER ENTWICKLUNG'''<br />
Der [[:Kategorie:Raspberry Pi|Raspberry Pi]], abgekürzt RPi ist ein Einplatinencomputer der [http://www.raspberrypi.org/ Raspberry Pi Foundation], der unter Linux läuft und über eine Vielzahl von Anschlüssen verfügt.<br />
<br />
FHEM läuft auf allen Modell des Raspberry Pi. Während [[:Kategorie:Raspberry Pi|hier]] die Installation von FHEM beschrieben wird, soll sich diese Seite nur mit dem Anschluss von 1-Wire Devices an den RPi befassen.<br />
<br />
== Hardware ==<br />
Bereits von der Hardware her bietet der RPi verschiedene Möglichkeiten zum Anschluss von 1-Wire-Devices<br />
<br />
=== USB-Port ===<br />
Über einen der USB-Ports des RPi mit entsprechendem Adapter. Hierbei sollte, wenn es sich nicht nur um wenige 1-Wire-Devices handelt, ein USB-Hub mit eigener Stromversorgung zwischengeschaltet werden. Mit USB-Extendern lässt sich dies bequem auch bis zu 20m entfernt vom RPi bewerkstelligen.<br />
<br />
Alle bekannten USB/1-Wire Adapter arbeiten mit dem RPi. Allerdings ist es möglicherweise (nur, wenn Fehler auftreten&#160;!) nötig, dafür ein Kernel-Update durchzuführen, da in manchen älteren Versionen des Linux-Kernels für den RPi Fehler im USB-Stack enthalten sind.<br />
<br />
=== COC-Modul ===<br />
Anschluss über ein COC-Modul des Herstellers [http://busware.de busware.de]. Siehe hierzu im Detail [[COC und 1-wire]]].<br />
<br />
=== RPI2-Modul ===<br />
Anschluss über ein RPI2-Modul des Herstellers [http://www.sheepwalkelectronics.co.uk/RPI2.shtml Sheepwalk Electronics]. Dieses Modul wird direkt auf den internen I2C-Bus des RPi aufgesteckt. Im Kaufzustand bietet es für den 1-Wire-Bus sowohl eine RJ45-Buchse, als auch einen Schraubklemmenanschluss. Diese sind leider beide so hoch, dass das Modul nicht mehr in das RPi-Gehäuse passt. Hier kann aber leicht abgeholfen werden (to be continued).<br />
<br />
Zur Ansteuerung ist auf dem RPi zunächst das Starten zweier Kernelmodule nötig, dazu als root ausführen<br />
<br />
<nowiki>modprobe i2c-bcm2708<br />
modprobe i2c-dev</nowiki><br />
Der automatische Start dieser beiden Module kann in der Datei /etc/modules eingetragen werden. Bei Vorhandensein des Paketes i2c-tools wird dann die korrekte Erkennung des Adapters mit dem Befehl<br />
<br />
<nowiki>i2cdetect -y 1</nowiki><br />
überprüft, der 1-Wire-Busmaster DS2482-100 sollte als I2C-Device mit der ID 0x18 gefunden werden.<br />
<br />
=== GPIO4-Port ===<br />
Anschluss direkt am GPIO-Port des RPi<br />
<br />
=== UART-Schnittstelle ===<br />
Der RPi verfügt auch über eine UART-Schnittstelle, an diese kann direkt ein Serielles 1-Wire Interface angeschlossen werden (IN VORBEREITUNG)<br />
<br />
== Software ==<br />
Die Ansteuerung des 1-Wire Bus auf dem RPi kann durch unterschiedliche Software-Systeme erfolgen. Verbreitet mit FHEM sind<br />
<br />
* '''OWX''' sowie die zugehörigen Frontendmodule OWAD, OWCOUNT, OWID, OWLCD, OWMULTI, OWSWITCH und OWTHERM. Das '''OWX'''-Modul operiert direkt auf der jeweiligen Hardware (USB bzw. Seriell) oder liest die Daten über Netzwerk (COC/CUNO/Arduino) und reicht sie an spezialisierte Frontendmodule weiter.<br />
* '''OWServer''', ein Modul, welches die vorhergehende Installation des Softwarepaketes [http://www.owfs.org"&gt;OWFS erfordert. OWFS startet einen speziellen Server, der die Kommunikation mit der Hardware übernimmt und die Daten dann an '''OWServer''' weiterleitet. Zu OWServer passt ein generisches Frontendmodul OWDevice, siehe hierzu<br />
<br />
Nachfolgend ist die Kompatibilität dieser Softwaresysteme mit den einzelnen Hardware-Möglichkeiten aufgeführt.<br />
<br />
{| class="wikitable" <br />
! Anschluss <br />
! Gerät <br />
! Unterstützte 1-Wire Devices <br />
! Besonderheit <br />
! Stromversorgung 1-Wire Bus<br />
|- <br />
| Direkt an USB <br />
| DS9490 Adapter <br />
| <br />
| <b>funktioniert nicht</b>, weil der enthaltene Chip DS2490 derzeit nur über <br /><i>libusb</i> ansteuerbar ist. Abhilfe ist in Arbeit. <br />
| &#160;??<br />
|- <br />
| Direkt an USB <br />
| USB9097 Adapter<br />
| rowspan="8" | Alle von OWX unterstützten Devices, d.h. <br /><p>DS18x20, DS1822 Temperatursensor <br /> DS2406, DS2408, DS2413 Schalter <br /> DS2423 Zähler <br />DS2438 Multisensor <br /> DS2450 4 Kanal ADC <br />LCD-Controller von [http://www.fuchs-shop.com/de/shop/6/1/13372316/ Louis Swart]<br />Alle anderen 1-Wire Devices: Nur ID<br />
</p><br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ch341.ko</i> findet man [https://sites.google.com/site/fhemarduino/file-cabinet/ch341.ko?attredirects=0&amp;d=1 hier]<br />
| Ja, 5V<br />
|- <br />
| Direkt an USB <br />
| Eigenbau, <br /> mit FT232RL und DS2480 Bus-Master <br />
| <b>funktioniert</b>, Fertiggeräte eventuell bei EBay erhältlich, <br />siehe auch [[Interfaces für 1-Wire]]<br />
| Ja, 5V<br />
|- <br />
| Direkt an USB <br />
| LinkUSBi Adapter <br />
| <b>funktioniert</b>, verwendet das FTDI Kernelmodul.<br />Achtung: Es kann zu Timing-Problemem kommen. <br /> Erhältlich z.B. [http://www.fuchs-shop.com/de/shop/17/1/13372210/ hier]<br />
| Ja, 5V an Pin2 (limited to 50mA)<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit Winchiphead CH341-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ch341.ko</i> findet man [https://sites.google.com/site/fhemarduino/file-cabinet/ch341.ko?attredirects=0&amp;d=1 hier]<br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit Prolific PL2303-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>pl2303.ko</i> findet man [https://groups.google.com/group/fhem-users/attach/1c0530caa5d8a864/pl2303.ko?part=2&amp;authuser=0 hier]<br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Über USB-zu-Seriell-Konverter <br /> 9- oder 25-polig <br /> mit FTDI RL232-Chip<br />
| Konverter + DS9097U-(009/S09, E25) <br />
| <b>funktioniert</b> auf der FB7390, das Kernelmodul <i>ftdi_sio.ko</i> ist auf der <br /> FritzBox vorhanden <br />
| Nur bei den 25-poligen Modellen als Standard,<br /> bei den 9-poligen Modellen<br /> externe Versorgung oder Modifikation des DS9097 nötig<br />
|- <br />
| Direct an USB<br />
| Arduino mit USB-Anschluss (UNO, Mega, Nano...)<br />
| rowspan="2"| 1-Wire Bus direkt am Arduino (reine Softwarelösung) oder (stabiler im Betrieb) in Verbindung mit DS2482-Busmaster (am I2C des Arduinos). Mit DS2482-100 ist 1 Bus (optional mit Strong-pullup über externen MosFET), mit DS2482-800 sind 8 busse (nur mit internem Strong-pullup) an 1 Arduino gleichzeitig möglich.<br />
| rowspan="2"| Ja, 3,3V oder 5V je nach Arduino-modell.<br />
|-<br />
| Über Netzwerk<br />
| Arduino mit Ethernetshield, Arduino mit ENC28J60-shield, Arduino Ethernet <br />
|-<br />
| Über Netzwerk und CUNO<br />
| CUNO <br />
| Mit OWX: Alle von OWX unterstützten Devices <br /> Ohne OWX: Nur DS18x20, DS1822 Temperatursensor <br />
| <b>funktioniert</b> mit gewissen Einschränkungen, siehe [[CUNO und 1-wire]]<br />
| Ja, aber nur 3,3 V. <br /> Kann allerdings zu 5V modifiziert werden<br />
|- <br />
| Über Netzwerk und <br /> Ethersex-Gerät<br />
| AVR-Net-IO oder ähnliches <br />
| DS18x20, DS1822 Temperatursensor <br /> DS2502 EEPROM <br />DS2450 4 Kanal ADC <br />
| <b>funktioniert</b>, siehe [[FHEM und 1-Wire]]und [[AVR-NET-IO]]<br /><br />
| &#160;??<br />
|}<br />
<br />
= Links =<br />
* [http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html Neubert &amp; Vollmar EDV-Dienstleistungen]<br />
[[Kategorie:Raspberry Pi]]<br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3197Arduino mit OneWireFirmata2013-10-21T08:59:50Z<p>Ntruchsess: /* OWX */</p>
<hr />
<div>= OneWireFirmata =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige ConfigurableFirmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata DS2482-Firmata] benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3196Arduino mit OneWireFirmata2013-10-21T08:59:03Z<p>Ntruchsess: /* OneWireFirmata */</p>
<hr />
<div>= OneWireFirmata =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige ConfigurableFirmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die DS2482-Firmata benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3195Arduino2013-10-21T08:56:40Z<p>Ntruchsess: Link zu UIPEthernet (für ENC28J60 shields) hinzugefügt</p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln). Eine Arduino-library für den ENC28J60, die richtige (persistente) TCP/IP-Verbindungen unterstützt und von der API her vollständig kompatibel zur original-Ethernetlibrary ist findet sich hier: [https://github.com/ntruchsess/arduino_uip UIPEthernet (arduino_uip)]<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino&diff=3113Arduino2013-10-19T21:22:18Z<p>Ntruchsess: Überarbeitung Ethernet mit ConfigurableFirmata</p>
<hr />
<div>== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==<br />
Mit [http://www.arduino.cc/ Arduino]-Boards lassen sich einfach und recht preisgünstig (ab ca. 15€ Stand Juli 2012) eigene Sensoren/Aktoren an FHEM anbinden.<br />
<br />
Das Board lässt sich recht einfach programmieren um Sensorwerte zu verarbeiten und diese z.B. per Ethernet an FHEM zu senden oder abfragen zu lassen. Über zahlreiche Schnittstellen (Standard: RS232, TWI/1-Wire, SPI, PWM, analog/digital-I/O, I2C) mit den entsprechenden Software-Libraries kann auf viele gängige Sensoren zugegriffen werden. Über Erweiterungsboards ("Shields") können die Anschlussmöglichkeiten ausgebaut werden. Zudem ist der Anschluss von Parallel-/Seriell-/I2C-LCD-Displays und SD-Karten möglich.<br />
<br />
Die Boards und eine Vielfalt an Sensoren/Aktoren sind über Online-Auktionen bzw. -Anbieter einfach zu bekommen. Kommunikation mit dem Arduino ist z.B. per Netzwerk/Ethernet, WLAN, 433/868MHz/2,4GHz-RF, Bluetooth, 1-Wire etc. möglich.<br />
<br />
'''Arduino mit Ethernet'''<br />
Eine einfache und sehr kompakte Lösung ist der Arduino Nano mit Ethernet-Shield. Der Nano hat je 8 nutzbare Analog- und Digital Ein-/Ausgänge über die sich beispielsweise Temperatursensoren, Relais etc. ansprechen lassen.<br />
<br />
Folgende Schritte sind zur Vorbereitung zu tun:<br />
<br />
# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen<br />
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren<br />
# Falls ENC28J60-Ethernet-Shield verwendet wird: Ethernet-Library für ENC28J60 herunterladen und in Arduino-IDE-Installation hineinkopieren (z.B. von hier: [http://trollmaker.com/article11/arduino-1-0-with-enc28j60-ethernet-shield-v1-1/], alternativ nach arduino+ENC28J60+library googeln)<br />
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&amp;d=1]<br />
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)<br />
# Sketch auf Arduino laden<br />
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen<br />
# Verbindung testen indem in einem Webbrowser &lt;arduino_ip_adresse&gt;/?cmd=set_D5_ON [http://192.168.2.44/?cmd=set_D5_ON] eingegeben wird (natürlich hier die im Sketch verwendete IP-Adresse angeben). Falls an Ausgang D5 eine Leuchtdiode o.ä. angeschlossen wurde sollte diese nun leuchten.<br />
# Wenn das geklappt hat sollte sich der Ausgang auch aus der FHEM-Kommandozeile ausschalten lassen mit { GetHttpFile('192.168.2.44:80', '/?cmd=set_D5_OFF');; } -&gt; natürlich wieder die im Sketch verwendete IP-Adresse verwenden.<br />
# Letzter Schritt wäre eine Definition in die fhem.cfg einzutragen um auch entsprechende Buttons in der FHEM-Oberfläche zu haben, ggf. wieder die verwendete IP-Adresse statt arduino:80 verwenden (für die Buttons wurde das FS20-Modul verwendet):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinobutton FS20 55d1 00<br />
attr arduinobutton room Arduino<br />
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton<br />
attr FileLog_arduinobutton room Arduino<br />
define arduinoswitchon notify FS20_55d100:on { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_ON&quot;)}<br />
attr arduinoswitchon room Arduino<br />
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile(&quot;arduino:80&quot;,&quot;/?cmd=set_D5_OFF&quot;)}<br />
attr arduinoswitchoff room Arduino<br />
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT<br />
attr weblink_arduinobutton label &quot;arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_arduinobutton room Arduino</nowiki><br />
<br />
<br />
Abfragen von Sensorwerten sind natürlich auch möglich, z.B. mit folgender Definition (Analog- und Digital-PINs werden alle fünf Minuten abgefragt und in Plots visualisiert):<br />
<br />
Auszug aus der ''fhem.cfg''<br />
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvalues $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvalues room Arduino<br />
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*<br />
attr FileLog_arduinogetsensorvalues room Arduino<br />
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT<br />
attr weblink_getsensorvalues label &quot;Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvalues room Arduino<br />
define arduinogetsensorvaluesD at +*00:05:35 {\ <br />
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\ <br />
fhem(&quot;trigger arduinogetsensorvaluesD $val&quot;);;\ <br />
}<br />
attr arduinogetsensorvaluesD room Arduino<br />
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*<br />
attr FileLog_arduinogetsensorvaluesD room Arduino<br />
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT<br />
attr weblink_getsensorvaluesD label &quot;Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}&quot;<br />
attr weblink_getsensorvaluesD room Arduino</nowiki><br />
<br />
<br />
<br />
TODO: Kommunikation via RF + Bluetooth + WLAN<br />
<br />
Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.<br />
<br />
<br />
Neben der hier beschriebenen Methode Arduinos an FHEM anzubinden gibt es noch die möglichkeit [[PanStamp]]s über das SWAP Protokoll per RF an FHEM anzubinden. Eine Firmata über SWAP Implementierung ist gerade in Arbeit.<br />
<br />
== Arduino mit Firmata ==<br />
Für den Arduino gibt es ein StandardProtokoll Firmata[https://github.com/ntruchsess/perl-firmata [6]] ist das Protokoll in perl einfach nutzbar und mit dem Modul 10_FRM.pm an FHEM adaptiert. Damit ist es möglich mit nur geringen Arduino-kenntnissen (Bedienung der Arduino-IDE ist und elektronische Kenntnisse zum Anschluss von Sensoren sind natürlich erforderlich) Messwerte aus eigenen Schaltungen über einen Arduino in FHEM einzulesen.<br />
Die in der Arduino-IDE enthaltene StandardFirmata kommuniziert über USB. Ihre Weiterentwicklung (die ConfigurableFirmata) muss man noch [https://github.com/firmata/arduino/archive/configurable.zip separat herunterladen] und damit die in der IDE enthaltene Firmata-library (komplett) ersetzen.<br />
<br />
=== Arduino IDE ===<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/HomePage http://arduino.cc/en/Guide/HomePage]). Die aktuelle Version der IDE enthält auch die StandardFirmata Firmware fertig zum Flashen auf den Arduino.<br />
Diese findet man unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'StandardFirmata'. Einfach öffnen, unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat, den Arduino über USB zu connecten, findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
Wenn man die ConfigurableFirmata installiert hat, findet sich diese genauso bei den Beispielen für Firmata.<br />
<br />
=== ConfigurableFirmata und Ethernet ===<br />
<br />
Die Unterstützung für Ethernet ist mittlerweile [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino in der Configurable-Firmata] enthalten. <br />
<br />
Im Sketch muss man unbedingt die IP-konfiguration anpassen, d.h. die IP-addresse und Port des FHEM-servers eintragen (ggf. auch eine neue mac-addresse). Falls der Speicher des Arduinos nicht reicht (insbesonders bei Verwendung eines ENC28J60-shields passt die Configurable-firmata nicht mehr mit allen Features auf einen Uno oder Nano) einfach die includes der nicht benötigten Features im sketch auskommentieren. (Wenn man Servo oder I2C-unterstützung weglassen möchte bitte vorher einmalig den sketch mit allen Features compilieren, sonst treten Fehler beim compilieren der library-klassen wg. fehlendem Include von Servo.h oder Wire.h) auf. Das gleiche gilt, wenn man in der IDE irgendwas ändert, das einen kompletten Neubuild des sketches triggert (was z.B. beim Wechsel des gewählten Boards passiert).<br />
<br />
<p>Getestet ist das ganze mit UNO R3 bzw. Mega 2560 + EthernetShield und zusätzlich mit UNO+Mega+Nano in Verbindung mit ENC28J60. Andere Arduinos als der Uno benötigen ggf. Anpassungen in der Setup/Reset Funktion.</p><br />
<p>Ein MEGA256 z.B. benutzt einen anderen Pin als SS (Slave select) zur Kommunikation mit dem Ethernetmodul. Man muss der Firmata im Setup mitteilen, welche Pins zu ignorieren sind, damit es keine Wechselwirkungen zwischen Firmata und Ethernetlibrary gibt. Das ist im Configurable.ino-sketch [https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L231 ab Zeile 231 vorbereitet] und muss (wenn man etwas anderes als ein Standard-Ethernetshield am Uno verwendet) geeignet angepasst werden (Beim Mega muss man z.B. den Pin 10 ignorieren und Pin 53 als hardcodiert auf Output stellen). Das gleiche gilt, wenn man eine andere Hardware (z.B. mit ENC28J60 anstelle des WizNet W5100 des Ethernetshields) benutzen möchte welche einen anderen Pin als CS/SS benutzt.</p><br />
<p>Die für den ENC28J80 benötigte [https://github.com/ntruchsess/arduino_uip UIPEthernet-library findet sich hier].</p><br />
<br />
=== FRM ===<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
10_FRM ist sozusagen die Basis (das IODev) für die anderen Module. Es lassen sich jeweils so viele Ein/Ausgabe Devices pro Arduino konfigurieren, wie dieser physikalisch besitzt (natürlich muss man darauf achten, dass nicht alle Arduino-pins alle Ein-/ausgabemöglichkeiten besitzen). Konfiguriert man einen Pin für einen nicht unterstützen Modus so gibt es mit der aktuellen Firmata-version (2.3) direkt einen Fehler - ältere Versionen schlucken so eine Fehlkonfiguration einfach so, der betreffende Pin funktioniert dann einfach nicht.<br />
<br />
define &lt;devicename&gt; FRM &lt;port&gt;<br />
<br />
Hier mal ein kurzer Ausschnitt aus der fhem.cfg:<br />
<br />
<hr /><br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define FIRMATA FRM /dev/ttyUSB0@57600<br />
attr FIRMATA loglevel 6<br />
attr FIRMATA sampling-interval 1000 # Wert ist in ms und 14Bit breit, also nur bis 16384 setzbar (Beschränkung des Firmata-protokolls) - gilt für alle Pins</nowiki><br />
Seit Anfang März 2013 unterstützt FRM auch über Ethernet angebundene Arduinos:<br />
<br />
<nowiki>define FIRMATA FRM &lt;port&gt; [global]</nowiki><br />
FRM macht fhem-seitig einen Serverport auf (dieser wird in der define-zeile angegeben). 'global' muss angegeben werden, damit der Serversocket an alle IP-addressen gebunden wird. (Sonst nur 'localhost', was hier wohl nicht funktionieren würde). Der Arduino verbindet aktiv zu diesem Port, sonst gilt im Prinzip alles was auch für den über USB angebunden Arduion gilt.<br />
=== FRM-Devices ===<br />
==== 20_FRM_IN.pm ====<br />
Macht einen Arduino-pin als digitalen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_IN FRM_IN 12 # definiert Arduino Pin 12 als digitalen Eingang</nowiki><br />
==== 20_FRM_OUT.pm ====<br />
Macht einen Arduino-pin als digitalen Ausgang nutzbar.<br />
<br />
<nowiki>define Firmata_OUT FRM_OUT 11 # definiert Arduino Pin 11 als digitalen Ausgang</nowiki><br />
==== 20_FRM_AD.pm ====<br />
Macht einen Arduino-pin als analogen Eingang nutzbar.<br />
<br />
<nowiki>define Firmata_ANALOG FRM_AD 17 # definiert Arduino Pin 17 als analogen Eingang</nowiki><br />
==== 20_FRM_PWM.pm ====<br />
Macht einen Arduino-pin als analogen Ausgang nutzbar. Es wird ein pulsweitenmoduliertes Signal ausgegeben.<br />
<br />
==== 20_FRM_SERVO.pm ====<br />
Erlaubt die Ansteuerung von analogen Modelbauservos (Ansteuerung über PWM) am Arduino.<br />
<br />
==== 20_FRM_I2C.pm ====<br />
Erlaubt das Auslesen von über I2C angeschlossenen ICs<br />
<br />
=== Arduino mit OneWireFirmata ===<br />
die Seite [[Arduino mit OneWireFirmata]] beschreibt, wie es möglich ist, mit einer um OneWire erweiterten Version der StandartFirmata an den Arduino angeschlossene 1-Wire Devices in FHEM einzubinden.<br />
<br />
[[Kategorie:Interface]]<br />
[[Kategorie:HOWTOS]]</div>Ntruchsesshttp://wiki.fhem.de/w/index.php?title=Arduino_mit_OneWireFirmata&diff=3112Arduino mit OneWireFirmata2013-10-19T20:52:31Z<p>Ntruchsess: Firmata-unterstützung für Ethernet und DS2482-Busmaster hinzugefügt</p>
<hr />
<div>= OneWireFirmata =<br />
<p>mit dem Modul 10_FRM.pm kann man einen Arduino als OneWire-Busmaster für das Modul 00_OWX.pm benutzen.<br />
Auf dem Arduino muss dazu eine erweiterte Version der Firmata-Firmware geladen werden. Unterstützt werden im prinzip alle Arduino-Versionen. Auf Arduinos mit nur 16kb RAM (MEGA168P) muss man die Zahl der eingebauten Features reduzieren, auf allen Arduinos mit mehr als 16kb Ram (MEGA328P aufwärts) läuft die Firmware unverändert.</p><br />
<p>Die aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man [https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata im 'configurable'-branch des Firmata repositories]. Den kompletten Branch kann man sich auch bequem [https://github.com/firmata/arduino/archive/configurable.zip als zip-Archiv herunterladen]</p><br />
<p>Wenn man die in dieser neuen Firmataversion eingebauten Features reduzieren möchte (weil man nur eine MEGA168P verwenden will und z.B. gar keine Servos ansteuern möchte), muss man nur im 'ConfigurableFirmata'-sketch die entsprechenden includes auskommentieren.</p><br />
<p>Die ConfigurableFirmata kommuniziert mit FHEM über den USB-anschluss oder Ethernet (sowohl original EthernetShield, 'Arduino Ethernet' als auch ENC28J60 basierte Boards werden unterstützt, letztere unter Verwendung der [https://github.com/ntruchsess/arduino_uip UIPEthernet-library]).</p><br />
<p>Alternativ kann man einen DS2482 als 1-Wire-Busmaster an den I2C-Bus des Arduino anschließen. Die nötige Firmata mit DS2482-Unterstützung [https://github.com/ntruchsess/arduino/tree/DS2482/examples/ConfigurableFirmata findet sich hier].</p><br />
<br />
= Arduino IDE =<br />
Zur Installation auf den Arduino wird natürlich erst mal die Arduino-IDE benötigt ([http://arduino.cc/en/Guide/Libraries http://arduino.cc/en/Guide/Libraries]))<br />
hat man das 'libraries' Verzeichnis seiner Arduino-ide-installation gefunden (unter Ubuntu z.B. unter /usr/share/arduino/libraries/), gibt es dort normalerweise schon ein Verzeichnis 'Firmata'. Falls nicht, muss dieses angelegt werden. Die in dem Verzeichniss befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im onewire-scheduler.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesammten Inhalt des Ordners 'arduino-onewire_scheduler' in das 'libraries/Firmata'-Verzeichnis (mitsammt des Unterordners 'examples'. Macht man das so, dann findet man nach einem Neustart der IDE den OneWireFirmata-sketch unter 'Datei'-&gt;'Beispiele'-&gt;'Firmata'-&gt;'OneWireSchedulerFirmata'. (Natürlich kann man den Unterordner 'OneWireSchedulerFirmata' auch in sein Sketchbook Unterverzeichnis kopieren. Solange man das Verzeichnis nicht umbenennt (so dass es nicht mehr so wie die darin befindliche 'OneWireSchedulerFirmata.ino'-datei heißt, erkennt die Arduino-IDE das Verzeichnis als korrekten Sketch und man kann es unter 'Datei'-&gt;'Sketchbook'-&gt;'OneWireSchedulerFirmata' finden.<br />
<br />
Naja - hat man es erst mal geschafft, dann muss man nur noch unter 'Tools'-&gt;'Board' den eigenen Arduino auswählen und mit dem Upload-knopf (der Rechtspfeil im Kreis oben links) den geladenen Sketch compilieren und auf das Board hochladen. Falls man unter Windows Probleme hat den Arduino über USB zu connecten findet sich hier weitere Informatation: [http://arduino.cc/en/Guide/Windows#toc2 http://arduino.cc/en/Guide/Windows#toc2]<br />
<br />
= FRM =<br />
Der Arduino wird in FHEM über das Modul 10_FRM.pm angesprochen (dazu bitte die aktuelle Development-version herunterladen ([http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz]) aus dem SVN auschecken oder per updatefhem aktualisieren).<br />
<br />
<nowiki># definiere FRM als IO-Device - Baudrate 57600 ist default in der Standardfirmata<br />
define Arduino FRM /dev/ttyUSB0@57600<br />
<br />
# definiere FRM als IO-Device über Ethernet ('global' bindet an alle IP-Addressen des Servers)<br />
define Arduino FRM <port> global</nowiki><br />
<br />
siehe dazu auch [http://fhem.de/commandref.html#FRM die commendref]<br />
= OWX =<br />
Ein im Anschluss daran definiertes [[FHEM und 1-Wire]]-device kann dann einfach einen der Arduino-pins als OneWireBusmaster nutzen. Das funktioniert an allen Pins, die digital-io unterstützen. Wenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:<br />
<br />
<nowiki>define OWX &lt;arduino-pin&gt;</nowiki><br />
Nach dem definieren des OWX-Moduls fängt dieses selbsttätig an über den Arduino-pin nach OneWire-devices zu suchen und im Raum 'OWX' automatisch anzulegen.<br />
<br />
Wenn man die DS2482-Firmata benutzt, dann findet man beim FRM-device unter 'onewire-pins' nur die I2C-Pins. Das sind z.B. bei einem Uno/Nano die Pins 18 und 19 (das entspricht den Analogpins 4 und 5). Einen der beiden muss man dann bei der Definition des OWX-Moduls angeben um die DS2482-Unterstützung zu aktivieren:<br />
<nowiki>define OWX 18</nowiki><br />
[[Kategorie:1-Wire]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Interface]]</div>Ntruchsess