Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

[harvey]

Hallo Jerome, @ jp112sdl

super die Änderung bzgl Batterie in HB-UNI-SenAct-4-4, Danke!

Als Fliegenschißänderung eventuell noch:
- als Unterspannung eine letzte Hilfe-LOW_BAT Message senden und dann in den halt gehen (Tiefentladungsschutz)
- Sabotagekontakt in beiden Varianten (RC und SC)
- CYCLETIME auch verwenden, nicht nur deklarieren
- ((Batteriemessung unter Last, sind aber nur noch exotische Pins übrig, activ high für mosfet, active low für simple Last))

War mein erster verwendeter Sketch - und lief fast sofort (bis auf den alten jetzt geänderten Sabotagepin=9:-),
daher nochmals vielen Dank!

cu
Harvey

[jp112sdl]

Hallo Jerome, @ jp112sdl

super die Änderung bzgl Batterie in HB-UNI-SenAct-4-4, Danke!

Der Dank gilt viel mehr @klassisch, der die Vorarbeit geleistet hat

Als Fliegenschißänderung eventuell noch:

In deinen Augen vielleicht...

- als Unterspannung eine letzte Hilfe-LOW_BAT Message senden und dann in den halt gehen (Tiefentladungsschutz)

Ich denke nicht, dass die Spannung so schnell sinken wird, dass es nicht noch Zeit bis zur nächsten zyklischen Nachricht hat.
Ansonsten müsste man das gesamte Batteriekonzept überdenken.
Du kannst aber noch

Code: Alles auswählen

 hal.battery.critical(xx);

deklarieren und in der loop() dann bei Erreichen dieser kritischen Spannung in eine Art "Offline-Modus" gehen.

Code: Alles auswählen

if( hal.battery.critical() ) { hal.activity.sleepForever(hal); }

- Sabotagekontakt in beiden Varianten (RC und SC)

Der ist beim SC nur drin, weil ich den XML-Inhalt komplett vom Fensterkontakt übernommen habe und er in der ThreeState.h bereits berücksichtigt wird.
Wenn sich jemand die Mühe macht und Addon + Sketch um den Sabotagekontakt für den RC noch erweitert, kann er mir gern einen PullRequest senden.
Mitarbeit begrüße ich sehr!

- CYCLETIME auch verwenden, nicht nur deklarieren

Wird doch...

Code: Alles auswählen

    class CycleInfoAlarm : public Alarm {
        MixDevice& dev;
      public:
        CycleInfoAlarm (MixDevice& d) : Alarm (CYCLETIME), dev(d) {}
        virtual ~CycleInfoAlarm () {}

        void trigger (AlarmClock& clock)  {
          set(CYCLETIME);
          clock.add(*this);
          dev.switchChannel(1).changed(true);
        }
    } cycle;

Oder an welcher Stelle meinst du?

- ((Batteriemessung unter Last, sind aber nur noch exotische Pins übrig, activ high für mosfet, active low für simple Last))

Dafür müsste auf die BatterySensorUni-Klasse umgestellt werden. Macht @klassisch vielleicht noch.

[klassisch]

- als Unterspannung eine letzte Hilfe-LOW_BAT Message senden und dann in den halt gehen (Tiefentladungsschutz)

Das fände ich nicht so gut und würde den Sinn der Meldung konterkarieren. Schließlich will ich die Meldung rechtzeitig und erwarte dann zumindest bei Sensoren, daß dann noch mind. 2 Wochen laufen, falls ich gerade mal auf Dienstreise bin.

Dafür müsste auf die BatterySensorUni-Klasse umgestellt werden. Macht @klassisch vielleicht noch.

Das habe ich schon umgesetzt, habe jetzt aber eine Dauermeldung. Muß wahrscheinlich die Grenzwerte anschauen und umrechnen. Vielleicht komme ich morgen Abend dazu, am WE ist wahrscheinlich keine Zeit dafür.
Aber Messen unter Last würde für mich bedeuten, daß ich während der (zyklischen) Sendemeldung messe. Ich will doch keinen extra Lastwiderstand einbauen und meine Batteriekapazität unnötig verheizen. Deshalb messen bei einer typischen Last unter ohnehin auftretenden Realbedingungen, also beim Senden. Ob die Prozessoren so multitaskfähig sind, weiss ich nicht. Ein Analogeingang mit spannungsabhängigem Interrupt wäre das Richtige.

Der Dank gilt viel mehr @klassisch, der die Vorarbeit geleistet hat

Oh, nein, das sehe ich nicht so. Habe mehr gefragt als gemacht...

[harvey]

@jerome und klassisch,

vielen Dank für die Antworten!

