AskSin++ Library

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

Vorheriges Thema - Nächstes Thema

Beetle2003

Zitat von: McShire am 01 Januar 2021, 11:38:43
Hallo Ralf,
hast Du in FHEM das device HM_120901 und die zugehörigen Kanäle HM_120901_Sw_01 und HM_120901_Sw_02
angelegt?

Ein frohes neues Jahr
Werner

Hallo Werner,

Dir auch ein frohes neues Jahr.

Ich hatte ein Missverständnis. Hatte die Beschaltung nicht richtig. Nun LED an D6 und mit SW1 kann ich die LED Ein / ausschalten. Mit SW2 über on-for-timer die Blinkfrequenz beeinflussen.

Nun stellten sich folgende Fragen:
1. kann die Blinkfrequenz durch einen Parameter direkt beeinflusst werden (je nach Status soll eine andere Frequenz ausgegeben werden)
2. Können weitere Kanäle mit LEDs angesteuert werden (ich möchte die LEDs als Statusanzeige für verschiedene Geräte nutzen)
3. Gibt es eine Resetfunktion ohne das Board stromlos zu machen


Gruss
Ralf

Tom Major

Zitat von: papa am 01 Januar 2021, 20:31:36
Im Typedef fehlt das CYCLETIME - also

public:
    typedef StateDevice<HalType, ChannelType, 1, WDSList0,CYCLETIME> TSDevice;


Das 2. template habe ich übersehen  ::)
Gerade getestet, funktioniert super, Danke!

---

patchStatus() habe ich auch schon angefangen zu testen. In die CCU/xml bekomme ich die extra Bytes rein, das sieht gut aus.
ich habe jetzt folgendes temporär in ContactState.h

#33

      DPRINTLN(F("### ContactState trigger"));
#ifdef CONTACT_STATE_WITH_BATTERY
      channel.patchStatus(msg);
      // msg.append(channel.device().battery().current());
      // msg.append(__gb_BatCount);
#endif


#138

#ifdef CONTACT_STATE_WITH_BATTERY
  void patchStatus (Message& msg) {
    uint16_t u16 = 0x0ABC;
    msg.append(u16);
    DPRINTLN(F("### ContactState patchStatus"));
  }
#endif


Sketch

class ADCThreeStateChannel : public StateGenericChannel<ADCPosition, HALTYPE, List0Type, List1Type, List4Type, PEERCOUNT> {
...
    // papa: patchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird, siehe Device.h #357, #391
    // append custom data to status message
    void patchStatus (Message& msg) {
        uint16_t u16 = 0x1234;
        msg.append(u16);
        DPRINTLN(F("### sketch patchStatus"));
    }


Die Messages sehen jetzt so aus:

*Position Change*

00:44:43.913 -> ADC Wet:   0
00:44:43.913 -> Status:    WATER
00:44:43.913 -> ### ContactState trigger
00:44:43.913 -> ### ContactState patchStatus
00:44:43.947 -> <- 0E 01 A2 41 4929D3 435F5B 01 00 C8 0A BC  - 247
00:44:44.083 -> -> 0A 01 80 02 435F5B 4929D3 00  - 372
00:44:44.083 -> waitAck: 01


*cycleInfoMsg*

01:14:58.709 -> ADC Wet:   0
01:14:58.709 -> Status:    WATER
01:14:58.743 -> ### sketch patchStatus
01:14:58.777 -> <- 10 02 A2 10 4929D3 435F5B 06 01 C8 00 25 12 34  - 1474
01:14:58.880 -> -> 0A 02 80 02 435F5B 4929D3 00  - 1599
01:14:58.914 -> waitAck: 01


Was du geschrieben hast
ZitatpatchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird, siehe Device.h #357, #391

stimmt exakt, der uint16_t 0x1234 wird bei der cycleInfoMsg appended, siehe 01:14:58.777

Einziges Problem noch, nur bei Position Change wird nicht 0x1234 appended, sondern 0x0ABC, siehe 00:44:43.947, was mein Testwert aus ContactState.h #138 ist.
Was muss getan werden, damit auch Position Change die Funktion patchStatus() aus dem Sketch hernimmt, nicht aus ContactState?

Danke,
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Hm - das wird nicht so einfach, da im ersten Fall nur die patchStatus vom StateGenericChannel bekannt ist. Damit das so funktioniert, müsste patchStatus() virtual gemacht werden.

Wir könnten am HAL eine Methode vorsehen, die immer vor dem Senden einer Nachricht aufgerufen wird. Diese kann dann einfach im Device-Sketch überladen werden. Dann brauchst Du das patchStatus() wahrscheinlich gar nicht. Was hältst DU davon ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 02 Januar 2021, 15:27:48
Hm - das wird nicht so einfach, da im ersten Fall nur die patchStatus vom StateGenericChannel bekannt ist. Damit das so funktioniert, müsste patchStatus() virtual gemacht werden.

Wir könnten am HAL eine Methode vorsehen, die immer vor dem Senden einer Nachricht aufgerufen wird. Diese kann dann einfach im Device-Sketch überladen werden. Dann brauchst Du das patchStatus() wahrscheinlich gar nicht. Was hältst DU davon ?

Das klingt nach einem guten Plan und würde die Umstände mit patchStatus() überflüssig machen. Die Sache mit patchStatus(), es gibt ja ein nicht virtuelles patchStatus mit leerer Impl. in Channel - das kann ich anscheinend für die cycleInfoMsg überschreiben, aber nicht für die PositionChangeMsg. Ich vermute das liegt daran, dass das nicht virtuelle patchStatus in Channel kein late binding bekommt und deswegen nichts vom patchStatus() im Sketch wissen kann?
(Außerdem gibt es weiterhin 2 virtuelle patchStatus in VirtBaseChannel und VirtChannel.)

Also eine neue Methode, die immer vor dem Senden einer Nachricht aufgerufen wird und die im Sketch überladen wird klingt gut, kannst du das bei Gelegenheit machen?

Danke,
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.
Z.B. so
typedef AskSin<LedType,BatterySensor,RadioType> HalType;
class Hal : public HalType {
public:
  void prepareSend (Message& msg) {
    if( msg.isSensorEvent() || msg.isInfoActuatorStatusMsg() ) {
      // add you code here
    }
  }
};

Hal hal;
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 02 Januar 2021, 22:51:05
Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.


Vielen Dank und Wow, so schnell habe ich nicht damit gerechnet  :)
ich werde testen und berichten.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

