Arduino Asksin library

[Jaydee]

Hi!

Ich würde auch 2 Module abnehmen.

LG
Jan

[PeterS]

Hallo trilu

Ich habe basierend auf deinem letzten Sketch (131001-2_sketch_aug05a.zip) mal versucht Ping-Pong zu spielen.
Gemäß message handling sollte das 3. Byte das Communication bit field enthalten ?!
Bei mir stehen da immer Werte >160 drin (A0=160). Was bedeuten diese ?
Das simulierte HM-Device "CUL_HM_HM_LC_Dim1PWM_CV_3FA65C_Sw" liefert beim Webcmd "on" folgenden Log:
-> 0E 1D A0 11 F1 15 02 3F A6 5C 02 01 C8 00 00 (l:15)(2313615)
Wie ist hier der Payload (C8 00 00) to interpretieren ?
Wie kann ich dem Device eine Nachricht zurückschicken ?

Gruss Peter

Available commands:
  p                - start pairing with master
  b[0] b[n] s      - send a string, b[0] is length (50 bytes max)

  i[0]. i[1]. e    - show eeprom content, i[0]. start address, i[1]. length
  i[0]. b[1] f     - write content to eeprom, i[0]. address, i[1] byte
  c                - clear eeprom complete, write 0 from start to end

  t                - gives an overview of the device configuration

  $nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer

l> 0C E0 86 70 1C C8 D1 00 00 00 00 3C 5A (l:13)(2253259)
-> 0E 1D A0 11 F1 15 02 3F A6 5C 02 01 C8 00 00 (l:15)(2313615)
l> 0C 96 86 70 1C C9 0F 00 00 00 00 AC 40 (l:13)(2402155)
l> 0C E1 86 70 1C C8 D1 00 00 00 00 3C 5A (l:13)(2418075)


01 02 03 04 05       06       07
1A 00 A2 00 3F A6 5C 00 00 00 10 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01

01   Message length indicator
Reflect the size of the message without the indicator
   
02   Message counter
One Byte counter, increased by every send message. While sending an ACK the message counter from the received message is used.

03   Communication bit field
       1   wakeup
       2   wake me up
       4   config mode (broadcast)
       8   unknown
      10   burst transmission
      20   ACK requested
      40   message from repeater
      80   message to master or message could be repeated

04   Message type; see table below

05   Source Address; 3 Byte length, identification of own device

06   Target Address; 3 Byte length, 00 00 00 means broadcast

07   Payload; max size is 20 bytes

[mmatt]

Hallo trilu,

giebts was neues ?
Hoffe nicht, dass Du das Project einstellst.

Grüsse Martin

[PeterS]

Hallo trilu

Das hoffe ich auch nicht !
Eine vernünftige Arduino library via homematic Protokoll würde neue Möglichkeiten bieten.
Multisensoren und jegliche Art der Signalerfassung (Klingelsensor, Hall- u .Ultraschallsensor, etc.) sowie der Steuerung   

Gruss Peter

[PeterS]

Hallo trilu

Die Fragen haben sich erübrigt
Durch lauschen und simulieren konnte ich diverse HM-Geräte (Temp, Sensor, etc.) nachstellen und den Payload besser verstehen.
Dein Script funktioniert wirklich gut.
Ich werde mich nun mal an deinen Sketch wagen.

Ich hoffe mal, dass noch jemand in das Library-Projekt zurückfindet

Gruss Peter

[mmatt]

Hallo PeterS

Wie kann ich dem Device eine Nachricht zurückschicken ?

Hast Du das auch hinbekommen ?
Eine Nachricht von FHEM an das Gerät zu schicken.

Ich warte noch auf meinen bestellten Arduino, sobald der da ist, werde ich mich auch mal an der Libary versuchen.

Gruss Martin

[PeterS]

Hallo mmatt

