Anleitung Nachbau Bewegungsmelder innen HM-SEC-MDIR-2

[TomMajor]

Das mit dem extra Interrupt beim Senden kommt mir bekannt vor. Ein FHEM Kollege hatte da mal umfangreiche Test mit dem HB-UNI-Sensor1 und AS312 gemacht.
https://github.com/TomMajor/SmartHome/t ... en-eingang

ist schon länger her, aber ich glaube deswegen ist bei mir Code drin, der den motion Interrupt erst etwas später nach dem Senden wieder freigibt.
Und der Transistor half auch bei der Sache.
Bilder und Tests sind von fhemfreund.

[ivo-int]

Hallo Tom

Das mit dem extra Interrupt beim Senden kommt mir bekannt vor. Ein FHEM Kollege hatte da mal umfangreiche Test mit dem HB-UNI-Sensor1 und AS312 gemacht.
https://github.com/TomMajor/SmartHome/t ... en-eingang

ist schon länger her, aber ich glaube deswegen ist bei mir Code drin, der den motion Interrupt erst etwas später nach dem Senden wieder freigibt.
Und der Transistor half auch bei der Sache.
Bilder und Tests sind von fhemfreund.

Die Transistor Schaltung habe ich bei mir nach deinem Beispiel umgesetzt. Das funktioniert auch sehr gut, ich habe es mit einem 3-fach Taster Sketch getestet. Dort geht das einwandfrei.

Mit diesem Thema bin ich auch bereits länger beschäftigt. Die ganzen Aski++ Bibliotheken sind für meine begrenzten C++ Kenntnisse sehr komplex.

Im Moment verfolge ich den Input von pa-pa mit der Verzögerten Einschaltung des Interrupts. Da bin ich aber noch am Testen. Ich werde mich in den nächsten Tagen mit diesem Thema auseinander setzen.

Gruss Ivo

[ivo-int]

Kann es sein, dass das Senden einen Motion-Interrupt auslöst ? Da gab es früher schon mal Probleme, weshalb der PirInterrupt während des Sendens abgeschalten wird. Mach mal nen Delay da mit rein, bevor der Interrupt wieder eingeschalten wird.

Ich habe ein Delay mit verschiedenen Werten bis zu 10s eingefügt.

Code: Alles auswählen

void pirInterruptOn () {
	// -------------------
	delay(10000);
	// -------------------
    isrenabled=true;
  }

Um die Helligkeit zu simulieren habe ich einen Random-Wert übergeben.

Code: Alles auswählen

// -------------------
	pload[0] = random(1, 99999);
// -------------------

Den Sendeabstand habe ich auf 2min gekürzt.

Code: Alles auswählen

// send the brightness every 5 minutes to the master
  #define LIGHTCYCLE seconds2ticks(2*60)

Mit einem Delay von ca > 5s war das Zyklische senden der Bewegung weg. siehe Bild

Was mir jetzt aber aufgefallen ist, dass die Helligkeit vor dem Senden auf 0 geht. Mit dem Delay wird sie auch nicht mehr gesendet.

Hast du noch eine weitere Idee?

[Horbi]

Das mit dem extra Interrupt beim Senden kommt mir bekannt vor. Ein FHEM Kollege hatte da mal umfangreiche Test mit dem HB-UNI-Sensor1 und AS312 gemacht.
https://github.com/TomMajor/SmartHome/t ... en-eingang

Ich habe mir gerade mal das Datenblatt angeschaut, eigentlich dürfte der Transistor nicht notwendig sein.
Der AM312 wie auch der AM612 geben für den Schaltausgang folgendes an:

Das heißt ein low wird signalisiert als <1V, ein high wird signalisiert als >2V
Das sollte der AVR gut erkennen, ist zwar etwas außerhalb der Spec aber nur knapp

Was mir jetzt aber aufgefallen ist, dass die Helligkeit vor dem Senden auf 0 geht. Mit dem Delay wird sie auch nicht mehr gesendet.

Schaul mal in der motion.h und setz dort ein DPRINT

