panStamp support

Begonnen von justme1968, 24 April 2013, 21:35:25

Vorheriges Thema - Nächstes Thema

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Rince

Irgendwann wirst du diese Worte bereuen *lach*

Was den Bereich angeht, sind doch schon einige mehr ;-)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Rince

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)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Heiermann

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


Rince

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.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Carsten

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

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ntruchsess

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...)
while (!asleep()) {sheep++};

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ntruchsess

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

while (!asleep()) {sheep++};

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

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 immer noch.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968