Arduino Asksin library

[mmatt]

Danke für die Antwort,
bin immer noch am grübeln...

Um ein Magnetventil zu schalten, breuchte ich Impulse mit bekannter Länge auf zwei weiteren Digitalen-Pins.
Ich dachte, ich könne den HM-LC-SW1-BA-PCB Sketch schnell etwas umschreiben.

Aber ohne die Funktion "HM_Set_Cmd" weiss ich nicht so recht wie ich das anstellen soll.
Irendwie müssete folgender Code an der richtigen Stelle noch rein.

Einschalten:

Code Auswählen Erweitern

digitalWrite(14,LOW);
digitalWrite(15,HIGH);
delay(250);
digitalWrite(14,LOW);
digitalWrite(15,LOW);


Ausschalten:

Code Auswählen Erweitern

digitalWrite(14,HIGH);   
digitalWrite(15,LOW);
delay(65);
digitalWrite(14,LOW);
digitalWrite(15LOW);


Kannst Du mir da weiterhelfen ?

Grüsse Martin

[trilu]

du möchtest aber nicht die pins parallel schalten?
das würde ich dir zumindest nicht empfehlen, ich hatte mit sowas auch mal experimentiert.
das problem ist, du produzierst einen kurzschluss für einige micro sekunden.

nehmen wir an du hast zwei pins - sagen wir 4 und 5.
im ausgangszustand sind beide pins auf low. jetzt schaltest du pin 4 auf high, damit fliesst jetzt strom zwischen
pin4 high und pin5 low. wenn du jetzt auf high ohne pullup geschaltet hast, dann sind das jetzt 20-30ma die da fliessen.

ich habe in der relay class einen bistabilen modus bereits vorgesehen, schau einfach mal rein...
   relay[0].regInHM(1,&hm);                                             // register relay class in HM to respective channel   
   relay[0].config(0,3,0,5,5);                                             // configure the relay to monostable, therefore only one HW pin needed

der erste config parameter gibt den modus an - 0 ist monostabil, 1 ist bistabil
der nächste parameter, also die 3 gibt den ersten pin an, bei bistabil also den einschalt pin.
dritter parameter ist bei bistabil der ausschaltpin.
die beiden hinteren parameter geben das timing für die messages vor, daran musst du nichts ändern.

falls du, so wie ich glaube, das ventil über die polung, bzw. flussrichtung schaltest, dann kannst du dir das in den relay sketch einbauen.

Code Auswählen Erweitern

void MyClassName::adjRly(uint8_t tValue) {
if (curStat == nxtStat) return; // nothing to do
if (hwType == 0) { // monostable - on
if (hwPin[0] > 0) digitalWrite(hwPin[0],tValue); // write the state to the port pin

} else if ((hwType == 1) && (tValue == 1)) { // bistable - on
if (hwPin[0] > 0) digitalWrite(hwPin[0],1); // port pin to on
delay(50); // wait a short time
if (hwPin[0] > 0) digitalWrite(hwPin[0],0); // port pin to off again

} else if ((hwType == 1) && (tValue == 0)) { // bistable - off
if (hwPin[1] > 0) digitalWrite(hwPin[2],1); // port pin to on
delay(50); // wait a short time
if (hwPin[1] > 0) digitalWrite(hwPin[2],0); // port pin to off again
}


reicht dir die beschreibung so?

[mmatt]

Hallo trilu,
nein die Pins möchte ich nicht paralell schalten.
Ja, das Ventil wird über die Polung geschaltet.

Das mit dem bistabilen Modus, tönt doch ganz gut
Das heisst für mich, ich müsste "nur" die gepostete Funktion "adjRly(uint8_t tValue)" in der Relais-Klasse etwas umbauen.

Gruss Martin

[trilu]

Ja, genau. Wenn du willst kannst du ja einen neuen modus ins relay basteln. ...

[mmatt]

ok, werd ich versuchen.
Danke Dir trilu.

Grüsse Martin

[trilu]

@Dirk
Ich habe die Sensoren gestern bekommen und den SHT10 gleich mal auf Lochraster gelötet.
Die Lötpads sind echt klein )))

