Diskussion:PanStamp: Unterschied zwischen den Versionen

Aktuelle Version vom 29. Januar 2019, 02:48 Uhr

~~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" (to be confirmed) gekennzeichnet.

Hallo, wie ist denn der Stand mit dem Artikel? Finde es schade, dass das gesammelte Know-how hier nur auf der Diskussionsseite zu finden ist. --TeeVau (Diskussion) 12:07, 15. Jul. 2015 (CEST)

Hallo TeeVau, danke, dass Du den Faden aufgenommen hattest. Ich habe die Struktur noch ein wenig überarbeitet und mit Berücksichtigung meiner ursprünglichen Idee den Artikel panStamp ersetzt. Die Neustrukturierung ist aus meiner Sicht damit vollzogen und abgeschlossen, mein ursprüngliches Ziel erreicht. Änderungshistorie der Artikelserie ist hier nochmal beschrieben.-- joshi04 (Diskussion) 03:38, 14. Jun. 2016 (CEST)

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

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

~~Allgemeines~~
~~Hardware~~
~~panStamp mit Antenne~~
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.

Inhalt wurde spätestens mit der Neustrukturierung der Artikelserie "panStamp" eingearbeitet. -- joshi04 (Diskussion) 03:38, 14. Jun. 2016 (CEST)

~~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:
Für die Vorbereitung eines panStamps für den Betrieb auf einem "Board" wird der neue panStamp in den Panstick gesteckt, um die Programmierung (flashen des Sketch) vorzunehmen.

Im "normalen" Betrieb steckt ein panStamp auf ihm. Der so angebundene panStamp wird mit einem (bei Auslieferung des PanStamps vorinstallierten) Modem-Sketch als RF Modem verwendet und dient so dem Rechner als Interface zu anderen panStamps, zu denen über eine Funkstrecke mittels des SWAP-Protokolls kommuniziert wird.
~~Da auf dem panStamp Shield der panStamp fest eingelötet ist, übernimmt dieser in der Regel nur die zweite Funktion.~~

Inhalt in Artikel [[panStick]] übernommen. --TeeVau (Diskussion) 21:10, 17. Jul. 2015 (CEST)

spezifisches "Board"

In Artikel panStamp

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.

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

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". In Artikel SWAP übernommen. --TeeVau (Diskussion) 19:59, 16. Jul. 2015 (CEST)

Modem-Sketch

In Artikel [[panStick]]

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

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

auf Board abgestimmter Sketch

In Artikel panStamp

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

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

Module und Description File

In Artikel panStamp

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]

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

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.

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

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

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

Ebene 3: SWAP_XXXXXXXXXXXXXXXX.pm

In Artikel panStamp

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

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

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.~~ In Artikel SWAP übernommen. --TeeVau (Diskussion) 19:59, 16. Jul. 2015 (CEST)

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

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

Schritte der Inbetriebnahme

In Artikel panStamp

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

Ein panStamp wird in einen Panstick gesteckt und der Panstick für die Programmierung z.B. unter Windows installiert. Selbstverständlich kann ein panStamp auch über diverse andere Möglichkeiten und unter diversen anderen Betriebssystemen und über diverse andere Schnittstellen programmiert werden.

Arduino IDE vorbereiten (libs hinzufügen, Board auswählen, etc.).

Ein Sketch wird in der Arduino IDE entsprechend konfiguriert, kompiliert und auf den panStamp hochgeladen.

Der programmierte panStamp aus dem Panstick in das RGB-Board stecken.

Einen panStamp mit Modem-Sketch in den Panstick stecken und an den FHEM-Host stecken.

panStamp unter FHEM einrichten, wenn nicht durch autocreate automatisch geschehen.

RGB-Board mit Strom versorgen und ggf. einmal Reset-Knopf drücken. Dann sollte, falls autocreate aktiv ist, der panStamp automatisch eingerichtet werden.

SWAP-Device in FHEM an Gegebenheiten anpassen.

