FHEMWiki - Benutzerbeiträge [de]

Benutzer Diskussion:TeeVau

2015-09-24T06:05:25Z

TeeVau:

== panStamp als Fhem-WikiNews ==
Hallo TeeVau,
wenn Du mit Deinen umfangreichen Überarbeitungen an den panStamp-Seiten fertig bist, halte ich das für "würdig" als FhemWiki-News auf der Hauptseite aufgenommen zu werden. Da derzeit noch einige Baustellen/Todo-Hinweise auf den Seiten sind, habe ich das bisher noch nicht gemacht. Was meinst Du?
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 07:12, 28. Jul. 2015 (CEST)
<hr>
:Wegen mir gerne. Du hast richtig erkannt, dass noch an diversen Artikeln etwas zu tun ist. Mal mehr, mal weniger. Ich habe es auf jeden Fall im Auge und möchte das auch zu ende bringen. Ich denke allerdings, dass ich noch so 3-4 Wochen dafür brauche. Ich melde mich einfach bei dir, wenn ich fertig bin und das in die FhemWiki-News mit eingebunden werden kann. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:39, 28. Jul. 2015 (CEST)
<hr>
::Das kannst Du gerne eigenständig in die FhemWiki-News aufnehmen, wenn Du fertig bist. Ich will nur nicht, dass solche grundlegenden Erweiterungen des Wikis, die deutlich über eine neue Wiki-Seite hinausgehen, keine Beachtung finden. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:37, 28. Jul. 2015 (CEST)
<hr>
:::Erledigt :-) --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 08:05, 24. Sep. 2015 (CEST)

== <nowiki><pre> oder <nowiki> oder <code></nowiki> ==

Hallo TeeVau,

Du hast auf der Seite [[PID20 - Der PID-Regler‎]] gerade einige <nowiki><code></nowiki> Markierungen in <nowiki><pre></nowiki> geändert. Das verbessert zwar die Darstellung ... aber nur, weil die alten Tags etwas ungeschickt gesetzt waren (Leerzeilen/Zeilenumbrüche zwischen den Tags). Ich würde vorschlagen:
* für "Einzeiler": <code><nowiki>:<code>der Code/Text</code></nowiki></code> (ab Spalte 1); das wird dann gleich eingerückt und zudem am Zeilenende umgebrochen, erzeugt also keine Endloszeilen, bei denen man gezwungen wird, nach rechts zu scrollen; der Code-Text kann trotzdem kopiert werden und enthält dabei keine Zeilenumbrüche
* für längere Codepassagen das <code><nowiki><pre>Text text text... </pre></nowiki></code>
* und <code><nowiki><nowiki></nowiki></code> nur, wenn der eingeschlossene Bereich Tags / Zeichen enthält, die nicht von der Wiki-Software formatiert werden sollen (wie die Wiki-Tags in den obigen Beispielen)
--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:31, 30. Jul. 2015 (CEST)
<hr>
:Hi Peter,
:habe mich schon gefragt was der unterschied zwischen dem pre und dem code Tag ist. So wirklich was verständliches habe ich nicht gefunden. Ich selber fand den pre Tag etwas "schöner" :zum formatieren, da dieser automatisch Zeilenumbrüche vor und nach dem Tag-Bereich einfügt. Ich habe die code und pre-Tags nun in dem Artikel so angepasst wie von dir vorgeschlagen. :Grüße und ein schönes Wochenende, Tobias. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:14, 31. Jul. 2015 (CEST)
:<hr />
:: Hab den Artikel noch mal leicht überarbeitet - ich denke, so ist es kompakter aber trotzdem übersichtlicher. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 11:02, 31. Jul. 2015 (CEST)

== panShield / Weiterleitung ==

Hallo TeeVau,

Du hast die Seite panShield als Weiterleitung auf panStick angelegt ... und panShield wird nur von panStick aus verlinkt. Ich halte diese Weiterleitungsseite nicht nur für unnötig, sondern in diesem Fall sogar für verwirrend. Hilfreich wäre sie nur, wenn jemand im Wiki die Seite panShield direkt aufrufen würde (was ich für eher unwahrscheinlich halte). Benutzt man die - in diesem Fall wahrscheinlichere Suche - findet man ohnehin den "zuständigen" Abschnitt auf der panStick Seite. Könntest Du das mit dem "panShield" bitte nochmal überdenken? --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:20, 6. Aug. 2015 (CEST)

:Hi Peter, du hast Recht. Ich habe den Artikel angelegt, weil ich dachte, panShield kommt viel häufiger in den unterschiedlichen Artikeln vor. Da dachte ich, ein Link zu einem Artikel wäre sinnvoll. Gerade habe ich festgestellt, dass panShield als Wort lediglich nur 3 mal im ganzen Wiki vorkommt. Da war ich etwas zu voreilig ;-). Ich werd den Artikel löschen bzw. als Löschkandidat vorschlagen. Oder du killst ihn direkt ;-). --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)
:<hr />
::Kein Problem - erledigt (Weiterleitung ist gelöscht) --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:06, 7. Aug. 2015 (CEST)

== Schreibweise von panS* in den Artikeln ==

TeeVau, nachdem Du gerade dabei bist, den panS*-Artikeln den letzten Schliff zu geben, würdest Du dabei auch gleich die Schreibweise vereinheitlichen? Es gibt immer noch reichlich Stellen, an denen '''P'''anS... (also mit großem Anfangsbuchstaben) steht - und wenn ich das richtig verstanden habe, ist das "p" wohl eigentlich als Kleinbuchstabe gedacht. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:23, 6. Aug. 2015 (CEST)
<hr />
:Erledigt, zumindest bei allem was auch in der Kategorie panStamp ist. Ich kenne leider keine komfortable Möglichkeit das Wiki nach '''P'''anStamp abzusuchen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)
:<hr />
::Ui, da warst Du aber fleißig ... das hätte auch noch Zeit gehabt; wollte das nur anregen, nachdem Du die Seiten gerade ohnehin verstärkt angefasst hast. Einer derartigen Suche am nächsten käme wohl google mit Suchbegriff ''"PanStamp" site:www.fhemwiki.de'', was aber Groß-/Kleinschreibung wieder nicht berücksichtigt. Bleibt dann wohl nur auf einer einzelnen Seite mit der Browser-Suchfunktion. Da kann man zumindest beim Firefox angeben, dass case-sensitiv gesucht werden soll. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:06, 7. Aug. 2015 (CEST)
::<hr />
:::Erledigt :-) --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 08:04, 24. Sep. 2015 (CEST)

Benutzer Diskussion:TeeVau

2015-09-24T06:04:45Z

TeeVau: /* Schreibweise von panS* in den Artikeln */

== panStamp als Fhem-WikiNews ==
Hallo TeeVau,
wenn Du mit Deinen umfangreichen Überarbeitungen an den panStamp-Seiten fertig bist, halte ich das für "würdig" als FhemWiki-News auf der Hauptseite aufgenommen zu werden. Da derzeit noch einige Baustellen/Todo-Hinweise auf den Seiten sind, habe ich das bisher noch nicht gemacht. Was meinst Du?
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 07:12, 28. Jul. 2015 (CEST)
<hr>
:Wegen mir gerne. Du hast richtig erkannt, dass noch an diversen Artikeln etwas zu tun ist. Mal mehr, mal weniger. Ich habe es auf jeden Fall im Auge und möchte das auch zu ende bringen. Ich denke allerdings, dass ich noch so 3-4 Wochen dafür brauche. Ich melde mich einfach bei dir, wenn ich fertig bin und das in die FhemWiki-News mit eingebunden werden kann. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:39, 28. Jul. 2015 (CEST)
<hr>
::Das kannst Du gerne eigenständig in die FhemWiki-News aufnehmen, wenn Du fertig bist. Ich will nur nicht, dass solche grundlegenden Erweiterungen des Wikis, die deutlich über eine neue Wiki-Seite hinausgehen, keine Beachtung finden. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:37, 28. Jul. 2015 (CEST)

== <nowiki><pre> oder <nowiki> oder <code></nowiki> ==

Hallo TeeVau,

Du hast auf der Seite [[PID20 - Der PID-Regler‎]] gerade einige <nowiki><code></nowiki> Markierungen in <nowiki><pre></nowiki> geändert. Das verbessert zwar die Darstellung ... aber nur, weil die alten Tags etwas ungeschickt gesetzt waren (Leerzeilen/Zeilenumbrüche zwischen den Tags). Ich würde vorschlagen:
* für "Einzeiler": <code><nowiki>:<code>der Code/Text</code></nowiki></code> (ab Spalte 1); das wird dann gleich eingerückt und zudem am Zeilenende umgebrochen, erzeugt also keine Endloszeilen, bei denen man gezwungen wird, nach rechts zu scrollen; der Code-Text kann trotzdem kopiert werden und enthält dabei keine Zeilenumbrüche
* für längere Codepassagen das <code><nowiki><pre>Text text text... </pre></nowiki></code>
* und <code><nowiki><nowiki></nowiki></code> nur, wenn der eingeschlossene Bereich Tags / Zeichen enthält, die nicht von der Wiki-Software formatiert werden sollen (wie die Wiki-Tags in den obigen Beispielen)
--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:31, 30. Jul. 2015 (CEST)
<hr>
:Hi Peter,
:habe mich schon gefragt was der unterschied zwischen dem pre und dem code Tag ist. So wirklich was verständliches habe ich nicht gefunden. Ich selber fand den pre Tag etwas "schöner" :zum formatieren, da dieser automatisch Zeilenumbrüche vor und nach dem Tag-Bereich einfügt. Ich habe die code und pre-Tags nun in dem Artikel so angepasst wie von dir vorgeschlagen. :Grüße und ein schönes Wochenende, Tobias. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:14, 31. Jul. 2015 (CEST)
:<hr />
:: Hab den Artikel noch mal leicht überarbeitet - ich denke, so ist es kompakter aber trotzdem übersichtlicher. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 11:02, 31. Jul. 2015 (CEST)

== panShield / Weiterleitung ==

Hallo TeeVau,

Du hast die Seite panShield als Weiterleitung auf panStick angelegt ... und panShield wird nur von panStick aus verlinkt. Ich halte diese Weiterleitungsseite nicht nur für unnötig, sondern in diesem Fall sogar für verwirrend. Hilfreich wäre sie nur, wenn jemand im Wiki die Seite panShield direkt aufrufen würde (was ich für eher unwahrscheinlich halte). Benutzt man die - in diesem Fall wahrscheinlichere Suche - findet man ohnehin den "zuständigen" Abschnitt auf der panStick Seite. Könntest Du das mit dem "panShield" bitte nochmal überdenken? --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:20, 6. Aug. 2015 (CEST)

:Hi Peter, du hast Recht. Ich habe den Artikel angelegt, weil ich dachte, panShield kommt viel häufiger in den unterschiedlichen Artikeln vor. Da dachte ich, ein Link zu einem Artikel wäre sinnvoll. Gerade habe ich festgestellt, dass panShield als Wort lediglich nur 3 mal im ganzen Wiki vorkommt. Da war ich etwas zu voreilig ;-). Ich werd den Artikel löschen bzw. als Löschkandidat vorschlagen. Oder du killst ihn direkt ;-). --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)
:<hr />
::Kein Problem - erledigt (Weiterleitung ist gelöscht) --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:06, 7. Aug. 2015 (CEST)

== Schreibweise von panS* in den Artikeln ==

TeeVau, nachdem Du gerade dabei bist, den panS*-Artikeln den letzten Schliff zu geben, würdest Du dabei auch gleich die Schreibweise vereinheitlichen? Es gibt immer noch reichlich Stellen, an denen '''P'''anS... (also mit großem Anfangsbuchstaben) steht - und wenn ich das richtig verstanden habe, ist das "p" wohl eigentlich als Kleinbuchstabe gedacht. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:23, 6. Aug. 2015 (CEST)
<hr />
:Erledigt, zumindest bei allem was auch in der Kategorie panStamp ist. Ich kenne leider keine komfortable Möglichkeit das Wiki nach '''P'''anStamp abzusuchen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)
:<hr />
::Ui, da warst Du aber fleißig ... das hätte auch noch Zeit gehabt; wollte das nur anregen, nachdem Du die Seiten gerade ohnehin verstärkt angefasst hast. Einer derartigen Suche am nächsten käme wohl google mit Suchbegriff ''"PanStamp" site:www.fhemwiki.de'', was aber Groß-/Kleinschreibung wieder nicht berücksichtigt. Bleibt dann wohl nur auf einer einzelnen Seite mit der Browser-Suchfunktion. Da kann man zumindest beim Firefox angeben, dass case-sensitiv gesucht werden soll. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:06, 7. Aug. 2015 (CEST)
::<hr />
:::Erledigt :-) --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 08:04, 24. Sep. 2015 (CEST)

Bewässerungssteuerung

2015-09-24T06:01:10Z

TeeVau: panStamp Schreibweise angepasst und Links zu panStamp Artikel aktualisiert

<div style="float:right">
{{Infobox Modul
|ModPurpose=Kontrollinstanz der Bewässerungssteuerung
|ModType=contrib
|ModFTopic=22142
|ModForumArea=Unterstützende Dienste
|ModTechName=97_SprinkleControl.pm
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
}}
{{Infobox Modul
|ModPurpose=Spezialisiertes Modul zur Bewässerungssteuerung
|ModType=contrib
|ModFTopic=22142
|ModForumArea=Unterstützende Dienste
|ModTechName=98_Sprinkle.pm
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
}}
</div>

Diese Seite beschreibt, wie man intelligent seine Bewässerung steuern kann wenn man Bodenfeuchtesensoren installiert hat.
Weiterhin kann man eine maximale Obergrenze von parallelen Bewässerungen angeben wenn man z.B. von einem Brunnen nur einen begrenzten Mengendurchfluss hat oder das Netzteil nicht alle Ventile gleichzeitig schalten kann.

__INHALTSVERZEICHNIS__

Es wird von folgenden Komponenten ausgegangen:

* Gardena oder Hunter Magnetventile, angesprochen über einen FS20-Aktor (zb. S8M), Homematic-Aktor oder 1wireSchaltaktoren
* Bodenfeuchtesensoren, zb. FS20 BF oder andere (z. B. an einem [[AVR-NET-IO#Analoge_Eing.C3.A4nge_in_Fhem_einbinden|AVR-NET-IO]] oder funkangebunden per [[SWAP#Beispiel:_panStamp_soilmoisture_Sketch_in_FHEM_einbinden|Panstamp]])

==allgemeine Vorbereitungen==
Wird ein 2- oder 8fach 1wire Schaltaktor verwendet, so muss jedes Ventil per [[ReadingsProxy|readingsProxy]] maskiert werden.
Bei jedem FS20 Aktor muss in Fhem das Attribut ''follow-on-for-timer'' auf 1 gesetzt werden. Andernfalls bitte die Prozedur [[On-for-timer_zur%C3%BCcksetzen|"on-for-timer-offcheck"]] anlegen.

===Anlegen der Bodenfeuchtesensoren===
Für eines FS20 Sensor: FS20BF
define Bodenfeuchtesensor FS20 34f2 00
attr Bodenfeuchtesensor room Bewässerung

Für eine 1wire Version: einen analogen Sensor (zb. Vegetronix), angeschlossen an einen 4fach A/D Converter DS2450
define Bodenfeuchte OWAD DS2450 03140C000000 60
attr Bodenfeuchte model DS2450
attr Bodenfeuchte room Bewässerung
attr Bodenfeuchte userReadings VWC_A {sprintf("%.0f",(11.6552 * ReadingsVal("$name","A",0)**4 + 7.10835 * ReadingsVal("$name","A",0)**2 - 0.569557) / (ReadingsVal("$name","A",0)**2 + 1))}

Kabelgebundene Vegetronix Bodenfeuchtesensoren können per [[SWAP#Beispiel:_panStamp_soilmoisture_Sketch_in_FHEM_einbinden|Panstamp-Anbindung]] auch funkbasiert arbeiten.

===Bewässerungsventile definieren===
Falls für jedes Magnetventil ein eigenes Device existiert. Zb. bei Nutzung von eines SM8/SM4/FS20ST/HM-LC-SW4-DR
define Bewaesserung_Ventil1 FS20 2305 51
attr Bewaesserung_Ventil1 model fs20st
attr Bewaesserung_Ventil1 room Bewässerung

Wird die Bewässerungssteuerung mittels 1Wire betrieben, so verfügt 1 Device (i.d.R DS2406/DS2408/DS1413) über 2 oder 8 Ports.
An folgendem Device hängen die physischen Bewässerungsventile. Dieses muss natürlich an die eigenen Gegebenheiten angepasst werden :)
define Schalter_rechts OWSWITCH DS2408 xxxxxxxxxxxxxx
attr Schalter_rechts IODev 1wireBus
attr Schalter_rechts model DS2408
attr Schalter_rechts room Bewässerung
attr Schalter_rechts stateS .

Zusätzlich das readingsProxy-Device für den Port A
define Bewaesserung_Ventil1 readingsProxy Schalter_rechts:A
attr Bewaesserung_Ventil1 room Bewässerung
attr Bewaesserung_Ventil1 setFn {"output A $CMD"}
attr Bewaesserung_Ventil1 setList on off
attr Bewaesserung_Ventil1 valueFn {($VALUE eq "ON.")?"OFF":"ON"}
attr Bewaesserung_Ventil1 webCmd on:off

===Module bereitstellen===
Als nächstes sind die benötigten Module aus dem Fhem SVN contrib Verzeichnis in das Fhem-Verzeichnis zu kopieren:
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/97_SprinkleControl.pm 97_SprinkleControl.pm]
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/98_Sprinkle.pm 98_Sprinkle.pm]

==Definitionen==
Pro Bewässerung bzw Bewässerungsventil ist eine SprinkleInstanz zu definieren:

define MySprinkle1 Sprinkle Bewaesserung_Ventil1 Bodenfeuchte:VWC_A +00:05:00;
attr MySprinkle1 Sprinkle_OnTimeSec 30;
attr MySprinkle1 Sprinkle_SensorThreshold 55;
attr MySprinkle1 room Bewässerung;
attr MySprinkle1 webCmd Auto:An:Aus:Toggle:Disable;

Die Timerangabe kann periodisch z.B. +00:05:00 alle 5min (wie im Beispiel oben) oder einmalig am Tag z.b. 04:00:00 für 4:00 Uhr eingestellt werden. Nach Ablauf des Timers wird überprüft, ob die Bodenfeuchte im Reading ''VWC_A'' kleiner als der Wert im Attribut ''Sprinkle_SensorThreshold'' ist und gegebenenfalls ein ''on-for-timer'' Befehl auf den Aktor ''Bewaesserung_Ventil1'' abgesetzt. Die Dauer der Beregnung bzw. des on-for-timers richtet sich nach dem Attributwert ''Sprinkle_OnTimeSec''.

Es sind folgende ''Set'' Befehle möglich:
* '''Disable''' <br> Deaktivierung. Erst ein erneuter Disable-Befehl aktiviert die Instanz wieder. Während einer Deaktivierung werden keine anderen Befehle akzeptiert
* '''An''' <br> Manuelles Starten eines Bewäserungsprozesses
* '''Aus''' <br> Manuelles Stoppen eines Bewäserungsprozesses
* '''Toggle''' <br> Je nach aktuellem Zustand wird ein Bewässerungsprozess gestartet oder gestoppt
* '''Auto''' <br> Der Auto-Modus ist nur verfügbar, wenn ein Bodenfeuchtesensor angegeben ist sowie die Attribute ''Sprinkle_OnTimeSec'' und ''Sprinkle_SensorThreshold'' angegeben sind. <br>
Der erste Klick auf ''Auto'' versetzt die Instanz in den AutoModus. Jeder folgende Klick startet einen Bewässerungsprozess im AutoModus - Je nach Zustand der Bodenfeuchte wird nun bewässert oder nicht.

==weitere Spezialfälle==
Ist die Anzahl der parallelen Bewässerungsprozesse zu begrenzen, so ist eine übergeordnete Kontrollinstanz zu definieren. Beispielsweise durch einen maximalen Wasserdurchfluss den ein Brunnen bedienen kann.

define MySprinkleControl SprinkleControl;
attr MySprinkleControl SprinkleControl_MaxParallel 1;
attr MySprinkleControl room Bewässerung;

Hiermit wird maximal ein Bewässerungsprozess zugelassen. Alle folgenden werden in eine Queue eingereiht und nacheinander abgearbeitet.<br>
Die vorher definierte SprinkleInstanz ist nun noch mit der Kontrollinstanz zu verbinden.

attr MySprinkle1 SprinkleControl SprinkleControl;

Mit einer einzelnen SprinkleInstanz kann man die Auswirkung noch nicht erkennen, dazu müssen weitere SprinkleInstanzen für weitere Bewässerungsventile angelegt werden

==Links==
Forumsthread zum Modul: {{Link2Forum|Topic=22142}}

[[Kategorie:Code Snippets]]

Arduino

2015-09-24T05:56:40Z

TeeVau: panStamp Schreibweise angepasst

== Arduino zur Anbindung eigener Sensoren und Aktoren an FHEM nutzen ==

=== mit eigenem Arduino-Sketch ===
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.

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.

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.

'''Arduino mit Ethernet'''
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.

Folgende Schritte sind zur Vorbereitung zu tun:

# Arduino (bzw. Klon) mit Ethernet-Shield (z.B. mit ENC28J60 Chip) und gewünschten Sensoren kaufen
# Arduino-IDE von der [http://arduino.cc/en/Main/Software Arduino-Homepage] (für Windows, Mac OS X und Linux vorhanden) herunterladen und installieren
# 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)]
# Folgenden Beispiel-Sketch mit Arduino-IDE öffnen Arduino_FHEM.ino [https://sites.google.com/site/fhemarduino/file-cabinet/Arduino_FHEM.ino?attredirects=0&d=1]
# IP Adresse im Sketch passend zum eigenen Netzwerk ändern (steht im Sketch auf 192.168.2.44)
# Sketch auf Arduino laden
# Arduino mit 5V-USB-Netzteil ans Netzwerk anschliessen
# Verbindung testen indem in einem Webbrowser <arduino_ip_adresse>/?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.
# 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');; } -> natürlich wieder die im Sketch verwendete IP-Adresse verwenden.
# 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):

Auszug aus der ''fhem.cfg''
<nowiki>define arduinobutton FS20 55d1 00
attr arduinobutton room Arduino
define FileLog_arduinobutton FileLog /otp/fhem/log/arduinobuttonon-%Y.log arduinobutton
attr FileLog_arduinobutton room Arduino
define arduinoswitchon notify FS20_55d100:on { GetHttpFile("arduino:80","/?cmd=set_D5_ON")}
attr arduinoswitchon room Arduino
define arduinoswitchoff notify FS20_55d100:off { GetHttpFile("arduino:80","/?cmd=set_D5_OFF")}
attr arduinoswitchoff room Arduino
define weblink_arduinobutton weblink fileplot FileLog_arduinobutton:fs20:CURRENT
attr weblink_arduinobutton label "arduinobutton Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_arduinobutton room Arduino</nowiki>

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):

Auszug aus der ''fhem.cfg''
<nowiki>define arduinogetsensorvalues at +*00:05:00 {\
my $val = GetHttpFile('arduino:80', '/?cmd=get_analog_values');;\
fhem("trigger arduinogetsensorvalues $val");;\
}
attr arduinogetsensorvalues room Arduino
define FileLog_arduinogetsensorvalues FileLog /opt/fhem/log/arduinogetsensorvalues-%Y.log arduinogetsensorvalues:.*
attr FileLog_arduinogetsensorvalues room Arduino
define weblink_getsensorvalues weblink fileplot FileLog_arduinogetsensorvalues:arduino:CURRENT
attr weblink_getsensorvalues label "Arduino Sensorvalues Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_getsensorvalues room Arduino
define arduinogetsensorvaluesD at +*00:05:35 {\
my $val = GetHttpFile('arduino:80', '/?cmd=get_digital_values');;\
fhem("trigger arduinogetsensorvaluesD $val");;\
}
attr arduinogetsensorvaluesD room Arduino
define FileLog_arduinogetsensorvaluesD FileLog /opt/fhem/log/arduinogetsensorvaluesD-%Y.log arduinogetsensorvaluesD:.*
attr FileLog_arduinogetsensorvaluesD room Arduino
define weblink_getsensorvaluesD weblink fileplot FileLog_arduinogetsensorvaluesD:arduino:CURRENT
attr weblink_getsensorvaluesD label "Arduino Digital Values Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_getsensorvaluesD room Arduino</nowiki>

TODO: Kommunikation via RF + Bluetooth + WLAN

Fragen zum Thema bitte in das FHEM-Forum [http://forum.fhem.de/] posten.

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.

=== mit vorgefertigem Firmata-Sketch ===
Zur Anbindung des Arduinos mit dem Firmata-Protocol und vorgefertigtem Sketch siehe: [[Arduino_Firmata]]

[[Kategorie:Other_Components]]
[[Kategorie:Arduino]]
[[Kategorie:Interfaces]]
[[Kategorie:HOWTOS]]

HomeMatic Asksin Library

2015-09-24T05:55:23Z

TeeVau: /* Hardware */ panStamp Schreibweise angepasst

'''Asksin Library für HomeMatic'''

<ins>Bitte beachten: 1. Entwurf und noch ausbaubedürftig. Es fehlen noch einige Inhalte, Anmerkungen usw. usf.</ins>

== Sinn bzw. Ziel ==

Ziel ist es, eine Arduino-Library (lib) zu entwickeln mit der es möglich ist, eigene Hardware auf Basis eines Arduino in ein HomeMatic-Netzwerk einzubinden. Es soll mit dieser lib auch möglich sein, vorhandene HM-Aktoren mit eigener Hardware zu peeren, so dass eine Interaktion zwischen den Geräten auch ohne laufendem Fhem-Server möglich ist.

Später soll sie <ins>vielleicht</ins> auch die Grundlage sein um vorhandene HomeMatic-Hardware neu zu programmieren.

Stand 12. November 2013 wird ein HomeMatic-Dimmer abgebildet. Das wird aber nicht der einzige [http://forum.fhem.de/index.php/topic,14140.msg106875.html#msg106875 Einsatzzweck] bleiben.

== Software ==

=== Arduino ===

Da es sich um eine Arduino-Library handelt, müssen Sie sich für deren Nutzung eine entsprechende [http://arduino.cc/de/Guide/Environment Entwicklungsumgebung] einrichten. Diese gibt es für [http://arduino.cc/en/Main/Software Linux, OS X und Windows].

=== Library ===

Die Library ist seit dem 16. November 2013 in der jeweils aktuellsten Fassung im [http://forum.fhem.de/index.php/topic,14140.msg88923.html#msg88923 ersten Threadbeitrag] zu finden. Die Verwendung der Library unterliegt der [http://creativecommons.org/licenses/by-nc-sa/3.0/de/ CC-BY-NC-SA-Lizenz].

Die Library besteht aus 4 Dateien:

* ''sketch_aug05a.ino'' ist der Userbereich. Hier kann man die gerätespezifischen Funktionen programmieren.

* ''register.h'' ist der Config-Bereich. Im oberen Teil sind die Variablen für Seriennummer usw. Im unteren Teil kommen die Registerdefinitionen rein. Also die Config für List0, List1 usw.

* ''asksin.h'' (die Kopfzeilen des eigentlichen Programms) und

* ''asksin.cpp'', das ist der HM-Kommunikationsbereich. Jegliches HM-Handling soll hier statt finden und keinen Benutzereingriff benötigen.

Für die ''register.h'' gibt es ein Config-Tool in Perl (noch nicht verfügbar). Die Gerätedefinition wird in diesem Tool vorgenommen, der Output in die ''register.h'' kopiert und gut.

Da der eigentliche Sketch den Namen ''sketch_aug05a.ino'' trägt, das Verzeichnis, in dem die ''gezippten'' Dateien entpackt werden, aber nach dem Schema ''TTMMJJ-sketch_aug05a'' (TT = Tag, MM = Monat und JJ = Jahr der Veröffentlichung der Lib) benannt ist, sollten Sie den Verzeichnisnamen auf ''sketch_aug05a'' umbenennen. Ansonsten können Sie den Sketch nach dem Öffnen der Arduino-IDE nicht öffnen. Der Name des Haupt-Sketches und des Verzeichnisses müssen also gleich sein.

Weiteres, auch zur Funktionsweise, siehe [http://forum.fhem.de/index.php/topic,14140.msg102672.html#msg102672 hier] und [http://forum.fhem.de/index.php/topic,14140.msg104644.html#msg104644 hier] (Forenbeiträge).

'''Beispiel der Ausgaben:'''

Folgende Ausgabe erscheint nach dem Übertragen des Sketches ("arduinisch" für Programm) auf den Arduino im seriellen Terminal der Arduino-IDE:

Port open
CC1101_init: 12..............................................3 - ready

Available commands:
p - start pairing with master
b[0] b[n] s - send a string, b[0] is length (50 bytes max)

i[0]. i[1]. e - show eeprom content, i[0]. start address, i[1]. length
i[0]. b[1] f - write content to eeprom, i[0]. address, i[1] byte
c - clear eeprom complete, write 0 from start to end

t - gives an overview of the device configuration

$nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer

Serial: PS00000001, Model ID: 00 57 , HMID: 2F B7 4A
Paired: F1 47 12

FreeMem: 1232 byte's

Und so sieht das ganze auf Ihrem Bildschirm aus: [[Datei:2013-11-12 - Asksin-Screenshot - CutUSM1200x802_85P.jpeg|300px|thumb|center|Ansicht der Arduino IDE und des Seriellen-Ausgabefensters mit den Ausgaben der Asksin Library]]

'''Achtung:''' Um in der seriellen Konsole (Aufruf per Klick auf das Lupensymbol rechts oben im Fenster der IDE) die Ausgaben zu sehen, müssen Sie noch die Baud-Rate rechts unten im Fenster von 9.600 auf 57.600 ändern (dies ist die im Asksin-Sketch eingestellte Datenübertragungsrate). Bei einer verkehrten Baud-Rate erscheinen maximal irgendwelche Sonderzeichen.

== Hardware ==

Als Ersatz für die HomeMatic Sensoren und Aktoren kommen panStamps [http://www.panstamp.com/ (Hersteller Webseite] / [[panStamp|Wiki Artikel)]] oder [http://arduino.cc/de/Main/ArduinoBoardProMini Arduino Pro Mini] (mit 3,3 V, dazu gleich mehr) zusammen mit Transceivern aus dem Frequenzbereich 868 MHz zum Einsatz.

=== panStamp ===

Vorteile:
* Transceiver on-board
* klein
* preiswert

Nachteile:
* nicht immer/überall verfügbar

=== Arduino Pro Mini 3,3 V mit separatem Transceiver ===

Bitte achten Sie darauf, nur Arduino Pro Minis mit 3,3 V zu verwenden, da die Transceiver-Module auch nur mit dieser Spannung arbeiten. Es gehen zwar notfalls auch Arduino-Boards mit 5 Volt, aber die Spannungsversorgung und Signal-/Datenleitungen der Transceiver-Module müssen dann per "Level-Converter" angepasst werden.

Vorteile:
* verfügbar

Nachteile:
* teurer als panStamps
* Volumen größer als panStamps

==== Transceiver-Module ====

Beim [[panStamp]] ist das Modul bereits on-board. Am preiswertesten fährt man bei den Arduinos mit den Bausätzen vom HomeMatic [[HM-LC-SW1-BA-PCB]] oder [[MAX#Fensterkontakte|vom MAX! Fensterkontakt]].

Module aus dem FS20-Bereich funktionieren <ins>nicht</ins>, da diese eine andere Signalmodulation haben. RFM12-Module können ebenfalls <ins>nicht</ins> verwendet werden. Auch die "CC1101 w/ co-processor shield for Arduino" von Busware werden <ins>nicht</ins> unterstützt.

[[Datei:Tranceiver_CutGradScaleUSM800x600_85P_IMGP8367.JPG|200px|thumb|right|Transceiver - links kurz und breit, rechts lang und schmal]]

===== HomeMatic HM-LC-Sw1-BA-PCB =====

Kurzes, aber breites Transceiver-Modul. Die '''1'''-reihigen Löt-Kontakte haben allerdings einen Abstand von 2 mm, was bei der Anbringung von Pfostenleisten berücksichtigt werden muss (üblicher sind 2,54 mm).

Siehe nebenstehendes Foto links.

===== MAX! Fensterkontakt =====

Längeres aber schmaleres Transceiver-Modul. Die '''2'''-reihigen Kontakte haben das üblichere Raster von 2,54 mm, jedoch sind schon einige Löterfahrungen erforderlich um das Modul sauber zu entlöten.

Siehe nebenstehendes Foto rechts.

===== CC1101 =====

Die CC1101-Module sind regulär für den 433MHz Bereich gedacht, können aber auf 868 MHz umgestellt werden. Dies geht allerdings zu Lasten der Sende- und Empfangsleistung.

==== Verbindung Transceiver mit Arduino Pro Mini ====

Zur Zeit (November 2013) gelten folgende Pin-Belegungen:

===== Breites Modul =====

[[Datei:2013-11-13 - Fritzing-Screenshot - breit - CutUSM_800x600_85P.jpeg|200px|thumb|right|Verkabelung des breiten Transceiver-Moduls mit einem Arduino Pro Mini 3,3 V]]

TRX868 - Pins von links nach rechts (metallisches
Abschirmblech - im Schema gelb - sichtbar, Antenne oben)

1 2 3 4 5 6 7 8
2 mm Raster (!)

Arduino
TRX868 ProMini 3.3V! Beschreibung Farbe
=================================================
1 11 SPI Mosi weiß
2 13 SPI SCK violett
3 12 SPI MISO grün
4 (n.c.) (3) PWM -LED-GND ---
5 2 GDO0 gelb
6 10 SPI chip select blau
7 GND GND schwarz
8 VCC 3.3V rot
=================================================

TRX868-Pin 4 ist GDO2 und war anfangs mit Pin 3 des Arduino verbunden. GDO2 wird nicht mehr verwendet und Pin 3 (PWM) kann nun anderweitig genutzt werden.

===== Schmales Modul =====

[[Datei:2013-11-13 - Fritzing-Screenshot - schmal -CutUSM_800x601_85P.jpeg|200px|thumb|right|Verkabelung des schmalen Transceiver-Moduls mit einem Arduino Pro Mini 3,3 V]]

TRX868 - Pins von links nach rechts (metallisches
Abschirmblech - im Schema gelb - sichtbar, Antenne oben)

1 3 5 7
2 4 6 8
2,54 mm Raster

Arduino
TRX868 ProMini 3.3V! Beschreibung Farbe
=================================================
1 VCC 3.3V
2 GND GND
3 11 SPI Mosi
4 13 SPI SCK
5 12 SPI MISO
6 (n.c.) (3) -- frei --
7 2 GD00
8 10 SPI chip select
=================================================

Der Arduino-Pin 3 (PWM) ist nun frei für die eigene Verwendung und kann z.B. als GND für eine zu dimmende LED eingesetzt werden

< Schema folgt >

== Links ==

[http://forum.fhem.de/index.php/topic,14140.0.html Foren-Thread]<br />
[http://www.elv.de/max-fensterkontakt-arr.html MAX! Fensterkontakt Bausatz]]<br />
[http://www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html HomeMatic Schaltaktor Bausatz]<br />

[[Kategorie:HomeMatic_Components]]

PanStamp Umweltsensor

2015-09-24T05:49:35Z

TeeVau:

{{SEITENTITEL:panStamp Umweltsensor}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sensor
|HWCategory=HardwareMods
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V
|HWPowerConsumption=
|HWPoweredBy=Battery AA
|HWSize=48.5 x 100 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=für diesen Sketch: [http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
|HWManufacturer=panStamp
}}

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Dieser bildet das Herzstück des Umweltsensors

Weiterführende Information zu panStamps und den grundlegenden Modulen um sie mit Fhem zu integrieren finden sich im zugehörigen [[panStamp|Wiki Artikel]].

== Beschreibung ==

Der auf dem panStamp (Arduino328p) basierende Umweltsensor hat die folgenden Eigenschaften:
* 4x Analogeingänge
* Helligkeitserfassung per TSL2561
* Temperatur- und Luftfeuchtemessung mit DHT22
* Luftdruck- und Temperaturmessung per BMP180
* Anschluss von 1..n 1wire Temperatursensoren DS18B20
* Messung der Batteriespannung
* Messung der Solarspannung
* Anpassbare MessFrequenz für Tag und Nacht
* passt alles in ein ELV IP65 (Nr: G203/G203C) Gehäuse und ist damit geeignet für den Außeneinsatz

Alle benötigten Dateien sind [https://tulpemd.traffic-eye.de/owncloud/public.php?service=files&t=b0bf5979833bc2ca01c8a7bc9cd11335 hier] zu finden:
* Sketch
* EnvironmentSensor.xml
* Target3001 Dateien

Unbestückte Platinen können beim [http://forum.fhem.de/index.php?action=profile;u=118 Ersteller], falls vorrätig, angefragt und erworben werden.

== Schaltplan und Bauteilliste ==
[[Datei:Arduino_Umweltsensor_v1.0_Schaltplan.jpg|200px|thumb|right|Schaltplan]]
[[Datei:Arduino_Umweltsensor_v1.0_Platine_Oben.jpg|200px|thumb|right|Platinenlayout Oberseite]]
[[Datei:Arduino_Umweltsensor_v1.0_Platine_Unten.jpg|200px|thumb|right|Platinenlayout Unterseite]]
[[Datei:Arduino_Umweltsensor_v1.0_Fertig.jpg|200px|thumb|right|fertiger Aufbau]]
[[Datei:Arduino_Umweltsensor_v1.0_Plot1.jpg|200px|thumb|right|Plot Nr 1]]

Bauteilliste:

{| class="wikitable"
! Bauteil
! Bezeichnung
! Shop
! BauteilNr
|-
| L1
| LQH4C Speicherdrossel
| Mouser.com
Reichelt

Reichelt
| 81-LQH43CN100K03L
L-1212FPS 10µ

L-1616FPS 10µ
|-
| C1, C2
| Keramikkondensator Typ:X7R 10uf
| Reichelt
Mouser.com
| X5R-G0805 10/16
810-CGJ4J1X7R0J106AC
|-
| C3
| Keramikkondensator Typ:X7R 1uF
| Reichelt
Mouser.com
| X7R-G0805 1,0/16
810-C2012X5R1C105K-2
|-
| C4, C7
| Keramikkondensator Typ:X7R 100nF
| Reichelt
Mouser.com
| X7R-G0805 100N
581-0805YD104KAT2A
|-
| IC1
| MAX1724 Schaltregler 1.5uA IQ Step-Up DC/DC Converter
| Mouser.com
tme.eu

Ebay: G&C Supermarket
| MAX1724EZK33T
MAX1724EZK33+T

MAX1724
|-
| K1,K2,K3,K4,K5
| Anreihklemme 3,5mm 3Pol
| IT-WNS
| AK-3.5-3-GY
|-
| R1
| Widerstandsnetzwerk 100K
| Reichelt
| SIL 5-4 100K
|-
| R2
| SMD Widerstand 1k
| Reichelt
Mouser.com
| SMD-0805 1K
71-CRCW0805-1.0K-E3
|-
| R3
| SMD Widerstand 10k
| Reichelt
Mouser.com
| SMD-0805 10K
71-CRCW0805-10K-E3
|-
| R4
| SMD Widerstand 4k7
| Reichelt
Mouser.com
| SMD-0805 4,70K
71-CRCW0805-4.7K-E3
|-
| J1
| Stiftleiste 1x5Pol
| Reichelt
| MPE 087-1-005
|-
| D1
| LED 3mm LowCurrent 2mA
| Reichelt
| LED 3MM 2MA GN
|-
| TASTER
| Reset TASTER 9314
| Reichelt
| TASTER 9314
|-
| Batteriehalter
| Batteriehalter 1x AA Mignon(Akku)
| Reichelt
| HALTER 1XAAP
|-
| K7
| Anschluss Solarpanel (VERT PCB 2Pin TIN FRICTION LOCK)
| Reichelt
Mouser
| zb. MPE 087-1-002
538-22-23-2021
|-
| D2
| BAV70 Schaltdiode SMD, SOT-23, 250V, 1A
| Reichelt
| BAV 70 SMD
|-
| T1
| BCW 61 Transistor SMD PNP SOT-23 32V 0,1A 0,25W
| Reichelt
| BCW 61C SMD
|-
| T2
| BC847 Transistor SMD NPN SOT-23 45V 0,1A 0,25W
| Reichelt
| BC 847B SMD
|-
| T3
| BSS138 Transistor SMD N-FET SOT-23 50V 0,22A
| Reichelt
| BSS 138 SMD
|-
| IC
| panStamp AVR
| panstamp.com
| panStamp AVR
|-
| --
| Female Header 2,54 mm, 1X16, straight
| Reichelt
| MPE 094-1-016
|-
| --
| DHT22
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=273096 DHT22]
|-
| --
| BMP180
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=277617 BMP180]
|-
| --
| TSL2561
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=276001 TSL2561]
|-
| --
| Dallas DS18B20
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=104763 DS18B20]
|}

== Hinweise zum Aufbau==
Soll kein 1Wire genutzt werden, so wird empfohlen den R4 (4k7) nicht zu bestücken da dieser Pullup bei jedem Messvorgang bei denen 1wire/DHT22/BMP180 oder TSL2561 involviert sind zusätzlich die Batterie belasten.

Soll kein DHT22 genutzt werden, so wird empfohlen R3 und C7 (4k7) nicht zu bestücken da beide bei jedem Messvorgang bei denen 1wire/DHT22/BMP180 oder TSL2561 involviert sind zusätzlich die Batterie belasten.

== Hinweise zum Betrieb mit FHEM ==
===Configuration===
Nach upload des Sketches auf den Panstamp ist zuerst die korrekte Kennung über das Register 09 sowie der gewünschte Sendezyklus über das Register 0A zu setzen (siehe [[panStamp#Neue_panStamps_in_Betrieb_nehmen|Inbetriebname im Wiki Artikel]] zum den panStamps).
Anschließend ist die Konfiguration mittels Register 0B zu setzen:
{| class="wikitable"
! Bezeichnung
! Länge
! Position
! Beschreibung
|-
| Sync Intervall
| 2 Byte
| 0+1
| Intervall in Sekunden zur Synronisation mit der Zentrale. 0000 ist deaktiviert
|-
| SendDelay
| 2 Byte
| 2+3
| Sendeverzögerung in ms zwischen dem Senden von mehreren Registern. Soll Sendeüberlagerung bei Nutzung von Repeatern minimieren
|-
| Altitude
| 2 Byte
| 4+5
| Angabe des Standortes des Sensors in Höhenmetern ünN. Notwendig zur Berechnung von SeaLevelPressure
|-
| Day/NichtShift Type
| 1 Byte
| 6
| Type:1 -> Nutzung des Solarwertes ; Type:2 -> Nutzung der Helligkeit vom TSL2561
|-
| Day/NigthShift Threshold
| 3 Byte
| 7+8+9
| Schwellwert bei dem Day/Night umgeschaltet werden soll, Type 1: in mV ;Type 2: in Lum
|-
| Day/NightShift TX Intervall
| 2 Byte
| 10+11
| Intervall in Sekunden im Tagesrhythmus, Das "normale" TX_INTERVAL (Register 0A) ist dann NachtRhythmus
|-
| HAS_Analog4
| 1Bit
| 12.0
| Die analoge Spannung am A3 wird gemessen. VCC liegt an D3 an.
|-
| HAS_Analog3
| 1Bit
| 12.1
| Die analoge Spannung am A2 wird gemessen. VCC liegt an D3 an.
|-
| HAS_Analog2
| 1Bit
| 12.2
| Die analoge Spannung am A1 wird gemessen. VCC liegt an D6 an.
|-
| HAS_Analog1
| 1Bit
| 12.3
| Die analoge Spannung am A0 wird gemessen. VCC liegt an D7 an.
|-
| HAS_DS18B20
| 1Bit
| 13.0
| Ein oder mehrere DS18B20 sind angeschlossen und sollen ausgelesen werden
|-
| HAS_DHT22
| 1Bit
| 13.1
| Ein DHT22 ist angeschlossen und soll ausgelesen werden
|-
| HAS_TSL2561
| 1Bit
| 13.2
| Ein Hellihkeitssensor TSL2561 ist angeschlossen und soll ausgelesen werden.
|-
| HAS_BMP180
| 1Bit
| 13.3
| Ein Luftdrucksensor BMP180 ist angeschlossen und soll ausgelesen werden.
|-
| Transmit BatVol
| 1Bit
| 14.0
| Die aktuelle Batteriespannung soll übermittelt werden.
|-
| Transmit SolarVol
| 1Bit
| 14.1
| Die aktuelle Spannung von der Solarzelle soll übermittelt werden.
|-
| Enable Debug LED
| 1Bit
| 14.2
| Aktivierung der LED als Debug Ausgabe zur Initialisierung und zu jedem Sendezeitpunkt
|-
| Enable Day/NightShift
| 1Bit
| 14.3
| Die Sendeintervalle für Tag und Nachtrhythmus sollen aktiviert werden
|}

===Nutzung von unterschiedlichen Sendeintervallen bei Tag/Nacht===
Soll das Sendeintervall tagsüber anders sein als in der Nacht, so ist dies über die Day/NightShift Funktionen einzustellen. Beispielsweise soll der Umweltsensor für eine Rolladensteuerung benutzt werden. Dann ist es besser die Messung minütlich durchzuführen. In der Nacht wäre dann 10-minütlich ausreichend.
Über den ConfigParameter "Day/NichtShift Type" kann angegeben werden, auf welcher Grundlage die Tag/Nachterkennung stattfinden soll. Entweder über eine Solarspannung die normalerweise nur am Tage vorliegt, oder über eine Helligkeitsmessung des TSL2561 falls einer bestückt ist. In beiden Fällen wird über "Day/NichtShift Threshold" der Schwellwert angegeben an welchem Punkt die Tag/Nacht Grenze gesetzt werden soll. Bei Nutzung von Solarspannung ist hier der Schwellwert in mV anzugeben (zb. 500 für 0.5V) oder in Lumen als gemsssener Lumenwert des TSL2561. Hier sollten man vorher die Messerte der jeweiligen Sensoren über einige Tage genau beobachten um einen geeigneten Wert zu finden.
Durch die angabe des Intervalls mit "Day/NichtShift TX Intervall" wird das Sendeintervall für den Tagrhythmus angegeben. Das Standardsendeintervall aus dem Register 0A ist das für den Nachtrhythmus verantwortlich.

===Setzen der Konfiguration===
Ein Register ist als Hex-Wert zu setzen. Folgende Tabelle zeigt eine exemplarische Konfiguration:
{| class="wikitable"
! Bezeichnung
! Wert
! Binär Wert
! Hex Wert
|-
| Sync Intervall
| 12h -> 43200s
|
| A8C0
|-
| SendDelay
| 100ms
|
| 0064
|-
| Altitude
| 53m
|
| 0035
|-
| Day/NichtShift Type
| 1
|
| 01
|-
| Day/NigthShift Threshold
| 1000mV
|
| 0003E8
|-
| Day/NightShift TX Intervall
| 60s
|
| 003C
|-
| HAS_Analog4
| nein
| 0
|
|-
| HAS_Analog3
| nein
| 0
|
|-
| HAS_Analog2
| ja
| 1
|
|-
| HAS_Analog1
| ja
| 1
|
|-
|
|
| 00001100
| 0C
|-
| HAS_DS18B20
| ja
| 1
|
|-
| HAS_DHT22
| nein
| 0
|
|-
| HAS_TSL2561
| nein
| 0
|
|-
| HAS_BMP180
| nein
| 1
|
|-
|
|
| 00001001
| 09
|-
| Transmit BatVol
| ja
| 1
|
|-
| Transmit SolarVol
| ja
| 1
|
|-
| Enable Debug LED
| nein
| 0
|
|-
| Enable Day/NightShift
| ja
| 1
|
|-
|
|
| 00001011
| 0B
|}

In obigem Fall ist das Konfigurationsregister wie folgt aufgebaut: ''A8C0 0064 0035 01 0003E8 003C 0C 09 0B''
Aufgrunddessen wird die Konfiguration folgendermaßen gesetzt:
set <MySwapDevice> regSet 0B A8C000640035010003E8003C0C090B

Es ist auch möglich die einzelnen Endpoints unabhängig voneinander zu setzen. z.B.:
set <MySwapDevice> regSet 0B.17 1

===Syncronisation mit der Zentrale===
Jede Syncronisation kostet zusätzlichen Strom und belastet damit die Batterie. Allerdings benötigt man eine Synronisation um Befehle von der Zentrale entgegenzunehmen. Z.B. für eine neue Konfiguration. Im Normalfall benötigt man keine automatisiert Synronisation da mit Druck auf den Reset-Button ebenfalls eine Synronisation erfolgt.
Hat man aber ein Szenario vorliegen, beidem FHEM automatisiert die Konfiguration ändern soll, so ist ein SyncIntervall notwendig. Um die automatisierte Syncronisation abzuschalten ist als Wert 0000 zu setzen.

===Nutzung von mehreren DS18B20===
Die Messwerte für die 1wire Temperatursensoren werden in einem einzelnen Register 0E übertragen. Das bedeutet, falls mehrere DS18B20 am Bus angeschossen sind, überschreiben diese sich gegenseitig. Dieses Verhalten ist aber vom Author so gewollt um eine gewissen Generik zu gewährleisten.
Um nun auf die einzelnen Messerte in FHEM zugriff zu bekommen, schafft folgendes UserReading Abhilfe:

attr <MySwapDevice> userReadings Temperature_Sun:0E.1-1wire_Address:.*28D6CF710400009C {SWAP_1wire($name)}
Die im Beispiel verwendete 1Wire ID ist natürlich an die eigenen Gegebenheiten anzupassen. Pro angeschlossenem DS18B20 ist ein weiteres userReading anzulegen.

Anschließend ist folgende Prozedur in 99_MyUtils.pm zu ergänzen:
sub SWAP_1wire($) {
my ($SwapDevice) = @_;
return (hex(ReadingsVal($SwapDevice, "0E.0-1wire_Temperature", ""))*0.01) - 50;
}
Nun wird pro eindeutiger 1Wire-ID ein neues Reading erzeugt welches den Messwert enthält.

== Weitere Hinweise ==
Keine.

== Links ==
* [https://tulpemd.traffic-eye.de/owncloud/public.php?service=files&t=b0bf5979833bc2ca01c8a7bc9cd11335 Alle benötigten Dateien auf der Seite des Authors]
* [https://www.tindie.com/products/miceuz/i2c-soil-moisture-sensor/ Bodenfeuchtesensor auf I2C-Basis]
* [http://vegetronix.com/Products/VH400/ Vegetronix Bodenfeuchtesensor]
* [http://www.amazon.com/Arduino-compatible-Sensitivity-Moisture-Sensor/dp/B00AFCNR3U LowCost Arduino compatible High Sensitivity Moisture Sensor]

[[Kategorie:panStamp]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Lichtsensoren]]

PanStamp RGBWW Board mit DMX und IR

2015-09-24T05:48:48Z

TeeVau:

{{Baustelle}}
{{SEITENTITEL:panStamp RGBWW Board mit DMX und IR}}

{{Infobox Hardware
|Bild=panStampRGBv1.0.jpg
|Bildbeschreibung=RGBWW Board
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz
|HWChannels=
|HWVoltage=12V
|HWPowerConsumption=
|HWPoweredBy=Netzteil
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#SWAP_0000002200000003 35_SWAP_0000002200000003.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}
[[panStamp RGBWW Board mit DMX und IR]] unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z.B. als Unterputz Touchpanel) und FHEM bedienen.
Es ist eine Hard- und Softwareentwicklung auf Basis von panStamp Modulen und verwendet zusätzlich das FHEM Modul [[SWAP 0000002200000003]] als 3. Ebene

Der Funktionsumfang wird in diesem {{Link2Forum|Topic=12487|Message=81923|LinkText=Forenthread}} vorgestellt. Die Hardware für das Board wird {{Link2Forum|Topic=13890|LinkText=hier}} im FHEM Forum vorgestellt und ein Prototyp ist {{Link2Forum|Topic=12487|Message=85777|LinkText=hier}} zu sehen.

== Hardware ==
Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

=== Kompatibilität RBG-Board mit NRG-panStamps ===
Mit dem hier beschriebenen Sketch ist das Board nur mit den panStamp AVRs kompatibel. Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht GND wie beim AVR. Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s einen „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0. {{Link2Forum|Topic=13890 |Message=247069}}

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.

=== Eigenschaften des fade TBC ===
Der wichtige Punkt ist das das RGBWW-Board Farbübergänge autonom macht und FHEM nur den Trigger zum starten und Rückmeldung über den Status gibt. d.h. wie ruckelfrei das faden ist hängt nicht von äußeren Bedingungen wie Funklast, FHEM timing oder FHEM Auslastung ab. Im Board gibt es 15 '''Register''' die jeweils eine Farbe und eine Anzeigedauer enthalten. Diese werden (ein mal) von FHEM aus programmiert. Zum starten wird dann nur noch das Anfangs- und das Endregister gesendet und das Board überblendet zwischen allen Farben der Register zwischen Anfang und Ende in der eingestellten Zeit.
Die eigentliche Einschränkung ist das die aktuelle AVR Version der panstamps ''nur'' 8bit pwm kann (jedenfalls wenn es 3 oder mehr Kanäle sein sollen und die Hardware PWM genutzt wird). Wenn dir diese 256 Stufen pro Grundfarbe reichen ist es absolut Ruckelfrei. d.h. es gibt keinen zeitlichen Jitter. Ob dir die Anzahl der Helligkeitsstufen reicht hängt ein wenig von den LEDs selber ab und davon zwischen welchen Farben du konkret wechselst. Im dunklen Bereich wirst du vermutlich stufen sehen (also beim aufblenden von dunkel zu hell). wenn du zwischen zwei hellen Farben (z.b. von rot nach grün) blendest wirst du keine stufen sehen. {{Link2Forum|Topic=13890|Message=106644}}

== Software ==
Eine Übersicht über die derzeit vorhandene Funktionalität des [[SWAP_0000002200000003|Fhem Moduls]] und panStamp Sketches (Stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
was geht:
* Bis zu vier LED Kanäle (je nach Kombination von ir und soft PWM)
* Ir senden
* Ir empfangen
* Messen ob die LED Versorgungsspannung an ist
* Helligkeit eines an Pin <code>A2</code> angeschlossenen Helligkeitssensors (LDR)
* Konfiguration der DMX Basisadresse über das SWAP Register <code>0x12</code>
* Optional soft on auf letzten RGBW Wert
* Alles was auch vorher schon ging: dimmen, faden, ir fernbedienungen anlernen, ...

wichtig zu wissen:
* Wenn ir aktiv ist und kein soft PWM lässt sich der 4. Kanal nur ein und aus schalten
* Wenn ir aktiv ist muss soft PWM aktiv sein um den 4. Kanal auch zu dimmen
* Es wird nur ein zusätzlicher LED Kanal tatsächlich schon unterstützt. Der fünfte kommt noch
* Bei ir senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die Anderen sind aber einfach zu ergänzen
* Beim ir senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein

was noch kommt:
* besseres soft PWM
* mehr Konfiguration bezüglich default verhalten. ramp zeiten, delays, ...
* hsv Farbmodell um besser zu faden und vor allem um den Weißanteil automatisch auf die weißen LEDs zu legen
* die virtuellen channel
* fhem kompatibles ir senden
* sofortiges senden von Helligkeit und LED Spannung bei Änderung
* andere ir lib mit sehr viel besserer Geräte Unterstützung

wie gehabt muss alles über <code>config.h</code> mit Compilerschalter konfiguriert werden.

=== Arduino IDE 1.5 / 1.6 einrichten ===
Mit der Arduino IDE 1.5.x gab es zusätzlich eine [http://www.panstamp.com/news/panstamp-is-now-fully-arduino-1-5-enabled/ grundlegende Umstellungen der Arduino SWAP Library], für die der derzeitige Sketch [r4716] angepasst werden muss. Der Sketch ist nur kompatibel zur alten SWAP Library, die unter [[panStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0 installiert]] werden muss (Stand 01.05.2015).

=== Arduino IDE 1.0 einrichten ===
Zum Flashen der panStamps wird die [[panStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0.x benötigt]]. Für den RGBWW-Sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin <code>C:\Users\<username>\Documents\Arduino\libraries</code>. Am Ende der ganzen Aktion sollten sich in diesem Unterordner 3 neue Unterordner befinden: <code>IRremote, DMXSerial und panstamp</code>.

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von <code>libraries</code>.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von <code>libraries</code>. Weitere Informationen zur Verwendung von Arduino Librarys finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Librarys richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter dem Menüpunkt <code>Sketch/Library importieren</code> die 3 weiteren Punkte unten unter <code>beigetragen</code> auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino <code>libraries</code> Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter Sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Für das kompilieren mit INO siehe [[panStamp_Programmierung#INO|hier]].

=== Link zum Sketch ===
Die aktuelle Version des RGBWW-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge]. {{Link2Forum|Topic=13890 |Message=201391}}
Dieser muss in <code>Arduino\libraries\panstamp\examples\sketches</code> entpackt und die <code>rbgdriver.ino</code> gestartet werden. In der Arduino IDE sollte unter Tools->Board "Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega328" eingestellt sein. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert kann man in der IDE auch direkt panStamp als Plattform auswählen.

==== Kompillierte hex version ====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=121619}}

==== HEX-File ohne IR und DMX ====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=201955}}

=== Compilerschalter ===
Welche Features der sketch bietet lässt sich im <code>config.h</code> file durch ein- oder auskommentieren der <code>#define ENABLE_...</code> Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}}

==== #define ENABLE_DMX ====
#define ENABLE_DMX
Ermöglicht die Nutzung eines DMX RGB Einstellers zur Steuerung der RGB LEDs

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei <code>DMXSerial.h</code> die Zeile
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
in
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
abgeändert werden muss.

==== #define HAS_SENSOR ====
#define HAS_SENSOR
Ermöglicht die Nutzung eines DHT22 Sensors zur Auswertung von Temperatur und Luftfeuchtigkeit
Dafür sollten diese Konfigurationszeilen auskommentiert sein:
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;

In der <code>IRremote.cpp</code> Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>

sowie die <code>Irremote.h</code> Datei unter <code>Public:</code> um die Zeile
void disableIRIn();
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an Pin <code>A2</code> des panStamps angeschlossen werden.
Ein Beispiel für die Umrechnung der userReading für Spannung Temp etc. ist hier beschrieben: {{Link2Forum|Topic=12487 |Message=76489}}

=== Zusammenhänge der Konfiguration ===
Die Zusammenhänge der Konfiguration sind hier beschrieben {{Link2Forum|Topic=13890 |Message=175181}}

=== 4. und 5. LED Kanal TBC ===
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936

=== Alternativer Fade per Patch ===
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.

== IR Schnittstelle TBC ==
=== IR TBC ===
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267

=== IR-Belegung Panstamp RGB-Board TBC ===
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153

=== Ircluster TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331

=== Irgate TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278

== DMX Schnittstelle ==
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge

[[Kategorie:panStamp]]

Vorlage:FHEMWiki News

2015-09-24T05:45:31Z

TeeVau:

{|
{{News|24.09.2015|Umfangreiche Überarbeitung der Wiki Artikel über [[:Kategorie:panStamp|panStamp Hardware und Software]]}}
{{News|11.09.2015|Neues Modul [[AMAD]] (Steuern und Informationsanzeige von Android-Geräten) wird per update verteilt}}
{{News|15.06.2015|Neues Modul [[yowsup]] (WhatsApp Unterstützung) wird per update verteilt}}
{{News|03.04.2015|Neues Geräte-Modul [[JawboneUp]] wird per update verteilt}}
{{News|23.03.2015|Neue Geräte-Module [[Modbus]], [[ModbusAttr]] und [[Modbus#Writing_modules_for_devices_using_this_module_as_a_library|ModbusSET]] werden per update verteilt}}
{{News|10.02.2015|FHEMWiki ist auf einen neuen Server umgezogen und [[FHEMWiki:Interna#Offene_Probleme|Aktualisierung der MediaWiki-Software]]}}
{{News|31.01.2015|Neues Geräte-Modul [[Pushbullet]] wird per update verteilt}}
{{News|14.01.2015|Neues Hilfs-Modul [[CALVIEW]] wird per update verteilt}}
{{News|08.01.2015|Neues Geräte-Modul [[Buderus_Web_Gateway|km200]] zur Anbindung eines Buderus Web-Gateways wird per update verteilt}}
{{News|18.12.2014|Neues Geräte-Modul [[SONOS]] wird per update verteilt}}
{{News|15.12.2014|Überarbeitetes und erweitertes Geräte-Modul [[HTTPMOD]] wird per update verteilt}}
{{News|10.12.2014|Neues Geräte-Modul [[Vitotronic_200_(Viessmann_Heizungssteuerung)|VCONTROL]] zur Anbindung einer Viessmann Heizung wird per update verteilt}}
{{News|17.11.2014|Neues Hilfs-Modul [[logProxy]] wird per update verteilt}}
{{News|09.11.2014|Fhem Version 5.6 wurde veröffentlicht}}
{{News|27.10.2014|Neues Geräte-Modul [[harmony]] zur Fhem-Anbindung Logitech Harmony Hub basierter Fernbedienungen wird per update verteilt}}
{{News|25.10.2014|Neues Geräte-Modul [[KostalPiko|KOSTALPIKO]] wird per update verteilt}}
{{News|24.10.2014|Neues Hilfs-Modul [[HourCounter]] wird per update verteilt}}
{{News|06.09.2014|Neues Hilfs-Modul [[CustomReadings]] per update verteilt}}
{{News|19.08.2014|Neues Hilfs-Modul [[DOIF]] wird per update verteilt}}
{{News|19.08.2014|Der Befehl [[update]] wurde überarbeitet: {{Link2Forum|Topic=26311}} }}
{{News|13.08.2014|Zusätzliche Domäne fhem.org aktiviert: {{Link2Forum|Topic=26113}} }}
{{News|02.03.2014|[[UserTreffenSuedMaerz2014|FHEM User Treffen]] in Karlsruhe am 22. März 2014 }}
{{News|29.09.2013|Fhem Version 5.5 wurde veröffentlicht}}
{{News|11.05.2013|Die meisten Daten aus dem FhemWiki sind wieder hergestellt.}}
{{News|04.05.2013|FhemWiki wird neu aufgebaut.}}
{{News|04.05.2013|FhemWiki Update zu [[Special:Version|MediaWiki 1.20.5]].}}
|}

Vorlage:FHEMWiki News

2015-09-24T05:45:11Z

TeeVau: panStamp Artikel

{|
{{News|11.09.2015|Umfangreiche Überarbeitung der Wiki Artikel über [[:Kategorie:panStamp|panStamp Hardware und Software]]}}
{{News|11.09.2015|Neues Modul [[AMAD]] (Steuern und Informationsanzeige von Android-Geräten) wird per update verteilt}}
{{News|15.06.2015|Neues Modul [[yowsup]] (WhatsApp Unterstützung) wird per update verteilt}}
{{News|03.04.2015|Neues Geräte-Modul [[JawboneUp]] wird per update verteilt}}
{{News|23.03.2015|Neue Geräte-Module [[Modbus]], [[ModbusAttr]] und [[Modbus#Writing_modules_for_devices_using_this_module_as_a_library|ModbusSET]] werden per update verteilt}}
{{News|10.02.2015|FHEMWiki ist auf einen neuen Server umgezogen und [[FHEMWiki:Interna#Offene_Probleme|Aktualisierung der MediaWiki-Software]]}}
{{News|31.01.2015|Neues Geräte-Modul [[Pushbullet]] wird per update verteilt}}
{{News|14.01.2015|Neues Hilfs-Modul [[CALVIEW]] wird per update verteilt}}
{{News|08.01.2015|Neues Geräte-Modul [[Buderus_Web_Gateway|km200]] zur Anbindung eines Buderus Web-Gateways wird per update verteilt}}
{{News|18.12.2014|Neues Geräte-Modul [[SONOS]] wird per update verteilt}}
{{News|15.12.2014|Überarbeitetes und erweitertes Geräte-Modul [[HTTPMOD]] wird per update verteilt}}
{{News|10.12.2014|Neues Geräte-Modul [[Vitotronic_200_(Viessmann_Heizungssteuerung)|VCONTROL]] zur Anbindung einer Viessmann Heizung wird per update verteilt}}
{{News|17.11.2014|Neues Hilfs-Modul [[logProxy]] wird per update verteilt}}
{{News|09.11.2014|Fhem Version 5.6 wurde veröffentlicht}}
{{News|27.10.2014|Neues Geräte-Modul [[harmony]] zur Fhem-Anbindung Logitech Harmony Hub basierter Fernbedienungen wird per update verteilt}}
{{News|25.10.2014|Neues Geräte-Modul [[KostalPiko|KOSTALPIKO]] wird per update verteilt}}
{{News|24.10.2014|Neues Hilfs-Modul [[HourCounter]] wird per update verteilt}}
{{News|06.09.2014|Neues Hilfs-Modul [[CustomReadings]] per update verteilt}}
{{News|19.08.2014|Neues Hilfs-Modul [[DOIF]] wird per update verteilt}}
{{News|19.08.2014|Der Befehl [[update]] wurde überarbeitet: {{Link2Forum|Topic=26311}} }}
{{News|13.08.2014|Zusätzliche Domäne fhem.org aktiviert: {{Link2Forum|Topic=26113}} }}
{{News|02.03.2014|[[UserTreffenSuedMaerz2014|FHEM User Treffen]] in Karlsruhe am 22. März 2014 }}
{{News|29.09.2013|Fhem Version 5.5 wurde veröffentlicht}}
{{News|11.05.2013|Die meisten Daten aus dem FhemWiki sind wieder hergestellt.}}
{{News|04.05.2013|FhemWiki wird neu aufgebaut.}}
{{News|04.05.2013|FhemWiki Update zu [[Special:Version|MediaWiki 1.20.5]].}}
|}

Benutzer Diskussion:TeeVau

2015-08-06T19:34:06Z

TeeVau:

== panStamp als Fhem-WikiNews ==
Hallo TeeVau,
wenn Du mit Deinen umfangreichen Überarbeitungen an den panStamp-Seiten fertig bist, halte ich das für "würdig" als FhemWiki-News auf der Hauptseite aufgenommen zu werden. Da derzeit noch einige Baustellen/Todo-Hinweise auf den Seiten sind, habe ich das bisher noch nicht gemacht. Was meinst Du?
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 07:12, 28. Jul. 2015 (CEST)
<hr>
:Wegen mir gerne. Du hast richtig erkannt, dass noch an diversen Artikeln etwas zu tun ist. Mal mehr, mal weniger. Ich habe es auf jeden Fall im Auge und möchte das auch zu ende bringen. Ich denke allerdings, dass ich noch so 3-4 Wochen dafür brauche. Ich melde mich einfach bei dir, wenn ich fertig bin und das in die FhemWiki-News mit eingebunden werden kann. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:39, 28. Jul. 2015 (CEST)
<hr>
::Das kannst Du gerne eigenständig in die FhemWiki-News aufnehmen, wenn Du fertig bist. Ich will nur nicht, dass solche grundlegenden Erweiterungen des Wikis, die deutlich über eine neue Wiki-Seite hinausgehen, keine Beachtung finden. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:37, 28. Jul. 2015 (CEST)

== <nowiki><pre> oder <nowiki> oder <code></nowiki> ==

Hallo TeeVau,

Du hast auf der Seite [[PID20 - Der PID-Regler‎]] gerade einige <nowiki><code></nowiki> Markierungen in <nowiki><pre></nowiki> geändert. Das verbessert zwar die Darstellung ... aber nur, weil die alten Tags etwas ungeschickt gesetzt waren (Leerzeilen/Zeilenumbrüche zwischen den Tags). Ich würde vorschlagen:
* für "Einzeiler": <code><nowiki>:<code>der Code/Text</code></nowiki></code> (ab Spalte 1); das wird dann gleich eingerückt und zudem am Zeilenende umgebrochen, erzeugt also keine Endloszeilen, bei denen man gezwungen wird, nach rechts zu scrollen; der Code-Text kann trotzdem kopiert werden und enthält dabei keine Zeilenumbrüche
* für längere Codepassagen das <code><nowiki><pre>Text text text... </pre></nowiki></code>
* und <code><nowiki><nowiki></nowiki></code> nur, wenn der eingeschlossene Bereich Tags / Zeichen enthält, die nicht von der Wiki-Software formatiert werden sollen (wie die Wiki-Tags in den obigen Beispielen)
--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:31, 30. Jul. 2015 (CEST)
<hr>
:Hi Peter,
:habe mich schon gefragt was der unterschied zwischen dem pre und dem code Tag ist. So wirklich was verständliches habe ich nicht gefunden. Ich selber fand den pre Tag etwas "schöner" :zum formatieren, da dieser automatisch Zeilenumbrüche vor und nach dem Tag-Bereich einfügt. Ich habe die code und pre-Tags nun in dem Artikel so angepasst wie von dir vorgeschlagen. :Grüße und ein schönes Wochenende, Tobias. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:14, 31. Jul. 2015 (CEST)
:<hr />
:: Hab den Artikel noch mal leicht überarbeitet - ich denke, so ist es kompakter aber trotzdem übersichtlicher. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 11:02, 31. Jul. 2015 (CEST)

== panShield / Weiterleitung ==

Hallo TeeVau,

Du hast die Seite panShield als Weiterleitung auf panStick angelegt ... und panShield wird nur von panStick aus verlinkt. Ich halte diese Weiterleitungsseite nicht nur für unnötig, sondern in diesem Fall sogar für verwirrend. Hilfreich wäre sie nur, wenn jemand im Wiki die Seite panShield direkt aufrufen würde (was ich für eher unwahrscheinlich halte). Benutzt man die - in diesem Fall wahrscheinlichere Suche - findet man ohnehin den "zuständigen" Abschnitt auf der panStick Seite. Könntest Du das mit dem "panShield" bitte nochmal überdenken? --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:20, 6. Aug. 2015 (CEST)

:Hi Peter, du hast Recht. Ich habe den Artikel angelegt, weil ich dachte, panShield kommt viel häufiger in den unterschiedlichen Artikeln vor. Da dachte ich, ein Link zu einem Artikel wäre sinnvoll. Gerade habe ich festgestellt, dass panShield als Wort lediglich nur 3 mal im ganzen Wiki vorkommt. Da war ich etwas zu voreilig ;-). Ich werd den Artikel löschen bzw. als Löschkandidat vorschlagen. Oder du killst ihn direkt ;-). --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)

== Schreibweise von panS* in den Artikeln ==

TeeVau, nachdem Du gerade dabei bist, den panS*-Artikeln den letzten Schliff zu geben, würdest Du dabei auch gleich die Schreibweise vereinheitlichen? Es gibt immer noch reichlich Stellen, an denen '''P'''anS... (also mit großem Anfangsbuchstaben) steht - und wenn ich das richtig verstanden habe, ist das "p" wohl eigentlich als Kleinbuchstabe gedacht. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:23, 6. Aug. 2015 (CEST)

:Erledigt, zumindest bei allem was auch in der Kategorie panStamp ist. Ich kenne leider keine komfortable Möglichkeit das Wiki nach '''P'''anStamp abzusuchen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:34, 6. Aug. 2015 (CEST)

ESP32 Innenraumsensor und -Steuerung

2015-08-06T14:04:11Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{SEITENTITEL:panStamp Innenraumsensor}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sensor
|HWCategory=HardwareMods
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V
|HWPowerConsumption=
|HWPoweredBy=Battery AA
|HWSize=48.5 x 100 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=für diesen Sketch: [http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
|HWManufacturer=panStamp
}}

{{Baustelle}}

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Dieser bildet das Herzstück des Umweltsensors

Weiterführende Information zu panStamps und den grundlegenden Modulen um sie mit Fhem zu integrieren finden sich im zugehörigen [[panStamp|Wiki Artikel]].

== Beschreibung ==

=== Bootloader flashen ===
Anschließend muss man nun die Fuses korrekt setzen (8Mhz Internal, 3.3v):

avrdude -p m2560 -c stk500v2 -P /dev/ttyUSB0 -U lfuse:w:0xE2:m -U hfuse:w:0xD4:m

und final den Bootloader flashen
wget https://github.com/lthiery/Sentinel/blob/master/sketches/hardware/mega-pro-3.3V/bootloaders/MegaPro3.3V-8MHz-57600.hex
avrdude -p m2560 -c stk500v2 -P /dev/ttyUSB0 -U flash:w:MegaPro3.3V-8MHz-57600.hex

Jetzt kann man mit einem normalen USB-ParallelProgrammer testen ob der Chip ansprechbar ist:
avrdude -c arduino -b 57600 -P /dev/ttyUSB0 -p m2560 -v

und anschließend den Sketch drauf flashen:
avrdude -c arduino -b 57600 -P /dev/ttyUSB3 -p m2560 -U flash:w:MeinSketch.hex

[[Kategorie:panStamp]]

Bodenfeuchtesensor

2015-08-06T14:03:12Z

TeeVau: Schreibweise auf panStamp (kleines p)

Dieser Beitrag beschreibt die Möglichkeiten der Einbindung von Bodenfeuchtesenoren in FHEM

[[File:1wire_Bodenfeuchtesensor1.jpg|mini|hochkant=2.5|Plot-Beispiel]]

== Nutzung von panStamps zur Funkbasierten Datenübertragung ==
Die folgende Platine ist eine Modifikation/Weiterentwicklung des von Panstamp.org vertriebenen BatterieBoards. Die Platine ist passend zum G203 Gainta Gehäuse. Der [[panStamp]] ist so angeordnet, dass die "5cm gerade Antenne" aus dem panStamp Shop exakt in das Gehäuse passt. Es sind Anschlüsse für bis zu 4 Bodenfeuchtesensoren vorhanden. Weiterhin ist ein OneWire Anschluss integriert an dem der Anschluss eines DS18B20 zur Bodentemperaturmessung vorgesehen ist.

Optional kann der Sensor zusätzlich mit einem Solarpanel ausgestatt werden. Dieses lädt den eingesetzten Akku auf, sobald die SolarSpannung > AkkuSpannung ist.
Der Akku MUSS(!) mindestens die zehnfache Leistung des Solarpanels haben, ansonsten ist ein Laderegler notwendig. Bsp: Akku: 2700mA -> Solarpanel: 270mA
Ein für den Gehäusedeckel passendes Solarmodul ist zb. bei ebay unter folgendem Namen zu finden: '''3V 270mA 0,8W 110x55mm Solarmodul Solarzelle Polykristallin vergossen'''. Ist ein Solarpanel angeschlossen, so wird dessen Spannung dem panStamp zugeführt. Damit kann mit entsprechender Sketcherweiterung die solare Einstrahlung gemessen und nach FHEM zusammen mit der Batteriespannung übermittelt werden.

In Planung ist, dieses mit Silikon sauber auf der Gehäuseoberseite zu verkleben und die benötigten Kabel zuvor durch 2 Löcher im Deckel zu ziehen.

Achtung: Zur Zeit kann der Sketch nur 2 Bodenfeuchtesensoren bedienen. Die Weiterentwicklung ist in Arbeit.
Die Weiterentwicklung zum Umweltsensor ist hier [[panStamp_Umweltsensor]] beschrieben. Der dortige Sketch kann ebenfalls mittels Konfigurationsanpassung hier verwendet werden. Damit sind nun auch 1wire und der SolarWert in FHEM nutzbar.

=== Schaltplan und Bauteilliste ===
[[Datei:Arduino_Bodenfeuchtesensor_v0.1_Schaltplan.jpg|200px|thumb|right|Schaltplan]]
[[Datei:Arduino_Bodenfeuchtesensor_v0.1_Platine_Oben.jpg|200px|thumb|right|Platinenlayout Oberseite]]
[[Datei:Arduino_Bodenfeuchtesensor_v0.1_Platine_Unten.jpg|200px|thumb|right|Platinenlayout Unterseite]]
[[Datei:Arduino_Bodenfeuchtesensor_v0.1_Aufbau_Oben.jpg|200px|thumb|right|Platine fertig aufgebaut Oberseite]]
[[Datei:Arduino_Bodenfeuchtesensor_v0.1_Aufbau_Unten.jpg|200px|thumb|right|Platine fertig aufgebaut Unterseite]]

Bauteilliste:

{| class="wikitable"
! Bauteil
! Bezeichnung
! Shop
! BauteilNr
|-
| L1
| LQH4C Speicherdrossel
| Mouser.com
Reichelt

Reichelt
| 81-LQH43CN100K03L
L-1212FPS 10µ

L-1616FPS 10µ
|-
| C1, C2
| Keramikkondensator Typ:X7R 10uf
| Reichelt
Mouser.com
| X5R-G0805 10/16
810-CGJ4J1X7R0J106AC
|-
| C3
| Keramikkondensator Typ:X7R 1uF
| Reichelt
Mouser.com
| X7R-G0805 1,0/16
810-C2012X5R1C105K-2
|-
| C4
| Keramikkondensator Typ:X7R 100nF
| Reichelt
Mouser.com
| X7R-G0805 100N
581-0805YD104KAT2A
|-
| IC1
| MAX1724 Schaltregler 1.5uA IQ Step-Up DC/DC Converter
| Mouser.com
tme.eu

Ebay: G&C Supermarket
| MAX1724EZK33T
MAX1724EZK33+T

MAX1724
|-
| K1,K2,K3,K4,K5
| Anreihklemme 3,5mm 3Pol
| IT-WNS
| AK-3.5-3-GY
|-
| R1
| Widerstandsnetzwerk 100K
| Reichelt
| SIL 5-4 100K
|-
| R2
| SMD Widerstand 1k
| Reichelt
Mouser.com
| SMD-0805 1K
71-CRCW0805-1.0K-E3
|-
| R4
| SMD Widerstand 4k7
| Reichelt
Mouser.com
| SMD-0805 4,70K
71-CRCW0805-4.7K-E3
|-
| R5
| Widerstandsnetzwerk 100K
| Reichelt
| SIL 7-6 100K
|-
| J1
| Stiftleiste 1x5Pol
| Reichelt
| MPE 087-1-005
|-
| D1
| LED 3mm LowCurrent 2mA
| Reichelt
| LED 3MM 2MA GN
|-
| TASTER
| Reset TASTER 9314
| Reichelt
| TASTER 9314
|-
| Batteriehalter
| Batteriehalter 1x AA Mignon(Akku)
| Reichelt
| HALTER 1XAAP
|-
| K7
| Anschluss Solarpanel (VERT PCB 2Pin TIN FRICTION LOCK)
| Reichelt
Mouser
| zb. MPE 087-1-002
538-22-23-2021
|-
| D2
| BAV70 Schaltdiode SMD, SOT-23, 250V, 1A
| Reichelt
| BAV 70 SMD
|-
| T1
| BCW 61 Transistor SMD PNP SOT-23 32V 0,1A 0,25W
| Reichelt
| BCW 61C SMD
|-
| T2
| BC847 Transistor SMD NPN SOT-23 45V 0,1A 0,25W
| Reichelt
| BC 847B SMD
|-
| T3
| BSS138 Transistor SMD N-FET SOT-23 50V 0,22A
| Reichelt
| BSS 138 SMD
|-
| IC
| panStamp AVR
| panstamp.com
| panStamp AVR
|-
| --
| Female Header 2,54 mm, 1X16, straight
| Reichelt
| MPE 094-1-016
|}

== Onewire Bodenfeuchtesensor ==
Das vorgestellte Platinenlayout dient dazu, an einem DS2450 ([[1-Wire]]) vier Vegetronix Bodenfeuchtesensoren anzuschließen. Die Platine passt in das ELV IP65 Gehäuse G203. Der Anschluss über fünf Kabeldurchführungen PG7 erfolgt von unten.

=== Schaltplan und Bauteilliste ===
[[Datei:1wire_BF_Schaltplan.jpg|300px|thumb|right|Schaltplan]]
[[Datei:1wire_BF_Platine.jpg|300px|thumb|right|Platinenlayout]]
Bauteilliste:

{| class="wikitable"
! Bauteil
! Bezeichnung
! Shop
! BauteilNr
|-
| D1,D2
| Diode
| Reichelt
| BAT85
|-
| C1
| Elko 47uF
| Reichelt
| RAD 47/16
|-
| C3
| Keramikkondensator 100N, 10%
| Reichelt
| X7R-5 100N
|-
| K1,K2,K3,K4
| Anreihklemme 3Pol
| Reichelt
| AKL 055-03
|-
| K5
| Anreihklemme 4Pol
| Reichelt
| AKL 055-04
|-
| J1
| Stiftleiste 1x3Pol
| Reichelt
| MPE 087-1-003
|-
| Jumper
| Jumper
| Reichelt
| JUMPER 2,54 SW
|}
Das Platinenlayout (erstellt mit Target3001) ist im unten aufgeführten Forenthread angehängt.

== Hinweise zum Betrieb mit FHEM ==
Die Einbindung der einzelnen Sensoren ist im [[1-Wire_Feuchtemessung]] Beitrag beschrieben.

== Weitere Hinweise ==
Keine.

== Links ==
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:1-Wire]]
[[Kategorie:panStamp]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Other Components]]

SWAP 0000002200000003

2015-08-06T14:02:10Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{Baustelle}}
{{SEITENTITEL:SWAP_0000002200000003}}

{{Infobox Modul
|ModPurpose=Modul zur Ansteuerung des erweiterten RGB Board
|ModType=d
|ModCmdRef=SWAP_0000002200000003
|ModForumArea=
|ModFTopic=
|ModTechName=
|ModOwner=
}}
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
Ein FHEM Modul für das modifizierte panStamp RGB LED Driver Board.

Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

===== weitrere Screenshots =====
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>

== Voraussetzungen ==
Um Modul xyz benutzen zu können, muss außerdem ...

== Anwendung ==
=== Define ===

=== set-Kommando ===
* on/off/on-for-timer/toggle/...
Wie bei jedem anderen Device
*rgb RRGGBB
Stellt die Farbe ein, ohne Fade.
*dimUp
*dimDown
Stufenweise heller oder dunkler schalten
*setIR # code
*learnIR #
*storeIR # code cmd
Hinterlegt eine von 16 möglichen Zuordnungen zwischen ir-Signal und FHEM-Kommando. # ist die Nummer der Registers, code ist das ir-Kommando, cmd ist das rgb driver kommando das ausgeführt werden soll
*getIR #
*getIR all
Fragt ein/alle hinterlegten ir Register ab. Anzeige mit <code>get <device> listIR</code>
*setFade # RRGGBB time
Speichert eine definierte Farbe in bis zu 16 unterschiedlichen Registern. Durch diese Farben kann später automatisch überblendet werden.
*getFade #
*getFade all
Fragt alle hinterlegten fader Register ab. Anzeige mit <code>get <device> listFade</code>
*startFade #1 #2
Beginnt in einer Endlosschleife zwischen die Register von <code>#1</code> bis zu <code>#2</code> durchzufaden.

=== get-Kommando===

=== Attribute ===
* defaultFadeTime
Es wird diese fadeTime verwendet, wenn bei dem set-Kommandor <code>fadeTo</code> keine Zeit angegeben wird. Das macht es etwas einfacher das [[panStamp RGBWW Board mit DMX und IR]] in eine [[LightScene]] einzubinden und beim aktivieren einer Szene die Farben zu faden statt hart umzuschalten

== Anwendungsbeispiele ==
=== original RGB-Sketch (von panstamp.com) ===
Der originale Sketch von der panStamp.com-Seite und das [[SWAP]] FHEM-Modul verstehen von Haus aus nur die <code>regSet</code> und <code>regGet</code> Kommandos. Wenn man den [[Color#Colorpicker|colorpicker]] verwenden möchte, geht das nur per [[readingsProxy]].
Das einfachste ist es den [[panStamp_RGBWW_Board_mit_DMX_und_IR#Link_zum_Sketch|Sketch]] und das [[SWAP_0000002200000003|FHEM-Modul]] für das [[panStamp_RGBWW_Board_mit_DMX_und_IR|RGBWW-Board]] zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen FHEM-Kommandos wie on, off, on-for-timer, dimup, etc. zu verwenden.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden. {{Link2Forum|Topic=12487 |Message=220463}}

Falls jemand trotzdem den normalen RGB-Sketch von panStamp verwendet:
* Im SourceCode der Datei alle drei <code>0000002200000003</code> durch <code>0000000100000003</code> ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

=== ir Code anlernen ===
Um die ir Kommandos anzulernen am besten <code>learnIR #</code> verwenden. Danach blinkt die LED auf dem Board schnell und es wird auf ein ir-Signal gewartet. Wenn das empfangen ist blinkt die LED langsamer und es wird auf ein Kommando von FHEM gewartet. Danach geht die LED auf dem Board aus und das eben gesendete FHEM-Kommando ist mit der Taste auf der ir Fernbedienung verknüpft.

Empfangene ir-Kommandos, die nicht über eines der 16 Register eine lokale Aktion auslösen, werden über das Register <code>0C</code> an FHEM übertragen und sind per notify ganz normal weiter verarbeitbar.

=== Power On State konfigurieren ===
register 0E PowerOnState:
* 1. byte: <code>0</code> -> aus, <code>1</code> -> weiss, <code>2</code>-> eine bestimmte Farbe wie im 3. Byte konfiguriert, <code>3</code> -> autosave. <code>E0.1 Bit 5&6</code> gibt jetzt in 10 Sekunden Schritten an nach welcher Zeit das autosave ins eeprom passieren soll. also 0, 10, 20 oder 30 Sekunden
* 2. byte: Helligkeit
* 3-5. byte <code>rrggbb</code>
Man kann z.b. mit <code>set <device> regSet 0E 0200FFFFFF</code> einstellen das nach dem einschalten alle drei Farbkanäle voll aufgedreht werden.
oder mit <code>set <device> regSet 0E 0300000000</code> autosave aktivieren. Dann wird jeweils nach 5 Minuten ohne Änderung die aktuelle Farbe ins eeprom gesichert. Die 5 Minuten könnte man eventuell noch verkürzen. Für autosave ist am Anfang der loop Schleife im Arduino Sketch das Schreiben ins eeprom zu aktivieren (das <code>#if 0</code> in ein <code>#'if 1</code> ändern). An dieser Stelle kannst du auch die 5 Minuten anpassen.
Soft on funktioniert auch mit dem Wert vor dem letzten ausschalten. Hierzu ist das Register <code>0E.1</code> wie folgt zu setzen: <code>0x02</code> um nach hard power on den letzten rgb wert zu haben, <code>0x08</code> um nach soft on den letzten wert zu haben. Für beides zusammen <code>0x0a</code>.

=== 5. LED Kanal zum schalten benutzen ===
Mit den 5. Kanal nur schalten ist kein Problem. Das SWAP FHEM-Modul kann schon so konfiguriert werden das es nur den Teil eines Registers als eigenständiges Device zur Verfügung stellt. Alternativ geht das auch mit dem [[readingsProxy]].
<pre>
define Leinwand readingsProxy RGB_Leinwand 0B.4
attr Leinwand setFn {if($CMD eq "on") {fhem("set $DEVICE regSet 0B.4 FF")} else {fhem("set $DEVICE regSet 0B.4 00")}}
attr Leinwand setList on off
attr Leinwand valueFn {return "off" if( $VALUE eq "00"); return "on";}
</pre>

=== Fade konfigurieren ===
Faderegister definieren:
<pre>
set Device setFade 01 FF0000 60
set Device setFade 02 00FF00 60
set Device setFade 03 0000FF 60
</pre>

Fade starten von Register 1 bis Register 3:
set Device startFade 01 03
== Links ==

[[Kategorie:panStamp]]

SWAP

2015-08-06T14:01:31Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher panStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der panStamp Baugruppen. Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. [[SWAP_0000002200000003]]) vorhanden sein. Diese Module bauen, als 3. Ebene, auf das SWAP Modul (2. Ebene) auf und bedienen im backend ebenfalls die panStamp-Hardware über die Register. Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
sudo apt-get install libxml-simple-perl
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das [[SWAP]] Modul greift auf das [[panStamp]] Modul zu, was vorher per <code>define</code> angelegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über [https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol#registers-and-values '''Register'''], dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können.
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele, sketchabängige Userregister (<code>0B</code>-<code>xx</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers#custom-registers] bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files'', die in <code>.../FHEM/lib/SWAP</code> zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt''-ID [https://github.com/panStamp/panstamp/wiki/How-to-develop-your-own-SWAP-device#specify-your-product-code] gebildet wird. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
In den Systemregistern steht z.B. der ProductCode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert. Also z.B. Adresse <code>FF</code> und Intervall <code>FFFF</code> (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).
Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

Alle low Level Dinge wie Register ID oder Register Wert können mit '''hex Werten'' direkt angepasst werden.
set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
set <device> regSet 08 <Netzwerk ID als 2 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87436 }}

Das [[SWAP]]-Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Queue für panStamp-Hardware im power down Modus gehalten. Sobald die panStamp-Hardware online (SYNC Modus) kommt werden die Kommandos von FHEM automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des Device Definition Files automatisch erzeugt
* Es ist möglich direkt Endpoints (Teile eines Registers) zu schreiben
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulebene neben dem [[panStamp]] FHEM-Modul (1. Ebene) für die Hardware und dem SWAP Modul (2. Ebene) für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP Devices ''zu Fuß'' über die Register ansprechen. Um die Register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann ein Modul der 3. Ebene notwendig. {{Link2Forum|Topic=12487 |Message=78502 }}

=== Define ===
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''
Wenn der [[panStick]] läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste Mal senden, z.B. nach dem Einschalten oder nach einem Reset. Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

panStick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down Mode erfolgt dieses das erste Mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem ProductCode. Die ID ist die SWAP Device Adresse und bei einem frisch geflashten panStamp in der Regel <code>FF</code>. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0 - FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Adresse und das gibt Konflikte.

Wer mehrere Devices hat, sollte jedem nach dem Anlegen mit
set <device> regSet 09 <Device Adresse als 2 stellige hex zahl>
eine eigene ID zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* <code>00</code> ist die Broadcast-ID
* <code>01</code> ist die ID des [[panStick]] am FHEM-System
* <code>FF</code> ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* <code>F0-FE</code> sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID <code>FF</code> erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich <code>F0 - FE</code> und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
define <device> SWAP <ID>
Bis allerdings der ProductCode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch passiert, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der ID <reg> ab. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Definition-XML-File neu ein.

* clearUnconfirmed
Löscht die Liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von panStamps NRG unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <ProductCode>: Verwendet das SWAP_<ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der Empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (ProductCode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der ProductCode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Definition-XML-File ein. Erst wenn der ProductCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sketch:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Definition File ===
Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch ''menschenlesbare'' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>
attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}
</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen Readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>
attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}
</code>

Ein weiteres Beispiel ist das Definition File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele sketchabängige Userregister (<code>0B</code> - <code>xx</code>)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern stehen z.B. der ProductCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert, also z.B. die Adresse <code>FF</code> und das Intervall <code>FFFF</code> (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem ProductCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene panStamps ===
panStamp Hardware mit power down Mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet. Normaler Weise werden dann die Register mit den Sensorwerten an FHEM gesendet. Power down Devices gehen danach schlafen (power down Modus mit extrem niedrigem Stromverbrauch) und wachen regelmäßig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modus keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich variieren und anders programmiert sein!

Nachrichten an eine panStamp-Hardware im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an die panStamp-Hardware geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <Intervall in Sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device definition file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von <code>FFFF</code> im Systemregister <code>0A</code> zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host Systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass FHEM mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum Senden kommt. Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf <code>0x5555</code> (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul eine panStamp-Hardware mit der Adresse <code>0xFF</code> wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich <code>0xF0 - 0xFE</code>. Das soll das Inbetriebnehmen von mehreren panStamp-Hardwaremodulen gleichzeitig erleichtern. Der automatisch vergeben Adressbereich ist begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fällen werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes panStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[panStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix Sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das Register <code>0A</code> konfigurierbar. Der Sensor wird an GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

<code>set <MyBodenfeuchte> stateFormat VWC_A%</code>

<code>
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)}, VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))}, voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}
</code>

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===
Es besteht die Möglichkeit, dass die Internals aus irgendeinem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
set <device> statusRequest
set <device> readDeviceXML

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiß welche Firmware auf der panStamp-Hardware ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}

=== register 0F is not known ===
{{Link2Forum|Topic=12487 |Message=84257}}

=== Komplette Übersicht eines Device ===
list <device>
{{Link2Forum|Topic=13890 |Message=201467}}

=== fehlender oder falsche ProductCode ===
Fehlt der ProductCode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den ProductCode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
set <device> statusRequest

{{Link2Forum|Topic=13890 |Message=201910}}

=== missing commands und register 00-0A unvollständig ===
Wenn in den INTERNALS missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register <code>00-0A</code> nicht vollständig sind und das INTERNAL "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}

=== Funktion des Autocreate ===
Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trotzdem <code>FF</code>. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde. {{Link2Forum|Topic=12487 |Message=88110}}

=== Adresse manuell setzen ===
Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
sudo apt-get install libxml-simple-perl

=== panStamp antwortet nicht/EEprom to factory defaults ===
Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in <code>setup()</code> ein <code>eepromToFactoryDefaults()</code> aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen Sketch flashen. {{Link2Forum|Topic=13890 |Message=121677}}

=== Factory Defaults ===
Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die <code>setup()</code> Routine einfügen:
eepromToFactoryDefaults()
{{Link2Forum|Topic=13890 |Message=157125}}

=== Status LED ===
Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit <code>#define LED_DEBUG</code> mit "//" auskommentiert. {{Link2Forum|Topic=13890 |Message=164731}}

== Links ==

[[Kategorie:panStamp]]

PanStamp Umweltsensor

2015-08-06T13:59:56Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sensor
|HWCategory=HardwareMods
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V
|HWPowerConsumption=
|HWPoweredBy=Battery AA
|HWSize=48.5 x 100 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=für diesen Sketch: [http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
|HWManufacturer=panStamp
}}

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Dieser bildet das Herzstück des Umweltsensors

Weiterführende Information zu panStamps und den grundlegenden Modulen um sie mit Fhem zu integrieren finden sich im zugehörigen [[panStamp|Wiki Artikel]].

== Beschreibung ==

Der auf dem panStamp (Arduino328p) basierende Umweltsensor hat die folgenden Eigenschaften:
* 4x Analogeingänge
* Helligkeitserfassung per TSL2561
* Temperatur- und Luftfeuchtemessung mit DHT22
* Luftdruck- und Temperaturmessung per BMP180
* Anschluss von 1..n 1wire Temperatursensoren DS18B20
* Messung der Batteriespannung
* Messung der Solarspannung
* Anpassbare MessFrequenz für Tag und Nacht
* passt alles in ein ELV IP65 (Nr: G203/G203C) Gehäuse und ist damit geeignet für den Außeneinsatz

Alle benötigten Dateien sind [https://tulpemd.traffic-eye.de/owncloud/public.php?service=files&t=b0bf5979833bc2ca01c8a7bc9cd11335 hier] zu finden:
* Sketch
* EnvironmentSensor.xml
* Target3001 Dateien

Unbestückte Platinen können beim [http://forum.fhem.de/index.php?action=profile;u=118 Ersteller], falls vorrätig, angefragt und erworben werden.

== Schaltplan und Bauteilliste ==
[[Datei:Arduino_Umweltsensor_v1.0_Schaltplan.jpg|200px|thumb|right|Schaltplan]]
[[Datei:Arduino_Umweltsensor_v1.0_Platine_Oben.jpg|200px|thumb|right|Platinenlayout Oberseite]]
[[Datei:Arduino_Umweltsensor_v1.0_Platine_Unten.jpg|200px|thumb|right|Platinenlayout Unterseite]]
[[Datei:Arduino_Umweltsensor_v1.0_Fertig.jpg|200px|thumb|right|fertiger Aufbau]]
[[Datei:Arduino_Umweltsensor_v1.0_Plot1.jpg|200px|thumb|right|Plot Nr 1]]

Bauteilliste:

{| class="wikitable"
! Bauteil
! Bezeichnung
! Shop
! BauteilNr
|-
| L1
| LQH4C Speicherdrossel
| Mouser.com
Reichelt

Reichelt
| 81-LQH43CN100K03L
L-1212FPS 10µ

L-1616FPS 10µ
|-
| C1, C2
| Keramikkondensator Typ:X7R 10uf
| Reichelt
Mouser.com
| X5R-G0805 10/16
810-CGJ4J1X7R0J106AC
|-
| C3
| Keramikkondensator Typ:X7R 1uF
| Reichelt
Mouser.com
| X7R-G0805 1,0/16
810-C2012X5R1C105K-2
|-
| C4, C7
| Keramikkondensator Typ:X7R 100nF
| Reichelt
Mouser.com
| X7R-G0805 100N
581-0805YD104KAT2A
|-
| IC1
| MAX1724 Schaltregler 1.5uA IQ Step-Up DC/DC Converter
| Mouser.com
tme.eu

Ebay: G&C Supermarket
| MAX1724EZK33T
MAX1724EZK33+T

MAX1724
|-
| K1,K2,K3,K4,K5
| Anreihklemme 3,5mm 3Pol
| IT-WNS
| AK-3.5-3-GY
|-
| R1
| Widerstandsnetzwerk 100K
| Reichelt
| SIL 5-4 100K
|-
| R2
| SMD Widerstand 1k
| Reichelt
Mouser.com
| SMD-0805 1K
71-CRCW0805-1.0K-E3
|-
| R3
| SMD Widerstand 10k
| Reichelt
Mouser.com
| SMD-0805 10K
71-CRCW0805-10K-E3
|-
| R4
| SMD Widerstand 4k7
| Reichelt
Mouser.com
| SMD-0805 4,70K
71-CRCW0805-4.7K-E3
|-
| J1
| Stiftleiste 1x5Pol
| Reichelt
| MPE 087-1-005
|-
| D1
| LED 3mm LowCurrent 2mA
| Reichelt
| LED 3MM 2MA GN
|-
| TASTER
| Reset TASTER 9314
| Reichelt
| TASTER 9314
|-
| Batteriehalter
| Batteriehalter 1x AA Mignon(Akku)
| Reichelt
| HALTER 1XAAP
|-
| K7
| Anschluss Solarpanel (VERT PCB 2Pin TIN FRICTION LOCK)
| Reichelt
Mouser
| zb. MPE 087-1-002
538-22-23-2021
|-
| D2
| BAV70 Schaltdiode SMD, SOT-23, 250V, 1A
| Reichelt
| BAV 70 SMD
|-
| T1
| BCW 61 Transistor SMD PNP SOT-23 32V 0,1A 0,25W
| Reichelt
| BCW 61C SMD
|-
| T2
| BC847 Transistor SMD NPN SOT-23 45V 0,1A 0,25W
| Reichelt
| BC 847B SMD
|-
| T3
| BSS138 Transistor SMD N-FET SOT-23 50V 0,22A
| Reichelt
| BSS 138 SMD
|-
| IC
| panStamp AVR
| panstamp.com
| panStamp AVR
|-
| --
| Female Header 2,54 mm, 1X16, straight
| Reichelt
| MPE 094-1-016
|-
| --
| DHT22
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=273096 DHT22]
|-
| --
| BMP180
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=277617 BMP180]
|-
| --
| TSL2561
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=276001 TSL2561]
|-
| --
| Dallas DS18B20
| lipoly.de
| [http://www.lipoly.de/index.php?main_page=product_info&products_id=104763 DS18B20]
|}

== Hinweise zum Aufbau==
Soll kein 1Wire genutzt werden, so wird empfohlen den R4 (4k7) nicht zu bestücken da dieser Pullup bei jedem Messvorgang bei denen 1wire/DHT22/BMP180 oder TSL2561 involviert sind zusätzlich die Batterie belasten.

Soll kein DHT22 genutzt werden, so wird empfohlen R3 und C7 (4k7) nicht zu bestücken da beide bei jedem Messvorgang bei denen 1wire/DHT22/BMP180 oder TSL2561 involviert sind zusätzlich die Batterie belasten.

== Hinweise zum Betrieb mit FHEM ==
===Configuration===
Nach upload des Sketches auf den Panstamp ist zuerst die korrekte Kennung über das Register 09 sowie der gewünschte Sendezyklus über das Register 0A zu setzen (siehe [[panStamp#Neue_panStamps_in_Betrieb_nehmen|Inbetriebname im Wiki Artikel]] zum den panStamps).
Anschließend ist die Konfiguration mittels Register 0B zu setzen:
{| class="wikitable"
! Bezeichnung
! Länge
! Position
! Beschreibung
|-
| Sync Intervall
| 2 Byte
| 0+1
| Intervall in Sekunden zur Synronisation mit der Zentrale. 0000 ist deaktiviert
|-
| SendDelay
| 2 Byte
| 2+3
| Sendeverzögerung in ms zwischen dem Senden von mehreren Registern. Soll Sendeüberlagerung bei Nutzung von Repeatern minimieren
|-
| Altitude
| 2 Byte
| 4+5
| Angabe des Standortes des Sensors in Höhenmetern ünN. Notwendig zur Berechnung von SeaLevelPressure
|-
| Day/NichtShift Type
| 1 Byte
| 6
| Type:1 -> Nutzung des Solarwertes ; Type:2 -> Nutzung der Helligkeit vom TSL2561
|-
| Day/NigthShift Threshold
| 3 Byte
| 7+8+9
| Schwellwert bei dem Day/Night umgeschaltet werden soll, Type 1: in mV ;Type 2: in Lum
|-
| Day/NightShift TX Intervall
| 2 Byte
| 10+11
| Intervall in Sekunden im Tagesrhythmus, Das "normale" TX_INTERVAL (Register 0A) ist dann NachtRhythmus
|-
| HAS_Analog4
| 1Bit
| 12.0
| Die analoge Spannung am A3 wird gemessen. VCC liegt an D3 an.
|-
| HAS_Analog3
| 1Bit
| 12.1
| Die analoge Spannung am A2 wird gemessen. VCC liegt an D3 an.
|-
| HAS_Analog2
| 1Bit
| 12.2
| Die analoge Spannung am A1 wird gemessen. VCC liegt an D6 an.
|-
| HAS_Analog1
| 1Bit
| 12.3
| Die analoge Spannung am A0 wird gemessen. VCC liegt an D7 an.
|-
| HAS_DS18B20
| 1Bit
| 13.0
| Ein oder mehrere DS18B20 sind angeschlossen und sollen ausgelesen werden
|-
| HAS_DHT22
| 1Bit
| 13.1
| Ein DHT22 ist angeschlossen und soll ausgelesen werden
|-
| HAS_TSL2561
| 1Bit
| 13.2
| Ein Hellihkeitssensor TSL2561 ist angeschlossen und soll ausgelesen werden.
|-
| HAS_BMP180
| 1Bit
| 13.3
| Ein Luftdrucksensor BMP180 ist angeschlossen und soll ausgelesen werden.
|-
| Transmit BatVol
| 1Bit
| 14.0
| Die aktuelle Batteriespannung soll übermittelt werden.
|-
| Transmit SolarVol
| 1Bit
| 14.1
| Die aktuelle Spannung von der Solarzelle soll übermittelt werden.
|-
| Enable Debug LED
| 1Bit
| 14.2
| Aktivierung der LED als Debug Ausgabe zur Initialisierung und zu jedem Sendezeitpunkt
|-
| Enable Day/NightShift
| 1Bit
| 14.3
| Die Sendeintervalle für Tag und Nachtrhythmus sollen aktiviert werden
|}

===Nutzung von unterschiedlichen Sendeintervallen bei Tag/Nacht===
Soll das Sendeintervall tagsüber anders sein als in der Nacht, so ist dies über die Day/NightShift Funktionen einzustellen. Beispielsweise soll der Umweltsensor für eine Rolladensteuerung benutzt werden. Dann ist es besser die Messung minütlich durchzuführen. In der Nacht wäre dann 10-minütlich ausreichend.
Über den ConfigParameter "Day/NichtShift Type" kann angegeben werden, auf welcher Grundlage die Tag/Nachterkennung stattfinden soll. Entweder über eine Solarspannung die normalerweise nur am Tage vorliegt, oder über eine Helligkeitsmessung des TSL2561 falls einer bestückt ist. In beiden Fällen wird über "Day/NichtShift Threshold" der Schwellwert angegeben an welchem Punkt die Tag/Nacht Grenze gesetzt werden soll. Bei Nutzung von Solarspannung ist hier der Schwellwert in mV anzugeben (zb. 500 für 0.5V) oder in Lumen als gemsssener Lumenwert des TSL2561. Hier sollten man vorher die Messerte der jeweiligen Sensoren über einige Tage genau beobachten um einen geeigneten Wert zu finden.
Durch die angabe des Intervalls mit "Day/NichtShift TX Intervall" wird das Sendeintervall für den Tagrhythmus angegeben. Das Standardsendeintervall aus dem Register 0A ist das für den Nachtrhythmus verantwortlich.

===Setzen der Konfiguration===
Ein Register ist als Hex-Wert zu setzen. Folgende Tabelle zeigt eine exemplarische Konfiguration:
{| class="wikitable"
! Bezeichnung
! Wert
! Binär Wert
! Hex Wert
|-
| Sync Intervall
| 12h -> 43200s
|
| A8C0
|-
| SendDelay
| 100ms
|
| 0064
|-
| Altitude
| 53m
|
| 0035
|-
| Day/NichtShift Type
| 1
|
| 01
|-
| Day/NigthShift Threshold
| 1000mV
|
| 0003E8
|-
| Day/NightShift TX Intervall
| 60s
|
| 003C
|-
| HAS_Analog4
| nein
| 0
|
|-
| HAS_Analog3
| nein
| 0
|
|-
| HAS_Analog2
| ja
| 1
|
|-
| HAS_Analog1
| ja
| 1
|
|-
|
|
| 00001100
| 0C
|-
| HAS_DS18B20
| ja
| 1
|
|-
| HAS_DHT22
| nein
| 0
|
|-
| HAS_TSL2561
| nein
| 0
|
|-
| HAS_BMP180
| nein
| 1
|
|-
|
|
| 00001001
| 09
|-
| Transmit BatVol
| ja
| 1
|
|-
| Transmit SolarVol
| ja
| 1
|
|-
| Enable Debug LED
| nein
| 0
|
|-
| Enable Day/NightShift
| ja
| 1
|
|-
|
|
| 00001011
| 0B
|}

In obigem Fall ist das Konfigurationsregister wie folgt aufgebaut: ''A8C0 0064 0035 01 0003E8 003C 0C 09 0B''
Aufgrunddessen wird die Konfiguration folgendermaßen gesetzt:
set <MySwapDevice> regSet 0B A8C000640035010003E8003C0C090B

Es ist auch möglich die einzelnen Endpoints unabhängig voneinander zu setzen. z.B.:
set <MySwapDevice> regSet 0B.17 1

===Syncronisation mit der Zentrale===
Jede Syncronisation kostet zusätzlichen Strom und belastet damit die Batterie. Allerdings benötigt man eine Synronisation um Befehle von der Zentrale entgegenzunehmen. Z.B. für eine neue Konfiguration. Im Normalfall benötigt man keine automatisiert Synronisation da mit Druck auf den Reset-Button ebenfalls eine Synronisation erfolgt.
Hat man aber ein Szenario vorliegen, beidem FHEM automatisiert die Konfiguration ändern soll, so ist ein SyncIntervall notwendig. Um die automatisierte Syncronisation abzuschalten ist als Wert 0000 zu setzen.

===Nutzung von mehreren DS18B20===
Die Messwerte für die 1wire Temperatursensoren werden in einem einzelnen Register 0E übertragen. Das bedeutet, falls mehrere DS18B20 am Bus angeschossen sind, überschreiben diese sich gegenseitig. Dieses Verhalten ist aber vom Author so gewollt um eine gewissen Generik zu gewährleisten.
Um nun auf die einzelnen Messerte in FHEM zugriff zu bekommen, schafft folgendes UserReading Abhilfe:

attr <MySwapDevice> userReadings Temperature_Sun:0E.1-1wire_Address:.*28D6CF710400009C {SWAP_1wire($name)}
Die im Beispiel verwendete 1Wire ID ist natürlich an die eigenen Gegebenheiten anzupassen. Pro angeschlossenem DS18B20 ist ein weiteres userReading anzulegen.

Anschließend ist folgende Prozedur in 99_MyUtils.pm zu ergänzen:
sub SWAP_1wire($) {
my ($SwapDevice) = @_;
return (hex(ReadingsVal($SwapDevice, "0E.0-1wire_Temperature", ""))*0.01) - 50;
}
Nun wird pro eindeutiger 1Wire-ID ein neues Reading erzeugt welches den Messwert enthält.

== Weitere Hinweise ==
Keine.

== Links ==
* [https://tulpemd.traffic-eye.de/owncloud/public.php?service=files&t=b0bf5979833bc2ca01c8a7bc9cd11335 Alle benötigten Dateien auf der Seite des Authors]
* [https://www.tindie.com/products/miceuz/i2c-soil-moisture-sensor/ Bodenfeuchtesensor auf I2C-Basis]
* [http://vegetronix.com/Products/VH400/ Vegetronix Bodenfeuchtesensor]
* [http://www.amazon.com/Arduino-compatible-Sensitivity-Moisture-Sensor/dp/B00AFCNR3U LowCost Arduino compatible High Sensitivity Moisture Sensor]

[[Kategorie:panStamp]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Lichtsensoren]]

PanStamp RGBWW Board mit DMX und IR

2015-08-06T13:59:01Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{Baustelle}}

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=RGBWW Board
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz
|HWChannels=
|HWVoltage=12V
|HWPowerConsumption=
|HWPoweredBy=Netzteil
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#SWAP_0000002200000003 35_SWAP_0000002200000003.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}
[[panStamp RGBWW Board mit DMX und IR]] unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z.B. als Unterputz Touchpanel) und FHEM bedienen.
Es ist eine Hard- und Softwareentwicklung auf Basis von panStamp Modulen und verwendet zusätzlich das FHEM Modul [[SWAP 0000002200000003]] als 3. Ebene

Der Funktionsumfang wird in diesem {{Link2Forum|Topic=12487|Message=81923|LinkText=Forenthread}} vorgestellt. Die Hardware für das Board wird {{Link2Forum|Topic=13890|LinkText=hier}} im FHEM Forum vorgestellt und ein Prototyp ist {{Link2Forum|Topic=12487|Message=85777|LinkText=hier}} zu sehen.

== Hardware ==
Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

=== Kompatibilität RBG-Board mit NRG-panStamps ===
Mit dem hier beschriebenen Sketch ist das Board nur mit den panStamp AVRs kompatibel. Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht GND wie beim AVR. Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s einen „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0. {{Link2Forum|Topic=13890 |Message=247069}}

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.

=== Eigenschaften des fade TBC ===
Der wichtige Punkt ist das das RGBWW-Board Farbübergänge autonom macht und FHEM nur den Trigger zum starten und Rückmeldung über den Status gibt. d.h. wie ruckelfrei das faden ist hängt nicht von äußeren Bedingungen wie Funklast, FHEM timing oder FHEM Auslastung ab. Im Board gibt es 15 '''Register''' die jeweils eine Farbe und eine Anzeigedauer enthalten. Diese werden (ein mal) von FHEM aus programmiert. Zum starten wird dann nur noch das Anfangs- und das Endregister gesendet und das Board überblendet zwischen allen Farben der Register zwischen Anfang und Ende in der eingestellten Zeit.
Die eigentliche Einschränkung ist das die aktuelle AVR Version der panstamps ''nur'' 8bit pwm kann (jedenfalls wenn es 3 oder mehr Kanäle sein sollen und die Hardware PWM genutzt wird). Wenn dir diese 256 Stufen pro Grundfarbe reichen ist es absolut Ruckelfrei. d.h. es gibt keinen zeitlichen Jitter. Ob dir die Anzahl der Helligkeitsstufen reicht hängt ein wenig von den LEDs selber ab und davon zwischen welchen Farben du konkret wechselst. Im dunklen Bereich wirst du vermutlich stufen sehen (also beim aufblenden von dunkel zu hell). wenn du zwischen zwei hellen Farben (z.b. von rot nach grün) blendest wirst du keine stufen sehen. {{Link2Forum|Topic=13890|Message=106644}}

== Software ==
Eine Übersicht über die derzeit vorhandene Funktionalität des [[SWAP_0000002200000003|Fhem Moduls]] und panStamp Sketches (Stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
was geht:
* Bis zu vier LED Kanäle (je nach Kombination von ir und soft PWM)
* Ir senden
* Ir empfangen
* Messen ob die LED Versorgungsspannung an ist
* Helligkeit eines an Pin <code>A2</code> angeschlossenen Helligkeitssensors (LDR)
* Konfiguration der DMX Basisadresse über das SWAP Register <code>0x12</code>
* Optional soft on auf letzten RGBW Wert
* Alles was auch vorher schon ging: dimmen, faden, ir fernbedienungen anlernen, ...

wichtig zu wissen:
* Wenn ir aktiv ist und kein soft PWM lässt sich der 4. Kanal nur ein und aus schalten
* Wenn ir aktiv ist muss soft PWM aktiv sein um den 4. Kanal auch zu dimmen
* Es wird nur ein zusätzlicher LED Kanal tatsächlich schon unterstützt. Der fünfte kommt noch
* Bei ir senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die Anderen sind aber einfach zu ergänzen
* Beim ir senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein

was noch kommt:
* besseres soft PWM
* mehr Konfiguration bezüglich default verhalten. ramp zeiten, delays, ...
* hsv Farbmodell um besser zu faden und vor allem um den Weißanteil automatisch auf die weißen LEDs zu legen
* die virtuellen channel
* fhem kompatibles ir senden
* sofortiges senden von Helligkeit und LED Spannung bei Änderung
* andere ir lib mit sehr viel besserer Geräte Unterstützung

wie gehabt muss alles über <code>config.h</code> mit Compilerschalter konfiguriert werden.

=== Arduino IDE 1.5 / 1.6 einrichten ===
Mit der Arduino IDE 1.5.x gab es zusätzlich eine [http://www.panstamp.com/news/panstamp-is-now-fully-arduino-1-5-enabled/ grundlegende Umstellungen der Arduino SWAP Library], für die der derzeitige Sketch [r4716] angepasst werden muss. Der Sketch ist nur kompatibel zur alten SWAP Library, die unter [[panStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0 installiert]] werden muss (Stand 01.05.2015).

=== Arduino IDE 1.0 einrichten ===
Zum Flashen der panStamps wird die [[panStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0.x benötigt]]. Für den RGBWW-Sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin <code>C:\Users\<username>\Documents\Arduino\libraries</code>. Am Ende der ganzen Aktion sollten sich in diesem Unterordner 3 neue Unterordner befinden: <code>IRremote, DMXSerial und panstamp</code>.

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von <code>libraries</code>.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von <code>libraries</code>. Weitere Informationen zur Verwendung von Arduino Librarys finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Librarys richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter dem Menüpunkt <code>Sketch/Library importieren</code> die 3 weiteren Punkte unten unter <code>beigetragen</code> auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino <code>libraries</code> Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter Sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Für das kompilieren mit INO siehe [[panStamp_Programmierung#INO|hier]].

=== Link zum Sketch ===
Die aktuelle Version des RGBWW-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge]. {{Link2Forum|Topic=13890 |Message=201391}}
Dieser muss in <code>Arduino\libraries\panstamp\examples\sketches</code> entpackt und die <code>rbgdriver.ino</code> gestartet werden. In der Arduino IDE sollte unter Tools->Board "Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega328" eingestellt sein. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert kann man in der IDE auch direkt panStamp als Plattform auswählen.

==== Kompillierte hex version ====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=121619}}

==== HEX-File ohne IR und DMX ====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=201955}}

=== Compilerschalter ===
Welche Features der sketch bietet lässt sich im <code>config.h</code> file durch ein- oder auskommentieren der <code>#define ENABLE_...</code> Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}}

==== #define ENABLE_DMX ====
#define ENABLE_DMX
Ermöglicht die Nutzung eines DMX RGB Einstellers zur Steuerung der RGB LEDs

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei <code>DMXSerial.h</code> die Zeile
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
in
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
abgeändert werden muss.

==== #define HAS_SENSOR ====
#define HAS_SENSOR
Ermöglicht die Nutzung eines DHT22 Sensors zur Auswertung von Temperatur und Luftfeuchtigkeit
Dafür sollten diese Konfigurationszeilen auskommentiert sein:
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;

In der <code>IRremote.cpp</code> Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>

sowie die <code>Irremote.h</code> Datei unter <code>Public:</code> um die Zeile
void disableIRIn();
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an Pin <code>A2</code> des panStamps angeschlossen werden.
Ein Beispiel für die Umrechnung der userReading für Spannung Temp etc. ist hier beschrieben: {{Link2Forum|Topic=12487 |Message=76489}}

=== Zusammenhänge der Konfiguration ===
Die Zusammenhänge der Konfiguration sind hier beschrieben {{Link2Forum|Topic=13890 |Message=175181}}

=== 4. und 5. LED Kanal TBC ===
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936

=== Alternativer Fade per Patch ===
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.

== IR Schnittstelle TBC ==
=== IR TBC ===
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267

=== IR-Belegung Panstamp RGB-Board TBC ===
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153

=== Ircluster TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331

=== Irgate TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278

== DMX Schnittstelle ==
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge

[[Kategorie:panStamp]]

PanStamp Programmierung

2015-08-06T13:58:07Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{SEITENTITEL:panStamp Programmierung}}
== Programmierung eines panStamp ==

=== Installation panStick ===
Für die Installation des panStick unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den panStick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [http://www.ftdichip.com/]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [https://www.youtube.com/watch?v=SPdSKT6KdF8].

=== Arduino IDE 1.0.x vorbereiten ===
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung für Arduino IDE 1.0 ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der panStamp/SWAP Librarys gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGBWW-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man lädt die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].
* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).
* Unter <code>Tools/Board</code> wird das '''passende Board''' ausgewählt, dass dem Chip auf dem panStamp entspricht. Für den panStamp AVR: <code>Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328</code>. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt <code>panStamp</code> als Plattform auswählen.
* Nun muss unter <code>Tools/Serieller Port</code> noch der richtigen '''Com-Port''' auswählen werden, unter dem der panStick eingebunden worden ist (entsprechend Gerätemanager).
* Als letztes unter <code>Tools/'''Programmer'''</code> noch den <code>AVRISPx mkII</code> auswählen.

=== Arduino IDE 1.6.x vorbereiten ===
Eine Installationsanleitung für Arduino IDE 1.6.4 ist unter folgendem Link zu finden:
:https://github.com/panStamp/panstamp/wiki/Installing-panStamp-cores-and-libraries-for-Arduino

=== Sketch vorbereiten, kompilieren und hochladen ===
* Den Sketch lädt man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompilieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den panStamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

=== Hexfile hochladen mit XLoader ===
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

== unter Linux ==

=== Installation panStick ===
Zum einen kann es sein, dass der panStick automatisch unter /dev/ttyUSBx eingebunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
lsusb
Sollte etwas Ähnliches zurückmelden:
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen. {{Link2Forum|Topic=12487 |Message=87746 }}

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
cat /proc/devices

Das Device wird dann angelegt mit:
sudo mknod /dev/ttyUSB0 c 188 0

Zusätzlich muss für den Betrieb des panStick das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
lsmod

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen. Damit wird der "Besitzer" festgelegt.
sudo chown root:dialout ttyUSBx

Hiermit werden die Berechtigungen gesetzt.
sudo chmod a+rw /dev/ttyUSBx

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören. Ist dieses nicht der Fall:
sudo adduser fhem dialout

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

=== IDE unter MacOS ===

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}

=== INO ===
Der RGB-Sketch wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die Arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
sudo apt-get install picocom python-pip arduino

Die Installation erfolgt im Anschluss über
sudo pip install ino

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
ino build

Und hochladen über
sudo ino upload

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}

== over-the-air (derzeit) nur NRG ==

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

== Was überlebt das Flashen==
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

== EEPROM löschen ==
Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
eepromToFactoryDefaults()

[[Kategorie:panStamp]]

PanStamp

2015-08-06T13:56:27Z

TeeVau: Schreibweise auf panStamp (kleines p)

{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}

Dieser Artikel, als mutmaßlicher Eingangsartikel zu dem Thema, beschreibt das FHEM Modul panStamp, was das Funkinterface zu FHEM bildet. Eine [[panStamp_(Systemübersicht)|Systemübersicht]] ist in einem separaten Artikel beschrieben. Der Focus liegt hier natürlich auf die Integration mit FHEM. Zu der Hardware [[panStamp]] gibt es Herstellerseitig eine eigenen Community mit [http://www.panstamp.org/forum/ Forum] und [https://github.com/panStamp/panstamp/wiki Wiki], sowie [https://github.com/panStamp/panstamp/wiki/Downloads Downloads] auf [https://github.com/panStamp Github].

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Der [[panStamp]] Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen". Zur Kommunikation in einem [[panStamp]] Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]). Um einen [[panStamp]] in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem Stück Draht in der [https://github.com/panStamp/panstamp/wiki/Antennae richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht, auch nicht auf kurze Distanzen!

== Allgemein ==
Die Integration in FHEM erfolgt über eine [[panStamp_(Systemübersicht)#FHEM_Module|Reihe von Modulen]] die im Folgenden und [[:Kategorie:panStamp|anderen]] Artikel genauer beschrieben sind. Das Modul [[panStamp]] erstellt dabei das IO-Device in FHEM.

== Voraussetzungen ==
Als Schnittstelle zwischen FHEM und einem [[panStamp]] Netzwerk dient entweder ein [[panStick]] (USB Stick mit aufgestecktem panStamp) oder ein panShield mit integriertem [[panStamp]] an einem Raspberry Pi. Der so angebundene [[panStamp]] wird mit einem (bei Auslieferung des panStamps vorinstallierten) [[panStick|Modem-Sketch]] als RF-Modem verwendet und über das FHEM Modul [[panStamp]] angesprochen. Der [[panStick]] kann auch per USB an einer anderen Serverhardware angebunden werden. Die Kommunikation zu FHEM erfolgt dann z.B. über ser2net oder FHEM2FHEM über LAN.

== Anwendung ==
=== Define ===
Das Device [[panStick]] wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss es manuell entsprechend folgendem Befehl angelegt werden:
define panStick panStamp /dev/ttyUSBx@38400
Die Schnittstelle (/dev/ttyUSBx) muss entsprechend der lokal verwendeten Schnittstelle angepasst werden. Für die Einrichtung des [[panStick]] innerhalb des Betriebssystem siehe [[Programmierung_eines_panStamp#Installation_panStick_2|hier]]

Dieses [[panStamp]] Device, der [[panStick]], versucht dann alle panStamps per [[SWAP]]-Broadcast zu finden und per [[autocreate]] anzulegen, wenn dieses aktiv sind. Die weitere Funktion übernimmt das Modul [[SWAP]], was das Funkprotokoll der [[panStamp]] Module in FHEM implementiert.

'''Betrieb an der Fritzbox'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernanschluss deaktiviert sein.

=== Attribute ===
Für den [[panStick]] gibt es keine modulspezifischen Attribute.

=== set-Befehle ===

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der [[panStick]] eingerichtet und meldet "Initialized", kann über das [[panStick]] device direkt eine raw Message abgesetzt werden. Diese ist zurzeit eigentlich immer eine SWAP Nachricht wie z.B.
set panStick raw 00010000010000

In diesem Beispiel wird ein Broadcast an alle abgesetzt, damit diese ihre ID und ihren ProductCode zurück an FHEM senden. Das macht der [[panStick]] nach dem Initialisieren auch einmal automatisch um alle nicht schlafenden Devices per [[autocreate]] anlegen zu können.
Mit diesem Befehl "raw" lassen sich [[SWAP]]-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

== Anwendungsbeispiele ==
=== Neue panStamps in Betrieb nehmen ===
'''Info: Das [[SWAP]] Modul unterstützt [[autocreate]]. Bei der Inbetriebnahme ist [[autocreate]] zu aktivieren!'''

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, da sie zuerst mit einer eindeutigen Device-Adresse (ungleich <code>FF</code> und grösser <code>01</code>) versehen werden müssen. Bei batteriebetriebenen Sensoren sollte auch das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
Für panStamp-Hardware im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald die panStamp-Hardware seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos aus FHEM die Reset-Taste an der panStamp-Hardware zu drücken oder die Stromquelle erneut zu verbinden.

Das [[SWAP]]-Modul versucht, panStamp-Hardware mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern. Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
Für batteriebetriebene panStamp-Hardware (genauer: Hardware die den Power-Down-Modus unterstützen) wird das Default Sendeintervall von <code>FFFF</code> zu <code>0384</code> (900 Sekunden) geändert.
Es gibt mit bestimmten [[panStamp]] lib Versionen das Problem das ein Wert von <code>FFFF</code> in Systemregister <code>0A</code> zum Überlauf führt und dann ununterbrochen SWAP Nachrichten gesendet werden. Im FHEM Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen Host-Systemen (z.B. FritzBox) nicht, weil der [[panStamp]] so schnell sendet, dass FHEM so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum Senden kommt.
Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Der Sketch ist dann zu flashen und wenn der Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen werden und der [[panStamp]] muss noch mal geflasht werden. Ansonsten wird die Adresse bei jedem Start erneut auf <code>5555</code> gesetzt.

= Weblinks =
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]

SWAP

2015-08-06T06:23:49Z

TeeVau: Rechtschreibfehler korrigiert und Baustelle entfernt

{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der PanStamp Baugruppen. Zur Kommunikation in einem PanStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. [[SWAP_0000002200000003]]) vorhanden sein. Diese Module bauen, als 3. Ebene, auf das SWAP Modul (2. Ebene) auf und bedienen im backend ebenfalls die panStamp-Hardware über die Register. Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
sudo apt-get install libxml-simple-perl
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das [[SWAP]] Modul greift auf das [[PanStamp]] Modul zu, was vorher per <code>define</code> angelegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über [https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol#registers-and-values '''Register'''], dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können.
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele, sketchabängige Userregister (<code>0B</code>-<code>xx</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers#custom-registers] bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files'', die in <code>.../FHEM/lib/SWAP</code> zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt''-ID [https://github.com/panStamp/panstamp/wiki/How-to-develop-your-own-SWAP-device#specify-your-product-code] gebildet wird. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
In den Systemregistern steht z.B. der ProductCode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert. Also z.B. Adresse <code>FF</code> und Intervall <code>FFFF</code> (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).
Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

Alle low Level Dinge wie Register ID oder Register Wert können mit '''hex Werten'' direkt angepasst werden.
set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
set <device> regSet 08 <Netzwerk ID als 2 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87436 }}

Das [[SWAP]]-Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Queue für panStamp-Hardware im power down Modus gehalten. Sobald die panStamp-Hardware online (SYNC Modus) kommt werden die Kommandos von FHEM automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des Device Definition Files automatisch erzeugt
* Es ist möglich direkt Endpoints (Teile eines Registers) zu schreiben
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulebene neben dem [[PanStamp]] FHEM-Modul (1. Ebene) für die Hardware und dem SWAP Modul (2. Ebene) für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP Devices ''zu Fuß'' über die Register ansprechen. Um die Register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann ein Modul der 3. Ebene notwendig. {{Link2Forum|Topic=12487 |Message=78502 }}

=== Define ===
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''
Wenn der [[panStick]] läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste Mal senden, z.B. nach dem Einschalten oder nach einem Reset. Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

PanStick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down Mode erfolgt dieses das erste Mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem ProductCode. Die ID ist die SWAP Device Adresse und bei einem frisch geflashten panStamp in der Regel <code>FF</code>. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0 - FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Adresse und das gibt Konflikte.

Wer mehrere Devices hat, sollte jedem nach dem Anlegen mit
set <device> regSet 09 <Device Adresse als 2 stellige hex zahl>
eine eigene ID zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* <code>00</code> ist die Broadcast-ID
* <code>01</code> ist die ID des [[panStick]] am FHEM-System
* <code>FF</code> ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* <code>F0-FE</code> sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID <code>FF</code> erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich <code>F0 - FE</code> und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
define <device> SWAP <ID>
Bis allerdings der ProductCode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch passiert, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der ID <reg> ab. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Definition-XML-File neu ein.

* clearUnconfirmed
Löscht die Liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von panStamps NRG unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <ProductCode>: Verwendet das SWAP_<ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der Empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (ProductCode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der ProductCode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Definition-XML-File ein. Erst wenn der ProductCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sketch:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Definition File ===
Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch ''menschenlesbare'' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>
attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}
</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen Readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>
attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}
</code>

Ein weiteres Beispiel ist das Definition File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele sketchabängige Userregister (<code>0B</code> - <code>xx</code>)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern stehen z.B. der ProductCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert, also z.B. die Adresse <code>FF</code> und das Intervall <code>FFFF</code> (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem ProductCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene PanStamps ===
panStamp Hardware mit power down Mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet. Normaler Weise werden dann die Register mit den Sensorwerten an FHEM gesendet. Power down Devices gehen danach schlafen (power down Modus mit extrem niedrigem Stromverbrauch) und wachen regelmäßig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modus keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich variieren und anders programmiert sein!

Nachrichten an eine panStamp-Hardware im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an die panStamp-Hardware geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <Intervall in Sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device definition file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von <code>FFFF</code> im Systemregister <code>0A</code> zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host Systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass FHEM mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum Senden kommt. Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf <code>0x5555</code> (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul eine panStamp-Hardware mit der Adresse <code>0xFF</code> wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich <code>0xF0 - 0xFE</code>. Das soll das Inbetriebnehmen von mehreren panStamp-Hardwaremodulen gleichzeitig erleichtern. Der automatisch vergeben Adressbereich ist begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fällen werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix Sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das Register <code>0A</code> konfigurierbar. Der Sensor wird an GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

<code>set <MyBodenfeuchte> stateFormat VWC_A%</code>

<code>
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)}, VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))}, voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}
</code>

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===
Es besteht die Möglichkeit, dass die Internals aus irgendeinem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
set <device> statusRequest
set <device> readDeviceXML

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiß welche Firmware auf der panStamp-Hardware ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}

=== register 0F is not known ===
{{Link2Forum|Topic=12487 |Message=84257}}

=== Komplette Übersicht eines Device ===
list <device>
{{Link2Forum|Topic=13890 |Message=201467}}

=== fehlender oder falsche ProductCode ===
Fehlt der ProductCode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den ProductCode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
set <device> statusRequest

{{Link2Forum|Topic=13890 |Message=201910}}

=== missing commands und register 00-0A unvollständig ===
Wenn in den INTERNALS missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register <code>00-0A</code> nicht vollständig sind und das INTERNAL "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}

=== Funktion des Autocreate ===
Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trotzdem <code>FF</code>. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde. {{Link2Forum|Topic=12487 |Message=88110}}

=== Adresse manuell setzen ===
Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
sudo apt-get install libxml-simple-perl

=== PanStamp antwortet nicht/EEprom to factory defaults ===
Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in <code>setup()</code> ein <code>eepromToFactoryDefaults()</code> aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen Sketch flashen. {{Link2Forum|Topic=13890 |Message=121677}}

=== Factory Defaults ===
Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die <code>setup()</code> Routine einfügen:
eepromToFactoryDefaults()
{{Link2Forum|Topic=13890 |Message=157125}}

=== Status LED ===
Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit <code>#define LED_DEBUG</code> mit "//" auskommentiert. {{Link2Forum|Topic=13890 |Message=164731}}

== Links ==

[[Kategorie:panStamp]]

PanStamp Programmierung

2015-08-06T05:52:22Z

TeeVau: Rechtschreibfehler korrigiert und Baustelle entfernt

{{SEITENTITEL:panStamp Programmierung}}
== Programmierung eines panStamp ==

=== Installation panStick ===
Für die Installation des panStick unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den panStick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [http://www.ftdichip.com/]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [https://www.youtube.com/watch?v=SPdSKT6KdF8].

=== Arduino IDE 1.0.x vorbereiten ===
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung für Arduino IDE 1.0 ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der panStamp/SWAP Librarys gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGBWW-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man lädt die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].
* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).
* Unter <code>Tools/Board</code> wird das '''passende Board''' ausgewählt, dass dem Chip auf dem PanStamp entspricht. Für den panStamp AVR: <code>Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328</code>. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt <code>panStamp</code> als Plattform auswählen.
* Nun muss unter <code>Tools/Serieller Port</code> noch der richtigen '''Com-Port''' auswählen werden, unter dem der panStick eingebunden worden ist (entsprechend Gerätemanager).
* Als letztes unter <code>Tools/'''Programmer'''</code> noch den <code>AVRISPx mkII</code> auswählen.

=== Arduino IDE 1.6.x vorbereiten ===
Eine Installationsanleitung für Arduino IDE 1.6.4 ist unter folgendem Link zu finden:
:https://github.com/panStamp/panstamp/wiki/Installing-panStamp-cores-and-libraries-for-Arduino

=== Sketch vorbereiten, kompilieren und hochladen ===
* Den Sketch lädt man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompilieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den panStamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

=== Hexfile hochladen mit XLoader ===
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

== unter Linux ==

=== Installation panStick ===
Zum einen kann es sein, dass der panStick automatisch unter /dev/ttyUSBx eingebunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
lsusb
Sollte etwas Ähnliches zurückmelden:
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen. {{Link2Forum|Topic=12487 |Message=87746 }}

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
cat /proc/devices

Das Device wird dann angelegt mit:
sudo mknod /dev/ttyUSB0 c 188 0

Zusätzlich muss für den Betrieb des panStick das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
lsmod

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen. Damit wird der "Besitzer" festgelegt.
sudo chown root:dialout ttyUSBx

Hiermit werden die Berechtigungen gesetzt.
sudo chmod a+rw /dev/ttyUSBx

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören. Ist dieses nicht der Fall:
sudo adduser fhem dialout

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

=== IDE unter MacOS ===

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}

=== INO ===
Der RGB-Sketch wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die Arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
sudo apt-get install picocom python-pip arduino

Die Installation erfolgt im Anschluss über
sudo pip install ino

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
ino build

Und hochladen über
sudo ino upload

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}

== over-the-air (derzeit) nur NRG ==

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

== Was überlebt das Flashen==
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

== EEPROM löschen ==
Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
eepromToFactoryDefaults()

[[Kategorie:panStamp]]

PanStamp

2015-08-06T05:47:28Z

TeeVau: Rechtschreibfehler korrigiert und Baustelle entfernt

{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}

Dieser Artikel, als mutmaßlicher Eingangsartikel zu dem Thema, beschreibt das FHEM Modul panStamp, was das Funkinterface zu FHEM bildet. Eine [[panStamp_(Systemübersicht)|Systemübersicht]] ist in einem separaten Artikel beschrieben. Der Focus liegt hier natürlich auf die Integration mit FHEM. Zu der Hardware [[panStamp]] gibt es Herstellerseitig eine eigenen Community mit [http://www.panstamp.org/forum/ Forum] und [https://github.com/panStamp/panstamp/wiki Wiki], sowie [https://github.com/panStamp/panstamp/wiki/Downloads Downloads] auf [https://github.com/panStamp Github].

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Der [[panStamp]] Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen". Zur Kommunikation in einem [[panStamp]] Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]). Um einen [[panStamp]] in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem Stück Draht in der [https://github.com/panStamp/panstamp/wiki/Antennae richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht, auch nicht auf kurze Distanzen!

== Allgemein ==
Die Integration in FHEM erfolgt über eine [[PanStamp_(Systemübersicht)#FHEM_Module|Reihe von Modulen]] die im Folgenden und [[:Kategorie:PanStamp|anderen]] Artikel genauer beschrieben sind. Das Modul [[panStamp]] erstellt dabei das IO-Device in FHEM.

== Voraussetzungen ==
Als Schnittstelle zwischen FHEM und einem [[panStamp]] Netzwerk dient entweder ein [[panStick]] (USB Stick mit aufgestecktem panStamp) oder ein panShield mit integriertem [[panStamp]] an einem Raspberry Pi. Der so angebundene [[panStamp]] wird mit einem (bei Auslieferung des panStamps vorinstallierten) [[panStick|Modem-Sketch]] als RF-Modem verwendet und über das FHEM Modul [[panStamp]] angesprochen. Der [[panStick]] kann auch per USB an einer anderen Serverhardware angebunden werden. Die Kommunikation zu FHEM erfolgt dann z.B. über ser2net oder FHEM2FHEM über LAN.

== Anwendung ==
=== Define ===
Das Device [[panStick]] wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss es manuell entsprechend folgendem Befehl angelegt werden:
define panStick panStamp /dev/ttyUSBx@38400
Die Schnittstelle (/dev/ttyUSBx) muss entsprechend der lokal verwendeten Schnittstelle angepasst werden. Für die Einrichtung des [[panStick]] innerhalb des Betriebssystem siehe [[Programmierung_eines_panStamp#Installation_panStick_2|hier]]

Dieses [[panStamp]] Device, der [[panStick]], versucht dann alle panStamps per [[SWAP]]-Broadcast zu finden und per [[autocreate]] anzulegen, wenn dieses aktiv sind. Die weitere Funktion übernimmt das Modul [[SWAP]], was das Funkprotokoll der [[panStamp]] Module in FHEM implementiert.

'''Betrieb an der Fritzbox'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernanschluss deaktiviert sein.

=== Attribute ===
Für den [[panStick]] gibt es keine modulspezifischen Attribute.

=== set-Befehle ===

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der [[panStick]] eingerichtet und meldet "Initialized", kann über das [[panStick]] device direkt eine raw Message abgesetzt werden. Diese ist zurzeit eigentlich immer eine SWAP Nachricht wie z.B.
set panStick raw 00010000010000

In diesem Beispiel wird ein Broadcast an alle abgesetzt, damit diese ihre ID und ihren ProductCode zurück an FHEM senden. Das macht der [[panStick]] nach dem Initialisieren auch einmal automatisch um alle nicht schlafenden Devices per [[autocreate]] anlegen zu können.
Mit diesem Befehl "raw" lassen sich [[SWAP]]-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

== Anwendungsbeispiele ==
=== Neue panStamps in Betrieb nehmen ===
'''Info: Das [[SWAP]] Modul unterstützt [[autocreate]]. Bei der Inbetriebnahme ist [[autocreate]] zu aktivieren!'''

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, da sie zuerst mit einer eindeutigen Device-Adresse (ungleich <code>FF</code> und grösser <code>01</code>) versehen werden müssen. Bei batteriebetriebenen Sensoren sollte auch das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
Für panStamp-Hardware im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald die panStamp-Hardware seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos aus FHEM die Reset-Taste an der panStamp-Hardware zu drücken oder die Stromquelle erneut zu verbinden.

Das [[SWAP]]-Modul versucht, panStamp-Hardware mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern. Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
Für batteriebetriebene panStamp-Hardware (genauer: Hardware die den Power-Down-Modus unterstützen) wird das Default Sendeintervall von <code>FFFF</code> zu <code>0384</code> (900 Sekunden) geändert.
Es gibt mit bestimmten [[panStamp]] lib Versionen das Problem das ein Wert von <code>FFFF</code> in Systemregister <code>0A</code> zum Überlauf führt und dann ununterbrochen SWAP Nachrichten gesendet werden. Im FHEM Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen Host-Systemen (z.B. FritzBox) nicht, weil der [[panStamp]] so schnell sendet, dass FHEM so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum Senden kommt.
Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Der Sketch ist dann zu flashen und wenn der Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen werden und der [[panStamp]] muss noch mal geflasht werden. Ansonsten wird die Adresse bei jedem Start erneut auf <code>5555</code> gesetzt.

= Weblinks =
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]

Benutzer Diskussion:TeeVau

2015-07-31T08:14:33Z

TeeVau: /* oder oder */

PID20 - Der PID-Regler

2015-07-31T08:11:46Z

TeeVau: code und pre Tags angepasst

{{Infobox Modul
|Name=PID20
|ModPurpose=Regler nach P-I-D Algorithmus
|ModType=d

|ModCmdRef=PID20
|ModForumArea=Automatisierung
|ModTechName=98_PID20.pm
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])
}}
'''PID20''' ist ein Modul, das nach dem P-I-D Algorithmus einen Regler realisiert.

== Projekt-Status ==

Das Modul ist seit dem 26.03.2014 Bestandteil von FHEM.

== Features ==
* einstellbarer Bewertungs-/Berechnungszyklus
* Überwachung des Istwert-Gebers über dessen Zeitstempel (Sensorausfall)
* Skalierbarkeit der Ausgabehäufigkeit an das Stellglied über Zeit und Mindeständerung
* Zwangsausgabe an das Stellglied nach Ablauf eines einstellbaren Zeitintervalls
* Notstellung des Stellgliedes, falls Istwert-Geber ausgefallen ist
* Begrenzung des Stellbereichs nach oben und unten
* Festlegung der Nachkommastellen (0..5) des Ausgabewertes zum Stellglied
* Festlegen einer minimalen Regelabweichung, ab der der Regler aktiv wird
* Festlegen des Reading-Namens für den Sollwert
* Festlegen des Reading-Namens für den Istwert
* Invertierung des Reglerwirksinns
* Festlegen der minimalen Aktualisierungsrate der Readings
* Festlegen der Proportionalitätskonstanten P,I,D
== Thread im Forum ==
[http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 Diskussion zu PID20 im Forum]

=== Define ===
<code>
define <name> PID20 sensor[:reading[:regexp]] actor:cmd
</code>

=== Attribute ===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|pidActorValueDecPlaces||[0..5]||0||Anzahl der Nachkommastellen für Ausgabewert zu Aktor
|-
|pidActorInterval||uint||180||minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann
|-
|pidActorThreshold||uint||1||Notwendige minimale Änderung zum Altwert der Stellgliedausgabe, damit diese erneut erfolgt
|-
|pidActorErrorAction||[freeze, errorPos]||freeze||legt das Verhalten der Ausgabe zum Stellglied fest, wenn der Istwert nicht innerhalb von <pidSensorTimeout> aktualisiert wurde (Sensor-Ausfall) <br />
freeze: Position des Stellgliedes beibehalten<br />
ErrorPos: Position anfahren, die unter Attribut <pidActorErrorPos> angegeben ist."
|-
|pidActorErrorPos||int||0||Diese Position ist einzunehmen, wenn pidActorErrorAction auf errorPos steht und der Istwert-Geber ausgefallen ist.
|-
|pidActorKeepAlive||uint||1800||Spätestens nach dieser Zeit erfolgt eine Zwangsausgabe an das Stellglied
(wenn PID nicht disabled und nicht stopped)
|-
|pidActorLimitLower||float||0||untere Begrenzung für das Stellglied
|-
|pidActorLimitUpper||float||100||obere Begrenzung für das Stellglied
|-
|pidCalcInterval||uint||60||Berechnungszyklus in Sekunden, nach dem die PID-Berechnung durchgeführt wird.
|-
|pidDeltaTreshold||pos. float||0||wenn die Regeldifferenz(delta) kleiner als pidDeltaThreshold, dann wird der Regler eingefroren (state=idle)
|-
|pidDesiredName||string||desired||Name für das Reading, das den Sollwert für den Regler aufnehmen soll
|-
|pidMeasuredName||string||measured||Name für das Reading, das den Istwert für den Regler aufnehmen soll
|-
|pidSensorTimeout||uint||3600||Zeitlimit in Sekunden, nach dessen Überschreitung der Ausfall des Istwert-Gebers anzunehmen ist
|-
|pidReverseAction||[0,1]||0||Umgekehrter Wirksinn des Reglers
|-
|pidUpdateInterval||uint||300||Zeitlimit in Sekunden, nach der ein Zwangsupdate der Readings erfolgen muss (Kurvendarstellung).
|-
|pidFactor_P||pos. float||25||Proportionalitätskonstante für P-Anteil

|-
|pidFactor_I||pos. float||0.25||Proportionalitätskonstante für I-Anteil

|-
|pidFactor_D||pos. float||0||Proportionalitätskonstante für D-Anteil
|-
|disable||[0,1]||0||Freigabe/Sperren des Reglers
|}

=== Setter ===
'''desired'''
* Funktion: Sollwert einstellen
* Name des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden

'''start'''
* PID nimmt den Betrieb wieder auf, es werden P-, I- und D-Anteil vor dem Stop übernommen

'''stop'''
* PID geht in den Zustand stopped; alles wird praktisch eingefroren

'''restart'''
* arbeitet zunächst wie Start, jedoch gibt man an, mit welchen Prozentwert der Stellausgang anfangs stehen soll

=== Readings ===
[[Datei:13 10 20 Pid readings.png]]
* actuation liefert den tatsächlichen Ausgabewert an das Stellglied
* actuationCalc liefert den internen Rechenwert des Ausgabewertes für das Stellglied(ohne Begrenzung)
* delta, die aktuelle Regeldifferenz
* desired (Name ist variabel), der Sollwert
* measured (Name ist variabel), der aktuelle Wert vom Istwert-geber
* p_p, der P-Anteil des Ausgabewertes für das Stellglied
* p_i, der I-Anteil des Ausgabewertes für das Stellglied
* p_d, der D-Anteil des Ausgabewertes für das Stellglied
* state, der Betriebszustand des Reglers

'''delta'''

<code>
delta = desired - measured (also Sollwert-Istwert)
</code>

'''actuation'''

<code>
actuation = actuationCalc
</code>

jedoch begrenzt durch pidActorLimitLower und pidActorLimitUpper
und formatiert via pidActorValueDecPlaces

'''actuationCalc'''

Der Ausgabewert für das Stellglied wird wie folgt berechnet

<code>
actuationCalc = p_p + p_i + p_d
</code>

'''state'''

{| class="wikitable"
|-
! state !! Erläuterung
|-
| disabled || PID-Instanz ist inaktiv
|-
| initializing || Modul wurde initialisiert
|-
| idle || Berechnung ist inaktiv
|-
| processing || Berechnung ist aktiv, Normalbetrieb
|-
| alarm || Ausnahmezustand, z.B. Timout des Istwert-Gebers
|}

== Inbetriebnahme ==
* PID20 definieren, hier mit HMS100TF als Istwert-Geber für die Temperatur und ein MAX-Thermostat als Stellglied; Auslegung für eine Fußbodenheizung (sehr träge)
<code>
define PID.FUBO PID20 DG.BAD.TF:temperature HT.FUBO:maxValveSetting
</code>
:* <sensor> = "DG.BAD.TF": Name des Istwert-Geber s (HMS100TF)
:* <reading> = "temperature": das Reading vom HMS100TF, das die Temperatur liefert
:* <regexp> = nicht definiert, wir können also direkt den Wert des Readings verwenden
:* <actor> = "HT.FUBO" : Name des MAX-Thermostats, das als Stellglied verwendet wird
:* <cmd> = "maxValveSetting" : Das Kommando mit dem PID20 die Stellausgabe realisieren soll
<br />
Letztlich wird mit <actor> und <cmd> Folgendes ausgeführt

<code>
set <actor> <cmd> <setting-value>
</code>

'''zusätzlich noch einige Attribute anpassen'''
* die Ausgabehäufigkeit an das Stellglied auf 15 Minuten begrenzen
<code>attr PID.FUBO pidActorInterval 900</code>
* nur dann einen Wert an das Stellglied ausgeben, wenn die Differenz zum Altwert >= 5%
<code>attr PID.FUBO pidActorTreshold 5</code>
* Nachommastellen für das Stellglied festlegen; MAX-Thermostate erlauben nur Werte ohne Nachkommastellen
<code>attr PID.FUBO pidActorValueDecPlaces 0</code>
* I-Faktor festlegen; Überlegung: bei einer Regelabweichung von 1 Grad, soll der I-Anteil um 0.2% pro Minute inkrementieren/dekrementieren
<code>attr PID.FUBO pidFactor_I 0.2</code>
* P-Faktor festlegen; Überlegung:Bei einer Regel-Abweichung von 1 Grad, soll der P-Anteil +/-50% betragen
<code>attr PID.FUBO pidFactor_P 50</code>
* Häufigkeit der Events begrenzen: Die Readings werden im Intervall von "pidCalcInterval" aktualisiert. Die damit erzeugten Events kann man mit den Standard-Mechanismen von FHEM begrenzen. Hier wird festgelegt, daß die Readings nur dann einen Event feuern, wenn diese sich tatsächlich ändern. Der Wert hinter dem Doppelpunkt, gibt die Mindeständerung an. Fehlt dieser feuert jede Änderung einen Event.
<code>attr PID.FUBO event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0</code>
* Events feuern, wenn sich über lange Zeit eine Reading nicht ändert: Wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert.(sinnvoll für Charts, hier z.B. alle 30 Minuten).
<code>attr PID.FUBO event-min-interval actuation:1800,actuationCalc:1800,delta:1800,desired:1800,measured:1800,p_d:1800,p_i:1800,p_p:1800</code>

'''Chart einrichten'''<br/>
Es ist für das Einstellen der Regel-Faktoren (P,I,D) überaus hilfreich, das Verhalten über die Zeit aufzuzeichnen, um das Verhalten objektiv beurteilen zu können.<br/>

;Zunächst ein Filelog einrichten<br/>
:define PID.FUBO.File FileLog ./log/PID.FUBO-%Y.log PID\.FUBO
:attr PID.FUBO.File logtype text

Danach ein Chart definieren, angelehnt an folgendem Beispiel:

[[Datei:13_12_03_PID_ChartDef.png]]

Anbei ein Vorschlag für au

== Hintergrund-Informationen ==
=== list <pid-name> ===
<pre>
Internals:
DEF DG.BAD.TF PID.Actor:state
NAME PID.PID
NR 616
NTFY_ORDER 50-PID.PID
STATE processing
TYPE PID
Readings:
2013-10-20 17:13:41 actuation 97
2013-10-20 17:21:42 actuationCalc 97.2079999999999
2013-10-20 17:21:42 delta 0.199999999999999
2013-10-20 17:13:41 desired 22
2013-10-20 17:13:41 measured 21.8
2013-10-20 17:21:42 p_d 0
2013-10-20 17:21:42 p_i 92.2079999999999
2013-10-20 17:21:42 p_p 4.99999999999998
2013-10-20 17:21:42 state processing
Helper:
actor PID.Actor
actorCommand state
actorErrorAction freeze
actorErrorPos 0
actorInterval 300
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 4
actorTimestamp 2013-10-20 17:13:41
actorValueDecPlaces 0
calcInterval 60
deltaGradient 0
deltaOld 0.199999999999999
deltaOldTS 2013-10-20 17:18:07
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP 0
measuredName measured
reading temperature
regexp ([\d\.]*)
reverseAction 0
sensor DG.BAD.TF
sensorTimeout 3600
updateInterval 600
Attributes:
pidActorInterval 300
pidActorTreshold 4
pidActorValueDecPlaces 0
room PID
verbose 4
</pre>

=== Anti-WindUp-Strategie ===
Der integrale Anteil des PID-Reglers wird ohne Gegenmassnahmen auch dann weiter integriert,
wenn das Stellglied bereits an seine Grenzen gestossen ist.
Dies hat den Nachteil, dass nach einer Reduzierung der Regeldifferenz lange Wartezeiten entstehen können, bis das
Stellglied reagiert.
Dies nennt man den WindUP-Effekt.
Hierzu wurde die folgende Strategie entwickelt:

[[Datei:13 10 20 PID Windup.png|WindUP]]

Sobald das rechnerische Stellsignal (Ventilstellung Calc=actuationCalc) die obere Grenze des Stellgliedes überschreitet (pidActorLimitUpper) oder die untere Grenze unterschreitet (pidActorLimitLower), wird die Integration des I-Anteils eingefroren.

'''Am Beispiel:'''
An Position L1 überschreitet der rechnerische Ausgabewert des Stellgliedes die obere Grenze (100%).
Der I-Anteil verändert sich nicht mehr bis zur Position L2. Hier unterschreitet der Ausgabewert die
obere Grenze, der I-Anteil kann wieder verändert werden.

== Fragen und Antworten ==
=== Temperatur im Raum steigt nicht oder stark verzögert, was kann ich tun ? ===

==== 1.Fehlerquelle : Heizsystem ist nicht ausreichend entlüftet ====
In diesem Fall behindern die Luftblasen im System den Durchfluss des Heizmediums.<br/>
Der Heizkörper erwärmt sich nur teilweise oder "gluckert".
Hier ist das Entlüften der Heizkörper angesagt.<br/><br/>
Natürlich können sich die Gasblasen an anderer Stelle befinden.
Normalerweise sorgen automatische Entlüfter, dass das Gas entweichen kann.<br/>
Aber auch diese "verkalken" im Lauf der Zeit.

==== 2.Fehlerquelle : Totzone beim Stellglied ====
Der Temperaturanstieg erfolgt erst ab einer bestimmten Ventilöffnung von xy%.<br/>
Der PID-Regler geht davon aus, dass jede Änderung des Stellausgangs auf die Regelgröße wirkt<br/>
(also bei Ventil weiter öffnen, wird mehr Wärme abgegeben)<br/><br/>
Ist dies nicht der Fall, wird der PID über die Zeit (I-Anteil) das Ventil weiter öffnen.<br/>
Allerdings vergeht hierbei Zeit und damit leidet die Regelgüte.<br/><br/>

Es ist also wichtig die Totzone zu ermitteln und im Attribut pidActorLimitLower zu hinterlegen.

==== 3.Fehlerquelle : Hydraulische Fehlanpassung ====
Wenn einzelnen Heizkreise einen sehr kleinen hydraulischen Widerstand aufweisen, kann es passieren
das Heizkreise mit höherem Widerstand zeitweise unterversorgt sind.<br/><br/>
Erst wenn die gut versorgten Heizkreise die Ventile schließen (Soll-Temperatur ist erreicht),
werden die Heizkreise mit hohem Widerstand ausreichend versorgt.<br/><br/>
Dies kann man dank FHEM sehr gut über die Charts nachvollziehen.<br/>
Es ist regelungstechnisch, ökologisch und energetisch absolut sinnvoll geregelte Hocheffizienz-Pumpen
im Heizkreis einzusetzen. Diese sorgen für konstanten Druck im Hauptstrang bei sehr geringen Energiebedarf.<br/>

Man kann gezielt den hydraulischen Widerstand einzelner Thermostate erhöhen, indem man deren maximale Ventilöffnung begrenzt.<br/>

Dies erreicht man durch Reduzieren des Wertes pidActorLimitUpper.<br/>
Dies ist gleichbedeutend mit der Erhöhung der hydraulischen Widerstandes durch voreinstellbare Heizungsventile beim hydraulischen Abgleich.

== Weblinks ==

* [http://forum.fhem.de/index.php/topic,15060.0.html Initialer Forumseintrag zur Überarbeitung des PID-Moduls]
* [http://de.wikipedia.org/wiki/Regler Wikipedia Regler]

[[Kategorie:Glossary]]
[[Kategorie:Regelungstechnik]]

PID20 - Der PID-Regler

2015-07-30T09:35:04Z

TeeVau: Kleinigkeiten in der Darstellung geändert

{{Infobox Modul
|Name=PID20
|ModPurpose=Regler nach P-I-D Algorithmus
|ModType=d

|ModCmdRef=PID20
|ModForumArea=Automatisierung
|ModTechName=98_PID20.pm
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])
}}
'''PID20''' ist ein Modul, das nach dem P-I-D Algorithmus einen Regler realisiert.

== Projekt-Status ==

Das Modul ist seit dem 26.03.2014 Bestandteil von FHEM.

== Features ==
* einstellbarer Bewertungs-/Berechnungszyklus
* Überwachung des Istwert-Gebers über dessen Zeitstempel (Sensorausfall)
* Skalierbarkeit der Ausgabehäufigkeit an das Stellglied über Zeit und Mindeständerung
* Zwangsausgabe an das Stellglied nach Ablauf eines einstellbaren Zeitintervalls
* Notstellung des Stellgliedes, falls Istwert-Geber ausgefallen ist
* Begrenzung des Stellbereichs nach oben und unten
* Festlegung der Nachkommastellen (0..5) des Ausgabewertes zum Stellglied
* Festlegen einer minimalen Regelabweichung, ab der der Regler aktiv wird
* Festlegen des Reading-Namens für den Sollwert
* Festlegen des Reading-Namens für den Istwert
* Invertierung des Reglerwirksinns
* Festlegen der minimalen Aktualisierungsrate der Readings
* Festlegen der Proportionalitätskonstanten P,I,D
== Thread im Forum ==
[http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 Diskussion zu PID20 im Forum]

=== Define ===
<pre>
define <name> PID20 sensor[:reading[:regexp]] actor:cmd
</pre>

=== Attribute ===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|pidActorValueDecPlaces||[0..5]||0||Anzahl der Nachkommastellen für Ausgabewert zu Aktor
|-
|pidActorInterval||uint||180||minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann
|-
|pidActorThreshold||uint||1||Notwendige minimale Änderung zum Altwert der Stellgliedausgabe, damit diese erneut erfolgt
|-
|pidActorErrorAction||[freeze, errorPos]||freeze||legt das Verhalten der Ausgabe zum Stellglied fest, wenn der Istwert nicht innerhalb von <pidSensorTimeout> aktualisiert wurde (Sensor-Ausfall) <br />
freeze: Position des Stellgliedes beibehalten<br />
ErrorPos: Position anfahren, die unter Attribut <pidActorErrorPos> angegeben ist."
|-
|pidActorErrorPos||int||0||Diese Position ist einzunehmen, wenn pidActorErrorAction auf errorPos steht und der Istwert-Geber ausgefallen ist.
|-
|pidActorKeepAlive||uint||1800||Spätestens nach dieser Zeit erfolgt eine Zwangsausgabe an das Stellglied
(wenn PID nicht disabled und nicht stopped)
|-
|pidActorLimitLower||float||0||untere Begrenzung für das Stellglied
|-
|pidActorLimitUpper||float||100||obere Begrenzung für das Stellglied
|-
|pidCalcInterval||uint||60||Berechnungszyklus in Sekunden, nach dem die PID-Berechnung durchgeführt wird.
|-
|pidDeltaTreshold||pos. float||0||wenn die Regeldifferenz(delta) kleiner als pidDeltaThreshold, dann wird der Regler eingefroren (state=idle)
|-
|pidDesiredName||string||desired||Name für das Reading, das den Sollwert für den Regler aufnehmen soll
|-
|pidMeasuredName||string||measured||Name für das Reading, das den Istwert für den Regler aufnehmen soll
|-
|pidSensorTimeout||uint||3600||Zeitlimit in Sekunden, nach dessen Überschreitung der Ausfall des Istwert-Gebers anzunehmen ist
|-
|pidReverseAction||[0,1]||0||Umgekehrter Wirksinn des Reglers
|-
|pidUpdateInterval||uint||300||Zeitlimit in Sekunden, nach der ein Zwangsupdate der Readings erfolgen muss (Kurvendarstellung).
|-
|pidFactor_P||pos. float||25||Proportionalitätskonstante für P-Anteil

|-
|pidFactor_I||pos. float||0.25||Proportionalitätskonstante für I-Anteil

|-
|pidFactor_D||pos. float||0||Proportionalitätskonstante für D-Anteil
|-
|disable||[0,1]||0||Freigabe/Sperren des Reglers
|}

=== Setter ===
'''desired'''
* Funktion: Sollwert einstellen
* Name des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden

'''start'''
* PID nimmt den Betrieb wieder auf, es werden P-, I- und D-Anteil vor dem Stop übernommen

'''stop'''
* PID geht in den Zustand stopped; alles wird praktisch eingefroren

'''restart'''
* arbeitet zunächst wie Start, jedoch gibt man an, mit welchen Prozentwert der Stellausgang anfangs stehen soll

=== Readings ===
[[Datei:13 10 20 Pid readings.png]]
* actuation liefert den tatsächlichen Ausgabewert an das Stellglied
* actuationCalc liefert den internen Rechenwert des Ausgabewertes für das Stellglied(ohne Begrenzung)
* delta, die aktuelle Regeldifferenz
* desired (Name ist variabel), der Sollwert
* measured (Name ist variabel), der aktuelle Wert vom Istwert-geber
* p_p, der P-Anteil des Ausgabewertes für das Stellglied
* p_i, der I-Anteil des Ausgabewertes für das Stellglied
* p_d, der D-Anteil des Ausgabewertes für das Stellglied
* state, der Betriebszustand des Reglers

'''delta'''
<pre>
delta = desired - measured (also Sollwert-Istwert)
</pre>

'''actuation'''
<pre>
actuation = actuationCalc
</pre>
jedoch begrenzt durch pidActorLimitLower und pidActorLimitUpper
und formatiert via pidActorValueDecPlaces

'''actuationCalc'''

Der Ausgabewert für das Stellglied wird wie folgt berechnet
<pre>
actuationCalc = p_p + p_i + p_d
</pre>

'''state'''

{| class="wikitable"
|-
! state !! Erläuterung
|-
| disabled || PID-Instanz ist inaktiv
|-
| initializing || Modul wurde initialisiert
|-
| idle || Berechnung ist inaktiv
|-
| processing || Berechnung ist aktiv, Normalbetrieb
|-
| alarm || Ausnahmezustand, z.B. Timout des Istwert-Gebers
|}

== Inbetriebnahme ==
* PID20 definieren, hier mit HMS100TF als Istwert-Geber für die Temperatur und ein MAX-Thermostat als Stellglied; Auslegung für eine Fußbodenheizung (sehr träge)
<pre>define PID.FUBO PID20 DG.BAD.TF:temperature HT.FUBO:maxValveSetting</pre>
:* <sensor> = "DG.BAD.TF": Name des Istwert-Geber s (HMS100TF)
:* <reading> = "temperature": das Reading vom HMS100TF, das die Temperatur liefert
:* <regexp> = nicht definiert, wir können also direkt den Wert des Readings verwenden
:* <actor> = "HT.FUBO" : Name des MAX-Thermostats, das als Stellglied verwendet wird
:* <cmd> = "maxValveSetting" : Das Kommando mit dem PID20 die Stellausgabe realisieren soll
<br />
Letztlich wird mit <actor> und <cmd> Folgendes ausgeführt
<pre>set <actor> <cmd> <setting-value> </pre>

'''zusätzlich noch einige Attribute anpassen'''
* die Ausgabehäufigkeit an das Stellglied auf 15 Minuten begrenzen
<pre>attr PID.FUBO pidActorInterval 900</pre>
* nur dann einen Wert an das Stellglied ausgeben, wenn die Differenz zum Altwert >= 5%
<pre>attr PID.FUBO pidActorTreshold 5</pre>
* Nachommastellen für das Stellglied festlegen; MAX-Thermostate erlauben nur Werte ohne Nachkommastellen
<pre>attr PID.FUBO pidActorValueDecPlaces 0</pre>
* I-Faktor festlegen; Überlegung: bei einer Regelabweichung von 1 Grad, soll der I-Anteil um 0.2% pro Minute inkrementieren/dekrementieren
<pre>attr PID.FUBO pidFactor_I 0.2</pre>
* P-Faktor festlegen; Überlegung:Bei einer Regel-Abweichung von 1 Grad, soll der P-Anteil +/-50% betragen
<pre>attr PID.FUBO pidFactor_P 50</pre>
* Häufigkeit der Events begrenzen: Die Readings werden im Intervall von "pidCalcInterval" aktualisiert. Die damit erzeugten Events kann man mit den Standard-Mechanismen von FHEM begrenzen. Hier wird festgelegt, daß die Readings nur dann einen Event feuern, wenn diese sich tatsächlich ändern. Der Wert hinter dem Doppelpunkt, gibt die Mindeständerung an. Fehlt dieser feuert jede Änderung einen Event.
<pre>attr PID.FUBO event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0</pre>
* Events feuern, wenn sich über lange Zeit eine Reading nicht ändert: Wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert.(sinnvoll für Charts, hier z.B. alle 30 Minuten).
<pre>attr PID.FUBO event-min-interval actuation:1800,actuationCalc:1800,delta:1800,desired:1800,measured:1800,p_d:1800,p_i:1800,p_p:1800</pre>

'''Chart einrichten'''<br/>
Es ist für das Einstellen der Regel-Faktoren (P,I,D) überaus hilfreich, das Verhalten über die Zeit aufzuzeichnen, um das Verhalten objektiv beurteilen zu können.<br/>

;Zunächst ein Filelog einrichten<br/>
:define PID.FUBO.File FileLog ./log/PID.FUBO-%Y.log PID\.FUBO
:attr PID.FUBO.File logtype text

Danach ein Chart definieren, angelehnt an folgendem Beispiel:

[[Datei:13_12_03_PID_ChartDef.png]]

Anbei ein Vorschlag für au

== Hintergrund-Informationen ==
=== list <pid-name> ===
<pre>
Internals:
DEF DG.BAD.TF PID.Actor:state
NAME PID.PID
NR 616
NTFY_ORDER 50-PID.PID
STATE processing
TYPE PID
Readings:
2013-10-20 17:13:41 actuation 97
2013-10-20 17:21:42 actuationCalc 97.2079999999999
2013-10-20 17:21:42 delta 0.199999999999999
2013-10-20 17:13:41 desired 22
2013-10-20 17:13:41 measured 21.8
2013-10-20 17:21:42 p_d 0
2013-10-20 17:21:42 p_i 92.2079999999999
2013-10-20 17:21:42 p_p 4.99999999999998
2013-10-20 17:21:42 state processing
Helper:
actor PID.Actor
actorCommand state
actorErrorAction freeze
actorErrorPos 0
actorInterval 300
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 4
actorTimestamp 2013-10-20 17:13:41
actorValueDecPlaces 0
calcInterval 60
deltaGradient 0
deltaOld 0.199999999999999
deltaOldTS 2013-10-20 17:18:07
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP 0
measuredName measured
reading temperature
regexp ([\d\.]*)
reverseAction 0
sensor DG.BAD.TF
sensorTimeout 3600
updateInterval 600
Attributes:
pidActorInterval 300
pidActorTreshold 4
pidActorValueDecPlaces 0
room PID
verbose 4
</pre>

=== Anti-WindUp-Strategie ===
Der integrale Anteil des PID-Reglers wird ohne Gegenmassnahmen auch dann weiter integriert,
wenn das Stellglied bereits an seine Grenzen gestossen ist.
Dies hat den Nachteil, dass nach einer Reduzierung der Regeldifferenz lange Wartezeiten entstehen können, bis das
Stellglied reagiert.
Dies nennt man den WindUP-Effekt.
Hierzu wurde die folgende Strategie entwickelt:

[[Datei:13 10 20 PID Windup.png|WindUP]]

Sobald das rechnerische Stellsignal (Ventilstellung Calc=actuationCalc) die obere Grenze des Stellgliedes überschreitet (pidActorLimitUpper) oder die untere Grenze unterschreitet (pidActorLimitLower), wird die Integration des I-Anteils eingefroren.

'''Am Beispiel:'''
An Position L1 überschreitet der rechnerische Ausgabewert des Stellgliedes die obere Grenze (100%).
Der I-Anteil verändert sich nicht mehr bis zur Position L2. Hier unterschreitet der Ausgabewert die
obere Grenze, der I-Anteil kann wieder verändert werden.

== Fragen und Antworten ==
=== Temperatur im Raum steigt nicht oder stark verzögert, was kann ich tun ? ===

==== 1.Fehlerquelle : Heizsystem ist nicht ausreichend entlüftet ====
In diesem Fall behindern die Luftblasen im System den Durchfluss des Heizmediums.<br/>
Der Heizkörper erwärmt sich nur teilweise oder "gluckert".
Hier ist das Entlüften der Heizkörper angesagt.<br/><br/>
Natürlich können sich die Gasblasen an anderer Stelle befinden.
Normalerweise sorgen automatische Entlüfter, dass das Gas entweichen kann.<br/>
Aber auch diese "verkalken" im Lauf der Zeit.

==== 2.Fehlerquelle : Totzone beim Stellglied ====
Der Temperaturanstieg erfolgt erst ab einer bestimmten Ventilöffnung von xy%.<br/>
Der PID-Regler geht davon aus, dass jede Änderung des Stellausgangs auf die Regelgröße wirkt<br/>
(also bei Ventil weiter öffnen, wird mehr Wärme abgegeben)<br/><br/>
Ist dies nicht der Fall, wird der PID über die Zeit (I-Anteil) das Ventil weiter öffnen.<br/>
Allerdings vergeht hierbei Zeit und damit leidet die Regelgüte.<br/><br/>

Es ist also wichtig die Totzone zu ermitteln und im Attribut pidActorLimitLower zu hinterlegen.

==== 3.Fehlerquelle : Hydraulische Fehlanpassung ====
Wenn einzelnen Heizkreise einen sehr kleinen hydraulischen Widerstand aufweisen, kann es passieren
das Heizkreise mit höherem Widerstand zeitweise unterversorgt sind.<br/><br/>
Erst wenn die gut versorgten Heizkreise die Ventile schließen (Soll-Temperatur ist erreicht),
werden die Heizkreise mit hohem Widerstand ausreichend versorgt.<br/><br/>
Dies kann man dank FHEM sehr gut über die Charts nachvollziehen.<br/>
Es ist regelungstechnisch, ökologisch und energetisch absolut sinnvoll geregelte Hocheffizienz-Pumpen
im Heizkreis einzusetzen. Diese sorgen für konstanten Druck im Hauptstrang bei sehr geringen Energiebedarf.<br/>

Man kann gezielt den hydraulischen Widerstand einzelner Thermostate erhöhen, indem man deren maximale Ventilöffnung begrenzt.<br/>

Dies erreicht man durch Reduzieren des Wertes pidActorLimitUpper.<br/>
Dies ist gleichbedeutend mit der Erhöhung der hydraulischen Widerstandes durch voreinstellbare Heizungsventile beim hydraulischen Abgleich.

== Weblinks ==

* [http://forum.fhem.de/index.php/topic,15060.0.html Initialer Forumseintrag zur Überarbeitung des PID-Moduls]
* [http://de.wikipedia.org/wiki/Regler Wikipedia Regler]

[[Kategorie:Glossary]]
[[Kategorie:Regelungstechnik]]

PanStamp RGBWW Board mit DMX und IR

2015-07-29T06:10:59Z

TeeVau: .

{{Baustelle}}

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=RGBWW Board
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz
|HWChannels=
|HWVoltage=12V
|HWPowerConsumption=
|HWPoweredBy=Netzteil
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#SWAP_0000002200000003 35_SWAP_0000002200000003.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}
[[PanStamp RGBWW Board mit DMX und IR]] unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z.B. als Unterputz Touchpanel) und FHEM bedienen.
Es ist eine Hard- und Softwareentwicklung auf Basis von panStamp Modulen und verwendet zusätzlich das FHEM Modul [[SWAP 0000002200000003]] als 3. Ebene

Der Funktionsumfang wird in diesem {{Link2Forum|Topic=12487|Message=81923|LinkText=Forenthread}} vorgestellt. Die Hardware für das Board wird {{Link2Forum|Topic=13890|LinkText=hier}} im FHEM Forum vorgestellt und ein Prototyp ist {{Link2Forum|Topic=12487|Message=85777|LinkText=hier}} zu sehen.

== Hardware ==
Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

=== Kompatibilität RBG-Board mit NRG-panStamps ===
Mit dem hier beschriebenen Sketch ist das Board nur mit den panStamp AVRs kompatibel. Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht GND wie beim AVR. Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s einen „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0. {{Link2Forum|Topic=13890 |Message=247069}}

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.

=== Eigenschaften des fade TBC ===
Der wichtige Punkt ist das das RGBWW-Board Farbübergänge autonom macht und FHEM nur den Trigger zum starten und Rückmeldung über den Status gibt. d.h. wie ruckelfrei das faden ist hängt nicht von äußeren Bedingungen wie Funklast, FHEM timing oder FHEM Auslastung ab. Im Board gibt es 15 '''Register''' die jeweils eine Farbe und eine Anzeigedauer enthalten. Diese werden (ein mal) von FHEM aus programmiert. Zum starten wird dann nur noch das Anfangs- und das Endregister gesendet und das Board überblendet zwischen allen Farben der Register zwischen Anfang und Ende in der eingestellten Zeit.
Die eigentliche Einschränkung ist das die aktuelle AVR Version der panstamps ''nur'' 8bit pwm kann (jedenfalls wenn es 3 oder mehr Kanäle sein sollen und die Hardware PWM genutzt wird). Wenn dir diese 256 Stufen pro Grundfarbe reichen ist es absolut Ruckelfrei. d.h. es gibt keinen zeitlichen Jitter. Ob dir die Anzahl der Helligkeitsstufen reicht hängt ein wenig von den LEDs selber ab und davon zwischen welchen Farben du konkret wechselst. Im dunklen Bereich wirst du vermutlich stufen sehen (also beim aufblenden von dunkel zu hell). wenn du zwischen zwei hellen Farben (z.b. von rot nach grün) blendest wirst du keine stufen sehen. {{Link2Forum|Topic=13890|Message=106644}}

== Software ==
Eine Übersicht über die derzeit vorhandene Funktionalität des [[SWAP_0000002200000003|Fhem Moduls]] und panStamp Sketches (Stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
was geht:
* Bis zu vier LED Kanäle (je nach Kombination von ir und soft PWM)
* Ir senden
* Ir empfangen
* Messen ob die LED Versorgungsspannung an ist
* Helligkeit eines an Pin <code>A2</code> angeschlossenen Helligkeitssensors (LDR)
* Konfiguration der DMX Basisadresse über das SWAP Register <code>0x12</code>
* Optional soft on auf letzten RGBW Wert
* Alles was auch vorher schon ging: dimmen, faden, ir fernbedienungen anlernen, ...

wichtig zu wissen:
* Wenn ir aktiv ist und kein soft PWM lässt sich der 4. Kanal nur ein und aus schalten
* Wenn ir aktiv ist muss soft PWM aktiv sein um den 4. Kanal auch zu dimmen
* Es wird nur ein zusätzlicher LED Kanal tatsächlich schon unterstützt. Der fünfte kommt noch
* Bei ir senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die Anderen sind aber einfach zu ergänzen
* Beim ir senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein

was noch kommt:
* besseres soft PWM
* mehr Konfiguration bezüglich default verhalten. ramp zeiten, delays, ...
* hsv Farbmodell um besser zu faden und vor allem um den Weißanteil automatisch auf die weißen LEDs zu legen
* die virtuellen channel
* fhem kompatibles ir senden
* sofortiges senden von Helligkeit und LED Spannung bei Änderung
* andere ir lib mit sehr viel besserer Geräte Unterstützung

wie gehabt muss alles über <code>config.h</code> mit Compilerschalter konfiguriert werden.

=== Arduino IDE 1.5 / 1.6 einrichten ===
Mit der Arduino IDE 1.5.x gab es zusätzlich eine [http://www.panstamp.com/news/panstamp-is-now-fully-arduino-1-5-enabled/ grundlegende Umstellungen der Arduino SWAP Library], für die der derzeitige Sketch [r4716] angepasst werden muss. Der Sketch ist nur kompatibel zur alten SWAP Library, die unter [[PanStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0 installiert]] werden muss (Stand 01.05.2015).

=== Arduino IDE 1.0 einrichten ===
Zum Flashen der panStamps wird die [[PanStamp_Programmierung#Arduino_IDE_1.0.x_vorbereiten|Arduino IDE 1.0.x benötigt]]. Für den RGBWW-Sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin <code>C:\Users\<username>\Documents\Arduino\libraries</code>. Am Ende der ganzen Aktion sollten sich in diesem Unterordner 3 neue Unterordner befinden: <code>IRremote, DMXSerial und panstamp</code>.

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von <code>libraries</code>.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von <code>libraries</code>. Weitere Informationen zur Verwendung von Arduino Librarys finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Librarys richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter dem Menüpunkt <code>Sketch/Library importieren</code> die 3 weiteren Punkte unten unter <code>beigetragen</code> auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino <code>libraries</code> Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter Sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Für das kompilieren mit INO siehe [[PanStamp_Programmierung#INO|hier]].

=== Link zum Sketch ===
Die aktuelle Version des RGBWW-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge]. {{Link2Forum|Topic=13890 |Message=201391}}
Dieser muss in <code>Arduino\libraries\panstamp\examples\sketches</code> entpackt und die <code>rbgdriver.ino</code> gestartet werden. In der Arduino IDE sollte unter Tools->Board "Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega328" eingestellt sein. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert kann man in der IDE auch direkt panStamp als Plattform auswählen.

==== Kompillierte hex version ====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=121619}}

==== HEX-File ohne IR und DMX ====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden: {{Link2Forum|Topic=13890 |Message=201955}}

=== Compilerschalter ===
Welche Features der sketch bietet lässt sich im <code>config.h</code> file durch ein- oder auskommentieren der <code>#define ENABLE_...</code> Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}}

==== #define ENABLE_DMX ====
#define ENABLE_DMX
Ermöglicht die Nutzung eines DMX RGB Einstellers zur Steuerung der RGB LEDs

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei <code>DMXSerial.h</code> die Zeile
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
in
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
abgeändert werden muss.

==== #define HAS_SENSOR ====
#define HAS_SENSOR
Ermöglicht die Nutzung eines DHT22 Sensors zur Auswertung von Temperatur und Luftfeuchtigkeit
Dafür sollten diese Konfigurationszeilen auskommentiert sein:
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;

In der <code>IRremote.cpp</code> Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>

sowie die <code>Irremote.h</code> Datei unter <code>Public:</code> um die Zeile
void disableIRIn();
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an Pin <code>A2</code> des panStamps angeschlossen werden.
Ein Beispiel für die Umrechnung der userReading für Spannung Temp etc. ist hier beschrieben: {{Link2Forum|Topic=12487 |Message=76489}}

=== Zusammenhänge der Konfiguration ===
Die Zusammenhänge der Konfiguration sind hier beschrieben {{Link2Forum|Topic=13890 |Message=175181}}

=== 4. und 5. LED Kanal TBC ===
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936

=== Alternativer Fade per Patch ===
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.

== IR Schnittstelle TBC ==
=== IR TBC ===
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267

=== IR-Belegung Panstamp RGB-Board TBC ===
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153

=== Ircluster TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331

=== Irgate TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278

== DMX Schnittstelle ==
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge

[[Kategorie:panStamp]]

PanStamp

2015-07-28T13:12:31Z

TeeVau:

SWAP 0000002200000003

2015-07-28T12:41:57Z

TeeVau: Inhalt aus panStamp Diskussion übernommen

{{Baustelle}}
{{SEITENTITEL:SWAP_0000002200000003}}

{{Infobox Modul
|ModPurpose=Modul zur Ansteuerung des erweiterten RGB Board
|ModType=d
|ModCmdRef=SWAP_0000002200000003
|ModForumArea=
|ModFTopic=
|ModTechName=
|ModOwner=
}}
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
Ein FHEM Modul für das modifizierte panStamp RGB LED Driver Board.

Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

===== weitrere Screenshots =====
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>

== Voraussetzungen ==
Um Modul xyz benutzen zu können, muss außerdem ...

== Anwendung ==
=== Define ===

=== set-Kommando ===
* on/off/on-for-timer/toggle/...
Wie bei jedem anderen Device
*rgb RRGGBB
Stellt die Farbe ein, ohne Fade.
*dimUp
*dimDown
Stufenweise heller oder dunkler schalten
*setIR # code
*learnIR #
*storeIR # code cmd
Hinterlegt eine von 16 möglichen Zuordnungen zwischen ir-Signal und FHEM-Kommando. # ist die Nummer der Registers, code ist das ir-Kommando, cmd ist das rgb driver kommando das ausgeführt werden soll
*getIR #
*getIR all
Fragt ein/alle hinterlegten ir Register ab. Anzeige mit <code>get <device> listIR</code>
*setFade # RRGGBB time
Speichert eine definierte Farbe in bis zu 16 unterschiedlichen Registern. Durch diese Farben kann später automatisch überblendet werden.
*getFade #
*getFade all
Fragt alle hinterlegten fader Register ab. Anzeige mit <code>get <device> listFade</code>
*startFade #1 #2
Beginnt in einer Endlosschleife zwischen die Register von <code>#1</code> bis zu <code>#2</code> durchzufaden.

=== get-Kommando===

=== Attribute ===
* defaultFadeTime
Es wird diese fadeTime verwendet, wenn bei dem set-Kommandor <code>fadeTo</code> keine Zeit angegeben wird. Das macht es etwas einfacher das [[PanStamp RGBWW Board mit DMX und IR]] in eine [[LightScene]] einzubinden und beim aktivieren einer Szene die Farben zu faden statt hart umzuschalten

== Anwendungsbeispiele ==
=== original RGB-Sketch (von panstamp.com) ===
Der originale Sketch von der panStamp.com-Seite und das [[SWAP]] FHEM-Modul verstehen von Haus aus nur die <code>regSet</code> und <code>regGet</code> Kommandos. Wenn man den [[Color#Colorpicker|colorpicker]] verwenden möchte, geht das nur per [[readingsProxy]].
Das einfachste ist es den [[PanStamp_RGBWW_Board_mit_DMX_und_IR#Link_zum_Sketch|Sketch]] und das [[SWAP_0000002200000003|FHEM-Modul]] für das [[PanStamp_RGBWW_Board_mit_DMX_und_IR|RGBWW-Board]] zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen FHEM-Kommandos wie on, off, on-for-timer, dimup, etc. zu verwenden.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden. {{Link2Forum|Topic=12487 |Message=220463}}

Falls jemand trotzdem den normalen RGB-Sketch von panStamp verwendet:
* Im SourceCode der Datei alle drei <code>0000002200000003</code> durch <code>0000000100000003</code> ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

=== ir Code anlernen ===
Um die ir Kommandos anzulernen am besten <code>learnIR #</code> verwenden. Danach blinkt die LED auf dem Board schnell und es wird auf ein ir-Signal gewartet. Wenn das empfangen ist blinkt die LED langsamer und es wird auf ein Kommando von FHEM gewartet. Danach geht die LED auf dem Board aus und das eben gesendete FHEM-Kommando ist mit der Taste auf der ir Fernbedienung verknüpft.

Empfangene ir-Kommandos, die nicht über eines der 16 Register eine lokale Aktion auslösen, werden über das Register <code>0C</code> an FHEM übertragen und sind per notify ganz normal weiter verarbeitbar.

=== Power On State konfigurieren ===
register 0E PowerOnState:
* 1. byte: <code>0</code> -> aus, <code>1</code> -> weiss, <code>2</code>-> eine bestimmte Farbe wie im 3. Byte konfiguriert, <code>3</code> -> autosave. <code>E0.1 Bit 5&6</code> gibt jetzt in 10 Sekunden Schritten an nach welcher Zeit das autosave ins eeprom passieren soll. also 0, 10, 20 oder 30 Sekunden
* 2. byte: Helligkeit
* 3-5. byte <code>rrggbb</code>
Man kann z.b. mit <code>set <device> regSet 0E 0200FFFFFF</code> einstellen das nach dem einschalten alle drei Farbkanäle voll aufgedreht werden.
oder mit <code>set <device> regSet 0E 0300000000</code> autosave aktivieren. Dann wird jeweils nach 5 Minuten ohne Änderung die aktuelle Farbe ins eeprom gesichert. Die 5 Minuten könnte man eventuell noch verkürzen. Für autosave ist am Anfang der loop Schleife im Arduino Sketch das Schreiben ins eeprom zu aktivieren (das <code>#if 0</code> in ein <code>#'if 1</code> ändern). An dieser Stelle kannst du auch die 5 Minuten anpassen.
Soft on funktioniert auch mit dem Wert vor dem letzten ausschalten. Hierzu ist das Register <code>0E.1</code> wie folgt zu setzen: <code>0x02</code> um nach hard power on den letzten rgb wert zu haben, <code>0x08</code> um nach soft on den letzten wert zu haben. Für beides zusammen <code>0x0a</code>.

=== 5. LED Kanal zum schalten benutzen ===
Mit den 5. Kanal nur schalten ist kein Problem. Das SWAP FHEM-Modul kann schon so konfiguriert werden das es nur den Teil eines Registers als eigenständiges Device zur Verfügung stellt. Alternativ geht das auch mit dem [[readingsProxy]].
<pre>
define Leinwand readingsProxy RGB_Leinwand 0B.4
attr Leinwand setFn {if($CMD eq "on") {fhem("set $DEVICE regSet 0B.4 FF")} else {fhem("set $DEVICE regSet 0B.4 00")}}
attr Leinwand setList on off
attr Leinwand valueFn {return "off" if( $VALUE eq "00"); return "on";}
</pre>

=== Fade konfigurieren ===
Faderegister definieren:
<pre>
set Device setFade 01 FF0000 60
set Device setFade 02 00FF00 60
set Device setFade 03 0000FF 60
</pre>

Fade starten von Register 1 bis Register 3:
set Device startFade 01 03
== Links ==

[[Kategorie:panStamp]]

Diskussion:PanStamp

2015-07-28T12:25:29Z

TeeVau: /* Explizite Anwendungen */ Inhalte in SWAP_0000002200000003 überführt.

'''Anmerkung für die hier vorgeschlagene Änderung des Hauptartikels'''
Während ich mich mit dem Thema vertraut gemacht habe, habe ich versucht, alle Informationen, die aus non-developer Sicht für die spätere Anwendung und Inbetriebnahme relevanten Informationen (also aus meiner ;) ) wichtig erscheinen, hier in einem Artikel zusammenfassen. Ich muss gestehen, bis ich meine ersten Panstamps am Laufen hatte, musste ich viel lesen und der derzeitige Artikel setzt mM recht viel Wissen voraus (alles eine Frage des Wissensstandes).
Die Inhalte des derzeitigen Artikels habe ich übernommen und einfließen lassen, d.h. es ist geplant, die derzeitige Seite zu ersetzen!

In diesem Artikel sind alle Posts bis heute (14.04.2015) aus den beiden Threads {{Link2Forum|Topic=12487 |Message=74967 |LinkText=Thema: panStamp support }} und {{Link2Forum|Topic=13890 |Message=86952 |LinkText=Thema: PanStamp Board RGB,CW,WW;DMX;IR }} berücksichtigt.

Da viele Informationen vor allen Dingen aus der Zeit der Entwicklung der Module und der Sketches stammen, bitte ich Euch, hier kritisch quer zu lesen, das geschriebene zu prüfen, ob noch aktuell und ggf. zu korrigieren, zu ergänzen oder im Forum konstruktiv zu kommentieren.

Dinge, die mir unklar waren, da noch nicht getestet oder Dinge, die noch näherer beschrieben werden können, habe ich mit "?" bzw. "TBC" gekennzeichnet.
----
: Hallo, wie ist denn der Stand mit dem Artikel? Finde es schade, dass das gesammelte Know-how hier nur auf der Diskussionsseite zu finden ist. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 12:07, 15. Jul. 2015 (CEST)

{{SEITENTITEL:panStamp}}

<nowiki>{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}</nowiki>

<big>Todo:Fehlerkontrolle, Formatierung, Ergänzung, Bestätigung des Geschriebenen, weitere Informationen zur Erstellung/Anpassung eines Device Description Files, Bestätigung des Hochladens mittels XLoader, Bedienung in FHEMWEB(RGB-Board/Sketch)</big>

== Allgemeines ==

=== Hardware ===
==== panStamp mit Antenne ====
[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem stück Draht in der [https://code.google.com/p/panstamp/wiki/antennalengths richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht. Auch nicht auf kurze Distanzen.

Mittlerweile gibt es zwei verschiedene panStamps (AVR und NRG), von denen der NRG neuer und etwas mehr Features zur Verfügung stellt, allerdings (noch) nicht mit allen hier beschriebenen Projekten kompatibel ist.

==== Panstick oder Panshield ====
<strike>
Als Schnittstelle zwischen Server-Hardware und einem panStamp dient entweder ein panStick (USB Stick mit Sockel zum aufstecken eines panStamp) oder ein "panStamp Shield" mit integriertem panStamp an einem Raspberry Pi. Der Panstick stellt dabei die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface des Panstamps auf der anderen Seite dar. Ein Panshield übernimmt die gleiche Funktion, wird aber direkt an die IOs eines Raspberries angeschlossen.

Der Panstick wird grundsätzlich für zwei Aufgaben benötigt:
# Für die Vorbereitung eines panStamps für den Betrieb auf einem "Board" wird der neue panStamp in den Panstick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
# Im "normalen" Betrieb steckt ein panStamp auf ihm. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und dient so dem Rechner als Interface zu anderen panStamps, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird.

Da auf dem panStamp Shield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die zweite Funktion.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:10, 17. Jul. 2015 (CEST)

==== spezifisches "Board" ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
: Im Gegenzug zum Panstick als Interface zwischen panStamp und USB-Port des Servers stellt das Board das Interface zwischen panStamp vor Ort und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs des panStamps auf die Ausgänge um bzw. leitet die Eingänge zur Auswertung an den panStamp weiter.
: Entsprechend Anwendungsfall und Sketch werden die Ein-/Ausgänge des panStamps verarbeitet. Z.B. können an ein Board Temperatur-, Feuchtigkeitssensoren oder LED-Strips angeschlossen werden. Der Sketch auf dem panStamp sollte entsprechend der Anwendung auf dem Board angepasst worden sein um nicht nur über die standardmäßig zur Verfügung stehenden Register kommunizieren zu müssen.

: Das Board benötigt irgend eine Art von Stromversorgung, um den panStamp zu betreiben. Das kann im Falle eines Sensorboards und entsprechend stromsparend ausgelegtem Sketch eine Batterie sein oder wie im Falle des RGB-Boards eine externe Stromversorgung.
: Speziell beim unten beschriebenen RGB-Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder ingesamt panStamp und LEDs gemeinsam versorgen.

</strike> Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)
=== Software ===

==== Simple Wireless Abstract Protocol (SWAP) ====
<strike>
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.
Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

==== Modem-Sketch ====
{{Randnotiz|RNText=In Artikel [[panStick]]}}
<strike>
Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und Funksignal dar, dass an andere panStamps geht.

Auf jedem panStamp (AVR, NRG?) ist im Auslieferungszustand der Modem-Sketch installiert. Das Protokoll der Funkstrecke folgt dem SWAP-Protokoll.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== auf Board abgestimmter Sketch ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Ein panStamp ist auf einem entsprechenden Board installiert und übernimmt dort lokal die Schnittstelle zwischen Funkstrecke und Board.

Der Sketch stellt dabei die passende "Software" auf dem panStamp. Der Sketch verarbeitet die über das SWAP-Protokoll versandte Nachrichten, wertet diese aus, reagiert entsprechend und setzt die Outputs des Boards. In umgekehrter Richtung wertet er die an den Inputs des Board angelegten Signale aus, verarbeitet diese und schickt sie per SWAP-Protokoll zum Panstamp mit Modem-Sketch zurück.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Module und Description File ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden genauer beschrieben werden. Zusammengefasst gibt es 3 Ebenen mit der Ergänzung eines Konfigurationsfiles in xml-format.
{{Link2Forum|Topic= 13890 |Message=121689 }}
[http://forum.fhem.de/index.php/topic,13890.msg121689.html#msg121689]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 1: 34_panStamp.pm =====
<strike>
Das Modul ist für einen panStamp der auf einem panStick sitzt und das Interface zwischen FHEM und dem panStamp netz bildet. Alle eintreffenden SWAP-Pakete auf dem panStick (mit Modem-Sketch) werden direkt durchgereicht und im nachfolgend beschriebenen SWAP-Modul verarbeitet.
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 2: 34_SWAP.pm =====
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
<strike>
Das Modul implementiert das SWAP protokoll das zwischen den panStamps gesprochen wird. Das SWAP Modul ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM.

Bei SWAP geht alle Komunikation über 'register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jedes device hat eine Reihe System register (00-0A) und beliebig viele user register die vom jeweiligen Sketch abängen. Welche Register dies sind, steht unter anderem jeweils im Device Description xml file im Verzeichnis .../FHEM/lib/SWAP.

In den System Registern steht z.b. der productcode, die device adresse und das Übertragungsintervall. Konfigurierbare register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).

Die Inhalte der System Register stehen als internal values im oberen Bereich der Detail Ansicht einer Komponente in FHEM, die user register als readings im unteren.

Alle low level Dinge wie Register id oder Register Wert können mit hex werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den register namen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (teile eines registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem panStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
</strike>

In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

===== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm =====
{{Randnotiz|RNText=In Artikel [[paNStamp]]}}
<strike>
Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Mit dieser dritten Modulebene ist es auch für Aktore wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.

Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.

Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Ein Beispiel für das RGB-Board dafür ist das Modul 35_SWAP_0000002200000003.pm.
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Device Description File =====
<strike>
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

=== Systemübersicht ===
<strike>
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.
[[Datei:Panstamp-Systemoverview.jpg|200px|thumb|panStamp Systemübersicht]]

{{Link2Forum|Topic=12487 |Message=75980 }}
[http://forum.fhem.de/index.php?topic=12487.msg75980#msg75980]

Die Kommunikationskette ist wie folgt:
FHEM -> Host-hardware/OS -> USB -> Panstick -> panStamp (Modem-Sketch) -> Funkstrecke (SWAP) -> panStamp (angepasster Sketch) -> Board -> Sensoren/LED-Strip/etc.

(Ein Panshield ersetzt "USB -> Panstick" durch "IO's am Rpi-> Panshield")
</strike>

Inhalt übernommen in Artikel [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:50, 17. Jul. 2015 (CEST)

== Schritte der Inbetriebnahme ==
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board:

* Ein panStamp wird in einen Panstick gesteckt und der Panstick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.
* Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).
* Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf den panStamp hochgeladen.
* Der programmierte panStamp aus dem Panstick in das RGB-Board stecken.
* Einen panStamp mit Modem-Sketch in den Panstick stecken und an den FHEM-Host stecken.
* panStamp unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
* RGB-Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, der panStamp automatisch eingerichtet werden.
* SWAP-Device in FHEM an Gegebenheiten anpassen.

</strike> Inhalt in Artikel [[PanStamp (Systemübersicht)]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:41, 24. Jul. 2015 (CEST)

== Programmierung eines panStamps ==
<strike>
=== unter Windows ===

==== Installation Panstick ====
Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====

Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man läd die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem Panstamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der Panstick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====

* Den Sketch läd man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation Panstick ====

Zum einen kann es sein, dass der Panstick automatisch unter /dev/ttyUSBx einbunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des Pansticks das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketches wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flaschen ===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===

Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>
</strike>

In Artikel [[Programmierung eines panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:36, 17. Jul. 2015 (CEST)

== Integration in FHEM ==
=== FHEM Voraussetzungen ===
<strike>
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>

Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
</strike> Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== Pfade innerhalb der FHEM Installation ====

Die Module befinden sich wie gewohnt im Installationsverzeichnis unter ./FHEM.
<strike>
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Register ===
<strike>
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Verwendung innerhalb FHEM ===
{{Randnotiz|RNText=In Artikel [[panStamp]] [[panStick]]}}
<strike>
Zu unterscheiden ist die Definition des "Panstick", wobei der panStamp, der als RF-Modem auf dem Panstick sitzt, gemeint ist. Dieser wird im Folgenden mit "Panstick" als Name des Device benannt . Der Type ist "panstamp".

Auf der anderen Seite gibt es die Definition der panStamps, die lokal auf den entsprechenden Boards stecken. Diese sind vom Type SWAP_<ProductCode>. Um die Verwirrung komplett zu machen, wird hier meistens vom "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind. Für diese werden hier nur die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Komandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des Productcode zur Verfügung stehen, werden bei den spezifischen Anwendungen beschrieben.

</strike> In [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Panstick ====
<strike>
===== Definition =====
Das Device "Panstick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv sind.

'''Betrieb an der FB'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernaschluss deaktiviert sein.

===== Attribute =====

Für den "Panstick" gibt es keine modulspezifischen Attribute.

===== Set =====

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
In diesem Beispiel wird ein broadcast an alle abgesetzt, damit diese ihre ID und ihren productcode zurück senden.
Das macht der panStick nach dem Initialisieren auch ein mal automatisch um alle nicht schlafenden Devices per autocreate anlegen zu können.

Mit diesem Befehl "raw" lassen sich SWAP-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 20:05, 17. Jul. 2015 (CEST)

==== SWAP ====

Alle empfangen SWAP Nachrichten werden in internals/readings im jeweiligen Device angezeigt.

===== Definition =====
<strike>
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== set =====
''ZUGEFÜGT ZU SWAP ARTIKEL, STRIKE FUNKTIONIERT ABER IN DIESEM ABSATZ NICHT''
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
* ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== get =====
<strike>
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== Attribute =====
<strike>
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest. Dieses Attribut wird dazu benutzt, die Konfiguration vom Device-XML-File festzulegen.
Erst wenn der Produktcode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen Kommandos die spezifischen der nächst höheren Modulebene 35_SWAP_<productcode>.pm mit hinzu. Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== SWAP_<ProductCode> ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Ist bei einem SWAP-Device das Attribut Productcode gesetzt, wird die SWAP-Nachricht an das entsprechende Modul der 3. Ebene weitergegeben und dort verarbeitet. Die spezifischen Kommandos und Attribute sind bei den entsprechenden [[panstamp#Explizite Anwendungen|Anwendungen]] näher beschrieben.
</strike>

Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

==== Intervall bei Sketch mit power down / batterie betriebene Panstamps ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Devices mit power down mode durchlaufen beim Einschalten oder bei einem Reset eine 3 Sekunden Schleife und warten auf Kommandos, dann werden normaler Weise die Register mit den Sensorwerten gesendet und die normale Loop gestartet. power down devices gehen danach schlafen und wachen regelmässig auf um ihre Werte zu senden.
Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.

Nachrichten an ein Device im power-down-state werden gepuffert und dann an das Device geschickt, sobald dieses sich im SYNC status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:

<pre> set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> </pre>
{{Link2Forum|Topic=12487 |Message=87409}}
[http://forum.fhem.de/index.php?topic=12487.msg87409#msg87409]

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert.

Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist.
{{Link2Forum|Topic=12487 |Message=89205}}
[http://forum.fhem.de/index.php/topic,12487.msg89205.html#msg89205]

{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF in 0A zum Überlauf führt und dann ununterbrochen gesendet wird. Im fhem Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum senden kommt.
Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden und noch mal flashen. Wenn der Sketch damit ein mal durchgelaufen ist können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht.

Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}
[http://forum.fhem.de/index.php/topic,12487.msg87859.html#msg87859]

Für Devices im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald das Device seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos Reset zu drücken oder die Stromquelle erneut zu verbinden.

Die automatisch vergebenen Adressen sind im Bereich F0-FE. d.h. eigentlich auch nur temporär und sollten auf eine lokal passende geändert werden.
{{Link2Forum|Topic=12487 |Message=87919}}
[http://forum.fhem.de/index.php/topic,12487.msg87919.html#msg87919]

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>
Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)
==== Verschlüsselung ====

Die Aktivierung der Verschlüsselung für die Kommunikation zwischen panStamp und panStick ist hier beschrieben, scheint allerdings derzeit noch nicht eingecheckt zu sein (Stand 01.05.2015).
{{Link2Forum|Topic=12487 |Message=133040}}
[http://forum.fhem.de/index.php/topic,12487.msg133040.html#msg133040]
{{Link2Forum|Topic=12487 |Message=139341}}
[http://forum.fhem.de/index.php/topic,12487.msg139341.html#msg139341]

=== Trouble Shooting ===
<strike>
==== value has to be 10 byte(s) in size ====

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

==== register 0F is not known ====

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

==== Komplette Übersicht eines Device ====

<pre>
list <device>
</pre>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

==== fehlender oder falsche Productcode ====

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

==== missing commands und register 00-0A unvollständig ====

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

==== Funktion des Autocreate ====

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

==== Adresse manuell setzen ====

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

==== Panstamp antwortet nicht/EEprom to factory defaults ====

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

==== Undefined subroutine &main::XMLin ====
Erhält man diese Fehlermeldung
<pre>
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.
</pre>
<pre>
2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!
</pre>

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

==== Factory Defaults ====

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

==== Status LED ====

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

</strike> Inhalt in Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:00, 17. Jul. 2015 (CEST)

== Explizite Anwendungen ==
=== RGB-Board ===
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
==== Allgemeines ====
<strike>
Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

Eine Übersicht über die derzeit vorhandene Funktionalität (stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
[http://forum.fhem.de/index.php?topic=13890.msg120404#msg120404]

* bis zu vier LED-Kanäle (je nach Kombination von ir und soft pwm)
* ir senden
* ir empfangen
* Messen ob die LED-Versorgung an ist.
* Helligkeit eines an A2 angeschlossenen Helligkeitssensors
* Konfiguration der DMX-Basis-Adresse über das SWAP Register 0x12
* optional soft on auf letzten Wert
* Alles was auch vorher schon ging: dimmen, faden, IR-Fernbedienungen anlernen, ...

Wichtig zu wissen:
* Wenn IR aktiv ist und kein soft pwm lässt sich der 4. Kanal nur ein- und ausschalten.
* Wenn IR aktiv ist muss soft pwm aktiv sein um den 4. Kanal auch zu dimmen.
* Es wird nur ein zusätzlicher Kanal tatsächlich schon unterstützt, der fünfte ist noch geplant.
* Bei IR-Senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die anderen sind aber einfach zu ergänzen.
* Beim IR-Senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein.

was noch kommt:
* besseres soft pwm
* mehr Konfiguration bezüglich default-Verhalten. Ramp-Zeiten, Delays, ...
* HSV-Farb-Modell um besser zu faden und vor Allem um den Weiss-Anteil automatisch auf die Weiss-LEDs zu legen
* die virtuellen Channel
* FHEM kompatibles IR-Senden
* sofortiges senden von Helligkeit und LED-Spannung bei Änderung
* andere IR-Lib mit sehr viel besserer Geräte-Unterstützung

Wie gehabt muss alles über config.h mit Compilerschaltern konfiguriert werden.
</strike>

Inhalt in Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== weitrere Screenshots =====
<strike>
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>
</strike>

Inhalt in Artikel [[SWAP_0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== original RGB-Sketch (von panstamp.com) =====
<strike>
Der originale Sketch von der panStamp.com-Seite und das generelle FHEM-Modul verstehen von Haus aus nur die regSet und regGet Kommandos. Wenn man den colorpicker verwenden möchte, geht das nur per readingsProxy.

Das einfachste ist es den Sketch und das FHEM-Modul für das RGB-Board zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen Kommandos wie on, off, on-for-timer, dimup, ... und kann konfigurieren, wie das Board nach dem Hart- oder Soft-Einschalten reagieren soll.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden.
{{Link2Forum|Topic=12487 |Message=220463}}
[http://forum.fhem.de/index.php/topic,12487.msg220463.html#msg220463]

Falls jemand trotzdem den normalen RGB-Sketch verwendet:
* Im Code alle drei 0000002200000003 durch 0000000100000003 ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

</strike> Inhalt in Artikel [[SWAP_0000002200000003#Anwendungsbeispiele]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:58, 28. Jul. 2015 (CEST)

==== Sketch vorbereiten, kompilieren und hochladen ====
===== Vorbereitungen =====
<strike>
(Stand 01.05.2015)

Mit der Arduino IDE 1.5.x gab es gundlegende Umstellungen, für die der derzeitige Sketch [r4716] vermutlich angepasst werden müsste.

Für den RGB-Driver sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin C:\Users\<username>\Documents\Arduino\libraries. Am Ende der ganzen Aktion im Folgenden sollten sich in diesem Unterordner 3 neue Unterordner befinden: IRremote, DMXSerial und panstamp

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Libraries richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter Sketch/Library importieren die 3 weiteren Punkte unten unter "beigetragen" auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino libraries Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).

Für das kompilieren mit INO siehe [[panstamp#ino|hier]].

===== Link zum sketch =====
Die aktuelle Version des RGB-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge].
{{Link2Forum|Topic=13890 |Message=201391}}
[http://forum.fhem.de/index.php?topic=13890.msg201391#msg201391]

===== Kompillierte hex version =====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=121619}}
[http://forum.fhem.de/index.php?topic=13890.msg121619#msg121619]

===== HEX-File ohne IR und DMX =====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=201955}}
[http://forum.fhem.de/index.php?topic=13890.msg201955#msg201955]

===== Sketch anpassen, kompilieren und hochladen =====

* Welche Features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der #define ENABLE_... Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}} [http://forum.fhem.de/index.php?topic=13890.msg173431#msg173431] Den Sketch entsprechend den Bedürfnissen in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen. Für die Konfigurationen siehe [[panstamp#Sketch konfigurieren|Sketch konfigurieren]].
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

==== Sketch konfigurieren ====

===== DMX =====
<pre>
#define ENABLE_DMX
</pre>

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei DMXSerial.h die Zeile

<pre>
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
</pre>

in

<pre>
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
</pre>

abgeändert werden muss.

===== Temperatur- und Luftfeuchtigkeitssensor =====

<pre>
#define HAS_SENSOR
</pre>

Dieses ermöglicht die Nutzung eines DHT22 Sensors zur Auswerung von Temperatur und Luftfeuchtigkeit.

Dafür sollten diese Konfigurationszeilen auskommentiert sein
<pre>
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;
</pre>

In der IRremote.cpp Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>
sowie die Irremote.h Datei unter Public: um die Zeile
<pre>
void disableIRIn();
</pre>
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an A2 des panStamps angeschlossen werden.

Ein Beispiel für die Umrechnung der Userreading für Spannung Temp etc. ist hier beschrieben.
{{Link2Forum|Topic=12487 |Message=76489}}
[http://forum.fhem.de/index.php?topic=12487.msg76489#msg76489]

===== Zusammenhänge der Konfiguration =====

Die Zusammenhänge der Konfiguration sind hier beschrieben
{{Link2Forum|Topic=13890 |Message=175181}}
[http://forum.fhem.de/index.php?topic=13890.msg175181#msg175181]
</strike>

Inhalt in Artikel [[PanStamp RGBWW Board mit DMX und IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== Bedienung in FHEMWEB ====

===== Komandos =====

====== Definition ======

Der Panstick wird entsprechend folgendem Befehlt angelegt:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle ist entsprechend Installation des [[panstamp#unter Linux|Pansticks]] anzupassen.

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv ist.

====== Attribute TBC ======

====== Set TBC ======

====== Get TBC ======
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

EIn register verändern
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Register umrechnung dec zu hex TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Poweronstate TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg88054.html#msg88054
http://forum.fhem.de/index.php/topic,12487.msg95574.html#msg95574
http://forum.fhem.de/index.php/topic,13890.msg124456.html#msg124456

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

===== Aus nach poweron TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg121296#msg121296
Power on register
http://forum.fhem.de/index.php?topic=13890.msg121137#msg121137

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

===== listunconfirmed TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Fadeto TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
Default fade time
http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

===== Eigenschaften des fade TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== 4.,5. kanal TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== Extra kanäle TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg173280#msg173280
http://forum.fhem.de/index.php?topic=13890.msg214329#msg214329
http://forum.fhem.de/index.php?topic=13890.msg214474#msg214474

</strike> Inhalt in Artikel [[SWAP 0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 14:25, 28. Jul. 2015 (CEST)

==== IR Schnittstelle TBC ====
===== IR TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267
</strike>

===== IR-Belegung Panstamp RGB-Board TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153
</strike>

===== Ircluster TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331
</strike>

===== Irgate TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== DMX Schnittstelle ====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
==== sonstiges ====

===== Alternativer Fade per Patch =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== Kompatibilität RBG-Board mit NRG-panStamps =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Mit dem hier beschriebenen Sketch ist das Board nur mit den AVRs kompatibel.
Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht Ground wie beim AVR.
Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s ein „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0.

{{Link2Forum|Topic=13890 |Message=247069}}
[http://forum.fhem.de/index.php?topic=13890.msg247069#msg247069]

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
=== Bodenfeuchtesensor ===
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbstentwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.
</strike>

In Artikel [[SWAP] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Umweltsensor ===
<strike>
Die Weiterentwicklung des Bodenfeuchtesensors zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.
</strike>

=== Ultraschall-Füllstandssensor ===

Projektidee

=== Repeater Mode ===

Die Repeaterfunktionalität ist derzeit (01.05.2015) noch nicht näher beschrieben, wird aber von den Modulen unterstützt.
{{Link2Forum|Topic=12487 |Message=118403}}
[http://forum.fhem.de/index.php/topic,12487.msg118403.html#msg118403]

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

Diskussion:PanStamp

2015-07-28T11:58:42Z

TeeVau: /* original RGB-Sketch (von panstamp.com) */ Inhalt in Artikel SWAP_0000002200000003#Anwendungsbeispiele übernommen

'''Anmerkung für die hier vorgeschlagene Änderung des Hauptartikels'''
Während ich mich mit dem Thema vertraut gemacht habe, habe ich versucht, alle Informationen, die aus non-developer Sicht für die spätere Anwendung und Inbetriebnahme relevanten Informationen (also aus meiner ;) ) wichtig erscheinen, hier in einem Artikel zusammenfassen. Ich muss gestehen, bis ich meine ersten Panstamps am Laufen hatte, musste ich viel lesen und der derzeitige Artikel setzt mM recht viel Wissen voraus (alles eine Frage des Wissensstandes).
Die Inhalte des derzeitigen Artikels habe ich übernommen und einfließen lassen, d.h. es ist geplant, die derzeitige Seite zu ersetzen!

In diesem Artikel sind alle Posts bis heute (14.04.2015) aus den beiden Threads {{Link2Forum|Topic=12487 |Message=74967 |LinkText=Thema: panStamp support }} und {{Link2Forum|Topic=13890 |Message=86952 |LinkText=Thema: PanStamp Board RGB,CW,WW;DMX;IR }} berücksichtigt.

Da viele Informationen vor allen Dingen aus der Zeit der Entwicklung der Module und der Sketches stammen, bitte ich Euch, hier kritisch quer zu lesen, das geschriebene zu prüfen, ob noch aktuell und ggf. zu korrigieren, zu ergänzen oder im Forum konstruktiv zu kommentieren.

Dinge, die mir unklar waren, da noch nicht getestet oder Dinge, die noch näherer beschrieben werden können, habe ich mit "?" bzw. "TBC" gekennzeichnet.
----
: Hallo, wie ist denn der Stand mit dem Artikel? Finde es schade, dass das gesammelte Know-how hier nur auf der Diskussionsseite zu finden ist. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 12:07, 15. Jul. 2015 (CEST)

{{SEITENTITEL:panStamp}}

<nowiki>{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}</nowiki>

<big>Todo:Fehlerkontrolle, Formatierung, Ergänzung, Bestätigung des Geschriebenen, weitere Informationen zur Erstellung/Anpassung eines Device Description Files, Bestätigung des Hochladens mittels XLoader, Bedienung in FHEMWEB(RGB-Board/Sketch)</big>

== Allgemeines ==

=== Hardware ===
==== panStamp mit Antenne ====
[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem stück Draht in der [https://code.google.com/p/panstamp/wiki/antennalengths richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht. Auch nicht auf kurze Distanzen.

Mittlerweile gibt es zwei verschiedene panStamps (AVR und NRG), von denen der NRG neuer und etwas mehr Features zur Verfügung stellt, allerdings (noch) nicht mit allen hier beschriebenen Projekten kompatibel ist.

==== Panstick oder Panshield ====
<strike>
Als Schnittstelle zwischen Server-Hardware und einem panStamp dient entweder ein panStick (USB Stick mit Sockel zum aufstecken eines panStamp) oder ein "panStamp Shield" mit integriertem panStamp an einem Raspberry Pi. Der Panstick stellt dabei die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface des Panstamps auf der anderen Seite dar. Ein Panshield übernimmt die gleiche Funktion, wird aber direkt an die IOs eines Raspberries angeschlossen.

Der Panstick wird grundsätzlich für zwei Aufgaben benötigt:
# Für die Vorbereitung eines panStamps für den Betrieb auf einem "Board" wird der neue panStamp in den Panstick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
# Im "normalen" Betrieb steckt ein panStamp auf ihm. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und dient so dem Rechner als Interface zu anderen panStamps, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird.

Da auf dem panStamp Shield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die zweite Funktion.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:10, 17. Jul. 2015 (CEST)

==== spezifisches "Board" ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
: Im Gegenzug zum Panstick als Interface zwischen panStamp und USB-Port des Servers stellt das Board das Interface zwischen panStamp vor Ort und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs des panStamps auf die Ausgänge um bzw. leitet die Eingänge zur Auswertung an den panStamp weiter.
: Entsprechend Anwendungsfall und Sketch werden die Ein-/Ausgänge des panStamps verarbeitet. Z.B. können an ein Board Temperatur-, Feuchtigkeitssensoren oder LED-Strips angeschlossen werden. Der Sketch auf dem panStamp sollte entsprechend der Anwendung auf dem Board angepasst worden sein um nicht nur über die standardmäßig zur Verfügung stehenden Register kommunizieren zu müssen.

: Das Board benötigt irgend eine Art von Stromversorgung, um den panStamp zu betreiben. Das kann im Falle eines Sensorboards und entsprechend stromsparend ausgelegtem Sketch eine Batterie sein oder wie im Falle des RGB-Boards eine externe Stromversorgung.
: Speziell beim unten beschriebenen RGB-Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder ingesamt panStamp und LEDs gemeinsam versorgen.

</strike> Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)
=== Software ===

==== Simple Wireless Abstract Protocol (SWAP) ====
<strike>
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.
Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

==== Modem-Sketch ====
{{Randnotiz|RNText=In Artikel [[panStick]]}}
<strike>
Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und Funksignal dar, dass an andere panStamps geht.

Auf jedem panStamp (AVR, NRG?) ist im Auslieferungszustand der Modem-Sketch installiert. Das Protokoll der Funkstrecke folgt dem SWAP-Protokoll.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== auf Board abgestimmter Sketch ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Ein panStamp ist auf einem entsprechenden Board installiert und übernimmt dort lokal die Schnittstelle zwischen Funkstrecke und Board.

Der Sketch stellt dabei die passende "Software" auf dem panStamp. Der Sketch verarbeitet die über das SWAP-Protokoll versandte Nachrichten, wertet diese aus, reagiert entsprechend und setzt die Outputs des Boards. In umgekehrter Richtung wertet er die an den Inputs des Board angelegten Signale aus, verarbeitet diese und schickt sie per SWAP-Protokoll zum Panstamp mit Modem-Sketch zurück.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Module und Description File ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden genauer beschrieben werden. Zusammengefasst gibt es 3 Ebenen mit der Ergänzung eines Konfigurationsfiles in xml-format.
{{Link2Forum|Topic= 13890 |Message=121689 }}
[http://forum.fhem.de/index.php/topic,13890.msg121689.html#msg121689]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 1: 34_panStamp.pm =====
<strike>
Das Modul ist für einen panStamp der auf einem panStick sitzt und das Interface zwischen FHEM und dem panStamp netz bildet. Alle eintreffenden SWAP-Pakete auf dem panStick (mit Modem-Sketch) werden direkt durchgereicht und im nachfolgend beschriebenen SWAP-Modul verarbeitet.
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 2: 34_SWAP.pm =====
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
<strike>
Das Modul implementiert das SWAP protokoll das zwischen den panStamps gesprochen wird. Das SWAP Modul ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM.

Bei SWAP geht alle Komunikation über 'register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jedes device hat eine Reihe System register (00-0A) und beliebig viele user register die vom jeweiligen Sketch abängen. Welche Register dies sind, steht unter anderem jeweils im Device Description xml file im Verzeichnis .../FHEM/lib/SWAP.

In den System Registern steht z.b. der productcode, die device adresse und das Übertragungsintervall. Konfigurierbare register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).

Die Inhalte der System Register stehen als internal values im oberen Bereich der Detail Ansicht einer Komponente in FHEM, die user register als readings im unteren.

Alle low level Dinge wie Register id oder Register Wert können mit hex werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den register namen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (teile eines registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem panStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
</strike>

In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

===== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm =====
{{Randnotiz|RNText=In Artikel [[paNStamp]]}}
<strike>
Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Mit dieser dritten Modulebene ist es auch für Aktore wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.

Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.

Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Ein Beispiel für das RGB-Board dafür ist das Modul 35_SWAP_0000002200000003.pm.
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Device Description File =====
<strike>
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

=== Systemübersicht ===
<strike>
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.
[[Datei:Panstamp-Systemoverview.jpg|200px|thumb|panStamp Systemübersicht]]

{{Link2Forum|Topic=12487 |Message=75980 }}
[http://forum.fhem.de/index.php?topic=12487.msg75980#msg75980]

Die Kommunikationskette ist wie folgt:
FHEM -> Host-hardware/OS -> USB -> Panstick -> panStamp (Modem-Sketch) -> Funkstrecke (SWAP) -> panStamp (angepasster Sketch) -> Board -> Sensoren/LED-Strip/etc.

(Ein Panshield ersetzt "USB -> Panstick" durch "IO's am Rpi-> Panshield")
</strike>

Inhalt übernommen in Artikel [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:50, 17. Jul. 2015 (CEST)

== Schritte der Inbetriebnahme ==
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board:

* Ein panStamp wird in einen Panstick gesteckt und der Panstick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.
* Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).
* Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf den panStamp hochgeladen.
* Der programmierte panStamp aus dem Panstick in das RGB-Board stecken.
* Einen panStamp mit Modem-Sketch in den Panstick stecken und an den FHEM-Host stecken.
* panStamp unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
* RGB-Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, der panStamp automatisch eingerichtet werden.
* SWAP-Device in FHEM an Gegebenheiten anpassen.

</strike> Inhalt in Artikel [[PanStamp (Systemübersicht)]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:41, 24. Jul. 2015 (CEST)

== Programmierung eines panStamps ==
<strike>
=== unter Windows ===

==== Installation Panstick ====
Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====

Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man läd die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem Panstamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der Panstick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====

* Den Sketch läd man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation Panstick ====

Zum einen kann es sein, dass der Panstick automatisch unter /dev/ttyUSBx einbunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des Pansticks das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketches wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flaschen ===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===

Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>
</strike>

In Artikel [[Programmierung eines panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:36, 17. Jul. 2015 (CEST)

== Integration in FHEM ==
=== FHEM Voraussetzungen ===
<strike>
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>

Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
</strike> Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== Pfade innerhalb der FHEM Installation ====

Die Module befinden sich wie gewohnt im Installationsverzeichnis unter ./FHEM.
<strike>
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Register ===
<strike>
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Verwendung innerhalb FHEM ===
{{Randnotiz|RNText=In Artikel [[panStamp]] [[panStick]]}}
<strike>
Zu unterscheiden ist die Definition des "Panstick", wobei der panStamp, der als RF-Modem auf dem Panstick sitzt, gemeint ist. Dieser wird im Folgenden mit "Panstick" als Name des Device benannt . Der Type ist "panstamp".

Auf der anderen Seite gibt es die Definition der panStamps, die lokal auf den entsprechenden Boards stecken. Diese sind vom Type SWAP_<ProductCode>. Um die Verwirrung komplett zu machen, wird hier meistens vom "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind. Für diese werden hier nur die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Komandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des Productcode zur Verfügung stehen, werden bei den spezifischen Anwendungen beschrieben.

</strike> In [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Panstick ====
<strike>
===== Definition =====
Das Device "Panstick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv sind.

'''Betrieb an der FB'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernaschluss deaktiviert sein.

===== Attribute =====

Für den "Panstick" gibt es keine modulspezifischen Attribute.

===== Set =====

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
In diesem Beispiel wird ein broadcast an alle abgesetzt, damit diese ihre ID und ihren productcode zurück senden.
Das macht der panStick nach dem Initialisieren auch ein mal automatisch um alle nicht schlafenden Devices per autocreate anlegen zu können.

Mit diesem Befehl "raw" lassen sich SWAP-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 20:05, 17. Jul. 2015 (CEST)

==== SWAP ====

Alle empfangen SWAP Nachrichten werden in internals/readings im jeweiligen Device angezeigt.

===== Definition =====
<strike>
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== set =====
''ZUGEFÜGT ZU SWAP ARTIKEL, STRIKE FUNKTIONIERT ABER IN DIESEM ABSATZ NICHT''
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
* ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== get =====
<strike>
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== Attribute =====
<strike>
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest. Dieses Attribut wird dazu benutzt, die Konfiguration vom Device-XML-File festzulegen.
Erst wenn der Produktcode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen Kommandos die spezifischen der nächst höheren Modulebene 35_SWAP_<productcode>.pm mit hinzu. Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== SWAP_<ProductCode> ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Ist bei einem SWAP-Device das Attribut Productcode gesetzt, wird die SWAP-Nachricht an das entsprechende Modul der 3. Ebene weitergegeben und dort verarbeitet. Die spezifischen Kommandos und Attribute sind bei den entsprechenden [[panstamp#Explizite Anwendungen|Anwendungen]] näher beschrieben.
</strike>

Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

==== Intervall bei Sketch mit power down / batterie betriebene Panstamps ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Devices mit power down mode durchlaufen beim Einschalten oder bei einem Reset eine 3 Sekunden Schleife und warten auf Kommandos, dann werden normaler Weise die Register mit den Sensorwerten gesendet und die normale Loop gestartet. power down devices gehen danach schlafen und wachen regelmässig auf um ihre Werte zu senden.
Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.

Nachrichten an ein Device im power-down-state werden gepuffert und dann an das Device geschickt, sobald dieses sich im SYNC status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:

<pre> set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> </pre>
{{Link2Forum|Topic=12487 |Message=87409}}
[http://forum.fhem.de/index.php?topic=12487.msg87409#msg87409]

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert.

Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist.
{{Link2Forum|Topic=12487 |Message=89205}}
[http://forum.fhem.de/index.php/topic,12487.msg89205.html#msg89205]

{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF in 0A zum Überlauf führt und dann ununterbrochen gesendet wird. Im fhem Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum senden kommt.
Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden und noch mal flashen. Wenn der Sketch damit ein mal durchgelaufen ist können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht.

Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}
[http://forum.fhem.de/index.php/topic,12487.msg87859.html#msg87859]

Für Devices im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald das Device seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos Reset zu drücken oder die Stromquelle erneut zu verbinden.

Die automatisch vergebenen Adressen sind im Bereich F0-FE. d.h. eigentlich auch nur temporär und sollten auf eine lokal passende geändert werden.
{{Link2Forum|Topic=12487 |Message=87919}}
[http://forum.fhem.de/index.php/topic,12487.msg87919.html#msg87919]

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>
Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)
==== Verschlüsselung ====

Die Aktivierung der Verschlüsselung für die Kommunikation zwischen panStamp und panStick ist hier beschrieben, scheint allerdings derzeit noch nicht eingecheckt zu sein (Stand 01.05.2015).
{{Link2Forum|Topic=12487 |Message=133040}}
[http://forum.fhem.de/index.php/topic,12487.msg133040.html#msg133040]
{{Link2Forum|Topic=12487 |Message=139341}}
[http://forum.fhem.de/index.php/topic,12487.msg139341.html#msg139341]

=== Trouble Shooting ===
<strike>
==== value has to be 10 byte(s) in size ====

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

==== register 0F is not known ====

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

==== Komplette Übersicht eines Device ====

<pre>
list <device>
</pre>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

==== fehlender oder falsche Productcode ====

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

==== missing commands und register 00-0A unvollständig ====

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

==== Funktion des Autocreate ====

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

==== Adresse manuell setzen ====

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

==== Panstamp antwortet nicht/EEprom to factory defaults ====

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

==== Undefined subroutine &main::XMLin ====
Erhält man diese Fehlermeldung
<pre>
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.
</pre>
<pre>
2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!
</pre>

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

==== Factory Defaults ====

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

==== Status LED ====

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

</strike> Inhalt in Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:00, 17. Jul. 2015 (CEST)

== Explizite Anwendungen ==
=== RGB-Board ===
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
==== Allgemeines ====
<strike>
Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

Eine Übersicht über die derzeit vorhandene Funktionalität (stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
[http://forum.fhem.de/index.php?topic=13890.msg120404#msg120404]

* bis zu vier LED-Kanäle (je nach Kombination von ir und soft pwm)
* ir senden
* ir empfangen
* Messen ob die LED-Versorgung an ist.
* Helligkeit eines an A2 angeschlossenen Helligkeitssensors
* Konfiguration der DMX-Basis-Adresse über das SWAP Register 0x12
* optional soft on auf letzten Wert
* Alles was auch vorher schon ging: dimmen, faden, IR-Fernbedienungen anlernen, ...

Wichtig zu wissen:
* Wenn IR aktiv ist und kein soft pwm lässt sich der 4. Kanal nur ein- und ausschalten.
* Wenn IR aktiv ist muss soft pwm aktiv sein um den 4. Kanal auch zu dimmen.
* Es wird nur ein zusätzlicher Kanal tatsächlich schon unterstützt, der fünfte ist noch geplant.
* Bei IR-Senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die anderen sind aber einfach zu ergänzen.
* Beim IR-Senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein.

was noch kommt:
* besseres soft pwm
* mehr Konfiguration bezüglich default-Verhalten. Ramp-Zeiten, Delays, ...
* HSV-Farb-Modell um besser zu faden und vor Allem um den Weiss-Anteil automatisch auf die Weiss-LEDs zu legen
* die virtuellen Channel
* FHEM kompatibles IR-Senden
* sofortiges senden von Helligkeit und LED-Spannung bei Änderung
* andere IR-Lib mit sehr viel besserer Geräte-Unterstützung

Wie gehabt muss alles über config.h mit Compilerschaltern konfiguriert werden.
</strike>

Inhalt in Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== weitrere Screenshots =====
<strike>
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>
</strike>

Inhalt in Artikel [[SWAP_0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== original RGB-Sketch (von panstamp.com) =====
<strike>
Der originale Sketch von der panStamp.com-Seite und das generelle FHEM-Modul verstehen von Haus aus nur die regSet und regGet Kommandos. Wenn man den colorpicker verwenden möchte, geht das nur per readingsProxy.

Das einfachste ist es den Sketch und das FHEM-Modul für das RGB-Board zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen Kommandos wie on, off, on-for-timer, dimup, ... und kann konfigurieren, wie das Board nach dem Hart- oder Soft-Einschalten reagieren soll.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden.
{{Link2Forum|Topic=12487 |Message=220463}}
[http://forum.fhem.de/index.php/topic,12487.msg220463.html#msg220463]

Falls jemand trotzdem den normalen RGB-Sketch verwendet:
* Im Code alle drei 0000002200000003 durch 0000000100000003 ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

</strike> Inhalt in Artikel [[SWAP_0000002200000003#Anwendungsbeispiele]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:58, 28. Jul. 2015 (CEST)

==== Sketch vorbereiten, kompilieren und hochladen ====
===== Vorbereitungen =====
<strike>
(Stand 01.05.2015)

Mit der Arduino IDE 1.5.x gab es gundlegende Umstellungen, für die der derzeitige Sketch [r4716] vermutlich angepasst werden müsste.

Für den RGB-Driver sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin C:\Users\<username>\Documents\Arduino\libraries. Am Ende der ganzen Aktion im Folgenden sollten sich in diesem Unterordner 3 neue Unterordner befinden: IRremote, DMXSerial und panstamp

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Libraries richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter Sketch/Library importieren die 3 weiteren Punkte unten unter "beigetragen" auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino libraries Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).

Für das kompilieren mit INO siehe [[panstamp#ino|hier]].

===== Link zum sketch =====
Die aktuelle Version des RGB-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge].
{{Link2Forum|Topic=13890 |Message=201391}}
[http://forum.fhem.de/index.php?topic=13890.msg201391#msg201391]

===== Kompillierte hex version =====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=121619}}
[http://forum.fhem.de/index.php?topic=13890.msg121619#msg121619]

===== HEX-File ohne IR und DMX =====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=201955}}
[http://forum.fhem.de/index.php?topic=13890.msg201955#msg201955]

===== Sketch anpassen, kompilieren und hochladen =====

* Welche Features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der #define ENABLE_... Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}} [http://forum.fhem.de/index.php?topic=13890.msg173431#msg173431] Den Sketch entsprechend den Bedürfnissen in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen. Für die Konfigurationen siehe [[panstamp#Sketch konfigurieren|Sketch konfigurieren]].
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

==== Sketch konfigurieren ====

===== DMX =====
<pre>
#define ENABLE_DMX
</pre>

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei DMXSerial.h die Zeile

<pre>
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
</pre>

in

<pre>
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
</pre>

abgeändert werden muss.

===== Temperatur- und Luftfeuchtigkeitssensor =====

<pre>
#define HAS_SENSOR
</pre>

Dieses ermöglicht die Nutzung eines DHT22 Sensors zur Auswerung von Temperatur und Luftfeuchtigkeit.

Dafür sollten diese Konfigurationszeilen auskommentiert sein
<pre>
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;
</pre>

In der IRremote.cpp Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>
sowie die Irremote.h Datei unter Public: um die Zeile
<pre>
void disableIRIn();
</pre>
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an A2 des panStamps angeschlossen werden.

Ein Beispiel für die Umrechnung der Userreading für Spannung Temp etc. ist hier beschrieben.
{{Link2Forum|Topic=12487 |Message=76489}}
[http://forum.fhem.de/index.php?topic=12487.msg76489#msg76489]

===== Zusammenhänge der Konfiguration =====

Die Zusammenhänge der Konfiguration sind hier beschrieben
{{Link2Forum|Topic=13890 |Message=175181}}
[http://forum.fhem.de/index.php?topic=13890.msg175181#msg175181]
</strike>

Inhalt in Artikel [[PanStamp RGBWW Board mit DMX und IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== Bedienung in FHEMWEB ====

===== Komandos =====

====== Definition ======

Der Panstick wird entsprechend folgendem Befehlt angelegt:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle ist entsprechend Installation des [[panstamp#unter Linux|Pansticks]] anzupassen.

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv ist.

====== Attribute TBC ======

====== Set TBC ======

====== Get TBC ======
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923

EIn register verändern
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Register umrechnung dec zu hex TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Poweronstate TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg88054.html#msg88054
http://forum.fhem.de/index.php/topic,12487.msg95574.html#msg95574
http://forum.fhem.de/index.php/topic,13890.msg124456.html#msg124456

===== Aus nach poweron TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg121296#msg121296
Power on register
http://forum.fhem.de/index.php?topic=13890.msg121137#msg121137

===== listunconfirmed TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Fadeto TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406

{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
Default fade time
http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572

===== Eigenschaften des fade TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== 4.,5. kanal TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== Extra kanäle TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg173280#msg173280
http://forum.fhem.de/index.php?topic=13890.msg214329#msg214329
http://forum.fhem.de/index.php?topic=13890.msg214474#msg214474

==== IR Schnittstelle TBC ====
===== IR TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267
</strike>

===== IR-Belegung Panstamp RGB-Board TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153
</strike>

===== Ircluster TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331
</strike>

===== Irgate TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== DMX Schnittstelle ====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
==== sonstiges ====

===== Alternativer Fade per Patch =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== Kompatibilität RBG-Board mit NRG-panStamps =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Mit dem hier beschriebenen Sketch ist das Board nur mit den AVRs kompatibel.
Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht Ground wie beim AVR.
Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s ein „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0.

{{Link2Forum|Topic=13890 |Message=247069}}
[http://forum.fhem.de/index.php?topic=13890.msg247069#msg247069]

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
=== Bodenfeuchtesensor ===
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbstentwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.
</strike>

In Artikel [[SWAP] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Umweltsensor ===

Die Weiterentwicklung des Bodenfeuchtesensors zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

=== Ultraschall-Füllstandssensor ===

Projektidee

=== Repeater Mode ===

Die Repeaterfunktionalität ist derzeit (01.05.2015) noch nicht näher beschrieben, wird aber von den Modulen unterstützt.
{{Link2Forum|Topic=12487 |Message=118403}}
[http://forum.fhem.de/index.php/topic,12487.msg118403.html#msg118403]

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

SWAP 0000002200000003

2015-07-28T11:57:57Z

TeeVau: /* Anwendungsbeispiele */ Inhalt aus panStamp Diskussion übernommen

Benutzer Diskussion:TeeVau

2015-07-28T09:39:43Z

TeeVau:

Hauptseite

2015-07-27T05:28:26Z

TeeVau: Unterstützte Hardware: panStamp zugefügt

{{DISPLAYTITLE:FHEMWiki - Informationsportal zum FHEM Hausautomationsserver}}
{| width="100%"
|-
|style="vertical-align:top" |

<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; border-radius: 8px; padding: 0 1em 1em 1em; background-color:#cce5ff;">

'''Was ist FHEM?'''

'''FHEM''' ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene [[:Kategorie:Hardware|Komponenten]] aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das FHEMWiki stellt neben dem [http://forum.fhem.de/ Forum] und der [http://www.fhem.de Fhem] Seite die zentrale Informationsquelle rund um FHEM dar.

{{NUMBEROFUSERS}} [[Special:Listusers|Benutzer]] haben sich seit Mai 2013 registriert und {{NUMBEROFARTICLES}} Artikel geschrieben. ({{NUMBEROFEDITS}} Seitenänderungen bislang).

Bitte [[FHEMWiki:Support | unterstütze uns]] und hilf, [[:Kategorie:NeedsEditing| das Wiki zu erweitern]]. Vielen Dank!

<div align="right"><small>'''Mehr [[FHEMWiki:Über_FHEMWiki|über FHEMWiki]]'''</small></div>
</div>

<div style="margin: 0; margin-top:10px; margin-right:10px; border: 1px solid #dfdfdf; border-radius: 8px; padding: 0em 1em 1em 1em; background-color:#efefef;">
'''Wie fange ich an?'''
* [[Datei:Info_green.png|20px]][http://fhem.de/Heimautomatisierung-mit-fhem.pdf FHEM-Übersicht für Anfänger][[Datei:Info_green.png|20px]]<br />DER Startpunkt. '''Pflichtlektüre!'''<br />
* [[Systemübersicht]]
* Phasen eines Fhem-Projekts:
** [[Planung]]
** [[Umsetzung]] (Implementierung)
** [[Betrieb]] ("Produktion")
* [[:Kategorie:Glossary|Glossar]] (Erklärung für bestimmte Begriffe)<br />
* [[:Kategorie:HOWTOS|Verschiedene HowTos]]<br />
* [[:Kategorie:FAQ|Frequently asked Questions - Häufig gestellte Fragen mit Antworten]]<br />

</div>

<div style="margin: 0; margin-top:10px; margin-right:10px; border: 1px solid #dfdfdf; border-radius: 8px; padding: 0 1em 1em 1em; background-color:#fff0e0;">
'''Unterstützte Hardware'''

* [[:Kategorie:Hardware Typen|Hardware Typen]] - Funktionsbezogene Übersicht (z.B. [[:Kategorie:Unterhaltungselektronik|Unterhaltungselektronik / Multimedia]], [[:Kategorie:Heizungssteuerung|Heizungssteuerung]], [[:Kategorie:Energieverbrauchsmessung|Energieverbrauchsmessung]], etc.)
* [[:Kategorie:Server Hardware|Server Hardware]] - Hardware, auf der FHEM installiert werden kann
* [[:Kategorie:FS20 Components|FS20 Komponenten]]
* [[:Kategorie:panStamp|panStamp Komponenten]]
* [[:Kategorie:HMS Components|HMS Komponenten]]
* [[:Kategorie:EMS Components|EMS Komponenten]]
* [[:Kategorie:FHT Components|FHT Komponenten]]
* [[:Kategorie:1-Wire|1-Wire System]]
* [[:Kategorie:EIB/KNX|EIB/KNX Komponenten]]
* [[:Kategorie:EnOcean Components|EnOcean Komponenten]]
* [[:Kategorie:HomeMatic Components|HomeMatic Komponenten]]
* [[:Kategorie:MAX|MAX! Komponenten]]
* [[:Kategorie:Z-Wave Components|Z-Wave Komponenten]]
* [[:Kategorie:IP Components|Geräte mit Webinterface ("IP")]]
* [[:Kategorie:Other Components|Andere Komponenten / Sonstige Systeme]]

<div align="right"><small>'''[[:Kategorie:Hardware|Alle Hardware-Kategorien]]'''</small></div>
</div>

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; border-radius: 8px; padding:0 1em 1em 1em; background-color:#F8F8FF;">
'''Ideen und Lösungen'''

* [[:Kategorie:Code_Snippets|Verschiedene kommentierte Lösungen und Code-Schnippsel]]
* [[:Kategorie:Examples|Beispielanwendungen - Hardwarelösungen - Fremdsystemanbindungen]]
* [[Anwendungsszenarien]]
* [[Trick der Woche|Tipp der Woche]]
* [[Wie kann ich...]]?

<div align="right"><small>'''[[:Kategorie:FHEM|Fhem-Haupt-Kategorien]]'''</small></div>
</div>

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; border-radius: 8px; padding:0 1em 1em 1em; background-color:#FFFFE7;">
'''Developers Corner'''

* [[:DevelopmentModuleIntro|Development Module Introduction]]
* [[:DevelopmentGuidelinesAV|Development Guidelines AV-Module]]
* [[:How_to_write_a_patch|How to write a patch]]

<div align="right"><small>'''[[:Kategorie:Development|Alle Artikel zu Development]]'''</small></div>
</div>

| width="55%" style="vertical-align:top" |
<div style="margin:0; border:1px solid #888888; border-radius: 8px; padding: 0em 1em 1em 1em; background-color:#d7ffff;height:14em;">
'''FHEMWiki News'''
<div style="font-size:small;height:10em;overflow:scroll;overflow-x:hidden;"><small>{{FHEMWiki_News}}</small></div>
<div align="right"><small>'''Mehr [[FHEMWiki:News|News]]'''</small></div>
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; border-radius: 8px; padding:0 1em 1em 1em; background-color:#F8F8FF;">
'''Letzte Änderungen'''
<div style="font-size:small;color:black;"><small>{{Special:Recentchanges/5}}</small></div>
<div align="right"><small>'''Mehr [[Special:Recentchanges|Änderungen]]'''</small></div>
</div>


<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; border-radius: 8px; padding:0 1em 1em 1em; background-color:#FFFFAA;">
'''Die letzten fünf neuen Seiten'''
<small>{{Special:NewPages/5}}</small>
<div align="right"><small>'''Mehr [[Special:NewPages|Neue Seiten]]'''</small></div>
</div>


<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; border-radius: 8px; padding:0 1em 1em 1em; background-color:#DDD68F;">
'''Administratives zum Wiki'''

''Allgemeine Aktivitäten:''
* Registrierung zur Mitarbeit: wende Dich bitte an einen [[FHEMWiki:Administratoren|Administrator]]
* Basiswissen über die Mitarbeit an einem Wiki erarbeiten ([http://de.wikipedia.org/wiki/Wikipedia:Beteiligen z.B. Wikipedia])
* Erweiterung und Korrektur von Artikeln, wo immer nötig
* Ein(ig)e der [[Spezial:Gewünschte Seiten|gewünschten Seiten]] erstellen
* Ideen aus dem [http://forum.fhem.de Forum] in bestehende oder neue Artikel einarbeiten
* [[Spezial:Verwaiste Seiten|verwaiste Seiten]] in sinnvoller Weise verlinken
* [[Spezial:Sackgassenseiten|Sackgassenseiten]] wikifizieren (Links auf andere Seiten einfügen)
* [[Datei:Info_red.png|20px]] '''Tips / Regeln / Hinweise auf "[[FHEMWiki:Über FHEMWiki|Über FHEMWiki]]" beachten!''' [[Datei:Info_red.png|20px]]


''Aktivitäten für Administratoren:''
* Sichten / Löschen von [[:Kategorie:Löschkandidaten|Löschkandidaten]]
* Vorschlag: Einrichten einer Seite, auf der Anfragen an Benutzer mit Admin-Rechten eingetragen werden können
* Beobachten der "Letzten Änderungen"

''Sonstiges:''
* Zum Ausprobieren bitte die [[FHEMWiki:Sandbox]] benutzen
* [//meta.wikimedia.org/wiki/Help:Contents Wiki Benutzerhandbuch].
* [//www.mediawiki.org/wiki/Manual:Configuration_settings Liste der Wiki-Konfigurationsvariablen]
* [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [[FHEMWiki:Interna|Internes zu diesem Wiki]]
</div>

|}

[[Kategorie:FHEM]]

PanStamp Programmierung

2015-07-24T10:08:59Z

TeeVau:

{{SEITENTITEL:panStamp Programmierung}}
{{Baustelle}}
== Programmierung eines panStamp ==

=== Installation panStick ===
Für die Installation des panStick unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den panStick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [http://www.ftdichip.com/]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [https://www.youtube.com/watch?v=SPdSKT6KdF8].

=== Arduino IDE 1.0.x vorbereiten ===
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung für Arduino IDE 1.0 ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der panStamp/SWAP Librarys gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGBWW-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man lädt die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].
* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).
* Unter <code>Tools/Board</code> wird das '''passende Board''' ausgewählt, dass dem Chip auf dem PanStamp entspricht. Für den panStamp AVR: <code>Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328</code>. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt <code>panStamp</code> als Plattform auswählen.
* Nun muss unter <code>Tools/Serieller Port</code> noch der richtigen '''Com-Port''' auswählen werden, unter dem der panStick eingebunden worden ist (entsprechend Gerätemanager).
* Als letztes unter <code>Tools/'''Programmer'''</code> noch den <code>AVRISPx mkII</code> auswählen.

=== Arduino IDE 1.6.x vorbereiten ===
Eine Installationsanleitung für Arduino IDE 1.6.4 ist unter folgendem Link zu finden:
:https://github.com/panStamp/panstamp/wiki/Installing-panStamp-cores-and-libraries-for-Arduino

=== Sketch vorbereiten, kompilieren und hochladen ===
* Den Sketch lädt man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompilieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den panStamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

=== Hexfile hochladen mit XLoader ===
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

== unter Linux ==

=== Installation panStick ===
Zum einen kann es sein, dass der panStick automatisch unter /dev/ttyUSBx eingebunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
lsusb
Sollte etwas Ähnliches zurückmelden:
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen. {{Link2Forum|Topic=12487 |Message=87746 }}

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
cat /proc/devices

Das Device wird dann angelegt mit:
sudo mknod /dev/ttyUSB0 c 188 0

Zusätzlich muss für den Betrieb des panStick das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
lsmod

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen. Damit wird der "Besitzer" festgelegt.
sudo chown root:dialout ttyUSBx

Hiermit werden die Berechtigungen gesetzt.
sudo chmod a+rw /dev/ttyUSBx

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören. Ist dieses nicht der Fall:
sudo adduser fhem dialout

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

=== IDE unter MacOS ===

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}

=== INO ===
Der RGB-Sketch wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die Arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
sudo apt-get install picocom python-pip arduino

Die Installation erfolgt im Anschluss über
sudo pip install ino

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
ino build

Und hochladen über
sudo ino upload

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}

== over-the-air (derzeit) nur NRG ==

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

== Was überlebt das Flashen==
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

== EEPROM löschen ==
Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
eepromToFactoryDefaults()

[[Kategorie:panStamp]]

PanStamp Programmierung

2015-07-24T09:42:34Z

TeeVau:

{{SEITENTITEL:panStamp Programmierung}}
{{Baustelle}}
== Programmierung eines panStamp ==

=== unter Windows ===

==== Installation panStick ====
Für die Installation des panStick unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den panStick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung für Arduino IDE 1.0 ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps
Eine Installationsanleitung für Arduino IDE 1.6.4 ist unter folgendem Link zu finden:
:https://github.com/panStamp/panstamp/wiki/Installing-panStamp-cores-and-libraries-for-Arduino

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man lädt die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem PanStamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der panStick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====
* Den Sketch lädt man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompilieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den panStamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation panStick ====
Zum einen kann es sein, dass der panStick automatisch unter /dev/ttyUSBx eingebunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas Ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des panStick das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketch wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die Arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flashen===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===
Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>

[[Kategorie:panStamp]]

PanStamp Programmierung

2015-07-24T09:42:00Z

TeeVau: TeeVau verschob die Seite Programmierung eines panStamp nach PanStamp Programmierung

{{Baustelle}}
== Programmierung eines panStamp ==

=== unter Windows ===

==== Installation panStick ====
Für die Installation des panStick unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den panStick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung für Arduino IDE 1.0 ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps
Eine Installationsanleitung für Arduino IDE 1.6.4 ist unter folgendem Link zu finden:
:https://github.com/panStamp/panstamp/wiki/Installing-panStamp-cores-and-libraries-for-Arduino

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man lädt die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem PanStamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der panStick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====
* Den Sketch lädt man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompilieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den panStamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation panStick ====
Zum einen kann es sein, dass der panStick automatisch unter /dev/ttyUSBx eingebunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas Ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des panStick das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketch wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die Arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flashen===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===
Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>

[[Kategorie:panStamp]]

Diskussion:PanStamp

2015-07-24T09:41:01Z

TeeVau: /* Schritte der Inbetriebnahme */ Inhalt in Artikel panStamp (Systemübersicht) übernommen.

{{Baustelle}}
'''Anmerkung für die hier vorgeschlagene Änderung des Hauptartikels'''
Während ich mich mit dem Thema vertraut gemacht habe, habe ich versucht, alle Informationen, die aus non-developer Sicht für die spätere Anwendung und Inbetriebnahme relevanten Informationen (also aus meiner ;) ) wichtig erscheinen, hier in einem Artikel zusammenfassen. Ich muss gestehen, bis ich meine ersten Panstamps am Laufen hatte, musste ich viel lesen und der derzeitige Artikel setzt mM recht viel Wissen voraus (alles eine Frage des Wissensstandes).
Die Inhalte des derzeitigen Artikels habe ich übernommen und einfließen lassen, d.h. es ist geplant, die derzeitige Seite zu ersetzen!

In diesem Artikel sind alle Posts bis heute (14.04.2015) aus den beiden Threads {{Link2Forum|Topic=12487 |Message=74967 |LinkText=Thema: panStamp support }} und {{Link2Forum|Topic=13890 |Message=86952 |LinkText=Thema: PanStamp Board RGB,CW,WW;DMX;IR }} berücksichtigt.

Da viele Informationen vor allen Dingen aus der Zeit der Entwicklung der Module und der Sketches stammen, bitte ich Euch, hier kritisch quer zu lesen, das geschriebene zu prüfen, ob noch aktuell und ggf. zu korrigieren, zu ergänzen oder im Forum konstruktiv zu kommentieren.

Dinge, die mir unklar waren, da noch nicht getestet oder Dinge, die noch näherer beschrieben werden können, habe ich mit "?" bzw. "TBC" gekennzeichnet.
----
: Hallo, wie ist denn der Stand mit dem Artikel? Finde es schade, dass das gesammelte Know-how hier nur auf der Diskussionsseite zu finden ist. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 12:07, 15. Jul. 2015 (CEST)

{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}

{{Todo|Fehlerkontrolle, Formatierung, Ergänzung, Bestätigung des Geschriebenen, weitere Informationen zur Erstellung/Anpassung eines Device Description Files, Bestätigung des Hochladens mittels XLoader, Bedienung in FHEMWEB(RGB-Board/Sketch)}}

== Allgemeines ==

=== Hardware ===
==== panStamp mit Antenne ====
[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem stück Draht in der [https://code.google.com/p/panstamp/wiki/antennalengths richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht. Auch nicht auf kurze Distanzen.

Mittlerweile gibt es zwei verschiedene panStamps (AVR und NRG), von denen der NRG neuer und etwas mehr Features zur Verfügung stellt, allerdings (noch) nicht mit allen hier beschriebenen Projekten kompatibel ist.

==== Panstick oder Panshield ====
<strike>
Als Schnittstelle zwischen Server-Hardware und einem panStamp dient entweder ein panStick (USB Stick mit Sockel zum aufstecken eines panStamp) oder ein "panStamp Shield" mit integriertem panStamp an einem Raspberry Pi. Der Panstick stellt dabei die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface des Panstamps auf der anderen Seite dar. Ein Panshield übernimmt die gleiche Funktion, wird aber direkt an die IOs eines Raspberries angeschlossen.

Der Panstick wird grundsätzlich für zwei Aufgaben benötigt:
# Für die Vorbereitung eines panStamps für den Betrieb auf einem "Board" wird der neue panStamp in den Panstick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
# Im "normalen" Betrieb steckt ein panStamp auf ihm. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und dient so dem Rechner als Interface zu anderen panStamps, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird.

Da auf dem panStamp Shield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die zweite Funktion.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:10, 17. Jul. 2015 (CEST)

==== spezifisches "Board" ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
: Im Gegenzug zum Panstick als Interface zwischen panStamp und USB-Port des Servers stellt das Board das Interface zwischen panStamp vor Ort und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs des panStamps auf die Ausgänge um bzw. leitet die Eingänge zur Auswertung an den panStamp weiter.
: Entsprechend Anwendungsfall und Sketch werden die Ein-/Ausgänge des panStamps verarbeitet. Z.B. können an ein Board Temperatur-, Feuchtigkeitssensoren oder LED-Strips angeschlossen werden. Der Sketch auf dem panStamp sollte entsprechend der Anwendung auf dem Board angepasst worden sein um nicht nur über die standardmäßig zur Verfügung stehenden Register kommunizieren zu müssen.

: Das Board benötigt irgend eine Art von Stromversorgung, um den panStamp zu betreiben. Das kann im Falle eines Sensorboards und entsprechend stromsparend ausgelegtem Sketch eine Batterie sein oder wie im Falle des RGB-Boards eine externe Stromversorgung.
: Speziell beim unten beschriebenen RGB-Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder ingesamt panStamp und LEDs gemeinsam versorgen.

</strike> Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)
=== Software ===

==== Simple Wireless Abstract Protocol (SWAP) ====
<strike>
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.
Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

==== Modem-Sketch ====
{{Randnotiz|RNText=In Artikel [[panStick]]}}
<strike>
Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und Funksignal dar, dass an andere panStamps geht.

Auf jedem panStamp (AVR, NRG?) ist im Auslieferungszustand der Modem-Sketch installiert. Das Protokoll der Funkstrecke folgt dem SWAP-Protokoll.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== auf Board abgestimmter Sketch ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Ein panStamp ist auf einem entsprechenden Board installiert und übernimmt dort lokal die Schnittstelle zwischen Funkstrecke und Board.

Der Sketch stellt dabei die passende "Software" auf dem panStamp. Der Sketch verarbeitet die über das SWAP-Protokoll versandte Nachrichten, wertet diese aus, reagiert entsprechend und setzt die Outputs des Boards. In umgekehrter Richtung wertet er die an den Inputs des Board angelegten Signale aus, verarbeitet diese und schickt sie per SWAP-Protokoll zum Panstamp mit Modem-Sketch zurück.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Module und Description File ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden genauer beschrieben werden. Zusammengefasst gibt es 3 Ebenen mit der Ergänzung eines Konfigurationsfiles in xml-format.
{{Link2Forum|Topic= 13890 |Message=121689 }}
[http://forum.fhem.de/index.php/topic,13890.msg121689.html#msg121689]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 1: 34_panStamp.pm =====
<strike>
Das Modul ist für einen panStamp der auf einem panStick sitzt und das Interface zwischen FHEM und dem panStamp netz bildet. Alle eintreffenden SWAP-Pakete auf dem panStick (mit Modem-Sketch) werden direkt durchgereicht und im nachfolgend beschriebenen SWAP-Modul verarbeitet.
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 2: 34_SWAP.pm =====
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
<strike>
Das Modul implementiert das SWAP protokoll das zwischen den panStamps gesprochen wird. Das SWAP Modul ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM.

Bei SWAP geht alle Komunikation über 'register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jedes device hat eine Reihe System register (00-0A) und beliebig viele user register die vom jeweiligen Sketch abängen. Welche Register dies sind, steht unter anderem jeweils im Device Description xml file im Verzeichnis .../FHEM/lib/SWAP.

In den System Registern steht z.b. der productcode, die device adresse und das Übertragungsintervall. Konfigurierbare register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).

Die Inhalte der System Register stehen als internal values im oberen Bereich der Detail Ansicht einer Komponente in FHEM, die user register als readings im unteren.

Alle low level Dinge wie Register id oder Register Wert können mit hex werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den register namen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (teile eines registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem panStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
</strike>

In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

===== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm =====
{{Randnotiz|RNText=In Artikel [[paNStamp]]}}
<strike>
Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Mit dieser dritten Modulebene ist es auch für Aktore wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.

Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.

Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Ein Beispiel für das RGB-Board dafür ist das Modul 35_SWAP_0000002200000003.pm.
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Device Description File =====
<strike>
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

=== Systemübersicht ===
<strike>
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.
[[Datei:Panstamp-Systemoverview.jpg|200px|thumb|panStamp Systemübersicht]]

{{Link2Forum|Topic=12487 |Message=75980 }}
[http://forum.fhem.de/index.php?topic=12487.msg75980#msg75980]

Die Kommunikationskette ist wie folgt:
FHEM -> Host-hardware/OS -> USB -> Panstick -> panStamp (Modem-Sketch) -> Funkstrecke (SWAP) -> panStamp (angepasster Sketch) -> Board -> Sensoren/LED-Strip/etc.

(Ein Panshield ersetzt "USB -> Panstick" durch "IO's am Rpi-> Panshield")
</strike>

Inhalt übernommen in Artikel [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:50, 17. Jul. 2015 (CEST)

== Schritte der Inbetriebnahme ==
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board:

* Ein panStamp wird in einen Panstick gesteckt und der Panstick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.
* Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).
* Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf den panStamp hochgeladen.
* Der programmierte panStamp aus dem Panstick in das RGB-Board stecken.
* Einen panStamp mit Modem-Sketch in den Panstick stecken und an den FHEM-Host stecken.
* panStamp unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
* RGB-Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, der panStamp automatisch eingerichtet werden.
* SWAP-Device in FHEM an Gegebenheiten anpassen.

</strike> Inhalt in Artikel [[PanStamp (Systemübersicht)]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:41, 24. Jul. 2015 (CEST)

== Programmierung eines panStamps ==
<strike>
=== unter Windows ===

==== Installation Panstick ====
Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====

Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man läd die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem Panstamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der Panstick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====

* Den Sketch läd man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation Panstick ====

Zum einen kann es sein, dass der Panstick automatisch unter /dev/ttyUSBx einbunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des Pansticks das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketches wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flaschen ===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===

Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>
</strike>

In Artikel [[Programmierung eines panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:36, 17. Jul. 2015 (CEST)

== Integration in FHEM ==
=== FHEM Voraussetzungen ===
<strike>
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>

Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
</strike> Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== Pfade innerhalb der FHEM Installation ====

Die Module befinden sich wie gewohnt im Installationsverzeichnis unter ./FHEM.
<strike>
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Register ===
<strike>
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Verwendung innerhalb FHEM ===
{{Randnotiz|RNText=In Artikel [[panStamp]] [[panStick]]}}
<strike>
Zu unterscheiden ist die Definition des "Panstick", wobei der panStamp, der als RF-Modem auf dem Panstick sitzt, gemeint ist. Dieser wird im Folgenden mit "Panstick" als Name des Device benannt . Der Type ist "panstamp".

Auf der anderen Seite gibt es die Definition der panStamps, die lokal auf den entsprechenden Boards stecken. Diese sind vom Type SWAP_<ProductCode>. Um die Verwirrung komplett zu machen, wird hier meistens vom "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind. Für diese werden hier nur die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Komandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des Productcode zur Verfügung stehen, werden bei den spezifischen Anwendungen beschrieben.

</strike> In [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Panstick ====
<strike>
===== Definition =====
Das Device "Panstick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv sind.

'''Betrieb an der FB'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernaschluss deaktiviert sein.

===== Attribute =====

Für den "Panstick" gibt es keine modulspezifischen Attribute.

===== Set =====

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
In diesem Beispiel wird ein broadcast an alle abgesetzt, damit diese ihre ID und ihren productcode zurück senden.
Das macht der panStick nach dem Initialisieren auch ein mal automatisch um alle nicht schlafenden Devices per autocreate anlegen zu können.

Mit diesem Befehl "raw" lassen sich SWAP-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 20:05, 17. Jul. 2015 (CEST)

==== SWAP ====

Alle empfangen SWAP Nachrichten werden in internals/readings im jeweiligen Device angezeigt.

===== Definition =====
<strike>
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== set =====
''ZUGEFÜGT ZU SWAP ARTIKEL, STRIKE FUNKTIONIERT ABER IN DIESEM ABSATZ NICHT''
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
* ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== get =====
<strike>
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== Attribute =====
<strike>
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest. Dieses Attribut wird dazu benutzt, die Konfiguration vom Device-XML-File festzulegen.
Erst wenn der Produktcode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen Kommandos die spezifischen der nächst höheren Modulebene 35_SWAP_<productcode>.pm mit hinzu. Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== SWAP_<ProductCode> ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Ist bei einem SWAP-Device das Attribut Productcode gesetzt, wird die SWAP-Nachricht an das entsprechende Modul der 3. Ebene weitergegeben und dort verarbeitet. Die spezifischen Kommandos und Attribute sind bei den entsprechenden [[panstamp#Explizite Anwendungen|Anwendungen]] näher beschrieben.
</strike>

Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

==== Intervall bei Sketch mit power down / batterie betriebene Panstamps ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Devices mit power down mode durchlaufen beim Einschalten oder bei einem Reset eine 3 Sekunden Schleife und warten auf Kommandos, dann werden normaler Weise die Register mit den Sensorwerten gesendet und die normale Loop gestartet. power down devices gehen danach schlafen und wachen regelmässig auf um ihre Werte zu senden.
Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.

Nachrichten an ein Device im power-down-state werden gepuffert und dann an das Device geschickt, sobald dieses sich im SYNC status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:

<pre> set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> </pre>
{{Link2Forum|Topic=12487 |Message=87409}}
[http://forum.fhem.de/index.php?topic=12487.msg87409#msg87409]

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert.

Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist.
{{Link2Forum|Topic=12487 |Message=89205}}
[http://forum.fhem.de/index.php/topic,12487.msg89205.html#msg89205]

{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF in 0A zum Überlauf führt und dann ununterbrochen gesendet wird. Im fhem Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum senden kommt.
Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden und noch mal flashen. Wenn der Sketch damit ein mal durchgelaufen ist können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht.

Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}
[http://forum.fhem.de/index.php/topic,12487.msg87859.html#msg87859]

Für Devices im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald das Device seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos Reset zu drücken oder die Stromquelle erneut zu verbinden.

Die automatisch vergebenen Adressen sind im Bereich F0-FE. d.h. eigentlich auch nur temporär und sollten auf eine lokal passende geändert werden.
{{Link2Forum|Topic=12487 |Message=87919}}
[http://forum.fhem.de/index.php/topic,12487.msg87919.html#msg87919]

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>
Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)
==== Verschlüsselung ====

Die Aktivierung der Verschlüsselung für die Kommunikation zwischen panStamp und panStick ist hier beschrieben, scheint allerdings derzeit noch nicht eingecheckt zu sein (Stand 01.05.2015).
{{Link2Forum|Topic=12487 |Message=133040}}
[http://forum.fhem.de/index.php/topic,12487.msg133040.html#msg133040]
{{Link2Forum|Topic=12487 |Message=139341}}
[http://forum.fhem.de/index.php/topic,12487.msg139341.html#msg139341]

=== Trouble Shooting ===
<strike>
==== value has to be 10 byte(s) in size ====

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

==== register 0F is not known ====

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

==== Komplette Übersicht eines Device ====

<pre>
list <device>
</pre>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

==== fehlender oder falsche Productcode ====

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

==== missing commands und register 00-0A unvollständig ====

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

==== Funktion des Autocreate ====

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

==== Adresse manuell setzen ====

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

==== Panstamp antwortet nicht/EEprom to factory defaults ====

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

==== Undefined subroutine &main::XMLin ====
Erhält man diese Fehlermeldung
<pre>
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.
</pre>
<pre>
2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!
</pre>

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

==== Factory Defaults ====

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

==== Status LED ====

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

</strike> Inhalt in Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:00, 17. Jul. 2015 (CEST)

== Explizite Anwendungen ==
=== RGB-Board ===
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
==== Allgemeines ====
<strike>
Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

Eine Übersicht über die derzeit vorhandene Funktionalität (stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
[http://forum.fhem.de/index.php?topic=13890.msg120404#msg120404]

* bis zu vier LED-Kanäle (je nach Kombination von ir und soft pwm)
* ir senden
* ir empfangen
* Messen ob die LED-Versorgung an ist.
* Helligkeit eines an A2 angeschlossenen Helligkeitssensors
* Konfiguration der DMX-Basis-Adresse über das SWAP Register 0x12
* optional soft on auf letzten Wert
* Alles was auch vorher schon ging: dimmen, faden, IR-Fernbedienungen anlernen, ...

Wichtig zu wissen:
* Wenn IR aktiv ist und kein soft pwm lässt sich der 4. Kanal nur ein- und ausschalten.
* Wenn IR aktiv ist muss soft pwm aktiv sein um den 4. Kanal auch zu dimmen.
* Es wird nur ein zusätzlicher Kanal tatsächlich schon unterstützt, der fünfte ist noch geplant.
* Bei IR-Senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die anderen sind aber einfach zu ergänzen.
* Beim IR-Senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein.

was noch kommt:
* besseres soft pwm
* mehr Konfiguration bezüglich default-Verhalten. Ramp-Zeiten, Delays, ...
* HSV-Farb-Modell um besser zu faden und vor Allem um den Weiss-Anteil automatisch auf die Weiss-LEDs zu legen
* die virtuellen Channel
* FHEM kompatibles IR-Senden
* sofortiges senden von Helligkeit und LED-Spannung bei Änderung
* andere IR-Lib mit sehr viel besserer Geräte-Unterstützung

Wie gehabt muss alles über config.h mit Compilerschaltern konfiguriert werden.
</strike>

Inhalt in Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== weitrere Screenshots =====
<strike>
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>
</strike>

Inhalt in Artikel [[SWAP_0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== original RGB-Sketch (von panstamp.com) =====
Der originale Sketch von der panStamp.com-Seite und das generelle FHEM-Modul verstehen von Haus aus nur die regSet und regGet Kommandos. Wenn man den colorpicker verwenden möchte, geht das nur per readingsProxy.

Das einfachste ist es den Sketch und das FHEM-Modul für das RGB-Board zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen Kommandos wie on, off, on-for-timer, dimup, ... und kann konfigurieren, wie das Board nach dem Hart- oder Soft-Einschalten reagieren soll.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden.
{{Link2Forum|Topic=12487 |Message=220463}}
[http://forum.fhem.de/index.php/topic,12487.msg220463.html#msg220463]

Falls jemand trotzdem den normalen RGB-Sketch verwendet:
* Im Code alle drei 0000002200000003 durch 0000000100000003 ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

==== Sketch vorbereiten, kompilieren und hochladen ====
===== Vorbereitungen =====
<strike>
(Stand 01.05.2015)

Mit der Arduino IDE 1.5.x gab es gundlegende Umstellungen, für die der derzeitige Sketch [r4716] vermutlich angepasst werden müsste.

Für den RGB-Driver sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin C:\Users\<username>\Documents\Arduino\libraries. Am Ende der ganzen Aktion im Folgenden sollten sich in diesem Unterordner 3 neue Unterordner befinden: IRremote, DMXSerial und panstamp

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Libraries richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter Sketch/Library importieren die 3 weiteren Punkte unten unter "beigetragen" auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino libraries Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).

Für das kompilieren mit INO siehe [[panstamp#ino|hier]].

===== Link zum sketch =====
Die aktuelle Version des RGB-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge].
{{Link2Forum|Topic=13890 |Message=201391}}
[http://forum.fhem.de/index.php?topic=13890.msg201391#msg201391]

===== Kompillierte hex version =====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=121619}}
[http://forum.fhem.de/index.php?topic=13890.msg121619#msg121619]

===== HEX-File ohne IR und DMX =====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=201955}}
[http://forum.fhem.de/index.php?topic=13890.msg201955#msg201955]

===== Sketch anpassen, kompilieren und hochladen =====

* Welche Features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der #define ENABLE_... Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}} [http://forum.fhem.de/index.php?topic=13890.msg173431#msg173431] Den Sketch entsprechend den Bedürfnissen in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen. Für die Konfigurationen siehe [[panstamp#Sketch konfigurieren|Sketch konfigurieren]].
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

==== Sketch konfigurieren ====

===== DMX =====
<pre>
#define ENABLE_DMX
</pre>

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei DMXSerial.h die Zeile

<pre>
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
</pre>

in

<pre>
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
</pre>

abgeändert werden muss.

===== Temperatur- und Luftfeuchtigkeitssensor =====

<pre>
#define HAS_SENSOR
</pre>

Dieses ermöglicht die Nutzung eines DHT22 Sensors zur Auswerung von Temperatur und Luftfeuchtigkeit.

Dafür sollten diese Konfigurationszeilen auskommentiert sein
<pre>
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;
</pre>

In der IRremote.cpp Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>
sowie die Irremote.h Datei unter Public: um die Zeile
<pre>
void disableIRIn();
</pre>
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an A2 des panStamps angeschlossen werden.

Ein Beispiel für die Umrechnung der Userreading für Spannung Temp etc. ist hier beschrieben.
{{Link2Forum|Topic=12487 |Message=76489}}
[http://forum.fhem.de/index.php?topic=12487.msg76489#msg76489]

===== Zusammenhänge der Konfiguration =====

Die Zusammenhänge der Konfiguration sind hier beschrieben
{{Link2Forum|Topic=13890 |Message=175181}}
[http://forum.fhem.de/index.php?topic=13890.msg175181#msg175181]
</strike>

Inhalt in Artikel [[PanStamp RGBWW Board mit DMX und IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== Bedienung in FHEMWEB ====

===== Komandos =====

====== Definition ======

Der Panstick wird entsprechend folgendem Befehlt angelegt:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle ist entsprechend Installation des [[panstamp#unter Linux|Pansticks]] anzupassen.

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv ist.

====== Attribute TBC ======

====== Set TBC ======

====== Get TBC ======
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923

EIn register verändern
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Register umrechnung dec zu hex TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Poweronstate TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg88054.html#msg88054
http://forum.fhem.de/index.php/topic,12487.msg95574.html#msg95574
http://forum.fhem.de/index.php/topic,13890.msg124456.html#msg124456

===== Aus nach poweron TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg121296#msg121296
Power on register
http://forum.fhem.de/index.php?topic=13890.msg121137#msg121137

===== listunconfirmed TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Fadeto TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406

{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
Default fade time
http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572

===== Eigenschaften des fade TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== 4.,5. kanal TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== Extra kanäle TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg173280#msg173280
http://forum.fhem.de/index.php?topic=13890.msg214329#msg214329
http://forum.fhem.de/index.php?topic=13890.msg214474#msg214474

==== IR Schnittstelle TBC ====
===== IR TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267
</strike>

===== IR-Belegung Panstamp RGB-Board TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153
</strike>

===== Ircluster TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331
</strike>

===== Irgate TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== DMX Schnittstelle ====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
==== sonstiges ====

===== Alternativer Fade per Patch =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== Kompatibilität RBG-Board mit NRG-panStamps =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Mit dem hier beschriebenen Sketch ist das Board nur mit den AVRs kompatibel.
Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht Ground wie beim AVR.
Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s ein „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0.

{{Link2Forum|Topic=13890 |Message=247069}}
[http://forum.fhem.de/index.php?topic=13890.msg247069#msg247069]

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
=== Bodenfeuchtesensor ===
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbstentwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.
</strike>

In Artikel [[SWAP] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Umweltsensor ===

Die Weiterentwicklung des Bodenfeuchtesensors zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

=== Ultraschall-Füllstandssensor ===

Projektidee

=== Repeater Mode ===

Die Repeaterfunktionalität ist derzeit (01.05.2015) noch nicht näher beschrieben, wird aber von den Modulen unterstützt.
{{Link2Forum|Topic=12487 |Message=118403}}
[http://forum.fhem.de/index.php/topic,12487.msg118403.html#msg118403]

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]

SWAP

2015-07-23T13:57:43Z

TeeVau:

{{Baustelle}}
{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der PanStamp Baugruppen. Zur Kommunikation in einem PanStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. [[SWAP_0000002200000003]]) vorhanden sein. Diese Module bauen, als 3. Ebene, auf das SWAP Modul (2. Ebene) auf und bedienen im backend ebenfalls die panStamp-Hardware über die Register. Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
sudo apt-get install libxml-simple-perl
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das [[SWAP]] Modul greift auf das [[PanStamp]] Modul zu, was vorher per <code>define</code> angelegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über [https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol#registers-and-values '''Register'''], dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können.
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele, sketchabängige Userregister (<code>0B</code>-<code>xx</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers#custom-registers] bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files'', die in <code>.../FHEM/lib/SWAP</code> zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt''-ID [https://github.com/panStamp/panstamp/wiki/How-to-develop-your-own-SWAP-device#specify-your-product-code] gebildet wird. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
In den Systemregistern steht z.b. der ProductCode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert. Also z.b. Adresse <code>FF</code> und Intervall <code>FFFF</code> (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).
Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

Alle low level Dinge wie Register ID oder Register Wert können mit '''hex Werten'' direkt angepasst werden.
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87436 }}

Das [[SWAP]]-Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Queue für panStamp-Hardware im power down Modus gehalten. Sobald die panStamp-Hardware online (SYNC Modus) kommt werden die Kommandos von FHEM automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des Device Definition Files automatisch erzeugt
* Es ist möglich direkt endpoints (Teile eines Registers) zu schreiben
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulebene neben dem [[PanStamp]] FHEM-Modul (1. Ebene) für die Hardware und dem SWAP Modul (2. Ebene) für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP Devices ''zu Fuß'' über die Register ansprechen. Um die Register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann ein Modul der 3. Ebene notwendig. {{Link2Forum|Topic=12487 |Message=78502 }}

=== Define ===
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''
Wenn der [[panStick]] läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset. Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem ProductCode. Die ID ist die SWAP Device Addresse und bei einem frisch geflashten panStamp in der Regel <code>FF</code>. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0 - FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Adresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* <code>00</code> ist die Broadcast-ID
* <code>01</code> ist die ID des [[panStick]] am FHEM-System
* <code>FF</code> ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* <code>F0-FE</code> sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID <code>FF</code> erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich <code>F0 - FE</code> und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
define <device> SWAP <ID>
Bis allerdings der ProductCode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch passiert, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Definition-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von panStamps NRG unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Definition-XML-File ein. Erst wenn der ProduktCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Definition File ===
Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch ''menschenlesbare'' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen Readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Definition File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele sketchabängige Userregister (<code>0B</code> - <code>xx</code>)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z.B. der ProductCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert, also z.B. die Adresse <code>FF</code> und das Intervall <code>FFFF</code> (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene Panstamps ===
panStamp Hardware mit power down mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet. Normaler Weise werden dann die Register mit den Sensorwerten an FHEM gesendet. Power down devices gehen danach schlafen (power down Modus mit extrem niedrigen Stromverbrauch) und wachen regelmäßig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modus keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich variieren und anders programmiert sein!

Nachrichten an eine panStamp-Hardware im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an die panStamp-Hardware geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device definition file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von <code>FFFF</code> im Systemregister <code>0A</code> zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass FHEM mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum senden kommt. Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch ein mal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf <code>0x5555</code> (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul eine panStamp-Hardware mit der Adresse <code>0xFF</code> wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich <code>0xF0 - 0xFE</code>. Das soll das inbetriebnehmen von mehreren panStamp-Hardwaremodulen gleichzeitig erleichtern. Der automatisch vergeben Adressbereich ist begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fälle werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix Sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das Register <code>0A</code> konfigurierbar. Der Sensor wird an GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
set <device> statusRequest
set <device> readDeviceXML

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiß welche Firmware auf der panStamp-Hardware ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}

=== register 0F is not known ===

{{Link2Forum|Topic=12487 |Message=84257}}

=== Komplette Übersicht eines Device ===

list <device>
{{Link2Forum|Topic=13890 |Message=201467}}

=== fehlender oder falsche ProductCode ===

Fehlt der ProductCode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den ProductCode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
set <device> statusRequest

{{Link2Forum|Topic=13890 |Message=201910}}

=== missing commands und register 00-0A unvollständig ===

Wenn in den INTERNALS missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register <code>00-0A</code> nicht vollständig sind und das INTERNAL "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}

=== Funktion des Autocreate ===

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trotzdem <code>FF</code>. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde. {{Link2Forum|Topic=12487 |Message=88110}}

=== Adresse manuell setzen ===

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
sudo apt-get install libxml-simple-perl

=== Panstamp antwortet nicht/EEprom to factory defaults ===

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in <code>setup()</code> ein <code>eepromToFactoryDefaults()</code> aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen Sketch flashen. {{Link2Forum|Topic=13890 |Message=121677}}

=== Factory Defaults ===

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die <code>setup()</code> Routine einfügen:
eepromToFactoryDefaults()
{{Link2Forum|Topic=13890 |Message=157125}}

=== Status LED ===

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit <code>#define LED_DEBUG</code> mit "//" auskommentiert. {{Link2Forum|Topic=13890 |Message=164731}}

== Links ==

[[Kategorie:panStamp]]

SWAP

2015-07-23T07:13:51Z

TeeVau:

{{Baustelle}}
{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der PanStamp Baugruppen. Zur Kommunikation in einem PanStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. [[SWAP_0000002200000003]]) vorhanden sein. Diese Module bauen, als 3. Ebene, auf das SWAP Modul (2. Ebene) auf und bedienen im backend ebenfalls die panStamp-Hardware über die Register. Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das SWAP Modul greift auf das [[PanStamp]] Modul zu, was vorher per define anglegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über [https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol#registers-and-values '''Register'''], dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können.
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele, sketchabängige Userregister (<code>0B</code>-<code>xx</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers#custom-registers] bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files'', die in <code>.../FHEM/lib/SWAP</code> zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt''-ID [https://github.com/panStamp/panstamp/wiki/How-to-develop-your-own-SWAP-device#specify-your-product-code] gebildet wird. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
In den Systemregistern steht z.b. der ProductCode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert. Also z.b. Adresse <code>FF</code> und Intervall <code>FFFF</code> (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).
Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

Alle low level Dinge wie Register ID oder Register Wert können mit '''hex Werten'' direkt angepasst werden.
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87436 }}

Das [[SWAP]]-Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Queue für panStamp-Hardware im power down Modus gehalten. Sobald die panStamp-Hardware online (SYNC Modus) kommt werden die Kommandos von FHEM automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des Device Definition Files automatisch erzeugt
* Es ist möglich direkt endpoints (Teile eines Registers) zu schreiben
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulebene neben dem [[PanStamp]] FHEM-Modul (1. Ebene) für die Hardware und dem SWAP Modul (2. Ebene) für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP Devices ''zu Fuß'' über die Register ansprechen. Um die Register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann ein Modul der 3. Ebene notwendig. {{Link2Forum|Topic=12487 |Message=78502 }}

=== Define ===
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''
Wenn der [[panStick]] läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset. Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem ProductCode. Die ID ist die SWAP Device Addresse und bei einem frisch geflashten panStamp in der Regel <code>FF</code>. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* <code>00</code> ist die Broadcast-ID
* <code>01</code> ist die ID des Pansticks am FHEM-System
* <code>FF</code> ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* <code>F0-FE</code> sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID <code>FF</code> erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich <code>F0-FE</code> und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
define <device> SWAP <ID>
Bis allerdings der ProductCode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch passiert, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von panStamps NRG unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Definition-XML-File ein. Erst wenn der ProduktCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Definition File ===
Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch ''menschenlesbare'' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen Readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Definition File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (00-0A) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene Panstamps ===
Devices mit power down mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet normaler Weise werden die Register mit den Sensorwerten an FHEM gesendet. Power down devices gehen danach schlafen (power down Modus mit extrem niedrigen Stromverbrauch) und wachen regelmässig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modes keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich varieren und anders programmiert sein!

Nachrichten an ein panStamp-Modul im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an das panStamp-Modul geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF im Systemregister 0A zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum senden kommt. Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch ein mal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf 0x5555 (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul ein panStamp Modul mit der Adresse 0xFF wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich 0xF0 bis 0xFE. Das soll das inbetriebnehmen von mehreren panStamp-Modulen gleichzeitig erleichtern. Der automatisch vergeben Adressebereich ist nur begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fälle werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}

=== register 0F is not known ===

{{Link2Forum|Topic=12487 |Message=84257}}

=== Komplette Übersicht eines Device ===

list <device>
{{Link2Forum|Topic=13890 |Message=201467}}

=== fehlender oder falsche Productcode ===

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}

=== missing commands und register 00-0A unvollständig ===

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}

=== Funktion des Autocreate ===

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}

=== Adresse manuell setzen ===

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

=== Panstamp antwortet nicht/EEprom to factory defaults ===

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}

=== Factory Defaults ===

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}

=== Status LED ===

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}

== Links ==

[[Kategorie:panStamp]]

ESP32 Innenraumsensor und -Steuerung

2015-07-23T06:38:11Z

TeeVau:

{{SEITENTITEL:panStamp Innenraumsensor}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sensor
|HWCategory=HardwareMods
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V
|HWPowerConsumption=
|HWPoweredBy=Battery AA
|HWSize=48.5 x 100 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=für diesen Sketch: [http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
|HWManufacturer=panStamp
}}

{{Baustelle}}

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Arduino IDE oder mit dem ino Kommandozeilen Binary programmieren. Dieser bildet das Herzstück des Umweltsensors

Weiterführende Information zu panStamps und den grundlegenden Modulen um sie mit Fhem zu integrieren finden sich im zugehörigen [[PanStamp|Wiki Artikel]].

== Beschreibung ==

=== Bootloader flashen ===
Anschließend muss man nun die Fuses korrekt setzen (8Mhz Internal, 3.3v):

avrdude -p m2560 -c stk500v2 -P /dev/ttyUSB0 -U lfuse:w:0xE2:m -U hfuse:w:0xD4:m

und final den Bootloader flashen
wget https://github.com/lthiery/Sentinel/blob/master/sketches/hardware/mega-pro-3.3V/bootloaders/MegaPro3.3V-8MHz-57600.hex
avrdude -p m2560 -c stk500v2 -P /dev/ttyUSB0 -U flash:w:MegaPro3.3V-8MHz-57600.hex

Jetzt kann man mit einem normalen USB-ParallelProgrammer testen ob der Chip ansprechbar ist:
avrdude -c arduino -b 57600 -P /dev/ttyUSB0 -p m2560 -v

und anschließend den Sketch drauf flashen:
avrdude -c arduino -b 57600 -P /dev/ttyUSB3 -p m2560 -U flash:w:MeinSketch.hex

[[Kategorie:PanStamp]]

Diskussion:Panstamp Innenraumsensor

2015-07-23T06:37:04Z

TeeVau: TeeVau verschob die Seite Diskussion:Panstamp Innenraumsensor nach Diskussion:PanStamp Innenraumsensor: Schreibweise den anderen Artikeln anpassen

#WEITERLEITUNG [[Diskussion:PanStamp Innenraumsensor]]

Diskussion:ESP32 Innenraumsensor und -Steuerung

2015-07-23T06:37:04Z

TeeVau: TeeVau verschob die Seite Diskussion:Panstamp Innenraumsensor nach Diskussion:PanStamp Innenraumsensor: Schreibweise den anderen Artikeln anpassen

Hi, es ist nur eine Kleinigkeit: Spricht was dagegen den Artikel zu verschieben auf den Artikel "PanStamp Innenraumsensor"? Dann wären alle Artikel gleich von der Schreibweise (PanStamp anstatt Panstamp). --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 22:18, 17. Jul. 2015 (CEST)
<hr />
:Bin einverstanden (und falls die korrekte Schreibweise panStamp ist/sein sollte (Mediawiki macht halt den ersten Buchstaben des Seitentitels immer zum Großbuchstaben), kannst Du das mit '''<nowiki>{{SEITENTITEL:naMeInRichtigerSchreibweise}}</nowiki>''' am Anfang der Seite auch noch "erzwingen"). --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 23:13, 17. Jul. 2015 (CEST)
<hr />
::Das mit <nowiki>{{SEITENTITEL:naMeInRichtigerSchreibweise}}</nowiki> ist ein guter Hinweis, danke!. Ich kenn mich so mit den Spielregeln nicht aus, sollte sich noch der Author (tobias.faust) von dem Artikel dazu melden? --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:49, 18. Jul. 2015 (CEST)
<hr />
:::Persönlich würde ich sofort verschieben, da das jetzt keine so entscheidende Umstellung ist und damit Du bei Deinen recht umfangreichen Arbeiten (Danke übrigens!) weiterkommst. Ansonsten (=100%-Lösung) tobias.faust direkt ansprechen, da er Deine Frage vermutlich nicht gesehen hat.--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:36, 20. Jul. 2015 (CEST)

Panstamp Innenraumsensor

2015-07-23T06:37:04Z

TeeVau: TeeVau verschob die Seite Panstamp Innenraumsensor nach PanStamp Innenraumsensor: Schreibweise den anderen Artikeln anpassen

#WEITERLEITUNG [[PanStamp Innenraumsensor]]

ESP32 Innenraumsensor und -Steuerung

2015-07-23T06:37:04Z

TeeVau: TeeVau verschob die Seite Panstamp Innenraumsensor nach PanStamp Innenraumsensor: Schreibweise den anderen Artikeln anpassen

Datei:Panstamp-Systemoverview.jpg

2015-07-23T06:29:55Z

TeeVau: TeeVau lud eine neue Version von Datei:Panstamp-Systemoverview.jpg hoch

SWAP

2015-07-21T07:33:30Z

TeeVau: /* Anwendung */ Inhalte aus panStamp Artikel eingefügt.

{{Baustelle}}
{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der PanStamp Baugruppen. Zur Kommunikation in einem PanStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. xxxx) vorhanden sein. Diese Module bauen auf das SWAP Modul auf und bedienen im backend ebenfalls die PanStamp Module über die Register. Der PanStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das SWAP Modul greift auf das [[PanStamp]] Modul zu, was vorher per define anglegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über 'Register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können.
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele, sketchabängige Userregister (<code>0B</code>-<code>xx</code>)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files'', die in <code>.../FHEM/lib/SWAP</code> zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt''-Id gebildet wird. Damit dies funktioniert, muss das Attribut productCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
In den Systemregistern steht z.b. der productcode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren Register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).
Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

Alle low level Dinge wie Register ID oder Register Wert können mit hex Werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den Registernamen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (Teile eines Registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem PanStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die Register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
=== Define ===

'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Description-XML-File ein. Erst wenn der ProduktCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Description File ===
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene Panstamps ===
Devices mit power down mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet normaler Weise werden die Register mit den Sensorwerten an FHEM gesendet. Power down devices gehen danach schlafen (power down Modus mit extrem niedrigen Stromverbrauch) und wachen regelmässig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modes keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich varieren und anders programmiert sein!

Nachrichten an ein panStamp-Modul im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an das panStamp-Modul geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF im Systemregister 0A zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum senden kommt. Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch ein mal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf 0x5555 (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul ein panStamp Modul mit der Adresse 0xFF wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich 0xF0 bis 0xFE. Das soll das inbetriebnehmen von mehreren panStamp-Modulen gleichzeitig erleichtern. Der automatisch vergeben Adressebereich ist nur begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fälle werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

=== register 0F is not known ===

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

=== Komplette Übersicht eines Device ===

list <device>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

=== fehlender oder falsche Productcode ===

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

=== missing commands und register 00-0A unvollständig ===

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

=== Funktion des Autocreate ===

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

=== Adresse manuell setzen ===

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

=== Panstamp antwortet nicht/EEprom to factory defaults ===

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

=== Factory Defaults ===

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

=== Status LED ===

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

== Links ==

[[Kategorie:panStamp]]

PanStamp

2015-07-21T07:32:49Z

TeeVau: Kapitel Systemübersicht aus panStamp in eigenständigen Artikel übernommen, Kapitel SWAP in Artikel SWAP übernommen

SWAP

2015-07-21T07:08:05Z

TeeVau: /* Beispiel: panStamp soilmoisture Sketch in FHEM einbinden */

{{Baustelle}}
{{SEITENTITEL:SWAP}}

{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModType=d
|ModCmdRef=SWAP
|ModForumArea=
|ModFTopic=
|ModTechName=34_SWAP.pm
|ModOwner=André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

[[SWAP]] ist das Basismodul für die Unterstützung der PanStamp Baugruppen. Zur Kommunikation in einem PanStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. xxxx) vorhanden sein. Diese Module bauen auf das SWAP Modul auf und bedienen im backend ebenfalls die PanStamp Module über die Register. Der PanStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

== Voraussetzungen ==
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>
Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das SWAP Modul greift auf das [[PanStamp]] Modul zu, was vorher per define anglegt werden muss.

== Anwendung ==
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Bei SWAP geht alle Kommunikation über 'Register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jedes Device hat eine Reihe Systemregister (00-0A) und beliebig viele Userregister die vom jeweiligen Sketch abhängen. Welche Register dies sind, steht unter anderem jeweils im Device Description xml file im Verzeichnis .../FHEM/lib/SWAP. Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.

In den System Registern steht z.b. der productcode, die device adresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren Register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).

Die Inhalte der System Register stehen als INTERNAL im oberen Bereich der Detail Ansicht einer Komponente in FHEM, die user register als Readings im unteren.

Alle low level Dinge wie Register ID oder Register Wert können mit hex Werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den Registernamen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (Teile eines Registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem PanStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die Register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
=== Define ===

'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. <data> muss als HEX Zahl angegeben werden. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
** ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
** <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

=== get ===
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange auf, also Nachrichten die von FHEM gesendet wurden, aber der empfang durch das panStamp Modul nicht bestätigt wurde.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.

=== Attribute ===
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Description-XML-File ein. Erst wenn der ProduktCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen FHEM set- und get-Kommandos des [[SWAP]] Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. [[SWAP_0000002200000003]]). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.

=== Device Description File ===
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.

=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

== Anwendungsbeispiele ==
=== Übersicht der Register anzeigen ===
Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL

=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
set <device> regGet <ID>
oder auch gesetzt werden durch
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

=== Intervall bei Sketch mit power down / batterie betriebene Panstamps ===
Devices mit power down mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet normaler Weise werden die Register mit den Sensorwerten an FHEM gesendet. Power down devices gehen danach schlafen (power down Modus mit extrem niedrigen Stromverbrauch) und wachen regelmässig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modes keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich varieren und anders programmiert sein!

Nachrichten an ein panStamp-Modul im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an das panStamp-Modul geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}

Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist. {{Link2Forum|Topic=12487 |Message=89205}}

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF im Systemregister 0A zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum senden kommt. Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch ein mal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf 0x5555 (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul ein panStamp Modul mit der Adresse 0xFF wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich 0xF0 bis 0xFE. Das soll das inbetriebnehmen von mehreren panStamp-Modulen gleichzeitig erleichtern. Der automatisch vergeben Adressebereich ist nur begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>

=== Registerinhalt von hex auf Dezimal umrechnen ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fälle werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}

=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbst entwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Trouble Shooting ==
=== value has to be 10 byte(s) in size ===

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

=== register 0F is not known ===

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

=== Komplette Übersicht eines Device ===

list <device>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

=== fehlender oder falsche Productcode ===

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

=== missing commands und register 00-0A unvollständig ===

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

=== Funktion des Autocreate ===

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

=== Adresse manuell setzen ===

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

=== Undefined subroutine &main::XMLin ===
Erhält man diese Fehlermeldung
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

=== Panstamp antwortet nicht/EEprom to factory defaults ===

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

=== Factory Defaults ===

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

=== Status LED ===

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

== Links ==

[[Kategorie:panStamp]]

PanStamp RGBWW Board mit DMX und IR

2015-07-21T05:37:55Z

TeeVau: Kategorie zugefügt

{{Baustelle}}

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=RGBWW Board
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz
|HWChannels=
|HWVoltage=12V
|HWPowerConsumption=
|HWPoweredBy=Netzteil
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#SWAP_0000002200000003 35_SWAP_0000002200000003.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}
[[PanStamp RGBWW Board mit DMX und IR]] unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.
Es ist eine Hard- und Softwareentwicklung auf Basis von panStamp Modulen und verwendet zusätzlich das FHEM Modul [[SWAP 0000002200000003]] als 3. Ebene

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

== Hardware ==
Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

=== Kompatibilität RBG-Board mit NRG-panStamps ===
Mit dem hier beschriebenen Sketch ist das Board nur mit den AVRs kompatibel.
Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht Ground wie beim AVR.
Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s ein „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0.

{{Link2Forum|Topic=13890 |Message=247069}}
[http://forum.fhem.de/index.php?topic=13890.msg247069#msg247069]

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.

=== Eigenschaften des fade TBC ===
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644

== Software ==
Eine Übersicht über die derzeit vorhandene Funktionalität des [[SWAP_0000002200000003|Fhem Moduls]] und panStamp Sketches (Stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
was geht:
* bis zu vier led kanäle (je nach kombination von ir und soft pwm)
* ir senden
* ir empfangen
* messen ob die led versorgung an ist
* helligkeit eines an A2 angeschlossenen helligkeits sensors
* konfiguration der dmx basis adresse über das swap register 0x12
* optional soft on auf letzten wert
* alles was auch vorher schon ging: dimmen, faden, ir fernbedienungen anlernen, ...

wichtig zu wissen:
* wenn ir aktiv ist und kein soft pwm lässt sich der 4. kanal nur ein und aus schalten
* wenn ir aktiv ist muss soft pwm aktiv sein um den 4. kanäle auch zu dimmen
* es wird nur ein zusätzlicher kanal tatsächlich schon unterstützt. der fünfte kommt noch
* bei ir senden sind nur die aufrufe für sony und nec tatsächlich eingebaut. die anderen sind aber einfach zu ergänzen
* beim ir senden sind noch keine Wiederholungen eingebaut. die müssen laut protokoll aber eigentlich sein

was noch kommt:
* besseres soft pwm
* mehr konfiguration bezüglich default verhalten. ramp zeiten, delays, ...
* hsv farb modell um besser zu faden und vor allem um den weiss anteil automatisch auf die weiss leds zu legen
* die virtuellen channel
* fhem kompatibles ir senden
* sofortiges senden von helligkeit und led spannung bei änderung
* andere ir lib mit sehr viel besserer geräte unterstützung

wie gehabt muss alles über config.h mit Compilerschalter konfiguriert werden.

=== Arduino IDE 1.5 / 1.6 einrichten ===
Mit der Arduino IDE 1.5.x gab es zusätzlich eine grundlegende Umstellungen der Arduino SWAP Library, für die der derzeitige Sketch [r4716] angepasst werden muss. Der Sketch ist nur kompatibel zur alten SWAP Library, die unter Arduino IDE 1.0 installiert werden muss (Stand 01.05.2015).

=== Arduino IDE 1.0 einrichten ===
Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Für den RGB-Driver sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin C:\Users\<username>\Documents\Arduino\libraries. Am Ende der ganzen Aktion im Folgenden sollten sich in diesem Unterordner 3 neue Unterordner befinden: IRremote, DMXSerial und panstamp

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Libraries richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter Sketch/Library importieren die 3 weiteren Punkte unten unter "beigetragen" auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino libraries verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Für das kompilieren mit INO siehe [[panstamp#ino|hier]].

=== Link zum Sketch ===
Die aktuelle Version des RGB-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge].
{{Link2Forum|Topic=13890 |Message=201391}}
[http://forum.fhem.de/index.php?topic=13890.msg201391#msg201391]
Dieser muss in Arduino\libraries\panstamp\examples\sketches entpackt und die rbgdriver.ino gestartet werden. In der Arduino IDE sollte unter Tools->Board "Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega328" eingestellt sein. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert kann man in der IDE auch direkt panStamp als Plattform auswählen.

==== Kompillierte hex version ====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=121619}}
[http://forum.fhem.de/index.php?topic=13890.msg121619#msg121619]

==== HEX-File ohne IR und DMX ====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=201955}}
[http://forum.fhem.de/index.php?topic=13890.msg201955#msg201955]

=== Compilerschalter ===
Welche Features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der <pre>#define ENABLE_...</pre> Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}}

==== #define ENABLE_DMX ====
#define ENABLE_DMX
Ermöglicht die Nutzung eines DMX RGB Einstellers zur Steuerung der RGB LEDs

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei DMXSerial.h die Zeile
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
in
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
abgeändert werden muss.

==== #define HAS_SENSOR ====
#define HAS_SENSOR
Ermöglicht die Nutzung eines DHT22 Sensors zur Auswertung von Temperatur und Luftfeuchtigkeit
Dafür sollten diese Konfigurationszeilen auskommentiert sein:
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;

In der IRremote.cpp Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>

sowie die Irremote.h Datei unter Public: um die Zeile
void disableIRIn();
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an A2 des panStamps angeschlossen werden.
Ein Beispiel für die Umrechnung der userReading für Spannung Temp etc. ist hier beschrieben.
{{Link2Forum|Topic=12487 |Message=76489}}

=== Zusammenhänge der Konfiguration ===
Die Zusammenhänge der Konfiguration sind hier beschrieben
{{Link2Forum|Topic=13890 |Message=175181}}

=== 4. und 5. LED Kanal TBC ===
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936

=== Alternativer Fade per Patch ===
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.

== IR Schnittstelle TBC ==
=== IR TBC ===
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267

=== IR-Belegung Panstamp RGB-Board TBC ===
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153

=== Ircluster TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331

=== Irgate TBC ===
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278

== DMX Schnittstelle ==
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge

[[Kategorie:panStamp]]

PanStamp

2015-07-19T11:09:22Z

TeeVau: /* Systemübersicht */ Inhalt aus panStamp Diskussion

{{Baustelle}}
{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}

''' Auf der Diskussionsseite dieses Artikels habe ich eine Neufassung dieses Artikels eingestellt mit der Bitte um Korrektur direkt hier oder konstruktive Kritik [http://forum.fhem.de/index.php/topic,12487.msg290966.html#msg290966]'''

[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Dieser Artikel beschreibt zu einem das FHEM Modul panStamp, was das Funkinterface zu FHEM bildet und die dazugehörige Hardware panStamps der spanischen Firma panStamp S.L.U.
Der Focus liegt natürlich auf die Integration mit FHEM. Zu der Hardware panStamp gibt es Herstellerseitig eine eigenen community mit Forum und Wiki, sowie SourceCodes auf Github.

== Systemübersicht ==
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.
[[Datei:Panstamp-Systemoverview.jpg|200px|thumb|panStamp Systemübersicht]]

Die Kommunikationskette ist wie folgt:
FHEM -> Host-hardware/OS -> USB -> [[panStick]] -> panStamp (Modem-Sketch) -> Funkstrecke ([[SWAP]]) -> panStamp (angepasster Sketch) -> Board -> Sensoren/LED-Strip/etc.
(Ein Panshield ersetzt "USB -> Panstick" durch "IO's am Rpi-> Panshield")
Zum Betrieb werden mindestens 2 panStamp Hardware-Module benötigt, [[panStamp]] FHEM-Modul als IO-Device für FHEM und FHEM-Modul [[SWAP]] zur Integration des Funkprotokoll der panStamps. Optional kann es noch weitere Module geben als 3. Ebene, die nach dem Schema SWAP_XXXXXXXXXXXXXXXX benannt sind. Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die [[SWAP]] Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Es gibt bereits selbstentwickelte Hardware und Software auf Basis der panStamp Hardware und dem SWAP Protokoll:
* [[PanStamp Umweltsensor]]
* [[Bodenfeuchtesensor]]
* [[Panstamp Innenraumsensor]]
* [[PanStamp RGBWW Board mit DMX und IR]]

=== panStamp Hardware ===
==== panStick ====
Zu unterscheiden ist die Definition des [[panStick]]. Mit [[panStick]] ist zu einem das Hardware-Modul, von der Firma panStamp, gemeint. Zum Anderen bezeichnet es aber auch die Kombination von [[panStick]]-und [[panStamp]]-Hardware, wobei letzteres mit einem Modem-Sketch (siehe [[panStick]] ausgestattet ist. Hier wird in der Regel immer von der letzteren Kombination gesprochen, also panStick als Hardware mit USB-Anschluss und panStamp mit Modem Sketch, was gesamt dann als Funk-Interface dient.
Die Bennen ist also panStick, der TYPE in FHEM ist jedoch panstamp (Aufgrund des Modulnamen).

==== panStamp ====
Auf der anderen Seite gibt es die Definition der panStamps, die lokal auf den entsprechenden Boards stecken. Diese sind vom TYPE SWAP_<ProductCode>. Um die Verwirrung komplett zu machen, wird hier meistens vom "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind. Für diese werden hier nur die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Komandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des ProductCode zur Verfügung stehen, werden bei den spezifischen Anwendungen beschrieben.

==== spezifisches "Board" ====
: Im Gegenzug zum Panstick als Interface zwischen panStamp und USB-Port des Servers stellt das Board das Interface zwischen panStamp vor Ort und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs des panStamps auf die Ausgänge um bzw. leitet die Eingänge zur Auswertung an den panStamp weiter.
: Entsprechend Anwendungsfall und Sketch werden die Ein-/Ausgänge des panStamps verarbeitet. Z.B. können an ein Board Temperatur-, Feuchtigkeitssensoren oder LED-Strips angeschlossen werden. Der Sketch auf dem panStamp sollte entsprechend der Anwendung auf dem Board angepasst worden sein um nicht nur über die standardmäßig zur Verfügung stehenden Register kommunizieren zu müssen.

: Das Board benötigt irgend eine Art von Stromversorgung, um den panStamp zu betreiben. Das kann im Falle eines Sensorboards und entsprechend stromsparend ausgelegtem Sketch eine Batterie sein oder wie im Falle des RGB-Boards eine externe Stromversorgung.
: Speziell beim unten beschriebenen RGB-Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder ingesamt panStamp und LEDs gemeinsam versorgen.

=== panStamp Software ===
==== Simple Wireless Abstract Protocol (SWAP) ====
Das Funkprotokoll [[SWAP]] wird von den panStamp-Modulen zur Datenübertragung verwendet. Es gibt ein gleichnamiges FHEM-Module [[SWAP]], was dieses Protokoll in FHEM integriert.

==== Modem-Sketch ====
Siehe [[panStick]]

==== auf Board abgestimmter Sketch ====
Ein panStamp ist auf einem entsprechenden Board installiert und übernimmt dort lokal die Schnittstelle zwischen Funkstrecke und Board.

Der Sketch stellt dabei die passende "Software" auf dem panStamp. Der Sketch verarbeitet die über das SWAP-Protokoll versandte Nachrichten, wertet diese aus, reagiert entsprechend und setzt die Outputs des Boards. In umgekehrter Richtung wertet er die an den Inputs des Board angelegten Signale aus, verarbeitet diese und schickt sie per SWAP-Protokoll zum Panstamp mit Modem-Sketch zurück.

=== FHEM Module ===
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden genauer beschrieben werden. Zusammengefasst gibt es 3 Ebenen mit der Ergänzung eines Konfigurationsfiles in xml-format.
{{Link2Forum|Topic= 13890 |Message=121689 }}

===== Ebene 1: 34_panStamp.pm =====
Das Modul ist für einen panStamp der auf einem panStick sitzt und das Interface zwischen FHEM und dem panStamp netz bildet. Alle eintreffenden SWAP-Pakete auf dem panStick (mit Modem-Sketch) werden direkt durchgereicht und im nachfolgend beschriebenen SWAP-Modul verarbeitet.

===== Ebene 2: 34_SWAP.pm =====
Das Modul implementiert das [[SWAP]] Protokoll das zwischen den panStamps gesprochen wird. Das FHEM-Modul [[SWAP]] ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM, und ist in einem eigenen Artikel [[SWAP]] erklärt.

===== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm =====
Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Mit dieser dritten Modulebene ist es auch für Aktore wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.

Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.

Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Ein Beispiel für das RGB-Board dafür ist das Modul 35_SWAP_0000002200000003.pm.
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]

===== Device Description File =====
Ein XML File was die Ein- und Ausgänge der panStamps beschreibt. Durch diese Datei wird dem FHEM-Modul mitgeteilt wie die Readings zu bennen sind, welche Werte die Readings haben können und ob die Readings/Register nur ausgelesen werden dürfen, oder auch beschrieben werden können.

== Das FHEM Modul panStamp ==
=== Allgemein ===
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden und anderen Artikel genauer beschrieben sind. Das Modul panStamp erstellt dabei das IO-Device in FHEM.

=== Voraussetzungen ===
Als Schnittstelle zwischen FHEM und einem panStamp Netzwerk dient entweder ein panStick (USB Stick mit aufgestecktem panStamp) oder ein panStamp Shield mit integriertem panStamp an einem Raspberry Pi. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und über das FHEM Modul panStamp angesprochen. Die USB Anbindung kann ggf. auch von einer remote Hardware aus per TCP/IP (ser2net oder FHEM2FHEM mit RAW) an FHEM angebunden werden.

=== Anwendung ===
==== Define ====
Das Device "panStick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:
<pre>define panStick panStamp /dev/ttyUSBx@38400</pre>
Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv sind. Die weitere Funktion übernimmt das Modul [[SWAP]], was das Funkprotokoll der panStamp Module in FHEM implementiert.

'''Betrieb an der Fritzbox'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernaschluss deaktiviert sein.

==== Attribute ====
Für den "panStick" gibt es keine modulspezifischen Attribute.

==== set-Befehle ====

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
In diesem Beispiel wird ein broadcast an alle abgesetzt, damit diese ihre ID und ihren productcode zurück senden.
Das macht der panStick nach dem Initialisieren auch ein mal automatisch um alle nicht schlafenden Devices per autocreate anlegen zu können.

Mit diesem Befehl "raw" lassen sich SWAP-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

=== Anwendungsbeispiele ===

=== Links ===

== Die Hardware panStamp ==
=== Allgemein ===
[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem stück Draht in der [https://code.google.com/p/panstamp/wiki/antennalengths richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht. Auch nicht auf kurze Distanzen.

=== Simple Wireless Abstract Protocol (SWAP) ===
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.

Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files'', die in .../FHEM/lib/SWAP zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt''-Id gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

=== Neue panStamps in Betrieb nehmen ===
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme ist autocreate zu aktivieren!'''

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, da sie zuerst mit einer eindeutigen Device-Adresse (ungleich FF und grösser 01) versehen werden müssen. Bei batteriebetriebenen Sensoren sollte auch das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
Für Devices im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald das Device seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos Reset zu drücken oder die Stromquelle erneut zu verbinden.

Das SWAP modul versucht, ein Device mit der default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall von <code>FFFF</code> zu <code>0384</code> (900 Sekunden) geändert.
Es gibt mit bestimmten panStamp lib Versionen das Problem das ein wert von FFFF in 0A zum Überlauf führt und dann ununterbrochen gesendet wird. Im fhem Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum senden kommt.
Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden und noch mal flashen. Wenn der Sketch damit ein mal durchgelaufen ist können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht.

Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.

=== Beispiele ===
==== Bodenfeuchte ====
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbstentwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]

Diskussion:PanStamp

2015-07-19T11:08:41Z

TeeVau: Inhalt auf neue Artikel ausgegliedert.

{{Baustelle}}
'''Anmerkung für die hier vorgeschlagene Änderung des Hauptartikels'''
Während ich mich mit dem Thema vertraut gemacht habe, habe ich versucht, alle Informationen, die aus non-developer Sicht für die spätere Anwendung und Inbetriebnahme relevanten Informationen (also aus meiner ;) ) wichtig erscheinen, hier in einem Artikel zusammenfassen. Ich muss gestehen, bis ich meine ersten Panstamps am Laufen hatte, musste ich viel lesen und der derzeitige Artikel setzt mM recht viel Wissen voraus (alles eine Frage des Wissensstandes).
Die Inhalte des derzeitigen Artikels habe ich übernommen und einfließen lassen, d.h. es ist geplant, die derzeitige Seite zu ersetzen!

In diesem Artikel sind alle Posts bis heute (14.04.2015) aus den beiden Threads {{Link2Forum|Topic=12487 |Message=74967 |LinkText=Thema: panStamp support }} und {{Link2Forum|Topic=13890 |Message=86952 |LinkText=Thema: PanStamp Board RGB,CW,WW;DMX;IR }} berücksichtigt.

Da viele Informationen vor allen Dingen aus der Zeit der Entwicklung der Module und der Sketches stammen, bitte ich Euch, hier kritisch quer zu lesen, das geschriebene zu prüfen, ob noch aktuell und ggf. zu korrigieren, zu ergänzen oder im Forum konstruktiv zu kommentieren.

Dinge, die mir unklar waren, da noch nicht getestet oder Dinge, die noch näherer beschrieben werden können, habe ich mit "?" bzw. "TBC" gekennzeichnet.
----
: Hallo, wie ist denn der Stand mit dem Artikel? Finde es schade, dass das gesammelte Know-how hier nur auf der Diskussionsseite zu finden ist. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 12:07, 15. Jul. 2015 (CEST)

{{SEITENTITEL:panStamp}}

{{Infobox Hardware
|Bild=panStamp.jpg
|Bildbeschreibung=panStamp
|HWProtocol=SWAP
|HWType=Sender, Empfänger, Sensor, [[Interface]]
|HWCategory=
|HWComm=868MHz (433/915MHz)
|HWChannels=
|HWVoltage=3.3V (panStick: 5V USB)
|HWPowerConsumption=
|HWPoweredBy=Battery (panStick: USB)
|HWSize=17.7 x 30.5 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#panStamp 34_panStamp.pm] [http://fhem.de/commandref.html#SWAP 34_SWAP.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|HWManufacturer=panStamp
}}

{{Todo|Fehlerkontrolle, Formatierung, Ergänzung, Bestätigung des Geschriebenen, weitere Informationen zur Erstellung/Anpassung eines Device Description Files, Bestätigung des Hochladens mittels XLoader, Bedienung in FHEMWEB(RGB-Board/Sketch)}}

== Allgemeines ==

=== Hardware ===
==== panStamp mit Antenne ====
[http://www.panstamp.com/home panStamps] sind [[Arduino]] Clones, die ein CC1101 Funkmodul beinhalten. Mit ihnen lassen sich Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau wie Arduinos über die Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem stück Draht in der [https://code.google.com/p/panstamp/wiki/antennalengths richtigen Länge] bestückt sein. Ohne Antenne funktioniert die Übertragung nicht. Auch nicht auf kurze Distanzen.

Mittlerweile gibt es zwei verschiedene panStamps (AVR und NRG), von denen der NRG neuer und etwas mehr Features zur Verfügung stellt, allerdings (noch) nicht mit allen hier beschriebenen Projekten kompatibel ist.

==== Panstick oder Panshield ====
<strike>
Als Schnittstelle zwischen Server-Hardware und einem panStamp dient entweder ein panStick (USB Stick mit Sockel zum aufstecken eines panStamp) oder ein "panStamp Shield" mit integriertem panStamp an einem Raspberry Pi. Der Panstick stellt dabei die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface des Panstamps auf der anderen Seite dar. Ein Panshield übernimmt die gleiche Funktion, wird aber direkt an die IOs eines Raspberries angeschlossen.

Der Panstick wird grundsätzlich für zwei Aufgaben benötigt:
# Für die Vorbereitung eines panStamps für den Betrieb auf einem "Board" wird der neue panStamp in den Panstick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
# Im "normalen" Betrieb steckt ein panStamp auf ihm. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und dient so dem Rechner als Interface zu anderen panStamps, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird.

Da auf dem panStamp Shield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die zweite Funktion.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:10, 17. Jul. 2015 (CEST)

==== spezifisches "Board" ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
: Im Gegenzug zum Panstick als Interface zwischen panStamp und USB-Port des Servers stellt das Board das Interface zwischen panStamp vor Ort und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs des panStamps auf die Ausgänge um bzw. leitet die Eingänge zur Auswertung an den panStamp weiter.
: Entsprechend Anwendungsfall und Sketch werden die Ein-/Ausgänge des panStamps verarbeitet. Z.B. können an ein Board Temperatur-, Feuchtigkeitssensoren oder LED-Strips angeschlossen werden. Der Sketch auf dem panStamp sollte entsprechend der Anwendung auf dem Board angepasst worden sein um nicht nur über die standardmäßig zur Verfügung stehenden Register kommunizieren zu müssen.

: Das Board benötigt irgend eine Art von Stromversorgung, um den panStamp zu betreiben. Das kann im Falle eines Sensorboards und entsprechend stromsparend ausgelegtem Sketch eine Batterie sein oder wie im Falle des RGB-Boards eine externe Stromversorgung.
: Speziell beim unten beschriebenen RGB-Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder ingesamt panStamp und LEDs gemeinsam versorgen.

</strike> Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)
=== Software ===

==== Simple Wireless Abstract Protocol (SWAP) ====
<strike>
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([http://code.google.com/p/panstamp/wiki/SWAP SWAP]).
Die komplette SWAP- Kommunikation ist registerbasiert und erfolgt mit Nachrichten um diese Register abzufragen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.
Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

==== Modem-Sketch ====
{{Randnotiz|RNText=In Artikel [[panStick]]}}
<strike>
Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und Funksignal dar, dass an andere panStamps geht.

Auf jedem panStamp (AVR, NRG?) ist im Auslieferungszustand der Modem-Sketch installiert. Das Protokoll der Funkstrecke folgt dem SWAP-Protokoll.

</strike> Inhalt in Artikel [[panStick]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== auf Board abgestimmter Sketch ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Ein panStamp ist auf einem entsprechenden Board installiert und übernimmt dort lokal die Schnittstelle zwischen Funkstrecke und Board.

Der Sketch stellt dabei die passende "Software" auf dem panStamp. Der Sketch verarbeitet die über das SWAP-Protokoll versandte Nachrichten, wertet diese aus, reagiert entsprechend und setzt die Outputs des Boards. In umgekehrter Richtung wertet er die an den Inputs des Board angelegten Signale aus, verarbeitet diese und schickt sie per SWAP-Protokoll zum Panstamp mit Modem-Sketch zurück.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Module und Description File ====
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
<strike>
Die Integration in FHEM erfolgt über eine Reihe von Modulen die im folgenden genauer beschrieben werden. Zusammengefasst gibt es 3 Ebenen mit der Ergänzung eines Konfigurationsfiles in xml-format.
{{Link2Forum|Topic= 13890 |Message=121689 }}
[http://forum.fhem.de/index.php/topic,13890.msg121689.html#msg121689]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 1: 34_panStamp.pm =====
<strike>
Das Modul ist für einen panStamp der auf einem panStick sitzt und das Interface zwischen FHEM und dem panStamp netz bildet. Alle eintreffenden SWAP-Pakete auf dem panStick (mit Modem-Sketch) werden direkt durchgereicht und im nachfolgend beschriebenen SWAP-Modul verarbeitet.
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Ebene 2: 34_SWAP.pm =====
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
<strike>
Das Modul implementiert das SWAP protokoll das zwischen den panStamps gesprochen wird. Das SWAP Modul ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM.

Bei SWAP geht alle Komunikation über 'register', dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jedes device hat eine Reihe System register (00-0A) und beliebig viele user register die vom jeweiligen Sketch abängen. Welche Register dies sind, steht unter anderem jeweils im Device Description xml file im Verzeichnis .../FHEM/lib/SWAP.

In den System Registern steht z.b. der productcode, die device adresse und das Übertragungsintervall. Konfigurierbare register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit "FF" initialisiert und alle konfigurierbaren register haben diesen Wert. also z.b. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden).

Die Inhalte der System Register stehen als internal values im oberen Bereich der Detail Ansicht einer Komponente in FHEM, die user register als readings im unteren.

Alle low level Dinge wie Register id oder Register Wert können mit hex werten direkt angepasst werden. Im Normalbetrieb ist dieses aber nicht notwendig und es kann über 'vereinfachte' Kommandos mit den register namen verwenden kann. Diese Funktionalität stellt das eines der Module zur Verfügung.
<pre>
set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>
</pre>

{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]

Dieses Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung
* Es wird eine command Liste für Devices im power down Modus gehalten. Sobald das Device online kommt werden die Kommandos automatisch übertragen.
* Die userReadings für 'menschenlesbare' Readings werden anhand des device description files automatisch erzeugt
* Es ist jetzt möglich direkt endpoints (teile eines registers) zu schreiben (???)
* (Fast) keine hardkodierte Sonderbehandlung mehr für das RGB-Board. Das SWAP Modul kann mit jedem beliebige Swap Device umgehen.
* Es gibt eine dritte (optionale) Modulschicht neben dem panStamp modul für die Hardware und dem SWAP Modul für das Protokoll. Mit dem generellen SWAP Modul lasen sich alle SWAP devices 'zu fuss' über die register ansprechen. Um die register auf einer höheren Ebene auf FHEM Kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig.

{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
</strike>

In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

===== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm =====
{{Randnotiz|RNText=In Artikel [[paNStamp]]}}
<strike>
Besonders bei Aktoren ist oft eine engere FHEM-Integration sinnvoll, um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die Registerebene und regSet und regGet Kommandos beschränkt zu sein.
Mit dieser dritten Modulebene ist es auch für Aktore wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.

Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.

Um per autocreate automatisch das passende Modul laden zu können, müssen diese Module nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm benannt sein wobei XXXXXXXXXXXXXXXX für den jeweiligen productCode steht.

Ein Beispiel für das RGB-Board dafür ist das Modul 35_SWAP_0000002200000003.pm.
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
</strike>

Inhalt in Artikel [[panStamp]] übernommen.--[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

===== Device Description File =====
<strike>
Mit Hilfe der im jeweiligen Device Description File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt die neben den reinen Registerwerten in hex auch 'menschenlesbare' readings der Sensorwerte erzeugen.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

<code>attr temppress userReadings voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, temperature:0C.0-Temperature {hex(ReadingsVal($name,"0C.0-Temperature","0"))*0.1-50}, pressure:0C.1-Pressure {hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01}, pressureNN:0C.1-Pressure {sprintf("%.2f",hex(ReadingsVal($name,"0C.1-Pressure","0"))*0.01 + AttrVal("global", "altitude", 0)/8.5)}</code>

[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>

Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.
</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:59, 16. Jul. 2015 (CEST)

=== Systemübersicht ===
<strike>
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.
[[Datei:Panstamp-Systemoverview.jpg|200px|thumb|panStamp Systemübersicht]]

{{Link2Forum|Topic=12487 |Message=75980 }}
[http://forum.fhem.de/index.php?topic=12487.msg75980#msg75980]

Die Kommunikationskette ist wie folgt:
FHEM -> Host-hardware/OS -> USB -> Panstick -> panStamp (Modem-Sketch) -> Funkstrecke (SWAP) -> panStamp (angepasster Sketch) -> Board -> Sensoren/LED-Strip/etc.

(Ein Panshield ersetzt "USB -> Panstick" durch "IO's am Rpi-> Panshield")
</strike>

Inhalt übernommen in Artikel [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 19:50, 17. Jul. 2015 (CEST)

== Schritte der Inbetriebnahme ==
{{Randnotiz|RNText=In Artikel [[panStamp]]}}
Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board:

* Ein panStamp wird in einen Panstick gesteckt und der Panstick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.
* Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).
* Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf den panStamp hochgeladen.
* Der programmierte panStamp aus dem Panstick in das RGB-Board stecken.
* Einen panStamp mit Modem-Sketch in den Panstick stecken und an den FHEM-Host stecken.
* panStamp unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
* RGB-Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, der panStamp automatisch eingerichtet werden.
* SWAP-Device in FHEM an Gegebenheiten anpassen.

== Programmierung eines panStamps ==
<strike>
=== unter Windows ===

==== Installation Panstick ====
Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.
# Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.
# Treiber von der offiziellen Homepage herunterladen und installieren [[http://www.ftdichip.com/]]. Die Treiber befinden sich ebenfalls im Unterordner drivers der Arduino IDE.

Bei der Installation kann es sein, dass kein Treiber gefunden wird. Dann muss der entsprechende Treiber manuell ausgewählt werden entsprechend dieser Anleitung [[https://www.youtube.com/watch?v=SPdSKT6KdF8]].

==== Arduino IDE vorbereiten ====

Zum Flashen der panStamps wird die Arduino IDE benötigt. Eine Installationsanleitung ist unter folgendem Link zu finden:
:https://code.google.com/p/panstamp/wiki/firststeps

Die IDE 1.5.x oder höher ist zwar mit den AVRs und NRGs kompatibel, wichtig zu wissen ist allerdings, dass mit dem Wechsel von 1.0.x zu 1.5.x oder höher es größere Änderungen der APIs gegeben hat. Dadurch lassen sich einige der bislang zur Verfügung stehenden Sketches (derzeit) nicht unter 1.5.x oder höher kompilieren (z.B. der RGB-Sketch). Für die IDE 1.0.x gibt es keine passenden Arduino Lib für den NRG [[https://github.com/panStamp/panstamp/wiki/First%20steps]], die daher nur mit den AVRs kompatibel sind. Im Folgenden wird sich für die Programmierung unter Windows daher auf die letzte 1.0.x IDE bezogen.

* Man läd die '''Arduino IDE 1.0.x''' für Windows [[http://arduino.cc/en/Main/OldSoftwareReleases]].

* Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe [[panstamp#Sketch konfigurieren|explizite Anwendung]]).

* Unter Tools/Board wird das '''passende Board''' ausgewählt, dass dem Chip auf dem Panstamp entspricht. Für den AVR: Arduino Pro or Pro Mini (3,3V, 8 MHz) /w ATmega328. Wenn man das boards.txt file von [http://code.google.com/p/panstamp/downloads/detail?name=boards.txt&can=2&q= hier] installiert, kann man in der IDE auch direkt panStamp als Plattform auswählen.

* Nun muss unter Tools/Serieller Port noch der richtigen '''Com-Port''' auswählen werden, unter dem der Panstick eingebunden worden ist (entsprechend Gerätemanager).

* Als letztes unter Tools/'''Programmer''' noch den AVRISP mkII auswählen.

==== Sketch vorbereiten, kompilieren und hochladen ====

* Den Sketch läd man von der entsprechenden Quelle und entpackt die Dateien in einen Unterordner z.B. parallel zum libraries-Ordner (unter "Eigene Dateien"). Der Ordner darf '''nicht im''' libraries-Ordner liegen, da die Arduino IDE dort das Speichern nicht zulässt. Innerhalb des Unterordners erwartet die IDE die Dateien in einen Unterordner namens "sketch".
* sketch.ino oder ähnlich in der Arduino IDE öffnen.
* Nun entsprechend den Bedürfnissen auf dem geöffneten Reiter in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

Bezüglich der Anpassung des Sketches sind einige spezifische Informationen unten bei den expliziten Anwendungen ergänzt.

==== Hexfile hochladen mit XLoader ====
Um ein fertig kompiliertes HEX-File hochzuladen, soll dieses über ein Programm namens XLoader möglich sein. [[http://xloader.russemotto.com]]

=== unter Linux ===

==== Installation Panstick ====

Zum einen kann es sein, dass der Panstick automatisch unter /dev/ttyUSBx einbunden wird. "x" steht für eine freie fortlaufende Nummer.

Falls er nicht automatisch angelegt worden ist, kann man zunächst prüfen, ob dieser überhaupt eingebunden und richtig erkannt wurde.
<pre>
lsusb
</pre>
Sollte etwas ähnliches zurückmelden:
<pre>
Bus 003 Device 002: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub
</pre>

Falls das Device nicht automatisch angelegt worden ist, muss dieses ggf. von Hand erledigen.

{{Link2Forum|Topic=12487 |Message=87746 }}
[http://forum.fhem.de/index.php/topic,12487.msg87746.html#msg87746]

Mit dem folgenden Befehl sollte in der Liste ein ttyUSB auftauchen. Normalerweise mit der Nummer 188.
<pre>cat /proc/devices</pre>

Das Device wird dann angelegt mit:
<pre>sudo mknod /dev/ttyUSB0 c 188 0</pre>

Zusätzlich muss für den Betrieb des Pansticks das ftdi_sio Modul zur Verfügung stehen. Dieses lässt sich prüfen mit
<pre>lsmod</pre>

Diese Voraussetzung könnte den Betrieb an einer Fritzbox erschweren, da nicht sicher ist, ob dieses Modul standardmäßig immer installiert ist.

Legt man das Device von Hand an, kann es sein, dass die Berechtigungen nicht richtig gesetzt sind.
<pre>
2015.04.23 22:20:06 3: Opening panStick device /dev/ttyUSB0
2015.04.23 22:20:06 3: Can't open /dev/ttyUSB0: Permission denied
</pre>

Das Device sollte für die Gruppe dialout Lese-/Schreibberechtigungen haben.
Ist dieses nicht der Fall, lassen sich diese über diesen Befehlt setzen.
<pre>
sudo chown root:dialout ttyUSBx
</pre>
Damit wird der "Besitz" festgelegt.
<pre>
sudo chmod a+rw /dev/ttyUSBx
</pre>
Hiermit werden die Berechtigungen gesetzt.

Der Benutzer "fhem" sollte selbstverständlich der Gruppe "dialout" angehören.
Ist dieses nicht der Fall:
<pre>
sudo adduser fhem dialout
</pre>

Falls dem nicht so sein sollte, hilft ggf. einer dieser beiden Links weiter:
[[https://www.youtube.com/watch?v=UOECwHhCWRg]] [[http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/15/bbb--usb-io-with-ftdi-ft2232h]] bzw. die Installation des Moduls.

==== IDE unter MacOS ====

Da für den RGB-Sketch die IDE 1.0.x benötigt wird und diese Java SE 6 eine Voraussetzung ist, stellt die IDE und MacOS keine Optimale Konfigurationsumgebung dar. Wer es trotzdem probieren möchte
{{Link2Forum|Topic=12487 |Message=82055 }}
[http://forum.fhem.de/index.php/topic,12487.msg82055.html#msg82055]

==== INO ====
Der RGB-Sketches wurde mit Hilfe des Tools INO entwickelt.
{{Link2Forum|Topic=12487 |Message=82139 }}
[http://forum.fhem.de/index.php/topic,12487.msg82139.html#msg82139]

Die Installation erfolgt am leichtesten mit Hilfe des Tools pip.

Voraussetzungen für das Tool sind darüber hinaus picocom für die Kommunikation mit der seriellen Schnittstelle und die arduino. Im gleichen Zuge lässt sich pip installieren.
Die benötigten Pakete werden über folgenden Aufruf installiert
<pre>
sudo apt-get install picocom python-pip arduino
</pre>

Die Installation erfolgt im Anschluss über
<pre>
sudo pip install ino
</pre>

Die für einen Sketch erforderlichen libs werden in den entsprechenden lib Ordner kopiert (dort in entsprechenden Unterordnern).

Die Pfade im Zip sind an dieses Tool angepasst.
{{Link2Forum|Topic=12487 |Message=94830 }}
[http://forum.fhem.de/index.php/topic,12487.msg94830.html#msg94830]

Der serielle Port in der ino.ini muss selbstverständlich an die passende dev-Schnittstelle angepasst werden.

Als letztes sind die Parameter für das Board noch in die board.txt unter /usr/share/arduino/hardware/arduino einzutragen. Die Parameter lassen sich von hier extrahieren [http://old.panstamp.com/downloads] bzw. lauten für den AVR
<pre>
##############################################################

panstamp.name=PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328

panstamp.upload.protocol=arduino
panstamp.upload.maximum_size=30720
panstamp.upload.speed=57600

panstamp.bootloader.low_fuses=0xE2
panstamp.bootloader.high_fuses=0xD8
panstamp.bootloader.extended_fuses=0x07
panstamp.bootloader.path=atmega
panstamp.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
panstamp.bootloader.unlock_bits=0x3F
panstamp.bootloader.lock_bits=0x0F

panstamp.build.mcu=atmega328p
panstamp.build.f_cpu=8000000L
panstamp.build.core=arduino
panstamp.build.variant=standard

##############################################################
</pre>

Wichtig zu wissen: Jedes Mal, wenn die Arduino ein Update erhält, wird vermutlich diese Datei überschrieben, so dass die Eintragung wiederholt werden muss.

Hier sind die grundlegendsten Befehle beschrieben [http://inotool.org/quickstart].

Wechselt man nun in das Verzeichnis z.B. des RGBdriver, lässt die der Sketch kompilieren über
<pre>
ino build
</pre>

Und hochladen über
<pre>
sudo ino upload
</pre>

; Troubeshooting
{{Link2Forum|Topic=12487 |Message=134786 }}
[http://forum.fhem.de/index.php/topic,12487.msg134786.html#msg134786]

=== over-the-air (derzeit) nur NRG ===

Die neueren panStamp NRGs können seit einiger Zeit auch over-the-air geflasht werden, wie hier im zugehörigen Forumthread beschrieben [[http://forum.fhem.de/index.php/topic,30589.0.html]].

=== Was überlebt das Flaschen ===
Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [http://forum.fhem.de/index.php/topic,12487.msg87560.html#msg87560].

=== EEPROM löschen ===

Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [http://forum.fhem.de/index.php/topic,13890.msg156868.html#msg156868].
<pre>
eepromToFactoryDefaults()
</pre>
</strike>

In Artikel [[Programmierung eines panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 11:36, 17. Jul. 2015 (CEST)

== Integration in FHEM ==
=== FHEM Voraussetzungen ===
<strike>
Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [http://forum.fhem.de/index.php?topic=12487.msg87373#msg87373].
<pre>
sudo apt-get install libxml-simple-perl
</pre>

Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
</strike> Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== Pfade innerhalb der FHEM Installation ====

Die Module befinden sich wie gewohnt im Installationsverzeichnis unter ./FHEM.
<strike>
Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [http://forum.fhem.de/index.php/topic,12487.msg86257.html#msg86257].

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Register ===
<strike>
Jeder panStamp stellt elf Systemregister (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele sketchabängige Userregister (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Description Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Description File erfolgt über den productCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.

In den Systemregistern steht z. B. der productCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert, also z. B. die Adresse FF und das Intervall FFFF (zwischen 18 und 19 Stunden).

Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.

Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen productCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.

</strike> In [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Verwendung innerhalb FHEM ===
{{Randnotiz|RNText=In Artikel [[panStamp]] [[panStick]]}}
<strike>
Zu unterscheiden ist die Definition des "Panstick", wobei der panStamp, der als RF-Modem auf dem Panstick sitzt, gemeint ist. Dieser wird im Folgenden mit "Panstick" als Name des Device benannt . Der Type ist "panstamp".

Auf der anderen Seite gibt es die Definition der panStamps, die lokal auf den entsprechenden Boards stecken. Diese sind vom Type SWAP_<ProductCode>. Um die Verwirrung komplett zu machen, wird hier meistens vom "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind. Für diese werden hier nur die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Komandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des Productcode zur Verfügung stehen, werden bei den spezifischen Anwendungen beschrieben.

</strike> In [[panStamp]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 13:08, 19. Jul. 2015 (CEST)

==== Panstick ====
<strike>
===== Definition =====
Das Device "Panstick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv sind.

'''Betrieb an der FB'''
Spezialitäten zum Betrieb an einer Fritzbox sind hier [http://forum.fhem.de/index.php/topic,12487.msg87778.html#msg87778] und hier [http://forum.fhem.de/index.php/topic,12487.msg95914.html#msg95914] beschrieben. Es scheint nur der hintere USB-Anschluss für die Verwendung zu laufen. Außerdem muss der USB-Fernaschluss deaktiviert sein.

===== Attribute =====

Für den "Panstick" gibt es keine modulspezifischen Attribute.

===== Set =====

* discover?
Mit diesem Befehl wird eine Broadcast SWAP-Message abgesetzt, die alle empfangenden panStamps dazu veranlassen, sich zu melden. Batteriebetriebenen panStamps können systembedingt nur identifiziert werden, wenn diese Empfangsbereit sind und sich nicht im Schlafmodus befinden.

* raw
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
In diesem Beispiel wird ein broadcast an alle abgesetzt, damit diese ihre ID und ihren productcode zurück senden.
Das macht der panStick nach dem Initialisieren auch ein mal automatisch um alle nicht schlafenden Devices per autocreate anlegen zu können.

Mit diesem Befehl "raw" lassen sich SWAP-Messages direkt absetzten, was vor allen Dingen dann hilfreich sein kann, wenn man vermutet, dass die Kommunikation über die modulgestützten Befehle fehlschlägt.

</strike> Inhalt in Artikel [[panStamp]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 20:05, 17. Jul. 2015 (CEST)

==== SWAP ====

Alle empfangen SWAP Nachrichten werden in internals/readings im jeweiligen Device angezeigt.

===== Definition =====
<strike>
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''

Wenn der panStick läuft, sollten die SWAP-Devices per autocreate angelegt werden, sobald sie das erste mal senden, z.B. nach dem Einschalten oder nach einem Reset.

Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.

Panstick rein -> broadcast -> discovery -> anlegen.

Bei Devices mit power down mode erfolgt dieses das erste mal wenn sie Strom haben.

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem productcode. Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Das SWAP Modul versucht, ein Device mit der Default Adresse <code>FF</code> automatisch auf die erste freie Adresse im Bereich <code>F0</code>-<code>FE</code> zu ändern.

Neue panStamps sollten nur Einer nach dem Anderen in Betrieb genommen werden, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.

Wer mehrere devices hat, sollte jedem nach dem Anlegen mit
<pre>
set <device> regSet 09 <device adresse als 2 stellige hex zahl>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:
* 00 ist die Broadcast-ID
* 01 ist die ID des Pansticks am FHEM-System
* FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
* F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

{{Link2Forum|Topic= 12487 |Message=87261 }}
[http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]

Ändert man die Adresse, dauert es einen Augenblick, bis alle Register neu übertragen worden sind.

Autocreate ändert bei der Einrichtung und Änderung der ID auch automatisch den Namen. Belässt man die ID im Bereich F0-FE und ändert den Namen des Device, ist zu berücksichtigen, dass autocreate für neue Devices eine freie neue Adresse anhand der Device-Namen sucht. Dadurch könnte es zu Doppeltverwendung von IDs kommen.

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit
<pre>
define <device> SWAP <ID>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== set =====
''ZUGEFÜGT ZU SWAP ARTIKEL, STRIKE FUNKTIONIERT ABER IN DIESEM ABSATZ NICHT''
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]

* regSet <reg> <data>
Schreibt <data> in den Register mit der id <reg>. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

* regSet <reg>.<ep> <data>
write <data> to endpoint <ep> of register <reg>. will not work if no reading for register <reg> is available as all nibbles that are not part of endpoint <ep> will be filled from this reading. ?

* statusRequest
Veranlasst, dass alle Register und deren Werte einmal übertragen werden.

* readDeviceXML
Liest das Device-Description-XML-File neu ein.

* clearUnconfirmed
Löscht die liste der unbestätigten Nachrichten.

* flash [<productCode>|<firmwareFile>]
Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von NRG panStamps unterstützt wird.
* ohne Parameter: Verwendet das SWAP_<current productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <productCode>: Verwendet das SWAP_<productCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
* <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== get =====
<strike>
* regList
Listet alle User-Register des SWAP-Device (Readings).

* regListAll
Listet alle Register des SWAP-Device (Internals und Readings).

* listUnconfirmed
Listet alle unbestätigten Nachrichten in der Warteschlange.

* products
Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

* deviceXML
Gibt die Daten des zum derzeit zum per Attribut (Productcode) eingerichteten Device-XML-Files aus.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

===== Attribute =====
<strike>
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung.

* createUnknownReadings
Erzeug Readings auch für Register, die im Device-XML-File nicht definiert werden.

* ProductCode
Legt den ProductCode eines SWAP-Device fest. Dieses Attribut wird dazu benutzt, die Konfiguration vom Device-XML-File festzulegen.
Erst wenn der Produktcode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech:
attr <device> ProductCode 0000002200000003
kommen zu den allgemeinen Kommandos die spezifischen der nächst höheren Modulebene 35_SWAP_<productcode>.pm mit hinzu. Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

Für batteriebetriebene Devices, die während der Definition nicht aktiv sind, muss dieses Attribut manuell angelegt werden.
</strike>

Zugefügt zu Artikel [[SWAP]] --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 10:51, 17. Jul. 2015 (CEST)

==== SWAP_<ProductCode> ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Ist bei einem SWAP-Device das Attribut Productcode gesetzt, wird die SWAP-Nachricht an das entsprechende Modul der 3. Ebene weitergegeben und dort verarbeitet. Die spezifischen Kommandos und Attribute sind bei den entsprechenden [[panstamp#Explizite Anwendungen|Anwendungen]] näher beschrieben.
</strike>

Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

==== Intervall bei Sketch mit power down / batterie betriebene Panstamps ====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Devices mit power down mode durchlaufen beim Einschalten oder bei einem Reset eine 3 Sekunden Schleife und warten auf Kommandos, dann werden normaler Weise die Register mit den Sensorwerten gesendet und die normale Loop gestartet. power down devices gehen danach schlafen und wachen regelmässig auf um ihre Werte zu senden.
Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.

Nachrichten an ein Device im power-down-state werden gepuffert und dann an das Device geschickt, sobald dieses sich im SYNC status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:

<pre> set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> </pre>
{{Link2Forum|Topic=12487 |Message=87409}}
[http://forum.fhem.de/index.php?topic=12487.msg87409#msg87409]

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert.

Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist.
{{Link2Forum|Topic=12487 |Message=89205}}
[http://forum.fhem.de/index.php/topic,12487.msg89205.html#msg89205]

{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF in 0A zum Überlauf führt und dann ununterbrochen gesendet wird. Im fhem Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass fhem so mit dem Abarbeiten beschäftigt ist, dass es selber nicht zum senden kommt.
Zur Abhilfe kann im sketch in setup() ganz am Anfang ein
EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden und noch mal flashen. Wenn der Sketch damit ein mal durchgelaufen ist können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht.

Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}
[http://forum.fhem.de/index.php/topic,12487.msg87859.html#msg87859]

Für Devices im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald das Device seine Initialisierungssequenz durchläuft. Hierzu ist nach Absetzen der Kommandos Reset zu drücken oder die Stromquelle erneut zu verbinden.

Die automatisch vergebenen Adressen sind im Bereich F0-FE. d.h. eigentlich auch nur temporär und sollten auf eine lokal passende geändert werden.
{{Link2Forum|Topic=12487 |Message=87919}}
[http://forum.fhem.de/index.php/topic,12487.msg87919.html#msg87919]

Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>
Zugefügt zu Artikel [[SWAP]]. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)
==== Verschlüsselung ====

Die Aktivierung der Verschlüsselung für die Kommunikation zwischen panStamp und panStick ist hier beschrieben, scheint allerdings derzeit noch nicht eingecheckt zu sein (Stand 01.05.2015).
{{Link2Forum|Topic=12487 |Message=133040}}
[http://forum.fhem.de/index.php/topic,12487.msg133040.html#msg133040]
{{Link2Forum|Topic=12487 |Message=139341}}
[http://forum.fhem.de/index.php/topic,12487.msg139341.html#msg139341]

=== Trouble Shooting ===
<strike>
==== value has to be 10 byte(s) in size ====

Es besteht die Möglichkeit, dass die Internals aus irgend einem Grund nicht vollständig sind.
Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen
<pre>
set <device> statusRequest
set <device> readDeviceXML
</pre>

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]

Das Übertragen aller Daten nach dem Statusrequest kann einen Augenblick dauern.

Eine weitere Möglichkeit:
Die Fehlermeldung kommt immer wenn FHEM nicht weiss welche Firmware auf dem device ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]

==== register 0F is not known ====

{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]

==== Komplette Übersicht eines Device ====

<pre>
list <device>
</pre>
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]

==== fehlender oder falsche Productcode ====

Fehlt der Productcode, werden die zum Sketch zugehörigen Befehle nicht angezeigt und die Register nicht korrekt zugeordnet.
Verändert man den Productcode, sollte man im Anschluss folgenden Befehlt absetzten, um alle Register neu auszulesen
<pre>
set <device> statusRequest
</pre>

{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]

==== missing commands und register 00-0A unvollständig ====

Wenn in den Internals missing commands (SWAP_Sent_unconfirmed) auftauchen und ggf. die Register 00-0A nicht vollständig sind und das Internal "channels" nicht vorhanden ist, gibt es irgendein Kommunikationsproblem.

{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]

==== Funktion des Autocreate ====

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trozdem FF. Erst wenn das Device angelegt wird, kann versucht werden automatisch die Adresse zu setzen, hoffentlich auf die gleiche freie, die beim Namen auch schon gefunden wurde.

{{Link2Forum|Topic=12487 |Message=88110}}
[http://forum.fhem.de/index.php/topic,12487.msg88110.html#msg88110]

==== Adresse manuell setzen ====

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]

==== Panstamp antwortet nicht/EEprom to factory defaults ====

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.

{{Link2Forum|Topic=13890 |Message=121677}}
[http://forum.fhem.de/index.php?topic=13890.msg121677#msg121677]

==== Undefined subroutine &main::XMLin ====
Erhält man diese Fehlermeldung
<pre>
Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.
</pre>
<pre>
2013.09.26 11:34:24 0: ERROR: Cannot autoload SWAP
2013.09.26 11:34:24 3: panStick: Unknown code 000A001B000A000000000100000007, help me!
</pre>

Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
</pre>

==== Factory Defaults ====

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]

==== Status LED ====

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]

</strike> Inhalt in Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 21:00, 17. Jul. 2015 (CEST)

== Explizite Anwendungen ==
=== RGB-Board ===
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
==== Allgemeines ====
<strike>
Das Board unterstützt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z. B. als Unterputz Touchpanel) und FHEM bedienen.

Der Funktionsumfang wird in diesem [http://forum.fhem.de/index.php/topic,12487.msg81923.html#msg81923 Forenthread] vorgestellt. Die Hardware für das Board wird [http://forum.fhem.de/index.php/topic,13890.0.html hier] im FHEM Forum vorgestellt und ein Prototyp ist [http://forum.fhem.de/index.php/topic,12487.msg85777.html#msg85777 hier] zu sehen.

Die Projektseite zur Hardware findet sich [http://itse.homeip.net/projekte/12/6/ hier]. Eine Version 2 des Boards in geplant.

Eine Übersicht über die derzeit vorhandene Funktionalität (stand 01.05.2015):
{{Link2Forum|Topic=13890 |Message=1205404}}
[http://forum.fhem.de/index.php?topic=13890.msg120404#msg120404]

* bis zu vier LED-Kanäle (je nach Kombination von ir und soft pwm)
* ir senden
* ir empfangen
* Messen ob die LED-Versorgung an ist.
* Helligkeit eines an A2 angeschlossenen Helligkeitssensors
* Konfiguration der DMX-Basis-Adresse über das SWAP Register 0x12
* optional soft on auf letzten Wert
* Alles was auch vorher schon ging: dimmen, faden, IR-Fernbedienungen anlernen, ...

Wichtig zu wissen:
* Wenn IR aktiv ist und kein soft pwm lässt sich der 4. Kanal nur ein- und ausschalten.
* Wenn IR aktiv ist muss soft pwm aktiv sein um den 4. Kanal auch zu dimmen.
* Es wird nur ein zusätzlicher Kanal tatsächlich schon unterstützt, der fünfte ist noch geplant.
* Bei IR-Senden sind nur die Aufrufe für Sony und NEC tatsächlich eingebaut. Die anderen sind aber einfach zu ergänzen.
* Beim IR-Senden sind noch keine Wiederholungen eingebaut. Die müssen laut Protokoll aber eigentlich sein.

was noch kommt:
* besseres soft pwm
* mehr Konfiguration bezüglich default-Verhalten. Ramp-Zeiten, Delays, ...
* HSV-Farb-Modell um besser zu faden und vor Allem um den Weiss-Anteil automatisch auf die Weiss-LEDs zu legen
* die virtuellen Channel
* FHEM kompatibles IR-Senden
* sofortiges senden von Helligkeit und LED-Spannung bei Änderung
* andere IR-Lib mit sehr viel besserer Geräte-Unterstützung

Wie gehabt muss alles über config.h mit Compilerschaltern konfiguriert werden.
</strike>

Inhalt in Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== weitrere Screenshots =====
<strike>
<gallery>
File:SWAP_0000002200000003-internal.png|InternalValues
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>
</strike>

Inhalt in Artikel [[SWAP_0000002200000003]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== original RGB-Sketch (von panstamp.com) =====
Der originale Sketch von der panStamp.com-Seite und das generelle FHEM-Modul verstehen von Haus aus nur die regSet und regGet Kommandos. Wenn man den colorpicker verwenden möchte, geht das nur per readingsProxy.

Das einfachste ist es den Sketch und das FHEM-Modul für das RGB-Board zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen Kommandos wie on, off, on-for-timer, dimup, ... und kann konfigurieren, wie das Board nach dem Hart- oder Soft-Einschalten reagieren soll.

Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden.
{{Link2Forum|Topic=12487 |Message=220463}}
[http://forum.fhem.de/index.php/topic,12487.msg220463.html#msg220463]

Falls jemand trotzdem den normalen RGB-Sketch verwendet:
* Im Code alle drei 0000002200000003 durch 0000000100000003 ersetzen.
Dann geht on/off/toggle/set rgb RRGGBB und auch der colorpicker, wenn das HUEDevice Modul auch geladen ist.

==== Sketch vorbereiten, kompilieren und hochladen ====
===== Vorbereitungen =====
<strike>
(Stand 01.05.2015)

Mit der Arduino IDE 1.5.x gab es gundlegende Umstellungen, für die der derzeitige Sketch [r4716] vermutlich angepasst werden müsste.

Für den RGB-Driver sketch sind je nach gewünschtem Funktionsumfang noch folgende libs zu installieren:

* Die Dateien der '''Panstamp Lib''' läd man von hier [[http://old.panstamp.com/downloads]] (panstamp_library.zip, 129k v.25, May 31, 2013). Mit der neueren Lib v.4 läuft die Kompillierung des derzeitigen Sketches nicht durch. Die Dateien der Lib speichert man in einem entsprechend neuen Unterordner, z.B. hierin C:\Users\<username>\Documents\Arduino\libraries. Am Ende der ganzen Aktion im Folgenden sollten sich in diesem Unterordner 3 neue Unterordner befinden: IRremote, DMXSerial und panstamp

* Die Dateien der '''IR Remote Lib''' kopiert man von hier [[https://github.com/shirriff/Arduino-IRremote]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.

* Die Dateien der '''DMX Lib''' kopiert man von hier [[http://www.mathertel.de/Arduino/DMXSerial.aspx]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[http://arduino.cc/en/Hacking/Libraries]]. Dass die Libraries richtig erkannt worden sind, lässt sich dadurch erkennen, dass unter Sketch/Library importieren die 3 weiteren Punkte unten unter "beigetragen" auftauchen.

Die Librarys sollten entweder mit dem entsprechenden Menüpunkt in die IDE integriert werden oder jeweils nach auspacken des zip files als als kompletten Ordner im Arduino libraries Verzeichnis abgelegt werden (siehe [http://www.arduino.cc/en/Hacking/Libraries)]).

Für das kompilieren mit INO siehe [[panstamp#ino|hier]].

===== Link zum sketch =====
Die aktuelle Version des RGB-Driver Sketches findet sich auf [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge].
{{Link2Forum|Topic=13890 |Message=201391}}
[http://forum.fhem.de/index.php?topic=13890.msg201391#msg201391]

===== Kompillierte hex version =====
Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=121619}}
[http://forum.fhem.de/index.php?topic=13890.msg121619#msg121619]

===== HEX-File ohne IR und DMX =====
Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden:
{{Link2Forum|Topic=13890 |Message=201955}}
[http://forum.fhem.de/index.php?topic=13890.msg201955#msg201955]

===== Sketch anpassen, kompilieren und hochladen =====

* Welche Features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der #define ENABLE_... Zeilen festlegen. {{Link2Forum|Topic=13890 |Message=173431}} [http://forum.fhem.de/index.php?topic=13890.msg173431#msg173431] Den Sketch entsprechend den Bedürfnissen in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen. Für die Konfigurationen siehe [[panstamp#Sketch konfigurieren|Sketch konfigurieren]].
* Windows IDE only: Falls alles so bleibt, wie es heruntergeladen wurde, wechselt man wieder auf den Reiter sketch und importiert über ->Sketch Library importieren die entsprechenden Libs für IRremote und DMX. Dadurch werden 3 neue Zeilen hinzugefügt.
* Nun sollte über Sketch/Überprüften/Kompillieren die Erstellung des Sketches möglich sein.
* Falls erfolgreich unter Datei/Hochladen (ohne Programmer) den Sketch auf den Panstamp laden.

==== Sketch konfigurieren ====

===== DMX =====
<pre>
#define ENABLE_DMX
</pre>

Hierbei ist darauf zu achten, dass in der DMX-Lib in der Datei DMXSerial.h die Zeile

<pre>
#define DmxModePin 2 // Arduino pin 2 for controlling the data direction
</pre>

in

<pre>
#define DmxModePin 7 // Arduino pin 7 for controlling the data direction
</pre>

abgeändert werden muss.

===== Temperatur- und Luftfeuchtigkeitssensor =====

<pre>
#define HAS_SENSOR
</pre>

Dieses ermöglicht die Nutzung eines DHT22 Sensors zur Auswerung von Temperatur und Luftfeuchtigkeit.

Dafür sollten diese Konfigurationszeilen auskommentiert sein
<pre>
USE_SOFT_PWM;
ENABLE_IR_SEND;
ENABLE_REPEATER;
</pre>

In der IRremote.cpp Datei in der Irremote Library muss die Zeile
<pre>
void IRrecv::disableIRIn()
{
TIMER_DISABLE_INTR;
}
</pre>
sowie die Irremote.h Datei unter Public: um die Zeile
<pre>
void disableIRIn();
</pre>
erweitert werden.

Der Daten-Pin des DHT22 Sensors muss hierfür an A2 des panStamps angeschlossen werden.

Ein Beispiel für die Umrechnung der Userreading für Spannung Temp etc. ist hier beschrieben.
{{Link2Forum|Topic=12487 |Message=76489}}
[http://forum.fhem.de/index.php?topic=12487.msg76489#msg76489]

===== Zusammenhänge der Konfiguration =====

Die Zusammenhänge der Konfiguration sind hier beschrieben
{{Link2Forum|Topic=13890 |Message=175181}}
[http://forum.fhem.de/index.php?topic=13890.msg175181#msg175181]
</strike>

Inhalt in Artikel [[PanStamp RGBWW Board mit DMX und IR]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== Bedienung in FHEMWEB ====

===== Komandos =====

====== Definition ======

Der Panstick wird entsprechend folgendem Befehlt angelegt:
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>

Die Schnittstelle ist entsprechend Installation des [[panstamp#unter Linux|Pansticks]] anzupassen.

Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv ist.

====== Attribute TBC ======

====== Set TBC ======

====== Get TBC ======
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923

EIn register verändern
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Register umrechnung dec zu hex TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Poweronstate TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg88054.html#msg88054
http://forum.fhem.de/index.php/topic,12487.msg95574.html#msg95574
http://forum.fhem.de/index.php/topic,13890.msg124456.html#msg124456

===== Aus nach poweron TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg121296#msg121296
Power on register
http://forum.fhem.de/index.php?topic=13890.msg121137#msg121137

===== listunconfirmed TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112

</strike> In Artikel [[SWAP]] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

===== Fadeto TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406

{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
Default fade time
http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572

===== Eigenschaften des fade TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== 4.,5. kanal TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg169741#msg169741
http://forum.fhem.de/index.php?topic=13890.msg192132#msg192132
http://forum.fhem.de/index.php?topic=13890.msg201922#msg201922
http://forum.fhem.de/index.php?topic=13890.msg201936#msg201936
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

===== Extra kanäle TBC =====
{{Randnotiz|RNText=In Artikel [[SWAP_0000002200000003]]}}
http://forum.fhem.de/index.php?topic=13890.msg173280#msg173280
http://forum.fhem.de/index.php?topic=13890.msg214329#msg214329
http://forum.fhem.de/index.php?topic=13890.msg214474#msg214474

==== IR Schnittstelle TBC ====
===== IR TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg107061#msg107061
http://forum.fhem.de/index.php?topic=13890.msg107197#msg107197
http://forum.fhem.de/index.php?topic=13890.msg107415#msg107415
http://forum.fhem.de/index.php/topic,13890.msg122021.html#msg122021
http://forum.fhem.de/index.php/topic,13890.msg122077.html#msg122077
http://forum.fhem.de/index.php?topic=13890.msg167351#msg167351
http://forum.fhem.de/index.php?topic=13890.msg175269#msg175269
http://forum.fhem.de/index.php?topic=13890.msg175285#msg175285
http://forum.fhem.de/index.php?topic=13890.msg182582#msg182582
http://forum.fhem.de/index.php?topic=13890.msg245597#msg245597
http://forum.fhem.de/index.php?topic=13890.msg259267#msg259267
</strike>

===== IR-Belegung Panstamp RGB-Board TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008
http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153
</strike>

===== Ircluster TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331
</strike>

===== Irgate TBC =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)

==== DMX Schnittstelle ====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Da die DMX-Schrittstelle kein direktes Interface zu FHEM hat, sondern nur die direkte Kommunikation zwischen DMX-Kontroller und RGB-Board betrifft, ist die Schnittstelle nur bei der Konfiguration des Sketches und über die Dokumentation des Boards beschrieben.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
==== sonstiges ====

===== Alternativer Fade per Patch =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt:
{{Link2Forum|Topic=12487 |Message=133096}}
[http://forum.fhem.de/index.php/topic,12487.msg133096.html#msg133096]

Der Patch ist '''nicht eingecheckt'''.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
===== Kompatibilität RBG-Board mit NRG-panStamps =====
{{Randnotiz|RNText=In Artikel [[PanStamp_RGBWW_Board_mit_DMX_und_IR]]}}
<strike>
Mit dem hier beschriebenen Sketch ist das Board nur mit den AVRs kompatibel.
Die Pinbelegung zwischen AVR und NRG ist im Prinzip gleich bis auf Pin 23. Das ist bei dem NRG ein IO Pin und nicht Ground wie beim AVR.
Das wäre kein Problem wenn man entweder hardwareseitig den Kontakt unterbricht oder aber programmiertechnisch diesen Pin '''NIE''' als Ausgang definiert. Ansonsten gibt’s ein „kurzen“. Oder wenn er als Ausgang definiert ist darf er nur das GND Potential haben, also Low, 0.

{{Link2Forum|Topic=13890 |Message=247069}}
[http://forum.fhem.de/index.php?topic=13890.msg247069#msg247069]

Da es derzeit (Stand 01.05.2015) aber keinen Sketch gibt, der auf den NRG lauffähig ist, wäre vorher noch diese Herausforderung zu lösen.
</strike>

In Artikel übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:54, 17. Jul. 2015 (CEST)
=== Bodenfeuchtesensor ===
{{Randnotiz|RNText=In Artikel [[SWAP]]}}
<strike>
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

Ein Artikel über ein selbstentwickeltes PanStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben.

Eine für einen Vegetronix sensor angepasste Version kann von [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ sourceforge] heruntergeladen werden. Das Übertragungsintervall ist wie üblich über das regsiter 0A konfigurierbar. Der Sensor wird and GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsintervall nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)},
VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 *
(ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))},
voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001},
battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>

Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.

Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.
</strike>

In Artikel [[SWAP] übernommen. --[[Benutzer:TeeVau|TeeVau]] ([[Benutzer Diskussion:TeeVau|Diskussion]]) 23:59, 18. Jul. 2015 (CEST)

=== Umweltsensor ===

Die Weiterentwicklung des Bodenfeuchtesensors zum Umweltsensor ist hier [[PanStamp_Umweltsensor]] beschrieben.

=== Ultraschall-Füllstandssensor ===

Projektidee

=== Repeater Mode ===

Die Repeaterfunktionalität ist derzeit (01.05.2015) noch nicht näher beschrieben, wird aber von den Modulen unterstützt.
{{Link2Forum|Topic=12487 |Message=118403}}
[http://forum.fhem.de/index.php/topic,12487.msg118403.html#msg118403]

== Weblinks ==
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
* [http://itse.homeip.net/projekte/12/6/ Projektseite] für das RGB-Multi-Board.
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ rgbdriver sketch] auf sourceforge
* [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/ soilmoisture sketch] auf sourceforge

[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]