Musste dann auch gleich mal einbinden und erste Versuche starten:

Code Auswählen Erweitern

Temperature = 19.86 C, Humidity = 54.36 %, Dewpoint = 10.38 C
Temperature = 19.82 C, Humidity = 53.86 %, Dewpoint = 10.20 C
Temperature = 19.78 C, Humidity = 52.86 %, Dewpoint = 9.88 C
Temperature = 19.74 C, Humidity = 53.36 %, Dewpoint = 9.98 C
Temperature = 19.70 C, Humidity = 52.36 %, Dewpoint = 9.66 C
Temperature = 19.70 C, Humidity = 51.86 %, Dewpoint = 9.52 C
Temperature = 19.66 C, Humidity = 52.85 %, Dewpoint = 9.77 C
Temperature = 19.66 C, Humidity = 51.85 %, Dewpoint = 9.48 C
Temperature = 19.62 C, Humidity = 51.85 %, Dewpoint = 9.44 C
Temperature = 19.58 C, Humidity = 51.84 %, Dewpoint = 9.41 C
Temperature = 19.58 C, Humidity = 51.84 %, Dewpoint = 9.41 C
Temperature = 19.58 C, Humidity = 51.34 %, Dewpoint = 9.26 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.46 C, Humidity = 50.33 %, Dewpoint = 8.85 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.46 C, Humidity = 49.82 %, Dewpoint = 8.71 C
Temperature = 19.46 C, Humidity = 49.82 %, Dewpoint = 8.71 C

Sensor läuft schon mal, jetzt muss er nur noch ins Class Modul und das PowerManagement muss
getestet werden. Der nächste Sensor wird dann der Luftdruck...
Danke noch einmal für die Sensoren!

Viele Grüße
Horst

[Dirk]

Sensor läuft schon mal, jetzt muss er nur noch ins Class Modul und das PowerManagement muss
getestet werden.

Sehr schön.

Der nächste Sensor wird dann der Luftdruck...

Da kannst du in das Modul "51_I2C_BMP180.pm" schauen.
Da hab ich den Code schon mal geschrieben. Ist halt Perl. Sollte aber einfach sein das nach C++ zu portieren.

Gruß
Dirk

[trilu]

SHT10 ist eingebunden, anbei ein Update der lib.
Beispielsketch ist zu finden unter Examples/HM_WDS10_TH_O

Der Sketch emuliert den Außensensor mit Temperatur und Luftfeuchte.
Timing sollte auch für die Verknüpfung mit dem Heizkörperregler passen. Im Beispiel ist der Datenpin des SHT10 auf pin 7,
der Clock Pin liegt auf pin9.
Einstellen lässt sich das ganze über sht10.config(7,9,0);
Der letzte Wert ist das Timing - eine 0 heisst, es wird die interne Timing Funktion verwendet, die das Timing aus Message ID
und HM ID berechnet. Falls ihhr ein eigenes Timing nutzen wollt, so könnt ihr einen x-beliebigen Millisekundenwert eintragen.

Ich werde mich in den nächsten Tagen ran setzen und versuchen eine WDC7000 nachzubilden. Hier wird es dann auch den Luftdruck geben...

Code Auswählen Erweitern

<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(2064)
<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(2766)
<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(3467)
-> NA (4165)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(168814)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(169517)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(170217)
-> NA (170915)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(301565)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(302268)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(302968)
-> NA (303667)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(483815)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(484517)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(485218)
-> NA (485916)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(651819)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(652519)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(653219)
-> NA (653918)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(805318)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(806019)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(806719)
-> NA (807417)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(944318)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(945018)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(945719)
-> NA (946417)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1069068)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1069768)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1070469)
-> NA (1071167)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1243318)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1244018)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1244719)
-> NA (1245417)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1403068)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1403768)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1404469)
-> NA (1405167)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1548318)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1549019)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1549719)
-> NA (1550417)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1679319)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1680019)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1680719)
-> NA (1681418)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1859817)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1860519)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1861220)
-> NA (1861918)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2025820)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2026520)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2027220)
-> NA (2027919)
So sehen die Messages des neuen Moduls aus. Ein Update im Git mache ich dann heute Abend...