Inhalt in Artikel [[panStamp (Systemübersicht)]] übernommen. --TeeVau (Diskussion) 11:41, 24. Jul. 2015 (CEST)

Programmierung eines panStamps

~~unter Windows~~
~~Installation Panstick~~
~~Für die Installation des Pansticks unter Windows gibt es mehrere Möglichkeiten.~~
Installiert man eine Arduino IDE, kann dabei auch der Treiber für den Panstick mitinstalliert werden.

Treiber von der offiziellen Homepage herunterladen und installieren [[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()~~

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

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 kann beim Betrieb auf einer Fritzbox ebenfalls zu Problemen führen.~~ Zugefügt zu Artikel SWAP --TeeVau (Diskussion) 10:51, 17. Jul. 2015 (CEST)

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].~~

In SWAP. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)

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.

In SWAP. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)

Verwendung innerhalb FHEM

In Artikel panStamp [[panStick]]

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.

In panStamp. --TeeVau (Diskussion) 13:08, 19. Jul. 2015 (CEST)

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.

Inhalt in Artikel panStamp übernommen. --TeeVau (Diskussion) 20:05, 17. Jul. 2015 (CEST)

SWAP

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 anderen Adressen sind wie folgt belegt:
00 ist die Broadcast-ID

01 ist die ID des Pansticks am FHEM-System

FF ist die Default ID, die jeder panStamp im Auslieferungszustand besitzt

F0-FE sind die IDs, auf die autocreate die Adresse automatisch ändert, wenn ein neuer mit der ID FF erkannt wird und kein entsprechender Device-Name definiert ist.
Beitrag [27]
Ä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 geschied, funktionieren nur die grundlegenden Funktionen bis zur 2. Modulebene.~~

Zugefügt zu Artikel SWAP --TeeVau (Diskussion) 10:51, 17. Jul. 2015 (CEST)

set

ZUGEFÜGT ZU SWAP ARTIKEL, STRIKE FUNKTIONIERT ABER IN DIESEM ABSATZ NICHT Ist ein SWAP-Device definiert, stehen folgende set-Befehle zur Verfügung:

regGet <reg>

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

regSet <reg>

Schreibt in den Register mit der id <reg>. Für die Systemregister kann hierzu statt der RegisterID auch der Registername (siehe regListAll) verwendet werden.

regSet <reg>.<ep>

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-Description-XML-File neu ein.

clearUnconfirmed

Löscht die liste der unbestätigten Nachrichten.

flash [<productCode>|<firmwareFile>]

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

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

Zugefügt zu Artikel SWAP --TeeVau (Diskussion) 10:51, 17. Jul. 2015 (CEST)

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

Zugefügt zu Artikel SWAP --TeeVau (Diskussion) 10:51, 17. Jul. 2015 (CEST)

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. Dieses Attribut wird dazu benutzt, die Konfiguration vom Device-XML-File festzulegen. Erst wenn der Produktcode als Attribut vorgegeben wurde, z.B. für einen RGB-Sktech: attr <device> ProductCode 0000002200000003 kommen zu den allgemeinen Kommandos die spezifischen der nächst höheren Modulebene 35_SWAP_<productcode>.pm mit hinzu. Dann werden die SWAP-Nachrichten an das entsprechende Modul weitergegeben und dort verarbeitet.

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

Zugefügt zu Artikel SWAP --TeeVau (Diskussion) 10:51, 17. Jul. 2015 (CEST)

SWAP_<ProductCode>

In Artikel SWAP

Ist bei einem SWAP-Device das Attribut Productcode gesetzt, wird die SWAP-Nachricht an das entsprechende Modul der 3. Ebene weitergegeben und dort verarbeitet. Die spezifischen Kommandos und Attribute sind bei den entsprechenden Anwendungen näher beschrieben.

Zugefügt zu Artikel SWAP. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)

Intervall bei Sketch mit power down / batterie betriebene Panstamps

In Artikel SWAP

