Arduino Asksin library

[trilu]

super!
falls möglich - einer fernbedienung/schalter und einem schaltgerät
wobei schaltgerät prio hat...

[PeterS]

Hallo trilu
Das Einschalten von #define AS_DBG_Explain brachte die erwünschten Debug-Messages. Funktioniert !!
Sorry hatte wohl in deiner Ausführung überlesen, dass man es erst aktivieren muss 
Allerdings werden die s_jumpTable z.B HM_Weather_Event im sketch nicht ausgeführt?!

Der Eintrag paired ist nun komischerweise auch gefüllt !

Gruss Peter

[trilu]

und wieder mal ein update...

die library sollte jetzt stabiler laufen da ich den code ein wenig aufgeräumt habe.
pair und peer geht
config request und status request von der zentrale werden beantwortet
settings werden ins eeprom geschrieben und stehen im user bereich zur verfügung (ist aber noch baustelle)
peer events stehen im user bereich zur verfügung

der jumptable im userbereich hat jetzt nicht nur die events, also sowas wie die benachrichtigung das von
einer fernbedienung die taste gedrückt wurde, sondern auch für den status request der zentrale
und für alle kommandos die von der zentrale an ein device gesendet werden können.

was noch fehlt ist das power management und die funktionen um als aktuator konfiguriert zu werden....

viele grüße
horst

ps: bin gerade ganz begeistert - wenn man debug ausschaltet und den serial parser auch weglässt dann braucht
die lib 13,4k im arduino - also 43% belegt! es bleibt also jede menge platz für eigene sachen!

[mmatt]

Danke Dir trilu,

Hab gerade das Update auf meinen arduino gespielt.
Pair mit Fhem hat problemlos geklappt.
Auch der Status Request von Fhem funtioniert.

Auch ich bin begeistert

Hab gerade etwas wenig Zeit, um weiter zu testen.
Bleibe aber in jedem Fall drann.

Grüsse Martin

[trilu]

Ich glaube ich weiss jetzt wie der Burst Mode funktioniert. Laut den culw Sourcen wird für das Senden im Burst Mode nur umgeschalten in den TX Mode und 360 ms gewartet.
Der Wake on Radio Mode des CC1101 scheint aber anders zu funktionieren. Hier wird einach alle paar ms aufgewacht und gewartet das die Preamble Bits kommen. Falls nicht, geht der Chip wieder in Idle.

Die Lösung des Problems, ich schalte den CC1101 einfach aus, warte 250 ms, schalte ihn ein, gehe in den RX Mode und prüfe auf ein Carier Signal. Ist keins da, lege ich den Chip wieder schlafen. Ist eins da, dann lasse ich den Chip für eine definierte Zeit wach und lege ihn dann wieder schlafen....

Für den Stromverbrauch ist das eine prima Sache. Im RX Mode braucht der CC1101 etwa 17 ma. In Power down sind es einige wenige ua. Das lauschen dauert 5ms alle 250ms, folglich brauchen wir nur 2% der Zeit die 17ma.
Rechnerrisch müsste ich den Stromverbrauch auf 350 ua im Idle mode reduzieren können. Das würde für den Batteriebetrieb absolut passen.
Weiter reduzieren ist auch noch möglich durch verlängern der Idle azeit. Aber hier muss ich noch testen wie lange der HM Lan den Burst sendet...

[PeterS]

Hallo trilu

Wann wird die s_jumptable jumptable Aktion (z.B. void HM_Weather_Event) im sketch getriggert?
Der #define AS_DBG_Explain triggert die entsprechende Routinen (z.B. 0x70) im AskSin.cpp.

Im Sketch bekomme ich diese einfach nicht aufgerufen ?!

Bitte gib mir mal einen neuen Insidertip 

Gruss Peter

[trilu]

Die Funktionen im jumptable werden immer dann aufgerufen wenn ein entsprechender String empfangen wird. Die Events sind alle den Peers zugeordnet. Der Weather Event kann also nur getriggert werden wenn dein Device mit einem Sensor gepeert ist, der einen Weather Event sendet.

AS_DBG und AS_DBG_Explain triggert nichts. Das sind Variablen um Debugmeldungen einzuschalten. Wenn AS_DBG definiert ist dann wird die Funkkommunikation an der seriellen Konsole angezeigt. AS_DBG_Explain zeigt zusätzlich die Erklärung zu den Byte Strings der Funkkommunikation.

[Dirk]

Hi trilu,

ich habe zwar nur ein Logicanalyzer, aber ich meine die Software kann auch SPI decodieren.

Ich habe die mal was mitgeschnitten und per PM geschickt.

Gruß
Dirk

[mmatt]

Hallo trilu

