Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
Moderator: Co-Administratoren
Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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
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
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
Der Dank gilt viel mehr @klassisch, der die Vorarbeit geleistet hat
In deinen Augen vielleicht...
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);
Code: Alles auswählen
if( hal.battery.critical() ) { hal.activity.sleepForever(hal); }
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!
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;
Dafür müsste auf die BatterySensorUni-Klasse umgestellt werden. Macht @klassisch vielleicht noch.
-
- Beiträge: 3974
- Registriert: 24.03.2011, 04:32
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 110 Mal
- Danksagung erhalten: 71 Mal
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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.
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.
Oh, nein, das sehe ich nicht so. Habe mehr gefragt als gemacht...
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
@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
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
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte
- deimos
- Beiträge: 5396
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 957 Mal
- Kontaktdaten:
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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
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
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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.
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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.
Das war wohl ein Flüchtigkeitsfehler, den ich auch nur zufällig entdeckt hab.
Bei solchen Bugs würde ich mich über ein Issue im Github freuen. Dann behalte ich es auch im Auge und vergesse es nicht.harvey hat geschrieben: ↑16.08.2018, 21:15Das "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).
-
- Beiträge: 3974
- Registriert: 24.03.2011, 04:32
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 110 Mal
- Danksagung erhalten: 71 Mal
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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.
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.
-
- Beiträge: 3974
- Registriert: 24.03.2011, 04:32
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 110 Mal
- Danksagung erhalten: 71 Mal
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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:
Die bd-Instanz wird so instanziert
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
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?
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:
Wenn diese Zeile auskommentiert ist, geht der Ruhestrom auf 20µAbd.enable(sysclock);
Die bd-Instanz wird so instanziert
Der HM-WDS30-OT2-NTC.ino scheint das Burst Thema ganz anders zu handeln.BurstDetector<Hal> bd(hal); // to wake by remote burst, taken from HM-LC-SW1-BA-PCB.ino
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);
}
};
Aber ansonsten gibt es nur ein
und einburstRX(false)
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?
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4
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.
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.