SWAP: Unterschied zwischen den Versionen

Aus FHEMWiki
(Inhalt aus panStamp Diskussion übernommen)
K (Überflüssiges "SEITENTITEL" entfernt)
 
(13 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Baustelle}}
{{SEITENTITEL:SWAP}}
{{Infobox Modul
{{Infobox Modul
|ModPurpose=Modul zur allgemeinen Ansteuerung sämtlicher PanStamp Boards.
|ModPurpose=Modul zur generischen Ansteuerung sämtlicher panStamp Boards.
|ModType=d
|ModType=d
|ModCmdRef=SWAP
|ModCmdRef=SWAP
Zeile 12: Zeile 9:
}}
}}


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


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


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


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


Alle low Level Dinge wie Register ID oder Register Wert können mit '''hex Werten'' direkt angepasst werden.
set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
set <device> regSet 08 <Netzwerk ID als 2 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87436 }}
{{Link2Forum|Topic=12487 |Message=87436 }}
[http://forum.fhem.de/index.php?topic=12487.msg87436#msg87436]


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


{{Link2Forum|Topic=12487 |Message=78502 }}
[http://forum.fhem.de/index.php/topic=12487.msg78502#msg78502]
=== Define ===
=== Define ===
'''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 [[panStamp#panStick/Shield|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.


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.
panStick rein -> broadcast -> discovery -> anlegen.  
 
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.  
Bei Devices mit power down Mode erfolgt dieses das erste Mal wenn sie Strom haben.  


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


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


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


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


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


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


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


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


=== set ===
=== set ===
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:
* regGet <reg>
* regGet <reg>
Fragt den Wert des Registers mit der id <reg> ab. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
Fragt den Wert des Registers mit der ID <reg> ab. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.
{{Link2Forum|Topic= 12487 |Message=87679 }}
{{Link2Forum|Topic= 12487 |Message=87679 }}
[http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679]


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


* regSet <reg>.<ep> <data>
* regSet <reg>.<ep> <data>
Zeile 107: Zeile 86:


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


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


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


Zeile 126: Zeile 105:


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


* products
* products
Zeile 132: Zeile 111:


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


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


* createUnknownReadings
* createUnknownReadings
Zeile 142: Zeile 120:


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


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


=== Device Description File ===
=== Device Definition 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.  
Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch ''menschenlesbare'' readings der Sensorwerte erzeugen.  
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device.
 
Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben {{Link2Forum|Topic=12487|Message=86257}}.


Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:
Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:


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


[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
[[Datei:SWAP_ 0000000100000005.png|mini|hochkant=2.5|Resultat eines stateFormat]]
Aus diesen readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:
Aus diesen Readings kann dann mit stateFormat die gewünschte Darstellung für die Raumübersicht erzeugt werden:
 
<code>
attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}
</code>
 
Ein weiteres Beispiel ist das Definition File für das RGB-Board rgbdriver.xml.
 
=== SWAP Register ===
Jeder panStamp stellt elf Systemregister (<code>00</code>-<code>0A</code>) [https://github.com/panStamp/panstamp/wiki/Standard-SWAP-registers] und beliebig viele sketchabängige Userregister (<code>0B</code> - <code>xx</code>)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in ''Device Definition Files''. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus ''Hersteller''- und ''Produkt-Id'' gebildet wird.
 
In den Systemregistern stehen z.B. der ProductCode, die Deviceadresse und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert, so dass die Werte auch bei einem Neustart nicht verlorengehen. Beim ersten Starten eines panStamp ist das EEPROM mit <code>FF</code> initialisiert und alle konfigurierbaren Register haben diesen Wert, also z.B. die Adresse <code>FF</code> und das Intervall <code>FFFF</code> (zwischen 18 und 19 Stunden).


<code>attr temppress stateFormat {sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C ".sprintf("%.1f",ReadingsVal($name,"pressureNN",0))."mbar"}</code>
Die Systemregister werden in der Device Detailansicht bei den InternalValues im oberen Bereich angezeigt und die User-Register als reading im unteren Bereich.


Ein weiteres Beispiel ist das Description File für das RGB-Board rgbdriver.xml.
Jeder panStamp durchläuft beim Start eine definierte Einschaltsequenz und überträgt als erstes seinen ProductCode. Batteriebetriebene panStamps warten anschließend drei Sekunden auf Konfigurationskommandos. Danach werden bestimmte Systemregister und aktuelle Messwerte gesendet.


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


und einzelne Register abgefragt und gesetzt werden:
=== Register auslesen oder setzen ===
Einzelne Register können abgefragt werden mit
  set <device> regGet <ID>
  set <device> regGet <ID>
oder auch gesetzt werden durch
  set <device> regSet <ID> <value>
  set <device> regSet <ID> <value>
Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.
Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden.
 
=== Intervall bei Sketch mit power down / batterie betriebene panStamps ===
panStamp Hardware mit power down Mode durchlaufen während des Booten (beim Einschalten oder bei einem Reset) eine 3 Sekunden Schleife und warten auf SWAP-Kommandos, die z.B. Register für das Sendeintervall oder sonstige Konfigurationen ändern. Nach dieser Zeit wird die normale Loop Schleife im Arduino Sketch gestartet. Normaler Weise werden dann die Register mit den Sensorwerten an FHEM gesendet. Power down Devices gehen danach schlafen (power down Modus mit extrem niedrigem Stromverbrauch) und wachen regelmäßig auf (TX_INTERVAL aus dem Systemregister) um die Sensoren auszulesen und die Werte wieder an FHEM zu senden. Das Sendeintervall betrifft nur das Senden der Sensorwerte. Normalerweise empfängt das panStamp Modul in diesem Modus keine Befehle mehr. Das passiert nur einmalig nach einem Reset. Je nach Sketch kann das natürlich variieren und anders programmiert sein!
 
Nachrichten an eine panStamp-Hardware im power-down-state werden in FHEM gepuffert (siehe INTERNAL SWAP_CMDsPending) und dann an die panStamp-Hardware geschickt, sobald dieses sich im SYNC Status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.
 
Bei batteriebetriebenen Sensoren sollte das Sendeintervall auf einen sinnvollen Wert gesetzt werden:
set <device> regSet 0A <Intervall in Sekunden als 4 stellige hex zahl>
{{Link2Forum|Topic=12487 |Message=87409}}
 
Für batteriebetriebene panStamp-Module (genauer: Module die den Power-Down-Modus unterstützen) wird das Default Sendeintervall bei der Einrichtung automatisch von <code>FFFF</code> zu <code>0384</code> (900 Sekunden = 15 Minuten) geändert. Das Intervall wird nur automatisch gesetzt, wenn pwrdownmode im device definition file true ist. {{Link2Forum|Topic=12487 |Message=89205}}
 
 
Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von <code>FFFF</code> im Systemregister <code>0A</code> zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im [[SWAP]] Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host Systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass FHEM mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum Senden kommt. Zur Abhilfe kann im Sketch in setup() ganz am Anfang  ein
  EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
  EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);
eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf <code>0x5555</code> (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.
 
=== Device Adresse automatisch setzen ===
Erkennt das SWAP Modul eine panStamp-Hardware mit der Adresse <code>0xFF</code> wird automatisch eine neue Adresse durch das [[SWAP] Modul vergeben. Die automatisch vergebenen Adressen sind im Bereich <code>0xF0 - 0xFE</code>. Das soll das Inbetriebnehmen von mehreren panStamp-Hardwaremodulen gleichzeitig erleichtern. Der automatisch vergeben Adressbereich ist begrenzt und sollte nur temporär verwendet werden. Nach der Inbetriebnahme sollte den panStamp Modulen eine individuelle, lokal passende Adresse geändert werden. {{Link2Forum|Topic=12487 |Message=87919}}
Automatisch gesetzte Werte sollten danach manuell auf die jeweilige Installation angepasst werden.
{{Link2Forum|Topic=12487 |Message=87859}}
 
Im Log sollte etwas in dieser Art auftauchen:
<pre>
2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)
 
2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
</pre>
 
=== Registerinhalt von hex auf Dezimal umrechnen  ===
Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fällen werden diese umgerechnet werden in Dezimalzahlen.
Hierzu kann die Perlfunktion hex() verwendet werden.
Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus:
{hex("FA")}
{hex("0xFA")}
 
=== Beispiel: panStamp soilmoisture Sketch in FHEM einbinden ===
Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.
 
Ein Artikel über ein selbst entwickeltes panStamp Batterieboard zum Anschluss von Analogsensoren/1Wire und Solarversorgung ist hier [[Bodenfeuchtesensor]] beschrieben. Die Weiterentwicklung zum Umweltsensor ist hier [[panStamp_Umweltsensor]] beschrieben.
 
Eine für einen Vegetronix Sensor angepasste Version kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Das Übertragungsinterval ist wie üblich über das Register <code>0A</code> konfigurierbar. Der Sensor wird an GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsinterval nach 12 Monaten Laufzeit die Batteriespannung von 1.55V auf 1.4V abfällt. Das würde bedeuten, dass eine Batterie im Batterieboard mindestens eine Laufzeit von drei Jahren haben sollte.
 
<code>set <MyBodenfeuchte> stateFormat VWC_A%</code>
 
<code>
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)}, VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))}, voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}
</code>
 