McShire

Zitat von: Beetle2003 am 01 Januar 2021, 22:50:26
Hallo Werner,

Dir auch ein frohes neues Jahr.

Ich hatte ein Missverständnis. Hatte die Beschaltung nicht richtig. Nun LED an D6 und mit SW1 kann ich die LED Ein / ausschalten. Mit SW2 über on-for-timer die Blinkfrequenz beeinflussen.

Nun stellten sich folgende Fragen:
1. kann die Blinkfrequenz durch einen Parameter direkt beeinflusst werden (je nach Status soll eine andere Frequenz ausgegeben werden)
2. Können weitere Kanäle mit LEDs angesteuert werden (ich möchte die LEDs als Statusanzeige für verschiedene Geräte nutzen)
3. Gibt es eine Resetfunktion ohne das Board stromlos zu machen


Gruss
Ralf

Hallo Ralf,
schön, dass es jetzt funktioniert.
zu1.
Ja, die Pulsweite des Blinkers wird durch die Einschaltdauer von RELAY2 gesetzt.
Mit der Anweisung set HM_120901_Sw_02 on-for-timer 500 gibt 500 die Pulsweite und damit die Blinkfrquenz vor.
Wenn Du jetzt die 500 durch den Wert eines Dummy-devices ersetzt oder die Einschaltdauer anders variierst,
z.B. set ... on, sleep ..., set off, kannst Du darüber die Blinkfrequenz setzen.
zu2.
Nur über FHEM ansteuern oder auch mit Taster lokal?
zu3. lokal über die Resttaste auf dem Pro Mini und über den Eingang RST gegen GND.

Viele Grüße
Werner

Tom Major

Zitat von: papa am 02 Januar 2021, 22:51:05
Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.

Läuft einwandfrei, papa, Vielen Dank für die Hilfe und rasche Umsetzung!

Im Log erst die Sensor Msg, danach die Gerätestatus Msg. 1234h angehängt per Überladung im Sketch.

..
Battery set low:  24
transmitDevTryMax: 6
ADC Wet:   0
Status:    WATER
<- 0E 01 A2 41 4929D3 435F5B 01 00 C8 12 34  - 243
-> 0A 01 80 02 435F5B 4929D3 00  - 368
waitAck: 01
<- 10 02 A2 10 4929D3 435F5B 06 01 C8 00 20 12 34  - 913
-> 0A 02 80 02 435F5B 4929D3 00  - 1038
waitAck: 01
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Beetle2003