Wie du beschrieben hast ist dein Sketch (über die register.h) als Dimmer konfigurtiert.
Wenn das device mit fhem gepairt ist, wird das device durch fhem auch angelegt.
Wenn ich nun ein "on" oder "off" von fhem sende, wird das über die Serielle Konsole von der Arduino IDE ausegeben.

Wo kann ich nun das "on" oder "off" abgreifen und für meine eigene Anwendung weiterverwenden ?
Wenn ich das richtig verstanden habe, werden die Funktionen der "jumptable" ja nur aufgerufen, wenn das device mit irgendwas gepeert ist.

Vielleicht hast Du ein kleines Beispiel.
Vielleicht bin ich mit meinem Wunsch auch etwas zu früh, dann einfach diesen Post ignorieren.

Grüsse Martin

[trilu]

ok, ok, - der jumptable scheint nicht wirklich selbsterklärend zu sein

Code Auswählen Erweitern

s_jumptable jumptable[] PROGMEM = { // jump table for HM communication
{ 0x01, 0x0E, HM_Status_Request },

{ 0x11, 0x02, HM_Set_Cmd },
{ 0x11, 0x03, HM_StopChange_Cmd },
{ 0x11, 0x04, HM_Reset_Cmd },
{ 0x11, 0x80, HM_Led_Cmd },
{ 0x11, 0x81, HM_Level_Cmd },
{ 0x11, 0x82, HM_SleepMode_Cmd },

{ 0x12, 0x00, HM_HaveData_Event  },
{ 0x3E, 0x00, HM_Switch_Event  },
{ 0x3F, 0x00, HM_TimeStamp_Event  },
{ 0x40, 0x00, HM_Remote_Event  },
{ 0x41, 0x00, HM_Sensor_Event  },
{ 0x53, 0x00, HM_Sensor_Data   },
{ 0x58, 0x00, HM_Climate_Event },
{ 0x70, 0x00, HM_Weather_Event },

{ 0x0 }
};

Derzeit gibt es drei verschiedene Kategorien im jumptable:
1 - der Statusrequest
2 - die Commands
3 - die Events

1. Statusrequest:
Ein Statusrequest kann nur von der Zentrale angefragt werden, also dem Pair.
Beantwortet wird er mit einem INFO_ACTUATOR_STATUS. Das ist die selbe Message die man auch proaktiv, nach dem Einschalten, oder nach einer Statusänderung des Devices senden muss.

Die jump - Funktion findest du in "sketch_aug05a.ino" als Funktion "void HM_Status_Request(uint8_t cnl, uint8_t *data, uint8_t len)".
Also, wenn du in FHEM Status request drückst, dann wird diese Funktion angesprungen, der Channel und die Statusdaten übergeben.

In der Funktion habe ich eine Status message drin

Code Auswählen Erweitern

Serial << F("\nStatus_Request; cnl: ") << pHex(cnl) << F(", data: ") << pHex(data,len) << "\n\n";

Vor, oder nach dieser Zeile kannst du deinen eigenen Code platzieren.
In dieser Funktion muss der eigene Status dann gesendet werden, das passiert mit dem Aufrufen der Funktion:
   hm.sendInfoActuatorStatus(cnl, status);
cnl: ist der Channel
status ist ein byte Wert, mehr Info kann über diese Funktion nicht transportiert werden.


2. Commands
Die Commands können nur von der Zentrale an unser Device gesendet werden. Z.b. wird die Funktion "HM_Set_Cmd " angesprungen wenn du in FHEM auf "toogle,on,off,up,down" drückst. Übergeben wird an die Funktion der Channel und der Statuswert.
Die Funktion findest du auch wieder in "sketch_aug05a.ino" als Funktion "void HM_Set_Cmd(uint8_t cnl, uint8_t *data, uint8_t len)".
Als Antwort auf alle Commands wird ein erweiterter ACK verwendet, der die Statusinformation enthält.
   hm.sendACKStatus(cnl,  status, douplo);
Ich habe das als Beispiel schon mal in die Funktion gepackt.

3. Events
Die Events werden nur von den Peers gesendet. Wen eine Remote oder ein Switch mit unserem Device gepeert ist und eine Taste gedrückt wird, dann bekommen wir einen "HM_Switch_Event". Die zugehörige Funktion findest du in "sketch_aug05a.ino" als Funktion "void HM_Switch_Event(uint8_t cnl, uint8_t *data, uint8_t len)".
Übergeben wird hier auch wieder der Channel und die gesendeten Daten. Bei einem Switch Event wird normalerweise der Channel des Peers als low byte übergeben. High byte enthält die Info ob es ein Tastendruck oder ein Langer Tastendruck war.
Antwort muss der User bei Events keine schicken, da die Message nur einen ACK erfordert und ich diesen automatisch sende.