[[Datei:SWAP_ soilmositure-plot.jpg|mini|x100px|Bodenfeuchte]]
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix1.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
<div class="tright" style="clear:none">[[Datei:panstamp_vegetronix2.jpg|mini|ohne|x130px|Vegetronix Bodenfeuchtesensor an panStamp]]</div>
 
Mit einem entsprechend erweiterten Sketch lassen sich auch mehrere Sensoren an einem panStamp auslesen.
 
Die folgenden Bilder zeigen eine panStamp/Vegetronix Außeneinheit im IP65-Gehäuse. Dieser Aufbau wird ganzjährig den Witterungseinflüssen ausgesetzt. Die auf den Stab aufgesetzte Antenne muss nicht verwendet werden, bei kürzeren Funkstrecken ist eine innenliegende Drahtantenne ausreichend. Bitte in FHEM den RSSI- und LQI-Wert sowie die Gleichmäßigkeit des Empfangens der 5 Minuten Sendeintervalle dementsprechend beobachten.


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


Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs.
{{Link2Forum|Topic=34474.0}}
{{Link2Forum|Topic=34474.0}}
[http://forum.fhem.de/index.php?topic=34474.0]


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


Eine weitere Möglichkeit:
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.
Die Fehlermeldung kommt immer wenn FHEM nicht weiß welche Firmware auf der panStamp-Hardware ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert.
{{Link2Forum|Topic=13890 |Message=122414}}  
{{Link2Forum|Topic=13890 |Message=122414}}  
[http://forum.fhem.de/index.php/topic,13890.msg122414.html#msg122414]


=== register 0F is not known ===
=== register 0F is not known ===
{{Link2Forum|Topic=12487 |Message=84257}}
{{Link2Forum|Topic=12487 |Message=84257}}
[http://forum.fhem.de/index.php/topic,12487.msg84257.html#msg84257]


=== Komplette Übersicht eines Device ===
=== Komplette Übersicht eines Device ===
  list <device>
  list <device>
{{Link2Forum|Topic=13890 |Message=201467}}
{{Link2Forum|Topic=13890 |Message=201467}}
[http://forum.fhem.de/index.php?topic=13890.msg201467#msg201467]
=== fehlender oder falsche Productcode ===


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


{{Link2Forum|Topic=13890 |Message=201910}}
{{Link2Forum|Topic=13890 |Message=201910}}
[http://forum.fhem.de/index.php?topic=13890.msg201910#msg201910]


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


{{Link2Forum|Topic=13890 |Message=201939}}
{{Link2Forum|Topic=13890 |Message=201939}}
[http://forum.fhem.de/index.php?topic=13890.msg201939#msg201939]


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


=== Adresse manuell setzen ===
=== Adresse manuell setzen ===
Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
Um die Adresse manuell bereits in den Sketch einzubauen kann man wie hier beschrieben vorgehen.
{{Link2Forum|Topic=13890 |Message=122347}}
{{Link2Forum|Topic=13890 |Message=122347}}
[http://forum.fhem.de/index.php/topic,13890.msg122347.html#msg122347]


=== Undefined subroutine &main::XMLin ===
=== Undefined subroutine &main::XMLin ===
Zeile 246: Zeile 282:


Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
Es fehlt XML::Simple, was folgendermaßen installiert werden kann:
<pre>
sudo apt-get install libxml-simple-perl
sudo apt-get install libxml-simple-perl
</pre>
=== Panstamp antwortet nicht/EEprom to factory defaults ===
Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein  eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen sketch flashen.


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


=== Factory Defaults ===
=== Factory Defaults ===
 
Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die <code>setup()</code> Routine einfügen:
Um einen panStamp auf den Auslieferungszustand zurückzusetzen, muss man beim Sketch folgendes in die setup() Routine einfügen:
eepromToFactoryDefaults()
<pre>
eepromToFactoryDefaults()
</pre>
{{Link2Forum|Topic=13890 |Message=157125}}
{{Link2Forum|Topic=13890 |Message=157125}}
[http://forum.fhem.de/index.php?topic=13890.msg157125#msg157125]


=== Status LED ===
=== Status LED ===
 
Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit <code>#define LED_DEBUG</code> mit "//" auskommentiert. {{Link2Forum|Topic=13890 |Message=164731}}
Die Status LED auf dem Board wird in der config.h deaktiviert, indem man die Zeit #define LED_DEBUG mit "//" auskommentiert.
{{Link2Forum|Topic=13890 |Message=164731}}
[http://forum.fhem.de/index.php/topic,13890.msg164731.html#msg164731]
 
 
 
 


== Links ==
== Links ==

Aktuelle Version vom 4. August 2017, 09:39 Uhr

SWAP
Zweck / Funktion
Modul zur generischen Ansteuerung sämtlicher panStamp Boards.
Allgemein
Typ Gerätemodul
Details
Dokumentation EN / DE
Modulname 34_SWAP.pm
Ersteller André/ justme1968 (Forum / Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!


SWAP ist das Basismodul für die Unterstützung der panStamp Baugruppen. 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. Für eine tiefgreifende FHEM Integration können weitere Module (wie z.B. SWAP_0000002200000003) vorhanden sein. Diese Module bauen, als 3. Ebene, auf das SWAP Modul (2. Ebene) auf und bedienen im backend ebenfalls die panStamp-Hardware über die Register. Der panStamp Software Stack unterstützt einen stromsparenden Power-Down- oder Sleep-Modus für batteriebetriebene Sensoren, aus dem diese dann nur zur eigentlichen Messung und Übertragung "aufwachen".

Voraussetzungen

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

sudo apt-get install libxml-simple-perl

Diese Abhängigkeit kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen. Das SWAP Modul greift auf das panStamp Modul zu, was vorher per define angelegt werden muss.

Anwendung

Readings

Bei SWAP geht alle Kommunikation über Register, dies sind unterschiedlich lange Werte die entweder nur gelesen oder gelesen und geschrieben werden können. Jeder panStamp stellt elf Systemregister (00-0A) [2] und beliebig viele, sketchabängige Userregister (0B-xx) [3] bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in Device Definition Files, die in .../FHEM/lib/SWAP zu finden sind. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus Hersteller- und Produkt-ID [4] gebildet wird. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device. In den Systemregistern steht z.B. der ProductCode, die Device Adresse im SWAP Protokoll und das Übertragungsintervall. Konfigurierbare Register werden im EEPROM gesichert und die Werte gehen auch beim Neustart nicht verloren. Beim aller ersten Starten ist das EEPROM mit FF initialisiert und alle konfigurierbaren Register haben diesen Wert. Also z.B. Adresse FF und Intervall FFFF (HEX in Sekunden, das wären dann zwischen 18 und 19 Stunden). Die Inhalte der Systemregister stehen als INTERNAL, im oberen Bereich der Detail Ansicht eines FHEM-Device, in FHEMWEB, die Userregister als Readings im unteren.

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

Alle low Level Dinge wie Register ID oder Register Wert können mit 'hex Werten direkt angepasst werden. 

set <device> regSet 0A <intervall in Sekunden als 4 stellige hex zahl>
set <device> regSet 08 <Netzwerk ID als 2 stellige hex zahl>

Beitrag

Das SWAP-Modul stellt unter anderem folgende grundlegende Funktionalitäten zur Verfügung

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

Define

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

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

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

Alle panStamps durchlaufen beim Starten eine bestimmte Einschaltsequenz. Sie melden sich mit ihrer ID und ihrem ProductCode. Die ID ist die SWAP Device Adresse und bei einem frisch geflashten panStamp in der Regel 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 Adresse und das gibt Konflikte.

Wer mehrere Devices hat, sollte jedem nach dem Anlegen mit 

set <device> regSet 09 <Device Adresse als 2 stellige hex zahl>

eine eigene ID zuweisen. Die landen auf dem panStamp im EEPROM und sind auch nach Neustart noch vorhanden.

Die anderen Adressen sind wie folgt belegt:

  • 00 ist die Broadcast-ID
  • 01 ist die ID des panStick am FHEM-System
  • FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt
  • F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.

Beitrag

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

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

Alternativ zum autocreate kann man ein Device auch von Hand anlegen mit 

define <device> SWAP <ID>

Bis allerdings der ProductCode nicht per Attribut hinterlegt ist, was bei autocreate ebenfalls automatisch passiert, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.

set

Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:

  • regGet <reg>

Fragt den Wert des Registers mit der ID <reg> ab. Für die Systemregister kann hierzu statt der Register ID auch der Registername (siehe regListAll) verwendet werden. Beitrag

  • regSet <reg>

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

  • regSet <reg>.<ep>

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

  • statusRequest

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

  • readDeviceXML

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

  • clearUnconfirmed

Löscht die Liste der unbestätigten Nachrichten.

  • flash [<productCode>|<firmwareFile>]

Initiiert das „over-the-air“ Firmware update, dass (derzeit) nur von panStamps NRG unterstützt wird.

    • ohne Parameter: Verwendet das SWAP_<current ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
    • <ProductCode>: Verwendet das SWAP_<ProductCode>.hex-File aus dem Verzeichnis ./FHEM/firmware.
    • <firmwareFile>: Verwendet ein <firmwareFile> als absoluten File-Namen des HEX-Files.

get

  • regList

Listet alle User-Register des SWAP-Device (Readings).

  • regListAll

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

  • listUnconfirmed

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

  • products

Gibt alle auf dem System bekannten Productcodes nebst Daten aus.

  • deviceXML

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

Attribute

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

  • createUnknownReadings

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

  • ProductCode

Legt den ProductCode eines SWAP-Device fest und liest dadurch das dazugehörige Device-Definition-XML-File ein. Erst wenn der ProductCode als Attribut vorgegeben wurde, z.B. für einen RGB-Sketch: 

attr <device> ProductCode 0000002200000003

kommen zu den allgemeinen FHEM set- und get-Kommandos des SWAP Modul die spezifischen der 3. Modulebene 35_SWAP_<productcode>.pm mit hinzu (Siehe z.B. SWAP_0000002200000003). Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

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

Device Definition File

Mit Hilfe der im jeweiligen Device Definition File hinterlegten Beschreibung werden hierzu automatisch userReadings angelegt (Wenn den Endpoints eine Unit mit Factor zugewiesen ist) die neben den reinen Registerwerten in hex auch menschenlesbare readings der Sensorwerte erzeugen. Damit dies funktioniert, muss das Attribut ProductCode korrekt gesetzt sein. Das geschieht normalerweise automatisch beim Anlegen des Device. Das entsprechende Device Definition File liegt unter ./FHEM/lib/SWAP wie hier beschrieben Beitrag.

Hier Beispielhaft anhand eines BMP085 Temperatur- und Luftdrucksensors dargestellt:

attr temp press 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 Definition File für das RGB-Board rgbdriver.xml.

SWAP Register

Jeder panStamp stellt elf Systemregister (00-0A) [5] und beliebig viele sketchabängige Userregister (0B - xx)bereit. Die Beschreibung der jeweils von einem Sketch bereitgestellten Userregister erfolgt in Device Definition Files. Die Identifikation der Art eines panStamp und die Zuordnung zu einem bestimmten Device Definition File erfolgt über den ProductCode der aus Hersteller- und Produkt-Id gebildet wird.

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

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

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

Anwendungsbeispiele

Übersicht der Register anzeigen

Sobald ein SWAP Device mit dem ProductCode korrekt angelegt wurde, können die Userregister bzw. alle Register aufgelistet werden: 

get <device> regList
get <device> regListALL

Register auslesen oder setzen

Einzelne Register können abgefragt werden mit 

set <device> regGet <ID>

oder auch gesetzt werden durch 

set <device> regSet <ID> <value>

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

Intervall bei Sketch mit power down / batterie betriebene panStamps

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

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

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

set <device> regSet 0A <Intervall in Sekunden als 4 stellige hex zahl>

Beitrag

Für batteriebetriebene panStamp-Module (genauer: Module 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 definition file true ist. Beitrag


Es gibt mit bestimmten panStamp lib Versionen das Problem das ein Wert von FFFF im Systemregister 0A zum Überlauf führt und der panStamp dann ununterbrochen sendet. Im SWAP Modul wird versucht das abzufangen. Das funktioniert auf manchen langsamen host Systemen (z.B. FritzBox) nicht, weil der panStamp so schnell sendet, dass FHEM mit dem Abarbeiten so beschäftigt und ausgelastet ist, dass es selber nicht zum Senden kommt. Zur Abhilfe kann im Sketch in setup() ganz am Anfang ein 

 EEPROM.write(EEPROM_TX_INTERVAL, 0x55);
 EEPROM.write(EEPROM_TX_INTERVAL+1, 0x55);

eingefügt werden. Den Sketch dann noch mal flashen. Wenn der panStamp mit diesem Sketch einmal durchgelaufen ist, können diese beiden Zeilen wieder entfernen und der panStamp noch mal geflasht werden. Damit wurde das Sendeintervall einmalig auf 0x5555 (0x5555 in Dezimal = 21.845 (Sekunden), entspricht 364 Minuten) gesetzt.

Device Adresse automatisch setzen

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

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

Registerinhalt von hex auf Dezimal umrechnen

Die Registerinhalte sind immer hexadezimale Zahlenwerte. In den meisten Fällen werden diese umgerechnet werden in Dezimalzahlen. Hierzu kann die Perlfunktion hex() verwendet werden. Beide Funktionsaufrufe geben in diesem Beispiel die Dezimalzahl 250 aus: 

{hex("FA")}
{hex("0xFA")}

Beispiel: panStamp soilmoisture Sketch in FHEM einbinden

Der panStamp soilmoisture Sketch aus dem examples Verzeichnis ist mit dem Standard SWAP Modul kompatibel.

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

Eine für einen Vegetronix Sensor angepasste Version kann aus dem FHEM-Repository heruntergeladen werden. Das Übertragungsinterval ist wie üblich über das Register 0A konfigurierbar. Der Sensor wird an GND, D7 für die Versorgungsspannung und A4 für den Messwert angeschlossen. Erfahrungen haben gezeigt, dass bei einem fünfminütigen Übertragungsinterval 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.

Trouble Shooting

value has to be 10 byte(s) in size

Es besteht die Möglichkeit, dass die Internals aus irgendeinem Grund nicht vollständig sind. Abhilfe in einem solchen Falle kann das Absetzen der folgenden beiden Befehlt schaffen 

set <device> statusRequest
set <device> readDeviceXML

Wenn das nicht zum Erfolg führt, hilft ggf. ein Löschen und neu setzen des ProductCode Attributs. Thema

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

Eine weitere Möglichkeit: Die Fehlermeldung kommt immer wenn FHEM nicht weiß welche Firmware auf der panStamp-Hardware ist. Das passiert wenn irgendetwas in der Kommunikation schief geht während FHEM initialisiert. Beitrag

register 0F is not known

Beitrag

Komplette Übersicht eines Device

list <device>

Beitrag

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

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

Funktion des Autocreate

Beim autocreate wird versucht ein Name für das Device zu vergeben, der zur nächsten freien Adresse passt. Während dieses Prozessen bleibt die Adresse erst mal trotzdem 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

Adresse manuell setzen

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

Undefined subroutine &main::XMLin

Erhält man diese Fehlermeldung 

Undefined subroutine &main::XMLin called at ./FHEM/34_SWAP.pm line 108.

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

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

panStamp antwortet nicht/EEprom to factory defaults

Wenn der panStamp nicht antwortet, kann es sein das die Adressen durcheinander gekommen sind. Dann musst man einmal in setup() ein eepromToFactoryDefaults() aufrufen und damit flashen. Wenn damit einmal gestartet wurde, die Zeile wieder entfernen und den normalen Sketch flashen. Beitrag

Factory Defaults

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

eepromToFactoryDefaults()

Beitrag

Status LED

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

Links

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