panStamp support

[nano]

Hallo zusammen,

dies ist mein erstes Posting hier im Forum.
Ich finde es prima, dass sich jemand der panStamp-Integration in FHEM angenommen hat.

Ich selbst bin gerade dabei, den panStack auf verschiedenen Homematic- bzw. RWE-Komponenten direkt laufen zu lassen (also ohne panStamp-Modul).
(Warum? Weil ich zum Beispiel keine Schalt- oder Dimmaktoren mit Gehäuse und Platine für den Preis und ohne viel Aufwand selbst bauen kann. Ist aber nur meine persönliche Meinung.)
(Warum panStack? Weil er schlicht und einfach ist. Ich habe mich in den letzen 8 Jahren intensiv mit diversen Systemen, Stacks und Protokollen (KNX, Zigbee, 6LoWPAN, Bluetooth Low Energy) beschäftigt. Für das, was ich zuhause benötige, reicht panStack allemal (derzeit nutze ich ein komplettes Homematic-System mit CCU). Und da es ja ein freies Projekt ist, gibt es derzeit auch nicht das Problem von Interoperabilität zwischen verschiedenen Herstellern. Generell würde ich aber in Zukunft eher auf IPv6 mit 6LoWPAN/802.15.4 setzen, aber zunächst muss panStack erstmal reichen. :-) Ist aber nur meine persönliche Meinung.)

Dazu habe ich zunächst eine Liste mit HM/RWE Komponenten erstellt, um einen Überblick zu gewinnen, in welchen Geräten ein AVR zum Einsatz kommt (bisher habe ich auch STM32 und 8051 gesichtet).
Die Liste ist in diesem Wiki zu finden und befindet sich im Anfangsstadium. Sie sollte öffentlich editierbar sein.

Angefangen habe ich mit diesem einfachen Schaltaktor als Endgerät: https://github.com/ccier/openhm/wiki/PSS

Als "panStick" kommt bei mir ein Wattuino pro mini adv 3.3V/8MHz mit einem TRX868-Modul (CC1100) zum Einsatz. Das Modul habe ich quasi für 16,95EUR von ELV bei Amazon als BAUSATZ gekauft. Beim Bausatz liegt das Modul lose dabei. Theoretisch bräuchte man den Wattuino nicht, da in diesem Bausatz auch ein ATmega328P zum Einsatz kommt. Die 6pol. ISP-Schnittstelle ist herausgeführt.

Die FW für die AVRs habe ich als Atmel Studio 6 Solution/Projekte erstellt und verwende dabei auch die Arduino CoreLib (libcore.a), die ich mit der Atmel AVR Toolchain kompiliert habe.

Sobald ich ersten veröffentlichbaren Code habe, werde ich alles auf meiner GitHub-Seite veröffentlichen.

Gruß
Christian

[justme1968]

ich hab hier http://forum.fhem.de/index.php?t=msg&goto=77055&rid=430#msg_77055 einen tread für das led carrier board auf gemacht. vielleicht gibt es ausser mir ja noch anwender.

gruss
  andre

[Rince]

Sodala,

noch vieles relativ unklar, aber es wird irgendwann fertig:

Universalplatine für panStamp speziell für Haussteuerung.
Ich finde es ja schade, wenn man die vielen Ein/Ausgänge so völlig ungenutzt läßt, weil man nur 2 oder 3 Sensoren anklemmt.

Ziel ist es, eine Universalplatine zu haben, die für bestimmte (vorgesehene) Sensoren schon fertig verdrahtet ist => man muss nur noch den Sensor anlöten einerseits, und die andererseits im Sketch schon auf die Sensoren vorbereitet ist. Der Sketch soll quasi fix und fertig sein, mit allen vorgesehenen Sensoren auskommentiert;
Beispiel:
Ich will nen PIR, dann klemme ich die 3 Verbindungen an (da wo auf dem PCB dann PIR steht), nehme aus dem Sketch bei //PIR die // weg, lade den Sketch hoch und bin fertig :)

Da das ganze im Endeffekt eine panStamp Erweiterung ist, gibt es dafür im panStamp FOrum einen Thread.

http://www.panstamp.org/forum/forumdisplay.php?fid=21

Wer also Vorschläge und Ideen hat, die man damit umsetzen kann, immer her damit.



Bis jetzt sind folgende Soll-Punkte definiert:

Anschluss:
12V - 24V (genaue Werte gibts später)
Format: so, dass es komplett in eine UP Dose passt
Gedachte Anbringung: Entweder an der Wand (dann z.B. mit einem Taster für Licht) oder an der Decke (wo der PIR wohl am meisten Sinn macht)

Stromversorgung auf dem Board selbst:
Standard 3,3V
Optional: vorbereitet, um eine zusätzliche 5V Versorgung anzubringen (1 Bauteil einlöten für 5V)

vorgesehene Module:
PIR
IR Diode zum steuern von Endgeräten (TV etc.)
IR Empfänger zum empfangen von IR Befehlen, Auswertung durch fhem
2-3 Taster für Schalter (mit Pulldownwiderstand)
Ultraschallsensor (für Füllstandsmessung etc., braucht aber wohl die 5V)

In der Überlegung:
DMX

Gewünscht:
Vorschläge, was man mit den Eingängen sinnvoll machen könnte (z.B. Poti für Drehregler oder so, irgendwelche Eingänge, wo Signale gezählt werden?)
Vorschläge, mit welchen Steckverbindern sowas nach außen geführt werden soll.

Wer weitere Vorschläge hat, drüben im Forum bitte einfach in den Thread reinschreiben, oder einen neuen Thread starten. Am besten mit Links zu Arduino Projekten, wo das schon läuft.


Realisierungszeitraum:
Keine Ahnung, ich denke die Weihnachtsbaumbeleuchtung bekommen wir damit auf jeden Fall gesteuert :)

Das ganze soll complett open source sein, wenn wir uns auf eine einheitliche Platine einigen, wird Daniel auch welche produzieren lassen für uns.

[justme1968]

hier der aktuelle softwarestand. die wichtigsten änderungen im vergleich zur letzten version:

• es wird eine command liste für devices im power down modus gehalten. soband 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 (von fehler abgesehen :) mit jedem beliebige swap device umgehen.
• es gibt eine neue 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 dann auf fhem kommandos wie on/off/on-for-timer zu mappen ist dann diese dritte schicht zuständig. mit dieser dritten modulebene ist es auch für aktore wie schalter/dimmer/... sehr einfach sie 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. ein beispiel für das rgb board (mit meiner firmware) ist angehängt.

wenn es intgeresse an den modulen gibt würde ich langsam anfangen mich um die 'offizielle' integration in fhem zu bemühen.

gruss
  andre

ps: vielleicht ist es übersichtlicher die hardware in einem eigenen thread zu besprechen.

[Rince]

Logisch gibts Interesse. Aber ich nehme an, du hast dir das gedacht :-)

[Tobias]

Für mich wären die Panstamps sehr(!) interessant um die drahtgebundenen Vegetronix Bodenfeuchtesensoren die irgendwanneinmal im Garten verteilt sein sollen an fhem anzubinden.
ZurZeit habe ich 3 davon, aber per 1wire angebunden. Habe aber keine Lust quer durch den Garten Kabel zu ziehen ;)

[justme1968]

guten morgen. hier ein kurzer status update:

• in der aktuellen version wird der repeater mode der panstamps unterstützt
• es ist jetzt möglich ein fhem device für ein einizges register eines panstamp anzulegen. d.h. wenn ein panstamp meherere digitale/analoge oder pwm ein- und ausgänge implementiert (z.b. das output board) lässt sich das auf eben so viele fhem devices aufteilen die jeweils getrennt und unabängig on, off und pct bereit stellen. damit lässt sich jetzt neben den sensoren auch jedes i/o board generisch in fhem integrieren ohne ein spezielles modul dafür zu schreiben. das ganze funktioniert im prinzip bis hinunter auf endpoint ebene und es ist z.b. auch möglich die drei farb kanäle des rgb boards auf drei fhem devices aufzuteilen und damit z.b. drei weisse leds unabhängig damit anzusteuern.

wegen der duplikat erkennung für den repeater mode diskutiere ich noch mit rudolf ob er einverstanden ist den zentralen duplikats check in fhem so zu erweitern das ich ihn mit verwenden kann oder ob ich es für die panstamps getrennt implementieren muss. die aktuellen quelltexte gibt es wenn das geklärt ist.

ansonsten schaue ich mir gerade an in wie weit es sinnvoll ist firmata und/oder 1-wire über swap zu implementieren und mit den bestehenden FRM und OWX modulen zu verbinden oder ob es für eine funkschnittselle besser ist etwas mehr intelligenz auf dem device zu lassen und nur aufbereitete sensor werte zu übertragen.
 
gruss
  andre

[ntruchsess]

ansonsten schaue ich mir gerade an in wie weit es sinnvoll ist firmata und/oder 1-wire über swap zu implementieren

Hallo Andre,

ich habe grade mal einen SWAP-basierten Arduino Stream geschrieben. PanStream.h,PanStream.cpp und einen Beispielssketch

