Arduino Asksin library

[trilu]

ich könnte dir auch einen arduino schicken, hab ja ein paar geliefert bekommen

[Dirk]

Da hat aber jemand eingekauft

Laut Sendungsverfolgung sind die Teile seit ein Paar Tagen schon in DE.
Daher rechne ich jeden Tag mit der Lieferung.
Bei den Funkmodulen komme ich ggf. nochmal drauf zurück.
Da hatte ich erst mal "nur" 5 geordert.

Gruß
Dirk

[xequtor]

Hallo Zusammen

Habe mal meine neuen "Level Converter" getestet.
http://www.adafruit.com/products/757

Wenn du 2-Teile für 5 Ports dazwischen hängen, geht nur noch die LED13 an und der Serialport protokolliert nix mehr
...

ich hab den Level Konverter für MOSI und SCK genommen und 1k/680 für CS und soweit funktioniert.

[Jaydee]

wenn ich es richtig verstanden habe, simuliert der Arduino existierende HM-Geräte. Er sieht also nach außen hin - für HMLAN, aber zur Not auch für eine CCU - aus, wie ein richtiges HM-Gerät.

Nun hätte ich mal ne ganz dumme Frage: kann er sich nur als EIN Gerät ausgeben?

wenn es z.B. mal irgendwann einen Sketch für einen HM-SCI-3-FM gibt, der die Schaltzustände von 3 Kontakten übertragen kann, wäre es dann theoretisch möglich mit einem Arduino 2 oder 3  solcher virtuellen Geräte zu simulieren? GPIOs sind ja nun genug vorhanden. Natürlich brauchte dann jedes der virtuellen Geräte eine eigene HM-ID, und  würde auch von der Zentrale als einzelne Geräte behandelt werden, aber wäre sowas prinzipiell machbar?

LG
Jan

[Dirk]

wenn ich es richtig verstanden habe, simuliert der Arduino existierende HM-Geräte. Er sieht also nach außen hin - für HMLAN, aber zur Not auch für eine CCU - aus, wie ein richtiges HM-Gerät.

Das sollte eigentlich so sein.

wenn es z.B. mal irgendwann einen Sketch für einen HM-SCI-3-FM gibt, der die Schaltzustände von 3 Kontakten übertragen kann, wäre es dann theoretisch möglich mit einem Arduino 2 oder 3  solcher virtuellen Geräte zu simulieren.

Das könnte man sicher machen.
Man könnte man auch eigene Geräte bauen die völlig neue Sachen machen. In FHEM muss dann so ein neues Gerät implementiert werden und in der CCU / HMLAN-Software auch.
Das wiederum würde bedeuten für dieses Gerät eine entsprechende XML-Datei zu Schreiben, dann kann man das auch "ganz normal" mit der CCU / der HMLAN-Software benutzen

[trilu]

Das simulieren von mehreren Geräten, also Kanälen sollte kein Problem sein. Zumindest nicht in FHEM.
Die xml's für die HM Soft, sei es für die Config Soft oder die CCU anzupassen sehe ich schon als größere Herausforderung.
Zumindest habe ich sie noch nicht ganz verstanden

[gandy]

Hi trilu,

super was Du hier auf die Beine stellst - hab mir inzwischen eine Handvoll panstamps besorgt und versucht, 131208_sketch_aug05a auf meiner Installation zu übersetzen:

Code Auswählen Erweitern


kubuntu 13.10
avr-g++ (GCC) 4.7.2
arduino 1:1.0.5+dfsg2-1

Dabei kommt es zu folgenden Fehlern:

Code Auswählen Erweitern


sketch_aug05a.ino:21:32: error: variable 'cmdTab' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
sketch_aug05a.ino:40:25: error: variable 'jumptable' must be const in order to be put into read-only section by means of '__attribute__((progmem))'

Um diese Fehler zu beheben, musste ich an verschiedenen Stellen const einfügen, die nötigen Änderungen habe ich als Patch angefügt, falls Interesse daran besteht.