Zitat von: McShire am 03 Januar 2021, 04:20:55
Hallo Ralf,
schön, dass es jetzt funktioniert.
zu1.
Ja, die Pulsweite des Blinkers wird durch die Einschaltdauer von RELAY2 gesetzt.
Mit der Anweisung set HM_120901_Sw_02 on-for-timer 500 gibt 500 die Pulsweite und damit die Blinkfrquenz vor.
Wenn Du jetzt die 500 durch den Wert eines Dummy-devices ersetzt oder die Einschaltdauer anders variierst,
z.B. set ... on, sleep ..., set off, kannst Du darüber die Blinkfrequenz setzen.
zu2.
Nur über FHEM ansteuern oder auch mit Taster lokal?
zu3. lokal über die Resttaste auf dem Pro Mini und über den Eingang RST gegen GND.

Viele Grüße
Werner

Hallo Werner,

danke.
zu 1. Das mit on-for-timer habe ich durchgeführt. Hat zur Folge, dass eine Veränderung der Blinkfreuenz sehr zeitaufwändig ist. Meine Hoffnung ging dorthin, dass ein Readingwert oder Attribut genutzt werden kann, in dem die Blinkfrequenz gespeichert ist und dieser Wert eingelesen wird. Somit enthält die Wartezeit für z.B. on-for-timer.
zu 2. Derzeit würde mir eine Steuerung über Fhem reichen. Sicherlich gibt es weitere Mitstreiter, welche die Ansteuerung über Taster für sinvoll halten. Die Blinkfreuenz sollte wie zu 1 beschrieben für jede LED anpassbar sein.
zu 3. Die genannten Dinge sind mir bekannt. Doch wenn ich das Board in eine Gehäuse einbaue, so ist es suboptimal wenn es hierfür geöffnet werden muss. Deshalb dachte ich an eine Steuerung für die Software.

Wie sagt ein sehr guter Kollege regelmässig: Auf Wunsch eines einzelnen angepasst! :-)

Gruss

Tom Major

Zitat von: Tom Major am 03 Januar 2021, 12:58:26
Läuft einwandfrei, papa, Vielen Dank für die Hilfe und rasche Umsetzung!

Im Log erst die Sensor Msg, danach die Gerätestatus Msg. 1234h angehängt per Überladung im Sketch.

und hier noch der erste Anwendungsfall:
https://homematic-forum.de/forum/viewtopic.php?f=76&t=64212

Es ist auf jeden Fall eine gute Sache vom Sketch aus Bytes der Nachricht anfügen zu können. Das erhöht die Flexibilität für zukünftige Geräte.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

McShire

Zitat von: Beetle2003 am 03 Januar 2021, 15:23:29
Hallo Werner,

danke.
zu 1. Das mit on-for-timer habe ich durchgeführt. Hat zur Folge, dass eine Veränderung der Blinkfreuenz sehr zeitaufwändig ist. Meine Hoffnung ging dorthin, dass ein Readingwert oder Attribut genutzt werden kann, in dem die Blinkfrequenz gespeichert ist und dieser Wert eingelesen wird. Somit enthält die Wartezeit für z.B. on-for-timer.
zu 2. Derzeit würde mir eine Steuerung über Fhem reichen. Sicherlich gibt es weitere Mitstreiter, welche die Ansteuerung über Taster für sinvoll halten. Die Blinkfreuenz sollte wie zu 1 beschrieben für jede LED anpassbar sein.
zu 3. Die genannten Dinge sind mir bekannt. Doch wenn ich das Board in eine Gehäuse einbaue, so ist es suboptimal wenn es hierfür geöffnet werden muss. Deshalb dachte ich an eine Steuerung für die Software.

Wie sagt ein sehr guter Kollege regelmässig: Auf Wunsch eines einzelnen angepasst! :-)

Gruss

