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

[unimatrix]

dimmen natürlich nur in dem ich den Taster des Aktors mit einem Dimmaktor gepeert habe...

Ich habe mir x Krücken in den Code gebaut nachdem ich an ein paar Dingen verzweifelt war ...ich werde das heute aufräumen und dann eine Version hier posten. Vieles fehlt aber noch. So muss die Strommessung auch in eine eigene Power-Klasse oder so ausgelagert werden...

Für das Dimmen selber kommt dann eine Dimmer-Klasse. Die muss die ganzen Rampen usw. können. Die virtuellen Kanäle der UP-Dimmer müssten auch zumindest schonmal bedacht werden.

Ich habe selbst keinen Rolladenaktor aber erst ist ja einer der 3 Schwester-Aktoren: Schaltaktor, Dimmer und Rolladenaktor. Ich habe einige der Dimmer, aber keinen Rolladenaktor. Auch hier sollte es nur die BlindActuator Klasse benötigen und dann kann das eingebaut werden.

[mmattern]

Mit GCC 4.6 sollte der Code davor auf jeden Fall und der danach eigentlich auch laufen.

Hi Jan,

ich vermute, dass das aktuelle Problem nicht an GCC 4.6 vs 4.8 liegt - ich habe es mit beiden probiert, und es funktioniert nicht...
Ich vermute im Moment ja, dass auf deinem "Bastel-Notebook" entweder irgendeine Library in einer anderen Version vorliegt, ggf. ein Compile-Setting anders gesetzt ist, irgendein arduino-File anders aussieht o.ä.

Aber das werden wir ja bald wissen

[trilu]

Ich habe in den Sourcen eine dummy class, da muss eigentlich nur der Usercode rein. Alles Andere wird im Hintergrund von Asksin erledigt. Bin gerade dabei an der Asksin zu schrauben. Mir gefällt da einiges noch nicht. Ich versuche aber die dummy class so beizubehalten.
Viele Grüsse
Trilu

[unimatrix]

@unimatrix: Ein update auf die aktuelle Firmware will ich auch noch machen für den Aktor. Hast du das fertig? Wenn ja können wir das gerne auch auf github packen (je nach Status erstmal als Branch).

ich HATTE heute morgen gegen 2 Uhr nachts eine Version, in der das passende Channel-Layout drin war (mit destillRegs neu gebaut), 2 Remotes, 2 Switches, die funktioniert hat. Man konnte peers konfigurieren (auch mit sich selbst) und in der Switch-Funktion habe ich einfach nur die LED geschaltet. Es war keine Stromerkennung etc. drin, ich denke das muss in eine eigene Klasse.

Allerdings (!!) habe ich am Code geändert und es geht jetzt nicht mehr. Ich habe mich die letzten 2 Stunden damit beschäftigt die änderung zu finden die es "kaputt gemacht hat". Ich bin jetzt im Zustand dass der uC immer beim Init des CC110x einfriert. Ich bin also gerade in einer Verzweiflungsphase.

Ich fliege gegen 15 Uhr für 3 Tage nach Dänemark und kann da nix machen. Bevor ich gehe poste ich gerne nochmal meinen jetzigen Code, auch wenn er nicht läuft.

Sobald ich was laufendes habe lege ich mir ein lokales GIT an usw...alles andere kostet nur Nerven. Muss mich damit beschäftigen da ich mich mit Github usw. noch nicht so auskenne.

[Mr. P]

Hej,

drei Dinge, die vielleicht noch auf die Todo-Liste sollten:

*) Button_1 sendet derzeit beim Loslassen kein LongRelease
*) Das Sendeintervall für den aktuellen Stromverbrauch sollte irgendwie einstellbar sein oder zumindest fix im Code höher gestellt werden. Auch der Zwischenstecker (HM-ES-PMSw1-Pl) übermittelt nur alle 90 Sekunden seine aktuellen Daten. Da scheinen mir die 20 Sekunden, in denen der Schalter ständig seinen aktuellen Verbrauch übermittelt, doch etwas überzogen
*) Scheint es, als wäre 'statusRequeset' noch nicht im Schalter implementiert. Das führt beim Neustart von FHEM immer zu einem MISSING ACK, da die Anfrage zwar raus geht - der Schalter diese aber vermutlich verwirft, da er damit nichts anfangen kann.

