Arduino Asksin library

[trilu]

ja, wird es - ich habe einfach zu wenig zeit
aber meine anderen baustellen sind jetzt einigermassen fertig - so dass ich hier definitiv wieder weitermachen möchte

brauche immer noch ein paar sensoren, den dimmer muss ich noch ein wenig umbauen damit die nicht lineare helligkeitssteuerung für leds besser klappt, einen sensor schalter hätte ich auch noch gerne, zum strom und gas zähler ablesen will ich nicht in den keller ....

[ccier]

Hallo!

Nachdem ja nun a) der AES-Schlüssel ab Werk bekannt ist und b) der AES-Signing Algorithmus bekannt ist, wollte ich mal nachfragen, ob hier schon an dem Einbau in die Asksin-Lib gearbeitet wird?

(siehe auch: http://forum.fhem.de/index.php?topic=38317.0)

[chipmunk]

Hallo,
ich habe dazu auch eine Frage
Gibt es damit eine Chance neue Firmware zu erstellen, die sich OTA einspielen lässt, ohne den Bootloader flashen zu müssen?
Der Schaltaktor ist ja von sich aus bereits OTA-fähig.

Danke
Chipmunk

[trilu]

Hallo Zusammen,

Dirk hat bereits an der Implementierung von AES gearbeitet, erste Teile sind bereits im Github. Habe aber noch nicht getestet.
Eigene Soft über einen HM Overtheair Bootloader wird wohl in absehbarer Zeit nicht funktionieren, da die Verschlüsselung der Firmware nicht bekannt ist.
Es gibt aber von Dirk einen OTA Bootloader für Arduino, damit klappts. Ist im Thermometer/Hygrometer Thread.
Viele Grüße
Horst

[gandy]

Hallo Horst,

bau gerade nach längerer Pause an meinem Sensor weiter. Im Moment versuche ich herauszufinden, wie ich in NewAskSin für List0 Defaultwerte definieren kann. Gibt es dafür eine Möglichkeit?

Danke,
Andy.

[trilu]

Hi Andy,

sorry, zu spät gesehen. Klar gibt es eine Funktion dafür, ist nur noch nicht dokumentiert
Zuerst musst du ein Array erzeugen das die Länge der List0 in Byte hat, dieses Array übergibst Du mit folgender Funktion

   hm.ee.uint8_t  EE::setListArray(uint8_t cnl, uint8_t lst, uint8_t idx, uint8_t len, uint8_t *buf) {

Parameter - Channel, List sind klar - Index, falls es eine List3 oder 4 ist abhängig von der Peer Position.
Len Länge des Arrays und der Pointer zum Array.

Um ein Peer per default einzufügen:
   uint8_t pT[] = {0x01,0x02,0x04,0x01,0x00};
   hm.ee.addPeer(1, pT);

Viele Grüße
Horst

[gandy]

Hi Horst,

danke für den Tipp! Wann rufe ich die Funktion auf, ich vermute mal das kommt nach dem Aufruf von AS::init() ?

Wird der Inhalt von buf dann auch ins EEProm geschrieben falls dieses noch ungültige Daten enthält? Und bleiben später die Daten erhalten wenn ich per regSet etwas geändert habe?

Im Moment ist es so, dass die Register allesamt auf 0 stehen wenn sich hinreichend viel geändert hat. Ich fange das dadurch ab, dass ich dann intern einen anderen Wert (z.B. für measureInterval) verwende, der Registerinhalt wird von FHEM aber immer noch als 0 ausgelesen. Eleganter fände ich, wenn nach dem ersten FW-upload die Registerinhalte auf meinen Defaults stehen, die ich dann bei Bedarf mit regSet ändere (von wo an die Defaults nicht mehr gelten).

So  wie ich setListArray() verstehe, kann ich für einen neuen Peer die Defaults für List1 und List3/4 festlegen, die dann ins EEprom geschrieben werden, wenn ich den Peervorgang initiiere. Registerinhalte für bestehende Peers dürften davon unberührt bleiben.

Aber wie funktioniert das bei List0, wird hier der Inalt von buf beim pairing ins EEprom geschrieben? Wie ist es dann wenn mein Sensor notfalls ungepaired an broadcast senden und dazu mit den Default-Einstellungen aus der List0 arbeiten soll?

Ich werde mal setListArray() testen (sehe gerade dass es ein (auskommentiertes) Beispiel in examples/HM_LC_Dim1PWM_CV gibt), geht aber eher gemächlich voran..

Etwas OT, aber weil wir gerade beim Dimmer Beispiel sind: Ich habe damit gelernt, wie ich ein PWM Signal ausgebe und habe versucht, eine RGB-Led per PWM anzusteuern. Resultat meiner zahlreichen Versuche: an/aus-Schalten der drei output-pins funktioniert noch (langweilig, nur 8 Farben), PWM auf Rot (PORTD5/OCR0A) und Grün (PORTD6/OCR0B) auch, nur meine blaue LED (PORTB1/OCR1A) bleibt aus, dafür geht die interne Uhr plötzlich nur noch halb so schnell. Mein Code für die PWM-Ausgabe:

Code Auswählen Erweitern


void init_RGB()
{
    dbg << "init pwm\n";

    // Timer0 (8Bit)
    DDRD |= (1 << DDD6);                      // PD6 is now an output (OC0A) GRN
    DDRD |= (1 << DDD5);                      // PD5 is now an output (OC0B) RED
    OCR0A = 128;                              // set PWM for 50% duty cycle GRN
    OCR0B = 128;                              // set PWM for 50% duty cycle RED
    TCCR0A |= (1 << COM0A1)| (1 << COM0B1);   // set none-inverting mode
    TCCR0A |= (1 << WGM01) | (1 << WGM00);    // set fast PWM Mode
    TCCR0B |= (1 << CS01);                    // set prescaler to 8 and starts PWM

    DDRB |= (1 << DDB1);                      // PB1 is now an output (OC1A) BLU
    TCCR1A |= (1 << COM1A1);                  // set none-inverting mode
    TCCR1A |= (1 << WGM10);
    TCCR1B |= (1 << WGM12);                   // set Fast PWM mode, 8bit, TOP 0xff
    TCCR1B |= (1 << CS10);                    // set prescaler to 8 and starts PWM
}

void set_RGB(byte r, byte g, byte b)
{
    OCR0A = g;                              // set PWM for 50% duty cycle GRN
    OCR0B = r;                              // set PWM for 50% duty cycle RED
    OCR1A = b;                              // set PWM for 50% duty cycle BLU
}


Ist aber nicht soo wichtig, nur ein Nebenschauplatz. Hat sicher damit zu tun, dass einer der Timer für die Systemzeit dient, die über getMillis() statt millis() auszulesen ist.

Danke für Deine Unterstützung,
Grüße,
Andy.

[trilu]

Ich habe zwei neue Funktionen in die library integriert - sind auf dem Git im master branch verfügbar.

Die Funktionen befinden sich in der register.h des sketches, hab sie auch in die Beispiele integriert.

Code Auswählen Erweitern

void everyTimeStart(void) {
// place here everything which should be done on each start or reset of the device
// typical use case are loading default values or user class configurations


}

void firstTimeStart(void) {
// place here everything which should be done on the first start or after a complete reset of the sketch
// typical use case are default values which should be written into the register or peer database


}


firstTimeStart wird beim ersten Start des Devices angesprungen, also nicht bei einem Reset oder Restart, weil Strom unterbrochen war.
Ich prüfe das gegen eine Magic Nummer die ins EEprom geschrieben wird. Die Magic Nummer ist abhängig von der Register Definition in register.h
Damit möchte ich erreichen das ich Code ändern kann, ohne das jedes mal der EEprom überschrieben wird. Wenn ich aber an einem neuen Device arbeiten möchte, das erkannt wird und der EEprom geläuscht wird.
Diese Funktion eignet sich also für das Setzen von Default Werten.

everyTimeStart wird nach dem Einschalten bzw. einem Reset angesprungen. Damit eignet sich die Funktion für das setzen von Default Werten die Grundsätzlich gebraucht werden. Hier hin möchte ich nach und nach die Starteinstellungen verlagern.
Also alle Funktionen wie das hier:

Code Auswählen Erweitern

hm.confButton.config(1, CONFIG_KEY_PCIE, CONFIG_KEY_INT); // configure the config button, mode, pci byte and pci bit

hm.ld.init(2, &hm); // set the led
hm.ld.set(welcome); // show something

hm.pw.setMode(1); // set power management mode
hm.bt.set(27, 600000); // 3600000 = 10min. // set battery check, internal, 2.7 reference, measurement each hour


Damit zu deinen weiteren Fragen - setze deine Default Werte für List0 in der Funktion firstTimeStart. Wenn du im laufenden Betrieb neue Register Inhalte setzt, wird der Default Wert im EEprom überschrieben und bleibt erhalten.
Mit setListArray kannst du prinzipiell in jede List schreiben, also auch in List3 und 4. Hier musst du aber die Index Position der Peer-Adresse beachten. Es gibt ja eine eigene List3/4 für jede PeerID - Ich habe deshalb das setzen der List3/$ Default Werte in die User Module verlagert.
Das setzen der Default Werte in List3/4 wird beim peering automatisch gemacht. Kannst du dir in der Dimmer Class anschauen.

Das PWM Problem beim Dimmer kenne ich Der 328 hat leider nur 3 Timer und einen benötige ich für die millis() - Das Problem hättest du aber auch ohne AskSin. Um einen 3 Kanal Dimmer zu bauen gibt es drei Möglichkeiten - auf einen anderen Chip mit mehr PWM Kanälen auszuweichen, wie den 644 oder 32u4. Eine zusätzliche HW zu verwenden, es gibt einen I2C nach PWM Baustein. Weiss gerade nicht mehr wie der heißt.
Oder diese 2811/12 LED Bänder mit eingebauter Logic verwenden...

So, ganz schön viel Text - Teste mal ob du mit den neuen Funktionen klar kommst ...
Viele Grüße
Horst

[gandy]

Super, genau das meinte ich, vielen Dank für die beiden Funktionen, damit komme ich gut zurecht Feedback kommt nach den Tests

An einen externen PWM controller mit i2c hatte ich auch schon gedacht, der PCA9685 ist mit 12 bit ganz gut, um eine halbwegs brauchbare brightness/luminance Anpassung hinzubekommen ohne wahrnehmbare Helligkeitssprünge im unteren Bereich. Mit 16 Kanälen ist er natürlich etwas überdimensioniert. Es gibt sicher andere die besser in Frage kämen,  aber mein Hauptproblem ist im Moment,  dass ich schon Probleme habe,  den code für den BMP185 noch in den Speicher meines Panstamp zu bekommen, der auch über i2c angebunden ist. Dann wird das Firmware Image so groß,  dass nach dem upload bei Byte 0x7000 ein verify-error geworfen wird. Deshalb hatte ich gehofft, es gibt eine Möglichkeit, den internen pwm zu verwenden. Komplett vom Panstamp verabschieden würde ich mich bei dem Projekt auch nur ungern, zur Not lieber Features abspecken.

Welchen timer verwendest du denn für millis? Im Grunde komme ich ja für rot und grün mit nur einem timer (Timer0) aus, dessen zwei compare-Register für die PWM herhalten. Der Timer1 sollte die blaue LED bedienen, was aber so gar nicht tun will, also vermute ich mal du verwendest den. Timer2 hatte ich noch nicht in Betracht gezogen, weil dessen einziger verfügbare Pin D3 (der andere ist SPI MOSI) bei mir belegt ist. Sollte ich aber umwidmen können, noch existiert der Sensor nur auf dem Steckbrett. Oder ist Timer2 auch belegt?

Beste Grüße,
Andy.

[gandy]

Hallo Horst, hab mir vor Arbeitsbeginn noch kurz versucht, die Änderungen von github zu pullen, dort ist die letzte Änderung aber der 6 Tage alte commit 70a8151 - darf ich Dich bitten, deine letzten Änderungen noch zu pushen?

Danke,
Andy.

[trilu]

stimmt, habe vergessen auf den knopf zu drücken - jetzt ist es im git

[gandy]

Danke Horst, habs gepullt und getested, funktioniert wie ich es mir erhofft hatte

Kleiner Unterschied: Das übergebene Array muss nicht alle Bytes der Channel-List angeben, vielmehr muss ein Array von Paaren aus REGNUM:VALUE übergeben werden. Ich habe die Funktion mal so dokumentiert, wie ich sie verstanden habe (und hochgeladen) Schau bitte, ob Du damit einverstanden bist, dann pushe ich das zusammen mit einer minimalen Änderung (const für uint8_t*buf, sollte ohne Auswirkung auf bestehenden Code bleiben).

Zudem habe ich testhalber in  AS::recvMessage  einen Aufruf an firstTimeStart() bei einem RESET eingefügt. So kann ich meine aktuellen Factory-Defaults sehr schön von FHEM aus laden

Aktuell nur bei mir lokal, bis Du dein OK gibst.

Grüße,
Andy.

[trilu]

du hast recht - setlistarray erwartet die addresse und das byte
gibt aber noch eine weitere funktion
   uint8_t  setList(uint8_t cnl, uint8_t lst, uint8_t idx, uint8_t *buf);            // set a complete list to the eeprom

hier wird einfach nur die list ins eeprom geschrieben, d.h. man braucht keine addressierung und spart die addressbytes im flash

deine änderungen schau ich mir nach dem grillen an 

[trilu]

hi andy,
in welchem branch finde ich deine änderungen - ist das in gh-pages?
sehe in gh-pages aber auch, das jede menge files einfach nur gelöscht sind...
mhhh, ich hab zu wenig ahnung von github 
aber grillen war lecker!
horst

[gandy]

Nachträglich noch guten Appetit - heute reicht's sicher die Würstchen zum Grillen auf den nächst größeren Stein zu legen

Die Änderungen an EEprom.cpp und EEprom.h (Dokumentation der setListArray()) gibt es aktuell nur in meiner Arbeitskopie, noch nicht in einem der Branches auf GitHub. Daraus habe ich mit Doxygen neue HTML-Seiten erzeugt (Stand heute, master-branch + meine Änderungen) und die Webseiten nach gh_pages auf GitHub gepusht. Damit sind sie über http://trilu2000.github.io/NewAskSin zugänglich, weil gh_pages ein spezieller Branch zum Hosten der Projekt-Webseiten ist (insbesondere kann man nicht unterscheiden zwischen Seiten die für den einen oder anderen Branch gedacht sind). Wenn Du jetzt eigene Seiten dort vermisst, vermute ich, dass Du diese ursprünglich aus dem dev-Branch erzeugt hattest? Kann auch sein, dass Du eine andere Doxygen Version verwendest, die die Seiten etwas anders erstellt.

Edit: Kann auch sein dass ich das nächste mal erst ein 'git pull' absetze bevor ich loslege...     man sollte mich ab 28° Aussentemperatur einfach nichts tun lassen 

So oder so stellt sich die Frage für die Dokumentation, auf welches Vorgehen wir uns einigen wollen. Vielleicht sollte nur einer von uns die Seiten für gh_pages erzeugen, dann immer aus dem gleichen branch, vorzugsweise master, wenn der die aktuell gültige Version enthält. Statt direkt auf gh_pages zu schreiben könnte ich dir auch einen temporären Link auf die mit noch nicht committeten Quellen erzeugte Seite schicken.

Und danke für den Tip mit setList(), ich versuche die bei der Gelegenheit mal zu dokumentieren und schick Dir dann einen Link auf die betreffende Seite(n) zum Review. Soll ich in master oder dev dokumentieren?