RWE/Innogy/Livisi Bewegungsmelder WMD - Homematic/AskSinPP Firmware

[papa]

Hab das erst mal so gelassen. Keine Zeit das Ding wieder aufzumachen

[Surfi]

Ich habe mir einen Pogo Pin Adapter gebastelt, damit kann man den BM flashen, ohne ihn zu öffnen.

[Steigerbalett]

Ich habe mir einen Pogo Pin Adapter gebastelt, damit kann man den BM flashen, ohne ihn zu öffnen.

Den WMDO muss man leider komplett auseinander bauen um ihn zu flashen...


Aber aktuell funktioniert der WMDO so für mich nicht ausreichend. Ich werde dann wohl mal, wie von Jérôme vorgeschlagen, die Version von Peter-Matic kompilieren und testen - wenn ich die Zeit finde.

[guwo]

hallo,

Eine Frage zum Flashen: ich habe mir auch einen WMDO besorgt und wollte ihn neu programmieren. Ich habe es nicht geschafft, die verklebten Platinen zu trennen und die genauen Flash Pins zu finden. Es gibt auf der Oberseite den Anschluss PRG1 (neben MP1 und MP2). Dort sind 6 Pins als Kontakte rausgelegt. GND ist Pin1. Die anderen konnte ich nicht zuordnen. Wie habt ihr den Programmer angeschlossen?

Danke.

[Surfi]

viewtopic.php?f=76&t=64100&hilit=brc8&start=10#p634140

Die Reihenfolge ist immer die gleiche

[Sunti]

Hier geht es um den WMDO - Bewegungsmelder draußen

Hallo miteinander,

leider ist es hier ja sehr ruhig geworden - nachdem mir meine alte IDE Installation beim Testen von "Peter-Matic" https://github.com/Peter-matic/HM-Sec-MDIR_WMD nur wilde Fehlermeldungen habe ich mich auch nicht mehr drum gekümmert.

Gestern habe ich eine ganz neue Installation von IDE aufgesetzt - genau nach Peter`s super Anleitung gearbeitet, Jeromes Hinweis auf Seite 10 umgesetzt (nur ohne PIR_PIN3 und PIR_PIN4) und siehe da - sauber durchgelaufen

Kurzfazit nach Kurztestzeit von ca 24 Stunden - Bewegungserkennung super !!! - Helligkeitsmessung unbrauchbar

Insgesamt habe ich 4 WMDO geflasht - alle meine Bewegungsmelder sind eingestellt auf:

Jedem Sensorimpuls und Sendeabstand klassisch und Helligskeitsfilter 2

2x WMDO parallel neben einem originalem HM-Sen-MDIR-O-2 - die vielen blauen und grünen "Bewegungen" kamen von der "Montage" - nur eine "grüne" Bewegung die die anderen Zwei nicht gemeldet haben:

Dann habe ich noch einen WMDO draußen als reinen Kamera"auslöser" und einen innen im Treppenhaus getestet - keine "Fehlbewegungen" und alle echten Bewegungen korrekt gemeldet


Tja nur leider läuft das mit Helligkeitswerten nicht so gut - hier der von den Dreien seit der Installation:
Tiefster Helligkeitswert bei den beiden WMDO ist 34 so wie im Sketch vorgegeben

Peter beschreibt ja sehr genau was und warum er das in seiner LMSS.h gemacht hat - ich kann noch den Trick mit den "255" erkennen - dann hören für mich die Möglichkeiten der "Anpassung" schlichtweg auf...

Alle ÄNDERUNGEN habe ich oberhalb mit // GEÄNDERT .... dokumentiert

Code: Alles auswählen

```cpp
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2023-04-12 modified by Peter.matic Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// ci-test=yes board=328p aes=no
//- -----------------------------------------------------------------------------------------------------------------------

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

// define this if you have a TSL2561 connected at address 0x29
// #define USE_TSL2561

// define this if you have a BH1750 connected at address 0x23
// #define USE_BH1750

// define this if you have a LDR or analougue sensor like LMSS-101 at analog input 
#define USE_LMSS

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

#if defined(USE_TSL2561)
#include <sensors/Tsl2561.h>
#elif defined(USE_BH1750)
#include <sensors/Bh1750.h>
#elif defined(USE_LMSS)
#include <sensors/LMSS.h>
// pin to measure LMSS-101
#define LMSS_SENSE_PIN A6
// pin to power LMSS-101 (or 0 if connected to vcc)
#define LMSS_ACTIVATOR_PIN 4
// curve steepness
#define LMSS_PARAM_M -129561
// axis intercept 
#define LMSS_PARAM_B 710343
// min value of measuring range
// GEÄNDERT #define LMSS_PARAM_MIN 34
#define LMSS_PARAM_MIN 4
// max value of meauring range
// GEÄNDERT #define LMSS_PARAM_MAX 600
#define LMSS_PARAM_MAX 254
#endif