Vom Grundsatz ist der Sketch so aufgebaut, das in Register.h die gerätespezifischen Sachen kommen, also die Register Definition.
Asksin.cpp und Asksin.h machen die Kommunikation im HM Netz, kein Usereingriff notwendig.
Das Programmieren der Device Funktionen findet in "sketch_aug05a.ino", also dem Userbereich statt.

Alles klar soweit?

Viele Grüße
Horst

[Rohan]

Hallo Horst aka trilu,

ich habe mit großem Interesse diesen Thread durchgelesen und möchte schon jetzt in dieses Projekt einsteigen um Erfahrungen sammeln.

Im Moment scheitere ich etwas an der Hardware. Die HM-TRX868 Module habe ich (aus 2 Bausätzen), aber nur ein Arduino Leonardo Board. Da scheitere ich schon an der zum Arduino Uno und Pro Mini anderen Pin-Belegung (INT0 und 1 vertauscht, die MOSI/MISO-Pins nur am 6-poligen Anschluss). Einen Arduino Micro habe ich auch noch hier, den wollte ich mir mal Heute Abend angucken.

In deinem Code habe ich mal nachgeschaut und auch die Stellen gefunden, wo die Port/Pin-Definitionen stehen, aber das sind ein wenig böhmische Dörfer für mich.

Könnten die Port/Pin-Definitionen statt an unterschiedlichen Stellen nicht besser an einem zentralen Ort stehen?
Wäre es möglich, diese je nach verwendetem Arduino-Board per

Code Auswählen Erweitern


#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
# Port=
# PIN=
#elif defined(__AVR_ATmega328P__)
# Port=
# PIN=
#endif


zu belegen bzw. kompilieren zu lassen?

Danke und Gruß
Thomas

[shaddi]

@Rohan: beachte auch, dass das TRX-Modul nur 3,3 Volt beherrscht! Wenn du da mit einem 5-Volt Arduino ankommst, grillst du wahrscheinlich das Teil!

[trilu]

Ich habe auch schon über die Flexibilisierung der HW nachgedacht, ist aber auf der Prio Liste erst mal nach hinten gerutscht.
Ist einfach eine lästige Arbeit die verschiedenen Pinbelegungen zu vergleichen

Es gibt derzeit zwei Stellen im Code an denen HW definiert wird - beide male in der Asksin.h
In der Class Definition CC die zusätzlichen Angaben zur Kommunikation über SPI

Code Auswählen Erweitern

// Hardware definition
#define PORT_SPI_MISO     PINB
#define BIT_SPI_MISO        4
#define PORT_SPI_SS         PORTB
#define BIT_SPI_SS            2
#define GDO0                     2


In der Class Definition HM die Angaben zum Interrupt 0, oder Pin 2

Code Auswählen Erweitern

// hardware definition for interrupt handling
#define GDO0                2
#define PORT_GDO0      PIND
#define BIT_GDO0         2
#define INT_GDO0         0


Ich sehe gerade, der Leonardo benutzt eine ATmega32u4 CPU mit 5 Volt. Das heisst du musst Level Converter zwischen Funkmodul und  CPU basteln, sonst grillst du das Funkmodul. Die Funkmodule vertragen nur eine Spannung zwischen 1,8 und 3,6 Volt.

Die Anpassung der HW Pins bekommst du allein durch den Vergleich der Datenblätter hin, ist wie gesagt, eine Fleißarbeit.

Viele Grüße
Horst 

[Rohan]

Hallo shaddi,
hallo Horst,

Eure Warnungen kommen wohl leider zu spät (aber die waren ja schon im Thread gewesen), denn ich habe noch einen UNO gefunden. Ich habe nicht dran gedacht, dass ja nicht nur die Stromversorgung 3,3 V (die ja die 5V Arduinos alle bieten) max. betragen sollte, sondern wohl auch die Spannungen auf den Signal-/Daten-/IO-Leitungen 

Egal, Lehrgeld bezahlt (werde das Modul aber dennoch mal im Bausatz testen) ... Weiter geht's 

Und bevor ich jetzt mit Level Convertern anfange, besorge ich mir lieber doch ein paar 3,3 V Mini-Pros 

Gruß
Thomas

Edit:
Nachtrag: Das HM-TRX868 Modul hat keinen Schaden genommen. Testaufbau mit dem Bausatz funktionierte in Sende- und Empfangsrichtung
Es bleibt aber dabei: 3,3 V Arduinos müssen ran.

[mmatt]

Hallo trilu,

vielen Dank für die genaue Bechreibung der jumptable.
Ob alles klar ist, denke nicht ganz alles, aber das liegt an mir

Hab gerade ne LED auf dem arduino über fhem ein und ausgeschaltet.
Geil

Grüsse Martin