Code: Alles auswählen

  uint8_t status () {
    brightsens.measure();
    uint32_t bright = brightsens.brightness();
    if( bright > maxbright ) {
      maxbright = bright;
    }
    DPRINT(F("brightsens: ")); DPRINTLN(bright);
    // scale to value between 0 - 255s
    return (uint8_t)(bright * 255UL / maxbright);
  }

Dann siehst Du ob dort das Helligkeitsreading noch existiert.

Ich habe meinen PIR jetzt mal gegen eine Wand gerichtet, das Interval auf 5 Sekunden gestellt und eine Stunde getestet.
Bei mir hat der PIR nicht einmal ausgelöst.

[ivo-int]

Ich habe meinen PIR jetzt mal gegen eine Wand gerichtet, das Interval auf 5 Sekunden gestellt und eine Stunde getestet.
Bei mir hat der PIR nicht einmal ausgelöst.

Das Problem ist nicht der Pir, der auslöst. Immer wenn der Helligkeitswert gesendet wird löst dies eine Flankentriggerung aus, siehe Bild. Wenn ich das Zyklische senden der Helligkeit ausschalt geschieht das nicht.

Dann frage ich mich schon aus welchem Grund du das Zyklische Senden/Triggern nicht hast? Hast du am Sketch Änderungen vorgenommen?

[TomMajor]

Das mit dem extra Interrupt beim Senden kommt mir bekannt vor. Ein FHEM Kollege hatte da mal umfangreiche Test mit dem HB-UNI-Sensor1 und AS312 gemacht.
https://github.com/TomMajor/SmartHome/t ... en-eingang

Ich habe mir gerade mal das Datenblatt angeschaut, eigentlich dürfte der Transistor nicht notwendig sein.
Der AM312 wie auch der AM612 geben für den Schaltausgang folgendes an:

Bild1.png

Das heißt ein low wird signalisiert als <1V, ein high wird signalisiert als >2V
Das sollte der AVR gut erkennen, ist zwar etwas außerhalb der Spec aber nur knapp

Soweit ich mich erinnere und auch auf github dokumentiert habe war der Transistor bei fhemfreund nicht wegen der Pegel sondern wegen a) Ruhestrom b) weniger falsche motion interrupts durch CC1101 Senden.

[Horbi]

Soweit ich mich erinnere und auch auf github dokumentiert habe war der Transistor bei fhemfreund nicht wegen der Pegel sondern wegen a) Ruhestrom b) weniger falsche motion interrupts durch CC1101 Senden.

Ich bin kein Elektroniker, aber für Ruhestrom sitzt der Transistor am falschen Pin - so wie die Schaltung aufgebaut ist, verstärkt er ja nur den Schaltausgang vom AM312. Der eigentliche Stromverbrauch kommt aber doch über den Betrieb des AM312 und natürlich über den Linearregler auf der kleinen Platine.

Dann frage ich mich schon aus welchem Grund du das Zyklische Senden/Triggern nicht hast? Hast du am Sketch Änderungen vorgenommen?

Nein, ich habe nichts am code geändert.
Könnte es sein das die Kabellänge eine Rolle spielt, also das das Funkmodul einstrahlt und weil wir knapp außerhalb der Specs für high/low am AVR sind, das die ungewollten Interrupts produziert?

Hast Du mal ohne PIR getestet? Also den PIR Eingang an einen Taster und mit Widerstand gegen High schalten?

An der Asksin kann es ja nicht liegen - Es wird ja bei jedem Sketch irgendwo ein Satus gesendet und zumindest der Gerätetaster ist immer als Eingang definiert und es kommt nie zu ungewollten Interrupts. Scheint ja ein Phänomen vom PIR zu sein...

[ivo-int]

Darf ich dich bitte ein paar Seiten weiter vorne meine bereits getestetes zu lesen?

Ich bin kein Elektroniker, aber für Ruhestrom sitzt der Transistor am falschen Pin - so wie die Schaltung aufgebaut ist, verstärkt er ja nur den Schaltausgang vom AM312. Der eigentliche Stromverbrauch kommt aber doch über den Betrieb des AM312 und natürlich über den Linearregler auf der kleinen Platine.

