Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[trilu]

Kannst du mir mal ein Beispiel geben wie Unit Tests aussehen? Bin gerade dran die Lib zu überarbeiten.
Register.h entflechten, mit der Senderoutine bin ich auch noch unzufrieden und auch mit dem Gesamtspeicherverbrauch...
Aber wenn ich das mit den unit tests kapiere, dann kann ich ja auch gleich testen 

[unimatrix]

frage mich auch wie die Unit Tests dafür aussehen sollen. Bzw. für welche Units genau. Auf Klassenebene oder auf Deviceebene. Auf Deviceebene könnte man sicher alle Messages, usw. durchrattern. Klingt ziemlich aufwendig...

@Trilu hast du selbst die FastDelegate eingebunden? Das ist ein Level zu hoch für mich und da verliere ich mich auch beim Verständnis, wie die List3 in die Relais reingelangt damit die Relais-Instanz die entsprechenden Parameter zugehörig zum auslösenden Peer kennt. Auf alle Settings der List3 kann man ja dort zugreifen. Aber wie kommt die RICHTIGE List3 da rein? Ich fände es gut wenn die Relaisinstanzen beim Prüfen auf eine Messagewiederholung auch prüfen, dass der sendende Kanal identisch ist. Wenn nur der Count überprüft wird, dann kommt es zu Überschneidungen und unerwünschtem Verhalten (NICHT-Schalten) - dies natürlich vor allem beim HM_LC_Sw1PBU_FM.

Edit: nach genaurem Durcharbeiten bin ich der Meinung, dass das Checken des Counts in der Relay Klasse redundant ist und nur bei den internen Tastern greifen würde (wo man es ja nie will). In der HM Klasse werden doch schon beim Empfangen doppelte Nachrichten verworfen.

@Jab: habe mit der Portierung der Strommessung weitermacht aber ich kann es erst Donnerstag abend wieder testen. Ehrlich gesagt ist mir im Moment nicht klar wieso es überhaupt funktioniert. Also die Messung selbst ist klar. Aber das Schalten des VirtualRelais. Wo da mit berücksichtigt wird, ob gerade Strom fließt oder nicht. Abgesehen davon ist der direkte Zugriff auf den nxtStat in der Relais-Klasse so nicht mehr möglich. Vll gibts ne andere Lösung aber mir ist gerade gar nicht klar, wieso das überhaupt zu dem Verhalten führt, den dein Code ja richtigerweise hat.

Es ist für mich ok, sobald alles portiert ist, das von mir angelegte Repository zu nehmen. Es wird aber irgendwann Zeiten geben, wo ich längere Zeit daran nicht aktiv sein kann. Kann man den Zugriff auf so ein GIT Repository für andere "ausgesuchte" Personen freigeben? Naja da findet sich dann später eine Lösung.

Edit: Die Strommessung und das Melden der Sensorwerte ist jetzt im GIT. Ob es funktioniert, kann ich im Moment nicht testen.

[jab]

Abend,

Mehr Maintainer ist immer gut. Bin ich gerne dabei.

Bzgl Strommessung gibt es einfach einen Schwellwert und wenn der erreicht wurde setzte ich den Status des virtuellen Aktors. Die Klasse erledigt dann den Rest.

In den Unit Tests würde ich die einzelnen Funktionen der Klassen testen. Jeweils die anderen Teile würde ich mocken. Also in der Relay Klasse würde ich die State Machine testen. In der Homematic Klasse die Generierung der Nachrichten etc. Alles direkt mit cppunit und ohne Arduino oder echte Hardware.


Gruß
Jan

[unimatrix]

ich habe nochmal den Bootloader mit einem neuen Setup gebaut. Ging immer noch nicht. Aber mir ist aufgefallen dass der String "Waiting for CB" message über UART geschickt wird.

Beim funktionierenden Bootloader kommt dieser String nicht. Es kann sich also nicht um die aktuelle Master-Version aus dem GIT handeln. Der String wurde beim letzten Commit eingebaut - neben anderen Änderungen.

habe nun x vorherige Commits durch aber ich bekomme keinen Empfang hin. Wer hat denn wann das laufende Binary gebaut?

Update: Nach dem durchgehen aller letzten Änderung im Detail habe ich nun eine übersetzbare Version, die auch läuft. Man kann per OTA einspielen, das ganze läuft auch nach mehreren malen stromlos noch, und mann kann erneut einspielen.

[unimatrix]