Ja, habe Senoren und Aktoren in Fhem definiert (Kopie von bestehenden mit neuer ID) und dann von Fhem bzw. per Serial Monitor aus getriggert.
Durch das Lauschen von echten Homematic-Komponenten bzw. Fenstersensor (HM-SEC-SC) kann man den Empfangsstring auch einfach noch mal abgewandelt schicken und so den Rückmeldestatus umschiessen.

Beispiel Fenstersensor (HM-SEC-SC): Sensor-ID:ABC123; HM-ID:456DEF

0C 2D A4 41 12 3A BC 45 6D EF 01 75 00 - > Rückmeldung Sensor zu
$0C $2C $A4 $41 $12 $3A $BC $45 $6D $EF $01 $74 $C8 s -> Rückmeldung ändern auf Sensor auf

Das Ergebnis macht echt Laune

Gruss Peter

[shaddi]

Hallo,

ich habe mir eben ein paar Funkmodule (MAX! Fensterkontakt ARR) bestellt und würde gerne bei der Entwicklung mitmachen.
Gibt es hier einen aktuellen Stand der Library mit dem man spielen kann?

bye,
Karl

[PeterS]

Hi shaddi

Die letzte Version von trilu ist 131001-2_sketch_aug05a.zip.
Auf dieser Basis habe ich auch getestet.

Gruss Peter

[PeterS]

Hi
Das original ELV-TRX868 Modul macht bisher auf mich noch den besten Eindruck.
Schlank und schmal:
https://github.com/ccier/openhm/wiki/Trx868

In Kombination mit einem Arduino Nano ideal.
Schade, dass man die CC1101-Module nicht über ELV beziehen kann.

