AskSin++ Library

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

Vorheriges Thema - Nächstes Thema

Beetle2003

Hallo,

habe schon mehrere Board mit dem HB-SCI-3-FM Sketch geflashed.
Seit gestern erhalte ich die gezeigte Fehlermeldung. Habe son verschiedene Versionen von AdruinoIDE probiert.
Immer der gleiche Fehler.

Was kann es sein?


Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"

C:\Users\Ralf\Documents\Save\Arduino_eigen\HB-SCI-3-FM\HB-SCI-3-FM.ino:179:1:   required from here

C:\Users\Ralf\Documents\Arduino\libraries\AskSinPP-master/ContactState.h:194:26: error: 'class OnePinChannel<Hal, RHSList0, RHSList1, as::RegList4<as::DefaultRegisterList4>, 6>' has no member named 'changed'

         dev.channel(idx).changed(true); // force StatusInfoMessage to central

Bibliothek EnableInterrupt-master in Version 1.0.0 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\EnableInterrupt-master  wird verwendet
Bibliothek AskSinPP-master in Version 4.1.2 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\AskSinPP-master  wird verwendet
Bibliothek Low-Power in Version 1.6 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\Low-Power  wird verwendet
exit status 1
template argument 1 is invalid



Danke Euch

papa

Das ThreeState-Sachen haben sich geändert. Am besten Du nimmst den V4-Branch. Sonst müsste man sich mal den Sketch genauer ansehen und entsprechend anpassen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Beetle2003

Zitat von: papa am 25 März 2020, 20:04:40
Das ThreeState-Sachen haben sich geändert. Am besten Du nimmst den V4-Branch. Sonst müsste man sich mal den Sketch genauer ansehen und entsprechend anpassen.

Hallo,

danke für die schnelle Rückmeldung.

Was ist mit V4 Branch gemeint. Ich habe den aktuelle Asksin-Master.zip in der Version 4.1.2 geladen.

Danke

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Psi

Also ich hab ja mit https://github.com/pa-pa/AskSinPP/archive/master.zip recht gute Erfahrungen gemacht :)

v4 Branch ist  234 commits behind master, ist das nicht schon etwas weit zurück?
https://github.com/pa-pa/AskSinPP/compare/018c087...8c75792
Der Move von ThreeState zu ContatState ist hier noch nich drin.

Beetle2003

Zitat von: Psi am 25 März 2020, 23:33:23
Also ich hab ja mit https://github.com/pa-pa/AskSinPP/archive/master.zip recht gute Erfahrungen gemacht :)

v4 Branch ist  234 commits behind master, ist das nicht schon etwas weit zurück?
https://github.com/pa-pa/AskSinPP/compare/018c087...8c75792
Der Move von ThreeState zu ContatState ist hier noch nich drin.

Danke, mit der alten Version hat es funktioniert.

Was muss getan werden, damit beim nächsten AskSin-Master update die alte Logik funktioniert?

papa

Keine Ahnung - der Sketch muss halt irgendwo angepasst werden. Eigentlich sollten die Änderungen im Master rückwärtskompatibel sein. Scheint wohl aber nicht ganz geklappt zu haben. Bei meinen Examples ging es ohne Probleme.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Bird

Hallo zusammen,

ich habe mir den HM-UNI-SEN-WEA nachgebaut und mit der aktuellen Software (1.4) versehen. In FHEM habe ich beiden PM-Files von papa installiert. Die Wetterstation wurde im FHEM sofort angelernt und liefert artig regelmässig seine Daten der angeschlossenen I2C Sensoren. Meinen grossen Dank an alle Beteiligten dieser tollen Homematic Projekte.
Als ich den Regensensor (generic) angeschlossen habe ist mir aber ein Fehler aufgefallen, bei einsetzenden Regen oder einer Windböe werden kurzzeitig falsche Werte für Temperatur, Feuchte und Luftdruck in FHEM angezeigt. Wenn ich die Software vom HM-UNI-SEN-WEA richtig verstanden habe, werden hier 3 verschiedene Messagetypen versenden, die zyklischen Wetterdaten (Typ 0x70), Eventdaten bei einsetzenden Regen, Heizung und Windböen (Typ 0x53) und weitere Eventdaten (Typ 0x41), der Payload dieser drei Messagetypen ist unterschiedlich. In dem PM-File HMConfig_AskSinCustom.pm wird nach meinem Verständnis nicht zwischen diesen Messagetypen unterschieden und nur das Datenformat der Typ 0x70 Messages ohne Typprüfung ausgewertet. Ich habe deswegen die HMConfig_AskSinCustom.pm so ergänzt, das der Messagetype mit berücksichtigt wird und das Datenformat des Typs 0x53 ergänzt. Meine Frage ist jetzt, habe ich das vom Verständnis richtig gelöst oder habe ich die Funktionsweise der HMConfig_AskSinCustom.pm falsch verstanden und muß doch woanders ansetzen?

papa

Da hast Du bestimmt Recht. Bitte als Pull-Request zur Verfügung stellen. Danke
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

@Bird: Danke. Ich habe noch ein paar kleine Änderungen gemacht. Kannst Du das bitte nochmal bei Dir testen ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Bird

@papa: Danke für Deine schnelle Hilfe. Ich musste allerdings noch etwas anpassen. Ich stelle Dir einen neuen pull request ein sobald ich mit den Tests fertig bin.

capt_bluebaer

Hallo,
hab mal ne Frage zu dem Beispiel HM-LC-SWX-SM. Ich habe einige Exemplare davon zusammengebaut und benutze sie als Ersatz für IT-Aktoren, die ja einigermassen unzuverlässig sind und auch kein Feedback senden.
Ich setzte die Aktoren für zeitgesteurte Schaltvorgänge ein und möchte unabhängig von der Zentrale sein. Leider erreiche ich bei "on-till-timer" nur Zeitspannen bis 26201 s, das entspricht 7h 16m 41s. Werte darüber hinaus werden mit NACK (Response 01010000 statt 0101C840) quittiert. Der Befehl "on-until" verhält sich dabei genauso, liegt die Ausschaltzeit später als die 26201s ist auch damit Schluß. Die Original HM-Aktoren kennen diese Grenze nicht. Sie liegt weitaus höher, ich habe das Limit aber nicht weiter verfolgt.
Da ich Schaltzeiten von bis zu 12 Stunden brauche und unabhängig von der Zentrale sein will, würde ich gerne wissen, ob - und wenn ja - wo in den Sketches was zu machen wäre.
Raspi 3 Model B, nanoCUL868 (HM), signalDuino (433 MHz), jeeLink

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

capt_bluebaer

Auf meinem Test-Aktor funktierte es auf Anhieb!
Grund: Ich bentutze einen fertig kompilierten Sketch den ich über OTA auf meine Produktiv-Aktoren verteilt habe. Dieser hatte allerdings noch einen Versionsstand 4.1.2.
Papa, du hast ja selber bereits den entscheidenen Patch hier eingebaut.
Mit der Deklaration der Variablen tByte als 4 Byte Integer kommt es nach Werten > 0x80 nicht mehr zu einem Überlauf.
Vielen, vielen Dank für die schnelle Hilfe, ohnen Deinen Hinweis hätte ich mir 'nen Ast gesucht.
Raspi 3 Model B, nanoCUL868 (HM), signalDuino (433 MHz), jeeLink

wolwin

Ich möchte das HM-LC-Sw1-Ba-PCB Script gerne so umbauen, dass es quasi eine 'Tasterfunktion' statt einer 'Schalterfunktion' abbildet - Anmerkung: ich weiß, dass man mit virtuellen Tastern und Experten Einstellungen aus Schaltern auch Schalter mit Tastfunktion machen kann - das ganze wollte ich auf Asksin Ebene nachstellen, ohne irgendwelche Expertenparameter einstellen zu müssen...

Dazu habe ich einen eigenen SwitchChannel eingeführt, in dem die Switch-Methode ersetzt wurde, die nun einem Trigger-Alarm startet. Der Trigger schaltet dann für eine vordefinierte Dauer den Port auf HIGH ... dannach wird er z.Z. wieder auf LOW gesetzt - funktioniert auch. Jedoch steht dann der Schalter auf AN ... besser wäre es, wenn er wieder auf AUS zurückgesetzt würde.

Eigentlich müsste man, statt den Port auf LOW zu setzen, eine Asksin Funktion aufrufen, mit der ein Tastendruck (o.ä.??) für AUS simuliert wird (damit auch die CCU ein Update bekommt). Ich habe schon einige Möglichkeiten durchprobiert (z.B. Toogle Methode), aber nichts führt zum Ziel. Hat jemand eine Idee ... gibt es in Asksin Möglichkeiten zur message-injection  o.ä. ... ???

Hier mal der (gekürzte) Beispielcode:


...
// this class controls the pin high/low sequence
class SwAlarm : public Alarm {
private:
  uint8_t  pin;
  uint16_t time;
  uint8_t  state;
public:
  SwAlarm () : Alarm(0), pin(0), time(0), state(0) {
    async(true);
  }
  virtual ~SwAlarm () {}

  virtual void trigger (AlarmClock& clock) {
    switch(state) {
    case 1:
      DPRINTLN("SwitchChannel - trigger 1 - START (500)");
      set(millis2ticks(500));
      break;
    case 2:
      DPRINT("SwitchChannel - trigger 2 - HIGH - "); DDEC(pin); DPRINT(" (");  DDEC(time); DPRINTLN(")");
      set(millis2ticks(time));
      digitalWrite(pin, HIGH);
      break;
    case 3:
      // DPRINT("SwitchChannel - trigger 3 - LOW - "); DDEC(pin); DPRINT(" (");  DDEC(time); DPRINTLN(")");
      // set(millis2ticks(time));
      DPRINT("SwitchChannel - trigger 3 - LOW - "); DDEC(pin); DPRINTLN(" (100)");
      set(millis2ticks(100));
      digitalWrite(pin, LOW);
      break;
    case 4:
      DPRINTLN("SwitchChannel - trigger 4 - END");
      state=0;
      break;
    }
    if( state != 0 ) {
      ++state;
      clock.add(*this);
    }
  }

  bool press (uint8_t p, uint16_t t, AlarmClock& clock) {
    // check that we are not running
    if( state == 0 ) {
      pin = p;
      time = t;
      state = 1;
      trigger(clock);
      return true;
    }
    return false;
  }
};

class SwChannel : public SwitchChannel<Hal, PEERS_PER_CHANNEL, SwList0> {
protected:
  uint8_t  swpin;
  uint16_t swtime;
  SwAlarm  swalarm;
public:
  typedef SwitchChannel<Hal, PEERS_PER_CHANNEL, SwList0> BaseChannel;
  virtual ~SwChannel () {}

  void init (uint8_t pin, uint16_t pintime) {
    BaseChannel::init(pin, false);
    swpin = pin;
    swtime = pintime;
    pinMode(swpin, OUTPUT);
    this->changed(true);
    DPRINT("INIT Pin "); DDEC(swpin); DPRINT(" - OUTPUT - SWTIME "); DDECLN(swtime);
  }

  // replace standard switch method - trigger alarm to start sequence
  virtual void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate,__attribute__((unused)) uint32_t delay) {
    bool pressed = false;
   
    DPRINTLN("### SwitchChannel - switchState");

    if( newstate == AS_CM_JT_ON ) {
      // digitalWrite(swpin, HIGH);
      if( swpin > 0) {
        DPRINT("SwitchChannel - AS_CM_JT_ON - Pin "); DDEC(swpin); DPRINT(" (");  DDEC(swtime); DPRINTLN(")");
        pressed = swalarm.press(swpin, swtime, sysclock);
      }
    }
    else if ( newstate == AS_CM_JT_OFF ) {
      // digitalWrite(swpin, LOW);
      if( swpin > 0) {
        DPRINT("SwitchChannel - AS_CM_JT_OFF - Pin "); DDEC(swpin); DPRINT(" (");  DDEC(swtime); DPRINTLN(")");
        pressed = swalarm.press(swpin, swtime, sysclock);
      }
    }
    if( pressed == true ) {
      DPRINTLN("### SwitchChannel - pressed");
      this->changed(true);
    }
  }
};

// setup the device with channel type and number of channels
class SwitchType : public MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> {
public:
  typedef MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> DevType;
  SwitchType (const DeviceInfo& i,uint16_t addr) : DevType(i,addr) {}
  virtual ~SwitchType () {}

  bool init (Hal& hal) {
    bool rtn = DevType::init(hal);
    return(rtn);
  }

};

SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY_PIN_1, RELAY_PIN_1_TIME);
...