AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

Dietmar63

Zitat
In der Gerätebeschreibungs-XML vom HM-ES-TX-WM https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_es_tx_wm.xml sind diese zwei Messages definiert. Sie unterscheiden sich nur in der ID. Ich weiss auch nicht, welche wann zu verwenden ist. Beim Gas-Event ist es auch so. Dort versende ich GAS_POWER_EVENT_CYCLIC=0x53. Das scheint soweit gut zu funktionieren.

aber sie unterscheiden sich doch:
Gas: 32bit  0x53
counter >> 24
counter >> 16
counter >> 8
counter >> 0


Power: 24 bit 0x5e
counter >> 16
counter >> 8
counter >> 0


Wie kannst du das richtig gemacht haben, wenn du keinen Unterschied gesehen hast?

Ich habe mir das xml  mal angesehen. Ich kann nicht erkennen wie festgelegt wird wie lang ein Element sein soll.
Der einzige Unterschied zwischen GAS_POWER und POWER ist neben dem maxvalue:
<conversion type="float_integer_scale" factor="1000"/>

ZitatFür die Anpassung der PowerDown-Implementierung ist das Template-Argument Saver bei Activity::savePower() gedacht. Hier gibt es bisher die Implementierungen Idle und Sleep. Du kannst einfach eine neue Ableitung HighPrecisionSleep von Sleep machen, die dann doSleep() entsprechend implementiert. Da kann die Low-Power-Library auch komplett weg fallen.

Das ist ja eine klasse Idee - wäre ich vielleicht nie drauf gekommen. Hatte mir allerdings über die endgülitge Implementierung auch noch keine Gedanken gemacht. Wollte es nur ersteinmal zu Laufen bringen. Klappt schon einigermaßen, habe aber noch ein für mich unverständliches Problem, kann aber noch nicht erklären worin es genau besteht.

Danke Dietmar.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

papa

#46
Zitat von: Dietmar63 am 25 Oktober 2016, 09:40:47
Wie kannst du das richtig gemacht haben, wenn du keinen Unterschied gesehen hast?

Natürlich unterscheiden sich Gas und Power Messages. Aber es gibt sowohl für Gas als auch für Power 2 Messages, die sich nur durch den Typ unterschieden. Deshalb habe ich auch für Gas und Power jeweils 2 Klassen definiert. Ich kann aber nicht sagen, wann welche zu nutzen ist. Ich benutzte für meine Gaszähler die GasPowerEventCycleMsg (Type=0x53). Das scheint soweit gut zu funktionieren.

Zitat von: Dietmar63 am 25 Oktober 2016, 09:40:47
Ich habe mir das xml  mal angesehen. Ich kann nicht erkennen wie festgelegt wird wie lang ein Element sein soll.

Die Länge steht im size Attribute des Parameters. So bedeute 2.7 beim ENERGY_COUNTER 2 Byte und 7 Bit. Also das höchste Bit gehört nicht zum Counter. Das wird nähmlich für das BOOT Flag benutzt. Entsprechend ist der Index zu verstehen. So bedeutet 9.7 das 7te Bit im 9ten Byte der Message. Eigentlich könnte man den Code für die Listen und  Messages direkt aus den XML-Daten generieren. Das macht ja auch trilu in der NewAskSin.

Das Nachrichtenformat steht übrigens im frames Abschnitt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

lech

Könnt ihr bitte die Beschaltung nochmal kurz erklären.
Ich versuche gerade HM-RC-4 anzulernen, aber weder die LED noch das Serial reagieren auf den Pin-8 gegen die Masse.
Habe auch schon versucht Pin-8 mit dem Pin-3 zu verbinden und beide gegen die Masse, ohne Erfolg.
Im Serial kommt nur:

AskSin++ V0.1.0
CC init12.................3 - ready
*

Auf die A0-A3 (gegen die Masse) scheint er zu reagieren:

debounce
pressed
released

Aber das bringt mich nicht weiter, denn der Schalter muss erst angelernt werden!?
Danke schon mal im Voraus für eine kurze Rückmeldung

papa

Pin 8 gegen Masse ist richtig. Das ist der Config-Taster. Wenn dieser gedrückt wurde, sollte auf der Console eine Nachricht (DEVICE-INFO) zu sehen sein. Diese startet das Pairing mit FHEM.

