FHEM Forum

FHEM - Hausautomations-Systeme => Sonstige Systeme => Thema gestartet von: justme1968 am 24 April 2013, 21:35:25

Titel: panStamp support
Beitrag von: justme1968 am 24 April 2013, 21:35:25
guten abend,

eigentlich ist es noch viel zu früh aber ich habe inzwischen schon mehrere anfragen bekommen und vielleicht interessiert es ja doch den einen oder anderen jetzt schon oder hat vielleicht sogar interesse sich zu beteiligen.

ich habe vorgestern nun endlich meine panstamps und zubehör bekommen und mit der integration in fhem angefangen.

die panstamps (http://www.panstamp.com/home (//www.panstamp.com/home)) sind kleine arduinos mit on board cc1101 funk modul. es gibt ein open source protokoll und alles ist mit der normalen arduino ide zu programmieren und zu flashen. die module können entweder auf kleine sensor bords gesteckt werden oder für alle möglichen eigenentwicklungen verwendet werden. die schnittstelle zum rechner ist ein kleiner usb stick auf den selber auch ein panstamp aufgesteckt wird. auf diesem läuft ein modem sketch und er ist dann in etwa vergleichbar zu einem cul. das schöne meiner meinung nach ist das sender und empfänger die gleiche hardware und die gleiche softwareumgebung verwenden.

als erstes beispiel habe ich mir natürlich das rgb led carrier board vorgenommen :). zur zeit verwende ich auf dem rgb board noch den beispiel sketch von panstamp. wenn die fhem integration fertig ist möchte ich aber dort auch noch eine ganze reihe dinge einbauen und auch an der hardware noch ein zwei erweiterungen machen. am ende soll es ein universeller rgb led controller werden der vollstdändig in fhem integriert ist und sich gleichzeitig per ir fernbedienung und per dmx wand dimmer bedienen lässt.

danach wären dann die diversen sensor boards und evetuell 1-wire sensoren dran. mich selber interessiert besonders ein füllstandssensor mit einem ultraschall modul. dafür hatte ich urspünglich einen arduino mit ethernet schield und firmata vorgesehen. das ganze per funk zu machen finde ich aber eigentlich schöner.

die integration in fhem ist genau so modular gehalten und aufgebaut wie z.b. cul/fs20/homematic. es gibt ein modul um den panstick anzusprechen, das ist die cul ebene und eins für das swap protokoll. das ist die fs20/hm ebene. es ist also denkbar das empfangen per cul zu machen wenn jemand hierfür die firmware erweitert und die nachrichten dann an das swap modul zu geben oder auch fs20 und andere protokolle mit dem panstick zu empfangen und dann an bestehende fhem module zu dispatchen.

so... genug von unfertigen dingen geredet.

anbei noch ein paar screenshots und zwei bilder von der hardware.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Carsten am 24 April 2013, 22:57:07
Super Sache!

Ich hoffe, ich finde auch bald die Zeit, mich damit zu beschäftigen.

Was ich dort im Shop vermisse, sind Gehäuse. Unter Products sind die aber irgendwo gelistet, zumindest für die Batteryboards.
Lässt du die so nackt, oder bastelst du dir selber was?
Wie sieht die Reichweite aus?

Gruß

Carsten
Titel: Aw: panStamp support
Beitrag von: justme1968 am 24 April 2013, 23:16:24
über gehäuse habe ich mir noch keine gedanken gemacht. das hat zeit.

die reichweite ist vergleichbar mit den cul die ich habe und deutlich besser als beim hmlan. wie es mit drahtantennen ausschauen würde weiss ich noch nicht.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Fennek am 25 April 2013, 00:49:30
Auch ich würde mich freuen wenn das klappt.
Dann könnte ich meine etlichen Stripes Zentral steuern.

Mein Dev Kit und driver board sind schon unterwegs zu mir.

Um die Leistung des driver Boards zu erhöhen, könnte man ja z.Bsp.:

http://www.leds24.com/RGB-LED-Verstaerker-12V (//www.leds24.com/RGB-LED-Verstaerker-12V)

so etwas nutzen.

Grüße Andreas
Titel: Aw: panStamp support
Beitrag von: TeeVau am 25 April 2013, 10:21:31
Hallo,

kann man mit dem CC1101 nicht direkt FS20 senden bzw. empfangen? Dann würde man sich einen weiteren CUL sparen und hätte einen FS20 RGB Dimmer, ohne noch was proprietäres zu haben/machen/benutzen
Titel: Aw: panStamp support
Beitrag von: justme1968 am 25 April 2013, 10:35:57
ich glaube ich verstehe deine frage nicht ganz...

natürlich könnte man direkt fs20 senden. genau so wie man es mit einem cul kann. aber dann muss jemand das protokoll auch implementieren. und in diversen punkten erweitern. also z.b. bidirektional machen, verschlüsseln, ... . am ende hättest du einen rgb dimmer der ein protokoll benutzt das fs20 ähnlich ist und von fhem bedient werden kann aber nicht sinnvoll mit anderen fs20 komponenten gepairt werden kann.

es gibt ja neben dem rgb board noch diverse andere sensor boards. die alle automatisch mit fhem gehen wenn ein mal das swap protokoll implementiert ist.

ansonsten ist am swap protokoll nichts proprietäres. alles ist komplett offen. genau so wie es die hardware ist.

gruss
  andre

Titel: Aw: panStamp support
Beitrag von: TeeVau am 25 April 2013, 14:15:38
Vielleicht reden wir wirklich aneinander vorbei. Habe es so verstanden, dass man für diese Lösung einen weiteren CUL braucht, der quasi die Bridge ist zwischen FHEM und dem swap Protokoll.
Der RGB Dimmer (Oder was auch immer) spricht nur swap.
Meine Frage zielte darauf ab, ob der RGB Dimmer auch die Möglichkeit hat FS20 zu verstehen. Somit würde also kein weiterer CUL notwendig sein, wenn schon ein FS20 CUL vorhanden ist. FS20 ähnlich meinen ich nicht, sondern so richtig FS20.

Hintergrund ist:
Ich überlege ein DIY Projekt zu machen, aus Arduino nano und dem ELV FS20 WUE.
Durch dein Post war mein Gedanke vielleicht direkt panstamp zu nehmen, um das zusätzliche WUE Modul zu sparen.

Ich wollte das Vorhaben auf keinen Fall schlecht machen oder so (von wegen proprietär), bitte nicht falsch verstehen :-)
Titel: Aw: panStamp support
Beitrag von: justme1968 am 25 April 2013, 14:39:52
ich habe keine angst das du was schlecht machen wolltest... ich wollte nur verstehen was du genau möchtest.

für den fall den ich mir als erstes vorgenommen habe brauchst du keinen zweiten cul sondern einen panstick und einen panstamp als sender. beides zusammen entspricht in etwas einem cul und kann im prinzip das gleiche ist aber etwas günstiger und kann von haus aus nur das swap protokoll. das wäre dann der teil über den fhem sendet und empfängt.

als sensor oder aktor brauchst du noch einen zweiten panstamp und sonst nichts. es ist ja im prinzip ein arduino nano mit funkmodul zusammen auf einem board.

man könnte dem panstamp sowohl auf sendender als auch empfangender seite das fs20 protokoll beibringen. wenn es schon einen fertigen arduino sketch dafür gibt würde das sogar recht einfach gehen denke ich. sonst müsste man das entwickeln. ich weiss nicht ob man fs20 und swap gleichzeitig über eine hardware machen kann oder ob sich beides ausschließt wie z.b. fs20 und homematic.

ich weiss nicht wie das fs20 wue modul genau angesteuert wird bzw. was es für daten liefert von daher kann ich es auf der ebene nicht vergleichen. du bist aber auf jeden fall auf das reine senden beschränkt. die panstamps sind bidirektional. wenn du schon einen cul hast der fs20 macht ist die fs20 lösung natürlich etwas günstiger. wenn du dafür extra einen cul kaufen müsstest nicht mehr. und wenn es mit den lötkünsten wie bei mir nicht so weit her ist erst recht nicht :)

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Carsten am 25 April 2013, 15:33:49
Soweit ich verstanden habe, braucht man den Panstick ja sowieso, um die Stamps zu programmieren. Die Schnittstelle kostet dich dann noch einen zusätzlichen Stamp, also ~18 USD. Sind das eigentlich Brutto- oder Nettopreise?

Wie sieht eigentlich die Verschlüsselung des Protokolls aus? Da steht in der Beschreibung
ZitatDevelopers are free to define new security options, using custom encryption algorithms.
Gibts auch eine Standardverschlüsselung oder muss man die grundsätzlich selbst implementieren?
Titel: Aw: panStamp support
Beitrag von: justme1968 am 25 April 2013, 15:42:27
die firma sitzt in spanien, die preise sind inklusive mwst. zoll fällt keiner an.

ZitatSoweit ich verstanden habe, braucht man den Panstick ja sowieso, um die Stamps zu programmieren. Die Schnittstelle kostet dich dann noch einen zusätzlichen Stamp, also ~18 USD.
ja. genau.

ZitatGibts auch eine Standardverschlüsselung oder muss man die grundsätzlich selbst implementieren?
seit der letzten version gibt es scheinbar schon eine verschlüsselung in den libs. ich habe aber noch nicht weiter danach geschaut.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Heiermann am 25 April 2013, 20:40:09
Moin,

am 23. April kam auch bei mir zu Hause die erste Lieferung aus Spanien an. Dabei hatte ich erst 5 Tage zuvor bestellt und per internationaler Überweisung bezahlt. Der Versand erfolgt mit DHL-Express für 14 Euro.
Ich habe mir 3 panStamps, 2x USB-Stick und 1x Batterieboard mit Temperatursensor im Gehäuse gekauft. Da ich damit u.a. meine Markise irgendwann über fhem steuern möchte, wäre es toll, wenn die kleinen Geräte über Firmata und die FRM-Module ansteuerbar wären. Der USB-Stick kann auch über ein Netzteil dauerhaft mit Strom, versorgt werden, und die GPIO-Pins sind - genauso wie beim Batterieboard - komplett nutzbar.

-Heiermann
Titel: Aw: panStamp support
Beitrag von: justme1968 am 27 April 2013, 21:06:43
kurzer zwischenstand:

- lichtsteuerung geht
- ir empfang am panstamp geht
- die erkannten ir kommandos werden per funk an fehm weiter gesendet
- das swap protokoll ist so generisch eingebaut das mit einem passenden device description file im prinzip jedes panstamp device funktionieren müsste
- beliebige swap register setzen und abfragen
- autodiscovery und autocreate von devices

noch zu tun:
- ir kommandos lokal auswerten und leds steuern
- diverse rgb controller features auf dem panstamp
- autmatisch lesen und konvertieren der device.xml files
- verschlüsselung
- etwas mehr bidirektionalität und retries ala homematic
- empfang und auswerten der panstamp sensor module. ich habe mir gestern den luftdruck/temperatur sensor bestellt. den baue ich ein sobald er da ist.

- noch eine ganze menge mehr...

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Rince am 01 Mai 2013, 11:58:00
Sehr schick.
Ich mag ja Arduinos sehr.

Was ich an den Boards unglücklich finde, dass sie immer nur 1 Sensor drauf löten. Da sind so viele Eingänge da. Temperatur, Luftfeuchte, Luftdruck.
Meiner Meinung nach sollten sie gleich noch Shield-Boards verkaufen, zum draufstecken. So wie beim Arduino auch.

Vor allem wenn ich bedenke, was z.B. so ein PIR kostet. 5-10$ bei Sparkfun.

Das gäbe für den Innenbereich ein Wandthermometer mit PIR, Hygrometer und dimmbarem Nachtlicht für um die 40€, alles FHEM gesteuert. Dazu noch ein Taster, z.B. als Lichtschalter.


Meine Güte, das ist ja ein Traum. Stromversorgung fehlt noch.


Anderes Thema:
Wenn wir schon grade am Protokoll erweitern sind:
Andre, hast du mal überlegt ob es möglich wäre, die Stamps auch als Relais Station nutzen zu können? Um die Funkreichweite sozusagen auf zu bohren?
Das macht natürlich nur Sinn, wenn das Teil immer unter Strom steht, aber letztlich ist das für viele Zwecke eh sinnvoll, außer für Sensoren z.B. im Garten, die Wetterstation spielen sollen.

Möller Xcomfort verwendet z.B. seine Funkmodule als Relais für entfernte Module, wobei man hier die Route festlegen muss. Also Modul A sendet zu B, das wiederum erreicht die Zentrale C. Andersrum auch: wenn C A erreichen will, sendet es an B, welches dann A erreicht.
Dieses Routing ist den Modulen einmalig zu programmieren. Also so eine Art Pairing mit einer Zwischenschicht  im Protokoll, der starren Route.

Scheint mir eine schlaue Lösung zu sein, weil es den Funkverkehr verglichen mit einem wilden Routing deutlich senkt, aber eben dennoch die Reichweite vergrößern kann.
Titel: Aw: panStamp support
Beitrag von: justme1968 am 01 Mai 2013, 12:11:02
das mit dem nur 1 sensor stimmt nicht ganz. es sind fast immer 2 oder 3. das protokoll sieht das auch extra vor. temperatur und feuchte oder temperatur und luftdruck zum beispiel. ich hab an das rgb carrier board den ir sensor gelötet und ein dmx empfänger und ein helligkeitssensor kommen auch noch dran. das mit den shields ist ja im prinzip auch so nur das der panstamp auf das carrier board gesteckt wird und nicht umgekehrt ein shield auf einen arduino. wenn du das nackte battery board nimmst kannst du selber deine sensoren dran löten. du hast (fast) alle pins im zugriff. oder gleich selber ein carrier board entwerfen.

was den traum angeht: ich habe gestern bei busware diesen prototypen gesehen http://busware.de/tiki-browse_gallery.php?galleryId=39 (//busware.de/tiki-browse_gallery.php?galleryId=39). so etwas ohne den unförmigen anbau für die stecker und mit einem kleinen panstamp und strom von der nächsten lampe geht schon in die richtung.

das mit der relais funktion ist im swap protokoll vorgesehen geht fast out of the box mit allen boards die über ein netzteil versorgt werden. bei der batterie version macht es nicht so viel sinn. ich habe es aber noch nicht probiert weil ich erst zwei panstamps habe und einer auf dem usb stick sitzt. zwei weitere sind unterwegs. dann werde ich es für den luftducksensor im garten probieren. ich denke ich werde einen der feuchtigkeitsensoren auch mit dran hängen. das ganze soll ohne starre route funktioniert ähnlich wie bei den hue lampen.

ob die starren routen wirklich so viel günstiger sind was den funk verkehr angeht hängt glaube ich von der anzahl der repeater ab. so lange es nur wenige sind sollte es keinen grossen unterschied machen. wenn doch wäre eine protokoll erweiterung recht einfach denke ich.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Rince am 01 Mai 2013, 13:53:50
Danke, dass du die Idee mit dem Routing im Kopf hast :-)

Ich will nicht weiter stören mit Träumen von ungelegten Eiern.
Ich bestelle mir mal welche und melde mich, wenn ich weiter bin oder Hilfe brauche.


Ist es möglich für die Stamps einen eigenen Forumsbereich auf zu machen? Die könnten ein echter Knüller werden. Preiswert, etwas Lötarbeit, aber programmiertechnisch gut handelbar und flexiebel einsetzbar.
Titel: Aw: panStamp support
Beitrag von: justme1968 am 01 Mai 2013, 15:21:43
ideen stören nie.

das mit dem eigenen bereich sollte man vielleicht dann klären wenn es genügend anwender gibt und nichtr nur deinen einen :).

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Rince am 01 Mai 2013, 16:35:21
Irgendwann wirst du diese Worte bereuen *lach*

Was den Bereich angeht, sind doch schon einige mehr ;-)
Titel: Aw: panStamp support
Beitrag von: justme1968 am 02 Mai 2013, 12:52:50
na dann finden wir mal raus ob es wirklich mehr sind :)

anbei eine aller erste version zum spielen.

das 34_panStamp.pm modul ist für einen panStamp der auf einem panStick sitzt und das interface zwischen fhem und dem panStamp netz bildet, das 34_SWAP.pm modul implementiert das SWAP protokoll das zwischen den panStamps gesprochen wird. das SWAP.tar file muss im FHEM verzeichniss ausgepackt werden. dort sind die device descriptions drin. zur zeit ist noch XML::Simple nötig um die device files zu lesen. eventuell lagere ich das aus dann können die device files offline aufbereitet werden. das wäre dann eine abhängigkeit weniger die auf der fritzbox probleme machen könnte.

das panStick device mit define panStick /dev/ttyxxxx@38400 B547 anlegen. der device paramter funktioniert genau so wie beim cul, B547 ist die default netz id. diese am besten erst mal so lassen. wenn der panStick läuft sollten die client panStamps per autocreate angelegt werden sobald sie das erste mal senden. z.b. nach dem einschalten oder nach einem reset.

alternativ kann man sie von hand mit define xxx SWAP <ID> anlegen. ID ist die device addresse und bei einem frisch geflashten panStamp in der regel FF. man sollte also einen nach dem anderen in betrieb nehmen, sonst haben mehrere die gleiche addresse und das gibt konflikte.

über das panStick device kann man direkt eine raw message absetzen. diese ist zur zeit eigentlich immer eine SWAP nachricht wie z.b. set panStick raw 00010000010000 als broadcast an alle damit sie ihren product code zurück senden. das macht der panStick nach dem initialisieren auch ein mal automatisch um alle nicht schlafenden devices per autocreate anlegen zu können.

wer mehrere devices hat sollte jedem nach dem anlegen mit set xxx regSet 09 <ID> eine eigene id zuweisen. die landen auf dem panStamp im eeprom und sind auch nach neustart noch vorhanden. das fhem device sollte danach auch automatisch anrepasst worden sein.

nach dem die einzelnen panStamp devices angelegt sind kann man mit set xxx regGet <reg> das senden eines bestimmten registers triggern, mit set xxx regSet <reg> <value> ein register auf einen bestimmten wert setzen, und mit set xxx statusRequest alle register senden lassen. mit get xxx regList
get xxx regListAll
lassen sich die benutzer register oder alle register die das device hat auflisten.

alle empfangen SWAP nachrichten werden in readings im jeweiligen device angezeigt. das sollte für alle devices funktionieren. ich habe zur zeit nur das rgb board und die steuerung dafür ist noch hard codiert auf meinen eigenen sketch mit dem ir empfänger.
falls jemand 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.  d.h. ich habe noch keine nachricht von einem 'echten' sensor empfangen. um aus den SWAP register readings temperaure/humidity/... readings zu machen ist zur zeit noch userReadings  und stateFormat nötig. das wird noch automatisiert und verbessert.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Rince am 02 Mai 2013, 21:15:35
Hi Andre,

leider kann ich es noch nicht ausprobieren :(
Meine Stamps sind noch irgendwo zwischen Spanien und München.


Dafür untersuche ich gerade die Möglichkeit, eine Art Standard-Platine zu basteln, die das Batterie-Board ersetzt.

Mein Wunsch ist es, eine Platine zu entwickeln mit vorgegebenen Lötpunkten für verschiedene (definierte) Sensoren, die dann am Stamp angebunden sind und einen Sketch zu schreiben, der diese Sensoren auswerten kann.
Anschluss an 230V.


Also so ähnlich wie die kaufbaren Boards, blos halt mir deutlich mehr Sensoren und nem normalen Stromanschluss nebst fertigem Sketch.

Man könnte also den fertigen Sketch nehmen, die Zeilen auskommentieren deren Sensoren nicht bestückt sind, auf den panStamp laden, die Sensoren anlöten (lassen) die man wirklich nutzen will, und ab geht die Post :)

Das ganze soll in einen 2-fach oder 3-fach Schalterrahmen eigenen Geschmacks passen, vermutlich wird 1 Loch in der Wand für die Unterputzdose nötig sein.

Da ich aber zur Zeit noch keine panStamps habe, wird es noch etwas dauern bevor ich konkret planen kann.


Jetzt die Frage:
Welche Sensoren oder Aktoren sind denn sinnvoll?


Temperatur (Raumtemperatur)
Feuchtigkeit (Luftfeuchte im Raum, spannend bei Schimmelproblemen etc, außen für Wetterstation)
Luftdruck (im Raum eher sinnbefreit, sinnvoller im Garten :) )
PIR (Anwesenheit von Personen)
1 Relais für direktes Schalten von Verbrauchern (z.B. Licht)
Lichtsensor (lichtabhängiges schalten von Beleuchtung)
Taster (z.B. Licht toggle)
Vorwiderstand für LED Beleuchtung? (Nachtlicht?)

??? welche würdet ihr verwenden ???

Ideen oder Meinungen?

Ist es besser ein weiteres Loch in die Wand zu bohren, oder einen Blindrahmen zu nutzen, der einige Zentimeter aus der Wand herausragt? Ein Loch für die Stromversorgung wird sich nicht vermeiden lassen)


PS:
Ich mache das so nebenher, mit einer finalen Version rechne ich eher im Herbst 2013, Weihnachten ist auch möglich und außerdem werde ich alleine kaum ein gutes Ergebnis erzielen.

Da die panStamps keine CE Zulassung haben (die Platine nebst der angelöteten Sensoren auch nicht), ist das ganze natürlich eine Lösung die keinen rechtlichen Segen hat!
Außerdem ist das Arbeiten an 230V potentiell lebensgefährlich und für unbefugte Personen ein völliges nogo...


PPS:
Wenn die Platinen fertig sind (also wirklich funktionieren), wäre es praktisch wenn man bei einem Dienstleister einfach die gewünschte Anzahl günstig bestellen könnte, bei SMD Bauteilen vielleicht auch fertig bestückt.



Was haltet ihr davon?


Ist dieses Projekt in irgend einer Form sinnvoll?
(Engagiert gestartete Projekte die im Sand verlaufen sind, gibt es im Netz ja genug. Dieser Liste ein weiteres hinzu zu fügen, macht eher wenig Sinn)
Titel: Aw: panStamp support
Beitrag von: justme1968 am 02 Mai 2013, 21:37:38
die generelle idee gefeällt mir.

was den pir sensor angehtfürchte ich nur das das nicht wirklich funktioniert wenn er an einer stelle an der wand angebracht ist. womöglich noch neben der tür. dann bekommst du höchstens mit das jemand kommt oder geht und kannst es noch nicht mal unterscheiden.ich glaube etwas an der decke ist dafür besser geignet.

ich wünsche mir einen ir empfänger und kräftigen sender. um die ganzen ir fernbedienungen mit zu sniffen und die diversen geräte im raum per fhem steuern zu können. am besten auch an der decke.

im design schwieriger aber in der anwendung flexibler wäre es statt einem grossen board ein paar kleine boards zu haben die sich zusammen stecken lassen. vielleicht nach input und output getrennt.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: Heiermann am 02 Mai 2013, 21:42:16
Zitat von: Rince schrieb am Do, 02 Mai 2013 21:15Jetzt die Frage:
Welche Sensoren oder Aktoren sind denn sinnvoll?

Nun, da ich bereits 3 panStamps zuhause rumliegen habe, melde ich mich mal zu Wort.

Ich möchte ein Gerät in Verbindung mit USB-Stick und USB-Netzteil zur Steuerung meiner Balkonmarkise einsetzen.
Ein weiterer panStamp auf Batterieboard mit Temperatursensor samt Gehäuse dient zum Lernen.
Als Temperatursensor erscheint mir das im Vergleich zu teuer.
Ich warte auf den Umweltsensor, der als Prototyp auf der CeBIT gezeigt wurde. Mit der fertigen Version möchte ich verschiedene Lüfter bzw. Fenster je nach Luftqualität schalten.
Da ich in einigen Wochen mehrere RFDuinos mit verschiedenen Erweiterungen erwarte, entscheide ich bei den möglichen Anwendungen nach Funkreichweite und Größe. So steht auch noch mein Roomba für die fhem-Integration bereit.
Meine Meinung zu Anbauplatinen: Der Vorteil der panStamps sind die kleinen Abmessungen. Erweiterungen sollten diesen Vorteil nicht eliminieren.

-Heiermann

Titel: Aw: panStamp support
Beitrag von: Rince am 03 Mai 2013, 07:43:56
Das Teil an die Decke montieren, hm, hat Vorteile auch.
Was den PIR an der Wand neben der Tür betrifft, wir haben sowas in einigen Räumen in der Arbeit. Da, wo die Leute immer vergessen haben das Licht aus zu machen. Da wurden die Schallter ausgetauscht mit PIRs.
Sehen an der Wand nicht störend aus, natürlich ist die Ausleuchtung beschränkt.
Zum generellen feststellen ob wer kommt und geht bzw. wer eignen sie sich gar nicht. Egal wo im Zimmer sie sind.

Eher könnte man versuchen eine Bewegungsrichtung mit mehreren PIRs zu analysieren. Ich hatte sowas im Kopf wie "in welchen Räumen hält sich jemand auf?"
Bei Feuer und Einbruch eine nicht unspannende Frage. Vermutlich wird ein PIR dir auch direkt sagen, wo es brennt ;-)

Dabei ist es aber egal, ob die PIRs an der Decke oder der Wand hängen.

Die Idee mit den Infrarot Sendern und Empfängern finde ich spannend, da hab ich auch nen Anwendungsfall.

Das spricht für die Decke.

Der Taster macht an der Decke weniger Sinn.

Was noch für die Decke spricht ist die Tatsache, dass da oben mittlerweile öfters Geräte sind, man nicht dagegen rennen kann und man ggf. eine Verkleidung anbringen kann.



Nachtrag:
IR Signal Auswertung:
im Stamp oder in FHEM?

Im Stamp hat den Vorteil, dass es autonom laufen kann und nicht erst gefunkt werden muss, um dann das Resultat zurück zu funken.
Das Auswerten in FHEM hat denVorteil, dass die Signale systemweit zur Verfügung stehen. Außerdem kann man Änderungen am Verhalten einfach in FHEM vornehmen, ohne den Stamp neu programmieren zu müssen.
Titel: Aw: panStamp support
Beitrag von: Carsten am 03 Mai 2013, 08:34:23
Hallo,

Luftdruck macht nach meinem Verständnis inhouse durchaus Sinn. Sofern man im Haus keinen Überdruck hat ( ist glaube ich bei kontrollierter Wohnraumbelüftung teilweise der Fall), sollte der sich vom Außendruck ja eigentlich nicht unterscheiden, oder? Nur mehr als ein Luftdrucksensor macht vermutlich keinen Sinn.

Was mir an dem Plan Unbehagen bereitet, sind die 230V. Das wär mir persönlich glaube ich zu heikel.

Ich überlege die Stamps im Moment erstmal für 3 Zwecke einzusetzen:
- Strom-/Gaszähler auslesen
- IR-Sender und Empfänger zur Steuerung von TV und Co und umgekehrt zur Steuerung von FHEM über IR
- diverse Schließerkontakte z.B. Rauchmelder und Schließzylinderkontakt

Wenn die Stamps da schonmal rumstehen, sollen sie auch gleich die Temperatur messen. Ursprünglich sollte auch ein Display dran, aber dafür ist jetzt erstmal ein Uno-Klon unterwegs.

Was ich also in erster Linie brauche sind Counter und Schließer.

Achso, die Auswertung und Codierung der IR-Signale soll zumindest bei mir FHEM übernehmen.

Gruß

Carsten
Titel: Aw: panStamp support
Beitrag von: justme1968 am 03 Mai 2013, 08:41:39
das mit den 230v finde ich auch nicht optimal. es gibt aber z.b. kleine 12v netzteile die in eine up dose oder einen lampen baldachin passen. für ir/luftdruck/helligkeit reicht aber vielleicht tatsächlich eine batterie.

temperatur an der decke ist nicht unbedingt richtig. das wäre an der wand besser. irgendwo ist auf dem panstamp scheinbar auch ein interner temperatur sensor. ich weiss nur noch nicht was der misst.

was die ir auswertung angeht: mit dem rgb board mache ich beides. ein paar konfigurierte befehle steuern das licht am rgb board. bei diesen wird nur das ergebnis also helligkeit und farbe an fhem gesendet. alle anderen befehle die unbekannt sind werden direkt an fhem weitergeleitet. wenn man das im sketch so vorsieht muss man auch nicht neu flashen um die ir-befehle neu zu konfigurieren sondern kann das über funk machen.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: ntruchsess am 03 Mai 2013, 15:11:50
ich hab mir das SWAP Protokoll jetzt auch mal näher angesehen. Was ich vermisst habe ist eine automatische Absicherung der Funktverbindung - also in dem Sinne, dass das Protokoll ein transparentes Handshake zwischen Sender und Empfänger machen würde um bei Fehlern automatisch noch mal zu senden oder so. Wie es z.B. ZigBee (oder auf Ethernet TCP/IP) macht. Wie kann der Sender denn sicher gehen, dass z.B. eine Status-message auch tatsächlich empfangen wurde?

Gruß,

Norbert

(Der sich wohl auch ein paar panStamps bestellen wird...)
Titel: Aw: panStamp support
Beitrag von: justme1968 am 03 Mai 2013, 15:35:41
hallo norbert,

das mit dem handshake auf protokoll ebene ist tatsächlich nicht vorgesehen und würde erst mal auch nicht funktionieren weil die status meldungen immer per broadcast an alle gehen.

ich denke es gibt mehrere wege das zu lösen. zum einen ist die frage ob wirklich der sender der status nachricht d.h. in der regel der sensor dafür zuständig ist sicherzustellen das die nachricht am empfänger angekommen ist. denn was sollte ein (dummer eventuell batterie betriebener) sensor im zweifel tun wenn die nachricht nicht ankommt? das ding hat weder display noch kann es sich sonst wie bemerkbar machen. in der regel also höchstens noch mal senden. das mach er meistens aber sowieso weil z.b. gemessene werte regelmäßig übertragen werden.

meiner meinung nach ist in den meisten fällen aufgabe der zentrale bzw. desjenigen der ein kommando sendet sicherzustellen das nichts verloren geht. und das lässt sich auf mehrere arten bewerkstelligen:

- die zentrale sollte reagieren wenn die regelmäßigen nachrichten eines sensors nicht kommen. und den status abfragen wenn eine bestimmte zeit keine nachrichten angekommen sind. allein schon well batterien schlicht und einfach leer sein können.

- über das noce byte lässt sich beim empfang einer nachricht rückwirkend feststellen ob nachrichten fehlen.

- für command nachrichten habe ich gerade in das swap modul eingebaut das intern eine liste der gesendeten kommandos gehalten wird. sobald ein register mit der status nachricht auf das kommando antwortet wird die nachricht aus der liste entfernt. nach einer weile könnte man das kommando also noch mal senden. diese liste ist in verbindung mit einem comand stack ist sowieso nötig weil die batterie betrieben sensoren keine nachrichten empfangen wenn sie schlafen. so können commandos übertragen werden sobald sie aufwachen.

wenn es aus irgend einem grund doch ein szenario gibt bei dem es wirklich wichtig ist das das der sensor sicher weiss das die nachricht bei der zentrale angekommen ist wollte ich das mit dem register address feld lösen. das device kann nach dem es gesendet hat aktiv nachfragen ob sein register in der zentrale angekommen ist.

das fehlen des direkten handshakes sehe ich bis jetzt nicht wirklich als nachteil. alleine die einfache in betriebname ohne pairing oder peeren wie es bei homematic nötig ist ist wirklich angenehm. und wenn ein handshake doch nötig ist läss er sich mit der oben skizierten methode realisieren. wenn das nicht reicht kann man das protokoll immer noch erweitern.

ansonsten habe ich bei meinen bisherigen spielereien noch keine einzige verlorene nachricht gehabt. sogar wenn ich mutwillig die 1%regel ignoriert habe und so schnell wie möglich dutzende von nachrichten gesendet und empfangen habe. und das auch wenn gleichzeitig fs20 und homematic nachrichten in der luft waren.


gruss
  andre
Titel: Aw: panStamp support
Beitrag von: ntruchsess am 03 Mai 2013, 16:41:18
naja, so ein Handshake auf Applikationsebene ist ja eher eine Krücke :-(, sowas gehört eigentlich schon ins Protokoll.
Sender sendet, Empfänger quittiert, bleibt die Quittung aus, sendet der Sender noch mal. Das ist schließlich Funktechnik, da kannst Du davon ausgehen, dass immer mal was verloren geht, weil irgendwer dazwischenfunkt. Spätestens wenn man über Multihop oder Meshnetze redet, dann geht das ohne Absicherung auf Protokollebene gar nicht mehr vernünftig.

Ich hab mir trotzdem grade mal 2 panStamps und den panStick bestellt. Ist ja schließlich alles im Sourcecoce verfügbar, das läßt sich sicher verbessern das ganze ;-)

Gruß,

Norbert

Titel: Aw: panStamp support
Beitrag von: justme1968 am 03 Mai 2013, 16:54:48
ich würde die aktuelle version von swap eher mit udp vergleichen als mit tcp und ein handshake auf protokoll ebene kein allheilmittel. den handshake nicht auf der untersten swap ebene zu machen bedeutete ja auch noch nicht es ganz oben auf applications ebene zu machen.

auf protokoll ebene weiss der sender in diesem fall ja eben gar nicht wer der empfänger ist. alle status nachrichten gehen per broadcast raus und nicht an einen bestimmten empfänger. und für alle umwelt sensoren sehe ich da auch kein problem. der einfache setup wiegt die nachteile bei weitem auf. zumal genau diese sensoren eh regelmässig senden.  und das funktioniert auch noch bei einem netz mit relativ wenigen repeatern.

ich sage nicht das es nicht viele anwendungsfälle gibt bei denen es sinnvoll ist auf protkoll ebene abzusichern. aber es gibt sicher auch fälle wo es nicht nötig ist.

und selbst wenn du die quittung auf protokoll ebene hast entbindet dich das nicht davon auf server seite zu kontrollieren ob nachrichten verloren gehen weil du sonst alle fälle von fehlkonfiguration über leere batterien nicht abgedeckt hast. nur auf protokoll ebene kannst du das nicht alles abfangen.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: justme1968 am 05 Mai 2013, 16:38:08
scheinbar sind aus dem beitrag weiter oben die attachments mit den fhem modulen verschwunden.

hier noch mal die aktuellen versionen. dazu gekommen ist inzwischen die möglichkeit beliebige definierte teilregister zu setzen, zwei interne queues zum speichern von set kommandos an schlafende devices und um ein resend auslösen zu können wenn ein kommando nicht bestätigt wurde. das resend an sich ist aber noch nicht eingebaut.

ansonsten gilt die beschreibung von hier (http://forum.fhem.de/index.php?topic=12487.msg75980#msg75980) immer noch.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: justme1968 am 06 Mai 2013, 16:29:24
ich habe oben das 34_SWAP.pm attachment gegen eine etwas aktuelleres ausgetauscht. damit funktioniert jetzt z.b. der luftruck sensor problemlos.

menschen lesbare readings für spannung, temperatur luftdruck bekommt man mit diesem userReadings attribut voltage {hex(ReadingsVal($name, "0B.0-Voltage","0"))*0.001 }, temperature  {hex(ReadingsVal($name, "0C.0-Temperature","0"))*0.1-50 }, preassure {hex(ReadingsVal($name, "0C.1-Pressure","0"))*0.01 }
es ist auch sinnvoll event-min-interval zu setzen wenn mehrere readings in mehreren nachrichten gesendet werden. der userReadings mechanismus erzeugt sonst mehrfache einträge:
attr <device> event-min-interval .*:5

ich werde noch einbauen das die user readings für neue devices automatisch angelegt werden.


(siehe Anhang / see attachement)


gruss
  andre

edit: seit eben geht auch das automatische senden der gespeicherten kommandos (z.b. addresse und sende intervall) für offline devices sobald diese per knopfdruck online gehen und empfangen.
Titel: Aw: panStamp support
Beitrag von: nano am 08 Mai 2013, 18:45:53
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 (//github.com/ccier/openhm/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 (//github.com/ccier/openhm/wiki/PSS)

Als "panStick" kommt bei mir ein Wattuino pro mini adv 3.3V/8MHz (//www.watterott.com/de/Wattuino-pro-mini-3V3-8MHz) mit einem TRX868-Modul (//github.com/ccier/openhm/wiki/TRX868) (CC1100) zum Einsatz. Das Modul habe ich quasi für 16,95EUR von ELV bei Amazon (//www.amazon.de/ELV-HomeMatic-Schaltaktor-f%25fcr-Batteriebetrieb-Komplettbausatz/dp/B0055B62ME/) 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








Titel: Aw: panStamp support
Beitrag von: justme1968 am 10 Mai 2013, 21:20:25
ich hab hier http://forum.fhem.de/index.php?t=msg&goto=77055&rid=430#msg_77055 (//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
Titel: Aw: panStamp support
Beitrag von: Rince am 16 Mai 2013, 11:19:58
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 (//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.
Titel: Aw: panStamp support
Beitrag von: justme1968 am 20 Mai 2013, 21:49:32
hier der aktuelle softwarestand. die wichtigsten änderungen im vergleich zur letzten version: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.
Titel: Aw: panStamp support
Beitrag von: Rince am 21 Mai 2013, 00:44:24
Logisch gibts Interesse. Aber ich nehme an, du hast dir das gedacht :-)
Titel: Aw: panStamp support
Beitrag von: Tobias am 21 Mai 2013, 16:59:02
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 ;)
Titel: Aw: panStamp support
Beitrag von: justme1968 am 27 Mai 2013, 10:46:00
guten morgen. hier ein kurzer status update: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
Titel: Aw: panStamp support
Beitrag von: ntruchsess am 30 Mai 2013, 01:17:26
Zitat von: justme1968 schrieb am Mo, 27 Mai 2013 10:46ansonsten 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
 
Titel: Aw: panStamp support
Beitrag von: justme1968 am 30 Mai 2013, 10:29:37
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
Titel: Aw: panStamp support
Beitrag von: ntruchsess am 30 Mai 2013, 12:38:52
Zitat von: justme1968 schrieb am Do, 30 Mai 2013 10:29eine 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
Titel: Aw: panStamp support
Beitrag von: justme1968 am 30 Mai 2013, 16:43:42
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.
Titel: Aw: panStamp support
Beitrag von: ntruchsess am 30 Mai 2013, 22:57:20
Prima, dass Du schon so weit bist!

Zitat von: justme1968 schrieb am Do, 30 Mai 2013 16:43inzwischen 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.

Zitat von: justme1968 schrieb am Do, 30 Mai 2013 16:43die 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
Titel: Aw: panStamp support
Beitrag von: justme1968 am 30 Mai 2013, 23:40:36
hallo norbert,

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

Titel: Aw: panStamp support
Beitrag von: ntruchsess am 31 Mai 2013, 03:19:50
Zitat von: justme1968 schrieb am Do, 30 Mai 2013 23:40wenn 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.
Zitat von: justme1968 schrieb am Do, 30 Mai 2013 23:40edit: 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
Titel: Aw: panStamp support
Beitrag von: justme1968 am 31 Mai 2013, 18:18:02
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
Titel: Aw: panStamp support
Beitrag von: justme1968 am 01 Juni 2013, 13:29:39
hallo norbert,

nur ein kurzer status auf die schnelle:heute abend hoffentlich mehr.

gruss
  andre
Titel: Aw: panStamp support
Beitrag von: justme1968 am 01 Juni 2013, 23:45:38
anbei meine aktuelle version: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
  • Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 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
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 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
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 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
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 04 Juni 2013, 13:07:41
    klar lege ich los :)

    die trennung von swap und device spezifischen packages gibt es ja schont: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
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 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

    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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


    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 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 (//github.com/ntruchsess/panstamp/tree/device_panstamp). 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
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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

    Titel: Aw: panStamp support
    Beitrag von: Tobias am 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?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 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
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 10 Juni 2013, 15:10:32
    Warum brauche ich für den zweiten Panstamp auch einen SMA-Connector? Ich dachte der Panstamp wird "nur" in den Panstick aufgesteckt der schon selbst eine angeflanschte Antene mitbringt?

    Bzgl Antenne: warscheinlich ist eine Drahtantenne besser die man ins Gehäuse reinlegt. Ich habe ca 30m freies Feld incl einer 40cm Poroton-Steinmauer zu überbrücken
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 10 Juni 2013, 15:19:33
    die die buchse und die antenne kommt jeweils an den panstamp. der eine panstamp kommt in dein sensor gehäuse, der andere auf den stick und an die usb schnittstelle. wenn dir die draht antenne reicht brauchst du natürlich die buchse nicht.

    der stick ist nur das interface um einen panstamp zum flashen und als modem an den rechner anzuschliessen. er hat keine antenne.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 10 Juni 2013, 15:35:03
    alles klar, jetzt habe ich es auf den Bildern auch gesehen :confused:
    Sorry für die vielen Fragen....
    Habe auch gesehen das es ein 2AAA-BatteryHolder gibt, mir ist aber nicht klar ob man dieses an das BatteryBoard anschließen kann.
    Zb. Arbeiten die Vegetronix Bodenfeuchtesensoren ab(!) 3.3V, und wenn man diese an dieser Grenze betreibt mit schwächelder Batterie weiß ich nicht wie die Messwerte aussehen.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 10 Juni 2013, 15:44:10
    der step up converter macht die 3.3v angeblich bis runter zu 0.8v. praktische erfahrung über die lebensdauer der batterie habe ich noch nicht.
    wenn die eine aa nicht lange genug durch hält würüde ich aber eher eine a als zwei aaa verwenden.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 11 Juni 2013, 16:37:13
    anbei der aktuelle stand mit den fhem und arduino modulen für den rgb driver. installation siehe oben.

    35_SWAP_0000002200000003.pm ist das fhem modul für das rgb driver board.
    rgbdriver.tar.gz ist der sketch für den panstamp per 'ino' auf kommandozeile kompilierbar.

    die doku für das rgbdriver fhem modul fehlt noch. hier eine kurzversion für set:
    um die ir commandos anzulernen am besten 'learnIR #' verwenden. danach blinkt die led auf dem board schnell und es wird auf ein ir signal gewartet. wenn das empfangen ist blinkt die led langsamer und es wird auf ein kommando von fhem gewartet. danach geht die led auf dem board aus und das eben gesendeete kommando ist mit der taste auf der ir fernbedienung verknüpft.

    empfange ir commandos die nicht über eines der 16 register eine lokale aktion auslösen werden über das register 0C an fhem übertragen und sind per notify ganz normal weiter verarbeitbar.

    im register 0E lässt sich konfigurieren in welchem zustand das board nach einem power on sein soll. aus, in einer festen farbe oder im zustand vor ausschalten. für letzteres ist zur zeit noch ein teil code in sketch.ino auszukommentieren.

    die anderen readings sollten selbsterklärend sein.

    an (fast) allen stellen wird zwischen helligkeiten und farben und beim off über etwa eine sekunde überblendet. das ist ist noch nicht konfigurierbar.  bei allen helligkeits oder färb änderungen wird zwischen start und ende höchstens alle 0.5 sekunden und maximal 10 mal der zustand an fhem übertragen. das ist für eine entgültige installation eventuell noch zu viel.

    dmx kommt noch.

    eigentlich ist alles viel einfacher als die lange erklärung :).

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 11 Juni 2013, 19:30:27
    Sehr schön, geht bei mir schonmal.

    Wenn nur nur meinen letzten Streifen RGB Stripe finden würde oO
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 11 Juni 2013, 21:25:17
    Mhh aber 20mA Ruhestrom ist auch nicht ohne.

    Das sind 0,23 Watt mhh. Muss ich glatt mal messen was mein RGB Controller zieht der jetzt an dem Stripes hängt.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 11 Juni 2013, 21:45:43
    mach ein besseres board :) ich kann ein paar gebrauchen.

    vielleicht ist sogar daniel ein dankbarer abnehmer wenn du ideen hast.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 12 Juni 2013, 08:57:04
    Hi Andre,
    hast du schon irgendwo eine anleitung gesehen wie man die Scetche auf die Panstamps(per Panstick) ohne Windows brutzelt?
    Du hast auch schon irgendwo geschrieben, das du den Vegetrinix Bodenfeuchtesensor selbst schon einmal angeschlossen hast. Welchen Scetch muss man dafür verwenden? Und an welche Kontakte muss dieser an den Panstamp angeschlossen werden? Ist dann das SWAP- und panstamp.pm Modul ausreichend
    Titel: Aw: panStamp support
    Beitrag von: Rince am 12 Juni 2013, 09:30:10
    Hier die Anleitung:
    http://code.google.com/p/panstamp/wiki/firststeps (//code.google.com/p/panstamp/wiki/firststeps)

     Die Arduino IDE gibt es auch für Linux, die Schritte sollten eigentlich ziemlich gleich sein.
    http://arduino.cc/en/Main/Software (//arduino.cc/en/Main/Software)

    Zu den anderen Fragen kann Andre wohl bessere Auskunft geben. Hab zwar 5 davon rumliegen, bin aber momentan voll im Umrüstwahn gefangen.

    Wenn du willst, übersetze ich die Anleitung mal auf Deutsch.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 12 Juni 2013, 09:49:56
    hallo tobias,

    ich weiss nur wie das ohne windows geht :)

    am einfachsten lädst du dir die arduino 'ide' von hier: http://arduino.cc/en/Main/Software (//arduino.cc/en/Main/Software). die panstamp lib findest du hier: http://code.google.com/p/panstamp/source/checkout (//code.google.com/p/panstamp/source/checkout). da gibt es ein .../arduino/libraries/panstamp das muss dort hin wo auch die anderen arduino libs sind. das ist auf dem mac .../Arduino.app/Contents/Resources/Java/libraries und  .../arduino/libraries/sketches am besten in das panstamp verzeichniss von eben aber mit dem namen examples. du findest den sketch dann in der ide unter .../beispiele/panstamp/...

    die pins die du verwendes kannst du dir im prinzip aussuchen: http://code.google.com/p/panstamp/wiki/panStamp (//code.google.com/p/panstamp/wiki/panStamp). du brauchst pro sensor einen digitalen und einen analogen pin und gnd.

    du brauchst den soilmoisture sketch. dort in soilmoisture.ino die sensor und power pins konfigurieren und in regtable.in in updtSensor das delay von 10 auf 400ms ändern.

    du brauchst nur das swap und das panstamp modul und die device files aus SWAP.tar. zur zeit liefert der sketch 'nackte' spannung als reading. das user reading für die bodenfeuchte musst du dir selber bauen weil im device file keine umrechnung angegeben ist und das format zur zeit auch nur ein lineares mapping erlauben würde. oder du erweiterst den sketch das die umrechnung direkt auf dem panstamp passiert. da bin ich noch nicht zu gekommen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 12 Juni 2013, 21:12:44
    Also ich hab hier versucht das rgb zeugs in die Arduino IDE zu laden das geht irgendwie nicht so recht, dann habe ich da was zusammen gebastelt, da fehlt aber deine IR header datei.

    Kannst du nochma schauen ob das alles so passt was du da hochgeladen hast?

    Danke
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 12 Juni 2013, 21:21:36
    Zitatrgbdriver.tar.gz ist der sketch für den panstamp per 'ino' auf kommandozeile kompilierbar.
    d.h. ich habe nicht die ide verwendet sondern die kommandozeilenversion von hier: http://inotool.org (//inotool.org)

    die ir lib hab ich vergessen. die gibt es hier: https://github.com/shirriff/Arduino-IRremote (//github.com/shirriff/Arduino-IRremote)

    sorry
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 12 Juni 2013, 21:32:30
    Ahh ok dann versuche ich es mal so, ist ja kein Problem.

    Man ich könnte kotzen ich find mein RGB Streifen nicht, ich hatte noch so ein kleines Stück zum testen und spielen... Ich sollte mal wieder von Kaffee auf Gingo Tee umsteigen...

    Gruß
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 12 Juni 2013, 21:40:00
    einen aller ersten test kannst du auch one externe leds machen. der sketch schaltet die kleine led auf dem rgb board an wenn die helligkeit > 0 ist und der status in fhem ist immer der echte status den die leds haben würden.

    zu ino: im verzeichniss rgbdriver 'ino build' zum kompilieren und 'ino upload' zum hochladen. in ino.ini musst du dazu noch den seriellen port anpassen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 12 Juni 2013, 23:47:39
    Ok danke.

    Ich werd morgen mal zum Chinamann fahren und ne Rolle kaufen. Dann kann ich auch gleich mal schauen ob es diese rgbw Stripes auch gibt.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 13 Juni 2013, 16:37:40
    Sag mal kann es sein das R und G vertauscht sind?!?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 13 Juni 2013, 16:46:40
    die pins laut Schaltplan (http://www.panstamp.com/downloads/rgb-driver.pdf (//www.panstamp.com/downloads/rgb-driver.pdf) passen zu zur pin definition im sketch und die werte die ich von fhem sende passen zum swap register im sketch.

    es kann natürlich sein das die beschriftnug auf dem board falsch ist.

    aber ich hatte schon stripes die falsch beschriftet waren. das halte ich fast für warscheinlicher.

    also am besten messen...

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 13 Juni 2013, 19:31:35
    Nö der Stripe stimmt, das habe ich gechecked, dachte ich zumindest...

    ...ABER der Stripe hat tatsache ein Ende wo die Beschriftung vertauscht ist und genau dieses Ende habe ich da dran, geil wa, naja original China eben, das ist das Gütesiegel... Die machen da wohl Handarbeite, ist billiger als Maschinen ...

    Btw. wie bekomme ich diesen Farbkreis hin? Ich sehe hier bei RGB kein Eingabefeld sondern nur die Auswahl zwischen RGB und Colorpicker oder sowas.

    Ansonsten geht alles, muss jetzt nur mal schauen wie du das mit dem Fader gemacht hast.

    Achso sagst du mir noch die PINS die du gerne hätteste für RGB und IR und DMX. Dann kann ich schonmal anfangen ein Modul zu basteln in Eagle. Ich muss nur noch passende Mosfets suchen, die BUZ11 find ich etwas übertrieben mit 30A.

    /Daniel

    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 13 Juni 2013, 19:45:15
    um den colorpicker zu bekommen müsste es reichen einmal 'reload 31_HUEDevice' einzugeben. wenn das nicht hilft definier dir einfach eine hue device. das sollte auch ohne bridge gehen. aussehen sollte es danach so:

    (siehe Anhang / see attachement)


    wenn das nicht geht schau mal ob man im logfile etwas sieht. das problem ist das ich den colorpicker nur ein mal global definieren kann und zur zeit steckt er halt im hue modul. das wollte ich sowieso noch umbauen.

    d9,d6 und d5 würde ich für rgb einfach beibehalten und d3 für weiss. für dmx würde ich d0 und d1 vorschlagen und für ir d4.  das müsste dann 3, 21, 20 für rgb sein, 18 für weiss, 16 und 17 für dmx und 19 für ir.

    im prinzip ist es mir aber ganz egal. in der software bin ich da flexibler :)

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 13 Juni 2013, 19:58:38
    Boa super, so ist schick ;-)

    Sag mal die Farben stimmen manchmal nicht im Browser, ich muss da immer F5 drücken beim Firefox.

    Wie im dem Anhang zu sehen ist es auch öfter mal asynchron. Beim nächsten Farbwechsel ist dann die letzte Farbe zu erkennen etc...

    Hast du das auch oder ist das bei mir jetzt ein Problem mit dem Browser Cache oder was auch immer?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 16 Juni 2013, 19:18:13
    kurzes update:

    in der neuesten version wird der status des led kontrollers jetzt auf off gesetzt wenn er sich in der eingestellten zeit nicht gemeldet hat. damit bekommt fhem jetzt (zwar etwas verzögert aber immer hin) auch mit wenn z.b. per normalem wand schalter aus geschaltet wird.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 16 Juni 2013, 19:36:20
    Du meinst jetzt wenn du den Controller Stromlos machst, oder dieser außer Reichweite ist oder wie?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 16 Juni 2013, 19:41:50
    ja. genau.wenn er stromlos wird. ausser reichweite im prinzip auch. aber das ist bei fest installation eher unwahrscheinlich.
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 17 Juni 2013, 23:12:17
    Zitat von: ntruchsess schrieb am Fr, 07 Juni 2013 00:45Ich portiere übrigens gerade die originale PanStamp python-library nach perl

    Hallo Andre

    ich will mich dann auch mal wieder melden. Ich habe in der Zwischenzeit o.g. library von python nach perl portiert. Findet sich im Branch 'device_panstamp' auf github

    das 'test.pl' ist ein kleines Beispiel, wie man die library einbindet. Man erbt von SwapInterface und überschreibt die gewünschten Callback-methoden über die man von der Library bei den verschiedensten Events aufgerufen wird. Der jeweils aktuelle Zustand des Swap-Netzwerks (also alle 'Mote'-objekte mit Ihrem aktuellen Register-inhalt) findet im property 'network' des Handler-objekts.

    Wenn man das so wie im test.pl initialisiert, dann wird der serielle Port in einem eigenen Thread bedient, das Handler-objekt datet sich beim Aufruf von poll() ab. Man kann die Event-handler alternativ auch aus dem Thread SerialPort-ojekts aufrufen lassen, dann muss man sich aber um das sharen der benötigten Werte selber kümmern.

    Kann im Moment genau das, was auch in Python ginge. D.h. Unterstützung für SwapStream habe ich noch nicht implementiert (kommt als nächstes). An der Konfigurierbarkeit muss ich auch noch mal arbeiten (die Python-library wird über xml-files konfiguriert. Ich möchte da natürlich alternativ eine Konfiguration als Hash übergeben können).

    Wirf einfach mal einen Blick darauf und sag, was du davon hältst.

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 18 Juni 2013, 11:17:47
    hallo norbert,

    das schaue ich mir auf jeden fall an. es kann aber sein das ich erst übers wochenende dazu komme.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 20 Juni 2013, 07:46:27
    Moin,

    mal eine Frage zu dem Fader, der überträgt ja doch ständig Funkdaten beim Faden, oder was ist das was ich da sehe?

    Und dann sag mal mit dem Fader hast du das richtig getestet und auch die Kennlinie des Auges mit beachtet? Irgendwie ist bei mir die Rotphase so kurz obwohl ich 1 FF0000 3, 2 00FF00 3 und 3 0000FF 3 durchlaufe. Wo habe ich denn da ein Fehler gemacht?

    Viele Grüße
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 Juni 2013, 08:46:17
    schau mal weiter oben im thread. da steht das der sketch zur zeit noch bei allen helligkeitsänderungen nicht schneller als alle 0.5s und höchstens 10mal zwischen zwei zuständen den aktuellen wert sendet. das ist noch zum testen drin. in der nächsten version ist das konfigurierbar.

    mommentan faded er linear zwischen  den werten im rgb farbraum. da ist noch keine gamma korrektur drin. bevor ich die einbaue wollte ich noch das faden noch (optional) im hsv farbraum machen. dann sollte bei den übergängen nicht immer wieder weiss auftauchen.

    da komme ich aber erst am wochenende zu. bin gerade unterwegs.

    versuch mal zwischen 1 und 2 noch ein '880000 2' einzubauen. das sollte erst mal etwas helfen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 20 Juni 2013, 13:07:49
    Ja du, ich hab das hier nur zum Testen aufm Tisch, da ist das kein Problem, ich spiel da im Moment nur ein bissel mit rum und wollte es daher mal wissen ja.

    Also kein Stress ;-)

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 23 Juni 2013, 23:50:13
    Zitat von: justme1968 schrieb am Di, 18 Juni 2013 11:17das schaue ich mir auf jeden fall an.

    Hallo Andre,

    heute hat's so viel geregnet, da bin ich mal ein ganzes Stück weiter gekommen. Im Branch 'device_panstamp' habe ich mittlerweile SwapStream-support implementiert und bin so Dinge wie automatischen retransmit angegangen. Das dazupassende Beispiel ist 'perl/swapstream.pl'. Funzt schon recht gut, nur kriege ich vom PanStreamHelloWorld.ino-sketch zum Bufferende hin korrupte Daten zurück wenn ich die vollen 51-bytes Nutzdatenlänge ausnutze.

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juni 2013, 17:48:42
    hallo norbert,

    hier war das Wetter (leider?) besser. und auch sonst gab es 1000 andere dinge und ich komme seit tagen nicht zu dem was ich mir vorgenommen habe.

    eigentlich wollte ich inzwischen zumindest deine lib probehalber aus fhem angesteuert haben. hoffentlich bald wirklich mehr als nur ein kurzes überfligen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juni 2013, 22:17:20
    so... langsam komme ich doch zu etwas aber bevor ich richtig angefangen habe bin ich prompt darüber gestolpert das du die reihenfolge der register geändert hast :)

    du musst ein bischen aufpassen mit den device xml files. am besten besorgst du dir bei daniel berenguer eine eigene developer id. wenn du meine id mit deinem namen verwendest finden die fhem module die device files nicht mehr weil der link über die id geht das file aber in einem directory mit dem namen gesucht wird.

    falls demnächst die neuen panstamp module mit mehr speicher rauskommen überlege ich ob man nicht eine kompimierte version des device files mit in den sketch packt und so dafür sorgt das es keine inkonsistenzen durch nicht passende lokale files gibt.

    ansonsten hab ich inzwischen die erfahrung gemacht das es viel handlicher ist für die konfiguration meherere swap register zu verwenden und nicht alles in ein register zu quetschen weil sich einzelne endpoints nicht unabhängig von einander setzen lassen ohne vorher das ganze register abzufragen. meine fhem module machen das zwar inzwischen halbwegs automatisch aber wenn es nicht aufs letzte byte ankommt und die endpoints nicht auch logsch etwas miteinander zu tun haben ist es anders einfacher.


    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juni 2013, 22:17:34
    doppelt gepostet ...
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 12:27:41
    Zitat von: justme1968 schrieb am Mo, 24 Juni 2013 22:17am besten besorgst du dir bei daniel berenguer eine eigene developer id.
    Das mit der nötigen eindeutigkeit der Developer-ids war mir bis vor kurzem etwas unklar, ich frage mal bei Daniel an. Meine perl portierung der swap-library möchte ich ja eh zu seinem panstamp-projekt contributen.

    SwapStream habe ich gestern abend noch ein bischen refactored, die klasse wird jetzt im registerValueChanged-callback aufgerufen, nicht mehr in swapPacketReceived. Das ist der logisch richtigere Platz. Die Arduino-library hat ein kleineres Update erfahren (eigene Packet-klasse, damit die destAddress in Status-paketen gesetzt werden kann).

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 12:38:21
    Appropos Speicherbedarf: ich habe den (noch unbestätigten) Eindruck, dass die Korruption-probleme bei etwas höheren Datenraten von Speichermangel hervorgerufen werden - die cc-pakete kommen ziemlich unkontrolliert interruptgesteuert in dynamisch allokiertem Speicher rein. Wenn da ein paar zuviel kommen, dann überschreiben die (vom oberen Ende her) die statischen Variablen (und damit auch den Sende- und Empfangspuffer des SwapStream). Mir ist noch nicht ganz klar, wie man das geziehlt untersuchen bzw. unterbinden kann außer das man das cc1101-modul bei Speichermangel abschaltet, dann aber im Gegenzug auch keine Daten mehr versenden kann. Debuggen auf dem PanStamp ist ja eher schwierig, weil das Serial-interface auch interrupt-gesteuert läuft und es dauernd Interrupt-überschneidungen mit dem cc1101-interrupts gibt. Im modem-sketch wird zu jeder Serial-kommunikation immer der cc1101-interrupt geziehlt abgeschaltet - wenn ich das richtig sehe ist der dazu nötige code offenbar kein Teil der öffendlichen API?

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juni 2013, 12:48:38
    ich hatte auch schon probleme mit den interupts bzw. in interupt handler zu viel zu tun. es reichen schon einige serial.print. wenn ich das auslagere in in der loop mache funktioniert es aber. ich weiss also nicht ob es wirklich der speicher ist. ich habe auch keine erfahrung mit embeddet systemem was das angeht. aber daniel hat vielleicht eine idee.

    die nächste version der panstamps wird doppelt so wie speicher haben. das hilft eventuell.

    daniel hat gestern schon einen link auf deine git repository auf die panstamp wiki seite gestellt.

    mehr wenn ich endlich dazu komme mehr als test.pl aufzurufen.

    gruss
      andre

    ach ja. noch was: ich habe bei meiner prel version progleme mit dem 'r' am ende von '~=s/.../gr' das du an ein paar stellen verwendest. ich hab auch keine doku dazu gefunden.

    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 13:51:00
    Zitat von: justme1968 schrieb am Di, 25 Juni 2013 12:48daniel hat gestern schon einen link auf deine git repository auf die panstamp wiki seite gestellt.
    schick :-)

    Zitatmehr wenn ich endlich dazu komme mehr als test.pl aufzurufen.
    nimm lieber mal die swapstream.pl, die ich (gestern?) mit committed habe ;-)

    Zitatprogleme mit dem 'r' am ende von '~=s/.../gr' [...] ich hab auch keine doku dazu gefunden.

    Im Regex-tutorial auf perldoc.perl.org findet sich:
    'If you don't want s/// to change your original variable you can use the non-destructive substitute modifier, s///r. This changes the behavior so that s///r returns the final substituted string (instead of the number of substitutions)'

    Muss ich mal sehen, ob man das einfach irgendwie anders substituieren kann. Was für eine Perl-version benutzt Du?

    Gruß,

    Norbert

    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juni 2013, 13:55:16
    ZitatWas für eine Perl-version benutzt Du?
    zum entwickeln den default auf meinem mac: This is perl 5, version 12, subversion 4 (v5.12.4) built for darwin-thread-multi-2level

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 16:11:37
    5.12.4 ist ja recht aktuell, das sollte der s///r modifier eigentlich tun :-( Naja, sollte sich mit einer einfachen Zuweisung an eine tmp-variable vor dem Anwenden der Regex eigentlich lösen lassen.

    Ich hab grade mal eine Verringerung der Paketgröße ausprobiert, wenn ich nur 36 Bytes 'Nutzlast' zulasse, dann gibts auch mit höherem Durchsatz keine Korruption mehr. Würde mich nur interessieren, wo ich (oder der PanStamp-stack) mir hier die Daten im hinteren Teil des Packets überschreibe, in der Theorie sollten die 51 Bytes (SWAP_REG_VAL_LEN-4) ja reinpassen.

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 22:41:32
    hier die erste lauffähige PanStampFirmata (//github.com/ntruchsess/arduino/tree/panstamp/examples/PanStampFirmata). Zum flashen erst mal einfach so compilieren, dann alles was man nicht braucht (I2C, OneWire, Scheduler, Servo, Stepper...) rauskommentieren und nochmal compilieren + hochladen. Alle Features passen zusammen mit PanStream nicht auf den PanStamp (wenn man keine Features streicht macht upload beim Verify einen Fehler).

    das dazu passende perl-beispiel (//github.com/ntruchsess/panstamp/blob/device_panstamp/perl/firmata-blink.pl) das Device::PanStamp (//github.com/ntruchsess/panstamp/tree/device_panstamp/perl) mit Device::Firmata (//github.com/ntruchsess/perl-firmata) zusammenführt und die Led an Pin 4 über PanStream und Firmata blinken läßt.

    (Man muss ein bischen Geduld mitbringen, die Initialisierung dauert wg. des langen transmit-intervals gefühlt ewig bis die LED dann endlich mal blinkt ;-)

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juni 2013, 23:09:16
    sehr geil...

    kannst du mir mal bitte ein wenig git nachilfe geben? ich habe gerade das problem das ich deine letzten änderungen nicht in meine ausgecheckte version bekomme.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ntruchsess am 25 Juni 2013, 23:20:54
    ein 'git pull origin' sollte eigentlich reichen.

    Falls Du den Branch an sich noch nicht ausgecheckt hast: 'git fetch origin device_panstamp', danach 'git checkout device_panstamp'

    Noch einfacher ist es 'git gui' aufzurufen. Dort gibt es den Menüpunkt 'Andere Archive'. Hier kann man mit 'anfordern von'->'origin' alle Änderungen auf einmal holen.

    Falls Du nicht weißt in welchem Branch Du gerade arbeitest: 'git status'...

    mit 'git help <command>' gibt detailierte Hilfe für die jeweilige Aktion. (Manchmal auch ein bischen zu detailiert...)

    Gruß,

    Norbert
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 28 Juni 2013, 22:46:31
    Nabend,

    sag mal ich bekomme neuerdings die Meldung "register 0F is not known" wenn ich den RGB Controller schalten möchte. Hat sich da irgend was bei FHEM geändert durch die Updates was stört?

    Gruß
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 28 Juni 2013, 23:33:36
    mach mal bittelist <device>
    get <device> deviceXML
    set <device> statusRequest
    set <device> readDeviceXML
    list <device>
    get <device> deviceXML

    die meldung kommt eigentlich nur dann wenn das device xml nicht geladen werden kann und das swap modul dann die register definition nicht kennt. da ist irgendetwas durcheinander gekommen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 29 Juni 2013, 08:45:10
    Mhh da tut sich nichts, aber es sieht jetzt auch nicht so aus als wenn ihm die XML fehlt.

    Ich finde in dem SWAP Modul keine Versionsinformation, hast du denn da vielleicht schon was Neues?

    Viele Grüße
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juni 2013, 09:07:32
    hast du den panstamp neu geflashed? laut ausgabe ist der beispielsketch von panstamp drauf und nicht meine version. es sollte developerid 22 und justme als developer auftauchen. nicht 1 und panstamp. wenn doch der richtige sketch drauf ist setz mal das productcode attribut auf 0000002200000003.

    eine neue version kommt bald.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 29 Juni 2013, 09:15:58
    Aha nee geflashed habe ich da nichts. Aber nach der o.b. Änderung geht es wieder, danke!
    Titel: Aw: panStamp support
    Beitrag von: fhainz am 30 Juni 2013, 18:29:20
    Hallo!

    Ich hab 2 Fragen zu panStamp, ich hoffe ihr könnt mir weiterhelfen.
     
    Es gibt ja ein Battery-Board mit eingebauten Temp. Sensor (TMP36 (//www.panstamp.com/products/battery-board-tmp36)). Dieses basiert ja auf einem "normalen" Battery-Board (//www.panstamp.com/products/battery-board). Auf dieser (//0cdf7099-a-3ce7cda5-s-sites.googlegroups.com/a/panstamp.com/panstamp/products/battery-board/battery-board_diagram.png?attachauth=ANoY7cr8b0boNVzs96U4rFXdQqzPszPX1lR8ytAO0UdM3CTJZACF8b5ulGMGlBW-WMuTULwggvRVBozgC1DI0h6wZ0G4GxKuHg4SagiLSY5zp6lFqjbmd_B4FrnXC3NFOlH3seIGCnlxJlE3m8KyeEQyDeUxab9PNslxX8V4tebiVM3FjV0jQxIGsL4EE3C_bZbhV5CP_VWJaLQombYCtRPZSDCSIqoCHyqENjsqL-hvxdiouZxT2W8lzb9j5FQ2z0BXdfu27KMv&attredirects=0) Zeichnung ist die Pin Darstellung zu sehen. Der panStamp hat ja 9 Digitale Eingänge oder? Warum sind auf dieser Zeichnung nur 6 Digitale Eingänge gezeichnet?

    Grüße
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 03 Juli 2013, 13:35:30
    Hi,
    Zitat von: justme1968 schrieb am Di, 25 Juni 2013 12:48die nächste version der panstamps wird doppelt so viel speicher haben. das hilft eventuell.

    ab wann sollen die denn verfügbar sein? Gibt es schon Ankündigungen? Ich würde solange warten bis diese rauskommen.
    Aktuell sieht es so aus:
    * Flash: 32 KB
    * RAM: 2 KB
    * EEPROM: 1 KB

    Btw: gibts einen sketch der eine Zustandsänderung eines/mehrerer Fensterkontakte übermittelt? Zusätzlich eine "alive" Zustandsmessage alle x Stunden?
    Hätte eine großes Fenster mit 9 Kontakten. Alle TFK´s zusammen wären es 14 Kontakte
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 03 Juli 2013, 13:49:55
    es gibt noch keinen termin. es ist auch nur doppelt so viel ram. flash und eeprom bleiben gleich. du kannst versuchen daniel berenguer zu fragen. das was du vor hast geht aber auch mit dem derzeitigen modell ohne probleme.

    es gibt ein bininps sketch. der fragt 8 pins binär und zusätzlich 4 binär und/oder als counter ab. er sendet sofort wenn wenn sich an einem pin etwas ändert und einstellbar regelmäßig ein alive.

    ich würde beim alive noch zusätzlich den batterie status mit senden. das fehlt bei diesem sketch aus irgend einem grund. das ist aber nur eine zusätzliche zeile.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 03 Juli 2013, 13:54:32
    @ fhainz: 8 digitale. d1 und d2 sind txd und rxd.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: fidel am 11 Juli 2013, 12:30:47
    Hallo,

    wird dieses Modul auch noch im SVN eingecheckt?

    Grüße
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 11 Juli 2013, 13:04:50
    ja. auf jeden fall.

    es sind noch  zwei punkte offen die ich vorher noch klären möchte.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: fidel am 11 Juli 2013, 16:51:51
    Super, dann weiter machen... ;) und noch ein großes Lob an deine/eure Arbeit hier...
    Ich muss mir erstmal die Hardware zulegen...
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 11 Juli 2013, 20:17:44
    @justme1968:

    Ich hab jetzt IRLR 024N da, ich werd mal versuchen ein RGB Board damit zu bauen. Das ist so ein bissel kritisch weil die PanStamps mit 3,3V Arbeiten. Da sind die meisten MOSFET's nocht nicht zu 100% durchgeschaltet. Ich würde das dann mit 5 Kanälen realisieren. Wie ist der Stand mit dem DMX? Bist du da schon weiter mit der Beschaltung? Für den IR Empfänger würde ich einfach ein Platinensteckverbinder vorsehen oder? Den setzt man ja ehe meistens ein Stück ab von dem Controller.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 11 Juli 2013, 20:35:27
    die dmx touch controller sind gestern gekommen. direkt in hong kong bestellt. machen einen guten ersten eindruck. den max485 und einen levelshifter habe ich schon da. ich hoffe ich komme am wochenende dazu das mal zusammen zu stecken. mal sehen wie das dann wird mit meinen zwei linken händen :)

    für ir wäre ein KF2510 stecker/buchse klasse. da geht der ir receiver entweder direkt rein oder per kabel abgesetzt. auf dem bild oben im thread siehst du wie ich es zur zeit mache.

    inzwischen hab ich gesehen das es den touch controller auch in einer 0-10v version gibt. das wäre natürlich einfacher gewesen. aber ich glaube dmx ist flexibler.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 12 Juli 2013, 23:23:25
    aller erster versuch mit einem mega2560 und noch ohne level shifter erfolgreich. der dmx empfang funktioniert einfach.

    mal sehen ob es morgen mit einem panstamp auch funktioniert.

    gruss
      andre

    ja. ich weiss... eigentlich nichts besonders. für einen software menschen aber trozdem geil wenn es geht :)


    (siehe Anhang / see attachement)
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 13 Juli 2013, 12:54:49
    und das ganze mit einem panstamp...

    die led beleuchtung lässt sich per touch controller -> dmx -> panstamp, per ir -> panstamp und per fhem -> panstamp bedienen. fhem kennt immer den aktuellen zustand auch wenn lokal per ir oder per touch controller bedient wird.

    jetzt fehlt nur noch die hardware vernünftig auf einem board zusammen zu fassen.

    gruss
      andre

    (siehe Anhang / see attachement)


    edit: ich hab gerade einen 3,3v rs485 transceiver gefunden. das würde den level shifter und die 5v versorgung überflüssig machen.
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 14 Juli 2013, 10:16:31
    Schick mal den Link wo du die DMX Controller bestellt hast.

    Ja mit den 3,3V ist auch eine Sache die mir so ziemlich auf den Sack geht. Zumal es dafür überhaupt keinen Grund gibt warum man nicht 5V Pegel benutzt, aber gut es ist nun so, was solls.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 14 Juli 2013, 10:46:34
    die sind direkt von sunricher. das ist der hersteller. der verschickt aber nur an firmenkunden und normalerweise nur ab 10 stück. beim ersten mal als samples auch weniger.

    es gibt das model aber auch bei ebay und diversen anderen shops. z.b. ledstudien.de. das dmx modell mit einer zone heißt sr-2811.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 14 Juli 2013, 11:03:11
    OK danke, jo naja ich kann auch gewerblich bestellen das ist kein Ding. Aber sehen ganz solide aus die Dinger, ist ne tolle Idee zumal bei mir eh viel über DMX läuft.
    Titel: Aw: panStamp support
    Beitrag von: PeterS am 14 Juli 2013, 13:34:08
    Hallo justme1968 und nano

    Ich nutze 2 Arduinos via RFM12b um meine Sensoren und Aktoren an Fhem anzubinden und zu steuern.
    Parallel laufen Homematic-Komponenten via Cul an Fhem.

    Mein Ziel ist es die Anzahl an Geräte bezüglich der Wartung zu reduzieren.

    Cool wäre es, wenn ein Arduino (Panstamp ??) einer Cul/CCU vorgaukeln könnte er sei ein oder mehrere Sensoren/Aktoren.
    siehe Thema Busware CC1101 Arduino shield (ARDCSM): Link (http://forum.fhem.de/index.php?topic=13744.0)

    Wäre so was denkbar ?

    Gruss Peter
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 14 Juli 2013, 13:47:22
    ja. im prinzip sollte das gehen.

    ich habe schon mal kurz versucht das cc1101 modul auf dem pansamp mit den rf parametern für fs20 oder homematic zu initialisieren. im netz gibt es sogar eine arduino firmware die angeblich homematic devices emuliert. dort könnte man die nötigen rf paramter auch rausziehen. die sind ziemlich identisch zu der aus der cul firmware.

    ich bin aber im ersten momment nicht weiter gekommen weil weder senden noch empfangen irgendetwas vorzeigbares gebracht haben und ich nicht die eventuell nötige hardware habe um mal nachzumessen. ich vermute die kommunikation (register,interrupts) zwischen cc1101 und arduino ist im swap mode anders realisiert als es die cul firmware erwartet.

    für jemanden der mit dem cc1101 erfahrung hat ist es vermutlich eine 'kleinigkeit' das problem zu finden. dann könnte man einen panstamp auf aktor seite fs20 oder hm kompatibel einsetzen (oder sogar auf fhem seite statt eines cul).

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: PeterS am 14 Juli 2013, 22:53:37
    Hallo Andre

    Klingt ja nicht unmöglich :-)
    Müsste man nur noch jemanden finden, der das Knowhow hat ?!

    PS: Danke für deine rege Informationen rund um den panStamp ! Schade nur, dass das 60$-Dollar Einsteigerangebot nicht mehr erhältlich ist :-(

    Gruss Peter
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 15 Juli 2013, 13:45:43
    schon gesehen das es einen Nachfolger des aktuellen Modells gibt?
    http://www.panstamp.com/announcements/imminentfuture (//www.panstamp.com/announcements/imminentfuture)
    Soll ab Septemper/Oktober im Webshop verfügbar sein. Beide Modelle sollen ein paar Monate parallel verkauft werden.
    Soll heißen, das aktuelle Modell läuft aus. Das wirft die spannende Frage auf, ob die SWAP-Module auch mit den neuen panstamps laufen...
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 15 Juli 2013, 14:06:12
    Heißt also noch ein paar alte bunkern, naja oder später selber nachbauen, Schaltpläne sind ja bekannt.

    Wobei ich nen Atmel besser finde als diese MSP Geschichte. Ich mag immer nicht tausende IDE's benutzen.

    Was das SWAP angeht, naja das kann doch bestimmt adaptiert werden. So viel anders werden die verwendeten µC ja auch nicht sein, also da würde ich mir jetzt weniger Sorgen machen. Ich hoffe nur das die Dinger Pinkompatible sind.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 15 Juli 2013, 14:40:44
    swap sowie alle fhem module werden natürlich laufen.

    was die ide angeht soll der support für die neuen chips in die gleiche ide eingebaut werden. also nichts zusätzlich.

    das panstsamp board ist im prinzip kompatibel und hat auch die gleiche grösse. ein vorteil der neuen version wird sein das sich alle funktionen wie pwm, uart, spi, ... freu auf jeden pin konfigurieren lassen und es eine feste zuordnung nicht mehr gibt.

    mehr sobald ich den ersten in den fingern hatte mehr :)

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 15 Juli 2013, 19:06:07
    Mhh sollte ich dann mit der RGB Platine lieber noch etwas warten?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 15 Juli 2013, 19:18:22
    also ich könnte direkt jetzt schon 3-5 für das aktuelle modell gebrauchen. bis jetzt schaut auch noch alles kompatibel aus und mit der planung kann man sicher auch weiter machen. aber wenn du auf nummer sicher gehen willst ist warten natürlich sicherer. fast wie mit dem verplungs schutz. aber jetzt bin ich mit der software auf der sichereren seite :)

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 16 Juli 2013, 07:36:53
    *lol* naja ich hab ja schon ein paar Dioden geordert. Ich hoffe der Spannungsabfall ist nicht so groß, aber die meisten "12V" Netzteile haben ehe eher 13V.

    Naja mal schauen, ich hoffe ich bekommt das noch hin demnächst.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 17 Juli 2013, 14:09:04
    ich habe eben die erste version der panStamp und SWAP module sowie die beispiel device description files eingecheckt.

    damit sollten wie oben beschrieben alle panstamp/swap devices generisch auf register ebene funktionieren. es werden für alle user register.

    fhem readings angelegt und diese automatisch per userReadings auf 'menschen lesbar' gemapped wenn es eine entsprechende beschreibung im device description file gibt.

    als beispiel für ein spezialsierteres modul gibt es das rgb driver modul von weiter oben. das checke ich demnächst zusammen mit dem sketch ein.

    achtung:der pfad zu den device description files hat sich noch mal geändert. es ist jetzt FHEM/lib/SWAP. falls jemand etwas an der alten stelle (FHEM/SWAP) stehen hat einfach löschen.

    achtung: die syntax zum define des panstick hat sich etwas geändert. bitte den <NETID> Parameter (B547) nach dem update entfernen.

    die module verwenden noch nicht norberts panStamp/SWAP lib. die umstellung wird warscheinlich dann kommen wenn der swapstream support so weit fertig ist.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 18 Juli 2013, 09:34:50
    es gibt noch ein kleines problem mit dem update und der directory struktur für die device description files.

    rudi muss noch mal hand anlegen bevor der update funktioniert...
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 19 Juli 2013, 12:53:52
    morgen sollte der update dann komplett funktionieren.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 20 Juli 2013, 07:47:02
    Hi Andre,
    habe jetzt die IDE und die Beispielscetche installiert. Kompilieren klappt auch soweit. Nur der Upload muss noch warten da die Ware noch unterwegs ist
    1. Frage: Welcher scetch muss auf den Panstamp der den Panstick betreibt?
    2. Frage: Ich habe hier auch einen MyAVR-Programmer mit einem 6-bzw 10er ISP-Anschluss. Damit würde ich am liebsten die panstamps programmieren. Sollte doch eigentlich funktionieren.Gibts irgendwo eine Verkabelungsanleitung?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 Juli 2013, 08:43:11
    1. der modem sketch.

    2. ja. das sollte gehen. die pinbelegung findest du hier: http://code.google.com/p/panstamp/wiki/panStamp (//code.google.com/p/panstamp/wiki/panStamp). von panstamp.com auf die wiki seiten und dann weiter.

    rein aus neugier: warum lieber den avr programmer statt dem panstick ?

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 20 Juli 2013, 09:08:04
    @Tobias: Ich mach das auch lieber über den ISP ;-) Dieses blöde Umgestecke in den USB Adapter da geht mir aufn Sack. Allerdings muss man dazu sagen das die neuen PanStamps leider nicht mehr auf AVR's basieren und somit wirst du dich früher oder später an den Bootloader gewöhnen müssen.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 20 Juli 2013, 09:40:22
    Zitat von: justme1968 schrieb am Sa, 20 Juli 2013 08:43rein aus neugier: warum lieber den avr programmer statt dem panstick ?
    Ganz einfach. Die produktive fhem instanz wo die panstamps eingesetzt werden sollen sind ca 10km entfernt. Und ich möchte ungern einen 2ten panstick kaufen ;)
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 20 Juli 2013, 10:17:49
    Dann benutze einfach ein RS232/USB Adapter und klemm den an RX/TX ran. Oder ein FT232, bauste dir quasi selber eine kleine Platine. Gibts aber auch kleine RS232/USB <-> TTL umsetzer fertig für einen kleinen Taler.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 20 Juli 2013, 15:00:12
    Ich habe hier eine Platine "FTDI Basic Breakout USB - UART TTL 3.3/5V with chipset FT232RL" die ich seinerzeit zum Deabianisieren/Consolezugriff für meine IomegaIconnect angeschafft hatte.
    Der würde sich für die serielle Programmierung wohl perfekt eignen.
    Danke & gruss
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 Juli 2013, 15:08:02
    ja. der panstick ist im prinzip auch nur genau so ein ftdi ft232rl usb/uart converter. du musst nur auf die 3.3v achten.

    wenn du seriell programmierst sparst du dir den boot loader selber zu brennen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 22 Juli 2013, 10:17:50
    Moin, sag mal die Module sind ja nun im svn aber dieser Colorpicker kommt dennoch nur wenn ich dieses HUE Modul lade. Kannst du das noch ändern? Oder mache ich da was falsch?

    Gruß
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 22 Juli 2013, 10:54:11
    des wegen sind auch erst die beiden grundlegenden module (panstamp und swap) im svn.

    das rgb modul checke ich ein wenn der colorpicker unabhängig geht. das muss ich noch machen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 22 Juli 2013, 11:00:18
    Ach stimmt das waren ja nur die generischen. Naja ok, kein Stress wa, dachte nur ich mach da wieder falsch falsch.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 24 Juli 2013, 08:25:41
    Hi,
    ein/zwei kurze Fragen zu einer selbstgebauten DrahtAntenne (//code.google.com/p/panstamp/wiki/antennalengths).
    1. Ist die angegebene Antennenlänge incl. oder excl. der Lötstelle die ja nocheinmal ca 3-4mm zusätzliche Länge ausmacht?
    2. Kann man die Antenne wie auf einigen Panstamp-Bildern gesehen als Spirale drehen um Bauhöhe zu sparen? Oder leidet dadurch die Empfangsqualität?
    3. Schlussendlich kann man die Empfangsqualität nur im FHEM-Modul in der internen Variable RSSI sehen, korrekt?

    Wenn die Empfangsqualität zu schlecht ist wäre eine Möglichkeit den Panstick an einen abgesetzten RasPi (mit WLAN) im Garten aufzustellen. Wie könnte man dann am besten den Panstick am RasPi an FHEM koppeln?
    Titel: Aw: panStamp support
    Beitrag von: rudolfkoenig am 24 Juli 2013, 08:38:11
    Zu 1/2 wuesste ich auch gerne etwas konkretes.

    Zu 3: RSSI (Received Signal Strength Indicator) ist Signalstaerke (==Lautstaerke), nicht Empfangsqualitaet.
    Vgl. mit laut reden bei lauter Musik oder bei Stille.

    Titel: Aw: panStamp support
    Beitrag von: betateilchen am 24 Juli 2013, 09:01:30
    zu 1. ohne Lötstelle. Du rechnest ja auch das Kabel nicht mit. Es spielt aber in diesem Frequenzbereich keine Rolle, ob man die Größe der Lötstelle mit einberechnet oder nicht.

    zu 2. Wenn Du eine Antenne aufwickelst, hast Du eine Spule und damit eine zusätzliche Induktivität. Dann muss die Länge anders berechnet werden. Das Prinzip nennt sich "Verlängerungsspule" und wird häufig bei Kurzwellenantennen eingesetzt, um deren mechanische Baugröße zu reduzieren.

    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juli 2013, 09:23:24
    zu 1. und 2. kann ich dir nichts sagen außer probieren.

    zu 3. zusätzlich zum rssi gibt es noch lqi (link quality indikator) als indikator der eigentlich genau das abbilden soll was du möchtest. das swap modul zeigt den wert auch an. ich bin mit aber nicht sicher wie aussagekräftig er ist. da jede swap nachricht eine sequenz nummer hat habe ich eingebaut das angezeigt wird ob und wie viele nachrichten verloren gegangen sind. ich denke das ist der beste indikator ob es verbindungspobleme gibt. fhem zeigt hier die eigenen enpfangswerte an. das sollte zwar meistens auf beiden seiten symmetrisch sein und nur relevant wenn es nicht um sensoren geht die eh nur senden.

    rein mechanisch den panstick einfach per usb anschließen oder statt dessen das board für den raspi verwenden. das ist aber noch ungetestet weil ich keins habe.

    die logische verbindung dann entweder per network usb (das will ich seit ewigkeiten schon mit einem cul probieren weil mein hmlan nur probleme macht) oder per netcat (da gibt es irgendwo einen post im forum) oder per fhem2fhem.

    oder man verwendet den panstamp am raspi nicht statt dessen sondern zusätzlich und aktiviert den repeater mode.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 24 Juli 2013, 09:34:23
    Moin,

    also zu 1. würde ich sagen ab da wo die Masseflächen neben der Seele nicht mehr vorhanden sind.

    /Daniel
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 24 Juli 2013, 18:43:25
    heute sind endlich meine panstamps eingetroffen :)

    Andre, du hast ja schnmal einen Vegetronix Bodenfeuchtesensor angeschlossen. Habe schon den soilmoisture-sketch geflashed.
    Stimmt eigentlich die Verdrahtungsanleitung (//www.panstamp.com/announcements/soilmoisturesensors) mit den im Sketch angegebenen Pins überein?
    #define SENSOR_0_PIN  3     // Analog pin - sensor 0
    #define POWER_0_PIN   16    // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  5     // Analog pin - sensor 1
    #define POWER_1_PIN   18    // Digital pin used to powwer sensor 1

    Ich will pro Panstamp nur Sensor0 nutzen. Sensor1 bleibt frei
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juli 2013, 18:57:17
    ich bin grad unterwegs deshalb nur kurz und ungenau...

    ich weiß noch das da etwas nicht zusammen gepasst hat und ich es geändert habe. ich weiß aber auswendig nicht mehr genau worauf. schau mal auf panstamp.com und dann im wiki. da gibt es ein bild mit der zuordnung zwischen hardware pins, arduiono pins und dem  panstamp layout. ich glaube ich hab das weiter oben schon mal verlinkt.

    die zweite sache die aendern musst ist das timing. auf der vegetronix seite steh bei den technischen daten wie lange der sensor braucht bis das messergebniss stabil ist. das ist deutlich länger als im beispielsketch.

    hmmm...  ich glaube das hab ich auch beides weiter oben schon mal geschrieben :)

    gruss
      andre

    edit: ich hatte in meine version  auch noch die batteriespannung als reading eingebaut. wenn du magst poste ich das spaeter.
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 24 Juli 2013, 20:47:21
    oh ja, poste mal bitte deinen Vegetronix-Sketch. Die Batteriespannung ist wichtig ;)
    Die 400ms habe ich auch schon gefunden und eingebaut.
    Was ich aber noch nicht gefunden habe, wo die Zeitspannen zwischen den Sendezyklen vorgeggeben ist. Ich möchte gerne einen Messwert alle 3min haben.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juli 2013, 20:55:51
    ok. mein sketch kommt nachher.

    das sende intervall einstellen geht aus fhem heraus per set <device> regSet.

    gruss
      ander
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 24 Juli 2013, 22:12:49
    ich hab gerade gesehen das die batteriespannung inzwischen in der normalen version drin ist. d.h. du solltest alles haben was du brauchst.

    das sende intervall setzt du mit set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl> aus fhem heraus. für die devices mit powerdown/sleep mode bleibt das kommando on der send queue. wenn du dann den panstamp ein mal per reset durchstartest wird das kommando gesendet und das kommando wird automatisch gesendet wenn die initialisierung durchlaufen wird. der wert landet im eeprom und das muss nur ein mal gemacht werden.

    mit den drei minuten würde ich an deiner stelle noch etwas spielen. ich vermute mal das alle 5 oder 10 minuten locker ausreicht und das das batterien spart.

    das ergebniss siehst du dann bei den internal values unter SWAP_0A-PeriodicTxInterval.

    auf die gleiche art solltest du ein mal die sensor addresse auf einen wert >01 und != FF setzen (00 ist broadcast, 01 ist der panstick am fhem system und ff ist die default adresse die jeder panstamp aus dem eeprom bekommt).

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 25 Juli 2013, 19:25:19
    Nachdem ich den panstamp definiert hatte (define panstamp panstamp /dev/ttyUSB0)
    kam folgende Fehlermeldung:
    2013.07.25 19:22:20 3: Opening panstamp device /dev/ttyUSB0
    2013.07.25 19:22:20 3: panstamp device opened
    Use of uninitialized value $val in sprintf at ./FHEM/34_panStamp.pm line 221.
    Use of uninitialized value $val in sprintf at ./FHEM/34_panStamp.pm line 230.
    Use of uninitialized value $val in sprintf at ./FHEM/34_panStamp.pm line 239.


    Und nachdem ich die Batterie in den Client (soilmoisture) eingelegt hatte kam folgendes:
    Illegal hexadecimal digit '�' ignored at ./FHEM/34_panStamp.pm line 453.
    Illegal hexadecimal digit 'n' ignored at ./FHEM/34_panStamp.pm line 455.
    2013.07.25 19:26:11 1: reload: Error:Modul 34_SWAP deactivated:
     Can't locate XML/Simple.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/34_SWAP.pm line 18.
    BEGIN failed--compilation aborted at ./FHEM/34_SWAP.pm line 18.

    2013.07.25 19:26:11 0: Can't locate XML/Simple.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/34_SWAP.pm line 18.
    BEGIN failed--compilation aborted at ./FHEM/34_SWAP.pm line 18.

    2013.07.25 19:26:11 0: ERROR: Cannot autoload SWAP
    2013.07.25 19:26:12 3: panstamp: Unknown code cc�C"b"c�b17�n��rbngn�C"B"c�r�ngn�cC"b"a�r�ncn�sC"B"a�b�nkn��C"""a�bcnknS�����Srcnon�C����[r�n�n���s��Srcn�n���s��Vr�n�nS�����[rcn�nCs����[bcn�n���s��bcn�nC��s��-b�7�n�s����Srcn�n������Srcncn�c�c��_bcncn�c�c��SbcngnSc����b�ngnSc����rcncnS��c��SrcnknSc�c��Srcnkn�c����r�non�c����r�n�����s��Srcn���c�s��Rb�n���c����b�n���c�

    usw....
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juli 2013, 19:30:48
    das schaut so aus als ob die kommunikation mit dem panstick klemmt.

    gib mal bitte die baudrate mit an (define panstamp panstamp /dev/ttyUSB0@38400)

    wenn das nicht hilft setz mal bitte global verbose auf 5 und mach dann ein 'modify panstamp /dev/ttyUSB0@38400' und zeig mir den log ausschnit wo der panstick initialisiert wird.

    gruss
      andre

    edit: ich denke es liegt an der baudrate.

    edit2: das swap modul braucht XML:Simple um die device description files zu lesen.

    edit3: und bitte die ausgabe von 'stty </dev/ttyUSB0'
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 25 Juli 2013, 19:37:41
    Habe in debian das Paket "libxml-simple-perl" nachinstalliert.
    Nach Änderung der Baudrate sieht es schon etwas besser aus:
    2013.07.25 19:34:49 3: SWAP Unknown device ©b, please define it
    2013.07.25 19:34:49 2: autocreate: define SWAP_©b SWAP ©b
    2013.07.25 19:34:49 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_©b
    2013.07.25 19:34:49 3: Opening panstamp device /dev/ttyUSB0
    2013.07.25 19:34:49 3: Setting panstamp baudrate to 38400
    2013.07.25 19:34:49 3: panstamp device opened
    substr outside of string at ./FHEM/34_SWAP.pm line 691.
    substr outside of string at ./FHEM/34_SWAP.pm line 692.
    substr outside of string at ./FHEM/34_SWAP.pm line 693.
    substr outside of string at ./FHEM/34_SWAP.pm line 694.
    Use of uninitialized value $raddr in hash element at ./FHEM/34_SWAP.pm line 698.
    Use of uninitialized value $rid in hex at ./FHEM/34_SWAP.pm line 704.
    Use of uninitialized value $func in hash element at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value $rname in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value $regname in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value $data in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value $raddr in string eq at ./FHEM/34_SWAP.pm line 741.
    Use of uninitialized value $func in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    Use of uninitialized value $raddr in hash element at ./FHEM/34_SWAP.pm line 744.
    Use of uninitialized value $rname in concatenation (.) or string at ./FHEM/34_SWAP.pm line 745.
    2013.07.25 19:34:53 3: SWAP Unknown device , please define it
    .....
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 25 Juli 2013, 19:39:53
    und weiter, fhem ist mir abgeschmiert musste neustarten...
    2013.07.25 19:39:00 3: Opening panstamp device /dev/ttyUSB0
    2013.07.25 19:39:00 3: Setting panstamp baudrate to 38400
    2013.07.25 19:39:00 3: panstamp device opened
    2013.07.25 19:39:05 3: SWAP_FF: I/O device is panstamp
    2013.07.25 19:39:05 3: SWAP_0F: I/O device is panstamp
    2013.07.25 19:39:05 3: SWAP_06: I/O device is panstamp
    2013.07.25 19:39:05 2: no device xml found for productcode 0FF0C01CB0218
    2013.07.25 19:39:05 2: no device xml found for productcode 0FF0C01CB0218
    2013.07.25 19:39:05 2: no device xml found for productcode 0FF0C01CB0218
    2013.07.25 19:39:05 3: SWAP_0A: I/O device is panstamp
    2013.07.25 19:39:05 1: Including ./log/fhem.save

    ein paar minuten später ging es weiter...
    2013.07.25 19:39:53 3: SWAP Unknown device , please define it
    2013.07.25 19:39:53 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:39:53 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:39:54 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:39:54 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:39:54 3: SWAP Unknown device , please define it
    2013.07.25 19:39:54 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:39:54 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:39:54 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:39:54 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:40:04 2: no device xml found for productcode C01DE0222
    2013.07.25 19:40:04 2: no device xml found for productcode C01DE0222
    2013.07.25 19:40:05 3: SWAP Unknown device 00, please define it
    2013.07.25 19:40:15 3: SWAP Unknown device F, please define it
    2013.07.25 19:40:15 2: autocreate: define SWAP_F SWAP F
    2013.07.25 19:40:15 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_F
    2013.07.25 19:40:22 3: SWAP Unknown device F, please define it
    2013.07.25 19:40:22 2: autocreate: define SWAP_F SWAP F
    2013.07.25 19:40:22 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_F
    2013.07.25 19:40:22 3: SWAP Unknown device , please define it
    2013.07.25 19:40:23 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:40:23 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:40:23 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:40:23 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:40:23 3: SWAP Unknown device 600FF0C01DC0222, please define it
    2013.07.25 19:40:23 2: autocreate: define SWAP_600FF0C01DC0222 SWAP 600FF0C01DC0222
    2013.07.25 19:40:23 1: define: 600FF0C01DC0222 is not a valid SWAP address
    2013.07.25 19:40:23 1: ERROR: 600FF0C01DC0222 is not a valid SWAP address
    2013.07.25 19:40:36 3: SWAP Unknown device F, please define it
    2013.07.25 19:40:36 2: autocreate: define SWAP_F SWAP F
    2013.07.25 19:40:36 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_F
    2013.07.25 19:40:37 3: SWAP Unknown device 0, please define it
    2013.07.25 19:40:37 2: autocreate: define SWAP_0 SWAP 0
    2013.07.25 19:40:37 1: define: 0 is not a valid SWAP address
    2013.07.25 19:40:37 1: ERROR: 0 is not a valid SWAP address
    2013.07.25 19:40:51 2: no device xml found for productcode C01DE0224
    2013.07.25 19:40:51 2: no device xml found for productcode C01DE0224
    2013.07.25 19:41:01 2: no device xml found for productcode C01E00227
    2013.07.25 19:41:01 2: no device xml found for productcode C01E00227
    2013.07.25 19:41:01 3: SWAP Unknown device A0, please define it
    2013.07.25 19:41:01 2: autocreate: define SWAP_A0 SWAP A0
    2013.07.25 19:41:01 3: SWAP_A0: I/O device is panstamp
    2013.07.25 19:41:01 2: autocreate: define FileLog_SWAP_A0 FileLog ./log/SWAP_A0-%Y.log SWAP_A0
    2013.07.25 19:41:19 3: SWAP Unknown device , please define it
    2013.07.25 19:41:19 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:41:19 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:19 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:19 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:26 3: SWAP Unknown device , please define it
    2013.07.25 19:41:26 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:41:26 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:26 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:26 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:33 2: no device xml found for productcode C01E00223
    2013.07.25 19:41:33 2: no device xml found for productcode C01E00223
    2013.07.25 19:41:33 3: SWAP Unknown device , please define it
    2013.07.25 19:41:33 2: autocreate: define SWAP_ SWAP  
    2013.07.25 19:41:33 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:33 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:41:33 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]

    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juli 2013, 19:42:39
    er hat am anfang als die baudrate nicht gestimmt hat alle möglichen devices angelegt die es so nicht gibt.

    am besten:

    erst mal die batterie raus

    dann bitte lösch mal alles was mit panstamp und swap zu tun hat.

    dann nur das panstamp device noch mal anlegen. das sollte komplett ohne fehler gehen.

    dann ein mal save.

    dann die batterie wieder rein.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 25 Juli 2013, 19:50:27
    Der Panstamp ist sauber initialisiert worden...
    Nach Einlegen der BAtterie kam folgendes:
    2013.07.25 19:47:34 3: Opening panstamp device /dev/ttyUSB0
    2013.07.25 19:47:34 3: Setting panstamp baudrate to 38400
    2013.07.25 19:47:34 3: panstamp device opened
    2013.07.25 19:48:45 3: SWAP Unknown device FF, please define it
    2013.07.25 19:48:45 2: autocreate: define SWAP_FF SWAP FF 000000010000000E
    2013.07.25 19:48:45 3: SWAP_FF: I/O device is panstamp
    2013.07.25 19:48:46 2: autocreate: define FileLog_SWAP_FF FileLog ./log/SWAP_FF-%Y.log SWAP_FF
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Argument "\00" isn't numeric in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    2013.07.25 19:48:58 3: SWAP Unknown device 0F, please define it
    2013.07.25 19:48:58 2: autocreate: define SWAP_0F SWAP 0F
    2013.07.25 19:48:58 3: SWAP_0F: I/O device is panstamp
    2013.07.25 19:48:58 2: autocreate: define FileLog_SWAP_0F FileLog ./log/SWAP_0F-%Y.log SWAP_0F
    2013.07.25 19:48:58 3: SWAP Unknown device 14, please define it
    2013.07.25 19:48:58 2: autocreate: define SWAP_14 SWAP 14
    2013.07.25 19:48:58 3: SWAP_14: I/O device is panstamp
    2013.07.25 19:48:58 2: autocreate: define FileLog_SWAP_14 FileLog ./log/SWAP_14-%Y.log SWAP_14
    2013.07.25 19:49:08 3: SWAP Unknown device F, please define it
    2013.07.25 19:49:08 2: autocreate: define SWAP_F SWAP F
    2013.07.25 19:49:08 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_F
    2013.07.25 19:49:16 3: SWAP Unknown device F, please define it
    2013.07.25 19:49:16 2: autocreate: define SWAP_F SWAP F
    2013.07.25 19:49:16 1: ERROR: Invalid characters in name (not A-Za-z0-9.:_): SWAP_F
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 735.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 735.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Argument "\00" isn't numeric in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Argument "E6" isn't numeric in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    2013.07.25 19:49:34 3: SWAP Unknown device 00, please define it
    Use of uninitialized value $found[0] in string eq at fhem.pl line 2672.

    usw... es läuft weiter das Log damit voll... Ideen?
    Edit: der letzte Eintrag ist der:2013.07.25 19:50:48 3: SWAP Unknown device , please define it
    Use of uninitialized value $raddr in string eq at ./FHEM/34_SWAP.pm line 746.
    Use of uninitialized value $data in concatenation (.) or string at ./FHEM/34_SWAP.pm line 747.
    Use of uninitialized value $rname in concatenation (.) or string at ./FHEM/34_SWAP.pm line 748.
    Use of uninitialized value $raddr in concatenation (.) or string at ./FHEM/34_SWAP.pm line 748.
    Use of uninitialized value $data in concatenation (.) or string at ./FHEM/34_SWAP.pm line 748.
    2013.07.25 19:50:48 2: autocreate: define SWAP_ SWAP
    2013.07.25 19:50:48 2: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:50:48 1: define: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    2013.07.25 19:50:48 1: ERROR: wrong syntax: define <name> SWAP <addr>[.<reg>] [<ProductCode>]
    Illegal hexadecimal digit '(' ignored at ./FHEM/34_panStamp.pm line 453.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Argument "E0" isn't numeric in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    Illegal hexadecimal digit ')' ignored at ./FHEM/34_panStamp.pm line 455.
    Use of uninitialized value in concatenation (.) or string at ./FHEM/34_SWAP.pm line 739.
    Argument "FF" isn't numeric in numeric eq (==) at ./FHEM/34_SWAP.pm line 742.
    substr outside of string at ./FHEM/34_SWAP.pm line 628.
    Use of uninitialized value in hex at ./FHEM/34_SWAP.pm line 628.
    2013.07.25 19:51:02 2: no device xml found for productcode B0633
    substr outside of string at ./FHEM/34_SWAP.pm line 786.

    Edit: ich mach jetzt erstmal Feierabend
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 25 Juli 2013, 20:01:41
    der anfang schaut schon mal sehr viel besser aus.

    der sensort wird richtig erkannt (000000010000000E) und versucht per autocreate anzulegen und bekommt das richtige iodev.

    aber dann kommen scheinbar nachrichten rein die im format nicht passen.

    bitte setz mal global verbose auf 4. dann werden die empfangen nachrichten geloggt. damit stimmt noch irgendetwas nicht.

    gruss
      andre

    edit: noch besser auf 5.

    edit2: und bitte die ausgabe von 'stty </dev/ttyUSB0'
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 26 Juli 2013, 07:39:46
    Hier die ausgabe:root@Iconnect:~# stty </dev/ttyUSB0
    speed 38400 baud; line = 0;
    min = 0; time = 0;
    ignbrk -brkint -icrnl -imaxbel
    -opost
    -isig -icanon -iexten -echo -echoe -echok -echoctl
    root@Iconnect:~#

    Stand von heute morgen, es wurden 4 Swap-Devices angelegt (siehe panstamp.jpg), eins davon das SWAAP_FF scheint das richtige zu sein (siehe swap_ff.jpg)
    Andre, was ist eigentlich das Default-Sendeintervall? Seit dem Initialisieren gestern abend wurden bis heute morgen (11h) keine messages empfangen.
    Ich bin heute abend erst wieder am Device vor Ort, aber wenn ich das SendeIntervall per RegSet einstelle, muss ich am Batterieboard einmal den Mini-ResetButton drücken damit der Panstamp aufwacht, sich neu initialisiert und das Paket entgegennimmt? Korrekt?
    set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
    Ich habe noch nicht ganz verstanden bzgl der Adresse des Panstamps ändern von FF auf <irgendwas>. Wie ist der korrekte RegSet Befehl? addr? Wenn ich es nicht mache wird es sicherlich Probleme beim zweiten Panstamp geben, korrekt? Wäre folgendes korrekt? Irgendwie muss das mal alles noch in die Doku oder ins Wiki rein... garnicht so einfach ;) ;) ;)
    set <device> regSet addr 02
    Da keine Messages empfangen werden kann ich leider das Log5 erst heute abend liefern
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 Juli 2013, 11:10:07
    also erst mal sorry für die anlaufschwierigkeiten. irgendetwas stimmt mit den nachrichten nicht und ich hab noch keine ahnung was. es scheinen 0-bytes oder zeilenumbrüche drin zu sein die da nicht hin gehören. und weil die nachrichten die grundlage für alles sind kann hinterher nicht mehr viel funktionieren.

    ja. SWAP_FF ist das richtige. die anderen sollten gar nicht da sein.aber auch beim richtigen steht in den internal values zum teil nicht das richtige. beim product code (register 0 steht z.b. die spannung aus dem 19:50 reading von register 0B statt dem richtigen 16 stelligen product code)

    aber von vorne:

    bei swap geht alle komunikation über 'register' das sind unterschiedlich lange werte die entweder nur gelesen oder gelesen oder 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 das sind steht jeweils in einem device description xml file unter .../FHEM/lib/SWAP.

    wenn ein device mit dem product code korrekt angelegt wurde kann man mit 'get <device> regList' bzw. 'get <device> regListAll' die user register bzw. alle register auflisten.

    in den system registern steht z.b. der productcode, die device adresse und das übtertragungs intervall. 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 (das wären dann zwischen 18 und 19 stunden).

    die inhalte der system register stehen als internal values im oberen bereicht der detail ansicht, die user register als readings im unteren. normalerweise werden beim autocreate alle werte abgefragt und angezeigt. das geht normalerweise ohne jedes zu tun. panstick rein -> broadcast -> discovery -> anlegen. bei devices mit power down mode erfolgt das das erste mal wenn sie strom haben.

    alle panstamps durchlaufen beim starten eine bestmmte einschaltsequenz. sie melden sich mit ihrem product code, devices mit power down mode durchlaufden dann eine 3 sekunden schleife und warten auf kommandos, dann werden normaler weise die regiser mit den sensor werten gesendet und die normale loop gestartet. power down devices gehen jetzt schlafen und wachen regelmässig auf um ihre werte zu senden. ich bin auf panstamp seite dabei diese sequenz zu standardisieren und power down devices regelmässig ein oder zwei mal am tag aufwachen zu lassen um kommandos zu empfangen. so das man nicht den reset knopf drücken muss wenn man sie nicht im zugriff hat.

    zur zeit müssen alle low level dinge wie register id oder register wert mit hex werten passieren. ich bin gerade dabei einzubauen das man auch 'vereinfachte' kommandos mit den register namen verwenden kann. zur zeit aber noch:set <device> regSet 0A <intervall in sekunden als 4 stellige hex zahl>
    set <device> regSet 08 <netzwerk id als 2 stellige hex zahl>


    die stty werte schauen richtig aus. ich hoffe in den log files sieht man was mit den nachrichten nicht stimmt und du verlierst nicht die geduld...

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 Juli 2013, 13:21:28
    es gibt jetzt einen ersten wiki artikel hierzu...
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 26 Juli 2013, 18:30:22
    Habe jetzt mal das Log auf 5 gestellt und am panstamp den Reset-Knopf gedrückt.
    Dann rauschten die Meldungen 5min lang durch (5,5MB) und dann war fhem abgeschmiert.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 Juli 2013, 19:21:56
    sag mal was ist das für ein system auf dem fhem läuft? das ganze log file ist eine einzige lange zeile ohne lf sondern nur mit cr.

    irgendetwas mit deinem sketch stimmt nicht. der sendet so schnell das fhem mit dem abarbeiten des empfangsbuffers nicht mehr hinterher kommt. und irgendwann nachrichten kaputt gehen.

    bitte schick mir mal den quelltext den du auf den panstamp gebrannt hast.

    gruss
      andre

    edit: hast du das gotoSleep in der loop am ende von soilmoisture.ino noch drin?
    welches arduino modell hast du in der ide ausgewählt?

    edit2: hattest du schon versucht das timeout und die adresse zu ändern?
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 26 Juli 2013, 19:43:45
    Hi,
    ich habe den panstamp noch mit den 10ms geflashed. Alles Test, noch hängt da kein Sensor dran.
    Ich habe den Panstamp nach deiner Anleitung in der IDE angelegt. Wird im Fenster angezeigt als: "Panstamp v2.0 (3.3V, 8Mhz) w/ ATmega328 on /dev/ttyUSB0"

    Den Panstamp mittels RegSet habe ich noch nicht eingestellt, anscheinend klemmt es ja schon vorher irgendwo..
    Ich habe gemäß Anleitung auf der panstamp WikiSeite alle DemoSketche in die IDE unter Examples/panstamp eingeladen
    Edit2: läuft auf einem DebianSystem, siehe Signatur
    Edit3: ich habe festgestellt, das das BatteryBoard einen leisen, aber sehr,sehr hohen frequenten Ton von sich gibt wenn der panstamp im sleepModus ist
    Edit4: Wenn ich den Sketch kompiliere ist er so groß: Binäre Sketchgröße: 8.028 Bytes (von einem Maximum von 30.720 Bytes)
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 Juli 2013, 20:47:09
    so wie die messages aussehen geht dein panstamp nie in den sleepmodus sondern sendet wie verrückt mehr als 20 nachrichten pro sekunde.

    die ide einstellungen schauen ok aus. und der sketch ist auch der ganz normale wie es ausschaut.

    das mit den fehlenden zeilenumbrüchen im log file ist sehr irritierend. aber hat nichts weiter mit dem problem zu tun denke ich.

    das setzen der adresse und des sende intervalls sollte troz allem funktionieren. in fhem die beiden regSetzen und dann erst die batterie rein.

    ich hab mal eine etwas geänderte version von soilmoisture.ino angehängt. da wird zum einen maximal jede minute ein mal gesendet. egal ob der sleep mode geht oder nicht und es wird
    die kleine led auf dem board eingeschaltet bevor der sleep mode aktiviert wird und danach wieder aus.

    ich kann gerade nicht testen was mit der led im sleep mode wirklich passiert. aber sie sollte entweder an oder aus sein. nicht so schnell flackern das sie gedimmt erscheint.

    gruss
      andre

    edit: ich habe gerade in 34_SWAP einen check eingebaut der versucht die kaputten nachrichten zu erkennen die durch den überlaufenden buffer erzeugt werden. damit sollte zumindest fhem nicht abstürzen.
    das eigentliche problem ist aber das viel zu schnelle senden. ich habe noch keine idee woran es liegt. ich hab daniele bernguer von panstamp auch eben danach gefragt.
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 26 Juli 2013, 21:12:10
    danke dir, morgen abend gehts weiter...
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 27 Juli 2013, 00:54:47
    daniele hat eventuell eine erklaerung gefunden. ich versteh zwar noch nicht warum es gerade dich betrifft und sonst scheinbar noch nicht aufgetreten ist aber vielleicht liegt es daran das dein system langsamer ist und deshalb das buffer voll laufen es erst bemerkbar macht.

    bitte versuch das sende intervall zu setzen. ein paar minuten sollten ok sein. also zb. in hex 0100 sekunden oder so. das sollte auch mit dem sketch gehen der jetzt drauf ist und zu viel sendet. erst das regSet und dann die batterie rein. der wert wird dann in der 3 sekunden initialisierungsaequenz übertragen. da ist ja noch alles ok.

    gute nacht
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 27 Juli 2013, 06:45:39
    Hi,
    nachdem ich das sendeintervall auf 0200 gestellt habe, scheint es ruhiger zu sein. Ich teste noch weiter
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 27 Juli 2013, 10:08:48
    das sieht deutlich besser aus.

    bei den internal values stehen noch ein paar falsche werte aber das ist vermutlich weil du fhem nicht neu gestartet hast. bei den readings sind auch ein paar falsch. die kannst du dann löschen wenn alles geht.

    ps: die led zeigt den sleep mode an. gesendet wird trotzdem nur maximal ein mal die minute. ich hatte in dieser version beides entkoppelt um ganz sicher zu gehen. nicht vergessen wieder den original sketch zu verenden. auch wenn die led winzig ist ist es für die batterielebensdauer besser ohne. auch die adresse solltest du noch ändern. beim mneu flashen bleiben adresse und intervall im eeprom erhalten. du musst sie also nicht neu setzen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 27 Juli 2013, 13:28:18
    jetzt wird pünktlich alle 10min gesendet :)

    kurze Zwischenfrage, wenn gemäß Intervall gesendet wird, werden vorher etwaige Befehle (regset) abgeholt?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 27 Juli 2013, 13:37:25
     der sketch empfängt zur zeit nur wärend der initialisierung nach dem reset.

    wie oben schon geschrieben hab ich im panstamp forum vorgeschlagen die startup sequenz genauer zu standardisieren und in dem zusammenhang auch den empfangsmodus nicht nur beim start sondern 1-2 mal am tag zu aktivieren.

    ich glaube ich muss einfach mal ein beispiel dafür posten.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 28 Juli 2013, 13:26:29
    Problem beim Setzen der NetzwerkID:
    set SWAP_FF regSet 08 02
    --> register 08 is readonly
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 28 Juli 2013, 13:31:33
    mein fehler. 08 ist falsch. es muss 09 sein. DeviceAddress und nicht NetworkID.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 28 Juli 2013, 19:37:19
    Danke, damit funktioniert es. Schön ist, das man in den Internals das AdressRegister ablesen kann :) Hab ich jetzt erst gesehen....
    SWAP_0A-PeriodicTxInterval    012C

    Edit: ich möchte per UserReading ein BatterieIndikator einbauen, wie man es auch von MAX oder HM kennt.
    Kann man sagen das unter 1Volt die Batterie gewechselt werden sollte? Oder 0.9V oder 0.85V? Was meinst du? (für Vegetronix VH400, unter 7mA, mindestens 3.3V)
    Wenn ich richtig gelesen habe kann das Batterieboard bis 0.8V Batteriespannung eine stabile 3.3V Spannung bereitstellen
    Titel: Aw: panStamp support
    Beitrag von: fidel am 28 Juli 2013, 20:53:16
    Hallo,

    ich habe Probleme mit meinem PanStick.
    Dieser wird einfach nicht von Fhem und meiner Fritzbox erkannt nachdem ich ihn wie in der Commandref beschrieben, angelegt habe. Der angelegte PanStick erscheint immer mit "disconnected".
    Mit Putty habe ich auch schon den Befehl "modprobe usbserial vendor=0x0403 product=0x6001" auf meiner 7390 ausgeführt.
    Unter dem Verzeichnis /dev/... erscheint jedoch nichts mit ttyUSB0

    Den Stick habe ich mit "define panStick panStamp /dev/ttyUSB0@38400" in Fhem definiert, auch schon mit Address Channel und Syncword.

    Kann mir jemand auf die Sprünge helfen?

    Grüße
    Steven
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 28 Juli 2013, 21:16:08
    ich habe keine fritzbox deshalb kann ich dir nicht wirklich speziell für die fritzbox helfen.

    allgemein unter linux ist es aber normalerweise so das die files unter /dev nicht automatisch angelegt werden sondern von hand.

    bei 'cat /proc/devices ' sollte in der liste ein  ttyUSB auftauchen. normalerweise mit der nummer 188.

    das device wird dann mit 'mknod /dev/ttyUSB0 c 188 0' angelegt.

    für den panstick brauchst du auch das ftdi_sio modul. ich weiss nicht ob das auf der fritzbox da ist und automatisch geladen wird.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 08:21:06
    Hab das wiki (Erstbetrieb) um 1-2 Sätze erweitert.

    Ansonsten siehts bei mir gut aus... die Tage werde ich noch die anderen 3 panstamps mit eine 1/2 Antenne beglücken und den Soilmoisture Sketch flashen.
    Leider kann ich selbst kein C(++) um den Sketch erweitern zu können.

    Aber noch eine Frage an die Antennen-Kenner: der anschluss des SMA-Connectors hat 3 Lötpunkte. Mittig die eigentliche Antenne und außen die Masse. Frage ist nun, ob die beiden außenliegenden Masseflächen direkt verbunden sind oder diese bei einer Antennenverlängerung als Schleife genutzt werden??

    Hintergrund ist, das ich die antenne erst ca 5cm verlängern will und dann erst die abstrahlung stattfinden soll. Muss ich dann die Kabelabschirmung nur einfach mit einer der Masseflächen verbinden oder muss der Schirm an den einen Lötpunkt und über ein zurückführendes Kabel an den anderen Lötpunkt??
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 08:47:28
    schön das es jetzt geht.

    ich werde direkt in das swap modul einbauen das für neue panstamps das sendeintervall automatisch auf einen unkritischen wert gesetzt wird. dann wird autocreate auch bei einem fhem system funktionieren das nicht schnell genug ist und das anlegen von hand unnötig machen. ich habe auch eine idee für das automatische setzen der adresse beim ersten mal. beides zusammen sollte den einstieg deutlich erleichtern. ich habe inzwischen mehr als 10 devices an zwei fhem sytemen per autocreate angelegt und das hat so viele vorteile das ich das gerne für so viele fälle wie möglich hin bekommen möchte.

    was fehlt dir denn in dem sketch? sammel doch mal deine ideen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 09:24:17
    Ist warscheinlich wegen der Fritzbox-Diskussion untergegangen:
    Zitat von: Tobias schrieb am So, 28 Juli 2013 19:37Danke, damit funktioniert es. Schön ist, das man in den Internals das AdressRegister ablesen kann :) Hab ich jetzt erst gesehen....
    SWAP_0A-PeriodicTxInterval    012C

    Edit: ich möchte per UserReading ein BatterieIndikator einbauen, wie man es auch von MAX oder HM kennt.
    Kann man sagen das unter 1Volt die Batterie gewechselt werden sollte? Oder 0.9V oder 0.85V? Was meinst du? (für Vegetronix VH400, unter 7mA, mindestens 3.3V)
    Wenn ich richtig gelesen habe kann das Batterieboard bis 0.8V Batteriespannung eine stabile 3.3V Spannung bereitstellen

    Meine Ideen bzgl Erweiterung:
    1. Bis zur maximalen Kapazität des panstamps anschließbare Sensoren. Müssen ja keine Bodenfeuchtesensoren sein, sondern nur welche die eine Spannung 0 - 3.3V abgeben.
    Ich habe zb. abgesetzt am Gartenhaus 4 große 2m lange "Särge" in denen Tomaten unter einem Dach wachsen. Würde also 4 Sensoren anschließen.

    2. hattest du auch schon als Idee, 1-2mal täglich Anfragen des Pansticks beantworten (regSet). Wenn möglich ebenfalls über regSet und Userregister setzbar

    3. bei Pulsecounter: ich bin grundsätzlich dafür die Zählerstände beim Stromausfall in Hardware zu sichern. Auch FHEM kann einmal alles verlieren. Deshalb bin ich auch glücklich darüber das es beim DS2324 AVR-Erstz eine eeprom-Sicherung jetzt gibt. (Ein Eingang des ATTiny ist mit 10K an VCC gebunden sowie mit 100uF gepuffert) Wenn man also einen Stromabfall beim panstamp feststellt, sollten die Zählerstände im eeprom gesichert, beim Init daraus ausgelesen und von dort aus weiter gezählt werden.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 09:55:56
    es gibt glaube ich (noch?) keine aussage wann die batterie wirklich schlapp macht. ich fürchte es hängt auch nicht nur von der spannung ab sondern auch von der 'qualität' der batterie. das verhalten  wird auch bei unterschiedlichen sketches unterschiedliche sein. ich könnte mir vorstellen das die änderungsrate ein mindestens so wichtiger indikator ist wie der absolutwert. d.h. wenn es zu ende geht vermutlich sehr schnell und plötzlich. wenn der sensor im 'freien' betrieben wird spiel sicher auch die temperaturschwankung zwischen tag und nacht eine rolle und linear ist das ganze vermutlich auch nicht.

    wenn ich das ins swap modul direkt einbaue könnte man ein paar mehr dinge berücksichtigen als nur eine feste schwelle. wie wäre es mit zwei schwellen? ein mal warning und ein mal error?

    ich habe bei meinen sketches eingebaut das die interne temperatur noch als reading zur verfügung steht. vielleicht kann man die auch mit verwursten. die dinger werden ja so gut wie gar nicht warm und im power down mode erst recht nicht. d.h. es ist eine viel viel bessere annäherung an die umgebungstemperatur als z.b. bei einem raspberry pi.

    mein luftdruck sensor läuft übrigens schon fast 3 monate und ist von 1.6 auf 1.54 runter.

    um hier wirklich sicher zu sein sollte man auf jeden fall auch das ausbleiben der nachrichten überwachen. z.b. keine nachricht im eingestellten intevall *10. ich glaube das baue ich direkt ins swap modul ein.

    1. das sollte kein problem sein. ich kann dir einen sketch bauen das jeden analog eingang als register sendet und ein config register hat bei dem man pro eingang ein bit setzen kann wenn er berücksichtig werden soll. die frage ist ob man gleich den bininp sketch erweitert dann hätte man einen sketch für alles.

    2. ja. das kommt auf jeden fall.

    3. das funktioniert vermutlich nicht ohne zusätzliche beschaltung. aber ich werde es daniel für die nächste version des batterie boards vorschlagen.
    ich kann aber mal versuchen das in den sketch einzubauen wenn du es probieren magst. eine weitere möglichkeit wäre es das regelmässig z.b. ein mal am tag zu machen. z.b. immer wenn ds ding aufwacht und auf anfragen wartet.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: fidel am 29 Juli 2013, 10:04:44
    Hi,

    nur zur Info habe den PanStamp an der 7390 zum laufen bekommen, indem ich den hinteren USB Anschluss genommen habe!?!?!
    Und in der Fritzbox den USB Ferngeräte-Anschluss deaktiviert habe.
    Am seitlichen Anschluss wurde er laut lsusb nicht erkannt.
    Der ftdi_sio Treiber ist auf der Box schon vorhanden.


    Grüße
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 10:50:08
    ich habe hier ein Notify welches auf *.:battery laucht und mir eine Mail schickt wenn ein Reading <> ok lautet.
    Es würde also etwas bringen wenn das SWAP-Modul ein Reading "battery" bereitstellt. 2 Schwellwerte hört sich noch besser an ;)
    Ich denke die angepassten Sketche für den jeweiligen Anwendungsfall sind schon eine gute Sache. Für Speziallösungen muss man dann den bininp-Sketch nutzen.

    Bzgl. Datensicherung im eeprom: Mir persönlich reicht es wenn es auf der ToDo Liste der nächsten BatteryBoard-VErsion steht. Da wo ich z.Z. PulseCounter benötige habe ich 1Wire zu liegen.

    So nebenbei beobachte ich hier die Readings und Updates derer. Mir fallen die unterschiedlichen Timestamps auf. Kann das sein, das der panstamp im angegebenen Intervall, aber nur die die Änderung sendet? Oder ist noch etwas bei mir falsch konfiguriert? Ich habe noch keine Sensoren angeschlossen, deshalb dieser niedrige Wert.

    (siehe Anhang / see attachement)

    Im übrigen: VWC heißt VolumetricWaterContent (danke an pah für die Formel) und gibt die Bodenfeuchte bei Nutzung der Vegetronix VH400 Sensoren in % an.
    VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**4 + 7.10835 * (hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**2 - 0.569557) / ((hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**2 + 1))}
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 11:18:53
    Zitat von: Tobias schrieb am Mi, 24 Juli 2013 18:43Stimmt eigentlich die Verdrahtungsanleitung mit den im Sketch angegebenen Pins überein?
    #define SENSOR_0_PIN  3     // Analog pin - sensor 0
    #define POWER_0_PIN   16    // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  5     // Analog pin - sensor 1
    #define POWER_1_PIN   18    // Digital pin used to powwer sensor 1

    Ich will pro Panstamp nur Sensor0 nutzen. Sensor1 bleibt frei

    Ich hänge gerade beim Verständnis der der Pin-Konventionen.
    Laut Anleitung ist der Sensor an A4/A5 abgeschlossen. Man sieht hier, das A4/A5 = PC4/PC5 bzw Pin 9/10 ist. Wie zum Kuckuk kommt man dann im Sketch auf "#define SENSOR_0_PIN  3"??
    Und was ist Pin 16/18? Es gibt auf dem BatteryBoard nur A0 bis A5 und D3 bis D9
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 14:32:29
    die readings 0B und 0C sind falsch. wenn kein register name dabei steht fehlt das ProductCode Attribut. hattest du nach dem setzten gespeichert?

    die userReadings die automatisch angelegt werden gehen jeweils auf den kompletten namen (id-name).

    bitte setze mal das attribut ProductCode auf 000000010000000E und lösche danach die beiden readings 0B und 0C. wenn das nicht hilft schick mir bitte mal ein list vom device.


    wenn alles passt (readings mit id und namen und die dazugehörigen userReadings) sollten die timestamps gleich sein.


    was die pins angeht muss ich heute abend zuhause in ruhe nachschauen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 16:03:15
    ich habe gleich eine version des swap moduls fertig die automatisch das default sende intervall auf eine stunde setzt wenn es noch der default ist und versucht eine freie adresse in einem vorgegebenen zu setzten falls es noch die default adresse ff ist.

    magst du das probieren wenn ich es fertig getestet habe? meinst du weniger als eine stunde ist besser?

    gruss
      andre

    edit: falls du es testen willst hab ich mal die neue version angehängt. der timeout wird nicht mehr auf eine stunde sondern 15 minuten (0384 = 900 sekunden) gesetzt.
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 19:16:07
    Hi,
    klar teste ich es... muss eben noch schnell die restlichen panstamps eine Antenne anlöten und dann gehts los...
    Hast du ev. schon was bzgl dem Pin-Mapping rausbekommen?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 19:35:52
    rausgefunden noch nicht. aber mir ist wieder eingefallen das ich das gleiche problem hatte.

    ich habe dann bei meinem test die beiden pins einfach auf etwas gesetzt das mir logisch erschien.

    sobald ich an den rechner komme sag ich dir genaueres.
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 19:57:45
    So, getestet... leider nicht ganz. per Autocreate wurde zwar ein Device SWAP_A0 angelegt, die addr bzw DeviceAddr blieb FF, auch das SendeIntervall blieb auf FFFF. Musste wieder abbrechen und manuell A0 setzen.
    Jetzt hab ich noch 2 unbenutzte Panstamps um zu testen.

    kurze Frage, Beim autocreate wird das Device mit einer Definition: FF 000000010000000E
    angelegt, wozu dann noch das Attr ProductCode?
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 29 Juli 2013, 21:06:03
    arg... das kommt davon wenn man auf dem trockenen testet. anbei noch mal eine version mit der es bei mir mit drei panstamps funktioniert hat. 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. im log sollte etwas in der 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

    das ganze hat hmmm historische gründe :) am anfang gab es nur das attribut. wie autocreate funktioniert hab ich erst später rausgefunden. aus dem code heraus ist es aber einfacher auf das attribut zuzugreifen. also wird das attribut jetzt eigentlich automatisch gesetzt wenn es in der definition da war. es gab aber bis eben einen fehler das es beim ändern der adresse wieder aud dem def verschwindet. das habe ich eben gefixt.

    ich hab dir auch noch eine etwas geänderte version vom soilmoisture.ino angehängt. die geht etwa alle 12 stunden in den sync mode und wartet für 3 sekunden auf kommandos.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 29 Juli 2013, 21:34:59
    Hi Andre,
    komme morgen Abend wieder dazu die panstamps zu flashen.
    Wollte heute Abend noch dem BatteryBoad 2x 3-polige Anreihklemmen verpassen, musste aber mit Schrecken feststellen das meine mit Rastermass 5mm  nicht passen.. grrrr
    Mit dem Zollstock gemessen müsste es ein RM von 3.5mm sein. Was hast du für welche drauf?

    Edit: wär schön wenn du zum Pin-Mapping was finden könntest
    Titel: Aw: panStamp support
    Beitrag von: fidel am 30 Juli 2013, 14:47:43
    Hi,

    ist es möglich im Sketch für das RGBDriver Board zu berücksichtigen, dass es nach dem Anschalten wieder den Zustand vor dem Einschalten annimmt?

    Grüße
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 15:39:24
    das sollte schon gehen.

    register 0E PowerOnState:
     - 1. byte: 0-> aus, 1-> weiss, 2-> eine bestimmte farbe, 3 -> autosave
     - 2. byte: helligkeit
     - 3-5. byte rrggbb

    du kannst z.b. mit  'set <device> regSet 0E 0200FFFFFF' einstellen das nach dem einschalten alle drei farbkanäle voll aufgedreht werden.

    oder mit 'set <device> regSet 0E 0300000000' autosave aktivieren. dann wird jeweils nach 5 minuten ohne änderung die aktuelle farbe ins eeprom gesichert. die 5 minuten könnte man eventuell noch verkürzen.

    für autosave ist am anfang der loop das schreiben ins eeprom zu aktivieren (das '#if 0' in ein #'if 1' ändern). an dieser stelle kannst du auch die 5 minuten anpassen.

    wenn ich die erweiterung auf 4 bzw. 5 kanäle fertig habe stelle ich die neue version  hier rein. dann wir das alles auch ein bischen einfacher zu konfigurueren sein.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 18:15:28
    so...

    zum einen ist das bildchen natürlich falsch: der grüne vom oberen sensor auf dem bild sollte nach a3 und nicht nach a4 wenn es zum sketch passen soll,  zum anderen sind die 16 und 18 für die digital pins falsch. es muss 7 und 6 sein.


    wenn es also zum bild passen soll muss es so aussehen:

    #define SENSOR_0_PIN  4     // Analog pin - sensor 0
    #define POWER_0_PIN   7     // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  5     // Analog pin - sensor 1
    #define POWER_1_PIN   6     // Digital pin used to powwer sensor 1

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 30 Juli 2013, 19:15:53
    Hi Andre,

    du sagt mal die aktuelle Firmware für das RGB Board, wo finde ich die immer?

    Ich sehe hier immer "SWAP_Sent_unconfirmed: 15 Sent_unconfirmed" und sowas, aber ich hab vermutlich auch eine sehr alte Version auf meinem Board. Btw. sehe ich irgendwo den Firmwarestand?

    Viele Grüße
    Daniel
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 30 Juli 2013, 20:07:26
    Test mit neuem SWAP Modul und neuer Ino Datei:
    Bei einem neuen Panstamp wird das Sendeintervall auf 0394 gesetzt: ok
    Das Device wird als F0 angelegt, die Adresse bleibt aber FF.
    Mein letzter hatte auch F0, der wurde vom Swap-Modul bei der Auswahl einer freien Adresse nicht erkannt und wurde demzufolge überschrieben.
    Ich denke, die FF Adresse könnte auch bleiben. Das Sendeintervall ist viel wichtiger ;)
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 30 Juli 2013, 20:10:51
    Hi Andre,
    Zitat von: justme1968 schrieb am Di, 30 Juli 2013 18:15wenn es also zum bild passen soll muss es so aussehen:

    #define SENSOR_0_PIN  4     // Analog pin - sensor 0
    #define POWER_0_PIN   7     // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  5     // Analog pin - sensor 1
    #define POWER_1_PIN   6     // Digital pin used to powwer sensor 1

    Ich vermisse die Angabe ob Pin4 A4 oder D4 vom Batterieboad ist. Oder ist Power implizit als DigitalPort und SensorPort implizit als Analogport festgelegt?
    Ist also die Angabe immer auf das Batterieboard bezogen oder auf die Pins als Arduino oder Atmega?
    https://0cdf7099-a-3ce7cda5-s-sites.googlegroups.com/a/panstamp.com/panstamp/pinmap.png
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 20:33:22
    beim autocreate versucht er den namen zu vergeben der zur nächsten freien adresse passt. aber die adresse ist erst mal trozdem ff. erst wenn das device angelegt wird kann dann versucht werden automatisch die adresse zu setzen. hoffentlich auf die gleiche freie die beim namen auch schon gefunden wurde.


    bei diesem sketch wird für power jeweils ein digital port und für sensor jeweils ein analog port verwendet. da die pins dann jeweils mit den arduino funktionen verwendet werden sind es die arduino pins. power 4 wäre d4 also nicht der gleiche pin wie sensor 4.

    also:
    sensor 4 -> a4
    power 7 -> d7
    sensor 5 -> a5
    power 6 -> d6


    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 20:48:04
    es gibt noch keine 'offizielle' stelle für die firmware. ich wollte sie ins fhem contrib verzeichnis packen. hast du eine bessere idee?

    du kannst mit 'get <device> listUnconfirmed' die kommandos auflisten die schief gegangen sind. und mit 'set <device> clearUnconfirmed' die liste löschen. es sollte aber nicht weiter stören.

    die firmware version siehst du in der detail ansicht als 'SWAP_02-FirmwareVersion'. ich habe aber noch nicht angefangen die auch hoch zu zählen. damit wollte ich anfangen wenn die beiden zusätzlichen kanäle dran sind und es irgendwo zum runterladen ist

    ich hab dir mal die aktuelle version angehängt. falls du mit dmx spielen willst kannst du den ENABLE_DMX aktivieren. die dmx lib dazu findest du hier :http://www.mathertel.de/Arduino/DMXSerial.aspx (//www.mathertel.de/Arduino/DMXSerial.aspx)

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: fidel am 30 Juli 2013, 21:39:16
    Hi Andre,

    irgendwie funktioniert das nicht so recht.

    Ich habe den Sketch an der Stelle void loop von #if 0 auf #if 1 angepasst und dann ein 'set <device> regSet 0E 0300000000' gemacht, mehr als 5 min gewartet und dennoch schaltet der Led Streifen weiß ein.
    Auch bei set <device> regSet 0E 0200FF00FF schaltet er mit weiß ein.

    Diese Stelle habe ich auf #if 1 angepasst.

    void loop()
    {
    #if 0
      static unsigned long last_eeprom_time = millis();
      if( regTable[REGI_POWER_ON_STATE]->value[0] == STATE_AUTOSAVE
          && !isFading()                                             // if not fading
          && rgbLed.timestamp() > last_eeprom_time                   // and color has changed
          && millis() - rgbLed.timestamp() > 1000 * 60 * 5 )  

    Habe ich etwas falsch gemacht oder hast du noh eine Idee?

    Grüße
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 21:54:37
    die stelle ist richtig.

    was steht in 0E ?

    mach mal bitte ein list auf das device.

    nur zur sicherheit: einschalten bedeutet vom strom trennen und wieder verbinden.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: ext23 am 30 Juli 2013, 22:01:10
    Zitat von: justme1968 schrieb am Di, 30 Juli 2013 20:48die firmware version siehst du in der detail ansicht als 'SWAP_02-FirmwareVersion'. ich habe aber noch nicht angefangen die auch hoch zu zählen. damit wollte ich anfangen wenn die beiden zusätzlichen kanäle dran sind und es irgendwo zum runterladen ist

    ich hab dir mal die aktuelle version angehängt. falls du mit dmx spielen willst kannst du den ENABLE_DMX aktivieren. die dmx lib dazu findest du hier :http://www.mathertel.de/Arduino/DMXSerial.aspx

    gruss
      andre

    Super danke jetzt geht es, und das SWAP_02-FirmwareVersion sehe ich jetzt auch, das habe ich vorher alles garnicht gesehen, geschweige denn das überhaupt irgend eine rückmeldung vom rgbboard kam ;-)
    Titel: Aw: panStamp support
    Beitrag von: fidel am 30 Juli 2013, 22:08:16
    Hi,

    im Anhang das list:

    in 0E steht 0300000000

    Mir ging es eigentlich um das ein und ausschalten aus fhem heraus. Nachdem ich die Spannung weggenommen habe blieb der Streifen einfach aus.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 30 Juli 2013, 22:15:57
    achso :)

    das baue ich ein.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 01 August 2013, 08:46:21
    Hi andre,

    was mir gestern beim Testen auf-/eingefallen ist: ist das Protokoll bidirektional? Also würde der panstamp/SoilmoistureSketch das Datenpaket nocheinmal senden wenn kein ACK vom Panstick kommt?

    Der Nutzen beim soilmoisturesketch wäre sicher fraglich, aber beim bininp sicher nicht wenn dieser als Fensterkontaktsensor benutzt würde. (oder binouts für die Alarmanlage-Statusanzeige)

    Gruss
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 01 August 2013, 09:33:28
    das protokol sieht für ein kommando vor das mit dem aktuellen status geantwortet wird. wenn der nicht kommt siehst das in fhem als unconfirmed. ich wollte hier noch einbauen das diese auch wiederholt werden.

    für status nachrichten ist das im protokoll direkt nicht vorgesehen. es gibt aber drei möglichkeiten das zu realisieren:
      - man definiert eine ack nachricht und wertet diese im sketch aus.
      - man lässt den sketch aktiv nachfragen ob die status nachricht angekommen ist.
      - man verwendet nicht swap sondern norberts swapstream klasse. die wiederholt die nachricht wenn sie nicht bestätigt wird.

    alle drei ansätze haben vor und nachteile. das erste braucht eine neue nachricht. das zweite braucht eine nachricht mehr im funkverkehr. das dritte verwendet nachrichten die länger sind als in diesem fall nötig. eventuell ist eine kombination aus eins und zwei das sparsamste. auf jeden fall müssen beide seiten (sketch und fhem) implementiert werden und zueinander passen.

    wenn es einen konkreten anwendungsfall und ein 'versuchskaninchen' gib hilft ganz bestimmt dabei eine lösung zu finden und einzubauen.

    gruss
      andre


    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 01 August 2013, 15:57:31
    kann man eigentlich diese LED-Stripes bei dem RGB-Board verwenden?
    http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=300939612781&clk_rvr_id=506047773869 (//cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=300939612781&clk_rvr_id=506047773869)

    http://www.ebay.de/itm/Lux-Pro-500cm-5m-LED-SMD-STRIP-LEISTE-RGB-5050-FERNBEDIENUNG-5-METER-STRIPE-/370867026012?pt=DE_M%C3%B6bel_Wohnen_Nachtlichter_Lichts%C3%A4ulen&hash=item565965b85c (//www.ebay.de/itm/Lux-Pro-500cm-5m-LED-SMD-STRIP-LEISTE-RGB-5050-FERNBEDIENUNG-5-METER-STRIPE-/370867026012?pt=DE_M%C3%B6bel_Wohnen_Nachtlichter_Lichts%C3%A4ulen&hash=item565965b85c)
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 01 August 2013, 16:10:22
    ja.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 07 August 2013, 21:05:41
    Hi Andre,
    hast du irgendetwas am Modul geändert?
    Es wird kein "regSet 0A 012C" angenommen. Dadurch hat mein letzter, noch nicht konfigurierter Panstamp auch wieder munter 100 Devices angelegt... ;)
    Ein Test bei den anderen hat es bestätigt, das Kommando wird nicht angenommen (nach drücken des resets).
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 07 August 2013, 22:12:12
    ich hab nichts geändert. hmmm. jedenfalls nicht das ich wüsste.

    gerade bei mir getestet und geht.

    was für ein sketch ist auf dem panstamp drauf? das intervall wird nur automatisch gesetzt wenn pwrdownmode im device description file true ist.


    wenn auch das von hand setzen nicht geht setz bitte mal global verbose auf 4 oder 5 und schick mir bitte das log. und ein list vom device und vom panstick.

    gruss
      andre

    edit: ich habe doch noch zwei dinge gefunden:
      - ich hatte einen fehler im suchen nach der nächsten freien adresse. es wurde immer F0 genommen.
        -> die addresse blieb FF wenn es schon ein anderes device mit F= gibt.

      - mir ist aufgefallen das es beim automatischen addresse und intervall ändern noch ein logisches problem gibt.
      ->   eventuell schlägt das bei langsamen systemem zu. da muss ich noch mal drüber nach denken.

    beides sollte aber nicht das setzen des intervalls von hand verhindern
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 08 August 2013, 05:49:03
    Hi Andre,
    es ist der soilmoisture-sketch drauf, angepasst ist nur die 400ms für die Vegetronix-Sensoren. Siehe Anhang.
    Ich habe auch im Sketch die Pins auf das Bild nach deiner Aussage gesetzt: 1: 4/5, 2: 7/6
    Irgendie kommt aber zu wenig im Messergebnis heraus, nur so um die 0.1-0.5V, ich werde aber heute abend weiter testen.....
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 08 August 2013, 09:21:17
    ob du den richtigen analog pin erwischt hast siehst du am aller besten wenn du das intervall auf 10 sekunden setzt und den pin an gnd oder vcc legst. natürlich ohne vegetronix sensor.

    du kannst den analg pin auch mit A1 angeben. das ist vielleicht weniger verwirrend.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 08 August 2013, 13:27:54
    Zitat von: justme1968 schrieb am Do, 08 August 2013 09:21ob du den richtigen analog pin erwischt hast siehst du am aller besten wenn du das intervall auf 10 sekunden setzt und den pin an gnd oder vcc legst. natürlich ohne vegetronix sensor.
    Genau das hate ich auch vor ;) ;)
    Zitatdu kannst den analg pin auch mit A1 angeben. das ist vielleicht weniger verwirrend.
    Ohhh, gut zu wissen
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 08 August 2013, 18:50:46
    ICh glaub ich weiß warum es mit den Vegetronix-Sensoren nicht funktioniert.
    Ich habe mal direkt die D* Pins auf die A* Pins gelegt um die Spannung im HIGH zu messen.

    Bei einer Batteriespannung von 1.59V:
    HIGH-Pegel (zb. D7 an A4) ist 1.018
    LowPegel (unconnected) ist 0.644
    LowPegel (verbunden mit GND) ist 0.000

    Da die Vegetronix-Sensoren erst ab 3.3V arbeiten ist klar das ich nur Müll messe :(
    Ich war der Meinung das der StepUp-Regulator die 1.5V auf 3.3V hochtransformiert und diese Spannung auch im HIGH-Pegel anliegt???

    Andre, was hast du bei deinem Test mit diesen Sensoren anders gemacht als ich jetzt?
    Muss ich auf dem Board noch irgendeine Brücke/Jumper einlöten??

    Edit: also irgendwie funzt ein "regSet 0A 012C" nicht... :( Der folgende Code zeigt das regSet mit anschließendem panstamp-reset
    2013.08.08 18:54:56 5: Cmd: >set SWAP_03 regSet 0A 012C<
    2013.08.08 18:54:56 5: Triggering SWAP_03 (3 changes)
    2013.08.08 18:54:56 5: Notify loop for SWAP_03 set-regSet
    2013.08.08 19:03:44 5: panStamp/RAW: /(ED30)0003000100030000000001000
    2013.08.08 19:03:44 5: panStamp/RAW: (ED30)0003000100030000000001000/0000E
    (EB32)0003000200030A0258
    (ED31)0003000300030303

    2013.08.08 19:03:44 5: panstamp: 00030001000300000000010000000E -83.5 48
    2013.08.08 19:03:44 5: panstamp dispatch 00030001000300000000010000000E
    2013.08.08 19:03:44 4: SWAP_03 -> broadcast (0,0-01): status SWAP_03 00:000000010000000E
    2013.08.08 19:03:44 5: panstamp: 0003000200030A0258 -84.5 50
    2013.08.08 19:03:44 5: panstamp dispatch 0003000200030A0258
    2013.08.08 19:03:44 4: SWAP_03 -> broadcast (0,0-02): status SWAP_03 0A:0258
    2013.08.08 19:03:44 5: panstamp: 0003000300030303 -83.5 49
    2013.08.08 19:03:44 5: panstamp dispatch 0003000300030303
    2013.08.08 19:03:44 4: SWAP_03 -> broadcast (0,0-03): status SWAP_03 03:03
    2013.08.08 19:03:44 5: panstamp sending 03 000002030A012C
    2013.08.08 19:03:44 5: SW: 03
    Modem ready!
    (EF31)00FF004F00FF0C00A300C8
    (F031)00FF005000FF0B0596
    (F02F)00FF005100FF0C00A800C8
    (F030)00FF005200FF0B0559
    (F02F)00FF005300FF0C00A200BF000002030A012C
    2013.08.08 19:03:47 5: panStamp/RAW: /(F132)00
    2013.08.08 19:03:47 5: panStamp/RAW: (F132)00/03000400
    2013.08.08 19:03:47 5: panStamp/RAW: (F132)0003000400/030302
    2013.08.08 19:03:47 5: panStamp/RAW: (F132)0003000400030302
    /

    2013.08.08 19:03:47 5: panstamp: 0003000400030302 -81.5 50
    2013.08.08 19:03:47 5: panstamp dispatch 0003000400030302
    2013.08.08 19:03:47 4: SWAP_03 -> broadcast (0,0-04): status SWAP_03 03:02
    2013.08.08 19:03:47 5: panStamp/RAW: /(F130)000300
    2013.08.08 19:03:47 5: panStamp/RAW: (F130)000300/0500030C
    2013.08.08 19:03:47 5: panStamp/RAW: (F130)0003000500030C/03FA025
    2013.08.08 19:03:47 5: panStamp/RAW: (F130)0003000500030C03FA025/2
    (
    2013.08.08 19:03:47 5: panstamp: 0003000500030C03FA0252 -81.5 48
    2013.08.08 19:03:47 5: panstamp dispatch 0003000500030C03FA0252
    2013.08.08 19:03:47 4: SWAP_03 -> broadcast (0,0-05): status SWAP_03 0C:03FA0252
    2013.08.08 19:03:47 5: Triggering SWAP_03 (4 changes)
    2013.08.08 19:03:47 5: Notify loop for SWAP_03 0C.0-Moisture_level_0: 03FA
    2013.08.08 19:03:47 5: panStamp/RAW: (/F030)0003000600030B063A

    2013.08.08 19:03:47 5: panstamp: 0003000600030B063A -82 48
    2013.08.08 19:03:47 5: panstamp dispatch 0003000600030B063A
    2013.08.08 19:03:47 4: SWAP_03 -> broadcast (0,0-06): status SWAP_03 0B:063A
    2013.08.08 19:03:47 5: Triggering SWAP_03 (4 changes)
    2013.08.08 19:03:47 5: Notify loop for SWAP_03 0B-Voltage: 063A

    Hinterher steht immer noch der alte Wert: SWAP_0A-PeriodicTxInterval 0258. Scheint auch nicht nur ein Anzeigeproblem zu sein, denn bei einem "regSet 0A 000F", also ein 10sek Intervall, passiert nach 10sek nix sondern erst nach den 0258, also 10min.
    Hoffe dir genug Infos gegeben zu haben...
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 08 August 2013, 19:46:42
    ich hatte es auf einem breadboard mit einer echten 3,3v versorgung getestet. aber der high pegel der digital pins ist auf jeden fall 3,3v oder ganz knapp darunter. egal ob der panstamp mit netzteil oder batterie läuft. sonst würde je keine externe beschaltung funktionieren.

    wie hat du denn die 1.018v gemessen? wenn du den arduino selber zum messen nimmst musst du aufpassen welche interne refferenz verwendet wird. es muss z.b. im sketch angepasst werden ob er mit batterie oder netzteil läuft, sonst ist die voltage ausgabe falsch.

    da stimmt noch was nicht. wenn du einen analog pin auf gnd legst solltest du auf jeden fall 0 messen.

    kannst du mit einem echten multimeter messen ?

    dein log file ist sehr komisch. es wird nichts bzw. etwas ganz falsches gesendet. das 'Modem ready!' gehört da nicht hin. das ist ein teil der initialisierung vom panstamp und sollte nur beim starten von fhem da stehen. auch die zeilen direkt danach sind sind nakte daten die der panstick eigentlich an fehm

    das hinter SW: ist das was gesendet wird. wenn in der zeilge vorher 'panstamp sending 03 000002030A012C' steht muss in der zeile danach 'SW: 03000002030A012C' stehen und nicht nur 'SW: 03'.

    ich habe gerade überhaupt keine idee was schief geht. ich versuche dir noch eine version mit mehr debug information zu bauen. ich weiss aber nicht ob ich das vor dem urlaub noch schaffe.

    eine idee hab ich noch... vielleicht ist dein fhem rechner zu langsam in den drei sekunden die nachrichten zu empfangen und zu verarbeiten.

    bitte mach mal die 3 sekunden schleife am sketch anfang länger. 10 oder 20 sekunden. dann müsste die zeit sogar reichen das set erst nach dem reset los zu senden.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 08 August 2013, 21:22:24
    Ich habe mal folgendes im Sketch ergänzt:
    Die LED blinkt jetzt 12x anstatt 6x. Dementsprechend länger dauert jetzt die Initsequenz
    Die Messung dauert jetzt 10sek.

    Folgendes kan ich mit meinem Multimeter messen:
    Es liegt zwischen D7 und GND exakt 3.03V an
    Der Sensor misst 2.59V welche an A4 anliegen.
    A3 habe ich gegen GND gelegt

    In FHEM steht folgendes:
    Readings:
         2013-08-08 21:16:49   0B-Voltage      051C
         2013-08-08 21:16:49   0C.0-Moisture_level_0 031E
         2013-08-08 21:16:49   0C.1-Moisture_level_1 0001
         2013-08-08 20:54:32   0C0Dez          0.15
         2013-08-08 21:16:49   Level0          0.793
         2013-08-08 21:16:49   Level1          0.001
         2013-08-08 21:16:49   VWC_A           -1
         2013-08-08 07:27:21   state           set-regSet
         2013-08-08 21:16:49   voltage         1.308


    Levelx ist nur die Umrechnung auf Dezimal analog Voltage. Laut FHEM liefert der Sensor also 0.798V. Real sind es aber 2.59V. Es wird also ein zu geringer Wert per 0C übermittelt??
    A3 gegen GND wird korrekt mit 0V ausgewiesen.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 08 August 2013, 21:43:20
    du darfst nicht die gleiche umrechnung verwenden.

    der wert im voltage register ist schon aufbereitet. und das userReading passt genau dazu.

    die moisture level werte sind die nakten a/d wandler werte mit einer auflösung von 10 bit. 0x400 entspricht 3.3v. deine 0x31e sind dann ziemlich genau 2.56v.

    ich würde sagen es passt...

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 09 August 2013, 09:24:02
    Danke, das wars... bleibt nur noch das regSet Problem.
    Ich teste heute abend mal mit einer alten SWAP-Modul Version sowie dem binouts/statusmon Sketch
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 09 August 2013, 09:33:31
    hat die längere init sequenz nichts geändert?

    vergiss nicht die kess zeit wieder auf 400ms zu stellen. die batterien werden es dir danken.
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 09 August 2013, 10:45:49
    nein, die Initzeit hat leider nichts geändert.
    Ich werde das ganze heute mal mit dem binouts und einem alten SWAP-Modul testen. An irgendetwas muss es ja liegen.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 09 August 2013, 20:18:35
    ich hab es gerade noch mal mit dem soilmoisture sketch probiert und ich kann das intervall einstellen und nach reset wird es gesendet und gesetzt.

    bitte mach mal ein list auf das device das nicht geht und auch auf das panstick device. wenn du es noch mal probierst schau bitte ob wieder modem ready da steht.

    bist du ganz sicher das du den richtigen sketch geflashed hast ?

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 09 August 2013, 22:07:52
    Hi Andre,
    nachdem ich den originalen Sketch mit 400ms wieder drauf habe, also alles incl. Modem resettet habe, gehts. Frag mich nicht warum, aber es wurden alle Kommandos angenommen.
    Muss jetzt beobachten ob der 12h sync auch funktioniert...
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 09 August 2013, 22:23:48
    das beruhigt mich einerseits sehr. anderseits würde ich schon gerne wissen was es war.

    ich hoffe es geht jetzt erst mal. ich bin ab morgen drei wochen weg und schaue nur ab und zu hier rein.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 11 August 2013, 11:54:40
    Hi Andre,
    schönen Urlaub...
    danach könntest du noch mal auf den 12h Sync schauen?? Scheint nicht zu funktionieren:
    Bsp:SWAP_CMDsPending 1 CMDs_pending
       SWAP_MISSED 0
       SWAP_Sent_unconfirmed 16 Sent_unconfirmed
       SWAP_lastRcv 2013-08-11 11:50:46
       SWAP_lastSend 2013-08-09 19:28:43


    Die Msg wartet hier schon 1.5Tage.

    Der Code:
    void loop()
    {
      // Transmit sensor data
      getRegister(REGI_SENSOR)->getData();
      // Transmit power voltage
      getRegister(REGI_VOLTSUPPLY)->getData();

      //alle 12h ein sync
      static unsigned long last_sync_time = 0;
      if( isTime(last_sync_time, (unsigned long)1000*60*60*12) )
        syncState();

      // Sleep
      panstamp.goToSleep();
    }


    Edit1: kann ich eigentlich diesen DC-DC-Wandler (12V->3.3V) direkt an den Panstamp and Pin 14/15 anschließen??
    http://www.reichelt.de/Wandler-Module-DC-DC/SIM1-1203-SIL4/3/index.html?;ACTION=3;LA=2;ARTICLE=57500;GROUPID=4956;artnr=SIM1-1203+SIL4 (//www.reichelt.de/Wandler-Module-DC-DC/SIM1-1203-SIL4/3/index.html?;ACTION=3;LA=2;ARTICLE=57500;GROUPID=4956;artnr=SIM1-1203+SIL4)
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 26 August 2013, 20:33:30
    eAndre, kannst du kurz zu meinem Post vorher etwas sagen??

    Hier mal 2 Bildchen von einem meiner 4 Panstamp/Vegetronix Bodenfeuchtesensoren die quer im Garten verteilt sind.
    Der Panstick als Empfänger hägt an einem RasPi, zentral im Garten unter dem Dach des Brunnenhäuschens. Nächste Woche wird der Panstick als Antenne auch eine gute Groundplane (//www.winklerantennenbau.de/gp868.htm) erhalten
    Habe ich mir von einem Antennenbauer (siehe Bild) bauen lassen.
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 August 2013, 21:15:29
    sorry. hatte deine frage nicht mitbekommen.

    - das mit dem 12 stunden verstehe ich nicht. laut code müsste es eigentlich gehen :). kann ich aber erst zuhause nachschauen. ich hab ausser dem laptop nichts dabei.

    - hardware ist nicht meine stärke... ich würde vermutlich mit so einem teil probieren. aber ich weiss weder ob es wirklich geht noch ob es eine gute lösung ist.
    -> frag doch mal in der bastelecke

    - die antenne ist ja eindrucksvoll. was hast du denn für ein grundstück das du solche geschütze auffahren musst :)

    wenn du überall strom hast und die panstamps dauernd laufen könntest du auch den repeater mode probieren und die reichweite so erhöhen.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 26 August 2013, 21:34:52
    du kannst zum testen in soilmoisture.ino in zeile 135 mal den timeout ändern um schneller zu sehen was passiert. 1000*60 sollte jede minute in den sync mode gehen. inklusive led blinken.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 27 August 2013, 11:15:56
    Hi Andre,
    ich habe erstmal alle Panstamps auf den BatteryBoards im Garten verbaut. Da der ein paar km weg ist komme ich nicht so schnell ran zum testen.
    Die nächsten 5 Panstamps sind schon da, aber ohne Batterieboard da diese eine ständige Stromversorgung haben sollen.
    Ich muss mir da erst einen Testcase aufbauen (deswegen auch die Frage zu den DC/DC Convertern).

    z.Z. hängt der Panstick am Raspi, bald mit dieser GroundPlane. Ggf kann ich aber auch den Panstick direkt in meinen fhem Server stecken und anstelle des Raspi´s im Garten einen zweiten Panstick als Repeater mit dieser GP hängen. Nur mit einer USB-Stromversorgung versehen.
    Das Grundstück ist 60m lang. Die Sendeeinheiten der Sensoren  sind allesamt ca 50cm über dem Boden, aber von viel Grünzeug verdeckt was auch ziemlich das Signal abdämpft. Das Brunnenhäuschen mit dem Panstick ist ziemlich in der Mitte ;)
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 07 September 2013, 13:45:14
    arg... ich habe den fehler gefunden warum das mit ein mal am tag aufwachen nicht geklappt hat....

    wenn das ding sich schlafen legt  läuft die interne uhr nicht weiter. und ich kann so natürlich nicht rausfinden wann die 12 stunden rum sind.

    ich baue am wochenende eine version die geht.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 07 September 2013, 16:39:06
    anbei die änderung mit der das aufwachen alle 12 stunden funktionieren sollte.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Tobias am 11 September 2013, 12:47:33
    Bin gerade im Urlaub, danach muss ich mich erstmal um die neuen HM-LC-BL1-FM kümmern, dann die angekommene 868Mhz Groundplane Antenne anbauen und dann kann ich mich wieder den panstamps wittmen :), insbes. der Alarmanlagen LED-StatusAnzeige
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 11 September 2013, 17:12:36
    dachte ich mir schon :)

    viel spass
      andre
    Titel: Aw: panStamp support
    Beitrag von: TeeVau am 16 September 2013, 15:51:24
    Habe mir gerade ein Startpaket bestellt...jetzt sind zwar die Panstamps lieferbar, dafür aber nicht mehr das RGB Board. Aber länger warten will ich nicht :-)
    Bin mal gespannt...jetzt muss ich mir überlegen was ich mit den Panstamps realisiere ;-)

    Das RGB Board V2.0 ist etwas überdimensioniert für meine Wohnwand....hab da keine LEDs für 50A verbaut :-)
    Titel: Aw: panStamp support
    Beitrag von: Stefan_Ne am 16 September 2013, 15:56:29
    Hallo Andre,

    ich bekomme den RGBDriver in der Arduino IDe nicht kompilliert, gibt immer mehrere Fehler

    regtable:37: error: 'updRGBlevels' was not declared in this scope
    regtable:37: error: 'setRGBlevel' was not declared in this scope
    regtable:41: error: 'updIRcommand' was not declared in this scope
    regtable:45: error: 'updInternalTemp' was not declared in this scope
    regtable:49: error: 'setPowerOnState' was not declared in this scope
    regtable:58: error: 'updtRepeaterCfg' was not declared in this scope
    regtable:58: error: 'setRepeaterCfg' was not declared in this scope

    Hast du eine Idee was das sein kann ?

    Grüße und Danke Stefan

    P.S ich habe hier im Forum gelesen, dass du mehr in der Software unterwegs bist, wenn mal um Hardware geht, da kann ich helfen !
    (siehe Anhang / see attachement)
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 16 September 2013, 16:13:01
    ich kompiliere den sketch nicht mit der ide sondern dem ino kommandozeilen tool.

    das hat vor allem den vorteil das ich jedem sketch ein ftdi device fest zuordnen kann und beim wechseln zwischen panstamp/jeenode/nano und mega nicht dauernd das bord und das device im menu suchen und einstellen muss. (ich hab inzwischen unter anderem drei pansticks, zwei jeenodes, einen nano und hab mir mit der ide schon mehr als ein mal den falschen arduino geflashed :) )

    du brauchst also zusätzlich zur ide noch das ino tool von hier: http://inotool.org (//inotool.org). das ist im prinzip nicht mehr als ein anderes frontend zu den komponenten aus der ide.

    wenn du das installiert hast brauchst du ein directory rgbdriver. darin ein leeres verzeichniss lib, ein verzeichniss src mit den quelltexten und ein file ino.ini. ino ini muss so aussehen:board-model = panstamp
    serial-port = /dev/tty.usbserial-A400D49W
    baud-rate = 115200
    den port musst du natürlich anpassen.

    danach kannst du im verzeichniss rgbdriver 'ino build' zum kompilieren und 'ino upload' zum hochladen aufrufen.

    anbei noch mal die aktuelle version in der richtigen directory struktur. in config.h kannst du einzelne features ein bzw. aus schalten.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 20 September 2013, 03:01:13
    Hallo zusammen,

    gestern sind endlich meine Panstamps und men PanStick gekommen.
    Mein RGB Board ist ja schon fertig und ich würde gern etwas testen, allerdings hab ich noch ein paar fragen zum flashen der sketch´s.

    Zuerst, bin ich richtig informiert, dass die PanStamp´s mit dem Modem Sketch ausgeliefert werden? Sollte der PanStick dann mit einem PanStamp im Auslieferungszustand in FHEM erkannt werden?

    Gibt es eine Möglichkeit das RGB Sketch auch unter Windows zu flashen? Oder muss ich es über Linux und ino machen.
    Sorry, für die vielen Fragen, aber ich bin neu in der Arduino und PanStamp Welt...

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 September 2013, 08:10:41
    der auslieferungszustand mit dem modem sketch ist genau das was du für die fhem seite brauchst.

    die arduino ide gibt es genau so auch für windows. das ino tool aber nur für mac und linux. wenn das ein problem schaue ich das die quelltexte auch in der ide kompilieren.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: Stefan_Ne am 20 September 2013, 12:33:25
    Hallo Lars,

    also die Baustelle Linux habe ich mir die Tage für den Zweck hergeichten, ist doch nicht mit gerade kleinem Aufwand verbunden gewesen.
    Es sind definitiv Kenntnisse in Linux oder Unix erforderlich. Dann lässt sich der code schön mit ino compilieren.
    Das flashen des Panstamp kannst du auch mit Windows machen wenn du das .hex file hast, geht mit xloader prima.

    Falls du für Fhem einen Raspberry im Einsatz hast kannst ino auch da installieren.

    @Andre
    hast du den Panstamp shield für Raspberry ausprobiert ?

    Grüße

    Stefan
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 September 2013, 12:46:27
    ich hab den raspberry shield noch nicht probiert. wenn alles nach anleitung konfiguriert ist sollte es aber reichen in fhem die entsprechende serielle schnittstelle anzugeben.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 20 September 2013, 19:09:16
    Hi,
    die Arduino IDE für Windows hab ich, allerdings kann ich da den RGB Sketch nicht kompilieren.
    Wenn es auch in der Windows IDE funktionieren würde, wär es echt komfortabel.
    Wenn nicht muss ich mir mal ne virtuelles Ubuntu aufsetzten...


    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 20 September 2013, 20:01:59
    hier eine version die mit der ide kompiliert.

    gruss
      andre

    Titel: Aw: panStamp support
    Beitrag von: LaSto am 20 September 2013, 20:12:19
    Super! Vielen Dank, dann kann ich morgen mal testen...

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: Stefan_Ne am 21 September 2013, 17:39:32
    Hallo,

    panstamp shield am Raspberry funktioniert super !
    Mann muss nur die Console vom TTY abschalten.

    Ich habe da noch ein paar ungelöste Punkte
    - Speichen der RGB Inhalte um die letzte Frarbe nach ein / aus zu haben.
    - Bedienung mit Fhemobil ( App für IOS Geräte )

    Grüße

    Stefan
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 21 September 2013, 18:05:23
    wenn du mit ausschalten stromlos machen meinst: der sketch speichert 30 sekunden nac der letzten änderung die aktuelle farbe im eeprom. du kannst konfigurieren das beim einschalten entweder eine feste farbe oder diese gespeicherte verwendet wird.

    wenn du mit ausschalten 'soft off' über fhem oder alles auf 0 setzen meinst: das kommt noch.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 21 September 2013, 18:21:43
    Zitat von: justme1968 schrieb am Fr, 20 September 2013 20:01hier eine version die mit der ide kompiliert.

    gruss
      andre


    Ich hab grad mal versucht es zu kompilieren. Bekomme aber noch nen Fehler.
    Die Dateien register.h und commonregs.h sind auch nicht vorhanden.

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 21 September 2013, 18:40:17
    hast du die panstamp lib installiert?

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 21 September 2013, 18:52:16
    Nö, hatte ich nicht :-/
    Aber jetzt ;-)

    Trotzdem bekomme ich noch Fehler beim kompilieren. Ich muss mich echt mal mit Arduino beschäftigen. Da hab ich bis jetzt immer nen großen Bogen drum gemacht...

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 21 September 2013, 18:56:40
    schau mal weiter oben im thread. dir fehlt die ir lib. oder du kommentierst das in config.h aus. das original board kann das sowieso nicht. das gleihe für dmx.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 21 September 2013, 19:30:57
    Erstmal Danke für die schnelle Unterstützung.
    Hab jetzt in der config.h ir, dmx und repeater auskommentiert, es kompiliert aber wieder mit neuen Fehlern. Hab heute auch keine Zeit mich näher damit zu beschäftigen...

    Morgen oder nächste Woche gehts weiter...

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 22 September 2013, 21:29:54
    Hallo Andre,

    ich bekomm es unter Windows nicht hin.
    Hab jetzt die Panstamp Lib, IR Lib und DMX Lib installiert.
    Bekomme trotzdem noch Fehler (siehe Anhang).
    Hab auch in der config.h testweise mal ir, dmx und repeater auskommentiert.
    Trotzdem Fehler.
    Hast du diese Version schon mal erfolgreich in der Windows IDE kompiliert? oder vielleicht wer anders?

    Gruß Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 22 September 2013, 21:54:48
    kopier mal die folgen zeilen in regtable.ino nach 'extern void setBlink( int );' in zeile 20:const void updRGBlevels( byte rId );          
    const void setRGBlevel(byte rId, byte *levels);
    const void updIRcommand( byte rId );          
    const void updInternalTemp( byte rId );        
    const void setPowerOnState(byte rId, byte *state);
    const void updtRepeaterCfg(byte rId);          
    const void setRepeaterCfg(byte rId, byte *config);

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 22 September 2013, 22:07:01
    Super! Jetzt kompiliert er ohne Fehler. Danke!

    Dann kann ich morgen endlich teste :-)

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 24 September 2013, 03:32:47
    Ich hangel mich von einem Problem zum nächstem :-(

    Irgendwie klappt define panStick panStamp /dev/ttyUSBx@38400 mit der Fritzbox nicht.
    Im Log steht immer
    2013.09.24 03:30:17 3: Opening panStick device /dev/ttyUSB0
    2013.09.24 03:30:17 3: Can't open /dev/ttyUSB0: No such file or directory

    im Verzeichnis /dev wird auch nichts mit ttyUSB angelegt. Siehe Anhang.
    Im FritzBox Webinterface wird mir aber ein USB-Serielconverter mit FTDI Chipsatz angezeigt.

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 24 September 2013, 03:50:02
    Schwere Geburt!!! Nach ausschalten des USBFernanschlusses und dann einem komplett Neustart der FritzBox hat er nun endlich ein ttyUSB0 angelegt :-)

    So, ab ins Bett...
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 02 Oktober 2013, 21:32:56
    Ich hab grad ein eigenartiges Problem...
    Und zwar habe ich mit

    set Device setFade 01 FF0000 60
    set Device setFade 02 00FF00 60
    set Device setFade 03 0000FF 60

    definiert. Wenn ich "set Device startFade 01 03" ausführe, bekommme ich im Log ein
    "2013.10.02 21:18:10 2: panStamp TRANSMIT LIMIT EXCEEDED"
    und es werden alle LED sehr hochfrequent angesteuert.

    Definiere ich ein

    set Device setFade 01 FF0000 10
    set Device setFade 02 00FF00 10
    set Device setFade 03 0000FF 10

    und starte mit "set Device startFade 01 03" funktioniert es.
    Die Zeit die ich als letztes angebe sind doch Sekunden, oder?
    Was ist der Maximale Wert?

    Gruß
    Lars



     
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 02 Oktober 2013, 21:45:55
    du hat recht. ich kann es reproduzieren. ich verstehe aber noch nicht ganz was da schief geht...

    ich melde mich wenn ich mehr weiss.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 02 Oktober 2013, 21:55:31
    ich denke ich weiss was es ist. da ist ein überlauf im code.

    kannst du bitte mal in fade.h in zeile 12 aus dem int ein long machen und es noch mal probieren?

    ich kann es gerade selber nicht testen weil ich alles mögliche am umstellen bin.

    gruss
      andre
    Titel: Aw: panStamp support
    Beitrag von: LaSto am 02 Oktober 2013, 22:02:28
    Ich kann momentan auch nicht testen. Der PanStick ist grad auf dem Dachboden in der FritzBox und ich bin übers lange Wochenende unterwegs.
    Denke ich werde am Sonntag oder Montag mal testen können.

    Gruß
    Lars
    Titel: Aw: panStamp support
    Beitrag von: justme1968 am 02 Oktober 2013, 22:44:53
    ich hab schnell einen anderen panstamp umgeflashed und ohne rgb board getestet.

    mein verdacht war richtig. aber es muss noch an einer zweiten stelle etwas geaendert werden. anbei die beiden reparierten files.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: LaSto am 15 Oktober 2013, 17:27:55
    So, jetzt bin ich mal dazu gekommen zu testen und es funktiniert.
    Vielen Dank Andre!

    Ich hänge mal die rgbdriver.zip an.
    Das ist jetzt die Version, die sich in der Windows IDE kompilieren lässt und alle Änderungen hat.

    Gruß
    Lars
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 03 November 2013, 17:23:12
    ich habe den rgb sketch inzwischen so weit das er mehr als die 3 kanäle des normalen boards unterstützt.

    leider sehe ich aber gerade keine möglichkeit fhem modul und sketch so vor und rückwärts kompatibel zu machen das man die alte und neue version gleichzeitg mit einem aktualiserten fhem modul betreiben kann.

    es gibt jetzt zwei lösungen:

    - es gibt für die alte und neue version jeweils ein eigenes fhem modul

    - zum zeitpunkt x wenn das fhem update kommt müssen auch alle panstamps auf den rgb boards mit dem passenden neuen sketch versehen werden

    ersteres ist für die anwender natülich einfacher, letzteres wäre mir lieber und auf dauer einfacher zu pflegen.

    da ich gerade nicht weiss ob und wie viele anwender es gibt würde ich den zweiten weg wählen wenn es keine proteste gibt.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ohweh am 03 November 2013, 17:51:50
    Hey,

    also ich wär auch für den zweiten Weg... Du baust ja massiv neue Funktionen ein, da ist dauerhafte Pflege mehrerer Module doch recht aufwändig.

    Ist SEND-IR im Modul schon implementiert? (auch wenn der Sketch das vielleicht noch nicht hergibt)

    Kannste noch ne neue Version des Sketches posten?

    Gruss
    Oliver
    Titel: Antw:panStamp support
    Beitrag von: ntruchsess am 04 November 2013, 10:25:35
    Zitat von: justme1968 am 03 November 2013, 17:23:12
    leider sehe ich aber gerade keine möglichkeit fhem modul und sketch so vor und rückwärts kompatibel zu machen
    Warum vergibst Du für die (inkompatible) neue Version nicht einfach eine neue Registerid?

    Gruß,

    Norbert
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 04 November 2013, 10:35:53
    das wäre genau variante 1. das mapping fhem modul <-> product code ist 1:1 und damit gäbe es dann zwei fhem module.

    inzwischen hab ich noch zwei oder drei ideen wie es doch rückwärts kompatibel gehen könnte aber es ist alles irgendwie unschön und ich weiss nicht ob es den aufwand wert ist. und von denen die es schon gibt werden über kurz oder lang hoffentlich aber sowieso alle wechseln weil der alte sketch und das alte modul nicht weiter entwickelt werden und der neue sketch alles kann was der alte auch kann. es sind ja (noch :) ) keine dutzende von anwendern aber man muss halt ein eventuell verbauten panstamp zum flashen ausbauen. wenn ein over the air update schon funktionieren würde wäre das gar keine frage.   



    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ntruchsess am 04 November 2013, 12:48:31
    Zitat von: justme1968 am 04 November 2013, 10:35:53
    das wäre genau variante 1. das mapping fhem modul <-> product code ist 1:1 und damit gäbe es dann zwei fhem module.
    Du solltest da eine Mapping-tabelle einfügen, sonst kannst Du nie FHEM-module schreiben, die mehrere (funktionell ähnliche) Register in einem Modul bedienen.

    - Norbert
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 04 November 2013, 13:19:07
    das mapping bzw. diese tabelle gibt es. aber wenn es keine 1:1 zuordnung gibt funktioniert autocreate nicht. von hand das passende modul auszuwählen ist auch jetzt schon kein problem.

    zu dem zeitpunkt an dem autocreate aufgerufen wird sind die module ja noch nicht mal geladen und können eine zusätzliche mapping ebene nicht initialisieren. das ganze zentral zu machen würde aber bedeuten das immer irgendetwas editiert werden muss sobald ein neues modul dazu kommt (so wie es zur zeit bei der client liste leider auch schon ist). das funktioniert aber nicht wenn jemand selber private module schreibt und ein fhem update das eigene mapping wieder überbügelt.

    das eigentliche problem ist auch nicht das passende modul zu laden sondern das die device description files es nur erlauben versions abhängig register ein und aus zu schalten aber nicht ein register in der größe zu verändern.

    das lässt sich zwar alles lösen und wie gesagt habe ich habe inzwischen auch noch ein paar ideen aber ich weiß nicht ob sich der aufwand lohnt so lange niemand schreit weil er den alten sketch weiter verwenden möchte.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 13 Dezember 2013, 08:26:27
    Hier ein aktueller Status meiner Panstamps die ich zZ ausschließlich mit Vegetronix Bodenfeuchtesensoren einsetze: (für Andre, fürs Wiki).
    Allerdings habe ich noch nicht den neuesten Sketch drauf mit dem Bugfix des 12stündigen sync´s

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


    Titel: Antw:panStamp support
    Beitrag von: Tobias am 25 Dezember 2013, 13:07:01
    Ich wieder...
    Habe meine 868Mhz Groundplane-Antenne vom externen RasPi getrennt und stattdessen einen Panstamp im RepeaterMode drangehangen. Den Originären Panstamp mit ModemSketch ist nun wieder direkt an meinem Server im Keller eingesteckt.

    Den Panstamp-Repeater habe einen Binout2 Sketch verpasst, Repeater-mode aktiviert und auf 1Hop geändert.
    Fazit: Funktioniert!!! Ich empfange nun sauber im Keller alle(!!) Bodenfeuchtesensore die ich so im Garten verteilt habe!
    2013.12.25 12:57:28 5: panStamp/RAW: /(EE2F)0001105500030C03130005

    2013.12.25 12:57:28 5: Panstamp: 0001105500030C03130005 -83 47
    2013.12.25 12:57:28 5: Panstamp dispatch 0001105500030C03130005
    2013.12.25 12:57:28 4: 01 -> broadcast (1,0-55): status BF_Rasen 0C:03130005
    2013.12.25 12:57:45 5: panStamp/RAW: /(EE32)0001105100040C02CE0005

    2013.12.25 12:57:45 5: Panstamp: 0001105100040C02CE0005 -83 50
    2013.12.25 12:57:45 5: Panstamp dispatch 0001105100040C02CE0005
    2013.12.25 12:57:45 4: 01 -> broadcast (1,0-51): status BF_Garten 0C:02CE0005
    2013.12.25 12:58:15 5: panStamp/RAW: /(ED2E)000110B500020C02980002

    2013.12.25 12:58:15 5: Panstamp: 000110B500020C02980002 -83.5 46
    2013.12.25 12:58:15 5: Panstamp dispatch 000110B500020C02980002
    2013.12.25 12:58:15 4: 01 -> broadcast (1,0-B5): status BF_Rhodedendren 0C:02980002


    aufgrund 01 -> broadcast sieht man, das die Datenpakete über den Repeater im Hop1 empfangen wurden!

    DANKE!!!!!
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 03 Januar 2014, 13:18:16
    Hi,
    die Repeaterfunktion für die Sensorwerte funktioniert prächtig. Allerdings kommen die Batteriewerte nur noch ca 1-2mal am Tag an. Ohne Repeater sind immer Sensorwert und Batteriewert gleichzeitig angekommen. Gibt es es da einen bekannten Bug?
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 03 Januar 2014, 13:21:45
    die werden beide direkt nacheinander abgesendet und der repeater wiederholt eigentlich wirklich alles.

    kannst du mit verbose 4 mehr sehen ?

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 03 Januar 2014, 13:57:29
    ich hatte mit verbose 5 geschaut, siehe 2 Einträge vorher.... die Batteriemeldung kommt einfach nicht....
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 03 Januar 2014, 14:08:45
    das ist sehr komisch. ich versuch das mal nachzustellen. ich weiss aber nicht ob ich genug panstamps frei habe.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Bjoern777 am 29 Januar 2014, 22:25:27
    Hallo zusammen,
    ich beschäftige mich seit kurzem mit panstamp und FHEM. Mir hat gut gefallen, dass es vermeintlich einfach ist die Verschlüsselung auf dem Übertragungsweg (im Sketch) einzustellen. Die Idee war einen RPi mit Shield als Gateway einzusetzen und panstamps als Sensoren / Aktoren zu verwenden. Gelernt habe ich jetzt aber, dass es im Modem-Sketch, welches die Firmware für den USB-Stick und das RPi Shield darstellt, nicht möglich ist, die Daten wieder zu entschlüsseln. Die Entschlüsselung muss vielmehr in der Host-Anwendung vorgenommen werden.
    Mit meinen rudimentären Kenntnissen habe ich mir nun die Perl-Programme angesehen um herauszulesen, ob die Verschlüsselung vielleicht bereits implementiert ist. Aber das scheint wohl nicht der Fall zu sein.

    Mich würde interessieren ob geplant ist dies noch zu implementieren?
    Mit etwas Hilfe von Profis würde ich dabei auch gern behilflich sein.

    Gruss Bjoern
    Titel: panStamp support
    Beitrag von: justme1968 am 30 Januar 2014, 08:57:59
    die verschlüsselung ist auf fhem seite noch nicht eingebaut. ich bin noch nicht dazu gekommen.

    es sollte aber eigentlich nicht aufwändig sein.

    ich schau es mir am wochenende mal an.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 30 Januar 2014, 22:53:10
    ich hab grade mal angefangen die entschlüsselung einzubauen. aber grade keinen panstamp frei um es zu probieren.

    wenn du magst und zeit hast würde ich dir eine version der fhem module fertig machen um es zu probieren.

    dauert aber noch bis nächste woche weil ich nicht genau weiss wo ich die verschlüsselung unter bringen soll.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 30 Januar 2014, 23:22:10
    Hi zusammen,

    währe es nicht besser die entschlüsselung direkt im Modem-Sketch zu machen? So dass man evtl. einen Sketch schreibt, der sowohl unverschlüsselte Pakete als auch verschlüsselte Pakete (natürlich entschlüsselt) über die serielle Schnittstelle ausgibt?

    So wie ich das gelesen habe, muss man dazu nur die Ver-/Entschlüsselung im panStamp-Stack aktivieren.

    Währe doch bestimmt besser als die Entschlüsselung im panStamp-FHEM-Modul durchzuführen.

    Viele Grüße

    Markus
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 30 Januar 2014, 23:31:16
    im prinzip ja. aber der modem sketch weiss zur zeit nichts von swap. er reicht nur alles was empfangen wird 1:1 durch.

    man müsste also zuerst dem modem sketch swap beibringen und dann pro device das password konfigurierbar machen. das muss je nicht für alle devices gleicht sein.

    aus dem gleichen grund kommt es auch nicht ins panstamp modul sondern ins swap modul. das panstamp modul reicht wieder nur 1:1 durch und kann im prinzip auch mit anderen protokollen arbeiten.

    unterm strich ist es in den fhem modulen schneller eingebaut und leichter zu testen als den modem sketch komplett umzubauen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Bjoern777 am 01 Februar 2014, 21:01:07
    Moinsen,

    bin gern bereit den Test zu übernehmen. :)

    Danke für dein Hilfe!

    Gruss Björn
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 01 Februar 2014, 21:22:46
    Ich würde mich ebenfalls gerne zum testen bereit erklären.
    Titel: Antw:panStamp support
    Beitrag von: daduke am 02 Februar 2014, 14:09:54
    Hallo zusammen,

    danke für den guten panstamp-Support in FHEM. Vermisst habe ich bislang eine Funktion, die weich durch die RGB-Farben blendet. Anbei ein Patch für den Sketch und 35_SWAP_0000002200000003.pm, der genau das nachrüstet. Das neue Kommando ColorCycle rotiert timergesteuert durch das RGB-Spektrum. Inspiriert ist das Ganze von forum.arduino.cc/index.php?topic=102040.0 (http://forum.arduino.cc/index.php?topic=102040.0). Eine Kleinigkeit fehlt noch, die ich aber in 35_SWAP... nicht finde: das Icon wird nicht != Fragezeichen gesetzt und die command history wird nicht mit ColorCycle befüllt, sodass er nach dem Aus- und Anschalten nicht weiterfaded. Ich würde mich freuen, wenn noch jemand dieses Feature gebrauchen kann und der patch im repo landet. Vielleicht können justme1968 et al. ja gerade noch die history einbauen.

    danke und viele Grüße,
    -Christian
    Titel: panStamp support
    Beitrag von: justme1968 am 02 Februar 2014, 14:37:42
    das faden durch die farben kann der sketch autonom. dafür gibt es 16 register in denen du farben und transition time setzen kannst und dann mit einem befehl eine loop über n aufeinanderfolgende dieser register startest. also ganz ohne das fhem damit belastet wird. so kann man eine beliebige loop auch auf eine taste einer ir fernbedienung legen. es wird aber ein regelmäßiger status an fhem gesendet und das icon welchselt in fhem mit.

    ich schaue mal ob setzen der register und starten der loop zu einem fhem kommando zusammenfassen kann damit es einfacher zu bedienen ist.

    das einzige das zur zeit nicht implementiert ist ist der automatische start nach dem einschalten.

    gruss
      andre

    ps: bin grad unterwegs. ich schaue mir den patch aber auf jeden fall noch an.
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 02 Februar 2014, 15:00:09
    Hallo andre,

    auch von mir vielen Dank für den tollen Support bisher.

    Ich habe bei mir mittlerweile 3 RGB-LED-Boards im Einsatz welche mein Wohnzimmer komplett beleuchten sollen, wenn ich Fernseher schauhe. Ich habe bei mir auch eine Funktion in FHEM eingebaut, welche alle Lichter und Verbraucher bei Abwesenheit abschaltet (falls mich mein Kurzzeitgedächtnis wieder verlassen sollte).

    Nun hatte ich an dem Tag mit dem panStick rumgespielt, welcher normalerweise als IO-Device für die panStamps dienen soll. Aufgrunddessen konnte ich natürlich die RGB's nun nicht mehr ausschalten, da ja der USB-Stick nicht gesteckt war. Daher meine Frage:

    Kann man eine Art alive-Mechanismus im RGB-Sketch implementieren, so dass sich die Boards alle selbstständig abschalten, wenn der Modem-panStamp nicht mehr antwortet? Ich stell mir dazu 2 Parameter in der rgb-sketch-config vor, in dem man die Andresse, sowie das Polling-Interval einstellen kann (ergänzt um eine Zufallskomponente). Leider weis ich nicht ob das generell möglich ist, oder ob das Protokoll einen solchen alive-Mechanismus bereits autonom bereitstellt.

    Ist mir gestern so als Idee gekommen, als ich vom Einkauf wiederkam und die LED's waren noch an, da der panStick noch auf meinem Schreibtisch lag.

    Währe toll, ist aber kein muss ;-)

    Viele Grüße

    Markus
    Titel: Antw:panStamp support
    Beitrag von: daduke am 02 Februar 2014, 15:04:03
    Hi andre,

    whoops, da hat wohl mal wieder jemand nicht alle Doku gefunden  ;)
    Dann möge die bessere Implementation gewinnen. Der von mir verwendete Algorithmus erzeugt jedenfalls das weichste fading, das ich bisher bei RGB-LEDs gesehen habe.

    bin gespannt auf Deine Einschätzung,
    -Christian
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 02 Februar 2014, 15:11:15
    klar geht das. aber bist du dir ganz sicher das du das möchtest? sollen deine hm aktoren auch aus gehen wenn fhem nicht mehr antwortet und sich z.b. nicht mehr über die wandtaster bedienen lassen?

    ansonsten würde ich vorschlagen das über ein alive signal das fehm regelmäßig als broadcast sendet und einem parameter im sketch der ausschaltet wenn kein alive von der Zentrale kommt lösen. das wäre nur eine funknachricht die auch nicht beantwortet werden muss im gegensatz zu zwei nachrichten pro panstsmp.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 02 Februar 2014, 15:14:25
    in meinem persönlichen Fall: Ja, weil die LED's ausschließlich von FHEM gesteuert werden. Meine HM Aktoren kann ich alle manuell direkt am Aktor bzw. über eine direkt angelernte Fernbedienung/Wandtaster steuern. Das ist bei den panStamps leider nicht möglich (zumindest nicht mit dem Standard-Board)

    Und bei einem Ausfall von FHEM oder dem USB-Stick möchte ich die LED's gerne ausgeschaltet haben. Normales licht kann ich ja immer noch anmachen und wenn alle Stricke reißen gibt es ja noch Kerzen ;-)
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 02 Februar 2014, 18:31:59
    ich baue eine art watchdog in den rgb sketch ein. wenn der aktiviert ist und eine  bestimmte zeit keine nachricht von fhem empfangen wurde geht alles aus.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 02 Februar 2014, 18:45:38
    das entschlüsseln habe ich inzwischen drin und sogar getestet. das verschlüsseln muss ich noch bauen.

    leider ist es aber doch nicht so das man pro device einen eigenen schlüssel vergeben kann. wenn es nur einen schlüssel pro netz gibt ist aber eigentlich dich schönder das im  modem sketch zu machen.

    ich muss mal schauen was einfacher ist.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 03 Februar 2014, 15:55:49
    anbei eine erste version die ver- und entschlüsseln kann.

    es gibt jeweils im panstamp und swap device das attribut smartPassword. das ist beim device für den panstick und bei jedem device das zu einem panstamp gehört bei dem die verschlüsselung aktiviert ist (also mindestens bei zwei devices) auf den gleichen wert zu setzen:attr <device> smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    die verschlüsselung im sketch wird in setup() (nach dem panstamp.init()) so aktiviert:byte password[] = {1,2,3,4,5,6,7,8,9,10,11,12}; panstamp.setSmartPassword(password);

    enableAntiPlayback() bitte erst mal noch weg lassen. das funktioniert noch nicht 100%ig.

    wichtig: in der panstamp lib muss in panstamp.cpp in der funktion isrGDO0event das 'static' vor 'bool eval = true;' entfernt werden sonst ist kein misch betrieb von panstamps mit und ohne verschlüsselung möglich.

    im rgb sketch gibt es noch irgendein problem mit der verschlüsselung sobald dmx aktiv ist. dann werden manchmal nachrichten scheinbar verschluckt. ich habe noch keine idee was es ist. ich vermute irgend ein stack überlauf. ohne dmx geht es problemlos.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: daduke am 03 Februar 2014, 18:56:45
    @justme1968

    Hi andre,

    habe gerade gesehen, dass mein patch abgeschnitten war. Der Vollständigkeit halber hier der richtige. Habe auch mal mit Deinen registern rumgespielt. Im Prinzip ist ein

    set led setFade 0 00FF00 5
    set led setFade 1 FFFF00 5
    set led setFade 2 FF0000 5
    set led setFade 3 FF00FF 5
    set led setFade 4 0000FF 5
    set led setFade 5 00FFFF 5
    set led setFade 6 FFFFFF 5
    set led setFade 7 FFFF00 5
    set led setFade 8 00FF00 5
    set led setFade 9 00FFFF 5
    set led setFade 10 FFFFFF 5
    set led setFade 11 FF00FF 5
    set led setFade 12 FFFF00 5
    set led setFade 13 00FFFF 5
    set led setFade 14 FF00FF 5
    set led setFade 15 FFFFFF 5

    set led setFade 16 FF0000 5
    set led setFade 17 0000FF 5
    set led setFade 18 00FF00 5
    set led setFade 19 FFFFFF 5
    set led setFade 20 0000FF 5

    set led startFade 0 15
    äquivalent zu meiner Lösung, mit dem Unterschied, dass die letzten 5 Fades (16-20, auch sehr schön  ;) ) bei der Registerlösung keinen Platz mehr haben. Liesse sich das erweitern? Falls ja, und falls wir es noch hinbekommen, dass er nach "set on" gleich losfadet, ist meine Lösung hinfällig.

    Was meinst Du?

    danke und Gruß,
    -Christian
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 03 Februar 2014, 19:01:01
    ich schlage vor zum einen noch ein paar register mehr zu spendieren und zusätzlich eine liste mit der reihenfolge zu übergeben. dann kann man die register die doppelt sind einfach mehrfach zu referenzieren.

    das mit dem starten bekommen wir auch noch hin.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: daduke am 03 Februar 2014, 19:09:46
    sounds good! dann habe ich zwar gestern ein paar Stunden umsonst gehackt, dafür weiss ich jetzt alles atmel timer. Im Endeffekt ist Deine Lösung einfach flexibler.

    cheers,
    -Christian
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 07 Februar 2014, 21:39:40
    Zitat von: justme1968 am 03 Februar 2014, 15:55:49
    anbei eine erste version die ver- und entschlüsseln kann.

    es gibt jeweils im panstamp und swap device das attribut smartPassword. das ist beim device für den panstick und bei jedem device das zu einem panstamp gehört bei dem die verschlüsselung aktiviert ist (also mindestens bei zwei devices) auf den gleichen wert zu setzen:attr <device> smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    die verschlüsselung im sketch wird in setup() (nach dem panstamp.init()) so aktiviert:byte password[] = {1,2,3,4,5,6,7,8,9,10,11,12}; panstamp.setSmartPassword(password);

    enableAntiPlayback() bitte erst mal noch weg lassen. das funktioniert noch nicht 100%ig.

    wichtig: in der panstamp lib muss in panstamp.cpp in der funktion isrGDO0event das 'static' vor 'bool eval = true;' entfernt werden sonst ist kein misch betrieb von panstamps mit und ohne verschlüsselung möglich.

    im rgb sketch gibt es noch irgendein problem mit der verschlüsselung sobald dmx aktiv ist. dann werden manchmal nachrichten scheinbar verschluckt. ich habe noch keine idee was es ist. ich vermute irgend ein stack überlauf. ohne dmx geht es problemlos.

    gruss
      andre

    Hallo andre,

    hab gerade die Änderungen im Sketch durchgeführt, sowie in der panstamp.cpp und deine modifizierten Module eingespielt. Ich habe die smartPassword Attribute am panStick und dem RGB Device in FHEM gesetzt und konnte auch auf Anhieb das Board steuern.

    Dann hatte ich das smartPassword beim RGB Device entfernt und konnte es auch direkt nicht mehr steueren. (wie erwartet)

    Als ich es wieder setzen wollte konnte ich das RGB Device eigenartigerweise nicht mehr steueren. Auch ein FHEM Neustart scheint hier keine Besserung zu bringen.

    In den Logs konnte ich nichts besonderes entdecken bis auf:

    Use of uninitialized value in multiplication (*) at /usr/local/FHEM/share/fhem/FHEM/35_SWAP_0000002200000003.pm line 219.
    Use of uninitialized value in repeat (x) at /usr/local/FHEM/share/fhem/FHEM/35_SWAP_0000002200000003.pm line 195.


    Hast du eine Idee?

    Vielen Dank

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 07 Februar 2014, 21:55:52
    Okay, nach einigem ausprobieren habe ich herausgefunden, dass die Verschlüsselung generell richtig funktioniert  und wie erwartet arbeitet.

    Allerdings scheint der Sketch abzustürzen, wenn man das Device ohne smartPassword oder mit einem falschen smartPassword versucht anzusprechen. Nur durch stromlos schalten lässt sich der Sketch dann wieder ansprechen.

    Bsp:

    - korrektes smartPassword gesetzt
    - schalten funktioniert erfolgreich
    - smartPassword löschen
    - schalten funktionier nicht mehr (wie zu erwarten)
    - wieder das korrekte smartPassword setzen
    - schalten funktioniert nicht mehr (sollte es aber)
    - RGB Board stromlos machen
    - schalten funktioniert wieder.

    Was könnte das sein?

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 07 Februar 2014, 22:07:49
    das schaut eigentlich so aus als ob die änderung in isrGDO0event eventuell nicht rein kompiliert ist.

    hast du die die verwendet oder das ino tool? in der die hilft es ein mal den ardunio typ zu ändern und wieder zurück auf panstamp. im ino tool sollte ein 'ino clean' helfen.

    ohne die änderung sind das genau die symptome die du siehst. wenn ein panstamp mit verschlüsselung eine umverschlüsselte nachricht bekommt ignoriert er ab da alles was empfangen wird.

    bei einem falschen password kann aber alles mögliche passieren. weder der sketch noch fhem hat wirklich die möglichkeit zu verifizieren das das password richtig war oder nach dem entschlüsseln müll raus kommt. sobald enableAntiPlayback() geht ist das nicht mehr so kritisch weil die sequenz nummer nach dem entschlüsseln stimmen muss.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 07 Februar 2014, 22:48:01
    ich habe unter C:\Program Files (x86)\Arduino\libraries\panstamp die panstamp.cpp geändert und anschließend in der Arduino IDE auf "Upload" geklickt.

    Ich habe jetzt einmal den typ geändert und wieder zurück auf panstamp und anschließend auf upload, aber nachwievor dasselbe.

    Ansonsten warte ich noch auf enableAntiPlayback() dann sollte das ja zuverlässiger funktionieren.

    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 08 Februar 2014, 10:27:19
    BTW: der panStamp Store wurde komplett neu gebaut und es ist auch wieder Ware verfügbar.

    http://panstamp.org/store/

    Allerdings wird das RGB Carrier Board momentan noch nicht angeboten.
    Titel: Antw:panStamp support
    Beitrag von: Bjoern777 am 17 Februar 2014, 20:46:22
    Bin leider erst jetzt dazu gekommen mir die Verschlüsselung einmal anzusehen.
    Hier mal die Sachen, die ich in der Konfiguration eingestellt hatte.

    Nachdem die Testfälle abgearbeitet waren, hat der Sensor trotz korrekt hinterlegten Passworten ununterbrochen gesendet.
    Auch ein mehrfaches stromlos machen des Sensors hat nicht geholfen. Ich musste erst das SWAP_F1 Device in der fhem.cfg entfernen, dann hat wieder alles wie erwartet funktioniert.

    Die Verschlüsselung scheint dass zu tun was sie soll. :)
    Allerdings ist mir aufgefallen, dass im Falle eines falsch hinterlegten Passworts der Sensor ununterbrochen sendet.
    Mir stellt sich die Frage, ob man sich durch eine fehlerhafte Konfiguration sein FHEM durch einen DoS Angriff still legt.

    Ansonten eine coole Sache. :)
    =============================================================================
    Fall 1: NOK
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    attr panStick smartPassword 1,2,3,4,5,6,7,8,9,10,11,10

    SWAP_F1
    -------
    kein Eintrag

    => Sensor sendet ununterbrochen Sensorwerte, diese werden im Log im Klartext angezeigt

    Wieso sendet der Sensor ununterbrochen?
    Wieso werden die Werte im Log im Klartext angezeigt, wenn für das Device kein Passwort hinterlegt ist?

    =============================================================================
    Fall 2:  OK
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    attr panStick smartPassword 1,2,3,4,5,6,7,8,9,10,11,10

    SWAP_F1
    -------
    attr SWAP_F1 smartPassword 1,2,3,4,5,6,7,8,9,10,11,10


    => Sensor sendet Werte, diese werden im Log im Klartext angezeigt

    =============================================================================
    Fall 3:  NOK
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    attr panStick smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    SWAP_F1
    -------
    attr SWAP_F1 smartPassword 1,2,3,4,5,6,7,8,9,10,11,10



    => Sensor sendet ununterbrochen Werte, im Log sind keine Eintraege vorhanden

    Wieso sendet der Sensor ununterbrochen?

    =============================================================================
    Fall 4:  NOK
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    attr panStick smartPassword 1,2,3,4,5,6,7,8,9,10,11,10

    SWAP_F1
    -------
    attr SWAP_F1 smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    => Sensor sendet ununterbrochen Sensorwerte, diese werden im Log im Klartext angezeigt

    Wieso sendet der Sensor ununterbrochen?

    =============================================================================
    Fall 5:  NOK
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    attr panStick smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    SWAP_F1
    -------
    attr SWAP_F1 smartPassword 1,2,3,4,5,6,7,8,9,10,11,12

    => Sensor sendet ununterbrochen Sensorwerte, im Log sind keine Eintraege vorhanden

    Wieso sendet der Sensor ununterbrochen?


    =============================================================================
    Fall 6:   OK??
    -------

    SKETCH
    ------
    byte password[] = {1,2,3,4,5,6,7,8,9,10,11,10};


    panStick
    --------
    kein Eintrag

    SWAP_F1
    -------
    attr SWAP_F1 smartPassword 1,2,3,4,5,6,7,8,9,10,11,10


    => Sensor sendet ununterbrochen, im Log ist zu finden:  "SWAP no password configured"

    Wieso sendet der Sensor ununterbrochen?
    Titel: Antw:Aw: panStamp support
    Beitrag von: Tobias am 28 Mai 2014, 08:14:29
    Zitat von: justme1968 am 07 September 2013, 16:39:06
    anbei die änderung mit der das aufwachen alle 12 stunden funktionieren sollte.

    Hi Andre,
    deine Änderungen sind leider noch nicht auf der panstamp-seite in der Download-section (http://www.panstamp.com/downloads) verfügbar :(

    Edit: ich hab mal den SoilmoistureSketch auf 4 Sensoren aufgebohrt
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Mai 2014, 10:43:36
    die aktuellen versionen der sketches die für fhem erweitert wurden findest du immer im fhem svn unter contrib/arduino.

    ich muss mal schauen ob man das vielleicht etwas besser mit der jeweiligen panstamp version abstimmen kann.

    du hast bei der quad version das auslesen der sensoren eingebaut. aber vergessen die werte auch wirklich zu senden. das deviceDescription file ist auch noch nicht angepasst. d.h. die werte würden auch nach dem senden noch nicht richtig aufbereitet in fhem landen. ich schaue mir beides an sobald ich dazu komme und checke es ein.

    zu überlegen wäre noch wie man das rückwärts kompatibel macht. zur zeit ist am fertig kompilierten device nicht zu erkennen wie viele sensoren man dran hängen kann. ganz schick wäre natürlich wenn der panstamp das selber feststellt oder es zumindest über ein register zu konfigurieren. dann müsste man nichts am sketch ändern wenn man einen sensor abklemmt oder entfernt. würde da noch jemandem ausser dir nützen :) ?

    noch ein aspekt wäre eventuell die sensoren nicht alle gleichzeitig ein zuschalten sondern zumindest gruppen weise nacheinander. eventuell gibt das einer schwachen batterie nicht sofort das letzte. ich hab aber kein equipment um das zu messen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Matthias Gehre am 21 September 2014, 17:31:30
    Hi,

    hab eben ein bisschen rumprobieren müssen, bevor mir folgendes aufgefallen ist:
    Alle eingehenden Pakete von Adresse 01 werden ignoriert, auch wenn man die Adresse des Panstamp in der fhem.cfg umstellt.
    Siehe Zeile 927 in 34_SWAP.pm.

    Der Check sollte wohl lieber gegen die Adresse des Pansticks checken?
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 21 September 2014, 17:50:45
    ja. das stimmt. das eigentliche problem ist das die trennung von panstamp und swap modul nicht ganz sauber möglich ist.
    die adresse des panstamp wird auf modem ebene im pansamp modul vergeben. dsa swap modul weiss davon eigentlich nichts.

    ich habe noch keine idee wie man das wirklich sauber lösen kann.

    die zweite komplikation ensteht wenn man mehrere fhem systeme mit jeweils eigenem panstick betreibt. dann müssten in jedem fhem system die adressen aller pansticks bekannt gemacht werden.

    zur zeit ist es das einfachste für den/die panstick die default adresse 01 zu verwenden. das funktioniert auch wenn man mehrere fhem systeme mit jeweils eigenem panstick hat.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: locutus am 17 November 2014, 19:25:59
    Hallo,
    wie kann ich einen Colorpicker mit dem normalen rgbdriver Sketch verwenden? Reicht eine Änderung der SWAP ID in der product.h aus?
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 17 November 2014, 19:42:25
    der normale sketch und das generelle fhem modul verstehen nur die regSer und regGet kommandos. wenn du hier den colorpicker verwenden willst geht das nur per readingsProxy.

    das einfachste ist es den sketch und das fhem modul für das rgb board zu verwenden. dann hast du neben dem colorpicker, einem farbigen state icon auch alle möglichen kommandos wie on, off, on-for-timer, dimup, ... und kannst konfigurieren wie das board nach dem hart oder soft einschalten reagieren soll.

    mit fällt kein grund ein mit fhem den original sketch zu verwenden.

    gruß
      andre 
    Titel: Antw:panStamp support
    Beitrag von: locutus am 17 November 2014, 22:47:50
    Trotz Modifikationen an den Libraries und als Windowsgeschädigter erhalte ich während der Kompilierung mit der Arduino IDE einige Fehlermeldungen. Das gehört aber in den anderen Forumsbeitrag.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 17 November 2014, 22:51:27
    weiter oben im thread ist ein hex file von einer recht aktuellen version.

    nimm erst mal die. ich hoffe das ich jetzt im herbst/winter dazu komme meine letzten änderungen auch offiziell frei zu geben. ich versuche dann auch wieder das kompilieren unter windows zum laufen zu bekommen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Maiks am 14 Dezember 2014, 21:10:23
    Ich kann es leider auch nicht unter windows kompilieren, habe alle Versionen ausprobiert :(

    Könnte jemand das HEX file hoch laden, damit ich es erst mal probieren kann (original board)

    Danke
    Titel: Antw:panStamp support
    Beitrag von: Matthias Gehre am 18 Dezember 2014, 00:57:19
    Ich mache hier noch mal Werbung für den Patch in http://forum.fhem.de/index.php/topic,30589.0.html
    falls du nicht alles mitliest :-)
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 18 Dezember 2014, 09:49:39
    hatte den patch schon gesehen :). sehr schön.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Maiks am 20 Dezember 2014, 20:27:14
    Kann es sein, das mit der 1.5.8 Arduino das ganze nicht mehr Funktioniert, da sich die API geändert hat ?

    Habe versucht einige Befehle Anzupassen, aber nicht alle neuen pendants gefunden :(

    EEPROM als not declared meckert er auch noch an, allerdings scheint es wird eingebunden.

    Arduino: 1.5.8 (Windows 8), Board: "panStamp AVR w/ atmega328p"

    Verwende die Bibliothek swap im Ordner: C:\Program Files (x86)\Arduino\libraries\swap (legacy)

    Verwende die Bibliothek EEPROM im Ordner: C:\Program Files (x86)\Arduino\hardware\panstamp\avr\libraries\EEPROM



    C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=158 -DARDUINO_PANSTAMP_AVR -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\cores\panstamp -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\variants\panstamp -IC:\Program Files (x86)\Arduino\libraries\swap -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\libraries\EEPROM C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\fade.cpp -o C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\fade.cpp.o

    C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=158 -DARDUINO_PANSTAMP_AVR -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\cores\panstamp -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\variants\panstamp -IC:\Program Files (x86)\Arduino\libraries\swap -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\libraries\EEPROM C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\ledChannel.cpp -o C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\ledChannel.cpp.o

    C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=158 -DARDUINO_PANSTAMP_AVR -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\cores\panstamp -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\variants\panstamp -IC:\Program Files (x86)\Arduino\libraries\swap -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\libraries\EEPROM C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\rgbled.cpp -o C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\rgbled.cpp.o

    C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=158 -DARDUINO_PANSTAMP_AVR -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\cores\panstamp -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\variants\panstamp -IC:\Program Files (x86)\Arduino\libraries\swap -IC:\Program Files (x86)\Arduino\hardware\panstamp\avr\libraries\EEPROM C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\sketch.cpp -o C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\sketch.cpp.o

    sketch.ino: In function 'void getConfig()':
    sketch.ino:99:47: error: 'EEPROM' was not declared in this scope
    In file included from sketch.ino:90:0:
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    sketch.ino:99:59: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    sketch.ino:111:27: error: 'EEPROM' was not declared in this scope
    In file included from sketch.ino:90:0:
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:24:33: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    #define EEPROM_CONFIG_REPEATER  EEPROM_POWER_ON_STATE+sizeof(powerOnState)
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:31:27: note: in expansion of macro 'EEPROM_CONFIG_REPEATER'
    #define EEPROM_CONFIG_IR  EEPROM_CONFIG_REPEATER+1
                               ^
    sketch.ino:111:39: note: in expansion of macro 'EEPROM_CONFIG_IR'
    sketch.ino:115:30: error: 'EEPROM' was not declared in this scope
    In file included from sketch.ino:90:0:
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:24:33: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    #define EEPROM_CONFIG_REPEATER  EEPROM_POWER_ON_STATE+sizeof(powerOnState)
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:31:27: note: in expansion of macro 'EEPROM_CONFIG_REPEATER'
    #define EEPROM_CONFIG_IR  EEPROM_CONFIG_REPEATER+1
                               ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:38:29: note: in expansion of macro 'EEPROM_CONFIG_IR'
    #define EEPROM_CONFIG_FADE  EEPROM_CONFIG_IR+sizeof(ir_cmds)
                                 ^
    sketch.ino:115:42: note: in expansion of macro 'EEPROM_CONFIG_FADE'
    sketch.ino: In function 'void setup()':
    sketch.ino:184:31: error: 'getRegister' was not declared in this scope
    sketch.ino:186:12: error: 'class PANSTAMP' has no member named 'enterSystemState'
    sketch.ino: In function 'void loop()':
    sketch.ino:278:13: error: 'EEPROM' was not declared in this scope
    In file included from sketch.ino:90:0:
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    sketch.ino:278:26: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    sketch.ino:288:40: error: 'getRegister' was not declared in this scope
    sketch.ino:477:35: error: 'getRegister' was not declared in this scope
    sketch.ino:481:35: error: 'getRegister' was not declared in this scope
    sketch.ino:528:36: error: 'class PANSTAMP' has no member named 'txInterval'
    sketch.ino:528:66: error: 'class PANSTAMP' has no member named 'txInterval'
    sketch.ino:532:33: error: 'getRegister' was not declared in this scope
    regtable.ino: At global scope:
    regtable.ino:103:55: error: 'updLedPower' was not declared in this scope
    regtable.ino: In function 'const void updInternalTemp(byte)':
    regtable.ino:180:24: error: 'class PANSTAMP' has no member named 'getInternalTemp'
    In file included from sketch.ino:90:0:
    regtable.ino: In function 'const void setPowerOnState(byte, byte*)':
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    regtable.ino:194:18: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    regtable.ino: In function 'const void setCommand(byte, byte*)':
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:24:33: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    #define EEPROM_CONFIG_REPEATER  EEPROM_POWER_ON_STATE+sizeof(powerOnState)
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:31:27: note: in expansion of macro 'EEPROM_CONFIG_REPEATER'
    #define EEPROM_CONFIG_IR  EEPROM_CONFIG_REPEATER+1
                               ^
    regtable.ino:276:30: note: in expansion of macro 'EEPROM_CONFIG_IR'
    regtable.ino:319:33: error: 'getRegister' was not declared in this scope
    In file included from sketch.ino:90:0:
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:19:33: error: 'EEPROM_FIRST_CUSTOM' was not declared in this scope
    #define EEPROM_POWER_ON_STATE   EEPROM_FIRST_CUSTOM
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:24:33: note: in expansion of macro 'EEPROM_POWER_ON_STATE'
    #define EEPROM_CONFIG_REPEATER  EEPROM_POWER_ON_STATE+sizeof(powerOnState)
                                     ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:31:27: note: in expansion of macro 'EEPROM_CONFIG_REPEATER'
    #define EEPROM_CONFIG_IR  EEPROM_CONFIG_REPEATER+1
                               ^
    C:\Users\Maik\AppData\Local\Temp\build2955246040970405916.tmp\eeprom.h:38:29: note: in expansion of macro 'EEPROM_CONFIG_IR'
    #define EEPROM_CONFIG_FADE  EEPROM_CONFIG_IR+sizeof(ir_cmds)
                                 ^
    regtable.ino:381:22: note: in expansion of macro 'EEPROM_CONFIG_FADE'
    Fehler beim Übersetzen
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Dezember 2014, 21:13:14
    das ganze ist noch nicht mit der neuen ide und der neuen panstamp lib getestet.

    nimm bitte erst mal die alte ide und panstamp lib.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: locutus am 19 Januar 2015, 21:34:16
    Ich versuche an meinem panStamp das Sendeintervall zu ändern:
    set SWAP_F0 regSet 0A 0258
    Leider ohne Erfolg:
    "set SWAP_F0 regSet" needs two arguments
    Hängt das eventuell mit dem letzten Update zusammen?
    # $Id: 34_SWAP.pm 7554 2015-01-13 18:46:28Z justme1968 $
    # $Id: 34_panStamp.pm 4756 2014-01-27 21:15:50Z justme1968 $
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 19 Januar 2015, 21:46:52
    die letzen änderungen waren alle nach der zeile die diese meldung ausgibt.

    ich habe es gerade mit einer aktuell ausgeheckten version probiert und ich bekomme diese meldung nicht.

    hast du die zeile genau so eingegeben ?

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: locutus am 19 Januar 2015, 22:00:10
    Eigenartig! Die direkte Eingabe hat funktioniert. Die Auswahl und Eingabe via Webinterface führt zu der o.g. Meldung.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Januar 2015, 12:38:34
    ich habe den auslöser des problems gefunden. siehe hier: http://forum.fhem.de/index.php/topic,31293.msg248786.html#msg248786 (http://forum.fhem.de/index.php/topic,31293.msg248786.html#msg248786).

    bis zur lösung bitte das set auf kommandozeile verwenden.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Januar 2015, 23:26:19
    ab morgen sollte es auch wieder über die menüs in der detail ansicht gehen.

    gruß
      andre
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 07 April 2015, 20:26:06
    Habe einen kleinen Schönheits FeatureRequest.
    Bei vielen Readings werden diese falsch in der Liste Sortiert. zb. kommt 0B.10 vor 0B.2.
    Da wäre es besser wenn du die Readings komplett zweistellig im Modul anlegst, zb. 0B.02
    Bei meinem Umweltsensor habe ich 18 ConfigurationsOptionen ;)

    Nur falls du mal Zeit hast und nicht weißt was du machen sollst ;)
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 07 April 2015, 22:45:23
    darüber habe ich auch schon nachgedacht. das problem ist ich weiss nicht wie ich das automatisch und rückwärts kompatibel hin bekomme.

    ich wollte aber sowieso noch ein paar attribute einbauen um z.b. zu steuern ob die hex register events generieren oder nicht.

    ein attribut das die führende 0 aktiviert könnte ich für neue devices automatisch setzen und alte wären nicht betroffen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 07 April 2015, 22:52:51
    kannst du mal bitte testen ob bei einem neuen device noch alles geht wenn du in 34_SWAP.pm in zeile 805 das hier einbaust:$ep = "0$ep" if( length($ep) == 1 );

    erst mal noch mit allen nebenwirkungen für alte devices.

    danke
      andre
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 14 April 2015, 21:24:42
    Ich wollte in naher Zukunft alle hier in diesem Thread aus non-developer Sicht für die spätere Anwendung und Inbetriebnahme relevanten Informationen (also aus meiner ;) ) mal in einem Artikel zusammenfassen und den Artikel im Wiki damit überarbeiten. Besteht daran Interesse?

    Ich muss gestehen, bis ich meine ersten Panstamps am Laufen hatte, musste ich viel lesen und der derzeitige Artikel ist recht rudimentär, wenn man neu im Thema ist (alles eine Frage des Wissensstandes).

    Außerdem habe ich ein ziemlich schlechte Gedächtnis, vergesse das alles ziemlich schnell wieder und würde das sonst ins private Wiki schmeißen.
    Würde mich freuen, wenn das jemand gegenliest und konstruktiv kommentiert.

    Bei Interesse, wo würde eine Draft-Version denn am ehesten hinpassen, auf die Diskussionsseite im Wiki des Panstamp-Artikels, neuer Thread, hier?

    Schöne Grüße,
    John

    ps: @ Andre, wenn noch etwas weiter bin, kann ich ebenfalls testen, allerdings nur mit 2 RGBs...
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 14 April 2015, 21:35:52
    im wiki kannst du dich gerne austoben. wenn du dir unsicher bist pack es auf die diskussions seite. das ganze eventuell später aufteilen können wir dann immer noch.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 14 April 2015, 21:42:14
    Ok, melde mich dann, wenn es was zu lesen gibt. Danke für die Unterstützung!

    Beschäftige mich leider noch nicht so lange mit den Panstamps...

    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 18 April 2015, 06:51:59
    Hi Andre,
    wenn ich im Wiki wie angegeben folgendes absetze, kommt folgender fehler.
    set <MySwapDevice> regSet 0B.17 1
    reading for 0B is not available


    Die Readings vom Register 0b liegen aber vollständig in FHEM vor...?? *grübel*
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 19 April 2015, 10:44:57
    die meldung kommt weil das modul zur zeit nach einem reading mit namen <reg id>-<reg name> sucht. in einem xml hat das komplette register keinen namen sondern nur alle entbeinst. dadurch wird das reading dann nicht gefunden.

    ich habe aber gehen das ich nur das setzen von endpoints mit 1 bit länge eingebaut habe.

    d.h. ich muss sowieso noch mal nachbessern bist das so geht wie vorgesehen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 01 Mai 2015, 20:10:03
    Zitat von: joshi04 am 14 April 2015, 21:42:14
    ... wenn es was zu lesen gibt.

    Es gibt etwas zu lesen/kommentieren/korrigieren.
    http://www.fhemwiki.de/wiki/Diskussion:PanStamp (http://www.fhemwiki.de/wiki/Diskussion:PanStamp)

    Leider noch nicht ganz fertig, daher erstmal auf der Diskussionsseite des Hauptartikels.

    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 01 Mai 2015, 20:48:31
    Ich finde eine Erklärung von "list <device>" hat in diesem Artikel nichts verloren, da es nichts panStamp-spezifisches ist sondern Gesamt-FHEM.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 02 Mai 2015, 09:44:31
    das schaut schon sehr umfangreich aus. du warst wirklich gründlich.

    ich habe beim überfliegen ein paar stellen gefunden die noch nicht ganz konsistent oder aktuell sind aber das aller meiste ist wirklich ein großer fortschritt gegenüber der aktuellen version.

    ich lese es noch mal in ruhe und korrigiere die stellen.

    vielen dank für deine mühe.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 02 Mai 2015, 16:45:12
    Hallo Andre,

    das freut mich, schon mal danke fürs Korrekturlesen.

    Ich bin selbst aber auch noch nicht so ganz zufrieden. Aber wie das immer so ist, wenn man erstmal was hat, muss man es erstmal eine Weile liegen lassen, bis man die Stellen selbst wieder sieht.
    Daher - lass Dir Zeit und "tob Dich aus". Woher ich das bloß wieder hab... ;)

    Und außerdem fehlt bei den Details für den RGB-Sketch noch ordentlich was (ist noch in Vorbereitung).

    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 02 Mai 2015, 17:33:32
    Ich würde den RGB-Board Artikel in einen eigenen Wiki-Artikel auslagern und nur hier verlinken. Analog Panstamp Umweltsensor/Bodenfeuchtesensor
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 02 Mai 2015, 18:23:33
    Ich hab noch nicht alles durch, aber ich denke auch Tobias hat vollkommen recht. Also es macht für eine bessere Übersicht mehr Sinn, die ganzen "Boards" bzw. Anwendungen, Satelliten wie auch immer man es nennt, in einem extra Bereich aufzugliedern.

    Gruß
    Daniel
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 03 Mai 2015, 14:22:32
    Ich habe die Kapitel 4.1 - 4.3 mal ein wenig umgestellt, um das Auslagern der spezifischen Anwendungen ein wenig vorzubereiten. Vieles hatte ich erst in Kapitel 5.1.4 beschrieben, obwohl es eigentlich zum allgemeinen Teil gehörte.

    Ich bin auch der Meinung, dass die spezifischen Anwendungen einen separaten Artikel verdienen. Ich werde das Auslagern vornehmen, sobald der Artikel für das RGB-Board etwas mehr Fleisch besitzt. Das derzeitige Kapitel 5.1.4. ist offline in Vorbereitung.

    Bitte tut Euch keinen Zwang an, es auch direkt im Wiki zu bearbeiten. Deswegen habe ich es online gestellt.

    Der Einwand zu "list <device>" ist natürlich richtig, das ist nichts modulspezifisches. Es unter Troubleshooting zu nennen als Hinweis/Erinnerung und mögliche Maßnahme, eine Übersicht über die Definition zu erhalten, finde ich aber nicht abwegig. Mir ist das aber eigentlich ziemlich egal.
    Über die recht negative Formulierung "hat in diesem Artikel nichts verloren" hab ich mich ein wenig gewundert.

    Schöne Grüße,
    John

    Edith:
    Mir ist gerade noch etwas aufgefallen, das wird aber nichts mehr an diesem Wochenende:
    Das Kapitel 4.3.2. beschreibt eigentlich die Funktionen des 34_SWAP-Moduls und sollt auch so heißen. Und für das spezifische Modul braucht es noch ein paar erklärende Sätze. Hier ist also absehbar, dass sich noch etwas grundlegendes ändert.

    Edith die 2.:
    Mir ging das so sehr auf die Nerven, dass ich das doch noch geändert habe.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Mai 2015, 09:22:28
    ich habe eine kleine änderung am panStamp modul eingecheckt. damit kann man jetzt auch einen per ser2net angebunden jeelink ansprechen. ich habe eine kleine änderung am jeelink modul eingecheckt. damit kann man jetzt auch einen per ser2net angebunden panstamp ansprechen.

    gruss
      andre

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 20 Mai 2015, 11:49:26
    Zitat von: justme1968 am 20 Mai 2015, 09:22:28
    ich habe eine kleine änderung am panStamp modul eingecheckt. damit kann man jetzt auch einen per ser2net angebunden jeelink ansprechen. ich habe eine kleine änderung am jeelink modul eingecheckt. damit kann man jetzt auch einen per ser2net angebunden panstamp ansprechen.

    Und auch ein Beispiel in der Doku? Wäre toll....
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Mai 2015, 11:57:57
    du musst auf dem anderen rechner das ser2net einrichten und gibst im define dann host:port anstelle des device an.

    such mal im wiki oder forum nach ser2net. da gibt es ein paar beispiele für den cul.

    die konfiguration für den panstamp ist identisch.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 20 Mai 2015, 23:17:59
    Daumen hoch dafür. Darauf habe ich schon lange gewartet. Endlich kann ich mein socat-im-screen-Gefummle abschalten.

    Vielen Dank dafür.

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 20 Mai 2015, 23:21:05
    Hier mal meine ser2net.conf:


    2000:raw:0:/dev/ttyAMA0:38400 8DATABITS NONE 1STOPBIT


    und in FHEM:
    define panStamp_Shield raspberry-wohnzimmer:2000

    Funktioniert astrein.
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 14 Juli 2015, 21:27:42
    Hallo zusammen,

    ich hab mich auch mal an meine PanStamp gemacht - aber ich scheitere mal wieder.
    Nicht mit der Integration in FHEM - das klappt wunderbar.
    Ich scheitere am flashen der PanStamp mit dem soilmoisture-sketch aus dem svn-Link aus dem Wiki http://www.fhemwiki.de/wiki/PanStamp (http://www.fhemwiki.de/wiki/PanStamp)

    Arduino-IDE 1.6.4 ist installiert und läuft.
    Ich bin auch https://code.google.com/p/panstamp/wiki/firststeps (https://code.google.com/p/panstamp/wiki/firststeps) gefolgt aber ein kompilieren des Sketch endet mit einem
    ZitatIn file included from soilmoisture.ino:42:0:
    regtable.h:31:22: fatal error: register.h: No such file or directory
    #include "register.h"
                          ^
    compilation terminated.
    Multiple libraries were found for "regtable.h"
    Used: D:\Arduino\libraries\soilmoisture
    Not used: D:\Arduino\libraries\soilmoisture
    Fehler beim Kompilieren.

    Wenn ich hingegen den soilmoisture-sketch unter SWAP lade und kompiliere klappt es einwandfrei.
    Auch das übertragen scheint zu klappen - geflasht wird mit einem panStick v3.0.
    Dieser blinkt auch fröhlich hektisch vor sich hin wenn ich in der IDE auf Hochladen klicke.

    Am Ende des flashen blinkt der Stick 6-mal, dann ziehe ich ihn ab und stecke den Guten auf mein Batteryboard.
    Batterie rein und FHEM legt das Device per autocreate an ABER - der Feuchtewert stimmt nicht (da kann aber FHEM nichts dafür - weil)
    im Sketch habe ich z.B definiert
    #define SENSOR_0_PIN  A3    // Analog pin - sensor 0
    #define POWER_0_PIN   18    // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  A4    // Analog pin - sensor 1
    #define POWER_1_PIN   20    // Digital pin used to powwer sensor 1

    im Reiter regtable hab ich hier
    digitalWrite(POWER_0_PIN, HIGH);
      digitalWrite(POWER_1_PIN, HIGH);
      delay(10);
      // Read analog values
      unsigned int adcValue0 = analogRead(SENSOR_0_PIN);
      unsigned int adcValue1 = analogRead(SENSOR_1_PIN);
      // Unpower sensors
      digitalWrite(POWER_0_PIN, LOW);
      digitalWrite(POWER_1_PIN, LOW);

    das delay
    a) erst auf 400 ms geändert - lt. Datenblatt zum Vegetronix und nun
    b) auf 1000 und auch auf 10000 geändert da a) nicht geklappt hat (der Sensor hat immer noch keine plausible Feuchte gemeldet - war dann klar warum nicht).

    Der Port wird nicht auf HIGH gelegt und entsprechend kommt am Analogeingang auch nichts verwertbares an.
    Aber egal welchen Port ich versuche für POWER_0_PIN oder POWER_1_PIN - der PanStamp macht nicht das was ich vermute (erhoffe).

    Ich hätte jetzt erwartet das mit einem delay(10000); Pin 18 am PanStamp resp. D3 (also bei K6 der linke Anschluss) am Batteryboard für 10 Sekunde auf HIGH gelegt wird (~3.3V) aber das macht der Gute nicht.
    Es wird übrigens kein DO auf HIGH gelegt - über FHEM habe ich Register 0A auf 001E gestellt (30 Sekunden Intervall) und das klappt auch (die Readings in FHEM aktualisieren sich alle 30 Sekunden - aber FHEM ist nicht das Problem) aber der Pin geht nicht auf 3.3 Volt, genauer - es wird kein Pin auf HIGH gelegt (ich hab alle der Reihe nach gemessen) und dementsprechend kann natürlich am analogen Eingang auch nichts ankommen.
    Wobei es dem PanStamp aber auch egal zu sein scheint wenn ich A3 (Pin 8), wie laut SENSOR_0_PIN, auf GND ziehe oder auf Vcc lege.

    Hm. Viel geschrieben mit wenig Inhalt (vermutlich).
    Ich bin mal wieder für einen Schubs dankbar.

    Grüße

    Edith: Ich hab ein Digital-Multimeter das 3.3V innert 1 Sekunde auf alle Fälle messen kann und Elektronen sind mir nicht unbekannt  8)
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 14 Juli 2015, 21:54:56
    Hallo Puschel74,

    nur mal eine Frage ins Blaue hinein bezüglich dem "Fehler beim Kompilieren", weißt Du sicher, dass der Sketch mit der IDE 1.6.4 kompatibel ist?
    Ist nur ein Verdacht von den billigen Rängen und ich frage nur nach, weil der RGB-Sketch z.Zt. nur mit der 1.x kompiliert werden kann bzw. mit dem tool INO + Arduino unter Linux.

    Und sorry, wenn ich nachfrage, was versteht Du unter "den soilmoisture-sketch unter SWAP lade und kompiliere"? Aber das ist nur eine Verständnisfrage, es scheint ja einwandfrei (ohne Fehlermeldung) durch zu laufen.

    Bei den Details zum Sketches muss ich leider passen.
    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 14 Juli 2015, 22:21:49
    Hi Puschel,

    Seit arduino 1.5 wird eine komplett neue swap Lib eingesetzt, die mit der alten nicht kompatibel ist.
    Das Beispiel bei Google Code ist für arduino 1.0 und mit der alten swap Lib.
    Sketche, die die alte Lib verwenden, sind nicht kompatibel.
    Alles, was es zu panstamp, bei Google Code gibt gehört zur älteren Lib. Alle aktuellen Daten gibt es nun in git.

    Du kannst entweder arduino 1.0 installieren mit der alten Lib. Doku dazu in Google Code.  Damit solltest du dann den vorhandenen Sketch  kompilieren können.
    Oder aber du bleibst bei Arduino 1.6, verwändest also die neue Lib,  muss dann allerdings den vorhandenen Sketch ändern.

    Grüße, Tobias
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 14 Juli 2015, 22:31:07
    Hallo John,

    danke schonmal für deine Antwort.

    Zu
    Zitatnur mal eine Frage ins Blaue hinein bezüglich dem "Fehler beim Kompilieren", weißt Du sicher, dass der Sketch mit der IDE 1.6.4 kompatibel ist?
    Öhm, ja. Also nein.
    Sowas in die Richtung hab ich gelesen aber gehofft das sich da inzwischen was getan hat.

    Zitatwas versteht Du unter "den soilmoisture-sketch unter SWAP lade und kompiliere"?
    Im Ordner libraries/SWAP/examples/soilmoisture gibt es auch eine soilmoisture.ino die sich nach dem laden einwandfrei kompilieren lässt.
    Nur die Änderungen im Code haben keine Auswirkungen - denke ich mal.

    Ich bin mir ziemlich sicher das der Fehler wiedermal zwischen Bildschirm und Tastatur sitzt  :(
    Aber ich find ihn (noch) nicht.

    Grüße
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 14 Juli 2015, 22:40:17
    Hallo Tobias,

    ZitatSketche, die die alte Lib verwenden, sind nicht kompatibel.
    Ja, genau das hab ich auch gelesen.

    ZitatDu kannst entweder arduino 1.0 installieren mit der alten Lib.
    Ja, das hatte ich schon versucht.
    ZitatOder aber du bleibst bei Arduino 1.6, verwändest also die neue Lib,
    War mir dann aber beim einbinden der Lib etwas "komfortabler".

    Zitatmuss dann allerdings den vorhandenen Sketch ändern.
    Hm, ich sehe ich muss mich wohl tiefer in die Sketch-Anpassung einlesen.
    Ich dachte in meiner Naivität doch tatsächlich das es genügt wenn ich den Pin und den delay im soilmoisture-sketch anpasse.

    Eigentlich war ich mir sicher nicht so grün an die Sache ran zu gehen aber so kann ich mich täuschen  :-[

    Grüße
    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 15 Juli 2015, 07:01:28
    Hallo Puschen74,

    Zitat von: Puschel74 am 14 Juli 2015, 22:31:07
    Im Ordner libraries/SWAP/examples/soilmoisture gibt es auch eine soilmoisture.ino die sich nach dem laden einwandfrei kompilieren lässt.

    Hm, eigentlich dachte ich (Vorsicht, Halbwissen), dass die dort abgelegten Sketches nur eine "Dienstleistung" des FHEM-Pakets sind, sodass man sich nicht auf die Suche auf Git oder Google machen muss. Kompilieren und Hochladen muss man die aber genauso, egal woher sie stammen. Daher kann ich ehrlicher Weise immer noch nicht so richtig folgen. Lässt sich dieser Sketch mit der 1.6 fehlerfrei kompilieren?

    Dass Änderungen an den Quellen nicht im Sketch ankommen, kann ja eigentlich nicht sein. Vielleicht probierst Du mal extremere, ich meine leicht prüfbare Änderungen am Sketch, um sicherzustellen, dass diese auch auf dem panStamp landen (nur um hier Fehler auszuschließen).

    Zitat von: Puschel74 am 14 Juli 2015, 22:40:17
    Hm, ich sehe ich muss mich wohl tiefer in die Sketch-Anpassung einlesen.
    Daran habe ich mich bislang noch nicht dran getraut. Wenn Du das hinbekämest, wäre das ein großer Fortschritt. Derzeit - meines Wissens - Sketche, die noch nicht angepasst worden sind und nur mit der 1.x kompatibel sind, laufen daher nicht auf den NVRs, da diese mit der 1.x nicht mehr kompatibel sind...

    Hallo Tobias
    Zitat von: TeeVau am 14 Juli 2015, 22:21:49
    Alles, was es zu panstamp, bei Google Code gibt gehört zur älteren Lib. Alle aktuellen Daten gibt es nun in git.
    Danke, den Hinweis kannte ich noch nicht. :)

    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 15 Juli 2015, 07:37:11
    Die Befehle für digitalWrite etc. sollten eigentlich immer funktionieren. Die sind ja von der Arduino Lib und nicht von der Panstamp/SWAP Lib.
    Hast du die AVR oder NRG Version?
    Mich macht das #DEFINE für die Power Pins stutzig. Die Digitalpins werden doch als 1 für Digital1 etc. angegeben, und nicht als 17 (Pin Nummer am Sockel) für Digital 1?! Oder bin ich jetzt auf dem Holzweg?

    Der Sketch, der im FHEM SVN ist (35_SWAP-soilmoisture.tar.gz) ist für die alte swap lib und Arduino IDE 1.0.x. Das kannst du u.a. an der Codezeile #include "panstamp.h"". Das ist ein Zeichen dafür, dass die alte Lib verwendet wird. Das wäre dann, soweit ich weis, nicht mit dem panStamp NRG kompatibel.
    Der Sketch, der mit der neuen Lib und Arduino 1.6 installiert wird, ist am "#include "swap.h"" zu erkennen. Der kann NRG und AVR.
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 15 Juli 2015, 11:45:56
    Hallo,

    @John
    ZitatHm, eigentlich dachte ich (Vorsicht, Halbwissen), dass die dort abgelegten Sketches nur eine "Dienstleistung" des FHEM-Pakets sind, sodass man sich nicht auf die Suche auf Git oder Google machen muss. Kompilieren und Hochladen muss man die aber genauso, egal woher sie stammen. Daher kann ich ehrlicher Weise immer noch nicht so richtig folgen. Lässt sich dieser Sketch mit der 1.6 fehlerfrei kompilieren?
    Ja, der "beiliegende" Sketch lässt sich ohne Probleme kompilieren und übertragen.

    ZitatDass Änderungen an den Quellen nicht im Sketch ankommen, kann ja eigentlich nicht sein. Vielleicht probierst Du mal extremere, ich meine leicht prüfbare Änderungen am Sketch, um sicherzustellen, dass diese auch auf dem panStamp landen (nur um hier Fehler auszuschließen).
    Tja, wenn du mir sagst welche Änderungen ich machen soll zum probieren dann gerne.
    Wie geschrieben - selbst ein ändern der Pinbelegung scheint nicht zu klappen.
    Aber ich denke mal da hab ich nur etwas falsch verstanden.

    @Tobias
    ZitatDie Befehle für digitalWrite etc. sollten eigentlich immer funktionieren. Die sind ja von der Arduino Lib und nicht von der Panstamp/SWAP Lib.
    Dann bin ich ja doch nicht soo falsch gelegen.

    ZitatDer Sketch, der im FHEM SVN ist (35_SWAP-soilmoisture.tar.gz) ist für die alte swap lib und Arduino IDE 1.0.x. Das kannst du u.a. an der Codezeile
    Jep, das include panstamp.h ist im "alten" Sketch vorhanden - dann lösch ich den wieder.

    ZitatHast du die AVR oder NRG Version?
    AVR

    ZitatMich macht das #DEFINE für die Power Pins stutzig. Die Digitalpins werden doch als 1 für Digital1 etc. angegeben, und nicht als 17 (Pin Nummer am Sockel) für Digital 1?!
    Öhm, ich hab das von Seite 13 aus diesem Beitrag von andre
    http://forum.fhem.de/index.php/topic,12487.msg88077.html#msg88077 (http://forum.fhem.de/index.php/topic,12487.msg88077.html#msg88077)
    und folgende Seiten/Beiträge bis ca. Seite 15 (etwas verteilt).
    Wobei ich mit Andres Pinzuordnung nicht viel anfangen kann  :-[

    Die Pinzuordnung habe ich versucht anhand des angehängten Bildes vor zu nehmen.

    Die Anschlüsse habe ich nach dem zweiten Bild dann gemacht - so wie im Wiki steht A4 für den analogen Anschluss und D7 für die Spannungsversorgung.
    Aber wie gesagt:
    Der PanStamp nimmt die Intervalländerungen per FHEM an - er sendet mir brav alle 30 Sekunden (zu Testzwecken) an den Panstick.
    Aber ich hatte nun gehofft das auch alle 30 Sekunden D7 auf High gezogen wird um an A4 dann das Signal messen zu können das der Sensor liefert.
    D7 geht aber nicht auf High und dementsprechend kann am Signalanschluss auch nichts zurück kommen (vom Sensor).
    Selbst ein Brücken von A4 mit GND oder Vcc veranlaast den PanStamp nicht dazu mir ein 0% oder 100%-Signal zu liefern.

    Der Fehler sitzt also immer noch zwischen Bildschirm und Tastatur - der PanStamp lässt sich einfach nicht flashen und die IDE wirft aber keine Meldung dazu aus.
    Wenn ich am PanStick den Prog-Schalter in Stellung PROG schiebe dann meckert die IDE das der Programmer nicht antwortet.
    Den Schalter zurück und die IDE scheint wohl was auf den Stamp zu schreiben da die LED`s am Stick dann anfangen zu blinken.
    Wenn die IDE meint das sie fertig ist blinkt am PanStamp 6-mal die LED - das scheint wohl die Init-Sequenz zu sein und das wars dann.
    Umgesteckt auf das Batteryboard sendet der PanStamp brav die Batteriewerte - nur eben die Feuchte nicht.

    Grüße

    Edith: Wobei ich in der IDE durchaus A3 für Sensor_x_Pin angeben kann aber mit D7 für Power_x_Pin meckert die IDE - 22 nimmt die IDE dann wieder ohne zu murren an.
    Titel: Antw:panStamp support
    Beitrag von: Tobias am 16 Juli 2015, 09:59:25
    Für D7 einfach 7 angeben

    Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 16 Juli 2015, 11:26:25
    Zitat von: Tobias am 16 Juli 2015, 09:59:25
    Für D7 einfach 7 angeben
    Sapperlot nochmal. Kaum macht man es richtig  ::)

    Vielen Dank Tobias.
    Das waren aber große Tomaten auf meinen Augen aber nun sieht es gut aus.
    Der erste Sensor meldet schonmal einen plausibleren Wert und er geht in Verbindung mit GND auch auf -1% und dann wieder hoch.
    Nun noch das Gehäuse präparieren und der Gartenbewässerung steht nichts mehr im Wege.

    Grüße
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 16 Juli 2015, 11:32:36
    Hi Puschel,

    also den panStick darfst du NICHT auf Prog. stellen. Prog ist nur für den NRG! Das schon mal um etwas Verwirrung beiseite zu schaffen.
    Also aus Ausgangslage haben wir jetzt: panStamp AVR, Arduino IDE 1.6, neue SWAP Lib und den soilmoisture sketch, der die neue Lib verwendet. Der Sketch kann auch aufgespielt werden. Richtig?
    D4 für die Spannungsversorgung ist ok, dann muss das DEFINE so aussehen: #define POWER_0_PIN   7
    Dann wird der PIN D7 bedient. Sollte er zumindest.
    6 mal blinken nach Reset sieht gut aus, das kommt durch das setup() und lässt den panStamp was empfangen, für die Zeit wo die LED blink.

    poste doch mal bitte die #DEFINES, die du jetzt verwendest. Und Schreib genau an welchen PIN du welchen Kontakt angeschlossen hast. Hab leider keinen panStamp mehr über, mit dem ich testen kann :-/
    Hast du kontrolliert, ob du den richten panStamp Type als Board, in der arduino IDE; ausgewählt hast?

    PS. Wenn du als POWER_PIN 22 definierst, wäre das D22 (Glaube ich zumindest).
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 16 Juli 2015, 13:10:26
    Hallo (anderer) Tobias  ;D

    Zitatalso den panStick darfst du NICHT auf Prog. stellen. Prog ist nur für den NRG! Das schon mal um etwas Verwirrung beiseite zu schaffen.
    Jep, hatte ich auch so gelesen.
    Aber mit der Zeit greift man nach jedem Strohhalm.

    ZitatAlso aus Ausgangslage haben wir jetzt: panStamp AVR, Arduino IDE 1.6, neue SWAP Lib und den soilmoisture sketch, der die neue Lib verwendet. Der Sketch kann auch aufgespielt werden. Richtig?
    Absolut richtig.

    Zitatposte doch mal bitte die #DEFINES, die du jetzt verwendest.
    #define SENSOR_0_PIN  A4    // Analog pin - sensor 0
    #define POWER_0_PIN   7    // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  A5    // Analog pin - sensor 1
    #define POWER_1_PIN   6    // Digital pin used to powwer sensor 1

    digitalWrite(POWER_1_PIN, HIGH);
      delay(500);
      // Read analog values


    ZitatUnd Schreib genau an welchen PIN du welchen Kontakt angeschlossen hast.
    Also.
    Der Vegetronix-Sensor ist mit
    schwarz --> A4
    rot --> D7
    Schirm --> GND
    wenn man die Zeichnung für das Batteryboard nimmt.

    ZitatHast du kontrolliert, ob du den richten panStamp Type als Board, in der arduino IDE; ausgewählt hast?
    siehe Screenshot

    Nun nur noch die restlichen 4 PanStamp flashen und die Boards verbauen und es kann los gehen.

    In FHEM sieht das ganze so aus wie im 2. Screenshot.

    Danke nochmal allen für die Tipps/Hinweise/Lösung  8)

    Grüße
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 16 Juli 2015, 13:44:51
    ja super. Hatte nicht gesehen, dass du bereits Erfolg hattest, als ich meinen reply geschrieben habe. Haben uns vermutlich gerade so eben verpasst ;-)
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 16 Juli 2015, 14:28:31
    Mal eine zusätzliche Frage: Was ist eigentlich mit den Inhalten, die joshi04 auf der Diskussionsseite zu den panStamps, gefüllt hat?
    Das ist eine wirklich respektable Arbeit und ich finde es schade, dass das know-how auf der Diskussionsseite versteckt ist.

    Sollen wir das nicht einmal voran treiben? Es müsste ja nur der Artikel etwas aufgeteilt werden (Die Inhalte, die sich auf spezielle SWAP Module beziehen sollten, wie jedes FHEM Modul, eine eigene Seite bekommen. Grobe Patzer sind Inhaltlich nicht drin...und Feintuning kommt eben danach.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 16 Juli 2015, 14:32:53
    ja. der wiki text solle auf jeden fall online gehen. es wäre schade drum.

    zur not sogar ohne vorher aufteilen.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 16 Juli 2015, 14:48:08
    Ich mach mich mal an eine Aufteilung, heute und in den nächsten Tagen. Ich markiere es als Baustelle, und nachträglich anpassen geht ja noch immer.
    Es versteht sich, meiner Meinung nach, von selbst, dass sich niemand auf den Schlipps getreten fühlt, wenn Änderungen unerwünscht sind?! Dafür gibt es ja die Diskussionsseiten oder die "Rückgängig" Funktion.
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 16 Juli 2015, 19:22:19
    Jetzt ist doch schon die erste Hürde da: Wie sollen am besten die Artikel aufgeteilt werden?
    Wollte gerade den Artikel für das Modul SWAP_0000002200000003 beginnen. Dabei ist mir aufgefallen, dass ja 3 unterschiedliche Komponenten eine Rolle spielen.
    Die Hardware (also das spezifische Board, nicht der PanStamp selber), die Software (z.B. Beschreibung zu compiler schalter) und das FHEM Modul.

    Da Hardware und Software ja doch sehr eng zusammen gehören, würde ich die Teile in einem Artikel beschreiben, in jeweils unterschiedlichen Kapiteln. Das FHEM Modul wird ebenfalls separat beschrieben, in dem Artikel wird dann auf den Hardware Artikel verlinkt.
    Von den Artikelnamen würde meiner Meinung nach Sinn machen:
    Für die Module: Name des Modul, wie im Wiki üblich (Also ohne .pm und Modulstartnummer)
    Für die Hardware/Software: PanStamp <Name vom Gerät>.

    Oder eine Alternative: Alles in einem Artikel (Hardware, Software, FHEM Modul) und ggf. mit weiterleitungen arbeiten. Das hätte z.B. den Vorteil, da es ja auch PanStamp Geräte geben kann, ohne ein eigenes Modul (Wie z.B. der Umweltsensor). Und Geräte, die ein eigenes Modul haben, dort wird eben der Artikel, mit dem Modulnamen, weitergeleitet auf den wirklichen Artikel, der dann alles enthält.

    Normalerweise würde ich einfach loslegen und im Fall der Fälle eben zich mal umstrukturieren, aber das wird wohl im Wiki nicht so gerne gesehen, da die Admins die Änderungen prüfen.
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 18 Juli 2015, 18:00:52
    So, ich muss nochmal nerven  ::)

    PanStamp laufen soweit 1a und senden brav die Werte aber ...

    Ich hab einem Batteryboard 2 Vegetronix gegönnt - klappt auch so weit.
    Userreadings erweitert - ist soweit auch ok (oder auch nicht).
    Nur das Reading VWC_B für den zweiten Sensor wird erst aktualisiert bzw. berechnet wenn das Batteryboard den nächsten Datensatz sendet.

    Blöd beschrieben daher hier mal die Daten aus dem EventMonitor:
    Ich habe A3 und D6 für den zweiten Sensor benutzt und A3 einmal mit GND verbunden und für die nächste Messung mit D6.

    2015-07-18 17:48:05 SWAP SWAP_02 0C.0-Moisture_level_0: 0098
    2015-07-18 17:48:05 SWAP SWAP_02 0C.1-Moisture_level_1: 0000
    2015-07-18 17:48:05 SWAP SWAP_02 VWC_B: -0.57
    2015-07-18 17:48:05 SWAP SWAP_02 Level0_Voltage: 0.48984375
    2015-07-18 17:48:05 SWAP SWAP_02 Level1_Voltage: 0
    2015-07-18 17:48:05 SWAP SWAP_02 VWC_A: 1.46
    2015-07-18 17:48:05 SWAP SWAP_02 0B-Voltage: 0CCA
    2015-07-18 17:48:05 SWAP SWAP_02 voltage: 3.274
    2015-07-18 17:48:05 SWAP SWAP_02 battery: low
    2015-07-18 17:48:05 SWAP SWAP_02 Level0_Voltage: 0.48984375
    2015-07-18 17:48:05 SWAP SWAP_02 Level1_Voltage: 0

    2015-07-18 17:48:35 SWAP SWAP_02 0C.0-Moisture_level_0: 0102
    2015-07-18 17:48:35 SWAP SWAP_02 0C.1-Moisture_level_1: 03FF
    2015-07-18 17:48:35 SWAP SWAP_02 VWC_B: -0.57
    2015-07-18 17:48:35 SWAP SWAP_02 Level0_Voltage: 0.8314453125
    2015-07-18 17:48:35 SWAP SWAP_02 Level1_Voltage: 3.29677734375
    2015-07-18 17:48:35 SWAP SWAP_02 VWC_A: 5.86
    2015-07-18 17:48:35 SWAP SWAP_02 0B-Voltage: 0CCA
    2015-07-18 17:48:35 SWAP SWAP_02 voltage: 3.274
    2015-07-18 17:48:35 SWAP SWAP_02 battery: low
    2015-07-18 17:48:35 SWAP SWAP_02 Level0_Voltage: 0.8314453125
    2015-07-18 17:48:35 SWAP SWAP_02 Level1_Voltage: 3.29677734375

    2015-07-18 17:49:06 SWAP SWAP_02 0C.0-Moisture_level_0: 0098
    2015-07-18 17:49:06 SWAP SWAP_02 0C.1-Moisture_level_1: 0000
    2015-07-18 17:49:06 SWAP SWAP_02 VWC_B: 122.47
    2015-07-18 17:49:06 SWAP SWAP_02 Level0_Voltage: 0.48984375
    2015-07-18 17:49:06 SWAP SWAP_02 Level1_Voltage: 0
    2015-07-18 17:49:06 SWAP SWAP_02 VWC_A: 1.46
    2015-07-18 17:49:06 SWAP SWAP_02 0B-Voltage: 0CCA
    2015-07-18 17:49:06 SWAP SWAP_02 voltage: 3.274
    2015-07-18 17:49:06 SWAP SWAP_02 battery: low
    2015-07-18 17:49:06 SWAP SWAP_02 Level0_Voltage: 0.48984375
    2015-07-18 17:49:06 SWAP SWAP_02 Level1_Voltage: 0

    2015-07-18 17:49:36 SWAP SWAP_02 0C.0-Moisture_level_0: 0097
    2015-07-18 17:49:36 SWAP SWAP_02 0C.1-Moisture_level_1: 0000
    2015-07-18 17:49:36 SWAP SWAP_02 VWC_B: -0.57
    2015-07-18 17:49:36 SWAP SWAP_02 Level0_Voltage: 0.48662109375
    2015-07-18 17:49:36 SWAP SWAP_02 Level1_Voltage: 0
    2015-07-18 17:49:36 SWAP SWAP_02 VWC_A: 1.43
    2015-07-18 17:49:36 SWAP SWAP_02 0B-Voltage: 0CCA
    2015-07-18 17:49:36 SWAP SWAP_02 voltage: 3.274
    2015-07-18 17:49:36 SWAP SWAP_02 battery: low
    2015-07-18 17:49:36 SWAP SWAP_02 Level0_Voltage: 0.48662109375
    2015-07-18 17:49:36 SWAP SWAP_02 Level1_Voltage: 0

    Im ersten Block passt noch alles.
    Im zweiten Block (17:48:35) sieht man das Level1_Voltage auf 3.29 V steht aber VWC_B noch auf -0.57%
    Um 17:49:06 sieht man das VWC_B dann auf 122.47 % steht obwohl Level1_Voltage wieder auf 0 ist.

    Hier das userreading dazu:
    Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)}, Level1_Voltage {hex(ReadingsVal($name,"0C.1-Moisture_level_1","0"))*(3.3/1024)}, VWC_A:0C.0-Moisture_level_0 {sprintf("%.2f",(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))}, VWC_B:0C.1-Moisture_level_1 {sprintf("%.2f",(11.6552 * (ReadingsVal($name,"Level1_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level1_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level1_Voltage","0"))**2 + 1))}, voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, battery:0B-Voltage {(ReadingsVal($name,"Level0_Voltage","0")<1?"low":"ok")}

    Ich hab auch schon versucht die userReadings in eine andere Reihenfolge zu bringen aber das hat auch nichts geändert.
    Der Wert für den ersten Sensor wird sofort richtig berechnet, nur der zweite hinkt eine Aktualisierung hinten nach.
    Ich hab noch 3 Screenshots angehängt in der Hoffnung das Bilder mehr sagen als meine 1000 Worte  :-[

    Eine kleine Zwischenfrage:
    "Abgleichen" kann ich die Sensoren nicht zufällig?

    Danke schonmal (wieder) für Eure Hilfe.

    Edith: Ich hab die userreadings mal rausgeworfen und die Berechnung in ein notify gepackt und nun klappt es auch mit dem zweiten Sensor.
    Zum "abgleichen" hat nicht zufällig noch jemand eine Idee?
    Ich muss mal schauen, beim ECMD gab es die Möglichkeit die Sensoren zu "justieren".
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 20 Juli 2015, 13:39:10
    Da bin ich ja froh, dass ich nicht der einzige Nutzer bin, der mit userReadings auf Kriegsfuß steht. Ich habe nur das Problem, dass der "Filter" oft nicht reagiert und somit das userReading gar nicht aktualisiert wird. Aber das nur am Rande ;-)

    Habe im Wiki sämtlichen Inhalt aus der Diskussionsseite jetzt in Artikel untergebracht. Teilweise sind Dinge trotzdem noch doppelt oder vielleicht nicht perfekt aufgeteilt. Irgendwann hab ich den Wald vor Bäumen nicht mehr gesehen.
    Die Benennung ist ganz schönes verwirrend, wenn man nicht im Thema ist. panStamp kann ja z.B. das FHEM-Modul, die Hardware oder die Firma sein. Wobei dann z.B. das Modul panStamp ja eigentlich zum panStick gehört etc. pp.
    Darum überlege, den Artikel "panStamp" doch noch einmal aufzuteilen ist "panStamp (Systemübersicht)" und "panStamp (Hardware)".
    Dann gehört der Artikel wieder ganz alleine dem Modul.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 20 Juli 2015, 13:52:17
    vielleicht wäre es besser gewesen wenn ich das fhem panstamp modul panstick ernannt hätte. andererseits würde es dann aber nicht zum panstamp shield passen. strenggenommen ist der stick an sich ohne aufgesteckten panstamp auch nicht besonders nützlich.

    wenn man die benennung einmal aufgedröselt hat passt es eigentlich.

    gruß
      andre

    ps: vielen dank für deinen wiki einsatz. 
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 21 Juli 2015, 21:17:48
    Mal eine andere Frage.
    Auf der Website von panStamp sind die ganzen AVR-PanStamp-Produkte nichtmehr erhältlich aber auch kein Verweis zu finden auf neue.
    Meine liebste Suchmaschine ist hier leider auch nicht wirklich hilfreich.
    Gibt es überhaupt noch welche zu kaufen?
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 21 Juli 2015, 21:19:42
    es wird ziemlich sicher wieder geben. im shop sind sie nur zu sehen wenn sie lieferbar sind.

    wenn du wissen willst wann wieder welche kommen frag am besten direkt daniel berenguer.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: Puschel74 am 21 Juli 2015, 21:37:00
    Danke dir Andre für die Antwort.

    Zitat von: justme1968 am 21 Juli 2015, 21:19:42
    es wird ziemlich sicher wieder geben. im shop sind sie nur zu sehen wenn sie lieferbar sind.
    Puh, dann bin ich beruhigt.
    Jetzt wo mir die Teile zu gefallen anfangen  8)

    Zitat von: justme1968 am 21 Juli 2015, 21:19:42
    wenn du wissen willst wann wieder welche kommen frag am besten direkt daniel berenguer.
    Öhm, ja. Wäre wohl der einfachere Weg gewesen wenn ich ersteres gewusst hätte  ;)
    Wobei auch da die direkte Nachfrage einfacher gewesen wäre  ::)
    Ich geb Bescheid wenn ich was weiß.
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 28 Juli 2015, 12:12:22
    Hallo zusammen,
    nachdem ich es nun endlich hinbekommen habe meine PanStamps zu programmieren stehe ich nun schon vor dem nächsten Problem.

    Ich habe einen RFXTRX in meinem FHEM laufen, welcher auch von FTDI stammt. Dieser wurde auch direkt selbstständig im System als ttyUSB0 angelegt, als ich diesen eingesteckt habe.

    Wenn ich nun meinen Panstamp mit dem ModemSketch in einen USB-Port einstecke, bleibt logischerweise bei einem "cat /proc/devices" die 188 stehen, jedoch erscheint keine weitere Nummer mit ttyUSB. Vielleicht ist das aber auch normal?!

    Nachdem ich nun meinen RFXTRX abgezogen habe, stand keine 188 mehr dort (nach einem neustart). Daraufhin habe ich "lsmod | grep  ftdi_sio" eingegeben und nichts zurückbekommen. Nachdem ich dann "modprobe ftdi_sio" eingegeben habe, erscheint auch die 188 wieder sauber. Daher habe ich das "ftdi_sio" in die /etc/modules geschrieben, sodass dieses Modul beim Systemstart mitgestartet wird.


    Nun aber zu meinem eigentlichen Problem:

    Es wird kein ttyUSBx-Device selbstständig angelegt, wenn ich das dann via "sudo mknod /dev/ttyUSB0 c 188 0" oder sudo "mknod /dev/ttyUSB1 c 188 0" (auch die entsprechenden Berechtigungen habe ich gesetzt) mache (der RFXTRX ist weiterhin abgezogen) sehe ich mittels "cat /proc/devices" auch ein entsprechendes Device. Wenn ich dieses nun in FHEM definiere, ist es jedoch disconnected - und nach einem neustart meines Cubies ist es komplett weg.


    Vielleicht hat ja jemand von euch noch eine Idee, vor allem auch wie ich meinen RFXTRX und den Panstick zusammen betreiben kann.


    Vielen Dank schonmal!
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Juli 2015, 12:18:45
    du hast zwei device files für das gleiche physikalische device angelegt. für das zweite device brauchst du:mknod /dev/ttyUSB1 c 188 1

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 28 Juli 2015, 13:11:16
    Zitat von: justme1968 am 28 Juli 2015, 12:18:45
    du hast zwei device files für das gleiche physikalische device angelegt. für das zweite device brauchst du:mknod /dev/ttyUSB1 c 188 1

    gruss
      andre

    Hallo Andre,
    das funktioniert leider auch nicht, sobald ich den Cubie neu starte, ist das Device ttyUSB1 wieder verschwunden :(. Auch wenn ich den PanStamp in hem anlege funktioniert dies nur auf ttyUSB0, dann laufen darauf der RFXTRX und der Panstamp und zeigen beide opened, daher gibt es offensichtlich Probleme mit dem PanStamp. Was komisch ist, ist folgendes: Wenn ich den RFXTRX vom Cubie abziehe und den Panstamp dranstecke, ist dieser, wie auch immer ich ihn anlege (als ttyUSB0 oder ttyUSB1) nach dem Neustadt verschwunden.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Juli 2015, 13:21:44
    geh die probleme nacheinander an. device file anlegen. mit 1 im namen und im mknod.

    im syslog oder mit dmesg schauen als welches device der panstick und der rfxtrx erkannt wird. es kann sein das der panstick 0 ist und der rfxtrx 1.

    wenn du diese Schwierigkeiten vermeiden willst nimm die device bis id files. 

    panstick in fhem anlegen. schauen ob alles geht.

    dann schauen warum das automatisch anlegen nicht geht.

    zur not steck das anlegen des device files einfach mit in das fhem start script.

    gruß
      andre
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 28 Juli 2015, 15:14:55
    So, die Inhalte sind jetzt alle von der Diskussionsseite in richtige Artikel gewandert. Unter der Kategorie panStamp ist alles zusammengefasst: http://www.fhemwiki.de/wiki/Kategorie:PanStamp

    Ich werde jetzt noch ein paar Schönheitskorrekturen vornehmen (Links innerhalb des Wiki und solche Kleinigkeiten) und sehe den Teil dann als fertig an. Ob wirklich alles 100%ig richtig ist, kann ich nicht durchgehend bewerten. :-)

    Grüße, Tobias
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 28 Juli 2015, 18:44:41
    Ich bin nun bis Donnerstag Abend unterwegs, dann werde ich mich aber direkt wieder dran machen, vielen Dank schon mal dafür.

    Damit ich dann gleich loslegen kann noch ein paar Fragen:

    Du schreibst:
    Zitatwenn du diese Schwierigkeiten vermeiden willst nimm die device bis id files.

    verstehe ich das richtig, dass ich wie folgt vorgehen müsste:

    1. Mittels "lsusb" den Bus und das Device raussuchen
    2. Mittels "lsusb -vs "003:006" die Detailinformationen des Gerätes raussuchen (idVendor, idProduct, iserial)
    3. Eine Datei, z.B. "/etc/udev/rules.d/20_FTDI.rules" erstellen und folgendes eintragen:
    "SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="ABC12345", SYMLINK+="ttyUSB_RFXTRX"
    "SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="ABC54321", SYMLINK+="ttyUSB_PanStick"
    4. "/etc/init.d/udev restart" ausführen


    und dann müsste ich ja noch den Panstamp mittels "define panStick panStamp /dev/ttyUSB_PanStickx@38400" anlegen.


    Oder habe ich da was komplett verhauen, dann würde ich mich über einen schubs in die richtige Richtung freuen :)


    Danke vielmals!
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Juli 2015, 19:17:52
    in /dev/serial/by-id werden je nach linux und kernel version automatisch device namen erzeugt ohne das du etwas in den udev regeln machen musst.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 28 Juli 2015, 21:00:09
    danke, dann werde ich das am Donnerstag / Freitag mal testen  :)
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 28 Juli 2015, 21:44:20
    Hallo justme1968

    Ich habe in der devices.xml einen mal einen Testeintrag für die ID20 ergänzt:
      <developer id="1" name="panStamp">
            ....
       <dev id="20" name="test" label="test"/>
      </developer>

    parallel habe ich eine test.xml unter dem Verzeichnis panStamp angelegt und bekomme aber immer folgende Fehlermeldung:
    could not read ./FHEM/lib/SWAP/panStamp/test.xml

    Ein Reboot brachte auch nichts.
    Wie kann man eigene Definitionen anlegen, ohne das die bei einem Update überschrieben werden ?

    Gruss Peter
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Juli 2015, 22:00:13
    dafür gibt es devices-local.xml

    stimmen die berechtigungen?

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 29 Juli 2015, 17:06:23
    Hallo justme1968

    Die Datei  devices-local.xml exisitiert im gleichen Pfad wie die Datei  devices.xml und besitzt 777er Rechte.

    Hast du noch eine Idee ?

    Gruss Peter
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 30 Juli 2015, 21:25:17
    Ich habe das Ganze nun mal so probiert, wie du gesagt hast, aber irgendwas scheint bei mir nicht zu passen :(.

    Wenn ich lsusb eingebe, sehe ich folgendes:
    Bus 003 Device 002: ID 0835:8500 Action Star Enterprise Co., Ltd
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 003 Device 003: ID 0835:8501 Action Star Enterprise Co., Ltd
    Bus 003 Device 004: ID 1b1f:c00f 
    Bus 003 Device 005: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
    Bus 003 Device 006: ID 0835:8500 Action Star Enterprise Co., Ltd
    Bus 003 Device 007: ID 0835:8502 Action Star Enterprise Co., Ltd
    Bus 003 Device 011: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
    Bus 003 Device 010: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub


    unter /dev/serial/by-id sehe ich jedoch nur folgendes:
    usb-RFXCOM_RFXtrx433_A1YU8SIO-if00-port0


    Auch beim dmesg sehe ich nur den RFXTRX.

    Hast noch irgendwer eine Idee, ich verzweifele nämlich so langsam :(

    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 30 Juli 2015, 22:11:10
    Kurzer Nachtrag:

    Ich habe nun mal den RFXTRX rausgezogen und nur den Panstamp reingesteckt. Dann erscheint im dmesg folgdendes:

    [   99.612423] usb 3-1.5.4: USB disconnect, device number 8
    [  118.024418] usb 3-1.5.4: new full-speed USB device number 9 using sw-ehci


    Es wird jedoch immer noch kein ttyUSB0 angezeigt, aber vielleicht kann damit ja jemand was anfangen
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 31 Juli 2015, 11:19:27
    Hallo justme1968

    Muss die Datei devices-local.xml noch irgendwo einzutragen, oder wird diese automatisch berücksichtigt?

    Gibt es irgendwo eine Doku ?

    Gruss Peter
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 31 Juli 2015, 22:56:28
    So, nun melde ich mich auch noch mal zu Wort, nachdem der PanStamp nun erkannt wird  :), ich hoffe, dass ich das hier richtig poste.

    Ich habe nun auf einen Panstamp, der auf einem BatteryBoard sitzt den Soilmoisture-Sketch gepackt, soweit wird auch alles erkannt.

    Dann habe ich aus dem Wiki
    Zitathttp://www.fhemwiki.de/wiki/SWAP
    die Umrechnungsformel für die Bodenfeuchte genommen, jedoch bekomme ich nun, wenn ich den Vegetronix vh400 Sensor in ein Glas mit Wasser packe eine Feuchte von 50% angezeigt.
    Kann es nun sein, dass beim anpassen des Pansticks doch etwas schief gegangen ist, oder ist das bei euch genauso, bzw. habt ihr ggf. eine andere Formel genommen?
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 02 August 2015, 11:11:12
    Die Datei devices-local.xml wird bei mir nicht berücksichtigt ?!

    Deshalb habe ich die die temp.xml (Dev-ID:1; Prod-ID:4) wie folgt geändert, um meine Übertragungen zu testen:


    <?xml version="1.0"?>
    <device>
      <developer>panStamp</developer>
      <product>Own sensor</product>
      <pwrdownmode>true</pwrdownmode>
      <regular>
        <reg name="Voltage supply" id="11">
          <endpoint name="Voltage" type="num" dir="inp">
            <size>2</size>
            <units>
              <unit name="C" factor="0.001" offset="0"/>
            </units>
          </endpoint>
        </reg>
        <reg name="Temperature" id="12">
          <endpoint name="Temp" type="num" dir="inp">
            <size>2</size>
            <units>
              <unit name="C" factor="0.1" offset="-50"/>
              <unit name="F" factor="0.18" offset="-58"/>
              <unit name="K" factor="0.1" offset="223.15"/>
            </units>
          </endpoint>
        </reg>
        <reg name="Input" id="13">
          <endpoint name="Input" type="num" dir="inp">
            <size>1</size>
          </endpoint>
        </reg>
        <reg name="Output" id="14">
          <endpoint name="Output" type="num" dir="out">
            <size>1</size>
          </endpoint>
        </reg>
      </regular>
    </device>


    Leider wird der Output nicht in den readings angezeigt.
    Der regListAll liefert folgendes Ergebnis:
    reg.   | pos   | size   | dir.   | name
    00   |    | 8   |    |ProductCode
      .1   |   0   |   4   |
      .2   |   4   |   4   |
    01   |    |    |    |HardwareVersion
    02   |    |    |    |FirmwareVersion
    03   |    |    |    |SystemState
    04   |    |    |    |FrequencyChannel
    05   |    |    |    |SecurityOption
    06   |    |    |    |SecurityPassword
    07   |    |    |    |SecurityNonce
    08   |    |    |    |NetworkID
    09   |    | 1   | set   |DeviceAddress
    0A   |    | 2   | set   |PeriodicTxInterval
    0B   |    | 2   | get   |Voltage
    0C   |    | 2   | get   |Temp
    0D   |    | 1   | get   |Input
    0E   |    | 1   | set   |Output

    Was mache ich noch falsch ? Das device regdriver wurde analog definiert.

    Gruss Peter
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 06 August 2015, 12:06:35
    Hat jemand einen Plan, wie man den neuen panStamp AVR2 auf die alten Boards bekommt?
    http://www.panstamp.com/product/panstamp-avr/
    Titel: Antw:panStamp support
    Beitrag von: dev0 am 06 August 2015, 15:49:10
    Es sind Adapterplatinen angekündigt: http://www.panstamp.com/news/panstamp-2-0-new-format/
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 06 August 2015, 17:48:20
    Hmpf,  der Chef seh schon. Das dauert doch noch länger mit meinem weiteren Ausbau.
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 11 August 2015, 09:56:42
    Hi

    Kannn mir jemand mit der devices-local.xml weiterhelfen ?
    Warum wir diese nicht gezogen ?

    Gruss

    Peter
    Titel: Antw:panStamp support
    Beitrag von: PeterS am 11 August 2015, 10:19:10
    Hi Zusammen

    Ok, die devices-local.xml wurde gezogen, allerdings hatte ich die SWAP_MANUFACT_ID/SWAP_PRODUCT_ID nicht hex codiert :-(

    Gruss Peter
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 11 August 2015, 10:22:42
    Zitat von: PeterS am 11 August 2015, 09:56:42
    Hi

    Kannn mir jemand mit der devices-local.xml weiterhelfen ?
    Warum wir diese nicht gezogen ?

    Gruss

    Peter

    Aktuell ist dein FHEM schon, oder?

    Ich benutze die devices-loca.xml selber und es funktioniert.
    \fhem\FHEM\lib\SWAP\devices-local.xml

    <?xml version="1.0"?>
    <devices>
      <developer id="67" name="TeeVau">
        <dev id="2" name="OneWireTemp" label="Read up to 8 DSxxxx Temp. sensors"/>
        <dev id="3" name="analogLogger" label="Read up to 8 analog inputs"/>
        <dev id="4" name="aquaControl" label="See whats up with the fishs"/>
      </developer>
    </devices>


    Und ein Beispiel:
    \fhem\FHEM\lib\SWAP\TeeVau\analogLogger.xml

    <?xml version="1.0"?>
    <device>
      <developer>TeeVau</developer>
      <product>analogLogger</product>
      <pwrdownmode>false</pwrdownmode>
      <regular>
        <reg name="Voltage supply" id="11">
          <endpoint name="Voltage" type="num" dir="inp">
            <size>2</size>
            <units>
              <unit name="V" factor="0.001" offset="0"/>
            </units>
          </endpoint>
        </reg>
        <reg name="ADC Input" id="12">
          <endpoint name="ADC Input 0" type="num" dir="inp">
            <position>0</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 1" type="num" dir="inp">
            <position>2</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 2" type="num" dir="inp">
            <position>4</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 3" type="num" dir="inp">
            <position>6</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 4" type="num" dir="inp">
            <position>8</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 5" type="num" dir="inp">
            <position>10</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 6" type="num" dir="inp">
            <position>12</position>
            <size>2</size>
          </endpoint>
          <endpoint name="ADC Input 7" type="num" dir="inp">
            <position>14</position>
            <size>2</size>
          </endpoint>
        </reg>
      </regular>
    </device>
    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 26 August 2015, 18:22:39
    Hat eigentlich irgendwer von euch einen lauffähigen temphum(press) sketch, der sich kompilieren und hochladen lässt?

    Bei allem was ich gefunden habe, meckert Arduino beim kompilieren :-/
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 22 September 2015, 10:04:08
    Daniel hat mir im Forum geantwortet, dass es bereits Adapter gibt von AVR2 zu dem Format des AVR1. Die Dinger gibt es nur nicht im Store, man soll ihn anschrieben.
    Das Layout zu dem Adapter gibt es unter https://github.com/panStamp/kicad/tree/master/dipadapter-avr

    Vielleicht hilft es dem ein oder anderem hier. Gerade für bereits erstellte Boards!
    Tobias
    Titel: Antw:panStamp support
    Beitrag von: TeeVau am 23 September 2015, 19:29:44
    Möchte sich jemand relativ kurzfristig an einer Bestellung bei panstamp beteiligen?
    Brauche ein paar Module. Versandkosten Spanien Deutschland werden geteilt. Die Versandkosten von mir zum Besteller trägt der jeweilige selber plus etwas für Verpackung.
    Spätestens Montag werde ich bestellen.

    Tobias

    Bei Interesse bitte nur per pm.
    Titel: Antw:panStamp support
    Beitrag von: locutus am 25 Oktober 2015, 00:12:50
    Hallo zusammen,

    ich habe für den panStamp AVR2 (https://github.com/panStamp/panstamp/wiki/panStamp-AVR-2.-Technical-details) ein Lithium Battery Charging Board entwickelt und biete die bestückte Platine (ohne panStamp AVR2) im Marktplatz (http://forum.fhem.de/index.php?topic=42886.0) an.
    Die Schaltung besteht aus einem Laderegler für ein 3,7V Lithium Akku und einem 3,3V Spannungsregler zur Versorgung des panStamps. Als Ladegerät bietet sich nahezu jede +5V Spannungsquelle mit Mini-USB-Stecker an. Alternativ sind auf dem Board Lötaugen für eine +5V Spannungsquelle vorhanden.
    Die Rückseite der Platine kann nach Bedarf mit zwei 4,7k Pull-Up Widerständen (Bauform 0805), einem 100nF Kondensator (Bauform 0805) und einer Reihe von I2C-Bus-Sensoren bestückt werden:
    BPM180 - barometrischer Luftdrucksensor
    TSL2561 - digitaler Lichtsensor
    HTU21D oder SHT21 - Temperatur- und Luftfeuchtesensor

    Außerdem ist ein Lötanschluss für eine SMA-Antennenbuchse vorhanden.
    Programmiert wird der panStamp AVR 2 über die 6-polige Buchsenleiste.
    Die Platine passt in das TEKO 10014 (http://www.reichelt.de/TEKO-10014/3/index.html?&ACTION=3&LA=446&ARTICLE=34083&artnr=TEKO+10014&SEARCH=teko+10014) ABS-Kunststoffgehäuse von Reichelt Elektronik.

    Ausstattung:
    TP4057 Lithium Battery Cell Charging IC - 100 mA Ladestrom
    MCP1802 Spannungsregler 3V / 300 mA - 35 µA Ruhestrohm
    LED für Ladestatus
    JST-Buchse für 3,7V Lithium-Akkumulator
    UART Interface für USB zu TTL Konverter mit 3,3V Signalpegel
    Lötanschluss für SMA-Antennenbuchse (PCB Edge Mount Solder 1,2 mm)
    Mini-USB-Buchse Typ B, 5-polig – Anschluss für Ladegerät
    Lötanschluss für alternative +5V Ladespannungsquelle
    Lötaugen im 2,54 mm Raster
    Lötanschluss für I2C-Bus-Sensoren: BMP180, TSL2561, HTU21D oder SHT21
    Platinenmaße (ohne Bauteile) LxBxH: 41,2 x 42 x 1,2 mm

    Im Anhang Gerberdaten für ITEAD Studio (https://www.itead.cc/open-pcb/pcb-prototyping.html) und Schaltplan für die, die selbst löten möchten.
    Die Verwendung der Daten für kommerzielle Zwecke, Herstellung oder gewerblichen Vertrieb ist untersagt.
    Titel: Antw:panStamp support
    Beitrag von: PeMue am 25 Oktober 2015, 06:52:58
    Coole Sache, wenn ich einen Panstamp 2 hätte, würde ich sofort bestellen, aber ich muss erst mal meine Panstamp 1 "verarbeiten".

    Gruß PeMue
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 26 Oktober 2015, 07:52:12
    Moin,

    sagt mal ich hab hier ein Problem mit einem AVR panStamp der auf dem Battery Board mit einem DHT22 bestückt ist.
    Es kommt ab und an vor, dass die Temperatur und Luftfeuchtigkeit steht wie eine 1. Übertragen werden die Daten weiterhin periodisch aber sie sind immer gleich. Kennt das einer? Ein Reset hilft...

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 26 Oktober 2015, 15:28:17
    Hallo,

    über 2 Stunden hat meiner auch schon mal die gleichen Werte - immer Nachts, wenn sich nichts bewegt. Wenn kein Durchzug ist und keine Türen auf und zu gemacht werden, kann das doch auch plausibel sein.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 26 Oktober 2015, 15:30:59
    Naja, also das ist schon sehr unwahrscheinlich, oder wohnst du in einer Höhle 400 Meter unter der Erde? Und vor allem nicht über mehrere Tage hinweg.

    /Daniel

    Titel: Antw:panStamp support
    Beitrag von: dennis87 am 26 Oktober 2015, 19:25:30
    Vielleicht hat hier ja noch jemand eine Antwort auf meine Frage :).

    Kann mir jemand sagen, welches Kabel ich verwenden muss/soll, wenn ich das Kabel eines Vegetronix Bodenfeuchtesensor an einem Panstamp Batteryboard verlängern möchte (5m verlängern)? Muss ich dabei irgendwas besonderes beachten, sodass die Werte nicht verfälscht werden?
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 26 Oktober 2015, 19:39:46
    Hallo,

    ich würde nirmale Kupferleitung nehmen. Ich habe zwei Sensoren bestellt - einmal mit 2 und einmal mit 5 Metern. An den Sensoren konnte ich keine Unterschiede sehen - ich kann mir auch nicht vorstellen, das Vegatronix jeden Sensor einzelnd "eicht". Von daher gibt es zwischen den Sensoren ohnehin eine Streuung.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 26 Oktober 2015, 20:30:48
    Nope, der gibt doch nur eine Spannung aus. Da fließt ja kein Strom, ist also von daher unkritisch. Nun nicht irgend eine dünne Litze nehmen und dann 10 Meter Kabel dran. Abstimmen tust du das ja dann eh über FHEM oder wie auch immer. Also den 0 und 100% Abgleich.

    Also wenn du ein 0,6er Querschnitt nimmst passt das schon.

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 15:13:56
    Hallo
    Ich versuch wieder mal meine panstamps zu Beschreiben  :'(

    Also aus Ausgangslage habe ich jetzt: panStamp AVR, Arduino IDE 1.6, neue SWAP Lib und den soilmoisture sketch.
    Wenn ich auf Verify drücke bekomme ich folgende Meldung:No SLEEP mode defined for this device
    Wo stell ich SLEEP mode ein?

    Gruß Markus

    Arduino: 1.6.6 (Windows 8.1), Board: "panStamp AVR 1 w/ atmega328p"

    Warning: platform.txt from core 'panStamp AVR Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
    Warning: platform.txt from core 'panStamp MSP430 boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
    Warning: platform.txt from core 'panStamp MSP430 boards' contains deprecated recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm, automatically converted to recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} -o "{build.path}/{build.project_name}.elf" {object_files} "{archive_file_path}" "-L{build.path}" -lm. Consider upgrading this core.
    WARNING: Category '' in library EEPROM is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library SPI is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library SoftwareSerial is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library Wire is not valid. Setting to 'Uncategorized'
    Build options changed, rebuilding all
    In file included from C:\Program Files (x86)\Arduino\libraries\panstamp\panstamp.h:38:0,

                     from C:\Program Files (x86)\Arduino\libraries\panstamp\panstamp.cpp:27:

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\sleep.h:634:6: error: #error "No SLEEP mode defined for this device."

         #error "No SLEEP mode defined for this device."

          ^

    exit status 1
    Error compiling.

      This report would have more information with
      "Show verbose output during compilation"
      enabled in File > Preferences.
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 17:31:32
    Hallo,

    wenn Du einen Panstamp AVR1 hast und auch den Sketch dazu nimmst, solltest Du die IDE 1.0.5 nutzen. In der 1.6.6 ist einiges umgestellt worden, so das die "alten" Sketche sich zum Teil nicht mehr compilieren lassen.
    Zu Deinem Sleep - normalerweise steht im Bereich "loop" nach dem Senden so etwas wie "panstamp_goto_sleep". Damit wird der Panstamp schlafengelegt um Batterie zu sparen. So wie ich den Fehler lese, findet der Compiler das nicht in der sleep.h und meckert deshalb rum. Das panstamp-goto-sleep war eine eigene Funktion, die auf dem WDT (Watchdogtimer) aufsetzte und nicht zur Standartbibliothek gehörte. Die angesprochene sleep.h ist soweit ich weiß aber eine dieser standart Bibliotheken.
    Ich habe diesen Sketch (von der Panstampseite) letztens (vor 4 Monaten) mit der 1.0.5 auf einen Panstamp gespielt - das lief problemlos.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 18:45:52
    Danke

    die Datei sleep scheint ja da zu sein aber leider nicht definiert...

    c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\sleep.h:634:6:

    ich hab es schon mit 1.0 und auch mit 1.6 versucht aber weil ich oben gesehen habe das es Puschel74 mit 1.6 geschafft hat hatte ich Hoffnung geschöpft ;-)

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 19:25:06
    Hallo,

    was steht denn in der sleep.h drin ? Die kann man mit Wordpad öffnen.

    Gruß Christoph

    PS - ich habe mal den Sketch anghängt, der bei mir mit 1.0.5 läuft-
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 19:38:40
    hier die datei..

    sleep.h
    /* Copyright (c) 2002, 2004 Theodore A. Roth
       Copyright (c) 2004, 2007, 2008 Eric B. Weddington
       Copyright (c) 2005, 2006, 2007 Joerg Wunsch
       All rights reserved.

       Redistribution and use in source and binary forms, with or without
       modification, are permitted provided that the following conditions are met:

       * Redistributions of source code must retain the above copyright
         notice, this list of conditions and the following disclaimer.

       * Redistributions in binary form must reproduce the above copyright
         notice, this list of conditions and the following disclaimer in
         the documentation and/or other materials provided with the
         distribution.

       * Neither the name of the copyright holders nor the names of
         contributors may be used to endorse or promote products derived
         from this software without specific prior written permission.

       THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
       AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
       IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
       ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
       LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
       CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
       SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
       INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
       CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
       ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
       POSSIBILITY OF SUCH DAMAGE. */

    /* $Id$ */

    #ifndef _AVR_SLEEP_H_
    #define _AVR_SLEEP_H_ 1

    #include <avr/io.h>
    #include <stdint.h>


    /** \file */

    /** \defgroup avr_sleep <avr/sleep.h>: Power Management and Sleep Modes

        \code #include <avr/sleep.h>\endcode

        Use of the \c SLEEP instruction can allow an application to reduce its
        power comsumption considerably. AVR devices can be put into different
        sleep modes. Refer to the datasheet for the details relating to the device
        you are using.

        There are several macros provided in this header file to actually
        put the device into sleep mode.  The simplest way is to optionally
        set the desired sleep mode using \c set_sleep_mode() (it usually
        defaults to idle mode where the CPU is put on sleep but all
        peripheral clocks are still running), and then call
        \c sleep_mode(). This macro automatically sets the sleep enable bit, goes
        to sleep, and clears the sleep enable bit.
       
        Example:
        \code
        #include <avr/sleep.h>

        ...
          set_sleep_mode(<mode>);
          sleep_mode();
        \endcode
       
        Note that unless your purpose is to completely lock the CPU (until a
        hardware reset), interrupts need to be enabled before going to sleep.

        As the \c sleep_mode() macro might cause race conditions in some
        situations, the individual steps of manipulating the sleep enable
        (SE) bit, and actually issuing the \c SLEEP instruction, are provided
        in the macros \c sleep_enable(), \c sleep_disable(), and
        \c sleep_cpu().  This also allows for test-and-sleep scenarios that
        take care of not missing the interrupt that will awake the device
        from sleep.

        Example:
        \code
        #include <avr/interrupt.h>
        #include <avr/sleep.h>

        ...
          set_sleep_mode(<mode>);
          cli();
          if (some_condition)
          {
            sleep_enable();
            sei();
            sleep_cpu();
            sleep_disable();
          }
          sei();
        \endcode

        This sequence ensures an atomic test of \c some_condition with
        interrupts being disabled.  If the condition is met, sleep mode
        will be prepared, and the \c SLEEP instruction will be scheduled
        immediately after an \c SEI instruction.  As the intruction right
        after the \c SEI is guaranteed to be executed before an interrupt
        could trigger, it is sure the device will really be put to sleep.

        Some devices have the ability to disable the Brown Out Detector (BOD) before
        going to sleep. This will also reduce power while sleeping. If the
        specific AVR device has this ability then an additional macro is defined:
        \c sleep_bod_disable(). This macro generates inlined assembly code
        that will correctly implement the timed sequence for disabling the BOD
        before sleeping. However, there is a limited number of cycles after the
        BOD has been disabled that the device can be put into sleep mode, otherwise
        the BOD will not truly be disabled. Recommended practice is to disable
        the BOD (\c sleep_bod_disable()), set the interrupts (\c sei()), and then
        put the device to sleep (\c sleep_cpu()), like so:

        \code
        #include <avr/interrupt.h>
        #include <avr/sleep.h>

        ...
          set_sleep_mode(<mode>);
          cli();
          if (some_condition)
          {
            sleep_enable();
            sleep_bod_disable();
            sei();
            sleep_cpu();
            sleep_disable();
          }
          sei();
        \endcode
    */


    /* Define an internal sleep control register and an internal sleep enable bit mask. */
    #if defined(SLEEP_CTRL)

        /* XMEGA devices */
        #define _SLEEP_CONTROL_REG  SLEEP_CTRL
        #define _SLEEP_ENABLE_MASK  SLEEP_SEN_bm

    #elif defined(SMCR)

        #define _SLEEP_CONTROL_REG  SMCR
        #define _SLEEP_ENABLE_MASK  _BV(SE)

    #elif defined(__AVR_AT94K__)

        #define _SLEEP_CONTROL_REG  MCUR
        #define _SLEEP_ENABLE_MASK  _BV(SE)

    #else

        #define _SLEEP_CONTROL_REG  MCUCR
        #define _SLEEP_ENABLE_MASK  _BV(SE)

    #endif


    /* Define set_sleep_mode() and sleep mode values per device. */
    #if defined(__AVR_ATmega161__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_PWR_DOWN     1
        #define SLEEP_MODE_PWR_SAVE     2

        #define set_sleep_mode(mode) \
        do { \
            MCUCR = ((MCUCR & ~_BV(SM1)) | ((mode) == SLEEP_MODE_PWR_DOWN || (mode) == SLEEP_MODE_PWR_SAVE ? _BV(SM1) : 0)); \
            EMCUCR = ((EMCUCR & ~_BV(SM0)) | ((mode) == SLEEP_MODE_PWR_SAVE ? _BV(SM0) : 0)); \
        } while(0)


    #elif defined(__AVR_ATmega162__) \
    || defined(__AVR_ATmega8515__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_PWR_DOWN     1
        #define SLEEP_MODE_PWR_SAVE     2
        #define SLEEP_MODE_ADC          3
        #define SLEEP_MODE_STANDBY      4
        #define SLEEP_MODE_EXT_STANDBY  5

        #define set_sleep_mode(mode) \
        do { \
            MCUCR = ((MCUCR & ~_BV(SM1)) | ((mode) == SLEEP_MODE_IDLE ? 0 : _BV(SM1))); \
            MCUCSR = ((MCUCSR & ~_BV(SM2)) | ((mode) == SLEEP_MODE_STANDBY  || (mode) == SLEEP_MODE_EXT_STANDBY ? _BV(SM2) : 0)); \
            EMCUCR = ((EMCUCR & ~_BV(SM0)) | ((mode) == SLEEP_MODE_PWR_SAVE || (mode) == SLEEP_MODE_EXT_STANDBY ? _BV(SM0) : 0)); \
        } while(0)

    #elif defined(__AVR_AT90S2313__) \
    || defined(__AVR_AT90S2323__) \
    || defined(__AVR_AT90S2333__) \
    || defined(__AVR_AT90S2343__) \
    || defined(__AVR_AT43USB320__) \
    || defined(__AVR_AT43USB355__) \
    || defined(__AVR_AT90S4414__) \
    || defined(__AVR_AT90S4433__) \
    || defined(__AVR_AT90S8515__) \
    || defined(__AVR_ATtiny22__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_PWR_DOWN     _BV(SM)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~_BV(SM)) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATA6616C__) \
    || defined(__AVR_ATA6617C__) \
    || defined(__AVR_ATA664251__) \
    || defined(__AVR_ATtiny167__) \
    || defined(__AVR_ATtiny87__) \
    || defined(__AVR_ATtiny441__) \
    || defined(__AVR_ATtiny828__) \
    || defined(__AVR_ATtiny841__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1))) | (mode)); \
        } while(0)

    #elif defined(__AVR_AT90S4434__) \
    || defined(__AVR_ATA5505__) \
    || defined(__AVR_ATA5272__) \
    || defined(__AVR_AT76C711__) \
    || defined(__AVR_AT90S8535__) \
    || defined(__AVR_ATmega103__) \
    || defined(__AVR_ATmega161__) \
    || defined(__AVR_ATmega163__) \
    || defined(__AVR_ATmega16HVB__) \
    || defined(__AVR_ATmega16HVBREVB__) \
    || defined(__AVR_ATmega32HVB__) \
    || defined(__AVR_ATmega32HVBREVB__) \
    || defined(__AVR_ATtiny13__) \
    || defined(__AVR_ATtiny13A__) \
    || defined(__AVR_ATtiny15__) \
    || defined(__AVR_ATtiny24__) \
    || defined(__AVR_ATtiny24A__) \
    || defined(__AVR_ATtiny44__) \
    || defined(__AVR_ATtiny44A__) \
    || defined(__AVR_ATtiny84__) \
    || defined(__AVR_ATtiny84A__) \
    || defined(__AVR_ATtiny25__) \
    || defined(__AVR_ATtiny45__) \
    || defined(__AVR_ATtiny48__) \
    || defined(__AVR_ATtiny85__) \
    || defined(__AVR_ATtiny88__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATmega16HVA__) \
    || defined(__AVR_ATmega8HVA__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_PWR_OFF      _BV(SM2)


        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATmega406__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_PWR_OFF      _BV(SM2)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATtiny2313__) \
    || defined(__AVR_ATtiny2313A__) \
    || defined(__AVR_ATtiny4313__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_PWR_DOWN     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_STANDBY      _BV(SM1)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1))) | (mode)); \
        } while(0)

    #elif defined(__AVR_AT94K__) \
    || defined(__AVR_ATmega64HVE__) \
    || defined(__AVR_ATmega64HVE2__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATtiny26__) \
    || defined(__AVR_ATtiny261__) \
    || defined(__AVR_ATtiny261A__) \
    || defined(__AVR_ATtiny461__) \
    || defined(__AVR_ATtiny461A__) \
    || defined(__AVR_ATtiny861__) \
    || defined(__AVR_ATtiny861A__) \
    || defined(__AVR_ATtiny43U__) \
    || defined(__AVR_ATtiny1634__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_STANDBY      (_BV(SM0) | _BV(SM1))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1))) | (mode)); \
        } while(0)

    #elif defined(__AVR_AT90PWM216__) \
    || defined(__AVR_AT90PWM316__) \
    || defined(__AVR_AT90PWM161__) \
    || defined(__AVR_AT90PWM81__) \
    || defined(__AVR_AT90PWM1__) \
    || defined(__AVR_AT90PWM2__) \
    || defined(__AVR_AT90PWM2B__) \
    || defined(__AVR_AT90PWM3__) \
    || defined(__AVR_AT90PWM3B__) \
    || defined(__AVR_ATmega32M1__) \
    || defined(__AVR_ATmega16M1__) \
    || defined(__AVR_ATmega64M1__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_STANDBY      (_BV(SM1) | _BV(SM2))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_AT90USB1286__) \
    || defined(__AVR_AT90USB1287__) \
    || defined(__AVR_AT90USB646__) \
    || defined(__AVR_AT90USB647__) \
    || defined(__AVR_ATA6614Q__) \
    || defined(__AVR_ATmega128__) \
    || defined(__AVR_ATmega128A__) \
    || defined(__AVR_ATmega1280__) \
    || defined(__AVR_ATmega1281__) \
    || defined(__AVR_ATmega1284__) \
    || defined(__AVR_ATmega1284P__) \
    || defined(__AVR_ATmega128RFA1__) \
    || defined(__AVR_ATmega128RFR2__) \
    || defined(__AVR_ATmega1284RFR2__) \
    || defined(__AVR_ATmega16__) \
    || defined(__AVR_ATmega16A__) \
    || defined(__AVR_ATmega162__) \
    || defined(__AVR_ATmega164A__) \
    || defined(__AVR_ATmega164P__) \
    || defined(__AVR_ATmega164PA__) \
    || defined(__AVR_ATmega168A__) \
    || defined(__AVR_ATmega168P__) \
    || defined(__AVR_ATmega168PA__) \
    || defined(__AVR_ATmega168PB__) \
    || defined(__AVR_ATmega16HVA2__) \
    || defined(__AVR_ATmega16U4__) \
    || defined(__AVR_ATmega2560__) \
    || defined(__AVR_ATmega2561__) \
    || defined(__AVR_ATmega256RFR2__) \
    || defined(__AVR_ATmega2564RFR2__) \
    || defined(__AVR_ATmega32__) \
    || defined(__AVR_ATmega32A__) \
    || defined(__AVR_ATmega323__) \
    || defined(__AVR_ATmega324A__) \
    || defined(__AVR_ATmega324P__) \
    || defined(__AVR_ATmega324PA__) \
    || defined(__AVR_ATmega328__) \
    || defined(__AVR_ATmega328P__) \
    || defined(__AVR_ATmega32C1__) \
    || defined(__AVR_ATmega32U4__) \
    || defined(__AVR_ATmega32U6__) \
    || defined(__AVR_ATmega48A__) \
    || defined(__AVR_ATmega48PA__) \
    || defined(__AVR_ATmega48PB__) \
    || defined(__AVR_ATmega48P__) \
    || defined(__AVR_ATmega64__) \
    || defined(__AVR_ATmega64A__) \
    || defined(__AVR_ATmega640__) \
    || defined(__AVR_ATmega644__) \
    || defined(__AVR_ATmega644A__) \
    || defined(__AVR_ATmega644P__) \
    || defined(__AVR_ATmega644PA__) \
    || defined(__AVR_ATmega64C1__) \
    || defined(__AVR_ATmega64RFR2__) \
    || defined(__AVR_ATmega644RFR2__) \
    || defined(__AVR_ATmega8515__) \
    || defined(__AVR_ATmega8535__) \
    || defined(__AVR_ATmega88A__) \
    || defined(__AVR_ATmega88P__) \
    || defined(__AVR_ATmega88PA__) \
    || defined(__AVR_ATmega88PB__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_STANDBY      (_BV(SM1) | _BV(SM2))
        #define SLEEP_MODE_EXT_STANDBY  (_BV(SM0) | _BV(SM1) | _BV(SM2))


        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATmega8A__) \
    || defined(__AVR_ATmega8__) \
    || defined(__AVR_ATmega6450A__) \
    || defined(__AVR_ATmega6450P__) \
    || defined(__AVR_ATmega645A__) \
    || defined(__AVR_ATmega645P__) \
    || defined(__AVR_ATmega3250A__) \
    || defined(__AVR_ATmega3250PA__) \
    || defined(__AVR_ATmega325A__) \
    || defined(__AVR_ATmega325PA__) \
    || defined(__AVR_ATmega165A__) \
    || defined(__AVR_ATmega165P__) \
    || defined(__AVR_ATmega165PA__) \
    || defined(__AVR_ATmega169A__) \
    || defined(__AVR_ATmega169P__) \
    || defined(__AVR_ATmega169PA__) \
    || defined(__AVR_ATmega329A__) \
    || defined(__AVR_ATmega329PA__) \
    || defined(__AVR_ATmega3290A__) \
    || defined(__AVR_ATmega3290PA__) \
    || defined(__AVR_ATmega649A__) \
    || defined(__AVR_ATmega649P__) \
    || defined(__AVR_ATmega6490A__) \
    || defined(__AVR_ATmega6490P__) \
    || defined(__AVR_ATmega165__) \
    || defined(__AVR_ATmega169__) \
    || defined(__AVR_ATmega48__) \
    || defined(__AVR_ATmega88__) \
    || defined(__AVR_ATmega168__) \
    || defined(__AVR_ATmega325P__) \
    || defined(__AVR_ATmega3250P__) \
    || defined(__AVR_ATmega325__) \
    || defined(__AVR_ATmega3250__) \
    || defined(__AVR_ATmega645__) \
    || defined(__AVR_ATmega6450__) \
    || defined(__AVR_ATmega329__) \
    || defined(__AVR_ATmega329P__) \
    || defined(__AVR_ATmega3290__) \
    || defined(__AVR_ATmega3290P__) \
    || defined(__AVR_ATmega649__) \
    || defined(__AVR_ATmega6490__) \
    || defined(__AVR_AT90CAN128__) \
    || defined(__AVR_AT90CAN32__) \
    || defined(__AVR_AT90CAN64__) \
    || defined(__AVR_ATA6612C__) \
    || defined(__AVR_ATA6613C__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_STANDBY      (_BV(SM1) | _BV(SM2))


        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATxmega16A4__) \
    || defined(__AVR_ATxmega16A4U__) \
    || defined(__AVR_ATxmega16C4__) \
    || defined(__AVR_ATxmega16D4__) \
    || defined(__AVR_ATxmega32A4__) \
    || defined(__AVR_ATxmega32A4U__) \
    || defined(__AVR_ATxmega32C3__) \
    || defined(__AVR_ATxmega32C4__) \
    || defined(__AVR_ATxmega32D3__) \
    || defined(__AVR_ATxmega32D4__) \
    || defined(__AVR_ATxmega8E5__) \
    || defined(__AVR_ATxmega16E5__) \
    || defined(__AVR_ATxmega32E5__) \
    || defined(__AVR_ATxmega64A1__) \
    || defined(__AVR_ATxmega64A1U__) \
    || defined(__AVR_ATxmega64A3__) \
    || defined(__AVR_ATxmega64A3U__) \
    || defined(__AVR_ATxmega64A4U__) \
    || defined(__AVR_ATxmega64B1__) \
    || defined(__AVR_ATxmega64B3__) \
    || defined(__AVR_ATxmega64C3__) \
    || defined(__AVR_ATxmega64D3__) \
    || defined(__AVR_ATxmega64D4__) \
    || defined(__AVR_ATxmega128A1__) \
    || defined(__AVR_ATxmega128A1U__) \
    || defined(__AVR_ATxmega128A3__) \
    || defined(__AVR_ATxmega128A3U__) \
    || defined(__AVR_ATxmega128A4U__) \
    || defined(__AVR_ATxmega128B1__) \
    || defined(__AVR_ATxmega128B3__) \
    || defined(__AVR_ATxmega128C3__) \
    || defined(__AVR_ATxmega128D3__) \
    || defined(__AVR_ATxmega128D4__) \
    || defined(__AVR_ATxmega192A3__) \
    || defined(__AVR_ATxmega192A3U__) \
    || defined(__AVR_ATxmega192C3__) \
    || defined(__AVR_ATxmega192D3__) \
    || defined(__AVR_ATxmega256A3__) \
    || defined(__AVR_ATxmega256A3U__) \
    || defined(__AVR_ATxmega256C3__) \
    || defined(__AVR_ATxmega256D3__) \
    || defined(__AVR_ATxmega256A3B__) \
    || defined(__AVR_ATxmega256A3BU__) \
    || defined(__AVR_ATxmega384C3__) \
    || defined(__AVR_ATxmega384D3__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_PWR_DOWN     (SLEEP_SMODE1_bm)
        #define SLEEP_MODE_PWR_SAVE     (SLEEP_SMODE1_bm | SLEEP_SMODE0_bm)
        #define SLEEP_MODE_STANDBY      (SLEEP_SMODE2_bm | SLEEP_SMODE1_bm)
        #define SLEEP_MODE_EXT_STANDBY  (SLEEP_SMODE2_bm | SLEEP_SMODE1_bm | SLEEP_SMODE0_bm)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(SLEEP_SMODE2_bm | SLEEP_SMODE1_bm | SLEEP_SMODE0_bm)) | (mode)); \
        } while(0)

    #elif defined(__AVR_AT90SCR100__) \
    || defined(__AVR_ATmega8U2__) \
    || defined(__AVR_ATmega16U2__) \
    || defined(__AVR_ATmega32U2__) \
    || defined(__AVR_AT90USB162__) \
    || defined(__AVR_AT90USB82__)

        #define SLEEP_MODE_IDLE         (0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_PWR_SAVE     (_BV(SM0) | _BV(SM1))
        #define SLEEP_MODE_STANDBY      (_BV(SM1) | _BV(SM2))
        #define SLEEP_MODE_EXT_STANDBY  (_BV(SM0) | _BV(SM1) | _BV(SM2))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATA6285__) \
    || defined(__AVR_ATA6286__) \
    || defined(__AVR_ATA6289__)

        #define SLEEP_MODE_IDLE                     (0)
        #define SLEEP_MODE_SENSOR_NOISE_REDUCTION   (_BV(SM0))
        #define SLEEP_MODE_PWR_DOWN                 (_BV(SM1))

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined (__AVR_ATA5790__) \
    || defined (__AVR_ATA5790N__) \
    || defined (__AVR_ATA5795__) \
    || defined (__AVR_ATA5782__) \
    || defined (__AVR_ATA5831__)

        #define SLEEP_MODE_IDLE           (0)
        #define SLEEP_MODE_EXT_PWR_SAVE   (_BV(SM0))
        #define SLEEP_MODE_PWR_DOWN       (_BV(SM1))
        #define SLEEP_MODE_PWR_SAVE       (_BV(SM1) | _BV(SM0))     
       
        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined (__AVR_ATA5702M322__)

        #define SLEEP_MODE_IDLE           (0)
        #define SLEEP_MODE_EXT_PWR_SAVE   (_BV(SM0))
        #define SLEEP_MODE_PWR_DOWN       (_BV(SM1))
        #define SLEEP_MODE_PWR_SAVE       (_BV(SM1) | _BV(SM0))     
        #define SLEEP_MODE_EXT_PWR_DOWN   (_BV(SM2))
        #define SLEEP_MODE_PWR_OFF        (_BV(SM2) | _BV(SM0))
       
        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #elif defined(__AVR_ATtiny4__) \
    || defined(__AVR_ATtiny5__) \
    || defined(__AVR_ATtiny9__) \
    || defined(__AVR_ATtiny10__) \
    || defined(__AVR_ATtiny20__) \
    || defined(__AVR_ATtiny40__)

        #define SLEEP_MODE_IDLE         0
        #define SLEEP_MODE_ADC          _BV(SM0)
        #define SLEEP_MODE_PWR_DOWN     _BV(SM1)
        #define SLEEP_MODE_STANDBY      _BV(SM2)

        #define set_sleep_mode(mode) \
        do { \
            _SLEEP_CONTROL_REG = ((_SLEEP_CONTROL_REG & ~(_BV(SM0) | _BV(SM1) | _BV(SM2))) | (mode)); \
        } while(0)

    #else

        #error "No SLEEP mode defined for this device."

    #endif



    /** \ingroup avr_sleep

        Put the device in sleep mode. How the device is brought out of sleep mode
        depends on the specific mode selected with the set_sleep_mode() function.
        See the data sheet for your device for more details. */


    #if defined(__DOXYGEN__)

    /** \ingroup avr_sleep

        Set the SE (sleep enable) bit.
    */
    extern void sleep_enable (void);

    #else

    #define sleep_enable()             \
    do {                               \
      _SLEEP_CONTROL_REG |= (uint8_t)_SLEEP_ENABLE_MASK;   \
    } while(0)

    #endif


    #if defined(__DOXYGEN__)

    /** \ingroup avr_sleep

        Clear the SE (sleep enable) bit.
    */
    extern void sleep_disable (void);

    #else

    #define sleep_disable()            \
    do {                               \
      _SLEEP_CONTROL_REG &= (uint8_t)(~_SLEEP_ENABLE_MASK);  \
    } while(0)

    #endif


    /** \ingroup avr_sleep

        Put the device into sleep mode.  The SE bit must be set
        beforehand, and it is recommended to clear it afterwards.
    */
    #if defined(__DOXYGEN__)

    extern void sleep_cpu (void);

    #else

    #define sleep_cpu()                              \
    do {                                             \
      __asm__ __volatile__ ( "sleep" "\n\t" :: );    \
    } while(0)

    #endif


    #if defined(__DOXYGEN__)

    extern void sleep_mode (void);

    #else

    #define sleep_mode() \
    do {                 \
        sleep_enable();  \
        sleep_cpu();     \
        sleep_disable(); \
    } while (0)

    #endif


    #if defined(__DOXYGEN__)

    extern void sleep_bod_disable (void);

    #else

    #if defined(BODS) && defined(BODSE)

    #ifdef BODCR

    #define BOD_CONTROL_REG BODCR

    #else

    #define BOD_CONTROL_REG MCUCR

    #endif

    #define sleep_bod_disable() \
    do { \
      uint8_t tempreg; \
      __asm__ __volatile__("in %[tempreg], %[mcucr]" "\n\t" \
                           "ori %[tempreg], %[bods_bodse]" "\n\t" \
                           "out %[mcucr], %[tempreg]" "\n\t" \
                           "andi %[tempreg], %[not_bodse]" "\n\t" \
                           "out %[mcucr], %[tempreg]" \
                           : [tempreg] "=&d" (tempreg) \
                           : [mcucr] "I" _SFR_IO_ADDR(BOD_CONTROL_REG), \
                             [bods_bodse] "i" (_BV(BODS) | _BV(BODSE)), \
                             [not_bodse] "i" (~_BV(BODSE))); \
    } while (0)

    #endif

    #endif


    /*@}*/

    #endif /* _AVR_SLEEP_H_ */
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 19:45:45
    Hallo Markus,

    ohne jetzt jede Zeile kontrolliert zu haben - meine sieht auch so aus. Schau mal was mit meinem Sketch passiert. Sonst schick doch mal Deine Sketch - bzw. das Sketchverzeichnis. Vielleicht kann ich das dann hier nachstellen.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 20:11:46
    Hier die Dateien.

    Wenn es bei dir läuft kannst du mir deine Daten geben vielleicht ist das einfacher?

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 20:29:13
    Hallo Markus,

    welchen AVR hast Du -den 1er (länglich) oder den 2er (quadratisch) - wo sitzt der drauf (es gibt ein dipBoard was aus einem AVR2 einen AVR1 macht). Meine Dateien sind für den AVR1 und IDE 1.0.5

    gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 20:35:18
    Hallo Christoph

    Ich hab den AVR 1 den Länglichen
    arduino 1.0.6 hab ich noch hier wens wäre :-)

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 20:36:57
    Hast du auch die Vegatronix Feuchtesensoren dran?

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 20:48:25
    Hallo Markus,

    ja - zwei Vegatronics. Versuche doch mal die Dateien aus dem Zip ein paar Beiträge drüber. Das ist der Sketch, der bei mir auf einen AVR1 mit IDE 1.0.5 läuft. Das ist ein Zip vom Verzeichnis.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 20:56:01
    ok installiere gerade die 1.0.6 vielleicht geht es damit besser

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus am 07 Dezember 2015, 22:30:21
    Jetzt bekomme ich die panstamp biblioteck nicht instaliert  >:( >:( :'(
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 07 Dezember 2015, 22:38:32
    Hallo,

    wie, nicht installiert ? Du musst die aus dem "alten" Panstamp Forum nehmen - entpacken und unter libs.. kopieren. Anschließend die Libs über das Menue einbinden. Das läuft etwas anders als bei 1.6.x
    Du brauchst die Lib von hier: https://code.google.com/p/panstamp/downloads/list - wie gesagt, entlacken und in das richtige Verzeichnis kopieren, anmelden und gut.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 08 Dezember 2015, 00:44:53
    Hallo

    Ich hab jetzt diesen Fehler beim Überprüfen...

      This report would have more information with
      "Show verbose output during compilation"
      enabled in File > Preferences.
    Arduino: 1.0.6 (Windows NT (unknown)), Board: "PanStamp v2.0 (3.3V, 8 MHz) w/ ATmega328"
    soilmoisture.ino: In function 'void setup()':
    soilmoisture:106: error: 'class PANSTAMP' has no member named 'setHighTxPower'
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 08 Dezember 2015, 07:10:05
    Hallo,

    das Board stimmt doch auch nicht, Du hast ein V1.0 Board. Also schau mal ob Du ein anderes Board findest. Und die Zeile mit dem "setHighTxPower" würde ich mal einfach auskommentieren. Wenn das der einzigste Fehler ist, kann man weiter suchen.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 08 Dezember 2015, 14:00:56
    Hallo Christoph

    Ich hab jetzt wieder 1.6.6 Installiert nach dem ersten starten wurden Automatisch alle libs die ich früher schon oben hatte Nachgeladen und auch die Bords Aktualisiert...

    Ich hab dann die Soilmoisture Datei Geöffnet und Verifyt. Es schaut aus als ob es Funktioniert :)
    Jetzt hab ich auch schon einen Beschrieben der blinkt erst ganz wild und zum Schluss noch ein paar mal langsam.
    Richte jetzt mal FHEM ein um zu Testen.
    Danke! Berichte später ob es klappt.

    Gruß Markus

    Warning: platform.txt from core 'panStamp AVR Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
    Warning: platform.txt from core 'panStamp MSP430 boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
    Warning: platform.txt from core 'panStamp MSP430 boards' contains deprecated recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm, automatically converted to recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} -o "{build.path}/{build.project_name}.elf" {object_files} "{archive_file_path}" "-L{build.path}" -lm. Consider upgrading this core.
    WARNING: Category '' in library EEPROM is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library SPI is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library SoftwareSerial is not valid. Setting to 'Uncategorized'
    WARNING: Category '' in library Wire is not valid. Setting to 'Uncategorized'

    Sketch uses 9,214 bytes (28%) of program storage space. Maximum is 32,256 bytes.
    Global variables use 403 bytes (19%) of dynamic memory, leaving 1,645 bytes for local variables. Maximum is 2,048 bytes.
    Titel: Antw:panStamp support
    Beitrag von: Markus am 08 Dezember 2015, 22:09:40
    Hallo
    Bin jetzt schon weiter aber wie Rechne ich die Messwerte jetzt in Vernünftige Zahlen um?
    Gruß Markus


    2015-12-08_21:39:30 SWAP_52 0C.0-Moisture_level_0: 00B1
    2015-12-08_21:39:30 SWAP_52 0C.1-Moisture_level_1: 0086
    2015-12-08_21:39:30 SWAP_52 0B-Voltage: 0CDD
    2015-12-08_21:39:30 SWAP_52 voltage: 3.293
    2015-12-08_21:41:58 SWAP_52 0B-Voltage: 0CDD
    2015-12-08_21:41:58 SWAP_52 voltage: 3.293
    2015-12-08_21:41:59 SWAP_52 0C.0-Moisture_level_0: 0001
    2015-12-08_21:41:59 SWAP_52 0C.1-Moisture_level_1: 0001
    2015-12-08_21:41:59 SWAP_52 0B-Voltage: 0CDD
    2015-12-08_21:41:59 SWAP_52 voltage: 3.293
    2015-12-08_21:46:29 SWAP_52 0C.0-Moisture_level_0: 02A9
    2015-12-08_21:46:29 SWAP_52 0C.1-Moisture_level_1: 01B9
    2015-12-08_21:46:29 SWAP_52 0B-Voltage: 0CCA
    2015-12-08_21:46:29 SWAP_52 voltage: 3.274
    2015-12-08_21:50:33 SWAP_52 0C.0-Moisture_level_0: 02A8
    2015-12-08_21:50:33 SWAP_52 0C.1-Moisture_level_1: 01B5
    2015-12-08_21:50:33 SWAP_52 0B-Voltage: 0CE7
    2015-12-08_21:50:33 SWAP_52 voltage: 3.303
    2015-12-08_21:55:06 SWAP_52 0C.0-Moisture_level_0: 02A7
    2015-12-08_21:55:06 SWAP_52 0C.1-Moisture_level_1: 01B2
    2015-12-08_21:55:06 SWAP_52 0B-Voltage: 0CE7
    2015-12-08_21:55:06 SWAP_52 voltage: 3.303
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 08 Dezember 2015, 22:24:02
    Hey Markus,

    geil - hast es ja hinbekommen. Knall das Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(4.0/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))}, Level1_Voltage {hex(ReadingsVal($name,"0C.1-Moisture_level_1","0"))*(4.5/1024)}, VWC_B:0C.1-Moisture_level_1 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level1_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level1_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level1_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")} mal als userReading in deim Gerät.
    Ich habe für mich die Werte etwas angepasst, da die Sensoren selbst im Wasserglas nicht 100% anzeigten. Normalerweise ist die Basis 3.3 V - ich habe die etwas angehoben und bekomme dann höhere Werte - die Basis steht (4.0/1024) bzw. (4.5/1024). Die Werte sind unterschiedlich, weil die Sensoren verschieden lange Kabel haben.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 08 Dezember 2015, 23:48:50
    Hallo Christoph
    Erst mal Danke!! Ohne dich hätte ich es nicht Geschafft!!

    Aber ich hab da noch ein Problem:
    wenn ich jetzt (4.0/1024) bzw. (4.5/1024) in (3.3/1024) ändere hab ich dann wieder den Original wert? sind die 1024 zum feineinstellen?
    Ich frag nur weil ich so weit weg bin von richtigen werten wie es nur geht.
    Im log sieht man zwei Sensoren in einem Vollem Wasserglas also 100%


    Danke
    Gruß Markus

    2015-12-08_23:32:41 PanStamp_1 0C.0-Moisture_level_0: 0243
    2015-12-08_23:32:41 PanStamp_1 0C.1-Moisture_level_1: 025F
    2015-12-08_23:32:41 PanStamp_1 VWC_B: 79
    2015-12-08_23:32:41 PanStamp_1 Level0_Voltage: 2.26171875
    2015-12-08_23:32:41 PanStamp_1 Level1_Voltage: 2.66748046875
    2015-12-08_23:32:41 PanStamp_1 VWC_A: 56
    2015-12-08_23:32:42 PanStamp_1 0B-Voltage: 0CE7
    2015-12-08_23:32:42 PanStamp_1 voltage: 3.303
    2015-12-08_23:32:42 PanStamp_1 battery: ok
    2015-12-08_23:32:42 PanStamp_1 Level0_Voltage: 2.26171875
    2015-12-08_23:32:42 PanStamp_1 Level1_Voltage: 2.66748046875
    2015-12-08_23:36:58 PanStamp_1 0C.0-Moisture_level_0: 0240
    2015-12-08_23:36:58 PanStamp_1 0C.1-Moisture_level_1: 025B
    2015-12-08_23:36:58 PanStamp_1 VWC_B: 79
    2015-12-08_23:36:58 PanStamp_1 Level0_Voltage: 2.25
    2015-12-08_23:36:58 PanStamp_1 Level1_Voltage: 2.64990234375
    2015-12-08_23:36:58 PanStamp_1 VWC_A: 55
    2015-12-08_23:36:58 PanStamp_1 0B-Voltage: 0CE7
    2015-12-08_23:36:58 PanStamp_1 voltage: 3.303
    2015-12-08_23:36:58 PanStamp_1 battery: ok
    2015-12-08_23:36:58 PanStamp_1 Level0_Voltage: 2.25
    2015-12-08_23:36:58 PanStamp_1 Level1_Voltage: 2.64990234375
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 09 Dezember 2015, 07:18:22
    Hallo,

    die 1024 sind ein Teiler wegen dem A/D Wandler. Eigentlich müsste die Spannung wenn die Teile im Wasserglas sind 3,3 Volt sein. Das das nicht so ist (2,26 bzw. 2,66) habe ich die Basis von 3,3 auf 4,0 bzw. 4,5 erhöht. Ich habe das auch irgendwo gefunden und nicht selber entwickelt. Zunächst hatte ich beide auf 4,5 - den einen habe ich vor kurzem runtergesetzt, da ich über 100% kam. Ich habe einfach versucht, die darüber auf 100% zu kalibrieren. Wichtig ist - länger im Wasser stehen lassen, die Werte verändern sich anscheinen noch leicht.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 09 Dezember 2015, 17:53:50
    Danke das Funktioniert aber noch nicht perfekt...
    Noch Teste ich in einem Wasserglas zwei Sensoren Neben einander.
    Ich musste 6 und 6.3 Volt einstellen um 100% zu haben
    Die Sensoren schwanken um bis zu 15% rauf und runter ist das Normal?
    Der erste VWC_A wird sofort Aktualisiert und der VWC_B hängt 4 Minuten nach (ich glaub das hatte Puschel74 auch)

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 09 Dezember 2015, 21:24:01
    Hallo,

    Feuchtigkeit messen - das ist immer so eine Sache. Auch bei den Luftfeuchtesensoren gibt es wahnsinnige Abweichungen. Ich habe im Wohnzimmer noch ein Therm-/Hygdrometer von Oregon stehen - die Abweichung zu dem HM Teil - was direkt daneben steht - sind so um die 10 - 15%.
    Für mich ist das nur ein "Peilometer" ich bestimme durch Versuch einen Wert, ab dem bewässert werden muss. Es kommt ja auch noch immer darauf an, wieviel Schatten usw. vorhanden sind. Meine zwei Sensoren sind ca. 4 Meter auseinander. Der eine geschützt unter Efeu, der andere nicht - Unterschied schlappe 26%.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 10 Dezember 2015, 13:05:39
    Hallo Christoph

    Ist jetzt auch nicht so extrem wie es am Anfang ausgeschaut hat Hab mir gerade einen Plot gemacht und die letzten 13 Stunden Schwankungen von 96 bis 100 und einmal 102% das las ich gelten  ;D

    Nochmals Danke!!! ohne dich hätte ich es nicht Geschafft!

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus am 11 Dezember 2015, 19:46:17
    Hallo

    Mir ist gerade aufgefallen das der PanStamp immer 3.3 Volt anzeigt egal wie lehr die Batterie ist.
    hab dann hier: http://old.panstamp.com/products/battery-board (http://old.panstamp.com/products/battery-board) gelesen das der Max aus 0.8-1.5 Volt 3.3 Volt Macht.
    Frage: Kann ich dann den wert überhaupt zur Batterieüberwachung nutzen?

    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 11 Dezember 2015, 21:06:07
    Hallo,

    mit der alten Bibliothek waren die Werte korrekt - also im Bereich der Batterie 1,5 - 1,2 Volt. Schau mal im Sktech an welchem Pin gemessen wird. Müsste nachsehen - glaube aber es war A7. Sonst müsste man mal beide Versionen vergleichen.

    Gruß Christoph

    Edit: in den alten Sketches stand immer "define VOLT_SUPPLY_A7" und dann gibt es noch in der regtable einen Abschnitt, wo der Wert berechnet wird.
    Titel: Antw:panStamp support
    Beitrag von: Markus am 12 Dezember 2015, 00:23:58
    Hallo
    in welcher Date muss ich nach "define VOLT_SUPPLY_A7" suchen?
    die Berechnung hab ich gefunden aber das ist mir zu hoch :(

    Gruß Markus

    /*
    * soilmoisture
    *
    * Copyright (c) 2014 panStamp <contact@panstamp.com>
    *
    * This file is part of the panStamp project.
    *
    * panStamp  is free software; you can redistribute it and/or modify
    * it under the terms of the GNU General Public License as published by
    * the Free Software Foundation; either version 2 of the License, or
    * any later version.
    *
    * panStamp is distributed in the hope that it will be useful,
    * but WITHOUT ANY WARRANTY; without even the implied warranty of
    * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    * GNU General Public License for more details.
    *
    * You should have received a copy of the GNU General Public License
    * along with panStamp; if not, write to the Free Software
    * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301
    * USA
    *
    * Author: Daniel Berenguer
    * Creation date: 04/29/2013
    *
    * Device:
    * Soil Moisture sensor
    *
    * Description:
    * This application measures soil moisture from any two sensor providing an
    * analog signal
    *
    * These devices are low-power enabled so they will enter low-power mode
    * just after reading the sensor values and transmitting them over the
    * SWAP network.
    *
    * Associated Device Definition File, defining registers, endpoints and
    * configuration parameters:
    * soilmoisture.xml
    */

    #include "regtable.h"
    #include "swap.h"

    /**
    * Sensor pins
    */
    #define SENSOR_0_PIN  A4    // Analog pin - sensor 0
    #define POWER_0_PIN   7    // Digital pin used to powwer sensor 0
    #define SENSOR_1_PIN  A5    // Analog pin - sensor 1
    #define POWER_1_PIN   6    // Digital pin used to powwer sensor 1
    /**
    * setup
    *
    * Arduino setup function
    */
    void setup()
    {
      int i;

      pinMode(LED, OUTPUT);
      digitalWrite(LED, LOW);

      // Initialize power pins
      pinMode(POWER_0_PIN, OUTPUT);
      digitalWrite(POWER_0_PIN, LOW);
      pinMode(POWER_1_PIN, OUTPUT);
      digitalWrite(POWER_1_PIN, LOW);

      // Init SWAP stack
      swap.init();
     
      // Transmit product code
      swap.getRegister(REGI_PRODUCTCODE)->getData();

      // Enter SYNC state
      swap.enterSystemState(SYSTATE_SYNC);

      // During 3 seconds, listen the network for possible commands whilst the LED blinks
      for(i=0 ; i<6 ; i++)
      {
        digitalWrite(LED, HIGH);
        delay(100);
        digitalWrite(LED, LOW);
        delay(400);
      }

      // Transmit periodic Tx interval
      swap.getRegister(REGI_TXINTERVAL)->getData();
      // Transmit power voltage
      swap.getRegister(REGI_VOLTSUPPLY)->getData();
       // Switch to Rx OFF state
      swap.enterSystemState(SYSTATE_RXOFF);
    }

    /**
    * loop
    *
    * Arduino main loop
    */
    void loop()
    {
      // Transmit sensor data
      swap.getRegister(REGI_SENSOR)->getData();
      // Transmit power voltage
      swap.getRegister(REGI_VOLTSUPPLY)->getData();

      // Sleep
      swap.goToSleep();
    }

    // Voltage supply
    static byte dtVoltSupply[2];
    REGISTER regVoltSupply(dtVoltSupply, sizeof(dtVoltSupply), &updtVoltSupply, NULL);
    // Sensor value register (dual sensor)
    static byte dtSensor[4];
    REGISTER regSensor(dtSensor, sizeof(dtSensor), &updtSensor, NULL);


    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 12 Dezember 2015, 08:19:39
    Hallo Markus,

    nach den beiden "include" geht es bei mir so
    /**
    * Uncomment if you are reading Vcc from A7. All battery-boards do this
    */
    #define VOLT_SUPPLY_A7

    /**
    * LED pin
    */
    #define LEDPIN        4

    weiter. Dann kommt wie bei Dir die Definition der Sensorpins.
    In der regtable steht das bei mir so
    // Voltage supply
    static unsigned long voltageSupply = 3300;
    static byte dtVoltSupply[2];
    REGISTER regVoltSupply(dtVoltSupply, sizeof(dtVoltSupply), &updtVoltSupply, NULL);
    // Sensor value register (dual sensor)
    static byte dtSensor[4];
    REGISTER regSensor(dtSensor, sizeof(dtSensor), &updtSensor, NULL);

    wie schon gesagt - die "alte" Version arbeitet noch mit der panstamp.h und nicht mit der swap.h

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: Markus am 12 Dezember 2015, 21:53:20
    Danke hab versucht es anzupassen Leider verstehe ich nichts davon...
    Upload des Programms funktioniert zwar immer aber das Ding sendet nicht mehr als sonst auch.
    Somit bin ich raus :'(
    Die Volt wäre halt schon toll gewesen aber ich kann auch ohne damit leben :'(


    Gruß Markus
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 16 Januar 2016, 19:50:13
    Nabend,

    sagt mal diese Adapterboards für die neuen panStamps auf die alte Bauform sind ja beschi**en, die sind ja viel größer, das passt ja nirgends mehr.

    Hat schon mal jemand gescheid Pfostenleisten an die neuen Boards anzulöten und die zu Sockeln? Irgendwie finde ich die neuen Briefmarken nicht so ganz sympathisch, bin ich da alleine mit meiner Meinung? Weniger ist nicht immer mehr...

    /Daniel

    Titel: Antw:panStamp support
    Beitrag von: joshi04 am 16 Januar 2016, 22:10:02
    Nö, bist Du nicht, auch wenn bei mir bislang keine Einschränkungen durch die Adapter auftraten (RGB-Board und Dein RGBWW-Board).

    So richtig nachvollziehen kann ich das noch nicht, warum der Schritt zum neuen Format getätigt wurde. Wobei darüber hinaus auch das schnell mal umflashen ohne die Adapterboards ja mit den AVRs recht aufwändig ist.

    Schöne Grüße,
    John
    Titel: Antw:panStamp support
    Beitrag von: Bennemannc am 16 Januar 2016, 22:43:32
    Hallo,

    da kann ich nur zustimmen - vor allem die Batterieboards, mit max und den "wichtigsten" Anschlüssen schin herausgeführt. Wirklich gut finde ich das neue Board auch nicht - wobei ich bis jetzt auch nicht vertsanden habe, was besser an dem AVR2 sein soll.

    Gruß Christoph
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 07 Februar 2016, 09:52:41
    Moin,

    mal eine Frage zum panStamp Temp Board, ich habe das Problem schon lange und jetzt denke ich mal dran zu fragen:

    Nach einem Refresh der Seite sehe ich folgendes:
    SWAP_03 Temp: 20.9 °C, Luftfeuchtigkeit: 50.7 %, Spannung: 3.382 V

    Dann durch eine Aktualisierung vom Longpoll sehe ich:
    SWAP_03 Temp: 20.9 °C, Luftfeuchtigkeit: 50.7 %, Spannung: 3.382 V

    Hat das noch jemand? Da haut doch was mit dem HTML Code nicht hin, das A mit Dach gehört doch da nicht rein.

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 07 Februar 2016, 16:52:30
    zeig mal bitte das stateFormat attribut von dem device. und am besten auch gleich userReadings und ein list. dein problem liegt ziemlich sicher eher hier als am modul selber.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 07 Februar 2016, 17:08:00
    Ja das kann schon sein. Hier das listing:

    Internals:
       DEF        03
       Developer  panStamp
       IODev      PanStick
       LASTInputDev PanStick
       MSGCNT     344
       NAME       SWAP_03
       NR         1681
       PanStick_LQI 48
       PanStick_MSGCNT 344
       PanStick_RAWMSG (0030)000300BA00030B0D36
       PanStick_RSSI -74
       PanStick_TIME 2016-02-07 17:01:29
       Product    Dual Temperature/Humidity sensor
       STATE      Temp: 20.9 °C, Luftfeuchtigkeit: 50.7 %, Spannung: 3.382 V
       SWAP_MISSED 6
       SWAP_Sent_unconfirmed 1 Sent_unconfirmed
       SWAP_lastRcv 2016-02-07 17:01:29
       SWAP_lastSend 2016-02-07 14:04:53
       SWAP_nonce BA
       TYPE       SWAP
       addr       03
       devices
       Readings:
         2016-02-07 17:01:29   0B-Voltage      0D36
         2016-02-07 17:01:29   0C.0-Temperature 02C5
         2016-02-07 17:01:29   0C.1-Humidity   01FB
         2016-02-07 17:01:29   dewpoint        10.3
         2016-02-07 17:01:29   humidity        50.7
         2016-02-07 10:28:11   state           set-statusRequest
         2016-02-07 17:01:29   temperature     20.9
         2016-02-07 17:01:29   voltage         3.382
       Product:
         label      Dual Temperature/Humidity sensor
         name       temphum
         pwrdownmode 1
         Registers:
           11:
             hwmask
             name       Voltage supply
             swversion
             type       regular
             endpoints:
               HASH(0x6846e00)
           12:
             hwmask
             name       Humidity and Temperature
             swversion
             type       regular
             endpoints:
               HASH(0x6846590)
               HASH(0x623ed68)
       sentList:
         ARRAY(0x6bad7b8)
    Attributes:
       IODev      PanStick
       ProductCode 0000000100000001
       comment    Batteriewechsel 21.09.15
       room       SWAP
       stateFormat Temp: temperature °C, Luftfeuchtigkeit: humidity %, Spannung: voltage V
       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}, humidity:0C.1-Humidity {hex(ReadingsVal($name,"0C.1-Humidity","0"))*0.1}
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 28 Februar 2016, 10:35:16
    Moin,

    schon mal geschaut ob du was finden konntest?

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 28 Februar 2016, 10:55:04
    sorry. das ist untergegangen. ich glaube das problem ist nicht nicht panstamp/swap spezifisch sondern ist ein encoding problem zwischen fhem und browser.

    geht es besser wenn du &deg; statt ° verwendest ?

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 28 Februar 2016, 11:13:47
    Stimmt scheint besser zu gehen. Ich hatte das damals schon mal eingefügt und im STATE das &deg; gesehen und wieder raus genommen, aber das wird nur im STATE so angezeigt, auf dem Gerät dann sieht es sauber aus. Ich werds beobachten.

    Gruß
    Daniel
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 24 April 2016, 01:45:25
    Nabend, du sag mal seit 17.04. bekommt FHEM zwar Daten von meinem Temp/Hum Boards, aber dieo readings für Temp und Hum und Spannung werden nicht mehr aktualisiert. Wurde da was geändert?!?

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 24 April 2016, 11:55:43
    du musst die user readings anpassen. ans ende jedes triggers muss ein .*

    gruß
      andre
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 24 April 2016, 11:55:49
    Hi Daniel,

    das liegt an https://sourceforge.net/p/fhem/code/11243/ (siehe: https://forum.fhem.de/index.php/topic,52165.0.html)

    Das bedeutet, dass bei allen Triggern in userReadings ein ".*" rangestellt werden muss.

    Bsp:

    vorher:

    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}

    nachher:

    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}

    Evtl. sollte man das im autocreate entsprechend ändern.

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 24 April 2016, 11:57:18
    Zufälle gibts......
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 24 April 2016, 12:00:28
    im modul ist es schon angepasst. wenn du nur den default verwendest kannst userReadings auch einfach löschen und es wird beim neu setzen des ProductCode attributs neu angelegt.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 24 April 2016, 12:10:37
    Alles klar, danke. Und ich habe mich schon gewundert warum die Heizung nicht mehr an geht im Arbeitszimmer...

    Ist aber auch immer wieder blöd das man beim Update keine vernünftigen Release Notes sieht. Immer nur wenn einer mal Laune hatte steht was kryptisches da. Beim Update der fhem.pl sieht man eigentlich nie was.

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 24 April 2016, 12:23:15
    In diesem Fall gab es aber eine Meldung im CHANGED:

    Zitat- bugfix:  userReadings trigger is always $ terminated (Forum #52165)

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 24 April 2016, 12:29:48
    Echt, mhh dann habe ich das überlesen. Auch wenn die Meldung für mich nichtssagend ist aber zumindest hätte man ein Link zum Forum gehabt ;-)

    Aber ich sehe bei dem Update Check Modul auch nicht durch, da sind manchmal Meldungen die schon alt sind und dann mitten drin was neues und mhh, ich glaube ich bin zu blöd das zu interpretieren ;-)

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: Markus Bloch am 24 April 2016, 12:49:16
    Dafür kannst du andere tolle Sachen, die ich nicht kann. Also jedem das Seine ;)

    Gruß
    Markus
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 05 September 2016, 08:48:17
    Moin,

    ich hab mir mal ein Gehäuse gedruckt für den panStick.

    http://www.thingiverse.com/thing:1690611

    Ich werd es bei Gelegenheit auch mal ins Wiki aufnehmen, falls nicht jemand schneller ist. Das Gehäuse ist recht simple in 10 Minuten zusammengeklickt, aber es erfüllt seinen Zweck und der Stick ist nicht mehr so nackig.
    Titel: Antw:panStamp support
    Beitrag von: klausw am 09 Oktober 2016, 17:13:23
    Hallo zusammen,

    hier im thread wurde mal (2013) das Thema Firmata auf Panstamp angesprochen.
    Gibt es einen funktionierenden Sketch dafür?

    Grüße
    Klaus
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 09 Oktober 2016, 17:31:13
    es gibt ein paar vorarbeiten, aber über die 868mhz ist das ganze nicht wirklich sinnvoll und flüssig. zumindest nicht wenn man swap untendrunter beibehält.

    direkt swap zu verwenden ist viel besser.

    was hast du denn genau vor?

    gruss
      andre

    Titel: Antw:panStamp support
    Beitrag von: klausw am 09 Oktober 2016, 17:37:49
    Zitat von: justme1968 am 09 Oktober 2016, 17:31:13
    es gibt ein paar vorarbeiten, aber über die 868mhz ist das ganze nicht wirklich sinnvoll und flüssig. zumindest nicht wenn man swap untendrunter beibehält.

    direkt swap zu verwenden ist viel besser.

    was hast du denn genau vor?

    Ich will meinen alten Heizkessel etwas intelligenter machen (Umschaltung Heizen/Frostschutz, Warmwasser einschalten,... ).
    Der Kessel soll nach wie vor autark funktionieren.
    Kabel möchte ich nicht erst legen.
    Firmata wäre da einen komfortable/flexible Lösung gewesen.
    Aber auch ein eigener Sketch ist nicht das Problem ;).

    Grüße
    Klaus
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 09 Oktober 2016, 17:44:52
    mit einem eigenen sketch bist du sehr viel flexibler. und es ist mit swap auch recht einfach das zu machen.
    Titel: Antw:panStamp support
    Beitrag von: klausw am 09 Oktober 2016, 18:19:05
    Zitat von: justme1968 am 09 Oktober 2016, 17:44:52
    mit einem eigenen sketch bist du sehr viel flexibler. und es ist mit swap auch recht einfach das zu machen.

    Stimmt, so schwer was das nicht.
    Ich habe jetzt ein anderes Problem.
    Nach einer Neuinstallation von Raspbian Jessie bekomme ich den panstick nicht mehr zum laufen.
    Ich habe das Modul direkt an die Raspberry ttyAMA0 gehängt (console ist deaktiviert).
    Wenn ich im DEF vom Panstick /dev/ttyAMA0 stehen habe, steht der Panstick auf initialized address,channel,syncword stehen auf 0
    Wenn ich eine ungültige Adresse nehme steht zwar disconnected address,channel,syncword haben aber die korrekten default werde.

    Vor der Neuinstallation lief der panstick

    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 09 Oktober 2016, 18:29:42
    ist /dev/ttyAMA0 wirklich richtig? einbinden über /dev/serial/by-id ist besser und stabiler.

    taucht der panstick in /dev/serial/by-id auf wenn du in einsteckst bzw. verschwindet wer wenn du ihn abziehst?



    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: klausw am 09 Oktober 2016, 18:37:12
    ich habe keinen Panstick dran.
    Das Panstamp Modul mit dem Modem Sketch habe ich direkt an die serielle Schnittstelle vom Pi (Pin8/10) angeschlossen.
    Das ist ttyAMA0 oder serial0 (gelinkt auf ttyAMA0). Das Modul taucht daher nicht in serial/by-id auf, weil dort nur USB Geräte auftauchen.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 09 Oktober 2016, 18:40:34
    ok. dazu kann ich dir nicht viel sagen. nur das ich irgend einen thread gesehen hab das das aktivieren der seriellen schnittstelle unter jessie anders funktioniert bzw. das man mehr tun muss als unter wheezy.
    Titel: Antw:panStamp support
    Beitrag von: klausw am 09 Oktober 2016, 19:09:00
    Zitat von: justme1968 am 09 Oktober 2016, 18:40:34
    ok. dazu kann ich dir nicht viel sagen. nur das ich irgend einen thread gesehen hab das das aktivieren der seriellen schnittstelle unter jessie anders funktioniert bzw. das man mehr tun muss als unter wheezy.
    Das muss ich mir noch genauer anschauen.
    Über USB geht es. Allerdings sind address,channel,syncword auch hier 0.

    Internals:
       Clients    :SWAP:
       DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A947N99D-if00-port0
       DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A947N99D-if00-port0@38400
       FD         34
       FWVersion
       HWVersion
       LQI        47
       NAME       panstick
       NR         58
       PARTIAL
       RAWMSG     (232F)0034002400340D0F
       RSSI       -56.5
       STATE      initialized
       TYPE       panStamp
       address    00
       channel    00
       nonce      0
       panstick_MSGCNT 12
       panstick_TIME 2016-10-09 19:07:38
       syncword   0000
       Matchlist:
         1:SWAP     ^.*
       Readings:
         2016-10-09 19:07:38   state           initialized
    Attributes:
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 26 Oktober 2016, 15:53:52
    Nabend,

    kann mir mal bitte jemand ein hex schicken für das alte Battery Board mit DHT22 und AKTIVIERTEM A7 Pin... Bei meinen ist das Flag wohl nicht gesetzt daher sehe ich immer nur die 3,3V. (AVR panstamp)

    Ich dachte ich kann den Sketch mal eben mit ino unter Linux kompilieren aber ich gebs auf *kotz*

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: klausw am 26 Oktober 2016, 17:20:39
    Hallo Andre,

    beim auslesen der xml Dateien scheinen die Positionswerte nicht beachtet zu werden, sondern die Reihenfolge.
    Bei den beiden folgenden Beispielen ist die Reihenfolge der Namen identisch, aber die Position ist jeweils umgekehrt.
    Bei beiden Beispielen werden die Readings gleich angezeigt:

    10.0-Zeitschaltuhr
    10.1-Heizen
    10.2-Frostschutz
    10.3-leer
    10.4-Pumpe_Boiler
    2016-10-26 17:18:21
    10.5-Pumpe_Heizkreis
    10.6-Brenner
    10.7-leer

    obwohl sie eigentlich die Reihenfolge umkehren müssten.

        <reg name="Status" id="16">
          <endpoint name="Zeitschaltuhr" type="bin" dir="inp">
            <position>0.0</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Heizen" type="bin" dir="inp">
            <position>0.1</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Frostschutz" type="bin" dir="inp">
            <position>0.2</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="leer" type="bin" dir="inp">
            <position>0.3</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Pumpe Boiler" type="bin" dir="inp">
            <position>0.4</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Pumpe Heizkreis" type="bin" dir="inp">
            <position>0.5</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Brenner" type="bin" dir="inp">
            <position>0.6</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="leer" type="bin" dir="inp">
            <position>0.7</position>
            <size>0.1</size>
          </endpoint>
        </reg>


        <reg name="Status" id="16">
          <endpoint name="leer" type="bin" dir="inp">
            <position>0.7</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Brenner" type="bin" dir="inp">
            <position>0.6</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Pumpe Heizkreis" type="bin" dir="inp">
            <position>0.5</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Pumpe Boiler" type="bin" dir="inp">
            <position>0.4</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="leer" type="bin" dir="inp">
            <position>0.3</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Frostschutz" type="bin" dir="inp">
            <position>0.2</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Heizen" type="bin" dir="inp">
            <position>0.1</position>
            <size>0.1</size>
          </endpoint>
          <endpoint name="Zeitschaltuhr" type="bin" dir="inp">
            <position>0.0</position>
            <size>0.1</size>
          </endpoint>
        </reg>


    Grüße
    Klaus
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 27 Oktober 2016, 11:27:54

    das ist absicht. im reading namen wird die laufende nummer des enpoints verwendet. nicht die bit position.

    prinzipiell sind endpoints nicht auf ein einzelnes bit beschränkt und es kann auch überlappungen zwischen den endpoints geben.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: klausw am 27 Oktober 2016, 16:38:33
    Zitat von: justme1968 am 27 Oktober 2016, 11:27:54
    das ist absicht. im reading namen wird die laufende nummer des enpoints verwendet. nicht die bit position.
    Ich stehe noch auf dem Schlauch.
    mit laufender Nummer meinst du die Reihenfolge?

    Zitat von: justme1968 am 27 Oktober 2016, 11:27:54
    prinzipiell sind endpoints nicht auf ein einzelnes bit beschränkt und es kann auch überlappungen zwischen den endpoints geben.
    Das ist mir klar.
    Das mit der Überlappung allerdings nicht. Wenn ich die Anfangsposition nicht aus der "position" nehme kann ich doch auch nicht herausfinden, was sich überlappen soll.
    Ich habe auch nur den Teil gepostet bei dem es mir aufgefallen ist und das war dieses eine Byte mit 8 booleschen Endpoints.
    Beispielsweise das xml vom Binout Sketch zeigt die Eingänge in SWAPdmt in umgekehrter Reihenfolge im Vergleich zu FHEM.

    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 27 Oktober 2016, 16:52:39
    ja. die reihenfolge im xml.

    der rgb controller sketch verwendet ein 4 byte register für die farbe und darin jeweils 1 byte breite endpoints für die einzelnen farben. (r, g, b und w) zusätzlich könnte man noch mal ein 3 byte endpoint definieren der rgb enthält. dann hättest du den r endpoint und den rgb endpoint an der gleichen postion.

    bei regSet und regGet gibts du nach dem punk auch nicht die bit position an sondern die laufende nummer. wenn man die bit position angeben würde wäre das nicht immer eindeutig (siehe rgb beispiel).

    aber das ist doch nur die angezeigte reihenfolge. fhem sortiert nicht nach bit position sondern nach reihenfolge im xml.
    Titel: Antw:panStamp support
    Beitrag von: klausw am 27 Oktober 2016, 17:20:44
    Ich sehe gerade, das ich einen Fehler in meinem Beispiel hatte, ich habe es korrigiert...vermutlich haben wir aneinander vorbei gesprochen.
    Das Problem war nicht die Reihenfolge, oder Bit Nummer.

    Die Endpoint-Blöcke sind in beide male identisch (nur einmal steht der Block von bit7 oben und das andere mal der Block von bit0)
    Unter SWAPdmt wird bei beiden Varianten, wenn ich Bit0 auf "1" setze auch 10.0-Zeitschaltuhr "1"
    Unter FHEM wird, wenn der Endpoint von Bit7 oben steht 10.7-leer auf "1" gesetzt
    und wenn der Endpoint von Bit1 oben steht ist 10.0-Zeitschaltuhr = "1"

    Aber ich bin jetzt trotzdem etwas verunsichert...  8)
    Ich muss es bei Gelegenheit noch einmal reproduzieren.
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 27 Oktober 2016, 18:02:33
    10.7 ist nicht der endpoint der zu bit 7 gehört sondern der endloint der an 7. stelle unter dem register 10 kommt.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 27 Oktober 2016, 18:27:28
    André, kannst du mir das mal eben kompilieren?

    Zitat von: ext23 am 26 Oktober 2016, 15:53:52
    Nabend,

    kann mir mal bitte jemand ein hex schicken für das alte Battery Board mit DHT22 und AKTIVIERTEM A7 Pin... Bei meinen ist das Flag wohl nicht gesetzt daher sehe ich immer nur die 3,3V. (AVR panstamp)

    Ich dachte ich kann den Sketch mal eben mit ino unter Linux kompilieren aber ich gebs auf *kotz*

    /Daniel
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 27 Oktober 2016, 18:33:27
    ich schicke es dir wenn ich am anderen rechner bin. wenn ich es vergesse erinnert mich am wochenende bitte noch mal.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: justme1968 am 29 Oktober 2016, 19:32:43
    schau mal on die angehängte version tut was du willst.

    gruss
      andre
    Titel: Antw:panStamp support
    Beitrag von: ext23 am 29 Oktober 2016, 20:34:46
    Super danke, das wars!

    /Daniel