Der Arduino Mini Pro wird über ein Breakout-Board versorgt und programmiert? Kostet auch wieder ein paar Euro. Dann schrumpft der Preisvorteil wieder gegenüber dem Nano:-(
http://arduino.cc/de/Main/ArduinoBoardProMini

Gruss Peter

PS: Die Arduino IDE ist auch nix für Debugger. Serial printing ist ja auch steinzeitlich

[trilu]

Hallo Zusammen,

zuerst einmal Entschuldigung für die lange Pause. Mit der neuen Forensoftware scheinen die Benachrichtigungen per Email verloren gegangen zu sein.
Klar bastle ich noch an der Lib weiter. Mein Ziel ist es ein Framework zu haben, mit dem man ähnlich Panstamp eigene Geräte für HM-Protokoll bauen kann.
Panstamp ist eigentlich eine feine Sache, leider gibt es aber keine schönen Aktoren, also Fernbedienungen und Wandschalter die dann direkt den Panstamp schalten können.

Status der China Funkmodule: Nachdem nicht annähernd 25 Stück zusammen gekommen sind, habe ich jetzt einen 5'er Pack bestellt. Sobald die da sind, bekommen die Leute die sich wegen Sammelbestellung gemeldet haben je 1 Stück zum testen. Wenn Qualität und Reichweite passt können wir ja eine neue Sammelbestellung versuchen.

Anbei gibt es einen neuen Stand der Library. Mittlerer weile funktioniert schon einiges
Ich versuche mal zusammen zu fassen was geht:

Der Sketch ist derzeit als Dimmer konfiguriert. Er lässt sich mit FHEM pairen. Peeren über die FHEM Oberfläche mit HM Aktoren funktioniert auch. Pair und peers werden im EEprom gespeichert und sind nach dem nächsten Start auch wieder vorhanden. Ich schreibe ein Magic Byte in den EEprom, anhand dessen erkenne ich beim nächsten starten ob der EEprom bereits richtig beschrieben ist. Beim ersten Start wird der EEprom mit 00 gefüllt.
Über die serielle Konsole kann man durch Eingabe eines 'r' <Return> das MagicByte löschen und einen Reset ausführen.

Zusätzlich könnt ihr euch den EEprom anzeigen lassen. Komplett anzeigen geht mit 'e' <Return>. Einzelne Bereiche mit Addresse '280.' (der Punkt nach der Addresse zeigt an das es ein 16bit Wert ist), Länge '10.' und 'e'. Z.b. <280. 10. e>  zeigt 10 Byte ab Adresse 280 an.
Schreiben geht mit  'f'. z.b. <100. 255 f> schreibt das Byte 255 an Adresse 100 im EEprom.
Mit 'c' kann man den kompletten EEprom mit 00 voll schreiben.

Ein 'p' <Return> an der seriellen Konsole startet das Pairen mit FHEM. Die PairID wird dann in den EEprom geschrieben und fort an ist das Gerät gepaired.

Wenn ihr Strings versenden wollt dann geht das mit 's' <Return>. Ihr könnt auch an die eigene Addresse versenden - hier geht dann die Message nicht durch das Funkmodul sondern direkt in den Empangs Puffer. Ist ganz praktisch zum testen eigener Funktionen.

Anfordern der Config und der Peers aus FHEM läuft auch (nach dem pairen auf getConfig in FHEM drücken). Die Anfrage wird aus dem EEprom beantwortet. Eingetragene peers und die dazugehörigen List3'en werden ausgelesen und übertragen.

Was noch nicht geht und als nächstes dran kommt sind die Status Messages. Also automatisches versenden nach einer Änderung, oder auf Anforderung durch die Zentrale.

Die Library besteht aus 4 files:

sketch_aug05a.ino ist der Userbereich. Hier kann man die gerätespezifischen Funktionen programmieren.

register.h ist der Config Bereich, im oberen Teil sind die Variablen für Seriennummer usw. Im unteren Teil kommen die Register Definitionen rein. Also die Config für List0, List1 usw.
Martin hat hier ein klasse Config Tool in Perl gebastelt. Aber dazu wird er hoffentlich bald mehr erzählen
Für später heisst das - die Gerätedefinition wird in dem Tool gemacht, der Output in die register.h kopiert und gut. 

asksin.cpp und asksin.h, das ist der HM Kommunikations Bereich. Jegliches HM Handling soll hier statt finden und kein User Eingreifen benötigen.

So jetzt aber zum Userbereich:
Im Userbereich (das ist sketch_aug05a.ino) - gibt es einen "s_jumpTable jumpTable[]", hier werden die Funktionen angegeben die beim erreichen eines HM Events aufgerufen werden. Das Format für diesen Table ist  "{ 0x40, HM_Remote_Event  },".
40 steht für die Art des Events, 'HM_Remote_Event' ist der Name der Funktion in "sketch_aug05a.ino" die aufgerufen wird. Hier werden dann auch Channel und Daten übergeben.

Die List0 und List1 je Channel stehen im Userbereich in der Variablen 'regMC' zur Verfügung. Im der aktuellen Beispiel Config gibt es zwei Channels, somit gibt es in der regMC folgende Variablen:

regMC.ch0.intKeyVisib
regMC.ch0.pairCentral
regMC.ch1.intKeyVisib
regMC.ch2.intKeyVisib

Die genaue Config könnt ihr euch in der register.h anschauen, da sind die structs definiert.
Dann gibt es eine struct für die List3'en. Das sind die Variablen die man braucht wenn ein Ereignis über ein Peer ausgelöst wird.
Diese struct heisst 'regL3', besteht in unserem Beispiel aus zwei Channeln die unterschiedlichen Inhalt haben können. Im aktuellen Beispiel ist der Inhalt aber gleich.

regL3.ch1
regL3.ch2

Dahinter sind dann die ganzen Variablen pro Peer. Den genauen Inhalt könnt ihr euch in der register.h in der struct "s_peer_regChan" anschauen.
Das struct wird aber nur befüllt wenn ein Event über ein peer ausgelöst wird. Deshalb empfehle ich die Variablen nur in den Funktionen im "jumpTable" definiert, zu benutzen.

Was fehlt noch - ausgiebige Tests
Statusmessages
Powermanagement
Lib als Aktor konfigurieren und die List4 im Userbereich zur Verfügung stellen.
Verknüpfung der Gerätespezifischen Variablen mit Aktionen in der asksin.cpp

Ach ja, fast vergessen. Ihr findet ganz oben in der register.h 4 Variablen für das debuggen.
//#define CC_DBG;         // debug messages of the CC module, ~0.2k program space
//#define SM_DBG;         // debug messages of the SM module, ~1k program space
#define AS_DBG;         // debug messages of the HM module, ~0.6k program space
//#define AS_DBG_Explain;   // debug messages of the HM module, ~5k program space

Wenn ihr die einschaltet bekommt ihr jede Menge Infos auf die serielle Konsole.
CC = Funkmodul
SM = Storage Management, ein Schelm wem was Anderes dazu einfällt
AS = Asksin oder eben HM Protokoll
AS Explain = zeigt eine Beschreibung der Binär Strings an

Viel Spass beim testen. Falls Fehler, oder Fragen nur her damit. Falls Programm Verbesserungen auch gern gesehen!!!!!

[PeterS]

Hallo trilu

Danke für die ausfürliche Beschreibung und für die neue lib.
Die Details muss man natürlich erst einmal komplett verinnerlichen und verstehen 

Werde mal weitertesten und berichten !!

PS: Bitte ergänze noch den Helptext (f,r, etc.) in der nächsten Version.

Gruss Peter

[unimatrix]

Hi,

habe diesen Thread heute erst gefunden. Wenn ich das hier richtig lese, dann müsste ich ja zu einer bestehenden SChaltung mit einem ATMega32 (Puppenhaus mit 6 dimmbaren LED-Leuchten, einer Kaminfeuer LED mit Flimmereffekt, und einer Türklinkel (über Transistor angesteuert)) ein Tranceiver-Modul hinzufügen können und dann noch die Lib und einige Funktionen dafür einbauen können.

Ist allerdings batteriebetrieben mit 3 AA Batterien. Mit meiner jetzigen Software halten die Batterien 2-3 Jahre, zumal sich die Lichter bei Nichtnutzung ja abschalten und der Controller dann in so ein Deep Standby geht. Das dürfte wohl dann so nicht mehr gehen. Man bräuchte so ein Verhalten ähnlich der Thermostate mit Aufwach / Burst Modus.

Nun das nur gedanken...freue mich dass es so ein Projekt gibt. Werde mir das im Detail durchlesen!

VG

[trilu]

Hi unimatrix,
Zu deiner Frage, ein ganz klares Jein.
ATMega 32 dürfte zu klein sein. Die Lib braucht im Moment etwa 15 k Flash und etwa 1k Ram.
Das Powermanagement ist noch nicht implementiert, aber ich habe schon ein wenig getestet.
Der Arduino zieht etwa 3ma wenn er läuft, das Funkmodul etwa 17ma. Sind 20ma. Damit ist deine Batterie vermutlich in 1 oder 2 Tagen leer.
Ich möchte einen Mode für Batteriebetrieb implementieren der über den Watchdog läuft. Bei Nichtbenutzung gehen dann der Atmel und das Funkmodul in einen Tiefschlaf mit einigen uA. Wachen aber alle 300 ms wieder auf. Ziehen dann für einige ms etwa 20ma, wenn in der Zeit keine Übertragung rein kommt, dann wird weiter geschlafen. Damit dürfte eine Batterie dann auch ziemlich lange halten.
Viele Grüsse
Horst

[PeterS]

Hallo trilu

Anbei ein paar Feedbacks:
- Der Befehl r (reset Device) führt bei mir nur zu einem lang (=unendlich) blinken der LED13
- Das HM Event (z.B. 0x40) ist das das Communication bit field oder der Messagetype ? Oder was ganz anderes Habe mal die Source auf Rückmeldungen meiner Geräte (xx86, xx70 ) umgeschossen. Leider ohne Log-Erfolg.
- SetSleep und SetWakeup funktioniert schon mal ganz gut.

PS: Hat schon mal jemand gelauscht, wenn HM-Geräte via AES-Key kommunizieren ?

Gruss Peter