Devices mit power down mode durchlaufen beim Einschalten oder bei einem Reset eine 3 Sekunden Schleife und warten auf Kommandos, dann werden normaler Weise die Register mit den Sensorwerten gesendet und die normale Loop gestartet. power down devices gehen danach schlafen und wachen regelmässig auf um ihre Werte zu senden. Alternativ zum Intervall kann man den Resetknopf drücken, wenn man sie nicht im Zugriff hat.

Nachrichten an ein Device im power-down-state werden gepuffert und dann an das Device geschickt, sobald dieses sich im SYNC status befindet. Dieses ist typischer Weise nach dem Startup z.B. nach einem Reset der Fall.

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

~~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
~~Zugefügt zu Artikel SWAP. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)~~
~~Verschlüsselung~~
Die Aktivierung der Verschlüsselung für die Kommunikation zwischen panStamp und panStick ist hier beschrieben, scheint allerdings derzeit noch nicht eingecheckt zu sein (Stand 01.05.2015). 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]~~
Inhalt in Artikel SWAP übernommen. --TeeVau (Diskussion) 21:00, 17. Jul. 2015 (CEST)
~~Explizite Anwendungen~~
~~RGB-Board~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~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 mit Compilerschaltern konfiguriert werden.~~
Inhalt in Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~weitrere Screenshots~~

InternalValues

Readings

Attributes

~~Inhalt in Artikel SWAP_0000002200000003 übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)~~
~~original RGB-Sketch (von panstamp.com)~~
Der originale Sketch von der panStamp.com-Seite und das generelle FHEM-Modul verstehen von Haus aus nur die regSet und regGet Kommandos. Wenn man den colorpicker verwenden möchte, geht das nur per readingsProxy.
Das einfachste ist es den Sketch und das FHEM-Modul für das RGB-Board zu verwenden. Dann hat man neben dem colorpicker, einem farbigen State-Icon auch alle Möglichen Kommandos wie on, off, on-for-timer, dimup, ... und kann konfigurieren, wie das Board nach dem Hart- oder Soft-Einschalten reagieren soll.
~~Derzeit scheint es keinen Grund zu geben, den original Sketch zu verwenden. 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.~~

Inhalt in Artikel SWAP_0000002200000003#Anwendungsbeispiele übernommen. --TeeVau (Diskussion) 13:58, 28. Jul. 2015 (CEST)
~~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]~~
Inhalt in Artikel PanStamp RGBWW Board mit DMX und IR übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~Bedienung in FHEMWEB~~
~~Komandos~~
~~Definition~~
~~Der Panstick wird entsprechend folgendem Befehlt angelegt:~~
~~define panStick panStamp /dev/ttyUSBx@38400~~
Die Schnittstelle ist entsprechend Installation des [[panstamp#unter Linux|Pansticks]] anzupassen.
Dieses panStamp Device versucht dann alle panStamps im Netz zu finden und per autocreate anzulegen, wenn dieses aktiv ist.
~~Attribute TBC~~
~~Set TBC~~
~~Get TBC~~
~~In Artikel SWAP_0000002200000003~~
~~http://forum.fhem.de/index.php?topic=12487.msg81923#msg81923~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
EIn register verändern
~~In Artikel SWAP~~
~~http://forum.fhem.de/index.php/topic,12487.msg87679.html#msg87679~~
In Artikel SWAP übernommen. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)
~~Register umrechnung dec zu hex TBC~~
~~In Artikel SWAP~~
~~http://forum.fhem.de/index.php/topic,13890.msg162790.html#msg162790~~
In Artikel SWAP übernommen. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)
~~Poweronstate TBC~~
~~In Artikel SWAP_0000002200000003~~
~~http://forum.fhem.de/index.php/topic,12487.msg88054.html#msg88054 http://forum.fhem.de/index.php/topic,12487.msg95574.html#msg95574 http://forum.fhem.de/index.php/topic,13890.msg124456.html#msg124456~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
~~Aus nach poweron TBC~~
~~In Artikel SWAP_0000002200000003~~
~~http://forum.fhem.de/index.php?topic=13890.msg121296#msg121296 Power on register http://forum.fhem.de/index.php?topic=13890.msg121137#msg121137~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
~~listunconfirmed TBC~~
~~In Artikel SWAP~~
~~http://forum.fhem.de/index.php/topic,12487.msg88112.html#msg88112~~
In Artikel SWAP übernommen. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)
~~Fadeto TBC~~
~~In Artikel SWAP_0000002200000003~~
~~http://forum.fhem.de/index.php/topic,12487.msg97406.html#msg97406~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
~~In Artikel SWAP_0000002200000003~~
~~Default fade time http://forum.fhem.de/index.php?topic=13890.msg121572#msg121572~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
~~Eigenschaften des fade TBC~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~http://forum.fhem.de/index.php?topic=13890.msg106644#msg106644~~
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~4.,5. kanal TBC~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
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
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~Extra kanäle TBC~~
~~In Artikel SWAP_0000002200000003~~
~~http://forum.fhem.de/index.php?topic=13890.msg173280#msg173280 http://forum.fhem.de/index.php?topic=13890.msg214329#msg214329 http://forum.fhem.de/index.php?topic=13890.msg214474#msg214474~~
Inhalt in Artikel SWAP 0000002200000003 übernommen. --TeeVau (Diskussion) 14:25, 28. Jul. 2015 (CEST)
~~IR Schnittstelle TBC~~
~~IR TBC~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
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~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~http://forum.fhem.de/index.php/topic,13890.msg163008.html#msg163008 http://forum.fhem.de/index.php/topic,13890.msg163153.html#msg163153~~
~~Ircluster TBC~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~http://forum.fhem.de/index.php?topic=13890.msg175331#msg175331~~
~~Irgate TBC~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~http://forum.fhem.de/index.php?topic=13890.msg175278#msg175278~~
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)