Viele Grüße
Horst

[sebixvi]

Hallo zusammen,

auch ich lese hier sehr interessiert mit und bin begeistert, wie weit das Projekt ist.

Mein Ziel ist es derzeit, mit den RFM22b-Modulen Homematic zu sprechen, um günstig µC-Projekte mit fhem/Homematic verheiraten zu können. Die Hürde, dass die RFM22-Module eine etwas andere Ansteuerung benötigen, habe ich inzwischen genommen und kann sie zumindest zum Mitlesen und dekodieren der Nachrichten benutzen. Kompatible Nachrichten senden ist der nächste Schritt.

Volle HM-Kompatibilität (alle Channels, zig Peer-Möglichkeiten) ist mir nicht so wichtig, möglichst kleine Controller dagegen schon. Mich macht derzeit hier die Code-Größe von ca. 6-8k stutzig. Bringt Arduino so viel Overhead mit, oder sind es die Debugging-Ausgaben? Mein Code hat derzeit ca. 2k, davon ist allerdings 50% Debugging (usart, einige Strings, alle möglichen Ausgaben per serieller Schnittstelle). Wenn ich alle usart-Ausgaben entferne komme ich auf 1k (Daten in struct einlesen, Adresse vergleichen, msg-type & 0x80 sowie Payload-Byte 2 auf 0xc8 prüfen und dann LED einschalten). Mit rudimentärem Pairing und Ack-Handling sollten knapp 2k drin sein.

Ideal fände ich, ggfls. sogar die kleinen 8-beinigen Tinys verwenden zu können, die haben allerdings max. 8k Speicher (und 256 Bytes sram ) Für einen einfachen Ein-Aus-Schalter, der sich auch am Gerät bedienen lässt, gleichzeitig aber auch per fhem steuerbar ist, sollte es reichen.

Hat jemand eine Ahnung, wie klein die Arduino-Codebase zu bekommen wäre? Kann man die Projekte ggfls. zusammenführen?

Sebastian

[trilu]

Hi Sebastian,
Herzlich willkommen.
Um ehrlich zu sein,  ich habe keine Ahnung warum der Code mittlererweile so gross ist.  Ich habe ziemlich genau vor einem Jahr mit den Arduinos und C++ begonnen. Die Debug Strings brauchen schon eine Menge Flash,  aber selbst wenn ich die abschalte bleibt eine Menge Code übrig. Aber das selbe Problem hat HM wohl auch,  sonst würden sie nicht einen 644 einsetzen 
Die beiden Projekte zusammen fahren sollte aber einfach sein,  ich habe versucht die Lib so flexibel wie Möglich aufzubauen.  Für die Kommunikation mit dem Funkmodul gibt es eine eigene Klasse,  das ist die CC1101.h/cpp.  Da drin sind alle relevanten Funktionen zur Ansteuerung des Funkmoduls.

Es gibt im wesentlichen drei Funktionen die du von aussen zugänglich machen musst.
.init -  wird von HM.init aufgerufen um das Modul zu initialisieren.
.send - das ist die Funktion um codierte Strings zum senden zu übergeben.
.recv - hier wird HM signalisiert,  das ein String im Empfangsbuffer liegt

Ich suche später noch einmal genau nach den Funktionen und stell sie hier rein.
Zur Einbindung in das Framework würde es dann reichen einfach ein Flag zu setzen und es wird die entsprechende HW ausgewählt.