Was ich gerne realisieren möchte, ist eine batteriegetriebene LED-Leuchte, die möglichst tief schläft, bis sie per config-taster (für ein pairing) oder per burst-signal geweckt wird. Nach dem Schaltvorgang soll sie sich wieder schlafen legen (aus: möglichst tief; an: bis zum nächsten Schaltvorgang oder Ablauf eines konfigurierbaren Timers). Zudem soll sie 1-2 mal pro Tag den Batteriestand melden und den ActionDetector zufriedenstellen können. Hab mich in die Homematic-Devices noch nicht genügend eingelesen, um zu sehen, was dafür alles benötigt wird oder wie am besten vorzugehen ist und wäre von daher sehr dankbar für Einstiegspunkte. Würde im Gegenzug gern versuchen, die Lösung incl. Schaltplan möglichst nachvollziehbar zu dokumentieren. Ist die AskSin Library prinzipiell schon so weit oder gibt es wesentliche Aspekte, die für eine erfolgreiche Umsetzung noch fehlen?

Danke,
Andy.

[trilu]

Hi Andy, 
So etwas bastle ich gerade. Die Frage ist allerdings was du unter Tiefschlaf verstehst 
Um ein Burstsignal empfangen zu können muss ich den Arduino und das Funkmodul alle 250 ms für 10 ms aufwachen lassen. Das heisst für den Stromverbrauch nichts Gutes. Das Modul wird vermutlich bei 0.1 bis 0.3 ma liegen. Das ist schwer an der Grenze für ein Batterie betriebenes Gerät.
Ansonsten bin ich mit dem Schaltmodul fast fertig. Es fehlt noch Trigger 41 für Sensor Peers. Trigger11 für FHEM und Trgger40 für Remotes ist fertig.
Batteriestand messen geht noch nicht. Da fehlt mir noch die zündende Idee. Soll ja möglichst universell sein und Widerstandsteiler in der Spannungszufuhr kostet zu viel Strom.

Wie möchtest du dein Modul ansteuern? Wenn nur über Fhem,  dann könnte ich dir heute Abend was schicken.

Viele Grüsse
Horst

Das mit den const schau ich mir mal an...

[gandy]

Hi Horst,

klingt fantastisch

Ansteuern per FHEM würde fürs erste schon reichen, später zoll zwar ein Bewegungsmelder den Trigger liefern ich vermute mal dass es dabei um Trigger41 geht?), aber FHEM kann gern erstmal Vermittler spielen. Bei der Gelegenheit keimt die verwegene Frage auf, ob bei einem Panstamp sowas wie Firmware-Update over-the-air denkbar ist  - aber erstmal zu den "einfachen" Dingen...  Zum Batteriestand hatte ich auch noch keine wirklich gute Idee, ist aber auch nicht höchste Priorität.

Sobald Du was hast, werd ichs gern testen!

Beste Grüße,
Andy.

[trilu]

so, mal wieder ein update.
ist noch nicht wirklich komplett und getestet. das ganze ist ein relais sketch.
hat einen channel, der als relais, bzw. schalter dient.
trigger11 sollte komplett gehen. trigger11 ist das was von fhem geschickt wird - auch die timer von fhem sollten gehen
trigger40 läuft bei mir auch, muss aber über die homematic config soft gepeert werden, es sind noch keine default werte in der list3
und ich habe nicht getestet wie sich der channel ohne default werte verhält.
trigger41, also sensoren werden noch nicht unterstützt.

ich habe als hardware nur eine led an pin 3 angeschlossen. konfigurieren lässt sich das relais mit den befehlen:
   rl[0].config(1,0,3,0,0,0);                                       // configure the relay to monostable, on pin 3
der erste wert, also die 1, gibt den channel an - in diesem beispiel ist es channel 1
der zweite wert, ob es sich um ein monostabiles oder bistabiles relais handelt, 0 steht für monostabil, 1 für bistabil
der dritte wert gibt den pin1 des relais an, der 4 wert den pin2 und so weiter

bei einem monostabilem relais kann man zwei pins zusammen schalten um das relais anzusteuern. damit kann man sich einen transistor sparen, falls die 20ma schaltstrom pro kanal nicht reichen.

bei einem bistabilen relais sind die ersten beiden ersten werte für die einschaltspule, die beiden letzten werte für die ausschaltspule.

eingestellt ist derzeit power mode 0, also kein stromsparen. power mode2 müsste aber auch funktionieren. ist aber nicht wirklich getestet.




   rl[0].setCallBack(&relayState,&hm,1,1);

[Dirk]

Hallo trilu,

Meine 3,3V / 8Mhz arduinos sind nun endlich da, und ich konnte hiermit jetzt endlich mal ein Paar Tests machen.
Das ganze funktioniert jetzt schon mal besser. Allerdings immer noch nicht ganz ohne Probleme.