@Jab: beim portieren der letzten Funktionen bin ich noch in einer Denkblockade angekommen. Letztlich habe ich dann auch das Verhalten der letzten Firmware von dir nicht mehr verstanden.

Ich habe keine Wechselschaltung hier, aber ich habe mal versucht das durch "herausdrehen" des Leuchtmittels zu simulieren.

Ich hatte eigentlich folgendes Verhalten vermutet:

Der virtuelle Kanal zeigt immer dann "ON" an, wenn auch tatsächlich Strom über dem Schwellwert fließt. Schaltet man das Licht über einen mechanischen Schalter in der Kreuz/Wechselschaltung aus, habe ich angenommen, würde sich auch der Zustand dieses virtuellen Kanals von ON auf OFF ändern. So dass er dann eben bei einem erneuten "on"-Befehl auch das Relay tatsächlich wieder schaltet.

Das würde aber auch bedeuten, dass der Zustand des Kanals sich erst dann ändern kann, wenn die Strommessung durch ist. Dies dauert ja aufgrund des Mittelns eine Weile (oder?). Wenn man alsoas auf ON "drückt" (sagen wir mal per Peer der als JT alles auf "on" hat) und macht dies 2 mal kurz hintereinander, müsste das Relais ja womöglich sogar 2 mal schalten (denn nach dem 1. Mal war noch nciht genug Zeit, um den Stromfluss zu registrieren und den Status entsprechend zu ändern)

Was von meinen Annahmen/Erwartungen ist falsch?

Die Strommessung als solches hab ich drin, das klappt. Aber ich verzweifle an den Status der Kanäle und den entsprechenden Schaltaktionen.

[mmattern]

Update: Nach dem durchgehen aller letzten Änderung im Detail habe ich nun eine übersetzbare Version, die auch läuft. Man kann per OTA einspielen, das ganze läuft auch nach mehreren malen stromlos noch, und mann kann erneut einspielen.

Hallo unimatrix,

d.h. du kannst jetzt einen Bootloader bauen? Woran lag's denn jetzt am Ende?
Bin super gespannt...

[unimatrix]

wenn man das sei() vor dem Init des CC entfernt, dann geht es. Ich nehme an, der CC generiert undefiniertes Zeug auf der Leitung, wenn er nicht ordentlich initialisiert wird. Das erklärt ggf. auch wieso das ganze nur nach einem Power-Cycle auftrat.

In früheren Versionen wurden die Interrupts auch vorher nicht aktiviert. Ich nehme an es ist ein Bug der bei dem Rafactoring entstanden ist.

Beschäftige mich gerade mit dem Reboot-Thema, da ich ja jetzt den BL bauen kann. Der Reboot selber klappt prima, aber nun versuche ich den FHEM Teil zu verstehen, damit man ein Reboot per FHEM senden kann.

[unimatrix]

Ich habe nun einen Watchdog-Reset eingebaut mit

Code Auswählen Erweitern


void softReboot(uint8_t *data, uint8_t len) {
  softRebootSer();
}

void softRebootSer(){
   wdt_reset();
    wdt_enable(WDTO_2S);
  while(1);
}


so kann ich dann einen WD-Reset sowohl über UART als auch über fhem auslösen. von FHEM aus habe ich einfach mal Message 99 erfunden und per set RAW an das Device geschickt, diese Message 99 habe ich in der JumpTable der Applikation abgegriffen. Das klappt auch. Martin müsste hier vll. vorgeben, als welche Message sich so ein Reboot-Befehl einbauen lässt. Falls das gewünscht ist. Als RAW klappts natürlich auch. Braucht man ja nicht oft. Ansonsten könnte es mit ins fwUpdate nehme ich mal an. Das fwUpdate habe ich allerdings noch nie zum laufen bekommen.

