RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 13.07.2021, 17:24

Die Sache mit digitalRead ist es nicht.

Es liegt am Aufruf von

Code: Alles auswählen

    if (TA == 1) cfgBtn.irq();
    else if (TA == 2) sdev.channel(1).button().irq();
    else if (TA == 3) sdev.channel(2).button().irq();
https://github.com/jp112sdl/Beispiel_As ... #L144-L146

In der Button.h erfolgt check() mit

Code: Alles auswählen

  void check() {
    uint8_t ps = digitalRead(pin);
    if( pinstate != ps ) {
    ...
https://github.com/pa-pa/AskSinPP/blob/ ... #L181-L182

Initial entspricht der pinstate dem definierten OFFSTATE(=HIGH).

Hält man einen Taster nur ganz kurz gedrückt (=LOW), wird zwar die Schaltung geweckt und wach gehalten.
Hat man den Taster jedoch wieder losgelassen (=HIGH), wenn das ganze Hal-Init-Zeugs durch ist und der irq() Aufruf kommt, dann erkennt die check() Methode keinen Tastendruck mehr.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

dirk.abel
Beiträge: 69
Registriert: 04.02.2019, 10:04
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von dirk.abel » 13.07.2021, 18:10

So, ich habe jetzt ein wenig mit dem Code gespielt.
Das Delay bringt keine Verbesserung - hätte ich da auch nicht wirklich erwartet.
Was gegen das (langsame) digitalRead() spricht (außer Stromverbrauch), weiß ich auch nicht.

Ich deute das wie folgt:

Code: Alles auswählen

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER); // initialisiert den Debug UART

  pinMode(ACTIVATE_PIN, OUTPUT);     // Selbthaltung...
  digitalWrite(ACTIVATE_PIN, HIGH);  // ...aktiv
  pinMode(CC1101_PWR_PIN, OUTPUT);   // Funkmodul...
  digitalWrite(CC1101_PWR_PIN, LOW); // ...ein

  pwrOffAlarm.init();                // irgendwas mit Batterie und Abschaltung...
dann kommt das:

Code: Alles auswählen

  buttonISR(cfgBtn,CONFIG_BTN);  // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf      
  remoteISR(sdev,1,BTN01_PIN);   // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf      
  remoteISR(sdev,2,BTN02_PIN);   // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf]
D.h. JETZT sind doch im Hintergrund schon die Interrupts scharf und werden ggf. sofort gestartet, weil die Taste ja gedrückt ist.
Und das sdev ist noch gar nicht initialisiert und die hal.battery auch nicht. Oder übersehe ich da was?

Dann werden die Ports (gemütlich) zu Fuß abgefragt:

Code: Alles auswählen

  uint8_t TA = 0;
  if (digitalRead(CONFIG_BTN) == LOW) TA = 1;
  if (digitalRead(BTN01_PIN)  == LOW) TA = 2;
  if (digitalRead(BTN02_PIN)  == LOW) TA = 3;
  DPRINT("TA = ");DDECLN(TA);
und nur, wenn hier ein Tastendruck erkannt wird, wird der ganze Init Kram aufgerufen:

Code: Alles auswählen

  if (TA>0) { 
    sdev.init(hal);
    hal.battery.init();
    hal.battery.low(BAT_LOW);
    hal.battery.critical(BAT_CRIT);
    sdev.initDone();

    while (hal.battery.current() == 0);
    if (hal.battery.critical()) pwrOffAlarm.powerOff(false);

    StorageConfig sc = sdev.getConfigArea();
    uint8_t msgCount = sc.getByte(MSG_COUNT_BYTE);
    while (sdev.nextcount() < msgCount);
  
    hal.radio.setSendTimeout();
    
    if (TA == 1) cfgBtn.irq();
    else if (TA == 2) sdev.channel(1).button().irq();
    else if (TA == 3) sdev.channel(2).button().irq();
        
  } else {
    pwrOffAlarm.powerOff(false);
  }
Über TA wird dann ggf. die Tastenpin Interrupt Routine zu Fuß angestoßen. Kann es sein, dass das mal so klappt und die anderen Male die ISR direkt nach der Initialisierung direkt startet ohne das das sdev.init und Co. durchläuft?

Das

Code: Alles auswählen

pwrOffAlarm.powerOff(false);
lässt den µC direkt wieder abschalten, oder was bewirkt das?


Habe das ganze mal so geändert:

Code: Alles auswählen

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER); // initialisiert den Debug UART

  pinMode(ACTIVATE_PIN, OUTPUT);     // Selbthaltung...
  digitalWrite(ACTIVATE_PIN, HIGH);  // ...aktiv
  pinMode(CC1101_PWR_PIN, OUTPUT);   // Funkmodul...
  digitalWrite(CC1101_PWR_PIN, LOW); // ...ein

  pwrOffAlarm.init();                // irgendwas mit Batterie und Abschaltung...
  
  //uint8_t TA = 0;
  //if (digitalRead(CONFIG_BTN) == LOW) TA = 1;
  //if (digitalRead(BTN01_PIN)  == LOW) TA = 2;
  //if (digitalRead(BTN02_PIN)  == LOW) TA = 3;
  //DPRINT("TA = ");DDECLN(TA);

  if (1) { // IMMER!!! Eine Taste muss ja gedrückt sei, wenn er aufwacht...
    sdev.init(hal);
    hal.battery.init();
    hal.battery.low(BAT_LOW);
    hal.battery.critical(BAT_CRIT);
    sdev.initDone();

    while (hal.battery.current() == 0);
    if (hal.battery.critical()) pwrOffAlarm.powerOff(false);

    StorageConfig sc = sdev.getConfigArea();
    uint8_t msgCount = sc.getByte(MSG_COUNT_BYTE);
    while (sdev.nextcount() < msgCount);
  
    hal.radio.setSendTimeout();
    
    //if (TA == 1) cfgBtn.irq();
    //else if (TA == 2) sdev.channel(1).button().irq();
    //else if (TA == 3) sdev.channel(2).button().irq();

    buttonISR(cfgBtn,CONFIG_BTN);  // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf      
    remoteISR(sdev,1,BTN01_PIN);   // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf      
    remoteISR(sdev,2,BTN02_PIN);   // initialisiert den Portpin und schalter den Pegelwechsel-Interrupt auf dem Portpin scharf 
        
  } else {
    pwrOffAlarm.powerOff(false);
  }
}
Funktioniert aber auch nicht besser... :roll:
Weil ich die Lib nicht überblicke und da nur an der Oberfläche rumkratze.
Ich hätte jetzt erwartet, das das sdev.init durch sein muss, bevor ein Pinwechsel Interrupt aufgerufen werden darf.
Die button.isr scheint ein Objekt per sysclock.add in eine Abarbeitungsliste außerhalb der ISR zuzufügen.
Wo und wie das ganze abgearbeitet wird, finde ich aber nicht... Daher kann ich auch nicht schauen, ob das ggf. geblockt wird, wenn das sdev nocht initialisiert ist.
Eventuell ist mein Erwartungsmodell aber auch falsch... Ich weiß es nicht.
Gruß, Dirk

System:
Selbst entwickelte Wandmodule (15Stk/eins pro Raum) mit 3*Rollo, 3*Relais, 3*Dimmer, 9*Tastereingängen, 4*4 Matrix für Tür-/Fenster Kontakte (auf/zu/kipp) im 2005 gebauten Einfamilienhaus, verbunden über CAN Bus, lokale Tabellen für Aktionen, 1* - 5* Tastendruck (üblich 1x 4-fach Taster verbaut) und Änderung Kontaktstatus, parametrierbar über eigene Windows Software, aktuell gesteuert über selbst gebautes CAN - Ethernet Interface und OpenHAB per HTTP Binding (JSON/GET/POST).
Zusätzlich diverse Xiaomi Sensoren (Temperatur und Brandmelder) und Homematic/AskSinPP Komponenten (über Homegear) für "vergessene" Funktionen...

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 13.07.2021, 18:24

Ich hatte jetzt einfach mal in der Button.h
https://github.com/pa-pa/AskSinPP/blob/ ... tton.h#L95
den pinsate(ONSTATE) übergeben und dann geht es auch wenn man den Taster nur ganz kur antippt zumindest was die check() Methode betrifft.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 13.07.2021, 18:50

Aber komisch ist es trotzdem mit der CCU.

Auch wenn das Senden eines gültigen Telegramms klappt (im AskSinAnalyzer zu sehen), wird das Programm manchmal nicht getriggert.
Vielleicht übersehe ich auch irgendwas total Simples an der ganzen Sache... Seltsam das alles, ich weiß da leider auch weiter keinen Rat.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

papa
Beiträge: 598
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 8 Mal
Danksagung erhalten: 92 Mal

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von papa » 13.07.2021, 21:18

Wird der Messagecounter auch ordentlich mit jeder Nachricht hochgezählt ? Wenn der Counter sich nicht ändert, verwirft die CCU u.U. (wegen Wiederholung) die Nachricht.
Anfragen zur AskSin++ werden nur im Forum beantwortet

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 13.07.2021, 22:12

papa hat geschrieben:
13.07.2021, 21:18
Wird der Messagecounter auch ordentlich mit jeder Nachricht hochgezählt ? Wenn der Counter sich nicht ändert, verwirft die CCU u.U. (wegen Wiederholung) die Nachricht.
Ja wird er. Das war meine erste Vermutung.
Zählt zwar in 2er 4er Schritten, aber er ändert sich.
Bildschirmfoto 2021-07-13 um 22.16.49.png

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 13.07.2021, 22:25

Jetzt wird es interessant...

Die Telegramme unterscheiden sich im letzten Byte.
Ich habe den Taster jetzt mehrmals ganz kurz betätigt (ich muss mich da echt anstrengen), wenn der Sender im Schlafmodus war.
Der Analyzer hat das Telegramm jeweils angezeigt.
Mein Aktor per DV hat nicht geschaltet :!:

Code: Alles auswählen

1330;13.07.2021 20:22:36;-95;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;242;REMOTE_EVENT;WKMEUP BIDI RPTEN;0B F2 A2 40 00 36 03 F3 35 02 01 01;
2695;13.07.2021 22:16:18;-93;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;254;REMOTE_EVENT;WKMEUP BIDI RPTEN;0B FE A2 40 00 36 03 F3 35 02 01 00;
2697;13.07.2021 22:16:22;-92;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;2;  REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 02 A2 40 00 36 03 F3 35 02 01 00;
2698;13.07.2021 22:16:31;-93;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;6;  REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 06 A2 40 00 36 03 F3 35 02 01 00;
2699;13.07.2021 22:16:33;-91;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;10; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 0A A2 40 00 36 03 F3 35 02 01 01;
2700;13.07.2021 22:16:40;-92;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;14; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 0E A2 40 00 36 03 F3 35 02 01 00;
2701;13.07.2021 22:16:42;-93;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;18; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 12 A2 40 00 36 03 F3 35 02 01 01;
2717;13.07.2021 22:18:03;-94;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;21; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 15 A2 40 00 36 03 F3 35 02 01 00;
2720;13.07.2021 22:18:13;-94;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;24; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 18 A2 40 00 36 03 F3 35 02 01 00;
2725;13.07.2021 22:18:25;-94;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;27; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 1B A2 40 00 36 03 F3 35 02 01 00;
2726;13.07.2021 22:18:39;-92;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;31; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 1F A2 40 00 36 03 F3 35 02 01 00;
2727;13.07.2021 22:18:42;-92;003603;JPRWEWSC02;F33502;HBSw1PBU02;11;35; REMOTE_EVENT;WKMEUP BIDI RPTEN;0B 23 A2 40 00 36 03 F3 35 02 01 01;
Immer dann, wenn das letzte Byte 0x00 ist, passiert beim Empfänger (CCU oder Aktor) nichts.


Stellt sich die Frage: Zeigt der AskSinSniffer das letzte Byte als 0x00 an, weil die Telegrammlänge (0x0B) im Telegramm selbst mitgegeben wird?
Fehlt also bei der Telegrammaussendung selbst das letzte Byte?
Oder ist es aus welchen Gründen auch immer 0x00 (Weil durch Loslassen des Tasters vor dem Aufruf von sdev.channel(1).button().irq() bereits die remoteISR zuschlägt ?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

stan23
Beiträge: 1606
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 365 Mal
Danksagung erhalten: 210 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von stan23 » 14.07.2021, 07:42

jp112sdl hat geschrieben:
13.07.2021, 22:25
Stellt sich die Frage: Zeigt der AskSinSniffer das letzte Byte als 0x00 an, weil die Telegrammlänge (0x0B) im Telegramm selbst mitgegeben wird?
Fehlt also bei der Telegrammaussendung selbst das letzte Byte?
Also hier werden immer length Bytes ausgegeben:
https://github.com/jp112sdl/AskSinAnaly ... 8P.ino#L54

Und hier werden auch len Bytes aus dem CC1101 gelesen:
https://github.com/pa-pa/AskSinPP/blob/ ... h#L230L239

Würde der CC1101 merken wenn ein Byte zu wenig gesendet wird?
Oder überschreibt der WCS2 seinen eigenen Sendepuffer während das Telegramm gesendet wird? Vielleicht sollten die IRQs dabei noch deaktiviert sein?

EDIT:
Hier wird zwar geprüft wie viele Bytes im FIFO sind, aber dann trotzdem die gesendete Längenangabe verwendet:
https://github.com/pa-pa/AskSinPP/blob/ ... #L771-L778
Könnte also sein dass da das letzte Byte fehlt.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

jp112sdl
Beiträge: 9143
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 552 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von jp112sdl » 14.07.2021, 08:01

papa hat geschrieben:
13.07.2021, 21:18
Wird der Messagecounter auch ordentlich mit jeder Nachricht hochgezählt ? Wenn der Counter sich nicht ändert, verwirft die CCU u.U. (wegen Wiederholung) die Nachricht.
Ja Moment... Was ist der letzte Parameter counter?

Code: Alles auswählen

 Message::init(0xb,msgcnt,AS_MESSAGE_REMOTE_EVENT,BIDI|WKMEUP,(ch & 0x3f) | flags,counter);
https://github.com/pa-pa/AskSinPP/blob/ ... age.h#L474

Ich inkrementiere den msgcnt und speichere den Zählerstand im EEPROM, jedoch ist der counter beim Start immer bei 0!

Bisher ging ich davon aus, dass eine Telegrammwiederholung allein am Messagecounter festgemacht wird...

Werd wohl heut Nachmittag mal meinen ISP rauskramen müssen.

Oder falls es jemand mal testen möchte, testweise in der Remote.h:57
ein

Code: Alles auswählen

msg.init(this->device().nextcount(),this->number(),this->device().nextcount(),(s==ButtonType::longreleased || s==ButtonType::longpressed),this->device().battery().low());
machen. Nur um erstmal zu garantieren, dass da immer eine andere Zahl übertragen wird und zu schauen, ob dann die CCU korrekt reagiert.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

papa
Beiträge: 598
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 8 Mal
Danksagung erhalten: 92 Mal

Re: RWE/Innogy/Livisi Wandsender WSC2 - Homematic/AskSinPP Firmware

Beitrag von papa » 14.07.2021, 08:55

Der Counter im RemoteEvent muss auch bei jedem neuen Tastendruck erhöht werden. Kann mich da auch noch dunkel an Probleme erinnern, wenn das nicht gepasst hat.
Anfragen zur AskSin++ werden nur im Forum beantwortet

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“