Die Schaltung ist korrekt, das kann ich mit guten gewissen bestätigen. Dieser soll etwas ganz anderes Bewirken, ist aber auch in der verlinkten Beschreibung aufgeführt. Das hat Tom geschrieben, dass das den Ruhestrom betrifft.

Nein, ich habe nichts am code geändert.

Somit kann das ausgeschlossen werden.

Hast Du mal ohne PIR getestet? Also den PIR Eingang an einen Taster und mit Widerstand gegen High schalten?

Hier habe ich bereits viel probiert. Nur mit 10k Widerstand und verschiedene Pir, Anschaltungen. Eben, nur mit Taster geht nicht. Dann fehlt das Bezugspotential. Einige schreiben dass das ohne Probleme geht. Bei mir senden alle getesteten AVR-Varianten ca. im 2s Takt.

An der Asksin kann es ja nicht liegen - Es wird ja bei jedem Sketch irgendwo ein Satus gesendet und zumindest der Gerätetaster ist immer als Eingang definiert und es kommt nie zu ungewollten Interrupts.

Und hier irrst du dich. Du musst dir einmal die Motion.h Datei ansehen. Dort wird der Interrupt für das Senden kurz ausgeschaltet. Sieh Kommentar von papa

Das Brigness Senden kann auch nicht ausgeschalten werden. Damit wird das "Lebenszeichen" des Pir in der CCU überwacht.

Ich werde mich nochmals auf das von papa vorgeschlagene Delay kümmern und das nochmals ausgiebig testen.

[Horbi]

Vielleicht kommt das falsch rüber, aber ich versuche Dir gerade zu helfen.

Hier habe ich bereits viel probiert. Nur mit 10k Widerstand und verschiedene Pir, Anschaltungen. Eben, nur mit Taster geht nicht. Dann fehlt das Bezugspotential. Einige schreiben dass das ohne Probleme geht. Bei mir senden alle getesteten AVR-Varianten ca. im 2s Takt.

Probiere es mal so, ich wüsste nicht warum das nicht gehen soll.

Bild1.png (21.55 KiB) 964 mal betrachtet

Und hier irrst du dich. Du musst dir einmal die Motion.h Datei ansehen. Dort wird der Interrupt für das Senden kurz ausgeschaltet. Sieh Kommentar von papa

Ein Interrupt wird nicht ausgelöst weil er an- oder ausgeschaltet wird, ein Interrupt wird ausgelöst weil sich ein Pin Zustand geändert hat.
Allerdings wird in der motion.h der Interrupt nicht ausgeschaltet sondern die Bearbeitung blockiert.

Da wird ein Flag gesetzt

Code: Alles auswählen

  void pirInterruptOn () {
    isrenabled=true;
  }

Und in der Interrupt Routine wird es abgefragt

Code: Alles auswählen

  // runs in interrupt
  void motionDetected () {
    if( isrenabled==true ) {
      // cancel may not needed but anyway
      sysclock.cancel(*this);
      // activate motion message handler
      sysclock.add(*this);
      DPRINTLN(F("motion detected"));
    }
  }

[TomMajor]

Ich bin kein Elektroniker, aber für Ruhestrom sitzt der Transistor am falschen Pin - so wie die Schaltung aufgebaut ist, verstärkt er ja nur den Schaltausgang vom AM312. Der eigentliche Stromverbrauch kommt aber doch über den Betrieb des AM312 und natürlich über den Linearregler auf der kleinen Platine.

Eventuell würde es dann helfen, die Ratschläge von Elektronikern anzunehmen.
Es geht hier nicht um Verstärkung sondern um statische Pegel, pull-ups und daraus resultierende Ruheströme der ganzen Kette Sensor bis AVR input für den Fall "keine Bewegung".
fhemfreund ist Elektroniker, meine Wenigkeit auch, und er hat damals eine Kleinserie UniSensor1 + AM312 aufgelegt und sich sehr intensiv mit dem Thema beschäftigt, das weiß ich auch der umfangreichen Kommunikation mit ihm.