Arduino Asksin library

[trilu]

Hi Peter,

wie das halt so ist mit Mirakeln - Ich persönlich glaube ja, dass Mirakel mehr dem Land der Wünsche/Träume entsprungen sind 

Du hast völlig recht, dass sich die Library für einen produktiven Einsatz derzeit nicht besonders eignet. Das liegt zum Einen an der fehlenden Dokumentation, zum Anderen aber auch an der Library selbst. Der aktuelle Stand ist das Ergebnis meiner nicht vorhandenen Programmierkünste. Ich habe als absoluter Anfänger, was das Thema Arduino und C++, vor etwa 1 Jahr angefangen an der Lib zu arbeiten und jede Menge über die Zeit dazu gelernt. Vieles von dem was in der aktuellen Lib ist, würde ich heute anders machen. Deshalb habe ich mit der Pflege/Verbesserung und Dokumentation der bestehenden Lib gestoppt und mit der NewAskSin begonnen.
Liegt ebenfalls im Git auf folgender Seite:  https://github.com/trilu2000/NewAskSin

Mittlerer weile habe ich mit der NewAskSin einen Stand erreicht, dass die grundlegende Kommunikation ganz gut läuft, also Pair und Peer funktioniert. Registerhandling ist auch größtenteils implementiert, aber noch nicht vollständig getestet. Config Taste, Led Status Anzeige und User Modul Registrar sind auch drin. Als nächstes kümmere ich mich um das Power Management. Danach fehlen nur noch die User Module, wie Relay, Dimmer und Sensoren. Es geht also voran....
Momentan ist sie deutlich kleiner und transparenter als die Vorgängerversion. Die Anbindung an die HW ist in eine HAL ausgelagert, damit dürfte sie auch leichter zu portieren sein.

Die User Module werden dann eine externe Schnittstelle haben, also egal welchen Sensor man ranhängen möchte, das Modul bleibt das selbe. Die eigentliche Funktionalität kommt vom Main Sketch und nicht mehr aus dem Modul. Beim Relay würde das heissen, es gibt zwei Funktionen im Main Sketch, eine Initialisierung wenn das Modul startet und eine Funktion wird bei Änderungen angesprungen.

Wenn oben beschriebene Funktionalitäten so weit sind, mache ich mich an die PC Software. Ziel ist es, eine Konfigurationssoftware zu entwickeln, in der man die gewünschte Funktionalität des Devices beschreibt und automatisch die register.h und ein Script zur Einbindung in FHEM bekommt. Sich also auf Arduino Seite nur noch um die eigentliche Mess-, Schalt- oder Ausgabefunktionalität kümmern muss.

Zur Zeit baue ich das Ding aber mehr oder weniger allein; Klar, Grundlagenarbeit ist nicht sexy. Aber Aufgrund meiner limitierten Zeit kümmere ich mich halt verstärkt um das Programmieren und nicht ums Dokumentieren. Ich weiß, ohne Doku kann die Lib auch nicht benutzt werden...
Die Frage ist jetzt nur, wenn Du wirklich Interesse hast und dokumentieren möchtest, ob es nicht vernünftiger wäre, mit der NewAskSin zu starten. Die Register Struktur hat sich massiv verändert. Ich lade mal ein Dokument hoch, mit dem ich gestartet habe - vielleicht hilft es dir, die neue Lib Struktur zu verstehen (Seite 35).
Ich bin auch gerne bereit Zeit in die Erklärungen zu investieren, aber zur schönen Aufbereitung fehlt mir halt die Zeit.

Viele Grüße
trilu

[Dirk]

Du hast völlig recht, dass sich die Library für einen produktiven Einsatz derzeit nicht besonders eignet. Das liegt zum Einen an der fehlenden Dokumentation, zum Anderen aber auch an der Library selbst. Der aktuelle Stand ist das Ergebnis meiner nicht vorhandenen Programmierkünste.

Man kann die Lib schon auch für produktive Sachen einsetzen. Allerdings geht das nicht von selbst. Und ohne deine Arbeit daran währen Projekte wie die alternative Firmware für HM_LC_Sw1PBU_FM der AskSin Bootloader oder auch der Universalsensor noch nicht so weit gekommen.

Zur Zeit baue ich das Ding aber mehr oder weniger allein;

Wenn du magst, beteilige ich mich hier gerne wieder.