Das mit dem low_bat und sleep habe ich u.a. bei TomMajor gelesen wegen Instabilitäten bei Senden/DutyCycle ...
Fand ich eigentlich ganz vernünftig, bevor die Teile an der ein oder andern Stelle bei Unterspannung spinnen.
Vielleicht ist die Meldung "warning" ja für ein paar Wochen vorher, das "critical" aber dann nur noch Selbstschutz
der Anlage durch Abschaltung. Ich bastel mal ein wenig und meldle mich...

Sorry das mit dem Sabotagekontakt, aber sonst sind RC und SC doch praktisch Zwillinge. Da ich in der Tat
aufgrund der alten Doppelbelegung Sabotage auf Pin9 nur so lustige Dinge in der HomematicGUI gesehen hatte
dachte ich, warum sind die Zwillinge hier so unterschiedlich. (Jetzt ist der Sabotagekontakt ja auf Pin3 - super)

CYCLETIME oh je, habe die letzten Nächte zuviel gelötet, meine Augen
Ich hatte die BatteryCycleTime gesehen, die ja in "Langschreibweise" drinsteht, ansonsten aller ok, danke!

Also der Fliegenschiß ist so gemeint dass alles völlig gut ist und man/ich noch ein winziges Häärchen in der Suppe
dachte gefunden zu haben, war also nicht als Herabwertung der umfangreichen Examples++ zu sehen!
Hmmm, nicht böse sein, einen hab ich noch @Jerome: Das "Beispiel für die Verwendung der AsksinPP Bibliethek"
verwendet den Sketch "Hm-RC-P1". Dort ist allerding eine DuoLED<4,5> verwendet, Das Schaltungsbild zeigt nur die
LED an Pin4. Ist unkritisch, aber ... (will nicht meckern, nur Inkonsistenzen bereinigen helfen).

Danke für die Geduld!
cu
Harvey

[deimos]

Hi,

das Messen mit Extralast finde ich jetzt von der Idee auch nicht so prikelnd, dann wirklich lieber messen, wenn man durch das Senden Reallast hat. Multitasking können die AVRs nicht wirklich, wenn man von den Interrupts mal absieht. Aber an sich sollte es ja reichen, wenn man direkt im Anschluss an eine Aussendung die Batterie misst. Wenn man dann noch einen Step-Up verwendet, dann sollte man da imho schon rechtzeitig mitbekommen, wenn die Batterien leer werden, ohne das die Spannung komplett einbricht.

Bei der Schaltung, die bei Unterspannung auf Reset geht, bin ich mir auch nicht ganz sicher, ob die in der Praxis so ideal ist. System geht bei halbleeren Batterien in eine Unterspannung und wird durch Reset abgwürgt. Bis hierhin gut. Nur erhohlt sich die Spannung jetzt wieder, Reset wird wieder freigegeben, Gerät startet neu und schickt als erstes mal ein Funkpaket raus, welches dann wieder durch eine Lastspitze eine Unterspannung auslöst und der Kreislauf geht von vorne los. Da müsste wenn dann etwas rein, dass bei einer Unterspannung der Rest dauerhaft runtergezogen wird, bis man die Batterien gewechselt hat.

Viele Grüße
Alex

[jp112sdl]

Da müsste wenn dann etwas rein, dass bei einer Unterspannung der Reset dauerhaft runtergezogen wird, bis man die Batterien gewechselt hat.

Der von TomMajor verwendete MCP111-270 hat eine eingebaute Hysterese (auch in unterschiedlichen Größen, je nach Variante MCP1xx-nnn).
Bei Unterschreiten der Kennspannung wird sofort auf L geschaltet. H wird erst wieder, wenn VDD > Kennspannung + Hysterese.

[jp112sdl]

Sorry das mit dem Sabotagekontakt, aber sonst sind RC und SC doch praktisch Zwillinge.

Nein, sind sie gar nicht. Der RC sendet einen short-press oder long-press (für die Dauer des Tastendrucks). Der SC sendet einen State (0 / (100) / 200) beim Wechsel des Eingangspegels an einem (oder 2 beim RHS) Pin.

aufgrund der alten Doppelbelegung Sabotage auf Pin9 nur so lustige Dinge in der HomematicGUI gesehen hatte
dachte ich, warum sind die Zwillinge hier so unterschiedlich. (Jetzt ist der Sabotagekontakt ja auf Pin3 - super)

Das war wohl ein Flüchtigkeitsfehler, den ich auch nur zufällig entdeckt hab.

Das "Beispiel für die Verwendung der AsksinPP Bibliethek"
verwendet den Sketch "Hm-RC-P1". Dort ist allerding eine DuoLED<4,5> verwendet, Das Schaltungsbild zeigt nur die
LED an Pin4. Ist unkritisch, aber ... (will nicht meckern, nur Inkonsistenzen bereinigen helfen).

Bei solchen Bugs würde ich mich über ein Issue im Github freuen. Dann behalte ich es auch im Auge und vergesse es nicht.