Das PanStream-message-format ist in PanStream.h, Zeile 25 definiert. Jede Seite teilt beim Empfang einer Message in der Reponse im 'received_id'-Feld mit, welches Packet gerade empfangen wurde. Ist das Feld 'send_id' 0, dann wird kein Acknowledge-packet mehr erwartet (als Antwort auf ein Acknowledge-packet ohne Nutzdaten). Der Panstamp schickt in seiner Status-message im 'received_bytes'-Feld mit, wieviele Bytes der Query-message er verarbeiten konnte (das kann auch weniger sein, als mitgeschickt wurde, wenn der Receive-buffer voll läuft). Die nicht empfangen Bytes sollen dann in der nächsten Message nochmal transmitted werden. Arduino-seitig wird das 'received_bytes'-feld (in einer Query-message) nicht ausgewertet. Hier wird angenommen, das die PC-seite über 'unbegrenzte' Receive-buffer verfügt.

Compiliert und läßst sich auf den PanStamp flashen ist aber mangels Gegenstelle (in Software) allerdings noch völlig ungetestet. Details wie Retransmit, wenn das Acknowledge-package nicht empfangen wurde, sind auch noch nicht implementiert. Schau halt mal drauf und sag, was Du von dem Ansatz hältst...

Gruß,

Norbert
 

[justme1968]

guten morgen norbert,

das ist ja eine sehr schöne überraschung :) ich hab es zwar gestern abend schon gesehen aber eben erst kurz rein geschaut. bei deiner beschreibung hatte ich gleich die idee es direkt zum debuggen zu missbrauchen. ich glaube ich baue nachher mal eine empfangende seite in fhem.

ich mag die idee. vielleicht bekommen wir eine version davon direkt in die panstamp libraries. ich habe auch daniel von panstamp den link mal geschickt. mal sehen was er dazu sagt. eine idee die ich noch habe wäre einen neuen nachrichten typ 'stream' mit variabler länge zusätzlich zu command zu implementieren. dann könnte man ein zusätzliches längen feld aus der nachricht weg lassen und spart etwas. das gilt natürlich noch mehr für das acknowledge weil man die unnötigen daten ganz weg lassen könnte.  

gruss
  andre

[ntruchsess]

eine idee die ich noch habe wäre einen neuen nachrichten typ 'stream' mit variabler länge zusätzlich zu command zu implementieren

Das wäre natürlich elegant, man würde sich auf einer wenig oder hauptsächlich in eine Richtung benutzten Funkstrecke einiges an Funkverkehr sparen (ist ja wg. der 1% Regel auch nicht ganz unwichtig). Wenn das Feld 'length' in der REGISTER-klasse nicht als const deklariert wäre, wäre es ja auch ein NoBrainer.

Gruß,

Norbert

[justme1968]

so... kurze rückmeldung.

nach etwas debuggen habe ich eben die erste stream nachricht empfangen :)

das haupt problem war das du den buffer zu gross gewählt hattest. eine swap nachricht darf maximal 55 byte lang sein. mit dem 64 byte buffer gab es einen überlauf und das ding hat immer neu gestartet statt die nachricht abzusenden. was sonst noch wichtig ist ist die developer und product id zumindest so zu wählen das es keinen konflikt mit einem existierenden produkt gibt. sonst werden die register falsch interpretiert. 0xFFFFFFFF für beides ist zum testen vielleicht das beste.

und du solltest den panstamp nicht schlafen legen. bzw. zumindest so lange wach lassen das der master eine chance hat die nachricht zu bestätigen :)

eine weitere möglichkeit das ack schlanker zu gestalten wäre zwei statt einem register zu verwenden. ein langes für die daten und ein kurzes für die bestätigung.

ich baue jetzt mal die bestätigung auf fhem seite.

gruss
  andre

edit: inzwischen kann ich zumindest den ersten teil einer nachricht bestätigen. dann wird auch gleich der nächste teil los gesendet. die bestätigung darauf liefert aber nur immer wieder diesen zweiten teil. ich bin mir noch nicht ganz sicher woran das liegt. um besser debuggen zu können werde ich mal die nachricht sehr klein machen. dazu muss ich aber erst mal die große des stream buffers von der größe der nachricht entkoppeln. ich glaube das ist aber so oder so sinnvoll.

edit2: die bisherige version erlaubt nur das aufteilen einer nachricht in höchstens zwei teile gleichzeitig. ein teil steht im swap register und der zweite teil im write buffer. wenn der write buffer das zweite mal voll läuft und der swap buffer noch nicht bestätigt wurde wird nichts mehr gebuffert.

edit3: ich habe jetzt ein beispiel laufen. aus dem oben genannten grund geht es aber nicht mit sehr gleinen buffern und nicht mit nachrichten die deutlich grösser sind als der buffer.

[ntruchsess]

Prima, dass Du schon so weit bist!

inzwischen kann ich zumindest den ersten teil einer nachricht bestätigen. dann wird auch gleich der nächste teil los gesendet. die bestätigung darauf liefert aber nur immer wieder diesen zweiten teil.
ich bin mir noch nicht ganz sicher woran das liegt.