Viele Grüße
Dirk

[trilu]

@Dirk
Ok, ich muss es umformulieren - Die Lib eignet sich für Kenner und Menschen die bereit sind, sich in die Lib einzuarbeiten.

Klar mag ich dass du dich wieder beteiligst! Danke für das Angebot. Wie wäre es, wenn wir es in einem Git machen und ich dich freischalte?
Minor Änderungen und Weiterentwicklung macht jeder allein. Major Themen sprechen wir per Mail oder Chat ab?

Viele Grüße
Horst

[Prof. Dr. Peter Henning]

Hm, "Kenner" wovon ? Ich entwickele mit meiner Arbeitsgruppe unter anderem extrem komplexe Lernsysteme, bei denen fünf verschiedene Dienste miteinander Nachrichten austauschen, als "Kenner" würde ich mich schon ansehen. Das ist auch keine Frage der Einarbeitung, sondern der fehlenden inneren Systematik der bisherigen AskSin-Software.

Ich bin gerne mit dabei, auch mit "Hilfsarbeiten" wie der Dokumentation. Um einen Anfang zu machen: Es wäre sinnvoll, wenn man ordentliche Sequenzdiagramme hätte, mit den drei Akteuren

Anwendung - (New)AskSin - HM-Zentrale.

Also beispielsweise Aktion Pairing: Was leitet die Anwendung an (New)AskSin, was leitet diese an die Zentrale, was kommt von dort zurück etc. Gerne steuere ich diese Diagramme zur Dokumentation bei.

Betreffend die "neue" Architektur der Software: Ich habe mir das noch nicht angesehen, insofern stochere ich im Nebel. Allerdings frage ich mich, ob solche Dinge wie eine HAL der geringen Performance der ausführenden Mikros angemessen ist. Ich habe die Erfahrung gemacht, dass Programmier-Autodidakten dazu neigen, eher komplexe Lösungen zu bauen. Insofern bin ich auch hier gerne mit Rat und Tat zur Stelle.

Aber erst einmal dokumentieren.

LG

pah




LG

pah

[Dirk]

Klar mag ich dass du dich wieder beteiligst! Danke für das Angebot. Wie wäre es, wenn wir es in einem Git machen und ich dich freischalte?
Minor Änderungen und Weiterentwicklung macht jeder allein. Major Themen sprechen wir per Mail oder Chat ab?

Das klingt gut, Das können wir so machen.
Dann könnte ich auch mal versuchen den Universalsensor-Code zu portieren. Dann haben wir auch gleich ein praktischen Test.

[trilu]

@pah - sorry, wollte dir nicht zu nahe treten - Kenner des HM Protokolls und der Lib.
Die Systematik der AskSin sollte eigentlich nicht die große Rolle spielen, das ist ja etwas, was ich von Modulentwicklern fern halten will.
Schau dir mal die Dummy Class an, alle Messages die für ein Modul relevant sind, werden an den Dummy (Relay, Switch) gerouted und nur diese müssen beantwortet werden. Dokumentation des ganzen ist auch in der Dummy Class drin. Nicht ausführlich aber zumindest als grobe Beschreibung. Standard Messages wie Pairing, Peering, Register read and write, config status, etc. werden autonom von der AskSin beantwortet, also ohne User Eingriff.
Aber wie gesagt, ich wollte in keinster Weise deine fachliche Kompetenz angreifen.
Ich lass dir die Tage mal kommentierte Protokollmitschnitte der Kommunikation zukommen.
Zur HAL, ich denke die HAL ist sogar kleiner und performanter als Arduino. Ich spreche die HW ja direkt an, aber halt aus Funktionsblöcken die in der HAL zusammen laufen. Bei anderer HW wird nur in der HAL ein weiteres Register oder Port oder was auch immer in die Funktion oder Makro eingetragen. Bin aber für Ratschläge dankbar!

@Dirk - Klasse, ich schalte dich frei.
Kannst du beim portieren vom Code Sensor drüber nachdenken wie wir das Messen der Werte in den User Sketch bekommen?
So dass das Sensor Modul möglichst universell wird. Ich stelle mir vor, dass dem Sensor Modul zwei Funktionspointer übergeben werden - einer fürs Init und einer fürs Messen - in der Messfunktion wird dann einfach nur noch ein Array befüllt und an die Sensor Class zurück gegeben. Nutzt du eigentlich irgendeinen Chat, Google, ICQ?

[Prof. Dr. Peter Henning]

OK, ich schau es mir mal an.

LG

pah

[Dirk]

Kannst du beim portieren vom Code Sensor drüber nachdenken wie wir das Messen der Werte in den User Sketch bekommen?
So dass das Sensor Modul möglichst universell wird. Ich stelle mir vor, dass dem Sensor Modul zwei Funktionspointer übergeben werden - einer fürs Init und einer fürs Messen - in der Messfunktion wird dann einfach nur noch ein Array befüllt und an die Sensor Class zurück gegeben.

ja, das sollte universell gehalten werden. Aber im Moment bekomme ich den Code erst mal nicht kompiliert. Dazu hebe ich das HM_LC_SW1_BA_PCB - Beispiel benutzt.

Code Auswählen Erweitern

E:/Projekte/Elektronik/Arduino-Libs/AskSin-Lib_NEW/EEprom.cpp:482: error: pointer of type 'void *' used in arithmetic
E:/Projekte/Elektronik/Arduino-Libs/AskSin-Lib_NEW/EEprom.cpp:482: error: pointer of type 'void *' used in arithmetic


[trilu]

mhhh - das müsste diese zeile sein?

if (*(uint8_t*)(ptr+len-1) != 0) return 0;

sollte aus meiner sicht funktionieren. pointer ist void, ich addiere den wert aus uint8_t und ziehe 1 ab um den pointer zu positionieren.
mit *(uint8_t*) wandle ich den inhalt des pointer zu einem byte wert.

teste mal damit:

Code Auswählen Erweitern

uint8_t  isEmpty(uint8_t *ptr, uint8_t len) {
do {
if (*(ptr+len-1) != 0) return 0;
len-=1;
} while (len>0);
return 1;
}

[MarcelK]

mhhh - das müsste diese zeile sein?

if (*(uint8_t*)(ptr+len-1) != 0) return 0;

sollte aus meiner sicht funktionieren. pointer ist void

Nein, Addition ist auf void nicht definiert. Void kann man eigentlich nur casten und sonst nichts.

Code Auswählen Erweitern

uint8_t  isEmpty(uint8_t *ptr, uint8_t len) {
do {
if (*(ptr+len-1) != 0) return 0;
len-=1;
} while (len>0);
return 1;
}

Ist len immer garantiert >0 beim Aufruf? Sonst müsste eine kopfgesteuerte while Schleife her. Ansonsten sollte es so passen.

Grüße, Marcel

[trilu]

Hi Marcel,
ich nutze die Funktion nur um zu Checken, ob ein ByteArray überhaupt einen Wert entält. Void hatte ich eingesetzt um das Ding universal nutzen zu können. Was mir nicht einleuchtet, warum ich zu einem void pointer nichts addieren kann, bzw. warum mein Kompiler nicht gemeckert hat
Viele Grüße
Horst

[MarcelK]

ich nutze die Funktion nur um zu Checken, ob ein ByteArray überhaupt einen Wert entält. Void hatte ich eingesetzt um das Ding universal nutzen zu können. Was mir nicht einleuchtet, warum ich zu einem void pointer nichts addieren kann, bzw. warum mein Kompiler nicht gemeckert hat

Naja, +1 auf einen Int32_t* erhöht den Pointer-Wert um 4, da es bei der Addition nicht um Bytes geht sondern um Elemente. Void hat keine Größe, daher ist das nicht definiert. Wieso Dein Compiler nicht gemeckert hat wundert mich aber auch sehr

Soll der Funktions-Prototyp weiterhin universell bleiben dann musst Du den Cast erst auf den Pointer machen:

Code Auswählen Erweitern


uint8_t  isEmpty(void *ptr, uint8_t len) {
while (len > 0) {
len--;
if (*((uint8_t*)ptr+len) != 0) return 0;
}
return 1;
}

Durch das Vorziehen von len-- sparst Du Dir noch ne Subtraktion. Evtl würde das aber ein optimierender Compiler so oder so machen.

Viele Grüße, Marcel

[trilu]

hättest du nicht lust mit an der asksin zu arbeiten?
so ein codereview und optimierung könnten nicht schaden?

schalte dich auch gerne für den github frei

[trilu]

@pah
Anbei ein Beispiel zur Kommunikation.
So läuft das Pairen mit einem "HM-LC-Sw1-Ba-PCB" (Funk-Schaltaktor, 1fach, Platine, Batterie) ab:

Code Auswählen Erweitern


-> 0D 26 84 10 1F B7 4A 00 00 00 06 01 00 80 (342544)
   INFO_ACTUATOR_STATUS; cnl: 01, status: 00, na: 80

<- 1A 27 84 00 1F B7 4A 00 00 00 15 00 6C 4B 45 51 30 32 33 37 33 39 36 10 41 01 00 (350420)
   DEVICE_INFO; fw: 15, type: 00 6C, serial: 4B 45 51 30 32 33 37 33 39 36
              , class: 10, pCnlA: 41, pCnlB: 01, na: 00

-> 10 01 B0 01 63 19 63 1F B7 4A 00 05 00 00 00 00 00 (351263)
   CONFIG_START; cnl: 00, peer: 00 00 00, pCnl: 00, lst: 00

<- 0A 01 80 02 1F B7 4A 63 19 63 00 (351382)
   ACK

-> 13 02 A0 01 63 19 63 1F B7 4A 00 08 02 01 0A 63 0B 19 0C 63 (351454)
   CONFIG_WRITE_INDEX; cnl: 00, data: 02 01 0A 63 0B 19 0C 63

<- 0A 02 80 02 1F B7 4A 63 19 63 00 (351571)
   ACK

-> 0B 03 A0 01 63 19 63 1F B7 4A 00 06 (351639)
   CONFIG_END; cnl: 00

<- 0A 03 80 02 1F B7 4A 63 19 63 00 (351762)
   ACK

-> 10 04 A0 01 63 19 63 1F B7 4A 00 04 00 00 00 00 00 (351834)
   CONFIG_PARAM_REQ; cnl: 00, peer: 00 00 00, pCnl: 00, lst: 00

<- 16 04 A0 10 1F B7 4A 63 19 63 02 02 01 05 00 0A 63 0B 19 0C 63 12 69 (351964)
   INFO_PARAM_RESPONSE_PAIRS; data: 02 01 05 00 0A 63 0B 19 0C 63 12 69

-> 0A 04 80 02 63 19 63 1F B7 4A 00 (352082)
   ACK

<- 0C 05 A0 10 1F B7 4A 63 19 63 02 00 00 (352208)
   INFO_PARAM_RESPONSE_PAIRS; data: 00 00

-> 0A 05 80 02 63 19 63 1F B7 4A 00 (352331)
   ACK

<- 0C 05 A0 10 1F B7 4A 63 19 63 02 00 00 (352497)
   INFO_PARAM_RESPONSE_PAIRS; data: 00 00

-> 0A 05 80 02 63 19 63 1F B7 4A 00 (352618)
   ACK

-> 10 0E A0 01 63 19 63 1F B7 4A 01 04 00 00 00 00 01 (352891)
   CONFIG_PARAM_REQ; cnl: 01, peer: 00 00 00, pCnl: 00, lst: 01

<- 0C 0E A0 10 1F B7 4A 63 19 63 03 08 00 (353012)
   INFO_PARAM_RESPONSE_SEQ; offset: 08, data: 00

-> 0A 0E 80 02 63 19 63 1F B7 4A 00 (353139)
   ACK

<- 0C 0F A0 10 1F B7 4A 63 19 63 03 00 00 (353265)
   INFO_PARAM_RESPONSE_SEQ; offset: 00, data: 00

-> 0A 0F 80 02 63 19 63 1F B7 4A 00 (353387)
   ACK

-> 0B 17 A0 01 63 19 63 1F B7 4A 01 03 (353656)
   CONFIG_PEER_LIST_REQ; cnl: 01

<- 0E 17 A0 10 1F B7 4A 63 19 63 01 00 00 00 00 (353783)
   INFO_PEER_LIST; peer1: 00 00 00 0000 01 0B 190C 63 12 6910 41 01 00

-> 0A 17 80 02 63 19 63 1F B7 4A 00 (353907)
   ACK


Reicht dir das auf dem Level oder brauchst du mehr Kommentare?

Viele Grüße
Horst

[Prof. Dr. Peter Henning]

Reicht erstmal.

LG

pah