Hallo Ralf,
zu 1.
leider wird hier für die Blinkfrequenz überhaupt kein Wert übertragen. Dieser Sketch ist lediglich
ein Derivat von einem 2-poligen Schalter, der nur on und off überträgt. Die Blinkfunktion, (LED on/off und blinkfrequenz ) wird nur im Arduino erzeugt, abgeleitet aus den Schaltzuständen.
Im Arduino läuft als Hauptprogramm eine loop. Die Pulsweite ergibt sich aus der Anzahl der loop-Durchläufe während der Einschaltzeit von Kanal2. Das ganze ist quick and dirty eingefügt in die loop am Ende. Pulsweiten in Form einer Zahl geht mit diesem Modul leider nicht. Es lässt sich Zeit sparen, wenn man die Pulsweite nicht variabel gestaltet, sondern nur wenige Frequenzen festlegt. Dann kann man dafür ganz kurze Einschaltzeiten übertragen und daraus im Arduino die Pulsweite ableiten.
zu2.
Wenn man keinen Taster braucht, benötigt man dafür auch keinen DI am Arduino. Die Zahl ist ja begrenzt. Ich glaube , es gibt auch einen Sketch für einen 8-fach Aktor, den könnte man dann wie beim 2-fach Switch "aufbohren" und käme auf 4 Blinker, das sind dann 12 DOs , das ist für den Mini das Maximum.
zu 3.
Mit Steuerung über FHEM kann man beliebige Logik und Verknüpfungen einführen, das ist ein großer Vorteil, z.B. die Pulsweite in Abhägigkeiten von Stati festlegen. Wer dann noch einen Taster braucht, kann dann ja parallel einen Taster betreiben und dessen Signale in FHEM zur Steuerung des Blinkmoduls benutzen.

Ich melde mich wieder, wenn ich mit dem 8-fach Aktor etwas probiert habe. Kann ein bisschen dauern.
Viele Grüße
Werner

Beetle2003

Zitat von: McShire am 04 Januar 2021, 01:00:44
Hallo Ralf,
zu 1.
leider wird hier für die Blinkfrequenz überhaupt kein Wert übertragen. Dieser Sketch ist lediglich
ein Derivat von einem 2-poligen Schalter, der nur on und off überträgt. Die Blinkfunktion, (LED on/off und blinkfrequenz ) wird nur im Arduino erzeugt, abgeleitet aus den Schaltzuständen.
Im Arduino läuft als Hauptprogramm eine loop. Die Pulsweite ergibt sich aus der Anzahl der loop-Durchläufe während der Einschaltzeit von Kanal2. Das ganze ist quick and dirty eingefügt in die loop am Ende. Pulsweiten in Form einer Zahl geht mit diesem Modul leider nicht. Es lässt sich Zeit sparen, wenn man die Pulsweite nicht variabel gestaltet, sondern nur wenige Frequenzen festlegt. Dann kann man dafür ganz kurze Einschaltzeiten übertragen und daraus im Arduino die Pulsweite ableiten.
zu2.
Wenn man keinen Taster braucht, benötigt man dafür auch keinen DI am Arduino. Die Zahl ist ja begrenzt. Ich glaube , es gibt auch einen Sketch für einen 8-fach Aktor, den könnte man dann wie beim 2-fach Switch "aufbohren" und käme auf 4 Blinker, das sind dann 12 DOs , das ist für den Mini das Maximum.
zu 3.
Mit Steuerung über FHEM kann man beliebige Logik und Verknüpfungen einführen, das ist ein großer Vorteil, z.B. die Pulsweite in Abhägigkeiten von Stati festlegen. Wer dann noch einen Taster braucht, kann dann ja parallel einen Taster betreiben und dessen Signale in FHEM zur Steuerung des Blinkmoduls benutzen.

Ich melde mich wieder, wenn ich mit dem 8-fach Aktor etwas probiert habe. Kann ein bisschen dauern.
Viele Grüße
Werner

Hallo Werner,

Danke für die Antwort.

Ich freue mich auf deinen Ergebnis.

Bleib gesund

Gruß
Ralf

McShire

Zitat von: Beetle2003 am 04 Januar 2021, 20:45:27
Hallo Werner,

Danke für die Antwort.

Ich freue mich auf deinen Ergebnis.

Bleib gesund

Gruß
Ralf


Hallo Ralf,
hat ein bisschen gedauert, ist jetzt fertig "quick and dirty"
3 Blinker, mehr geht nach diesem Verfahren wegen der begrenzten Ausgänge nicht.
jeder Blinker hat 3 Kanäle, Ein/Aus, Pulsweite, Blinker-Ausgang.
Falls man mehr Blinker braucht, muss man ein vollkommen neues device in FHEM schaffen,
das dann die Daten anders überträgt. Das jetzige Modell ist ja nur von einem Aktor abgeleited.
Falls Du es gebrauchen kannst, viel Spass damit.


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2018-09-29 jp112sdl Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2021-01-05 modification by mcshire, to use this sketch in combination with device HM-MOD-Re-8
// to generate 3 outputs for blinkers with varable frequency.
// There are 3 DI for every blinker: on/off Signal, pulsewidth, blinkeroutput.
// on/off controlled in FHEM: on - blinker is activ
// pulsewidth: duration on-time is analog to pulswidth scaled by factor
// blinkeroutput: supplies LED or relay with square wave signal, when DI (on/off) is HIGH
//PIN-Belgung und FHEM-Kanäle siehe im auskommentierten define-Block
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER
#define USE_WOR

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.h>


// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

int RELAY_EA_PIN[3] = {14, 16, 7};
int RELAY_PW_PIN[3] = {15, 17, 9};
int RELAY_BLINK_PIN[3] = {6, 3, 5};

// #define RELAY_EA_PIN[0] 14      //A0 //on-off Blinker 1 CH1
// #define RELAY_PW_PIN[0] 15      //A1 //Pulswi Blinker 1 CH2
// #define RELAY_EA_PIN[1] 16      //A2 //on-off Blinker 2 CH3
// #define RELAY_PW_PIN[1] 17      //A3 //Pulswi Blinker 2 CH4
// #define RELAY_EA_PIN[2] 7            //on-off Blinker 3 CH5
// #define RELAY_PW_PIN[2] 9            //Pulswi Blinker 3 CH6
// #define RELAY_BLINK_PIN[0] 6         //Output Blinker 1 CH7
// #define RELAY_BLINK_PIN[1] 3         //Output Blinker 2 CH8
// #define RELAY_BLINK_PIN[2] 5         //Output Blinker 3 kein Channel,keine Verbindung zu FHEM
// Pin 10:  connected to ChipSelect CC1101
// Pin 11, 12, 13: SPI (Miso, Mosi CLK) CC1101
// PIN 2: GD0 CC1101
// PIN 4: StateLED
// PIN 8: Config-button


// number of available peers per channel
#define PEERS_PER_CHANNEL 4
// max number of loops for pulswidth
int MAX_NO_LOOP = 5000;

// all library classes are placed in the namespace 'as'
using namespace as;

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x00,0xBE,0x00},       // Device ID
    "JP00BE0000",           // Device Serial
    {0x00,0xbe},            // Device Model
    0x12,                   // Firmware Version
    as::DeviceType::Switch, // Device Type
    {0x01,0x00}             // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,BatterySensor,Radio<RadioSPI,2> > Hal;

DEFREGISTER(Reg0,DREG_INTKEY,DREG_LEDMODE,MASTERID_REGS,DREG_LOWBATLIMIT)
class SwList0 : public RegList0<Reg0> {
public:
  SwList0(uint16_t addr) : RegList0<Reg0>(addr) {}
  void defaults () {
    clear();
    lowBatLimit(22);
  }
};

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

  virtual void configChanged () {
    DevType::configChanged();
    uint8_t lowbat = getList0().lowBatLimit();
    DDECLN(lowbat);
    if( lowbat > 0 ) {
      battery().low(lowbat);
    }
  }
};

// Mod WS
int peri_max[3] = {50,50,50};         // number of loops for blink/no blink time
int peri_count[3] = {1,1,1};         // counter for actual number of loops
int peri_set[3] = {500,500,500};           // Counter for setting peri_max counting SWITCH2 on-time, init = 500
int peri_set_max[3] = {MAX_NO_LOOP,MAX_NO_LOOP,MAX_NO_LOOP}; // Limit for peri_max
bool rel_old[3] = {LOW,LOW,LOW}; //
bool blinki[3] = {LOW,LOW,LOW}; //
int peri_scale = 5; // loops pulsewidth = loops/peri_scale (peri_max = peri_set/peri_scale)

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

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for( uint8_t i=1; i<=sdev.channels(); ++i ) {
      Peer ipeer(devid,i);
      sdev.channel(i).peer(ipeer);
    }
  }
}


void setup () {

// Mod WS
  pinMode(RELAY_BLINK_PIN[2], OUTPUT);   
 
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY_EA_PIN[0]);
  sdev.channel(2).init(RELAY_PW_PIN[0]);
  sdev.channel(3).init(RELAY_EA_PIN[1]);
  sdev.channel(4).init(RELAY_PW_PIN[1]);
  sdev.channel(5).init(RELAY_EA_PIN[2]);
  sdev.channel(6).init(RELAY_PW_PIN[2]);
  sdev.channel(7).init(RELAY_BLINK_PIN[0]);
  sdev.channel(8).init(RELAY_BLINK_PIN[1]);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  initPeerings(first);
  // stay on for 15 seconds after start
  hal.activity.stayAwake(seconds2ticks(15));
  // measure battery every hour
  hal.battery.init(seconds2ticks(60UL*60),sysclock);
  sdev.initDone();

  digitalWrite(RELAY_BLINK_PIN[0],LOW);
  digitalWrite(RELAY_BLINK_PIN[1],LOW);
  digitalWrite(RELAY_BLINK_PIN[2],LOW);
}
int i = 2;
int count = 0;
int count_diff = 0;


void loop() {
  bool worked = hal.runready();

// Mod WS start

for (i=0;i<3;i++) {

count++;
if (count >= 10000) {count = 0;} //Schleifnkontrolle für Geschindigkeit
count_diff = count - peri_count[0]; //Kontrolle ob alle perioden erfasst werden

  if( digitalRead(RELAY_EA_PIN[i]) == HIGH ) { //Blinker is set on
    peri_count[i]++;
     Serial.print("peri_count: ");
     Serial.println(peri_count[i]);
 
    if( peri_count[i] >= peri_max[i] ) {
      blinki[i] = !blinki[i];
      digitalWrite(RELAY_BLINK_PIN[i],blinki[i]);
      peri_count[i] = 0;
    }
  }
  else {
    blinki[i] = LOW;
    digitalWrite(RELAY_BLINK_PIN[i],blinki[i]) ;
  }

  if( digitalRead(RELAY_PW_PIN[i]) == HIGH) {  // set new duration of blink / no blink time
    if (rel_old[i] == LOW) peri_set[i] = 0;
    if (peri_set[i] <= peri_set_max[i]) {
      peri_set[i]++;
    }
  }
  else {
    peri_max[i] = peri_set[i]/peri_scale;
  }
  rel_old[i] = digitalRead(RELAY_PW_PIN[i]);

}
// Mod WS end

 
  bool poll = sdev.pollRadio();
 
  if(RELAY_EA_PIN[0] == LOW && RELAY_PW_PIN[0] == LOW) {
    if( worked == false && poll == false ) {
      hal.activity.savePower<Sleep<> >(hal);
    }
  }
}


Viele Grüße
Werner

Beetle2003

Zitat von: McShire am 13 Januar 2021, 02:05:24

Hallo Ralf,
hat ein bisschen gedauert, ist jetzt fertig "quick and dirty"
3 Blinker, mehr geht nach diesem Verfahren wegen der begrenzten Ausgänge nicht.
jeder Blinker hat 3 Kanäle, Ein/Aus, Pulsweite, Blinker-Ausgang.
Falls man mehr Blinker braucht, muss man ein vollkommen neues device in FHEM schaffen,
das dann die Daten anders überträgt. Das jetzige Modell ist ja nur von einem Aktor abgeleited.
Falls Du es gebrauchen kannst, viel Spass damit.



Viele Grüße
Werner

Guten Morgen Werner,

Ich habe das schlechte Wetter gestern genutzt um mich mit deinem Vorschlag zu beschäftigen.
Vielen Dank für die Mühe. Mir fehlt oft die Idee, ein fertiges Produkt für meine Belange zu ändern.

Ich habe aufgrund deiner Grundidee den 8 Fach Schalter wie folgt geändert:
2x BlinkLed, 3x leuchtende LEDs welche geschaltet werden können und die Blinkfrequenz über einen Kanal für beide Ausgänge festgelegt werden.

Was mache ich damit:
Ich habe dieses Modul in das Gehäuse für meinen Kartenleser eingebaut.
Led1. Signal Alarmanlage ein/aus
Led2 blink. Signalisierung Aktivierung / Deaktivierung Alarmanlage ( Funktion wurde ausgeführt)
Led3 blink. Meldung Wassermelder Wasser erkannt
Led4 und 5. Duo Led.   Türen / Fenster min 1 offen oder alle geschlossen.

Danke für deine Hilfe

McShire

Hallo Ralf,
eine gute Idee, zum Ein-und Ausschalten einen Kartenleser zu verwenden und mit LEDs die Ausführung zu bestätigen.
Kann ich vielleicht gut verwenden.
Ein- Ausschalten für Alarm, Prüfung Türen und Fenster zu usw. mache ich mit einem 4-fach-Taster. (Homebrew HB_... batterieschonend in Ruhe 4,7uA).
Die Rückmeldung bekomme ich über SIP-Anrufe auf mein Mobiltelefon.
Insbesondere Warnmeldungen wie Wasserschaden, Fenster bei Abwesenheit auf, Alarm, Rauchmelder usw.
Bleib gesund und eine schöne Zeit
Werner