Wäre toll, wenn ihr das noch mit auf die Liste packen könntet!

Thx a lot!

[unimatrix]

so, habe den Fehler gefunden. Wie immer total blöd.

Ich habe nun ein eigenes GIT-Repository erstellt. Ich hoffe dies ist im Sinne der Urheber des Sourcecodes. Ansonsten teilt es mir bitte mit. Mir geht es nur darum, möglichst gemeinsam hier weiter dran zu arbeiten.

https://github.com/unimatrix27/HM-LC-Sw1PBU-FM-CustomFW

Dort ist jetzt eine lauffähige Version. Einzig die Stromerkennung ist nicht implementiert. Peering, Schalten, Buttons usw. geht alles (und wird ja zu 99% über die Lib abgedeckt).

ich habe die Register.h mit dem aktuellen Perl-Script neu erstellt. Die eigentliche .ino - Datei ist jetzt extrem minimal, da ja alles in der Lib schon drin ist.

Der Stand  ist als experimenteller Arbeitsstand zu verstehen.

Nochmals vielen Dank für die Schaltpläne, damit habe ich den Fehler entdeckt den ich drin hatte (ein Rätsel wieso es vorher jemals lief...)

@Mr. P: Deine Punkte 1 und 3 sind mit der aktuellen Lib schon abgedeckt.

[Mr. P]

@Mr. P: Deine Punkte 1 und 3 sind mit der aktuellen Lib schon abgedeckt.

Großartig, danke. Wird morgen dann gleich geflasht, sobald ich wieder daheim bin.

Und viel Spaß in Dänemark (ich hoffe, es ist ein erholsamer Aufenthalt)!

[unimatrix]

da musst du nicht mir danken. ich hab das nicht eingebaut

es ist weit entfernt von fertig für den Produktiveinsatz. Zum testen gerne, aber ich bin sicher vieles ist buggy.

[Mr. P]

da musst du nicht mir danken. ich hab das nicht eingebaut

es ist weit entfernt von fertig für den Produktiveinsatz. Zum testen gerne, aber ich bin sicher vieles ist buggy.

Nun ja... Dann dank dem bzw. denen, die diese Punkte bereits umgesetzt haben.

[mmattern]

*) Das Sendeintervall für den aktuellen Stromverbrauch sollte irgendwie einstellbar sein oder zumindest fix im Code höher gestellt werden. Auch der Zwischenstecker (HM-ES-PMSw1-Pl) übermittelt nur alle 90 Sekunden seine aktuellen Daten. Da scheinen mir die 20 Sekunden, in denen der Schalter ständig seinen aktuellen Verbrauch übermittelt, doch etwas überzogen

eigentlich ist das komisch...

In https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/blob/master/Asksin_HM_LC_Sw1PBU_FM.ino findet sich dieser Code in der "loop()"-Funktion:

Code Auswählen Erweitern