[klassisch]

Just my 5ct zur dauerhaften Unterspannungsabschaltung:
Eines der größten Ärgernisse mancher, besonders der frühen, HM-Sensoren ist das Instabile Verhalten bei Batteriewechsel. Habe dabei schon einen Drehgriffkontakt und einen TFK ganz verloren und mußte solche etliche Male nach Batteriwechsel tagelang rumliegen lassen bevor sie wieder liefen. Ein 70 EUR Wassermelder zog irgendwann mal nach Batteriewechsel dauerhaft richtig viel Ruhestrom, wodurch die Batterien nach wenigen Wochen leer waren. Konnte ich aber durch einen fetten Elko (mit ausgesucht geringem Leckstrom) parallel zur Batterie reparieren.
Aus meiner Sicht ist sowas bei einem kommerziellen Produkt ein unverzeihlicher Fehler. Und auch bei einem Selbstbau Produkt würde ich keine Ruhe geben bis das abgestellt ist.
Falls nun die AskSin Teile auch so ein Verhalten hätten, dann müßten wir das eben lokalisieren und reparieren. Die dauerhafte Unterspannungsabschaltung würde den eigentlichen Fehler nur kaschieren und nicht wirklich beheben.
Dauerhafte (Teil-)Abschaltungen können bei sicherheitsrelevanten Systemen (safety nicht security) eine sinnvolle Lösung sein, wenn ein Monitor feststellt, daß die Systemintegrität nicht mehr gewährleistet werden kann. Aber von solchen Einsatzgebieten ist HM weit entfernt - weil nicht dafür entwickelt.

[klassisch]

So, große Peinlichkeit und Schande über mich!

Habe ja den Burstmode eingebaut und das aus dem HM-LC-SW1-BA-PCB.ino Sketch abgeschrieben ohne genau zu wissen, was ich tue. Also genau so wie man es nicht machen sollte.

Resultat: Ruhestrom liegt bei ca. 0.5mA, schankend bis auf 32µA und wieder zurück. Jedenfalls viel zu lange viel zu hoch. Geht nicht für ein Batteriegerät.
Alex hat mir dankenswerterweise mitgeteilt, daß der HM-WDS30-OT2-NTC.ino einen niedrigen Ruhestrom hat und in der Tat damit kommt das verwendete 644 Board von Alex auf 23µA. Damit kann man schon was anfangen.

Der Ruhestrom hat damit zu tun:

bd.enable(sysclock);

Wenn diese Zeile auskommentiert ist, geht der Ruhestrom auf 20µA
Die bd-Instanz wird so instanziert

BurstDetector<Hal> bd(hal); // to wake by remote burst, taken from HM-LC-SW1-BA-PCB.ino

Der HM-WDS30-OT2-NTC.ino scheint das Burst Thema ganz anders zu handeln.

Code: Alles auswählen

DEFREGISTER(Reg0, MASTERID_REGS, DREG_BURSTRX, DREG_TPARAMS, DREG_CYCLICINFOMSGDIS, DREG_LOCALRESETDISABLE)
class UList0 : public RegList0<Reg0> {
  public:
    UList0(uint16_t addr) : RegList0<Reg0>(addr) {}
    void defaults () {
      clear();
      localResetDisable(false);
      burstRx(false);
      tParamSelect(3);
      cyclicInfoMsgDis(0);
    }
};

Ich rate mal, daß man mit DEFREGISTER die Konfiguration in der CCU verwenden kann und dann auch den Burst ein und abhaken kann - sofern das xml dazu passt. Das wäre klasse.
Aber ansonsten gibt es nur ein

burstRX(false)

und ein

DPRINT("Wake-On-Radio: "); DDECLN(this->getList0().burstRx());

im Sketch. Letzteres sieht nach debug info aus.
Aber kein Timer der gesetzt wird, kein Burstdetektor der instanziert wird
Kennt jemand die verschiedenen Methoden und deren Unterschiede?

[jp112sdl]

Du vergleichst gerade Äpfel mit Birnen.

Der HB-UNI-SenAct-4-4 nutzt den BurstDetector als Empfänger (Aktor). Er muss also alle paar Millisekunden kurz lauschen, ob ein Burst Telegramm in der Luft liegt.

Der HM-WDS30-OT2-NTC ist ein Sender. Er geht nur in Betrieb, wenn die Zeit rum ist, mal wieder die Temperatur zu senden.
Der Parameter burstRx ist im HM-WDS30-OT2-NTC nur pseudo eingebunden, damit das Übertragen der Option von CCU zum Gerät ordentlich von diesem quittiert wird. burstRx wird nicht weiter berücksichtigt. Der HM-WDS30-OT2-NTC lässt sich so, wie der Code aktuell gestaltet ist, nicht wecken.