Die anderen Taster sind (derzeit noch) mittels einer Diode zusätzlich an Pin 3 für den gemeinsamen Interrupt anzuschliessen. Das ist allerdings gar nicht wirklich nötig. Muss ich mal umbauen, wenn etwas Zeit ist. Diese scheinen ja aber bei Dir zu funktionieren.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

lech

Dann verstehe ich irgendwas nicht  ???

Ich nehme die gleiche Platine, spiele einen Sketch von der New AskSin ein, und schon kann ich die Hardware anlernen mit dem gleichen Pin-8.
Das funktioniert einwandfrei......

Kann das sein dass ich falsche Lib eingebunden habe? Denn beim Kompilieren fehlten ihm <PinChangeInt.h>
Ich habe die <PinChangeInterrupt by NicoHood> installiert und im Sketch auf #include <PinChangeInterrupt.h>  geändert.
Es fehlten noch zwei andere Libs  <Low-Power> und <TimerOne>, aber die gingen problemlos...

Hat jemand das gleiche Problem?

lech

#50
OK, war doch mein Fehler. Man muss die PinChangeInterrupt vom "GreyGnome", die im Github verlinkt, nehmen  :D

So, jetzt reagiert er auf Pin 8, nur anlernen an der CCU2 lässt er sich nicht.....
Die CCU2 sieht ihn leider nicht. Und wenn ich versuche über die Seriennummer manuel, dann kommt im Serial periodisch "waitAck: 00" und die Zentrale meldet nach paar Sekunden einen Fehler.
Schade eigentlich....
Ist momentan die Kommunikation nur mit FHEM möglich?

papa

Zitat von: lech am 27 Oktober 2016, 19:51:05
OK, war doch mein Fehler. Man muss die PinChangeInterrupt vom "GreyGnome", die im Github verlinkt, nehmen

Ja - bitte die verlinkten Libs installieren. Dann klappts auch mit der Software ...

Zitat von: lech am 27 Oktober 2016, 19:51:05
Ist momentan die Kommunikation nur mit FHEM möglich?

Hm - keine Ahnung. Habe keine CCU und entwickele nur mit FHEM. Aber gundsätzlich sollte es funktionieren.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

lech

irgendwie gefällt der CCU die Seriennummer nicht.
Ist es vielleicht aus einer bestimmten Zahlenkombination? ???

papa

Zitat von: lech am 27 Oktober 2016, 19:51:05
So, jetzt reagiert er auf Pin 8, nur anlernen an der CCU2 lässt er sich nicht.....
Die CCU2 sieht ihn leider nicht. Und wenn ich versuche über die Seriennummer manuel, dann kommt im Serial periodisch "waitAck: 00" und die Zentrale meldet nach paar Sekunden einen Fehler.

Kannst Du bitte mal alle Ausgaben der Console posten.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Dietmar63

Der Stromverbrauchzähler läuft. Die Zeit (hier eine Minute ) hält er ganz gut ein.
Problem sind und bleiben die Interrupts. Sie praktisch nicht in den Griff zu bekommen.
Ich habe viel probiert, aber leider wenig Erfolg gehabt. Jetzt wird der A. Alle 250ms geweckt und durch probieren habe ich es geschaft die Zeiten so aufzusummieren, dass nach einer Minute kaum eine Abweichung mehr vorlag.

Bei Interrupts habe ich mir nun gedacht dass dieser im Mittel immer in der Mitte eines wdt eintritt und bewerte ihn nun mit der halben Zeit. Das passt einigermaßen.

Also danke für das wirklich einfach zu verwenden Framework.
Ich habe einige Ideen, die auf Umsetzung warten


