PanStamp: Unterschied zwischen den Versionen

Aus FHEMWiki
 
(58 dazwischenliegende Versionen von 11 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{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] [http://fhem.de/commandref.html#SWAP_0000002200000003 35_SWAP_0000002200000003.pm]
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=430 Andre / justme1968]
|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 Ardunio IDE oder mit dem ino Kommandozeilen Binary programmieren.
Dieser Artikel, gedacht als Eingangsartikel zu dem Thema, beschreibt die Zusammenhänge rund um die Hardwaremodule „panStamp“.
 
Zur Hardware gibt es [http://www.panstamp.com/ herstellerseitig] eine eigene 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].
 
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".
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]).
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).
 
== Allgemein ==
Grundsätzlich gehören zur Integration in FHEM das [[#FHEM-Module/Device Definition Files|FHEM Modul]] panStamp-Modul, das FHEM Modul SWAP und je nach [[#Anwendungsbeispiele|Anwendung]] ein spezifisches FHEM Modul SWAP_XXXXXXXXXXXXXXXX mit entsprechenden Device Definition Files.
Details über das Zusammenspiel sind in der [[#Systemübersicht|Systemübersicht]] weiter unten beschrieben.
 
Darüber hinaus muss ein passender [#panStamp Sketches|Sketch]] (wie eine Firmware) auf die Hardwaremodule geladen werden vergleichbar mit der Firmware für einen CUL. Der Sketch bestimmt die Funktion und ist damit abhängig von der Anwendung.
Teilweise findet man fertig kompilierte Sketches. Man kann sich aber auch den Sourcecode herunterladen, den eigenen Bedürfnissen anpassen oder gleich einen eigenen Sketch programmieren. Der Sketch wird dann innerhalb einer passenden Entwicklungsumgebung kompiliert und anschließend auf den panStamp hochgeladen.
 
Für die Einrichtung (Device Definition) innerhalb von FHEM wird für die Serverseite das IO-Device definiert, für die Seite der Aktuatoren/Sensoren das entsprechende Device.
 
Eine Übersicht über alle sich mit dem Thema panStamp befassenden Artikel befindet sich [[:Kategorie:PanStamp|hier]].
 
== Systemübersicht ==
[[Datei:Panstamp-Systemoverview.jpg|550px|thumb|panStamp Systemübersicht]]
Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt. Die Kommunikationskette ist wie folgt:
 
FHEM -> Server Hardware -> USB -> [[#panStick|panStick]] -> panStamp (mit [[#Modem-Sketch|Modem-Sketch]]) -> Funkstrecke (per SWAP-Protokoll) -> panStamp ([[#auf Board abgestimmter Sketch|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, das panStamp FHEM-Modul als IO-Device für FHEM und das FHEM-Modul SWAP zur Integration des Funkprotokolls der panStamps.  


== Simple Wireless Abstract Protocol (SWAP) ==
Optional kann es noch weitere Module geben als 3. Ebene, die nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm 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.
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.
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.


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.
== panStamp Hardware ==


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 Beschreibung im Folgenden bezieht sich vornehmlich auf die Hardwaremodule der Generation 1 und 1.1, sowie panStick 1.1, 1.2, die derzeit (Mitte 2016) beim Hersteller nicht mehr erworben werden können.  


Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.
=== panStick/Shield ===
Als Schnittstelle zwischen FHEM Server-Hardware und dem Funkprotokoll dient entweder ein panStick mit aufgestecktem panStamp-Hardwaremodul und Modem-Sketch (USB Stick mit Sockel zum Aufstecken eines panStamp) oder ein panShield (mit integriertem panStamp und RTC) an einem Raspberry Pi.


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.
==== panStick ====
Der panStick stellt die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface der panStamp-Hardware auf der anderen Seite dar. Der panStick wird grundsätzlich für zwei Aufgaben benötigt:
# Zur Vorbereitung einer panStamp-Hardware für den Betrieb auf einem ''Board'' wird die neue panStamp-Hardware in den panStick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
# Im "normalen" Betrieb steckt eine panStamp-Hardware auf dem panStick. Der so angebundene panStamp wird mit einem (bei Auslieferung des panStamps vorinstallierten) Modem-Sketch als RF-Modem verwendet und dient so der FHEM Server-Hardware als Interface zu anderen panStamp-Hardwaremodulen, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird. Der panStick kann auch per USB an einer anderen Serverhardware angebunden werden. Die Kommunikation zu FHEM erfolgt dann z.B. über {{Link2Forum|Topic= 12487|Message=296182l|LinkText=ser2net}} oder [[FHEM2FHEM]] über LAN.
 
An dieser Stelle sei darauf hingewiesen, dass umgangssprachlich im Forum häufig von panStick die Rede ist, damit aber die Definition des IO-Devices innerhalb von FHEM gemeint ist. Auch kann darunter die Kombination aus panStick, aufgestecktem panStamp und darauf befindlichem Model-Sketch gemeint sein, was gesamt dann als Funk-Interface dient. Ein panStick ohne panStamp-Hardware ist ziemlich nutzlos für die Funktion. Mit panStick ist hier also die reine Hardware als Interface zwischen USB-Port und panStamp gemeint.
 
==== panShield ====
Ein panShield übernimmt die gleiche Funktion wie ein panStick mit aufgestecktem panStamp, wird aber direkt an die IOs eines Raspberrys angeschlossen. Da auf dem panShield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die Funktion des IO-Interfaces wie für den panStick der "normale" Betrieb oben beschrieben.
 
Der Einfachheit halber wird im Folgenden nicht mehr auf den panShield im Speziellen eingegangen, da es keinen funktionalen Unterschied zur Kombination aus panStick und panStamp gibt.


== FHEM Integration ==
Die Integration in FHEM erfolgt über eine reihe von Modulen die im folgenden genauer beschrieben werden.
=== panStamp ===
=== panStamp ===
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 Modem-Sketch als RF Modem verwenden und über das FHEM Modul panStamp angesprochen. Hierzu ist in FHEM ein entsprechendes Device anzulegen: <pre>define panStick panStamp /dev/ttyUSBx@38400</pre>
Die panStamps bilden das zentrale Glied und sind wie eingangs bereits beschrieben Arduino Clones mit einem CC1101 Funkmodul. Mit einer passenden Firmware (Sketch) ausgestattet, stecken sie entweder auf dem panStick oder den entsprechenden Boards/Platinen.
 
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!
 
Um die Verwirrung der Namensgebung komplett zu machen, wird im Forum häufig vom "panStamps" als Device gesprochen, obwohl es eigentlich als SWAP-Device definiert wird.
 
Mit der Einführung der 2. Generation (AVR2, NRG2) hat sich das Footprint der Module stark verändert. Adapterplatinen, um die Module mit neuem Footprint in Hardware mit altem zu integrieren, konnten auf Anfrage bei Daniel im Shop noch geordert werden (Stand Ende 2015; {{Link2Forum|Topic= 12487|Message=296464l|LinkText=Forum}}, {{Link2Forum|Topic= 12487|Message=392818l|LinkText=Forum}}). Langfristig ist davon auszugehen, dass diese nicht dauerhaft werden lieferbar sein. Von der Programmierung her unterscheiden sich die Module jedoch nicht.
 
=== spezifisches "Board" ===
Im Gegenzug zum panStick, als Hardware-Interface zwischen panStamp und USB-Port des Servers, stellt das spezifische Board das Hardware-Interface zwischen panStamp-Hardware und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs der panStamp-Hardware auf die Steuerausgänge des Boards um bzw. leitet die Steuereingänge des Boards zur Auswertung an den panStamp Input weiter. Mit panStamp Input und Output sind in diesem Fall die Pins der CPU gemeint.
Entsprechend Anwendungsfall und Sketch werden die Steuereingänge und Steuerausgä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 irgendeine 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 [[#Anwendungsbeispiele|panStamp RGBWW Board mit DMX und IR]] eine externe Stromversorgung. Speziell bei diesem Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder insgesamt panStamp und LEDs gemeinsam versorgen.
 
== panStamp Sketch ==
 
=== Modem-Sketch ===
Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und dem SWAP-Funkprotokoll dar. Das SWAP-Protokoll wird über ein serielles Protokoll dem FHEM-Server zur Verfügung gestellt. Die Verarbeitung des SWAP-Protokolls übernimmt das gleichnamige FHEM-Modul [[#Ebene 2: 34_SWAP.pm|SWAP]]. Auf jedem panStamp (AVR, bei NRG unbekannt) ist im Auslieferungszustand der Modem-Sketch installiert. Der panStick besitzt ebenfalls eine SWAP-ID, also eine fest zugeordnete Adresse. Das ist immer die Adresse <code>0x01</code>.
 
Ein NRG panStamp lässt sich als Modem verwenden, wenn man den Schalter auf dem panStick auf AVR stellt ([http://www.panstamp.org/forum/archive/index.php/thread-4200.html Forum]).


Dieses panStamp Device versucht dann als erstes alle panStamps im Netz zu finden und per autocreate anzulegen.
=== 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-Hardwaremodul bereit. Der Sketch verarbeitet die über das SWAP-Protokoll versandten 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.


=== SWAP ===
Die Kompatibilität der bestehenden Sketches hängt stark vom Typ des panStamps und von der Entwicklungsumgebung ab. D.h. die neuesten panStamps (NRG) sind mit den neuesten Umgebungen Arduino 1.6x und unabhängig davon mit den alten Sketches meistens nicht kompatibel.
[[Datei:SWAP_ 0000000100000005-detail.png|mini|hochkant=2.5|Readings]]
Das SWAP Modul ermöglicht die generische Integration beliebiger panStamp Sensoren und Aktoren in FHEM. 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:
== FHEM-Module/Device Definition Files ==
Wie eingangs erwähnt erfolgt die Integration in FHEM ü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 }}


:<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>
=== Ebene 1: 34_panStamp.pm ===
Das Modul ist dazu da, Nachrichten aus dem Funknetzwerk, die von einem panStamp mit Modem-Sketch auf einem panStick empfangen werden, FHEM zur Verfügung zu stellen und umgekehrt. Alle eintreffenden SWAP-Pakete werden direkt an FHEM durchgereicht und im SWAP-Modul verarbeitet.


[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Im moduleigenen [[panStamp (Modul)|Artikel]] ist die Einrichtung des IO-Devices innerhalb von FHEM beschrieben.
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>
=== Ebene 2: 34_SWAP.pm ===
Das Modul implementiert das SWAP Protokoll das zwischen den panStamps gesprochen wird. Darüber werden die auf den entsprechenden Boards/Platinen steckenden panStamp innerhalb von FHEM als TYPE SWAP_<ProductCode> definiert.


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. Für diese werden hier die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Kommandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des ProductCode zur Verfügung stehen, werden in den Wiki-Artikeln der jeweiligen Module beschrieben.


Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:
Um die Verwirrung komplett zu machen, wird im Forum meistens von "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind.
get <device> regList
get <device> regListALL


und einzelne Register abgefragt und gesetzt werden:
=== Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm ===
set <device> regGet <ID>
[[Datei:SWAP_0000002200000003.png|thumb|rechts|RGB LED Driver Board]]
set <device> regSet <ID> <value>
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 Aktoren wie Schalter/Dimmer/... sehr einfach, diese in FHEM zu integrieren.  
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.


==== Neue panStamps in Betrieb nehmen ====
Wenn die Namenskonvention SWAP_<ProductCode> für diese Module eingehalten wird, funktioniert auch das autocreate sofern das Modul in FHEM bekannt ist.
'''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:
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 [[#Anwendungsbeispiele|35_SWAP_0000002200000003.pm]].
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.
=== Device Definition Files ===
Ein XML File was die Ein- und Ausgänge der panStamps beschreibt. Durch diese Datei wird dem FHEM-Modul mitgeteilt wie die Readings zu benennen sind, welche Werte die Readings haben können und ob die Readings/Register nur ausgelesen werden dürfen, oder auch beschrieben werden können. Im [https://github.com/panStamp/panstamp/wiki/Device-Definition-Files Wiki des Herstellers] ist der Aufbau des Device Definition Files beschrieben. Wenn für einen End Point eine Unit angegeben ist, mit entsprechendem Faktor, dann erstellt das SWAP-Modul automatisch ein passendes userReadings mit der angegebenen Umrechnung.


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.
== panStamps konfigurieren und in Betrieb nehmen ==
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 das fhem so mit dem abarbeiten beschäftigt ist das 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.
Die Inbetriebnahme ist grundsätzlich in die Einrichtung des IO-Devices und die Einrichtung des entfernten Hardwaremoduls (Sensor/Aktuator) zu unterscheiden.


=== SWAP_XXXXXXXXXXXXXXXX ===
Auf die Einrichtung des IO-Devices ist [[#Ebene 1: 34_panStamp.pm|hier]] bereits verwiesen.
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.


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.
Für die Einrichtung des entfernten Hardwaremoduls müssen im Groben folgende Schritte erfolgen:
# Vorbereiten einer [[panStamp_Programmierung|Entwicklungsumgebung]], kompilieren und hochladen der Firmware
# Aufstecken des programmierten panStamps auf das Board
# Mit Strom versorgen und von Autocreate einrichten lassen
# Attribute, Namen, Userreading des neuen SWAP-Device nach Bedarf anpassen


==== SWAP_0000002200000003 ====
=== während der Einrichtung zu berücksichtigen ===
[[Datei:SWAP_0000002200000003.png|mini|rechts|hochkant=2.5|RGB LED Driver Board]]
'''Info: Das SWAP Modul unterstützt [[autocreate]]. Bei der Inbetriebnahme ist autocreate zu aktivieren!'''
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.&nbsp;B. als Unterputz Touchpanel) und FHEM bedienen.
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 ihre 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ützt) 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, dass 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 entfernt werden und der panStamp muss noch mal geflasht werden. Ansonsten wird die Adresse bei jedem Start erneut auf <code>5555</code> gesetzt.


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.
=== Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board ===


===== weitrere Screenshots =====
* Ein panStamp-Hardwaremodul wird in einen panStick gesteckt und der panStick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp-Hardwaremodul auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.
<gallery>
* Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).
File:SWAP_0000002200000003-internal.png|InternalValues
* Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf das panStamp-Hardwaremodul hochgeladen.
File:SWAP_0000002200000003-readings.png|Readings
* Das programmierte panStamp-Hardwaremodul, aus dem panStick, in das panStamp_RGBWW_Board stecken.
File:SWAP_0000002200000003-attributes.png|Attributes
* Ein panStamp-Hardwaremodul mit Modem-Sketch in den panStick stecken und an den FHEM-Host stecken.
</gallery>
* IO-Device unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
* panStamp_RGBWW_Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, das SWAP-Device automatisch eingerichtet werden.
* SWAP-Device in FHEM an Gegebenheiten anpassen.


== Arduino Sketches ==
== Anwendungsbeispiele ==
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:
Es gibt bereits selbst entwickelte Hardware und Software auf Basis der panStamp Hardware und dem SWAP Protokoll:
* [[panStamp Umweltsensor|Umweltsensor]]
* [[Bodenfeuchtesensor]]
* [[panStamp Innenraumsensor|Innenraumsensor]]
* [[panStamp RGBWW Board mit DMX und IR|RGBWW Board mit DMX und IR]]
* Lithium Battery Charging Board für den panStamp AVR2 {{Link2Forum|Topic=12487|Message=349328}}
* [[panStamp FensterkontaktSensor|Fensterkontaktsensor]]


* IR lib - https://github.com/shirriff/Arduino-IRremote
== Bekannte Probleme ==
* DMX lib- http://www.mathertel.de/Arduino/DMXSerial.aspx


Diese 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.
* Beim Systemstart werden einige Perl-Warnings ins Log geschrieben, die aber die Funktion der Module nicht beeinträchtigen.


Nun fehlt noch der angepasste rgbdriver-Sketch:
* Beim Systemstart wird eine SWAP-Broadcast Nachricht verschickt, die von allen empfangsbereiten panStamps beantwortet wird. Dieses führt bei häufig schnell bei kurz aufeinanderfolgenden Systemstarts zur Überschreitung des Transmit Limits im Rahmen der [[1%25_Regel|1%-Regel]] für das verwendete Frequenzband.
* Version vom 06.2013: http://forum.fhem.de/index.php?action=dlattach;topic=12487.0;attach=3392
* Version vom 10.2013: http://forum.fhem.de/index.php?action=dlattach;topic=12487.0;attach=6701


Welche features der sketch bietet lässt sich im config.h file durch ein- oder auskommentieren der #define ENABLE_... Zeilen festlegen.
Weitere Troubleshooting Hinweise finden sich [[SWAP#Trouble Shooting|hier]]


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.
= Weblinks =
* [http://www.panstamp.com/home panStamp] panStamp Hersteller


[[Kategorie:Interface]]
[[Kategorie:panStamp]]
[[Kategorie:Interfaces]]

Aktuelle Version vom 27. Januar 2019, 21:11 Uhr

PanStamp
panStamp
Allgemein
Protokoll SWAP
Typ Sender, Empfänger, Sensor, Interface
Kategorie
Technische Details
Kommunikation 868MHz (433/915MHz)
Kanäle
Betriebsspannung 3.3V (panStick: 5V USB)
Leistungsaufnahme
Versorgung Battery (panStick: USB)
Abmessungen 17.7 x 30.5 mm
Sonstiges
Modulname 34_panStamp.pm 34_SWAP.pm 35_SWAP_0000002200000003.pm
Ersteller Andre / justme1968
Hersteller panStamp


Dieser Artikel, gedacht als Eingangsartikel zu dem Thema, beschreibt die Zusammenhänge rund um die Hardwaremodule „panStamp“.

Zur Hardware gibt es herstellerseitig eine eigene Community mit Forum und Wiki, sowie Downloads auf Github.

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 (SWAP).

Allgemein

Grundsätzlich gehören zur Integration in FHEM das FHEM Modul panStamp-Modul, das FHEM Modul SWAP und je nach Anwendung ein spezifisches FHEM Modul SWAP_XXXXXXXXXXXXXXXX mit entsprechenden Device Definition Files. Details über das Zusammenspiel sind in der Systemübersicht weiter unten beschrieben.

Darüber hinaus muss ein passender [#panStamp Sketches|Sketch]] (wie eine Firmware) auf die Hardwaremodule geladen werden vergleichbar mit der Firmware für einen CUL. Der Sketch bestimmt die Funktion und ist damit abhängig von der Anwendung. Teilweise findet man fertig kompilierte Sketches. Man kann sich aber auch den Sourcecode herunterladen, den eigenen Bedürfnissen anpassen oder gleich einen eigenen Sketch programmieren. Der Sketch wird dann innerhalb einer passenden Entwicklungsumgebung kompiliert und anschließend auf den panStamp hochgeladen.

Für die Einrichtung (Device Definition) innerhalb von FHEM wird für die Serverseite das IO-Device definiert, für die Seite der Aktuatoren/Sensoren das entsprechende Device.

Eine Übersicht über alle sich mit dem Thema panStamp befassenden Artikel befindet sich hier.

Systemübersicht

panStamp Systemübersicht

Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt. Die Kommunikationskette ist wie folgt:

FHEM -> Server Hardware -> USB -> panStick -> panStamp (mit Modem-Sketch) -> Funkstrecke (per SWAP-Protokoll) -> 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, das panStamp FHEM-Modul als IO-Device für FHEM und das FHEM-Modul SWAP zur Integration des Funkprotokolls der panStamps.

Optional kann es noch weitere Module geben als 3. Ebene, die nach dem Schema SWAP_XXXXXXXXXXXXXXXX.pm 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.

panStamp Hardware

Die Beschreibung im Folgenden bezieht sich vornehmlich auf die Hardwaremodule der Generation 1 und 1.1, sowie panStick 1.1, 1.2, die derzeit (Mitte 2016) beim Hersteller nicht mehr erworben werden können.

panStick/Shield

Als Schnittstelle zwischen FHEM Server-Hardware und dem Funkprotokoll dient entweder ein panStick mit aufgestecktem panStamp-Hardwaremodul und Modem-Sketch (USB Stick mit Sockel zum Aufstecken eines panStamp) oder ein panShield (mit integriertem panStamp und RTC) an einem Raspberry Pi.

panStick

Der panStick stellt die Verbindung zwischen dem USB-Port auf der einen Seite und dem seriellen Interface der panStamp-Hardware auf der anderen Seite dar. Der panStick wird grundsätzlich für zwei Aufgaben benötigt:

  1. Zur Vorbereitung einer panStamp-Hardware für den Betrieb auf einem Board wird die neue panStamp-Hardware in den panStick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.
  2. Im "normalen" Betrieb steckt eine panStamp-Hardware auf dem panStick. Der so angebundene panStamp wird mit einem (bei Auslieferung des panStamps vorinstallierten) Modem-Sketch als RF-Modem verwendet und dient so der FHEM Server-Hardware als Interface zu anderen panStamp-Hardwaremodulen, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird. 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.

An dieser Stelle sei darauf hingewiesen, dass umgangssprachlich im Forum häufig von panStick die Rede ist, damit aber die Definition des IO-Devices innerhalb von FHEM gemeint ist. Auch kann darunter die Kombination aus panStick, aufgestecktem panStamp und darauf befindlichem Model-Sketch gemeint sein, was gesamt dann als Funk-Interface dient. Ein panStick ohne panStamp-Hardware ist ziemlich nutzlos für die Funktion. Mit panStick ist hier also die reine Hardware als Interface zwischen USB-Port und panStamp gemeint.

panShield

Ein panShield übernimmt die gleiche Funktion wie ein panStick mit aufgestecktem panStamp, wird aber direkt an die IOs eines Raspberrys angeschlossen. Da auf dem panShield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die Funktion des IO-Interfaces wie für den panStick der "normale" Betrieb oben beschrieben.

Der Einfachheit halber wird im Folgenden nicht mehr auf den panShield im Speziellen eingegangen, da es keinen funktionalen Unterschied zur Kombination aus panStick und panStamp gibt.

panStamp

Die panStamps bilden das zentrale Glied und sind wie eingangs bereits beschrieben Arduino Clones mit einem CC1101 Funkmodul. Mit einer passenden Firmware (Sketch) ausgestattet, stecken sie entweder auf dem panStick oder den entsprechenden Boards/Platinen.

Um einen panStamp in Betrieb zu nehmen muss er unbedingt mit einer Antenne oder einem Stück Draht in der richtigen Länge bestückt sein. Ohne Antenne funktioniert die Übertragung nicht, auch nicht auf kurze Distanzen!

Um die Verwirrung der Namensgebung komplett zu machen, wird im Forum häufig vom "panStamps" als Device gesprochen, obwohl es eigentlich als SWAP-Device definiert wird.

Mit der Einführung der 2. Generation (AVR2, NRG2) hat sich das Footprint der Module stark verändert. Adapterplatinen, um die Module mit neuem Footprint in Hardware mit altem zu integrieren, konnten auf Anfrage bei Daniel im Shop noch geordert werden (Stand Ende 2015; Forum, Forum). Langfristig ist davon auszugehen, dass diese nicht dauerhaft werden lieferbar sein. Von der Programmierung her unterscheiden sich die Module jedoch nicht.

spezifisches "Board"

Im Gegenzug zum panStick, als Hardware-Interface zwischen panStamp und USB-Port des Servers, stellt das spezifische Board das Hardware-Interface zwischen panStamp-Hardware und Input/Outputs (analog/digital) dar. Das "Board" nimmt den panStamp mit dem passenden Sketch auf und setzt die Outputs der panStamp-Hardware auf die Steuerausgänge des Boards um bzw. leitet die Steuereingänge des Boards zur Auswertung an den panStamp Input weiter. Mit panStamp Input und Output sind in diesem Fall die Pins der CPU gemeint. Entsprechend Anwendungsfall und Sketch werden die Steuereingänge und Steuerausgä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 irgendeine 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 panStamp RGBWW Board mit DMX und IR eine externe Stromversorgung. Speziell bei diesem Board kann die Stromversorgung sogar separat für panStamp und LEDs ausgeführt sein oder insgesamt panStamp und LEDs gemeinsam versorgen.

panStamp Sketch

Modem-Sketch

Der Modem-Sketch stellt das Software-Verbindungsglied zwischen panStamp und dem SWAP-Funkprotokoll dar. Das SWAP-Protokoll wird über ein serielles Protokoll dem FHEM-Server zur Verfügung gestellt. Die Verarbeitung des SWAP-Protokolls übernimmt das gleichnamige FHEM-Modul SWAP. Auf jedem panStamp (AVR, bei NRG unbekannt) ist im Auslieferungszustand der Modem-Sketch installiert. Der panStick besitzt ebenfalls eine SWAP-ID, also eine fest zugeordnete Adresse. Das ist immer die Adresse 0x01.

Ein NRG panStamp lässt sich als Modem verwenden, wenn man den Schalter auf dem panStick auf AVR stellt (Forum).

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-Hardwaremodul bereit. Der Sketch verarbeitet die über das SWAP-Protokoll versandten 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.

Die Kompatibilität der bestehenden Sketches hängt stark vom Typ des panStamps und von der Entwicklungsumgebung ab. D.h. die neuesten panStamps (NRG) sind mit den neuesten Umgebungen Arduino 1.6x und unabhängig davon mit den alten Sketches meistens nicht kompatibel.

FHEM-Module/Device Definition Files

Wie eingangs erwähnt erfolgt die Integration in FHEM ü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. Beitrag

Ebene 1: 34_panStamp.pm

Das Modul ist dazu da, Nachrichten aus dem Funknetzwerk, die von einem panStamp mit Modem-Sketch auf einem panStick empfangen werden, FHEM zur Verfügung zu stellen und umgekehrt. Alle eintreffenden SWAP-Pakete werden direkt an FHEM durchgereicht und im SWAP-Modul verarbeitet.

Im moduleigenen Artikel ist die Einrichtung des IO-Devices innerhalb von FHEM beschrieben.

Ebene 2: 34_SWAP.pm

Das Modul implementiert das SWAP Protokoll das zwischen den panStamps gesprochen wird. Darüber werden die auf den entsprechenden Boards/Platinen steckenden panStamp innerhalb von FHEM als TYPE SWAP_<ProductCode> definiert.

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. Für diese werden hier die allgemeinen Grundfunktionen beschrieben, die bei jedem SWAP-Device funktionieren. Die spezifischen Kommandos und Attribute, die durch die 3. Modulebene in Abhängigkeit des ProductCode zur Verfügung stehen, werden in den Wiki-Artikeln der jeweiligen Module beschrieben.

Um die Verwirrung komplett zu machen, wird im Forum meistens von "panStamps" gesprochen, obwohl es eigentlich SWAP-Devices sind.

Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm

RGB LED Driver Board

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 Aktoren 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.

Device Definition Files

Ein XML File was die Ein- und Ausgänge der panStamps beschreibt. Durch diese Datei wird dem FHEM-Modul mitgeteilt wie die Readings zu benennen sind, welche Werte die Readings haben können und ob die Readings/Register nur ausgelesen werden dürfen, oder auch beschrieben werden können. Im Wiki des Herstellers ist der Aufbau des Device Definition Files beschrieben. Wenn für einen End Point eine Unit angegeben ist, mit entsprechendem Faktor, dann erstellt das SWAP-Modul automatisch ein passendes userReadings mit der angegebenen Umrechnung.

panStamps konfigurieren und in Betrieb nehmen

Die Inbetriebnahme ist grundsätzlich in die Einrichtung des IO-Devices und die Einrichtung des entfernten Hardwaremoduls (Sensor/Aktuator) zu unterscheiden.

Auf die Einrichtung des IO-Devices ist hier bereits verwiesen.

Für die Einrichtung des entfernten Hardwaremoduls müssen im Groben folgende Schritte erfolgen:

  1. Vorbereiten einer Entwicklungsumgebung, kompilieren und hochladen der Firmware
  2. Aufstecken des programmierten panStamps auf das Board
  3. Mit Strom versorgen und von Autocreate einrichten lassen
  4. Attribute, Namen, Userreading des neuen SWAP-Device nach Bedarf anpassen

während der Einrichtung zu berücksichtigen

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 panStamp-Hardware im Power-Down-Modus werden diese Kommandos in eine Warteschlange gestellt und übertragen, sobald die panStamp-Hardware ihre 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 FF automatisch auf die erste freie Adresse im Bereich F0-FE 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ützt) wird das Default Sendeintervall von FFFF zu 0384 (900 Sekunden) geändert. Es gibt mit bestimmten panStamp lib Versionen das Problem, dass ein Wert von FFFF in Systemregister 0A 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 entfernt werden und der panStamp muss noch mal geflasht werden. Ansonsten wird die Adresse bei jedem Start erneut auf 5555 gesetzt.

Beispiel für Kurzentschlossene anhand der Einrichtung für das RGB-Board

  • Ein panStamp-Hardwaremodul wird in einen panStick gesteckt und der panStick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp-Hardwaremodul 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 das panStamp-Hardwaremodul hochgeladen.
  • Das programmierte panStamp-Hardwaremodul, aus dem panStick, in das panStamp_RGBWW_Board stecken.
  • Ein panStamp-Hardwaremodul mit Modem-Sketch in den panStick stecken und an den FHEM-Host stecken.
  • IO-Device unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.
  • panStamp_RGBWW_Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, das SWAP-Device automatisch eingerichtet werden.
  • SWAP-Device in FHEM an Gegebenheiten anpassen.

Anwendungsbeispiele

Es gibt bereits selbst entwickelte Hardware und Software auf Basis der panStamp Hardware und dem SWAP Protokoll:

Bekannte Probleme

  • Beim Systemstart werden einige Perl-Warnings ins Log geschrieben, die aber die Funktion der Module nicht beeinträchtigen.
  • Beim Systemstart wird eine SWAP-Broadcast Nachricht verschickt, die von allen empfangsbereiten panStamps beantwortet wird. Dieses führt bei häufig schnell bei kurz aufeinanderfolgenden Systemstarts zur Überschreitung des Transmit Limits im Rahmen der 1%-Regel für das verwendete Frequenzband.

Weitere Troubleshooting Hinweise finden sich hier

Weblinks

Abgerufen von „http://wiki.fhem.de/w/index.php?title=PanStamp&oldid=29278“