Arduino Asksin library

[trilu]

Danke,  bau ich ein.
Hast du dir mal das Atmel Studio angeschaut?

Wegen der Leds,  vielleicht koennten wir daraus eine Klasse machen. Ich muss ja dann noch ein paar Trigger in das HM Modul bauen.

Viele Gruesse
Horst

[Dirk]

Hast du dir mal das Atmel Studio angeschaut?

Ja, hatte aber keine Lust mir knapp 800MB runter zu laden.
Habe es jetzt einigermaßen im Eclipse ans laufen bekommen. Muss aber auch in der Arduino-IDE Kompilieren.
Mal sehen ob ich das noch hinbekomme.

Ich mache grade schon mal ein Paar Versuche mit den LED's
Mal sehen ob ich das mit meinen rudimentären C++ Kenntnissen hinbekomme.

vielleicht koennten wir daraus eine Klasse machen

Du hast die LED-Sachen ja schon schön in einer Klasse gekapselt.
Ich erweitere die nur grade so, das man eine 2. LED angeben kann.

Gruß
Dirk

[trilu]

Beim Atmel Studio macht das Kompilieren dann das Visual Micro Plugin. Ich muss also nicht zwischen verschiedenen Programmen waehlen.
Du nutzt aber Linux,  oder?
Mit Eclipse unter Windows bin ich damals gescheitert 

[Dirk]

Ich nutze Eclipse unter Windows schon recht lange. Zuerst im Javascript- und PHP-Umfeld (inzwischen PhpStorm). Aktuell für Android und Perl (FHEM) Entwicklung.
Daher wollte ich das bei einer IDE belassen.
Ich werde mir das Atmel Studio zusammen mit dem Visual Micro aber auch noch mal ansehen.
Ich wollte aber erstmal schnell was am laufen haben.

[Dirk]

Hi Horst,

Ich habe mich mal an das LED-Handling gemacht.
Man kann nun 2 LED's bzw eine Dual-Color-Led als Status-LED anschliessen.
Pin4 ist bei mir grün
Pin5 ist bei mir rot

Nach Anlegen der Spannungsversorung blinkt es zunächst 3x rot.
Nach dem Drücken der Config-Taste blinkt es rot, währen der Datenübertragung blinkt die grüne LED. Dadurch kann man nun auch sehen wenn Daten z.B. beim Peering ausgetauscht werden.

Nach dem Drücken einer Taste blinkt bei jedem Sendeversuch die grüne und rote LED Eine Duocolor-LED zeigt dann gelb an.
Nach einem Ack vom Aktor blinkt es einmal kurz grün. Man kann nun also sehen ob der Befehl erfolgreich am Aktor ankam.
Falls es kein ACK vom Aktor gibt, dann blinkt es nach dem Letzten Sendeversuch rot.

Update:
Eine einfache Batteriemessung ist jetzt auch mit drinn.
Hier wird AVCC als Reference genommen und gegen die interne Bandgap-Reference gemessen.
Der Arduino-Mini-Pro hat die entsprechende Aussenbeschaltung schon (100 nF an AREF gegen Masse und VCC an AVCC)

Da ich meine Testschaltung mit 2 AA-Zelen betreibe, habe ich die Spannung für Batterie leer im Sketch auf 2,35 V eingestellt.
Die Batteriespannung wird vor jedem Tastendruck gemessen und wenn zu klein wird der batLow-Event mitgeschickt.

Gruß
Dirk

[jab]

Abend,

wir haben die Library gestern und heute auf dem 30C3 auf den Homemativ HM-LC-Sw1PBU-FM geportet. Dazu waren allerdings ein paar Änderungen an der Lib notwendig. Ich habe das ganze mal auf Github eingecheckt:

https://github.com/jabdoa2/Asksin-HM-LC-Sw1PBU-FM

Grobe Changelog:
- add quirks for Atmega 644
- change ports for M-LC-Sw1PBU-FM
- change interrupt handlers

Leider ist das ganze nicht mehr zur Ursprungslib kompatibel. Ggf sollte man den Button und Interruptkram von der Homematic Lib trennen. Für die SPI Pins könnte man Ifdefs machen.


Gruß,
Jan

[trilu]

@dirk -  Danke,  werde ich mir gleich mal anschauen. Vielleicht sollten wir auch einen github eröffnen. Sonst wird es sehr schnell unübersichtlich mit den Änderungen. Ich habe nur keine Ahnung wie github,  etc funktioniert. Cool wäre eine Lösung die mir die Änderungen gleich ins Atmel Studio zieht...
@jan - freut mich einen neuen Mitstreiter gefunden zu haben
Ich hatte mir auch schon überlegt die Peripherie von der Lib zu trennen. Habe mich aber dagegen entschieden da das ganze ein Framework werden soll. Ich stelle mir das so vor:
Man definiert in einem externen Script die Funktionalität die man haben möchte,  das Script generiert dann die Register.h und ein xml File für die HM config Software.
Register.h kommt zum Sketch und die verschiedenen Channel sind automatisch konfiguriert.

Dank Martin gibts das Script schon,  also den Register.h Teil. Das xml generieren fehlt noch.
Das ganze kann also HW unabhängig sein,  aber die Peripherie Module müssen im Paket bleiben. Gerne aber ifdef hardwareunabhängig...

Ich werde das Script gleich mal posten...
Weiter vorne hatte ich mal einen pcb sketch gepostet,  da wäre auch das Schaltmodul für deinen Unterputzschalter drin

Viele Grüsse
Horst

[Dirk]

Vielleicht sollten wir auch einen github eröffnen

Unbedingt. Das macht die Zusammenarbeit viel einfacher.
Kannst ja mal ein Repo bei Github anlegen. Alternativ kann ich das gerne auch bei mir machen.

Ich habe nur keine Ahnung wie github,  etc funktioniert.

Das gibt es ganz gute Tuturials.
Du hast lokal ein Repository, darin arbeitest du, committest Änderungen usw.
Das ganze sollte man dann von Zeit zu Zeit in das Remote-Repo puschen. Damit z.B. andere hier weiter arbeiten können.

Cool wäre eine Lösung die mir die Änderungen gleich ins Atmel Studio zieht...

https://gallery.atmel.com/Products/Details/2398da3e-aba5-45ed-b3a0-d0714a6dc661
Es gibt auch Plugins für Eclipse. Auch Tools für Windows z.B. Tortoise GIT https://code.google.com/p/tortoisegit/

... Habe mich aber dagegen entschieden da das ganze ein Framework werden soll.

Das eine muss das andere ja nicht ausschließen
Ich bin auch immer ein Freund gekapselter Modulbausteine.

Gruß
Dirk

[jab]

Moin,

um das ganze zu vervollständigen habe ich auch mein Arduino Target auf github hochgeladen. Basiert auf Sanguino und ist für den Atmel 644 auf dem HM-LC-Sw1PBU-FM angepasst: https://github.com/jabdoa2/jabduino

Ich sehe das mit der Lib wir Dirk. Mein Vorschlag wäre pro Klasse ein File zu machen (bzw 2 mit Header). Dann hätten wir:
- HM: mit aller Funktionalität für Homematic.
- CC: mit aller Funktionalität für CC1100/CC1101
- LD: mit LED Kram
- BK: mit dem Button Kram
- InputParser: serial kram

Dann könnten wir die Namen noch etwas lesbarer machen:
- HM -> Homematic
- LD -> LED
- BK -> ButtonPress

Konkret habe ich aktuell folgende Probleme:
- Die Logik in BK funktioniert so nicht für meinen Controller. Da ist viel Magie drin die ich nicht durchschaue und die sich bei mir mit den Ports und Indexes verrechnet. Ggf ist das für meinen Anwendungsfall auch etwas zu aufwändig. Interrupthandling funktioniert auch nicht auf jedem Controller gleich und ich musste es anpassen. Das ist also relativ spezifisch pro Gerät.
- Das schalten eines  HM-LC-Sw1-Pl funktioniert nicht wirklich zuverlässig. Manchmal geht es und dann auch wieder nicht. Im Sniffer sieht es aber ganz gut aus. Hast du eine Idee woran das liegen kann? Kein Burst? Timing?


Gruß,
Jan

[trilu]

Hi Jan,

ich schaue mir das heute mal mit dem Github an und wenn es für mich eine handhabbare Lösung gibt mehrere Files über mehrere Rechner aktuell zu halten, dann können wir die Lib gerne über mehrere Files aufdröseln.
Eigentlich sollte das Interrupthandling doch über Arduino transparent sein? Klar das der 644 mehr Interrupts hat, aber auch das müsste über Arduino.h geregelt sein:
In der BK::config suche ich den Interrupt und die PCMask zum Arduino Pin und schreibe beides ins Interrupt Register
danach den Pin und Port zum Arduino Pin und schreibe ihn in ein Array, damit ich ihn später, wenn der entsprechende Interrupt auslöst,  griffbereit habe.

Danach gibts dann das Interrupt Handling in der pcInt Funktion.
Hier suche ich dann nach dem bit das den Interrupt ausgelöst hat und schreibe ihn in das Struct zur entsprechenden BK Instanz.

Per Polling schau ich mir regelmäßig das Struct an und prüfe ob es etwas zum abarbeiten gibt. Vielleicht solltest du einfach mal die entsprechenden PCINTX_vect für den 644 mit einbauen.
Der Rest, so lange Arduino compatibel sollte von der BK Class abgedeckt sein...

So aus der Ferne ist es schwer zu beurteilen was bei dir nicht läuft. Poste doch mal ein paar Logs und ich schau sie mir an.
Aber wie gesagt, zu aller erst, würde ich versuchen die 644'er int vectoren zu definieren und zu testen...

Viele Grüße
Horst

[jab]

Hi,

die Interruptvektoren habe ich ja definiert. Das klappt so weit auch. Habe zwei Probleme beim Schalten identifiziert:
- Nach einem Neustart hält er die Nachricht für eine Wiederholung, wenn der Taster nur einmal gedrückt wurde. Ich vermute mal, dass es die gleiche Sequencenummer ist.
- Ansonsten geht es relativ zuverlässig. Selten klappt es nicht. Ich kann das aber noch nicht zuverlässig nachstellen

Abseits davon scheint beim Empfang irgendwas nicht zu klappen. Z.b. bei einem getConfig in FHEM bekomme ich folgenden Output in der Seriellen Konsole:

-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157168)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157770)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2158372)

Er scheint aber keine Antwort zu senden. Oder ist das noch nicht implementiert?

Btw: Ich habe noch zwei Mitstreiter mit der gleichen Hardware die sicher in den nächsten Tagen auch noch weiter dran schrauben werden.


Gruß,
Jan

[trilu]

Hi Jan,

klar das die lib damit nicht viel anfangen kann - hier wird eine burst message vom gerät 12 1A B1
an uns gesendet.
"12"          => { txt => "HAVE_DATA"},
Die Message habe ich noch nicht implementiert, da ich sie noch nie gesehen habe. Hast du ein original device und kannst mir die Antwort darauf sniffen?
Ich bau das dann gerne ein...

-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157168)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157770)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2158372)

[jab]

Hi,

das ist FHEM wenn ich getConfig aufrufe. Vorher hab ich burstAccess auf Auto gestellt. Ansonsten hat FHEM nie irgendwas an das Gerät geschickt. Ich bekomme alle 30s ein t:xxx auf dem Serial. Sollte er da ein Wakeup schicken? Afaik müsste er ja eins von beiden tun: Entweder periodisches Wakeup oder auf Burst reagieren.

Nachtrag: power mode habe ich 0 gesetzt, weil es noch Probleme gab beim Sleep mit der CPU. Hat ja auch keine Batterie.

Beim Pairing sieht das bei mir so aus:
<- 1A 01 A2 00 5F B7 4A 1A B1 50 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(2411407)
-> 0A 01 80 02 1A B1 50 5F B7 4A 00 (l:11)(2411546)
-> 10 55 A0 01 1A B1 50 5F B7 4A 00 05 00 00 00 00 00 (l:17)(2411823)
-> 10 55 A0 01 1A B1 50 5F B7 4A 00 05 00 00 00 00 00 (l:17)(2412023)
<- 0A 55 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412105)           
-> 13 56 A0 01 1A B1 50 5F B7 4A 00 08 02 01 0A 1A 0B B1 0C 50 (l:20)(2412408)
<- 0A 56 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412423)
-> 0B 57 A0 01 1A B1 50 5F B7 4A 00 06 (l:12)(2412720)
config changed                                                                 
<- 0A 57 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412744)     
-> 10 58 A0 01 1A B1 50 5F B7 4A 00 04 00 00 00 00 00 (l:17)(2413041)
<- 18 58 A0 10 5F B7 4A 1A B1 50 02 01 00 02 01 0A 1A 0B B1 0C 50 18 00 00 00 (l:25)(2413056)
-> 11 58 A0 02 1A B1 50 5F B7 4A 04 6E F8 5E 10 71 4C 02 (l:18)(2413197)

Wenn ich danach ein getConfig in FHEM anstoße passiert genau nichts. Es sei denn ich aktiviere BurstAccess. Was geht da schief?


Gruß,
Jan

[trilu]

schau dir mal die power modes an, derzeit sind 4 stück drin
power mode 0 - default, keine power savings
power mode 2 - device wacht alle 250ms auf und lauscht ob es ein burst signal gibt, wenn nicht schläft es weiter
power mode 3 - gerät wacht alle 8 sekunden auf, dann könnte es einen sensor auslesen um dann wieder weiter zu schlafen, RX bleibt aber aus
power mode 4 - gerät schläft bis es von einem interrupt geweckt wird, RX ist aus

in power mode 3 und 4 muss man eine taste drücken um etwas zu senden, danach geht das funkmodul in RX um die bestätigung zu empfangen.
hier hilft also kein burst signal. burst hilft nur bei power mode 2.

power mode 3 und 4 soll für schalter und sensoren sein, da wird getconfig gelesen wenn das gerät einen pairing string gesendet hat, also die config taste gedrückt wurde...
das ganze ist in fhem über die model ID hinterlegt.

das t:xxx war für mich zum testen. der millis() timer ist ja normalerweise im tiefschlaf auch aus, damit würde ich aber die referenz für viele zeitgesteuerte funktionen verlieren,
z.b. das wiederholte senden einer nachricht, etc... deshalb fülle ich den millis() timer manuell durch die watch dog referenz

[trilu]

gerade mal nachgeschaut, der 644 hat eigentlich nur einen pcint vektor mehr...
versuch mal so:

ISR(PCINT3_vect) {
   pcInt(3);
}

und in void pcInt(uint8_t iPort)
   if (iPort == 3) pcMskByte = PCMSK3;
setzen

das müsste eigentlich reichen