016.10.27 15:14:47 3: Nachricht von HM_441234_IEC_02: power: 1320
2016.10.27 15:13:48 3: Nachricht von HM_441234_IEC_02: power: 600
2016.10.27 15:12:48 3: Nachricht von HM_441234_IEC_02: power: 840
2016.10.27 15:11:49 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:10:51 3: Nachricht von HM_441234_IEC_02: power: 1680
2016.10.27 15:09:53 3: Nachricht von HM_441234_IEC_02: power: 1440
2016.10.27 15:08:54 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:07:56 3: Nachricht von HM_441234_IEC_02: power: 1680
2016.10.27 15:06:57 3: Nachricht von HM_441234_IEC_02: power: 2040
2016.10.27 15:06:57 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 15:05:59 3: Nachricht von HM_441234_IEC_02: power: 2160
2016.10.27 15:05:01 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:04:03 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 15:03:03 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 15:02:03 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 15:01:04 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 15:00:04 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:59:05 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:58:05 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:57:06 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:57:06 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 14:56:06 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:55:07 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:54:07 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:53:08 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:52:08 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:51:09 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:50:09 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:49:10 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:48:10 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:47:11 3: Nachricht von HM_441234_IEC_02: power: 120
2016.10.27 14:47:11 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 14:46:11 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:45:12 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:44:12 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:43:12 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:42:13 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:41:14 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:40:14 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:39:15 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:38:16 3: Nachricht von HM_441234_IEC_02: power: 240
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

papa

Das klingt doch gut. Könnte man den PowerDown-Code in die Lib mit aufnehmen ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Dietmar63

ja,
aber im Moment sieht der noch ziemlich hässlich aus. Ich bin in viele Probleme geraten, die ich zunächst nur provisorisch gelöst habe:


  • Korrektur per offset - nur auf Zentelsekunde, offsetRest eingeführt, um genauer aktualisieren zu können
  • durch Probieren herausgefunden, dass pro wdt250ms eine Korrektur von 177ms(ohne Interrupt) am genauesten funktioniert
  • Der Arduino wird bei einem Interrupt CHANGE zweimal kurz hintereinander aus dem LowPowermode  geweckt.
  • debounce() erzeugt neben dem schon laufenden Alarm mit 250ms einen weiteren Alarm auf Basis der debounce Zeit. Dieser Alarm hat mich lange Zeit irritiert. Ich dachte zunächst an einen Fehler
  • Bei meiner Idee den wdt durch LowPower.powerDown(SLEEP_FOREVER, ...) einfach weiterlaufen zu lassen wollte ich durch aktualisieren des aclock mit 0 kompensieren. Leider ist das nicht möglich weil das in aClock eine Korrekur nach sich zog. in aClock werden die ticks(0) um eins vermindert(ticks--), ticks-- wird dann zu ~4554455444556, und dann eingerechnet min(...)..., führt dazu,dass der Alarm abläuft. Das gleiche Problem tritt auch bei der aktuellen Lösung auf.

häßlich:


public:

  static uint8_t offsetRest;
  static bool wdtAbgelaufen;
  static bool lowPinFound;

...
    if( ticks == 0 ) {
      LowPower.powerDown(SLEEP_FOREVER,ADC_OFF,BOD_OFF);
    }
    else if (ticks2millis(ticks) > 300 ) {
      wdtAbgelaufen = false;
      lowPinFound   = false;
    //Serial << "Schlafen:" << "\n";
      waitSerial();
      LowPower.powerDown(SLEEP_250MS,ADC_OFF,BOD_OFF);
      if (wdtAbgelaufen) {
         offset = millis2ticks(100);
         offsetRest += 77;
       //Serial << "LPD:normal aufgewacht:" <<  offset << " " << offsetRest << "\n";
      }else{
         if (lowPinFound) {
            offset = millis2ticks(000);
            offsetRest += 50+35+4-20;
            Serial << "LPD:Interrupt aufgewacht:" <<  offset << " " << offsetRest << "\n";
         }else{
            offset = 0;
         }   
      }
    }

    radio.wakeup();
    if (offsetRest>=100) {
       offset += millis2ticks(100); offsetRest -= 100;
     //Serial << "offset erhöht:" <<  offset << " " << offsetRest << "\n";       
    }       
    return offset;
  }


Ach, was mir aufgefallen ist. Nachdem ich auf wdt 250ms umgestellt hatte, habe ich festgestellt, dass die kleine rote LED am A. nach jedem Weckruf ganz kurz, kaum wahrnehmbar aufblinkt, offensichtlich im Takt dieser 250ms aufblinkt.

Habe natürlich daran gedacht, dass es eventuell an meinem Code liegen könnte und habe dann herausgefunden, dass es in radio.setIdle(); passiert. Jenes Modul habe ich dann nicht weiter untersucht.:


void    CC1101::setIdle() { // put CC1101 into power-down state
strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
//strobe(CC1101_SFRX);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}


Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

papa

Zitat von: Dietmar63 am 28 Oktober 2016, 01:33:41
  • Korrektur per offset - nur auf Zentelsekunde, offsetRest eingeführt, um genauer aktualisieren zu können
Die Auflösung des Timers kannst Du in AlarmClock.h durch ändern von TICKS_PER_SECOND einstellen/erhöhen
Zitat
  • Der Arduino wird bei einem Interrupt CHANGE zweimal kurz hintereinander aus dem LowPowermode  geweckt.
Steigende und fallende Flanke
Zitat
  • Bei meiner Idee den wdt durch LowPower.powerDown(SLEEP_FOREVER, ...) einfach weiterlaufen zu lassen wollte ich durch aktualisieren des aclock mit 0 kompensieren. Leider ist das nicht möglich weil das in aClock eine Korrekur nach sich zog. in aClock werden die ticks(0) um eins vermindert(ticks--), ticks-- wird dann zu ~4554455444556, und dann eingerechnet min(...)..., führt dazu,dass der Alarm abläuft. Das gleiche Problem tritt auch bei der aktuellen Lösung auf.
Hm - die Korrektur hat ein paar Randbedingungen, die sollte man besser dokumentieren bzw. die Fehlerfälle mit halbwegs sinnvollem Code behandeln.

Zitat
Ach, was mir aufgefallen ist. Nachdem ich auf wdt 250ms umgestellt hatte, habe ich festgestellt, dass die kleine rote LED am A. nach jedem Weckruf ganz kurz, kaum wahrnehmbar aufblinkt, offensichtlich im Takt dieser 250ms aufblinkt.

Habe natürlich daran gedacht, dass es eventuell an meinem Code liegen könnte und habe dann herausgefunden, dass es in radio.setIdle(); passiert. Jenes Modul habe ich dann nicht weiter untersucht.:

Das ist ganz normal, da die Led an MOSI oder MISO (weiss jetzt nicht genau) hängt und somit die Kommunikation mit dem CC1101 sichtbar macht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

MBHG

Hallo Holger,

ZitatSollte so funktionieren ..... habe es aber nur hier im Editor geschrieben - also ungetestet. Der Channel könnte natürlich noch als Member änderbar gemacht werden.

super, funktioniert. Lieben Dank.

Marc
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

Dietmar63

ZitatDie Auflösung des Timers kannst Du in AlarmClock.h durch ändern von TICKS_PER_SECOND einstellen/erhöhen
müssten dann nicht die makros angepasst werden, Sie berücksichtigen im Moment TICKS_PER_SECOND  nicht vollständig

#define TICKS_PER_SECOND 10

#define seconds2ticks(tm) ( tm * TICKS_PER_SECOND )
#define ticks2seconds(tm) ( tm / TICKS_PER_SECOND )

//#define decis2ticks(tm) ( tm * TICKS_PER_SECOND / 10 )
#define decis2ticks(tm) ( tm )
#define ticks2decis(tm) ( tm )

//#define centis2ticks(tm)  ( tm * TICKS_PER_SECOND / 100 )
#define centis2ticks(tm)  ( tm / 10 )
#define ticks2centis(tm)  ( tm * 10 )

//#define millis2ticks(tm) ( tm * TICKS_PER_SECOND / 1000 )
#define millis2ticks(tm) ( tm / 100 )
#define ticks2millis(tm) ( tm * 100 )


ZitatSteigende und fallende Flanke
ist mir auch inzwischen klar, aber erst einmal darauf kommen.

ZitatHm - die Korrektur hat ein paar Randbedingungen, die sollte man besser dokumentieren bzw. die Fehlerfälle mit halbwegs sinnvollem Code behandeln.
Wie meinst du das? ich habe die Methode correct offset bei mir korrigirt, damit ich aClock.correct(0) aufrufen kann. Soll ich eine Version erstellen, die bei mir funktioniert und dann den Code verschmelzen - wäre wahrscheinlich das beste.
Ich will nochmals versuchen von der Version mit konstant 250ms zu wecken in eine dynamischere Version zu wechseln. Das sollte möglich sein, dann kann ich vielleicht auch dafür sorgen, die häßlichen Codestellen zu verbessern.

ZitatDas ist ganz normal, da die Led an MOSI oder MISO (weiss jetzt nicht genau) hängt und somit die Kommunikation mit dem CC1101 sichtbar macht.
Das ist mir bisher nicht aufgefallen.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm