panStamp support

justme1968 · 01 Juni 2013, 13:29:39

hallo norbert,

nur ein kurzer status auf die schnelle:

den onStatusReceived callback im panstream constructor zu setzen geht nicht. das ist noch zu früh und er wird dann im setup durch das panstamp.init() überschrieben.
die manufacturer und ddevice id sowie die hardware und firmware ids sind jewils 4 byte lang. nicht nur 1 byte.
ich habe die emfangende seite in fhem auf die status messages umgebaut und es funktioniert sehr gut.
mit den unterschiedlichen langen buffern geht jetzt natürlich das zerlegen in mehr als zwei häppchen.
meine befürchtung das es probleme gibt weil status nachrichten immer broadcast nachrichten sind hat sich nicht bestätigt. es ist sogar im gegenteil eine chance die streams von 'normalen' status broadcast nachrichten zu unterscheiden ohne an panstamp oder swap etwas zu ändern.
vielleicht kann man die tatsache das man mit einer query auf das register das aktuelle häppchen explizit neu anfordert zu etwas nutzen.
das gleiche gilt für ein command auf das register. vielleicht gibt es dazu auch eine sinnvolle verwendung.

heute abend hoffentlich mehr.

gruss
andre

justme1968 · 01 Juni 2013, 23:45:38

anbei meine aktuelle version:

die drei perl module ins FHEM verzeichnis kopieren dann am besten alle drei per reload laden oder fhem neu starten
das SWAP.tar im FHEM verzeichnis auspacken da sind die device description files drin
beim usb device für den panstick die geschwindigkeit nicht vergessen: @38400, die <NETID> ist B547.
im arduino.tar stecken die änderungen aus dem post obendrüber, die passende device id für das description file
ich habe auch noch anfangen das register im konstruktor der panstream klasse zu setzen. ich denke es gibt nicht wirklich einen grund nur ein festes register zu haben.
den callback habe ich noch erweitert das nur packete an die eigene adresse ausgewertet werden. das geht sonst schief wenn es mehr als einen sender gibt und das register dort noch etwas ganz anderes macht.
ebenfalls in arduino.tar ist der umgebaute test sketch der jede minute etwas in richtung fhem sendet und ansonsten auf daten von fhem wartet, alle gross in kleinbuchstaben und umgekehrt wandelt und zurück sendet.
wenn der panstick in fhem konfiguriert ist sollte beim einschalten des panstamp mit dem test sketch automatisch das richtige device in fhem angelegt werden:

Code Auswählen

define SWAP_FF SWAP_00000022FFFFFFFF FF 00000022FFFFFFFFdas einzelne FF ist dabei die adresse des panstamp.

das device kennt zusätzlich zu den normalen swap kommandos noch send,flush,showSendBuffer und clearSendBuffer für set und received für get. eine raw message kannst du per set raw auf das panstick device absetzen.

die sende/empfangs logik ist sehr an die arduino seite angelehnt.

wenn man in dieses modul die client liste für dir FRM devices und eine WriteFn einbaut sollte man im prinzip aus SendStreamPacket beim empfang dann dispatch aufrufen können[/list]
ein problem gibt es noch das ich mir noch nicht angeschaut habe: wenn man von fhem mehr als etwa 12-14 byte sendet kommt ab dem zweiten häpchen müll zurück.

gruss
andre

ntruchsess · 03 Juni 2013, 22:38:32

Hallo Andre,

mal ein kurzes Update meinerseits. Also erst mal ging ja gar nix :-( Jetzt habe ich 2 Abende erfolglos rumgeraten und Debug-statements im code verstreut...

... und dann habe ich doch mal Lambda/4-Antennen drangelötet. Und siehe da - es flutscht. Also ich hätte ja erwartet, dass es ohne Antenne zumindestens 20cm weit funkt, aber nix, nada. Was so ein kleines Stückchen Draht doch ausmacht :-)

Also, jetzt kann ich mich endlich mal ums Eingemachte kümmern. Deine panstamp-module habe ich bei der Fehlersuche jedenfalls schon mal gut kennengelernt.

Gruß,

Norbert

justme1968 · 03 Juni 2013, 23:20:53

lach. und ich hatte schon angst ich hab dich verschreckt. das mit der antenne hätte ich dir sagen können :).

ich hatte bis jetzt immer eine antenne dran. beim letzten hatte ich es dann aber so eilig deine panstream klasse zu testen das ich zu faul war sie dran zu löten.

bei mir hat es dann aber gott sei dank nur zwei stunden gedauert. ich habe schon an mir gezweifelt bis ich beim senden durch zufall mit der hand in der nähe des panstamp war. und plötzlich alles ging.

wenn du die module schon so gut kennst muss ich nicht mehr ein ganz so schlechtes gewissen haben weil die kommentare sehr spärlich sind...

gruss
andre

ntruchsess · 03 Juni 2013, 23:51:09

Zitat von: justme1968 schrieb am Mo, 03 Juni 2013 23:20nicht mehr ein ganz so schlechtes gewissen haben weil die kommentare sehr spärlich sind...

Passt schon, Kommentare lenken doch nur vom code ab ;-)

Ich hab das panStamp svn mal auf GitHub gemirrored: https://github.com/ntruchsess/panstamp/ - Branch 'panstream'. Wenn Du Dir da auch einen Account anlegst, kann ich Dir Schreibberechtigung darauf geben.

Gruß,

Norbert

justme1968 · 04 Juni 2013, 10:26:05

ich hab dir eben meinen account per pm geschickt.

ich wuerde gerne zu aller erste die panstream klasse etwas an die anderen panstamp beispiele anlehnen und alle register deffinitionen in regtable files verschieben, alle restlichen abhängigkeiten die verhindern das mehr als ein register und stream möglich ist entfernen und dann ein beispiel mit zwei streams bauen.

gruss
andre

ntruchsess · 04 Juni 2013, 12:45:54

Ich habe dich grade berechtigt. Klingt gut, was Du vorhast. Leg los :-)

Was die FHEM/Perl-seite angeht, ich denke es wäre sinnvoll, das SWAP-protokoll und Register-spezifische Handler Objektorientiert zu implementieren (also in jeweils eigene Perl-Packages zu verschieben), dann kann man sauber zwischen dem Interface zu FHEM hin (alle Funktionen mit einem vorangestellen Präfix 'SWAP_' oder 'PANSTAMP_'...) und den Protokoll bzw. Register-interna trennen. Ideal wäre, wenn man Die panstamp-klassen uneingeschränkt auch außerhalb von fhem nutzen könnte (z.B. als package Device::Panstamp), dann wäre es viel leichter Testcases zu schreiben und zu debuggen. Diese Panstamp-library würde man dann nach FHEM/lib verschieben. Die eigentlichen FHEM-module wären dann nur recht schlanke Wrapper. (So ist das im Prinzip mit dem Device::Firmata package und den FRM-modulen auch gemacht). Abgesehen davon könnte man so eine PanStamp-perl-api ja auch gut ins originale panstamp-projekt contributen (da gibt's bisher ja nur python und java libraries)

Gruß,

Norbert

justme1968 · 04 Juni 2013, 13:07:41

klar lege ich los :)

die trennung von swap und device spezifischen packages gibt es ja schont:

34_panStamp als interface zum panstick. vielleicht sollte man es in panStick oder panModem umbenennen...
34_SWAP für das swap protokoll und alles was nötig ist generisch mit allen pan stamp devices zu kommunizieren.
35_SWAP_* als device spezifische module die transparent das 34_SWAP modul nutzen und auf deren basis device spezifika abbilden die nicht mehr generisch sind.
für 34_SWAP und 35_SWAP.* ist es möglich das device auf jeweils genau ein register zu definieren. damit kann man dann z.b. bei einem io board jeden kanal in fhem einzeln bedienen.

die stream implementierung sehe ich in 34_SWAP. das augenblickliche 35 modul war nur zum testen gedacht bis alles geht.