~~DMX Schnittstelle~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
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.
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~sonstiges~~
~~Alternativer Fade per Patch~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
~~Als Alternative zum im Sketch und im Modul eingebauten Fade-Befehl ist hier ein Patch vorgestellt: Beitrag [60]~~
~~Der Patch ist nicht eingecheckt.~~
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~Kompatibilität RBG-Board mit NRG-panStamps~~
~~In Artikel PanStamp_RGBWW_Board_mit_DMX_und_IR~~
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.~~
In Artikel übernommen. --TeeVau (Diskussion) 23:54, 17. Jul. 2015 (CEST)
~~Bodenfeuchtesensor~~
~~In Artikel SWAP~~
~~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.
In Artikel [[SWAP] übernommen. --TeeVau (Diskussion) 23:59, 18. Jul. 2015 (CEST)
~~Umweltsensor~~
~~Die Weiterentwicklung des Bodenfeuchtesensors zum Umweltsensor ist hier PanStamp_Umweltsensor beschrieben.~~
~~Ultraschall-Füllstandssensor~~
~~Projektidee~~
~~Repeater Mode~~
~~Die Repeaterfunktionalität ist derzeit (01.05.2015) noch nicht näher beschrieben, wird aber von den Modulen unterstützt. Beitrag [62]~~
~~Weblinks~~
panStamp panStamp Hersteller

Projektseite für das RGB-Multi-Board.

rgbdriver sketch auf sourceforge

soilmoisture sketch auf sourceforge
~~[/u] [/s]~~
~~Einleitung falsch~~
Oh, cool: Eine Diskussion, die komplett durchgestrichen ist.
Auf den Hauptartikel klickte ich völlig zufällig: "Was könnte das wohl sein?"
Von daher ist aus meiner ganz bescheidenen Sicht die Einleitung völlig falsch. Da hat für so neugierige Leute wie mich zu stehen: "Es geht um <das hier> und <dafür> kannst Du das nutzen."
Nicht aufregen! Ich mache nichts Böses - ich bin die Zielgruppe. Curt (Diskussion) 02:46, 29. Jan. 2019 (CET)