PanStamp: Unterschied zwischen den Versionen

Aus FHEMWiki
 
(84 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
}}


= panStamps =
Dieser Artikel, gedacht als Eingangsartikel zu dem Thema, beschreibt die Zusammenhänge rund um die Hardwaremodule „panStamp“.
PanStamps [http://www.panstamp.com/home)] sind kleine Arduinos mit On-Board CC1101 Funkmodul. Mit ihnen lassen sich eigene Sensoren und Aktoren drahtlos an FHEM anbinden. Sie lassen sich genau so wie Arduinos z.B. über die Ardunio IDE oder mit dem ino kommandozeilen binary programmieren.


Der panStamp software Stack unterstützt einen stromsparenden Power-Down- oder Sleep- Mode für batteriebetriebene Sensoren aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".
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].


Zur Kommunikation in einem panStamp Netzwerk dient das SWAP Protokoll [http://code.google.com/p/panstamp/wiki/SWAP].
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.  


= SWAP =
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".
Alle Kommunikation im SWAP Protokoll ist Register basiert und erfolgt mit Nachrichten um diese Register abzfuagen, zu setzen und deren Inhalt zu senden. Alle Register lassen sich lesen, manche auch beschreiben.


Jeder panStamp stellt 11 System Register (00-0A) [http://code.google.com/p/panstamp/wiki/SWAPregisters] und beliebig viele Sketch abängige User Register (0B-)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten User Register 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.
Zur Kommunikation in einem panStamp Netzwerk dient das ''Simple Wireless Abstract Protocol'' ([https://github.com/panStamp/panstamp/wiki/Simple%20Wireless%20Abstract%20Protocol SWAP]).


In den System Registern steht z.b. der productCode, die Device Adresse und das Übtertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert so das die Werte auch beim einem Neustart nicht verloren gehen. Meim aller ersten starten 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).
== 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.


Die System-Register werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.
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.  


Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als aller erstes seinen productCode. Batteriebetiebene panStamps warten jetzt 3 sekunden auf konfigurations Kommandos. Danach werden bestimmte System-Register und aktuelle Messwerte gesendet.
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.


= FHEM integration =
Eine Übersicht über alle sich mit dem Thema panStamp befassenden Artikel befindet sich [[:Kategorie:PanStamp|hier]].
== panStamp ==
Als Schnittstelle zwischen FHEM und einem panStamp Netzwerk dient entweder ein panStick mit aufgestecktem panStamp an einem USB port 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>


Dieses panStamp Device versucht dann als erstes alle panStamps im Netz zu finden und per autocreate anzulegen.
== 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:


==SWAP==
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.
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 'nakten' Register werten 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.


(Ein panShield ersetzt "USB -> PanStick" durch "IO's am Rpi -> panShield").


Hier Beispielhaft anhand eines BMP085 Temperatur und Luftdruck Sensors dargestellt:
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.


<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>
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.
[[Datei:SWAP_ 0000000100000005-detail.png]]
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.


Aus diesen readings kann dann mit stateFormat die gewünschte darstellung für die Raumübersicht erzeugt werden:
== panStamp Hardware ==


<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>
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.  
[[Datei:SWAP_ 0000000100000005.png]]


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


Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde kann man sich die User Register bzw. alle Register auflisten und einzelne register abfragen und setzen:
==== panStick ====
<pre>get <device> regList</pre>
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:
<pre>get <device> regListALL</pre>
# 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.
<pre>set <device> regGet <ID></pre>
# 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.
<pre>set <device> regSet <ID> <value></pre>


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.


===Neue panStamps in Betrieb nehmen===
==== panShield ====
Neue panStamps sollten nur einer nach dem anderen in Betrieb genommen werden da sie zuerst mit einer eindeutigen Netzwerk-ID (ungleich FF und grösser 01) versehen werden müssen. Bei batteriebetriebenen Sensoren sollte man auch das Sendeintervall auf einen sinnvollen wert setzen:
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.
<pre>set <device> regSet 08 <netzwerk id als 2 stellige hex zahl></pre>
<pre>set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl></pre>


Für Devices im Power-Down-Mode 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.
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.


==SWAP_XXXXXXXXXXXXXXXX==
=== panStamp ===
Besonders bei Aktoren ist eine engere FHEM Integration sinnvoll um FHEM Konzepte wie on/off/on-for-timer direkt abzubilden und nicht mehr nur auf die register Ebene und regSet und regGet Kommandos beschränkt zu sein.
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 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.
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!


===SWAP_0000002200000003===
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.
Ein FHEM modul für das modifizierte panStamp RGB LED Driver Board.  


Das Board unterstürzt RGBW LEDs und lässt sich per Infrarot Fernbedienung, DMX Controller (z.b. als unterputz Touch Pannel) und FHEM bedienen.
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.


Der Funktionsumfang wird hier [http://forum.fhem.de/index.php?t=msg&th=12487&goto=81923&rid=430#msg_81923] vorgestellt. Die Hardware für das Board wird hier  [http://forum.fhem.de/index.php?t=msg&th=13890&start=0&rid=430] im FHEM Forum vorgestellt und ein prototyp ist hier zu sehen [http://forum.fhem.de/index.php?t=msg&th=12487&goto=85777&rid=430#msg_85777].
=== 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.


[[Datei:SWAP_0000002200000003.png]]
== panStamp Sketch ==


<gallery>
=== Modem-Sketch ===
File:SWAP_0000002200000003-internal.png|InternalValues
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>.
File:SWAP_0000002200000003-readings.png|Readings
File:SWAP_0000002200000003-attributes.png|Attributes
</gallery>


[[Kategorie:Other Components]]
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]).
[[Kategorie:Hardware]]
 
=== 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. {{Link2Forum|Topic= 13890 |Message=121689 }}
 
=== 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 [[panStamp (Modul)|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 ===
[[Datei:SWAP_0000002200000003.png|thumb|rechts|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 [[#Anwendungsbeispiele|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 [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.
 
== 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 [[#Ebene 1: 34_panStamp.pm|hier]] bereits verwiesen.
 
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
 
=== 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 <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.
 
=== 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:
* [[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]]
 
== 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%25_Regel|1%-Regel]] für das verwendete Frequenzband.
 
Weitere Troubleshooting Hinweise finden sich [[SWAP#Trouble Shooting|hier]]
 
= Weblinks =
* [http://www.panstamp.com/home panStamp] panStamp Hersteller
 
[[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