was es zu zur zeit nicht gibt ist die möglichkeit ein device anzulegen und dabei mehrere register spezifische handler zu mischen. wenn sich tatsächlich so viel unterschiedliche funktionalität in einem device vereinen lässt gerne. im momment glaube ich aber eher das es dann sowieso unterschiedliche devices sind die dann auch mit den bisherigen ebene abgedeckt werden können.

was das wieder verwenden ausserhalb von fhem angeht schaue ich mir das mal an. der panstick als funkmodem und swap als protokoll sind aber beide so einfach das das meiste nicht das auslagern in eine lib wäre sondern teile von fhem wie platform unabhängiges device handling, dispatchen von nachrichten, duplikats check, module laden,... zu duplizieren. zum reinen testen ist es glaube ich einfacher eine eigene fhem installation dafür zu haben und tatsächlich innerhalb von fhem zu testen.

wenn man die pansticks generell auch ausserhalb von fhem verwenden möchte schaut das natürlich anders aus.

gruss
andre

ntruchsess · 04 Juni 2013, 14:13:08

Zitat von: justme1968 schrieb am Di, 04 Juni 2013 13:07die trennung von swap und device spezifischen packages gibt es ja schon

jain... das sind zwar getrennte perl-module, aber alle im package 'main'. Ich weiß - FHEM ist halt so gestrickt und das will ich auch gar nicht ändern (so viel Zeit habe ich gar nicht, dafür ist FHEM schon deutlich zu groß).

Ich bin halt prinzipiell ein Freund code so zu schreiben, dass er gut wiederverwendbar ist (und das bedeutet für mich erst mal unabhängig und außerhalb von FHEM wiederverwendbar). Typische FHEM-module leben alle im package 'main' und man kann sie eigentlich nur in Bruchstücken per cut&paste wiederverwenden, eben weil sie so eng mit dem fhem.pl verzahnt sind.

Zitat von: justme1968 schrieb am Di, 04 Juni 2013 13:07der panstick als funkmodem und swap als protokoll sind aber beide so einfach das das meiste nicht das auslagern in eine lib wäre sondern teile von fhem wie platform unabhängiges device handling, dispatchen von nachrichten, duplikats check, module laden,... zu duplizieren.

Die lib sollte natürlich relativ schlank bleiben und sich auf das wesentliche beschränken (Eierlegende Wollmilchsäue sind für eine Wiederverwendung in anderem Context in der Regel viel zu schwergewichtig). Also SWAP-packete parsen, versenden und unter Verwendung der SWAP device-xmls auf RegisterObjekte oder ähnliches mappen. Dazu ein paar Callbacks, über die man erfährt, wenn sich ein neues Device/Register gemeldet oder der Status schon eines bestehenden sich geändert hat. Oder auch nur direktes Durchreichen der (in handliche Objekte transformierten) Registerinhalte ohne jede Verwaltung. Netz- und Device-ids wären dann einfach nur properties der Austauschobjekte. Also in etwa das, was Arduino-seitig auch existiert oder nur ein bischen mehr. Die ganze high-level Verwaltung sollte da sowie draußen (bzw. in den FHEM-modulen) bleiben.

Gruß,

Norbert

justme1968 · 04 Juni 2013, 14:49:55

jetzt weiss ich erst was du meinst :)

die perl package geschichten muss ich mir erst mal anschauen. da ich perl erst seit zwei monaten und auch nur in zusammehang mit fhem kenne :) habe ich das bis jetzt komplett ausgeblendet.

ansonsten bin ich immer dafür dinge wieder zu verwenden. das parsen einer swap nachricht an sich sind halt nur 4 zeilen. dafür lohnt es sich fast nicht. aber wenn man das ein bischen weiter fast finden finden wir auf jeden fall einen sinnvollen weg. ob das dann bis zum beim device oder register management geht weiss ich noch nicht. es könnte sein das dann schon wieder zu viel von fhem dupliziert wird.

das parsen der xml files und bei bedarf laden ist aber z.b. ein guter kandidat. den wollte ich sowieso auslagern um für kleine geräte die das xml modul nicht installieren können/wollen das parsen mit einem getrennten kommandozeilen programm zu erledigen und dann fhem die aufbereiteten files zu geben.