#include <MultiChannelDevice.h>
#include <Motion.h>

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 8
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 0
// Arduino pins for the PIRs (2 PIRs * 2 channels each)
#define PIR_PIN1 14
#define PIR_PIN2 15
// GEÄNDERT #define PIR_PIN3 16
// GEÄNDERT #define PIR_PIN4 17

// === Battery measurement ===
#define BAT_VOLT_LOW        33  // 3.3V low voltage threshold
#define BAT_VOLT_CRITICAL   30  // 3.0V critical voltage threshold, puts AVR into sleep-forever mode
// Internal measuring: AVR voltage
//#define BAT_SENSOR BatterySensor
// External measuring: Potential devider on GPIO; required if a StepUp converter is used
// one can consider lower thresholds (low=20; cri=13)
#define BAT_SENSOR          BattSensor<SyncMeter<ExternalVCC<A7,0xFF,LOW,3000,20>>>

// number of available peers per channel
#define PEERS_PER_CHANNEL 6

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0xX,0xX,0xX},       // Device ID
    "XXXXXXXXXX",           // Device Serial
    {0x00,0x5D},            // Device Model GEÄNDERT AUF HM-Sen-MDIR-O
    0x16,                   // Firmware Version
    as::DeviceType::MotionDetector, // Device Type
    {0x01,0x00}             // Info Bytes
};

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<LED_PIN> LedType;
// typedef AskSin<LedType,BAT_SENSOR,RadioType> Hal;
typedef AskSin<NoLed,BAT_SENSOR,RadioType> Hal;

#if defined(USE_TSL2561)
typedef MotionChannel<Hal,PEERS_PER_CHANNEL,List0,Tsl2561<TSL2561_ADDR_LOW> > MChannel;
#elif defined(USE_BH1750)
typedef MotionChannel<Hal,PEERS_PER_CHANNEL,List0,Bh1750<0x23> > MChannel;
#elif defined(USE_LMSS)
typedef MotionChannel<Hal,PEERS_PER_CHANNEL,List0,Lmss<LMSS_SENSE_PIN,LMSS_ACTIVATOR_PIN,LMSS_PARAM_M,LMSS_PARAM_B,LMSS_PARAM_MIN,LMSS_PARAM_MAX>> MChannel;
#else	
typedef MotionChannel<Hal,PEERS_PER_CHANNEL,List0> MChannel;
#endif

