Diskussion:PanStamp: Unterschied zwischen den Versionen

Aus FHEMWiki
(Vorschlag für eine Neufassung des Artikels)
 
(Umstellung Kapitel 4.1-4.3 zur Vorbereitung, Abtrennung der spezifischen Anwendungen)
Zeile 365: Zeile 365:


Diese Abhängigkeit beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
Diese Abhängigkeit beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.
==== Installation des Pansticks ====
Für die Einrichtung des Pansticks innerhalb des OS siehe [[panstamp#unter Linux|Installation Panstick]]
Innerhalb FHEM wird der Panstick folgendermaßen eingerichtet
<pre>
define panStick panStamp /dev/ttyUSBx@38400
</pre>
Die Device Paramter funktionieren genau so wie beim CUL, B547 ist die Default Netz ID. Diese am Besten erst mal so lassen.
Ist der Panstick ersteinmal eingerichtet und meldet "Initialized", kann über das panStick device kann direkt eine raw Message abgesetzt werden. Diese ist zur Zeit eigentlich immer eine SWAP Nachricht wie z.b.
<pre>
set panStick raw 00010000010000
</pre>
Als broadcast an alle, damit sie ihren product code 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.
; 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.


==== Pfade innerhalb der FHEM Installation ====
==== Pfade innerhalb der FHEM Installation ====
Zeile 402: Zeile 382:
=== Verwendung innerhalb FHEM ===
=== Verwendung innerhalb FHEM ===


Sobald ein SWAP Device mit dem productCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden:  
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".
get <device> regList
 
get <device> regListALL
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.
 
==== Panstick ====
 
===== 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 =====


Außerdem können einzelne Register abgefragt und gesetzt werden:
* discover?
set <device> regGet <ID>
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.
set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.


Des weiteren kann veranlasst werden, die Werte aller Register zu senden:
* 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>
<pre>
set <device> statusRequest
set panStick raw 00010000010000
</pre>
</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.


Alle empfangen SWAP Nachrichten werden in readings im jeweiligen Device angezeigt.
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.
 
==== SWAP_<ProductCode> ====
 
Alle empfangen SWAP Nachrichten werden in internals/readings im jeweiligen Device angezeigt.
 
===== Definition =====


==== Adressierung ====
'''Info: Das SWAP Modul unterstützt autocreate. Bei der Inbetriebnahme sollte autocreate aktiviert sein, da dies die Einrichtung deutlich vereinfacht.'''
'''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 client panStamps per autocreate angelegt werden, sobald sie das erste mal senden. Z.b. nach dem Einschalten oder nach einem Reset.
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.  
Normalerweise werden beim autocreate alle Werte abgefragt und angezeigt. Das geht normalerweise ohne jedes Zutun.  
Zeile 427: Zeile 434:
Panstick rein -> broadcast -> discovery -> anlegen.  
Panstick rein -> broadcast -> discovery -> anlegen.  


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


Alle panStamps durchlaufen beim Starten eine bestmmte Einschaltsequenz. Sie melden sich mit ihrem productcode.
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.


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.  


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.
Wer mehrere devices hat, sollte jedem nach dem Anlegen mit  
 
Wer mehrere devices hat sollte jedem nach dem Anlegen mit  
<pre>
<pre>
  set <device> regSet 09 <device adresse als 2 stellige hex zahl>  
  set <device> regSet 09 <device adresse als 2 stellige hex zahl>  
</pre>
</pre>
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden. Das fhem device sollte danach auch automatisch anrepasst worden sein [http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261].
eine eigene id zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden. Die Definition in FHEM sollte danach auch automatisch anrepasst worden sein [http://forum.fhem.de/index.php?topic=12487.msg87261#msg87261]. Die Sie erhalten dadurch eine eindeutige Device-Adresse (ungleich FF und grösser 01).
 
Die ID ist die device Addresse und bei einem frisch geflashten panStamp in der Regel FF. Man sollte also Einen nach dem Anderen in Betrieb nehmen, sonst haben mehrere die gleiche Addresse und das gibt Konflikte.


Alternativ kann man sie von Hand anlegen mit  
Alternativ kann man sie von Hand anlegen mit  
Zeile 447: Zeile 450:
define <device> SWAP <ID>
define <device> SWAP <ID>
</pre>
</pre>
Bis allerdings der Productcode nicht per Attribut hinterlegt ist, funktionieren selbstverständlich nur die grundlegenden Funktionen bis zur 2. Modulebene. Wird beim autocreate der Productcode nicht erkannt, wird das Modul als Type "SWAP" angelegt.
===== set =====


Wird der Productcode nicht automatisch erkannt, stehen auch nur die Standardbefehle des panStamps zur Verfügung. Dann hilft es den Produktcode als Attribut vorzugeben.
Ist ein SWAP-Device definiert, können einzelne Register abgefragt und gesetzt werden:
set <device> regGet <ID>
set <device> regSet <ID> <value>
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]
 
Des weiteren kann veranlasst werden, die Werte aller Register zu senden:
<pre>
<pre>
attr <device> ProductCode 0000002200000003
set <device> statusRequest
</pre>
</pre>


==== Intervall (nur automatisch bei sketch mit powerdown) ====
===== get =====
 
Ist ein SWAP-Device definiert, können die Userregister bzw. alle Register aufgelistet werden:
get <device> regList
get <device> regListALL


Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist.
===== Attribute =====
{{Link2Forum|Topic=12487 |Message=89205}}
[http://forum.fhem.de/index.php/topic,12487.msg89205.html#msg89205]


{{Link2Forum|Topic=13890 |Message=157125}}
Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung. Dann hilft es den Produktcode als Attribut vorzugeben, z.B. für einen RGB-Sktech:
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]
<pre>
attr <device> ProductCode 0000002200000003
</pre>


==== Inbetriebnahme von batterie betriebene Panstamps ====
==== Intervall bei Sketch mit power down / batterie betriebene Panstamps ====


Devices mit power down mode durchlaufden dann 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 jetzt schlafen und wachen regelmässig auf um ihre Werte zu senden.
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.  
Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.  


Bei batteriebetriebenen Sensoren sollte auch das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
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>
<pre> set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> </pre>
Zeile 473: Zeile 491:
[http://forum.fhem.de/index.php?topic=12487.msg87409#msg87409]
[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 von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert.
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.
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
Zur Abhilfe kann im sketch in setup() ganz am Anfang  ein

Version vom 3. Mai 2015, 13:01 Uhr


Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


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 Thema: panStamp support und 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.



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
Ersteller Andre / justme1968
Hersteller 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

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

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:

  1. 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.
  2. 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.

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.

Software

Simple Wireless Abstract Protocol (SWAP)

Zur Kommunikation in einem panStamp Netzwerk dient das 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. 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".


Modem-Sketch

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.

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.

Module und Description File

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. Beitrag [1]

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
Readings

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.

set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>

Beitrag [2]

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.

Beitrag [3]

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.

RGB LED Driver Board
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.


Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

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

Resultat eines stateFormat

Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:

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

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

Systemübersicht

Zum besseren Verständnis der Begrifflichkeiten und Zusammenhänge ist hier eine Systemübersicht dargestellt.

panStamp Systemübersicht


Beitrag [4]

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

Schritte der Inbetriebnahme

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

unter Windows

Installation Panstick

Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.

  1. Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.
  2. Treiber von der offiziellen Homepage herunterladen und installieren [[5]]. 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 [[6]].

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 [[7]], 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 [[8]].
  • Für bestimmte Sketches müssen noch die entsprechenden Libs hinzugefügt werden (siehe 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 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. [[9]]

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.

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.

Beitrag [10]

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

sudo chown root:dialout ttyUSBx

Damit wird der "Besitz" festgelegt.

sudo chmod a+rw /dev/ttyUSBx

Hiermit werden die Berechtigungen gesetzt.

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: [[11]] [[12]] 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 Beitrag [13]

INO

Der RGB-Sketches wurde mit Hilfe des Tools INO entwickelt. Beitrag [14]

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. Beitrag [15]

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 [16] bzw. lauten für den AVR

##############################################################

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

##############################################################

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 [17].

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

Beitrag [18]

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 [[19]].

Was überlebt das Flaschen

Bestimmte Konfigurationen überstehen das Flashen, dieses sind zumindest Adresse und Intervall, die nicht neu gesetzt werden müssen [20].

EEPROM löschen

Das EEPROM lässt sich komplett löschen, indem man in der setup() dieses hier einträgt [21].

eepromToFactoryDefaults()

Integration in FHEM

FHEM Voraussetzungen

Für den Betrieb ist XML:Simple notwendig, dass bei Bedarf folgendermaßen nachinstalliert werden kann [22].

sudo apt-get install libxml-simple-perl

Diese Abhängigkeit beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.

Pfade innerhalb der FHEM Installation

Die Module befinden sich wie gewohnt im Installationsverzeichnis unter ./FHEM. Das entsprechende Device Description File liegt unter ./FHEM/lib/SWAP wie hier beschrieben [23].

Register

Jeder panStamp stellt elf Systemregister (00-0A) [24] 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.

Verwendung innerhalb FHEM

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.

Panstick

Definition

Das Device "Panstick" wird derzeit (01.05.2015) nicht durch autocreate angelegt. Daher muss er manuell entsprechend folgendem Befehl angelegt werden:

define panStick panStamp /dev/ttyUSBx@38400

Die Schnittstelle muss entsprechend der Installation des Pansticks anzupassen werden. Für die Einrichtung des Pansticks innerhalb des OS siehe 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 [25] und hier [26] 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.

set panStick raw 00010000010000

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.

SWAP_<ProductCode>

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

Definition

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 FF automatisch auf die erste freie Adresse im Bereich F0-FE 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 Definition in FHEM sollte danach auch automatisch anrepasst worden sein [27]. Die Sie erhalten dadurch eine eindeutige Device-Adresse (ungleich FF und grösser 01).

Alternativ kann man sie von Hand anlegen mit

define <device> SWAP <ID>

Bis allerdings der Productcode nicht per Attribut hinterlegt ist, funktionieren selbstverständlich nur die grundlegenden Funktionen bis zur 2. Modulebene. Wird beim autocreate der Productcode nicht erkannt, wird das Modul als Type "SWAP" angelegt.

set

Ist ein SWAP-Device definiert, können einzelne Register abgefragt und gesetzt werden:

set <device> regGet <ID>
set <device> regSet <ID> <value>

Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

Beitrag [28]

Des weiteren kann veranlasst werden, die Werte aller Register zu senden:

set <device> statusRequest
get

Ist ein SWAP-Device definiert, können die Userregister bzw. alle Register aufgelistet werden:

get <device> regList
get <device> regListALL
Attribute

Wird der Productcode bei der Definition nicht gesetzt, stehen auch nur die Standardbefehle bei zur 2. Modulebene zur Verfügung. Dann hilft es den Produktcode als Attribut vorzugeben, z.B. für einen RGB-Sktech:

attr <device> ProductCode 0000002200000003

Intervall bei Sketch mit power down / batterie betriebene Panstamps

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.

Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:

 set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> 

Beitrag [29]

Für batteriebetriebene Devices (genauer: Devices die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von FFFF zu 0384 (900 Sekunden = 15 Minuten) geändert.

Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device description file true ist. Beitrag [30]

Beitrag [31]

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. Beitrag [32]

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. Beitrag [33]

Im Log sollte etwas in dieser Art auftauchen:

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

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). Beitrag [34] Beitrag [35]

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. Thema [36]

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. Beitrag [37]

register 0F is not known

Beitrag [38]

Komplette Übersicht eines Device

list <device>

Beitrag [39]

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

Beitrag [40]

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.

Beitrag [41]

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.

Beitrag [42]

Adresse manuell setzen

Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen. Beitrag [43]

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.

Beitrag [44]

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

Factory Defaults

Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:

eepromToFactoryDefaults()

Beitrag [45]

Status LED

Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert. Beitrag [46]

Explizite Anwendungen

RGB-Board

Allgemeines

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 Forenthread vorgestellt. Die Hardware für das Board wird hier im FHEM Forum vorgestellt und ein Prototyp ist hier zu sehen.

Die Projektseite zur Hardware findet sich hier. Eine Version 2 des Boards in geplant.

Eine Übersicht über die derzeit vorhandene Funktionalität (stand 01.05.2015): Beitrag [47]

  • 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 konfiguriert werden.

weitrere Screenshots
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. Beitrag [48]

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

(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 [[49]] (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 [[50]] und speichert sie ebenfalls in einem passenden Unterordner von libraries.
  • Die Dateien der DMX Lib kopiert man von hier [[51]] und speichert sie ein weiteres Mal in einem weiteren Unterordner von libraries. Weitere Informationen zur Verwendung von Arduino Libraties finden sich hier [[52]]. 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 [53]).

Für das kompilieren mit INO siehe hier.

Link zum sketch

Die aktuelle Version des RGB-Driver Sketches findet sich auf sourceforge. Beitrag [54]

Kompillierte hex version

Eine kompiliertes HEX-File für drei (vier) Kanäle plus IR-Empfang und DMX ist hier im Forum zu finden: Beitrag [55]

HEX-File ohne IR und DMX

Eine kompiliertes HEX-File ohne IR-Empfang und DMX ist hier im Forum zu finden: Beitrag [56]

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. Beitrag [57] Den Sketch entsprechend den Bedürfnissen in den config.h die nicht benötigten Zeilen mit "//" auskommentieren bzw. anpassen. Für die Konfigurationen siehe 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
#define ENABLE_DMX

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.


Temperatur- und Luftfeuchtigkeitssensor
#define HAS_SENSOR

Dieses ermöglicht die Nutzung eines DHT22 Sensors zur Auswerung 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

void IRrecv::disableIRIn() 
{
TIMER_DISABLE_INTR;
}

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. Beitrag [58]

Zusammenhänge der Konfiguration

Die Zusammenhänge der Konfiguration sind hier beschrieben Beitrag [59]

Bedienung in FHEMWEB

Komandos
Definition

Der Panstick wird entsprechend folgendem Befehlt angelegt:

define panStick panStamp /dev/ttyUSBx@38400

Die Schnittstelle ist entsprechend Installation des 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

http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923 EIn register verändern http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679

Register umrechnung TBC

http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790

Poweronstate TBC

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

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

http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112

Fadeto TBC

http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406 Default fade time http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572

Eigenschaften des fade TBC

http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644

4.,5. 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

Extra kanäle TBC

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

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.

sonstiges

Alternativer Fade per Patch

Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt: Beitrag [60]

Der Patch ist nicht eingecheckt.

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.

Beitrag [61]

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.

Bodenfeuchtesensor

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 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")}
Bodenfeuchte
Vegetronix Bodenfeuchtesensor an panStamp
Vegetronix Bodenfeuchtesensor an panStamp

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.

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. Beitrag [62]

Weblinks