Die Register und Kommunikationsfunktionen liegen dann alle in der AskSinMain.h/cpp und müssten 1:1 funktionieren.
Wenn du willst,  schalte ich dich dann für den git frei.  Darfst auch gerne an der AskSin Code und Grösse optimieren.

Attiny halte ich für fast ausgeschlossen,  für Peers,  etc braucht es einfach ein wenig eeprom Speicher. Der Vorteil von HM ist ja,  das die Geräte nicht über eine Zentrale reden müssen,  sondern direkt kommunizieren können.  Um das variabel zu halten und bequem über eine Software konfigurieren zu können,  braucht es einen gewissen Protokolloverhead.

Viele Grüsse
Horst

Edit: So gerade noch einmal nachgeschaut - wir brüchten eine rm22 class mit folgenden Funktionen:

Code Auswählen Erweitern

void    config(uint8_t csP, uint8_t mosiP, uint8_t misoP, uint8_t sckP, uint8_t gdo0P, uint8_t int_gdo0); // set the respective pins
hier wird letztendlich nur Konfiguriert - Die Funktion wird vom Main Sketch aufgerufen, du bist also frei welche Parameter du übergeben möchtest.

Code Auswählen Erweitern

void    init(); // initialize CC1101
Wie weiter oben beschrieben. Wird von hm.init aufgerufen.

Code Auswählen Erweitern

uint8_t sendData(uint8_t *buf, uint8_t burst); // send data packet via RF
Wird von HM aufgerufen um codierte Strings zu senden. Codier Routine ist in HM. Burst ist 0 oder 1 und schaltet einfach nur das Sendemodul für 250ms ein.
Ist notwendig um mit Devices, die im Standby sind, zu sprechen. Wenn Burst0, dann Sende Teil einschalten und String sofort in den Sendebuffer des Moduls schreiben.

Code Auswählen Erweitern

uint8_t receiveData(uint8_t *buf); // read data packet from RX FIFO
Funktion um den Empfangsbuffer des Funkmoduls auszulesen und in den übergebenen Buffer zu schreiben.

Das etwas empfangen wurde, wir in der AskSinLib derzeit über Interrupt 0 and Pin2 signalisiert, ich weiss nicht, ob dein Funkmodul das kann?
Schau mal nach und sag Bescheid. Wie gesagt, es würde mich freuen, wenn wir weitere Funkmodule mit in die Lib integrieren könnten.
Und Mitstreiter zur Code Optimierung sind auch herzlich Willkommen....

[sebixvi]

Moin trilu,

Hi Sebastian,
Herzlich willkommen.
Um ehrlich zu sein,  ich habe keine Ahnung warum der Code mittlererweile so gross ist.  Ich habe ziemlich genau vor einem Jahr mit den Arduinos und C++ begonnen. Die Debug Strings brauchen schon eine Menge Flash,  aber selbst wenn ich die abschalte bleibt eine Menge Code übrig. Aber das selbe Problem hat HM wohl auch,  sonst würden sie nicht einen 644 einsetzen 
Die beiden Projekte zusammen fahren sollte aber einfach sein,  ich habe versucht die Lib so flexibel wie Möglich aufzubauen.  Für die Kommunikation mit dem Funkmodul gibt es eine eigene Klasse,  das ist die CC1101.h/cpp.  Da drin sind alle relevanten Funktionen zur Ansteuerung des Funkmoduls.

Dass ELV/eQ3 überall Megas einsetzen, ist mir bekannt. Im 1-Kanal-Bausatz ist ein Mega328 drin, allerdings ist der im TFQP32 mit 0,8mm Pinabstand schon ziemlich fummelig zu löten. Die 8-beinigen Tinys mit 1,27mm lassen sich dagegen wunderbar verbauen (wobei die nur mit HVSP sinnvoll einzusetzen sind, damit man den RESET-Pin als I/O benutzen kann, sonst wird´s etwas knapp mit Ein-/Ausgängen).