if (millis() - lastCurrentInfoSentTime > sendSensorIntervalSec * 1000) {, sendSensorIntervalSec steht auf 150 - d.h. etwa alle 2:30 Minuten müsste gesendet werden...

millis() macht dabei laut Arduino-Dokumentation (http://arduino.cc/en/Reference/millis) genau, was der Name vermuten lässt: Millisekunden messen (Überlauf ca. alle 50 Tage).

Ansonsten wird im Code direkt danach

Code Auswählen Erweitern

if (millis() - lastCurrentSenseTime > 500) {
                cli();
lastCurrentSenseTime = millis();

                // Calculate current sense boolean: 500ms*50Hz = 25 Impulses
                boolean currentSense = lastCurrentSenseImpulsLength > (25 * minImpulsLength);
                lastCurrentSenseImpulsLength = 0;

                // Act on changes
                if (currentSense != lastCurrentSense)
                {
                  rl[1].setCurStat(currentSense?3:6);
//                  Serial << F("New Powersense: ") << currentSense << '\n';
//                  hm.sendInfoActuatorStatus(4,currentSense?0xC8:0x00,0);
                  lastCurrentSense = currentSense;
                }
                sei();

zweimal pro Sekunde geprüft, ob ein Stromimpuls von mindestens 125ms Länge vorliegt bzw. ob einer vorlag und nun nicht mehr... Bei Änderung wird "setCurStat" des Fake-Relays, das den Current-Sensor repräsentiert, aufgerufen (class RL in AskSin.cpp).
setCurStat setzt wiederum den cbsTme (ein Timer, bei dessen Ablauf durch void RL::poll_cbd(void) der ActuatorStatus gesendet wird; poll_cbd() wird innerhalb RL::poll() aufgerufen, und das wiederum innerhalb der loop()-Funktion) auf

Code Auswählen Erweitern

cbsTme = millis() + ((uint32_t)mDel*1000) + random(((uint32_t)rDel*1000));

mDel und rDel sind in setup() innerhalb https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/blob/master/Asksin_HM_LC_Sw1PBU_FM.ino  jeweils auf 1 Sekunde gesetzt (die letzten beiden Parameter):

Code Auswählen Erweitern

rl[1].config(4,&relayState,&setVirtualRelay,&hm,1,1);

Also wird alle ca. 1-2 Sekunden ein Update gesendet, wenn denn eine Änderung vorliegt.

Frage ist nun also - ist das so erwünscht - einerseits nur alle ca. zweieinhalb Minuten ein Update zu senden, andererseits den Actuator-Status ca. alle 1-2 Sekunden zu senden.

Mir persönlich ist wichtig, eine Änderung des Current-Sensors schnell zu bekommen (insbesondere von Null auf Stromfluss) für meine Wechselschaltung, aber wenn sich nichts ändert, wäre Funkstille klasse...

Eigentlich dann aber auch wieder merkwürdig, dass so häufig Updates gesendet werden, wenn der "Current"-Status stabil ist...

Habe ich noch eine Stelle in der Logik übersehen?

[unimatrix]

ist mir auch aufgefallen. 150 sekunden sind "eingestellt" er sendet aber auch ohne Änderung alle ca. 18 Sekunden. Habe die Logik so verstanden wie du,

Bin aber gerade noch bei anderen Feinheiten. die Relaisklasse prüft beim trigger 40 den Event-Counter. Ist der identisch mit dem vorhergehenden Event, wird von einem Resend ausgegangen (an sich sinnvoll). Im speziellen Fall dieses Aktors ist es aber ja ganz typisch, dass ein Aktor mit 2 Remotes bedient wird, eine für aus, eine für ein. Nach stromlos ist der Counter beider Remotes auf 0. Das führt zunächst mal dazu, dass der erste Tastendruck nach stromlos immer ignoriert wird (weil cnt == msgRcvCnt). Jetzt habe ich zwar eingebaut, dass er nach stromlos beim ersten mal IMMER reagiert, das löst aber nicht das Problem, dass sich die Counts der beiden Taster immer wieder schneiden können.

Beispiel

Btn1: Cnt: 00 -> schaltet -> Relais merkt sich Cnt 00

Btn2 steht noch auf 00 -> keine Reaktion weil Cnt schon == 00

Btn 2 man drückt nochmal, er schaltet -> Cnt = 01

Btn 1 man will wieder Licht an machen -> Cnt ist schon 01 - schaltet wieder nicht.

Bin mir noch nicht klar wie man beides erreichen kann. Der Quellkanal ist dem Relais ja unbekannt ...

Edit: irgendwo muss die Information ja sein um welchen Peer es sich handelt, dann könnte man sie unabhängig betrachten....aber ich werde aus diesem ptrPeerList - Ding noch nicht schlau

[mmattern]

Edit: irgendwo muss die Information ja sein um welchen Peer es sich handelt, dann könnte man sie unabhängig betrachten....aber ich werde aus diesem ptrPeerList - Ding noch nicht schlau

Hallo unimatrix,

ist es nicht viel einfacher?
HM_RemoteEvent aus dem .ino-File macht das so:

Code Auswählen Erweitern


        void HM_Remote_Event(uint8_t cnl, uint8_t *data, uint8_t len) {
// message from a remote to the client device; this event pop's up if the remote is peered
// cnl = indicates client device channel
// data[0] the remote channel, but also the information for long key press - ((data[0] & 0x40)>>6) extracts the long key press
// data[1] = typically the key counter of the remote
        #if defined(USE_SERIAL)
Serial << F("\nRemote_Event; cnl: ") << pHex(cnl) << F(", data: ") << pHex(data,len) << "\n\n";
        #endif
if (cnl == 3) rl[0].trigger40(((data[0] & 0x40)>>6),data[1],(void*)&regMC.ch3.l3);
if (cnl == 4) rl[1].trigger40(((data[0] & 0x40)>>6),data[1],(void*)&regMC.ch4.l3);


In data[0] wird der Remote-Channel mitgeliefert - müsste man dann nicht einfach das unveränderte data[0] bzw. die extrahierte Channel-Information in einem weiteren Parameter für trigger40 übertragen?
Gibt es irgendwo eine Doku, in welchen Bits der Channel genau steckt?



Zusätzlich zur Counter-Thematik:
Hier in AskSin.cpp wird der cnt-Wert des letzten Aufrufs in rCnt aufgehoben - vor dem allerersten Aufruf ist der Wert undefiniert, man sollte ihn vielleicht lieber mit 0 initialisieren...

Code Auswählen Erweitern

void RL::trigger40(uint8_t lngIn, uint8_t cnt, void *plist3) {
s_peer_regChan_actor* srly = (s_peer_regChan_actor*)plist3; // copy list3 to pointer
static uint8_t rCnt;

[mmattern]

Ich frage mich gerade, nachdem ich mir nochmal den Schaltplan angeschaut habe: Wieso wird in der Firmware Pin 31 für den Stromsensor gesetzt, wo es doch eigentlich Pin 37 (PA0) sein müsste? Der PinChange-Interrupt wird auf PA0 gesetzt, aber Werte werden über Pin 31 abgefragt... der unbeschaltet ist... und trotzdem funktioniert die FW ja...

In https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/blob/master/Asksin_HM_LC_Sw1PBU_FM.ino:

Code Auswählen Erweitern

const uint8_t pinCurrent = 31;

und dann später das Lesen in impulsCurrent():

Code Auswählen Erweitern

boolean actualCurrentPin = digitalRead(pinCurrent);

?

[unimatrix]

laut der pin_arduino.h in dem von JAB erstellen "Jabduino" Target für den 644a ist Digital Pin 31 = PA0.

Bin mit den ganzen Pinmappings auch zunächst durcheinander gekommen. Die Nummern im Schaltplan sind die PINS von PIN1 an durchgezählt, Pin 37 ist hier PA0 im TQFP Gehäuse.

Kann nun, da ich inzwischen am flughafen MUC hocke, nur noch trocken arbeiten. Jetzt bräuchte ich den vollautomatischen "Reboot-Loader" dann würde ich einfach über Internet flashen  und debuggen ...

Was die Counts usw. angeht, kann ich das in der alten Version schon sehen und nachvollziehen. Aber in der "neuen" Lib ist das ja alles in eigenen Klassen. Was mit Sicherheit auch sehr gut ist. Aber da muss ich noch durchsteigen. Es geht  hier konkret um die Methode Relais::trigger40 in der Relais.cpp. Vll. bekomme ich im Flieger die erleuchtung...

[jab]

Hi unimatrix,

das sieht ja schon sehr gut aus. Da das auf der aktuellen Version aufbaue können wir meinen Kram dann als obsolet markieren sobald alle Features portiert sind. Fehlen noch Unit Tests und dann bin ich glücklich.

Beim Bootloader glaube ich nicht, dass mein Setup besonders ist. Normales 64Bit Ubuntu + eine aktuelle Arduino IDE. Ich probiere es aus.


Gruß,
Jan