Es gibt aber ein Problem. Sobald das Device dann reseted (im Beispiel oben immerhin erst nach 2 Sekunden, kommt es zu einem sehr schnellen Flackern der LED (ich würde mal sagen 6-7 mal pro Sekunde) - in den Bootloader hatte ich aber den Beginn von main() so wie unten modifiziert.

Code Auswählen Erweitern


int main()
{
// disable watchdog (used for software reset the device)
wdt_reset();
wdt_disable();
// Blink LED
DDRB = 0x01;  /* set pin 0 as output */


Vll hat jemand eine Idee. für heute gebe ich auf...

[frank]

Code Auswählen Erweitern

0A 0A 3011 123ABC ABCDEF CA
so sieht die msg von fhem zum booten des schalters aus. siehe http://forum.fhem.de/index.php/topic,23329.msg168582.html#msg168582

[unimatrix]

Danke, Frank. Dieser Thread war mir noch nicht bekannt.

Hatte eine solche Implementierung eines Reboots in der aktuellen AskSin Lib auch nicht gefunden. Schaus mir an...

(das Problem mit dem Bootloader hab ich doch gelöst. Es geht jetzt soweit alles und für mich ist das schon gut genug da ich ohne in den Keller zu gehen updaten kann. problem entsteht allerdings wenn das ota-flash aufgrund von Fehlern abbricht. Dann springt man in eine korrupte Applikation und kann nicht mehr soft-rebooten.

[frank]

Hatte eine solche Implementierung eines Reboots in der aktuellen AskSin Lib auch nicht gefunden. Schaus mir an...

bei asksin war das auch noch nicht vorhanden. jan wollte das im letzten bootloader/fw einbauen. ich hatte bisher auch keine gelegenheit das auszutesten. nun gibts ja bald schon was neues. 

problem entsteht allerdings wenn das ota-flash aufgrund von Fehlern abbricht. Dann springt man in eine korrupte Applikation und kann nicht mehr soft-rebooten.

man könnte der fw doch irgendeine checksumme mitgeben, sodass der bootloader den download vor dem starten der fw checken kann. notfalls wieder löschen und neu booten.

[unimatrix]

Das hier sieht vielversprechend aus:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=127852&start=0

ich schaus mir an...das könnte man ohne Änderung an den Update-Tools einbauen.

[frank]

nicht übel. 

wenn du dann noch lange weile hast, könntest du noch eine sperre für den softreboot einbauen. es gab, soweit ich mich erinnere, bedenken, dass der böse nachbar eventuell den schalter zerflasht. dazu könnte man ein register softrebootenable vorsehen, dass man vor dem softreboot erst aktivieren müsste. und für die ganz ängstlichen die möglichkeit den bootloader komplett für softreboot zu sperren, indem man solch eine bootloadervarante kompilieren kann. dazu wäre dann natürlich eine bootmöglichkeit über den configtaster komforttabel.

[unimatrix]

ok, den Nachbar möchte ich erstmal sehen, der 1. das notwendige Wissen und 2. die Boshaftigkeit hat, mir Homematic-Devices zu "zerfl(ei)ashen) ...haha.

werde versuchen es zu berücksichtigen.

In den BL muss ich beim Starten einen Checksum-Check einbauen, der dann bevor er in die App springt, den gesamten Flash liest. Dadurch dauert das Booten etwas länger - aber das sollte bei so einem Device wohl egal sein. Die Option muss man per #define abschalten können (zur Build-Zeit), damit auch Applikationen ohne Checksumme unterstützt werden.

Beim Bauen muss für die Applikation dann das .elf file post-prozessiert werden und eine Checksumme eingebaut werden. Da es für den Bootloader sowieso mit der avr-objcopy und der convert.php bearbeitet werden muss, lässt sich dieser Schritt da irgendwo mit einbauen.

Edit: CRC-Check ist eingebaut und läuft. Werde heute Abend den Code aufräumen dann hier den Link posten. Zum Einbauen des CRC16 in das Binaryfile muss man sich allerdings das Tool srecord installieren.

[unimatrix]

Update:

Der Bootloader in neuer Version ist nun im GIT verfügbar: https://github.com/jabdoa2/Asksin_OTA_Bootloader

Neue Funktionen:

- Reboot-Möglichkeit aus der Applikation wird unterstützt (durch Watchdog Disable beim Start des Bootloaders)
- Serial kann per #define im Header der bootloader.c angepasst werden
- CRC Check ist optional möglich (Default: aus). Dazu muss das Binary vorbereitet werden, Details im Readme auf dem GIT. Dies verhindert das Starten von nicht vollständig korrekt übertragenen Files. Der Bootloader schickt dann immer wieder einen CB Request. Durch diese Maßnahmen ist es nun möglich, die Schalter ohne jeden Eingriff vor Ort und ohne die Notwendigkeit, den Strom abzustellen, gezielt zu updaten.

Bugreports, Anregungen, etc. gerne hier oder im GIT.

@Frank: Die Sicherheitslücke entsteht nur dann, wenn die Applikation den Reboot auch anbietet. Das sollte in der LIB konfigurierbar gemacht werden. Kommt noch...