Es gibt im wesentlichen drei Funktionen die du von aussen zugänglich machen musst.
.init -  wird von HM.init aufgerufen um das Modul zu initialisieren.
.send - das ist die Funktion um codierte Strings zum senden zu übergeben.
.recv - hier wird HM signalisiert,  das ein String im Empfangsbuffer liegt

Ich suche später noch einmal genau nach den Funktionen und stell sie hier rein.
Zur Einbindung in das Framework würde es dann reichen einfach ein Flag zu setzen und es wird die entsprechende HW ausgewählt.

Die Register und Kommunikationsfunktionen liegen dann alle in der AskSinMain.h/cpp und müssten 1:1 funktionieren.
Wenn du willst,  schalte ich dich dann für den git frei.  Darfst auch gerne an der AskSin Code und Grösse optimieren.

Attiny halte ich für fast ausgeschlossen,  für Peers,  etc braucht es einfach ein wenig eeprom Speicher. Der Vorteil von HM ist ja,  das die Geräte nicht über eine Zentrale reden müssen,  sondern direkt kommunizieren können.  Um das variabel zu halten und bequem über eine Software konfigurieren zu können,  braucht es einen gewissen Protokolloverhead.

Die Diskussion über den EEPROM-Speicher habe ich verfolgt. Allerdings meine ich, dass man zumindest für einfache Schalter mit weniger auskommen kann:

- Serien-Nr. etc kann in´s Flash, es reicht, wenn ich die beim Kompilieren festlege
- Adresse der Zentrale (3 Bytes)
- Adresse(n) der Peers (x * 3 Bytes)
- aktueller Zustand (1 Byte)

Selbst mit 256 Bytes EEPROM kann ich da schon einige Peers unterbringen. Wie gesagt, für mich muss es nicht das komplette HM-Protokoll mit allen Channels etc. werden. "Kopieren" von bekannten Devices empfiehlt sich mE trotzdem, damit die Teile auch mit CCUs einsetzbar sind. Aber bei unsupporteten Features kann dann ja einfach NACK gesendet werden, wenn ich das richtig verfolgt habe.

Bisher habe ich meinem Nachbau-Empfänger eine ID eines zuvor gepairten Schalters verpasst. Er liest die Kommunikation mit und schaltet parallel zum "Original" ein und aus. Das funktioniert, solange der original-Schalter auch aktiv ist und brav die ACKs sendet; ohne die ACKs funktioniert es genau ein mal

Als nächstes werde ich also die Senderoutine und "eigene" ACKs einbauen, dann kann der "vorgepairte" Schalter eingesetzt werden. Pairing ist dann die nächste Baustelle. Aber das kennst Du ja 

Edit: So gerade noch einmal nachgeschaut - wir brüchten eine rm22 class mit folgenden Funktionen:

Code Auswählen Erweitern

void    config(uint8_t csP, uint8_t mosiP, uint8_t misoP, uint8_t sckP, uint8_t gdo0P, uint8_t int_gdo0); // set the respective pins
hier wird letztendlich nur Konfiguriert - Die Funktion wird vom Main Sketch aufgerufen, du bist also frei welche Parameter du übergeben möchtest.

Ist das Arduino-spezifisch? Ich kenne das so, dass man die Pins in der Header-Datei konfiguriert. Dort steht dann z.B.

Code Auswählen Erweitern


#define MOSI  PB0
#define SCK    PB2


Im restlichen Proramm wird dann anstatt der direkten PIN-Bezeichnung nur MOSI bzw. SCK verwendet. Die Ersetzung wird beim Kompilieren einmalig vorgenommen, Speicher wird hinterher nicht mehr dafür benötigt. Da sich die Parameter auch zur Laufzeit nicht ändern (die Verdrahtung ist nun mal so, wie sie ist...), sehe ich keinen Grund, hierfür eine Funktion vorzusehen.

Code Auswählen Erweitern

void    init(); // initialize CC1101
Wie weiter oben beschrieben. Wird von hm.init aufgerufen.

