panStamp support

[Markus Bloch]

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

[justme1968]

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

[justme1968]

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

[justme1968]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[daduke]

@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

[justme1968]

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

[daduke]

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

[Markus Bloch]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[Markus Bloch]

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

[justme1968]

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

[Markus Bloch]

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.

[Markus Bloch]

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.

[Bjoern777]

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?

[Tobias]

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 verfügbar

Edit: ich hab mal den SoilmoistureSketch auf 4 Sensoren aufgebohrt

[justme1968]

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