gruss
andre

justme1968 · 05 Juni 2013, 18:31:52

hallo norbert,

ich bin beim debuggen eben noch auf ein konzeptionelles problem gestossen das beim gleichzeitigen senden in beide richtungen noch zu viele nachrichten hin und her gehen weil bestätigungen für die gleiche nachricht mehrfach gesendet werden:

a -> b: 1. nachricht + flush
b -> a: 1. bestätigung
a -> b: 2. nachricht und gleichzeitig:
b -> a: 1. eigene nachricht + flush -> die nachricht wird mit der eben schon mal gesendeten bestätigung versendet weil inzwischen nichts empfangen wurde
a empfängt bestätigung für nachricht 1. statt 2. und sendet 2. noch mal.

ich weiss noch nicht wie man das lösen kann ohne retransmit nach bestimmter zeit ohne bestätigung.

auch sollte keine bestätigung versendet werden wenn wenn die send_id = 0 ist. das ist der 'last packet not acknowledged' fall der ist noch zu allgemein.

gruss
andre

ntruchsess · 07 Juni 2013, 00:45:06

Zitata empfängt bestätigung für nachricht 1. statt 2. und sendet 2. noch mal.

Hm.. diese Racecondition ist natürlich schon etwas blöd. Aber das sollte sich schon lösen lassen, immerhin unterscheiden sich die beiden Packete ja in der send_id, auch wenn Sie die gleiche Received_id enthalten. Vieleicht sollte man die received_id nur einmal mitschicken und wenn zwischenzeitlich kein neues Packet eingetroffen ist, beim nächsten Packet eine 0 als received_id verwenden (Um anzuzeigen, das dieses Packet kein neues Acknowledge ist). Ein Retransmit soll ja nur beim Ausbleiben des Acknowledges versendet werden.

Da muss ich noch mal seeehr genau drüber nachdenken.

Ich portiere übrigens gerade die originale PanStamp python-library nach perl. Ich finde die API sehr gut verständlich entworfen. Die FHEM-module sollten sich daran recht sauber anflanschen lassen. Die Hälfte habe ich etwa, aber laufen tut natürlich noch nichts, dafür fehlt noch zu viel. Auf der CcPacket-ebene scheint es auch Acknowledges zu geben, das will ich mir auch noch mal genauer ansehen - eventuell kann man selbige in der PanStream-implementierung ja auch einfach weglassen, wenn man diese Aufgabe dem CSM-modul überlassen kann.

Gruß,

Norbert

justme1968 · 09 Juni 2013, 17:16:25

auch von mir ein kurzes update:

ich habe mal einen PanStreamFirmata sketch zusammengebastelt. es geht zwar alles mögliche noch nicht. ich kann aber von hand per sysex die firmware abfragen und bekomme auch ein ergebniss per panstream zurück.

gruss
andre

Tobias · 10 Juni 2013, 10:37:43

Hi Andre,
was brauche ich um einen Vegetronix Bodenfeuchtesensor über Panstamps in FHEM zu bringen?

1x Panstick
2x Panstamp
1x BatterieBoard ohne jegliche Erweiterung
1x SMA-Connector
1x SMA 5cm DipoleAntenne?

Korrekt?

bzgl der antenne: kennst du gute 868Mhz SMA-Outdoorantennen? Und sehr kurze biegsame SMA-Verlängerungen incl Adapter (IP65) zum Einschrauben in eine Gehäusewand?

justme1968 · 10 Juni 2013, 11:01:28

hallo tobias,

die liste stimmt so weit. aber für den zweiten panstamp brauchst du auch den sma connector.

wegen der antenne auf sensor seite habe ich mir auch schon gedanken gemacht und tendiere zur zeit eher zu einem etwas grösseren gehäuse bei dem die antenne noch mit rein passt. das ist ein loch (sogar an der oberseite) weniger und es ist preislich glaube ich deutlich günstiger.

je nach entfernung lohnt es sich vielleicht sogar es auf sensor seite mit einer draht antenne zu probieren.

gruss
andre