Code Auswählen Erweitern

uint8_t sendData(uint8_t *buf, uint8_t burst); // send data packet via RF
Wird von HM aufgerufen um codierte Strings zu senden. Codier Routine ist in HM. Burst ist 0 oder 1 und schaltet einfach nur das Sendemodul für 250ms ein.
Ist notwendig um mit Devices, die im Standby sind, zu sprechen. Wenn Burst0, dann Sende Teil einschalten und String sofort in den Sendebuffer des Moduls schreiben.

Code Auswählen Erweitern

uint8_t receiveData(uint8_t *buf); // read data packet from RX FIFO
Funktion um den Empfangsbuffer des Funkmoduls auszulesen und in den übergebenen Buffer zu schreiben.

Ja, das lässt sich 1:1 abbilden. Wie gesagt, senden muss ich noch machen

Die Routinen sind etwas aufwendiger, da CRC-Berechnung und data whitening in Software realisiert werden muss. Data whitening habe ich schon, da auch für den Emfpang nötig. CRC kommt.

Was meinst Du mit "codier routine ist in HM"? Diese XOR-Geschichte habe ich bisher von der Empfangsroutine direkt erledigen lassen, sodass meine Receive-Routine direkt eine Struct hm_message befüllt. Denn meines Erachtens nach werden nirgendwo die verschlüsselten Daten benötigt, die können also direkt beim Emfpang dekodiert bzw. codiert werden. Je nach dem, was das Modul selbst kann (CRC, data whitening), ist es evtl. nötig, das hier zu erledigen, da bin ich mir allerdings noch nicht sicher. Bedeutet zwar evtl. etwas doppelten Code, aber nicht im AVR, sondern nur auf dem PC

Das etwas empfangen wurde, wir in der AskSinLib derzeit über Interrupt 0 and Pin2 signalisiert, ich weiss nicht, ob dein Funkmodul das kann?
Schau mal nach und sag Bescheid. Wie gesagt, es würde mich freuen, wenn wir weitere Funkmodule mit in die Lib integrieren könnten.
Und Mitstreiter zur Code Optimierung sind auch herzlich Willkommen....

Ja, es gibt einen frei konfigurierbaren Interrupt-Pin. Auch einen Wakeup-Timer gibt es (für burst/Stromspar-Modus), so weit bin ich aber noch nicht.

Sebastian

[sebixvi]

Hallo,

kurzes Update zum RFM22:

Ich habe den CRC-Code implementiert und bin in der Lage, mit dem RFM22 Pakete zu senden, die der CC1101 versteht. Die ersten ACKs auf Schaltbefehle aus FHEM habe ich erfolgreich gesendet, allerdings noch ein bißchen hakelig (FHEM sendet die Befehle mehrfach, eines der ACKs wird dann schließlich akzeptiert), das könnte ein Timing-Problem sein, da ich bisher die gesendeten Befehle unmittelbar nach dem Empfang über die serielle ausgebe, bevor ein ACK gesendet wird.

Code-Größe bisher einschließlich Debugging ca. 2,5k, ich rechne mit etwa 1,5k ohne Debugging-Code. Mal sehen, was für Pairing etc. noch draufgeht. Aber es gibt ja Tinys mit 4k oder gar 8k

Sebastian

[trilu]

Versuch mal in deinem Debug Code das Timing mit einzubauen, also eine Millis() Ausgabe nach der Seriellen String Ausgabe.
HM hätte den ACK gerne nach spätestens 300ms, hört sich wenig an, ist im Falle Arduino aber eine halbe Ewigkeit.

Was mir noch einfällt, schau mal welche RSSI Werte du bekommst, wenn die Frequenz oder Modulation nicht passt, dann
geht der Empfangsstärkewert in den Keller.

Das eigentliche Funkgedöns macht bei meiner Code Größe auch nicht so viel aus, das String und Registerhandling pumpt
den Code auf. Am meissten ist es, das Register auslesen und die Peer Geschichte, also alle Peers lesen und die Registerwerte (List3/List4)
der einzelnen Peers.