typedef MultiChannelDevice<Hal,MChannel,1> MotionType;

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

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  motionISR(sdev,1,PIR_PIN1);
  motionISR(sdev,2,PIR_PIN2);
  // GEÄNDERT motionISR(sdev,3,PIR_PIN3);
  // GEÄNDERT motionISR(sdev,4,PIR_PIN4);
  
  hal.initBattery(60UL*60,BAT_VOLT_LOW,BAT_VOLT_CRITICAL); // Measure Battery every 1h
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }
    // if nothing to do - go sleep
    hal.activity.savePower<Sleep<>>(hal);
  }
}
```

Schönen Restsonntag Greetz SunTi

[Peter.matic]

Hallo in die Runde,

ja, tatsächlich ist es in den letzte Wochen und Monaten etwas ruhig um das Thema geworden. Ich hatte mich anfangs recht intensiv mit demThema beschäftigt, komme aber wegen anderer Projekte seither nicht mehr so recht dazu.

Wie ich deinem Sketch entnehmen kann, hast du den min und max Wert der Helligkeitsmessung auf 4 bzw. 600 geändert.
Aber offensichtlich entsprechend des Diagramms nur für dir rote Linie. Grün und Blau sind wohl noch auf einem Offset von 34.

Im Prinzip sieht das doch alles ganz gut aus. Ohne einen Bezugswert zur tatsächlichen Helligkeit zu haben, kann man nicht beurteilen was nun falsch oder richtig wäre.
Ein min Wert von 4 ist schon sehr dunkel. Die kleinste Resthelligkeit bringt da den Messwert etwas hoch. Und tatsächlich geht er ja zwischen 4:00 und ca. 6:00h auf 4 zurück. Vorausgesetzt, dass die Helligkeit danach auf ca. 550 Lux ansteigt, sind grün und blau am Anschlag, während rot noch einen geringeren Wert anzeigt. Auch das wäre m. E. korrekt. Solange man aber keinen Referenzwert der tatsächlichen Helligkeit hat, kann man das nur vermuten.

Ich hatte die Werte so gewählt, um die Kennlinie möglichst eng an die des Originalen HM-SEN-MDIR anzupassen.

Es gibt aber noch ein paar andere Baustellen, um die ich mich bisher auch noch nicht kümmern konnte:

Ich habe seit einigen Monaten 3 WMDs im Einsatz. Seit der Änderung Jeromes mit der Flankenauswertug ist es in all den Monaten zu keiner Fehlauslösung mehr gekommen.
Das Problem, dass die Helligkeitsmeldung alle 19 Sekunden statt 5 Minuten kommt, habe ich ganz einfach gelöst, indem ich in der Motion.h Zeile 65 die Zeit hochgedreht habe, bis wieder 5 Minuten draus wurden.

Inzwischen habe ich jedoch festgestellt, dass schon nach 3 Monaten die Batterien leer sind. Der Stromverbrauch ist also zu hoch.

Außerdem dauert es ca. 2-3 Sekunden, bis das Licht angeht, wenn man einen dunklen Raum betritt. Hier ist also auch noch Raum für Optimierung.

[Sunti]

Hallo miteinander,

@Peter - schön das du vorbeischaust

den min. & max. Wert habe ich im ersten Diagramm nicht geändert - es sind die in deinem Sketch vorgesehen Werte von 34 min und 600 max

Die rote Kurve ist die vom original HM-Sen-MDIR-O-2


Später habe ich dann den original HM-Sen-MDIR-O-2 und einen weiteren geflashten WMDO auf die Fensterbank gelegt um schneller mit Werten "herumspielen/testen" zu können.

In deiner tollen Beschreibung erwähnst du ja das man die Werte anpassen kann - welche sind das?

Danke Greetz Markus alias SunTi

[jp112sdl]

Das Problem, dass die Helligkeitsmeldung alle 19 Sekunden statt 5 Minuten kommt, habe ich ganz einfach gelöst, indem ich in der Motion.h Zeile 65 die Zeit hochgedreht habe, bis wieder 5 Minuten draus wurden.

Inzwischen habe ich jedoch festgestellt, dass schon nach 3 Monaten die Batterien leer sind. Der Stromverbrauch ist also zu hoch.

Da haut doch irgendwas mit dem Timer / Sleep nicht hin.

Das eine hängt mit dem anderen zusammen.

[Peter.matic]

@Jerome:

Ja, so was in der Art hatte ich mir schon gedacht. Aber momentan keine Zeit weiter zu graben…

@Sunti:

Das Verhalten des Helligkeitssensors wird im Datenblatt als Gerade im logarithmischen Koordinatensystem dargestellt.
Dies wurde als mathematische Funktion nachgebildet.

Die allgemeine Geradengleichung lautet y=mx+b

An lmss.h werden dazu 4 Parameter übergeben.

//curve steepness LMSS_PARAM_M ist die Seigung m der Kurve. Die Steigung ist negativ, also kleinere Spannung bei hellerer Beleuchtung. Ein größerer negativer Wert des Parameters macht die Kurve steiler (mehr Millivolt pro Lux)

//axis intercept LMSS_PARAM_B ist der sogenannte Achsenabschnitt b in der Geradengleichung. Eine Vergrößerung dieses Wertes bewirkt eine Parallelverschiebung der Kurve nach oben.

Die beiden weiteren Parameter dienen zum Eingrenzen des Messbereichs. Sie wurden eingeführt um das Verhalten des HM MDIR möglichst genau nachzubilden.

// min value of measuring range LMSS_PARAM_MIN setzt bei Dunkelheit (0.1 Lux) einen Offset von z.B. 34. Wurde eingeführt, weil das Original das auch so macht. Kann im Extremfall auch 0 sein.

// max value of meauring range LMSS_PARAM_MAX begrenzt den Messbereich auf z.B. 600 Lux. Grund wie oben. Da der lmss-101 lt. Datenblatt bis 3000 Lux messen kann könnte man hier auch bis zu diesem Wert eintragen. Aber ohne Gewähr. Habe ich mit diesen Werten nie getestet.

Da zur Übertragung des Helligkeitswertes im Telegramm nur 1 Byte zur Verfügung steht, wird das Ergebnis dann noch auf 8 Bit umgerechnet. (Z.B. MIN 34, MAX 600 —> 0 Lux = 34, 600 Lux = 254)

Daraus folgt, das bei größerem Messbereich natürlich die Auflösung leidet.

Da die Intention aber bei einem Dämmerungsschalter zum Bewegungsmeldern liegt, ist alles oberhalb ca. 500 Lux sowieso hell und daher uninteressant.

Hoffe, dass ich jetzt nicht alle Klarheiten beseitigt habe.