Die HMLAN-Software erkennt den Taster nun, aber will einen Sicherheitscode zum anlernen, den er ja nicht haben kann.
Sehr merkwürdig.

FHEM kann nach wie vor die Register nicht auslesen. Ein getConfig bleibt unbeantwortet.
Hast du noch Ideen was ich testen / Anders machen kann / sollte.

Gruß
Dirk

[Samsi]

Hallo Dirk,

Die HMLAN-Software erkennt den Taster nun, aber will einen Sicherheitscode zum anlernen

Das ist interessant. Das liegt bestimmt daran das Du auch einen eignen AES Signierungsschlüssen in der Software gesetzt hast. Wenn ein eigener Key gesetzt ist, dann ist es ja das bestreben der HMLAN Software, den Schlüssel auf alle Geräte zu verteilen. Die Asksin Library wird aber auf dieses schreiben des Schlüssels nicht (richtig) reagieren, da nicht implementiert. Ich vermute deshalb, das die HMLAN Software deshalb denkt, es wäre schone ein anderer Schlüssel gesetzt ohne den der neue nicht akzeptiert wird.

Ich hatte so etwas ähnliches mal mit einem Problematischen Handsender der Probleme mit dem Funkmodul hat. Obwohl der Key in der Software richtig gesetzt war. Hat mich die Software manchmal nach dem Key gefragt wenn ich ihn neu anlernen wollte.

Grüße

[trilu]

@dirk - der sketch ist im power mode 4, d.h. er reagiert auf funkanfragen nicht. Das ding verhält sich wie ein hm remote. Da musst du ja auch den config taster drücken um das gerät für 20 sekunden empfangsbereit zu haben.
Du kannst aber auch im sketch den power mode auf 0 setzen. Dann ist das gerät immer empfangsbereit.

Auch wichtig ist, du brauchst einen gewissen abstand zwischen zwei geräten. Bei mir ist es ungefähr 1m...

Bezüglich des schlüssels. Die hm software geht davon aus, das alle remotes per default AES an haben. Bei der config soft musste ich in die einzelnen kanäle der remote gehen und die signierung ausschalten. Danach gings dann ohne probleme...

[Dirk]

Das liegt bestimmt daran das Du auch einen eignen AES Signierungsschlüssen in der Software gesetzt hast.

Mit Sicherheit. Währ aber gut wenn wir das fixen könnten. Ich denke es gibt einige Leute die mit eigenem Schlüssel funken.
Und die Geräteverknüpfungen (Peering) macht mir im Moment viel mehr "Spass" als im FHEM

der sketch ist im power mode 4, d.h. er reagiert auf funkanfragen nicht.

Ist klar. Daher hatte ich dann auch den Config-Taster gedrückt. Er mag dann aber immer noch nicht antworten.

Auch wichtig ist, du brauchst einen gewissen abstand zwischen zwei geräten. Bei mir ist es ungefähr 1m...

Ja, mein HM-LAN ist etwa 3-4m Luflinie entfernt.

Bezüglich des schlüssels. Die hm software geht davon aus, das alle remotes per default AES an haben. Bei der config soft musste ich in die einzelnen kanäle der remote gehen und die signierung ausschalten.

So kenne ich das auch. Aber wie abschalten, wenn der Taster noch gar nicht angelernt ist?
Oder wie meinst du das?

Gruß
Dirk

[trilu]

AES werde ich stand heute nicht implementieren koennen. Ich weiss derzeit nicht wie verschluesselt wird und was unverschluesselt im string steht.

Beim druecken vom config taster wird der pairing string gesendet. Fhem muss dann darauf antworten. Passiert das bei dir? Oder ab wann stockt die kommunikation. Teste einfach mal im powermode 0,  dann hast du zumindest kein problem das der funkchip aus wäre.
Um irgendwas zu fixen brauch ich zumindest einen anhaltspunkt wo es hakt. Bei mir funzt das pairing,  das peeren und das register lesen,  insofern kann ich auch nicht fixen...

Ich nutze die letzte version der um config soft. Zum anlernen geh ich in der config soft auf anlernen,  dann geht ein dialog auf und das ding zaehlt von 60 sekunden runter. Dann drueck ich die config taste und im log wird der pairing string gesendet,  daraufhin kommen einige Ack und config strings und im dialog fenster steht das ein neues geraet gefunden wurde...  thats it

Naechster schritt ist dann,  ich oeffne die einzelnen kanaele und nehm den haken bei aes raus.
Danach klappt dann das peeren problemlos.