[sebixvi]

Moin,

es lag am Timing; wenn ich das ACK versende, bevor ich die empfangene Message mit 2.400 Baud ausgebe, bekomme ich keine Fehler.

Inzwischen ist auch das Pairing halbwegs implementiert, d.h., das Device sendet nach 1s Druck auf eine Taste eine Pairing-Message, meldet sich als 1-Kanal-Schaltaktor-Bausatz und holt sich so die ID der Zentrale. Schalten per FHEM geht danach, allerdings wird der Status immer als "50%" angezeigt. Ich muss also meine Config noch aufräumen und getConfig noch implementieren.

ATtiny, ich komme: Code-Größe mit Debugging-Ausgaben 2,6k. Ich vermute, dass die Arduino-Variante einige Libs immer dazulinkt, egal, ob sie benötigt werden oder nicht. Jedenfalls dürfte es kein Problem sein, das in den größeren Tinys unterzubringen. Ein paar 25er und 45er habe ich noch hier, sobald die genannten Fehler ausgemerzt sind, werde ich mal einen Tiny45 versuchen.

@trilu: Kannst Du mir noch eine Frage zum Burst-Modus beantworten? Du sendest für 350ms ein burst-Signal. Laut Code wird dafür nur der Tx-Mode des CC1101 aktiviert. Fängt der CC1101 bereits in diesem Moment an, Präambel-Bits zu senden? Im Datenblatt habe ich dazu nichts gefunden.

Allerdings dürfte es auf Sensor-Seite auch reichen, den passiven Burst-Modus zu unterstützen (also alle 300ms aufwachen und lauschen). Für Schalter wäre es natürlich schon fein, auch mit Bursts wecken zu können; mal sehen, ob der RFM22 das auch kann.

Schönen Abend,
Sebatian

[trilu]

Hi Sebastian,

stell doch deinen seriellen Port auf 57600, dann passen mehr Bytes in kürzerer Zeit durch die Leitung.
Dein Vorgehen kommt mir bekannt vor, am Anfang der ACK, dann Pairing, jetzt getConfig

Burst Mode ist einfach - Im Burstmode wird einfach nur das Sendeteil eingeschaltet und der Empfänger lauscht im 250ms Takt
ob die Trägerfrequenz an ist. Da werden noch keine Bytes ausgetauscht.

Bei Schaltern gibt es den Burst nur pro Kanal, also Schaltaktor sendet 300ms Trägerfrequenz und dann erst Bytes.
Das was du meinst geht bei Schaltern anders...

Schalter sendet irgendwas, Zentrale merkt das der Schalter empfangsbereit ist und sendet ein getConfig oder was auch immer, in
dem String wird ein Flag mitgesendet um das Device wach zu halten. Es findet also kein Polling vom Schalter statt, sondern er schläft
wirklich und wird nur durch Interrupts der Taste aufgeweckt.

Ein HM String fängt ja mit der Länge an, gefolgt vom Counter und dann kommt das Message Byte, in dem Message Byte gibt es ein paar Flags:

Code Auswählen Erweitern

my @culHmCmdFlags = ("WAKEUP", "WAKEMEUP", "CFG", "Bit3",
                     "BURST", "BIDI", "RPTED", "RPTEN");
#RPTEN    0x80: set in every message. Meaning?
#RPTED    0x40: repeated (repeater operation)
                     #BIDI     0x20: response is expected
#Burst    0x10: set if burst is required by device
#Bit3     0x08:
#CFG      0x04: Device in Config mode
#WAKEMEUP 0x02: awake - hurry up to send messages
#WAKEUP   0x01: send initially to keep the device awake

Das #WAKEUP ist das entsprechende Flag das du auswerten musst um dein Gerät für einen gewissen Zeitraum wach zu halten...

Viele Grüße
Horst