Ich habe das so designed, dass ein Acknoledge immer (optional) ein Datenpacket in die Rückrichtung ist. Die send_id muss sich dabei von den  vorherigen Packeten unterscheiden. Unterscheidet sie sich nicht, bedeutet das, dass das letzte Acknowlede-packet (welches auch Daten enthalten konnte) nicht empfangen wurde und noch mal gesendet werden muss. Da habe ich grade 2 Bugs entdeckt:
Die PanStreamClass::setValue-methode muss sich natürlich die send_id des empfangenen Packets im feld master_id merken. Außerdem muss die Zahl der empfangen Bytes zu 'receive_len' hinzuaddiert werden, sonst können diese Bytes gar nicht mit read() gelesen werden.

die bisherige version erlaubt nur das aufteilen einer nachricht in höchstens zwei teile gleichzeitig. ein teil steht im swap register und der zweite teil im write buffer. wenn der write buffer das zweite mal voll läuft und der swap buffer noch nicht bestätigt wurde wird nichts mehr gebuffert.

Das ist bei einem gepufferten Stream immer so. Man kann es entweder so implementieren, dass der Stream dann blockiert (bis im Hintergrund die Daten interruptgesteuert aus dem Puffer entfernt wurden), oder man kann in 'write()' eine 0 zurückgeben, was bedeutet, dass nichts geschrieben wurde. (Blockieren wäre natürich eigentlich besser, ich habe halt erst mal die einfachere Variante implementiert, weil ich nicht weiß, inwieweit PanStamp das brav im Hintergrund erledigt).

Mein Bugfix ist auf Github. Hast Du auch einen Github-account?

[edit] Wegen einer möglichen variablen Länge der SWAP-packete: so wie ich das sehen ginge das wenn man das nicht als REGISTER implementiert, sondern in beide Richtungen Status-message verschickt und zum Empfangen mit setSwapStatusCallBack() eine Callbackfunktion mit der Signatur 'void statusReceived(SWPACKET *status);' registriert, die das Swap-packet dann unmittelbar übergeben bekommt. In dem Fall kann man die Länge bei jedem Packet individuell einstellen.

Gruß,

Norbert

[justme1968]

hallo norbert,

Das ist bei einem gepufferten Stream immer so.

auch ohne verarbeitung im hintergrund ist mir nicht klar warum das so sein muss. wenn der swap buffer und der stream buffer unterschiedlich lang sind sollte es möglich sein erst dann 0 zurück zu geben wenn der stream buffer voll ist. egal wie viele swap teile noch zu versenden sind. nicht schon beim zweiten häpchen. das sollte sogar mit einem linearen buffer noch gehen wenn man das ende einer nachricht an irgendetwas fest machen kann.

dieses 'nachrichten ende' ist auch nötig damit die 8 bit länge nicht überläuft. das ist mir nämlich prompt passiert.

einen guthub account habe ich (noch) nicht.

gruss
  andre

edit: vielleicht ist es ein besserer ansatz nicht die bestehende register klasse zu wrappen sondern davon eine klasse abzuleiten die register erlaubt die variabel lange und über lange nachrichten direkt erlaubt.

[ntruchsess]

wenn der swap buffer und der stream buffer unterschiedlich lang sind sollte es möglich sein erst dann 0 zurück zu geben wenn der stream buffer voll ist.

So ist das ja auch gedacht. Es ist nur so, dass man die schon gesendeten Daten erst nach dem Acknowledge verwerfen kann, sonst kann man keinen Retransmit machen, wenn das Acknowledge ausbleibt, oder ein Acknowledge für ein älteres Packet reinkommt.

edit: vielleicht ist es ein besserer ansatz nicht die bestehende register klasse zu wrappen sondern davon eine klasse abzuleiten die register erlaubt die variabel lange und über lange nachrichten

Von REGISTER ableiten alleine reicht wohl nicht, da die (feste) Länge beim Empfang einer command-message geprüft wird, bevor der setData-callback aufgerufen wird.

Ich habe mal das Ganze hinter den statusReceived-callback gepackt und den Sendepuffer so gestaltet, dass die daten per pointer auf diesen zum Versand übergeben werden. Die Kommunikation muss in beide Richtungen per Status-message erfolgen. Du findest den code hier: PanStream.h und PanStream.cpp

Wäre prima, wenn Du den aktuellen Test/Arbeits-Stand der FHEM-seite auch irgendwo (z.B. auf Github) ablegen würdest, dann könnte ich auch damit testen.

Gruß,

Norbert

[justme1968]

hallo norbert,

ich komme erst morgen dazu etwas weiter zu machen. ich raeume dann meine stand auf und sende ihn dir.

das einzige das mir gerade zu den status nachrichten einfällt ist das sie nicht auf swap ebene adressierbar sind sondern immer an die broadcast adresse gehen.

gruss
  andre