HM-LC-SW1-BA-PCB mit Stepup und ext. Batteriemessung

[der-pw]

Ich hatte die Idee, eine HM-Sensor Stepup Platine als HM-LC-SW1-BA-PCB zu verwenden.
Um eine Aussage zum Batteriestatus zu bekommen, möchte ich über den vorhanden Spannungsteiler die Spannung am VIN messen.
Als gutes Beispiel dient ja u.a. der HM-SEC-RHS, den man über

Code: Alles auswählen

#define DEVICE_CONFIG CFG_STEPUP_OFF,22,19

parametrisiert.

Allerdings ich bin zu blöd, alles dafür benötigte von "HM-SEC-RHS" in "HM-LC-SW1-BA-PCB" zu packen und erbitte hier Hilfe.
Desweiteren müsste man dann auch der CCU vorgaukeln es lägen mind. 5V an.
Da bekam ich an anderer Stelle vor einiger Zeit (ja jetzt möchte ich, weihnachtsbedingt, das Projekt wieder angreifen) von Jérôme den Tipp mit.

Code: Alles auswählen

uint8_t lowbat = getList0().lowBatLimit() / 3;

allerdings betrifft das ja die "alte" Batterieklasse.

[jp112sdl]

Als gutes Beispiel dient ja u.a. der HM-SEC-RHS, den man über
CODE: ALLES AUSWÄHLEN
#define DEVICE_CONFIG CFG_STEPUP_OFF,22,19
parametrisiert.

Das ist ja für den OTA Bootloader nur relevant.
Geht es dir beim HM-LC-SW1-BA-PCB auch um die Verwendung des OTA Bootloaders?

Da bekam ich an anderer Stelle vor einiger Zeit (ja jetzt möchte ich, weihnachtsbedingt, das Projekt wieder angreifen) von Jérôme den Tipp mit.
CODE: ALLES AUSWÄHLEN
uint8_t lowbat = getList0().lowBatLimit() / 3;
allerdings betrifft das ja die "alte" Batterieklasse.

Was meinst du mit "alte" Batterieklasse?

[der-pw]

Das ist ja für den OTA Bootloader nur relevant.
Geht es dir beim HM-LC-SW1-BA-PCB auch um die Verwendung des OTA Bootloaders?

Nein OTA ist nicht relevant für mein Vorhaben.

Was meinst du mit "alte" Batterieklasse?

Der Commit "BatterySensor changes" im HM-SEC-RHS, bin daher davon ausgegangen, dass es was "altes" und was "neues" gibt.
Nichts desto Trotz reicht es nicht, weil ich nicht weiß, wie ich die Methoden erfolgreich austausche. :-/

[jp112sdl]

Ändere InternalVCC in ExternalVCC<17,7,LOW,3000>
Zeile 48:

Code: Alles auswählen

typedef AskSin<StatusLed<LED_PIN>,BattSensor<AsyncMeter<ExternalVCC<17,7,LOW,3000> >>,Radio<RadioSPI,2> > Hal;

Parameter sind SENSPIN, ACTIVATIONPIN, ACTIVATIONSTATE, VCC

Warum im HM-Sec-RHS 3000mV als Referenzspannung gesetzt werden, kann ich dir jedoch nicht erklären.
Default sind 3300.

Vielleicht kann das jemand erklären?

[TomMajor]

Ändere InternalVCC in ExternalVCC<17,7,LOW,3000>
Zeile 48:

Code: Alles auswählen

typedef AskSin<StatusLed<LED_PIN>,BattSensor<AsyncMeter<ExternalVCC<17,7,LOW,3000> >>,Radio<RadioSPI,2> > Hal;

Parameter sind SENSPIN, ACTIVATIONPIN, ACTIVATIONSTATE, VCC

Warum im HM-Sec-RHS 3000mV als Referenzspannung gesetzt werden, kann ich dir jedoch nicht erklären.
Default sind 3300.

Vielleicht kann das jemand erklären?

Vielleicht weil papa den RHS mit seiner AskSinPP Platine mit CR2032 Versorgung betreibt?
Oder einen 3,0V StepUp hat.

[der-pw]

Code: Alles auswählen

AskSin++ V4.1.1 (Nov 16 2019 16:19:15)
Address Space: 32 - 258
CC init1
CC Version: 04
 - ready
Config Freq: 0x2165D2
eVcc: 2571

Dankeschön Jérôme!
Oh man, wenn man erstmal weiß wie es geht.

Warum im HM-Sec-RHS 3000mV als Referenzspannung gesetzt werden, kann ich dir jedoch nicht erklären.
Default sind 3300.

Vielleicht kann das jemand erklären?

Ich leider nicht. Kann aber sagen, dass die Messung nur 0,05V vom Multimeter ggü. interner Messung abweicht.

[der-pw]

Vielleicht weil papa den RHS mit seiner AskSinPP Platine mit CR2032 Versorgung betreibt?
Oder einen 3,0V StepUp hat.

Das ergibt Sinn. Der Step-Up TLV61224 hat i.d.T. 3V output.

[jp112sdl]

Ah, alles klar!

[der-pw]

Ich habe jetzt noch im setup

Code: Alles auswählen

hal.battery.critical(10);

und im Loop

Code: Alles auswählen

    if( hal.battery.critical() ) {
    // this call will never return
    hal.activity.sleepForever(hal);
    }

eingebaut. Funktioniert auch soweit. Frage mich nur gerade selber, ob das sinnig, bzw. nötig ist.
Bestenfalls liefert der Stepup einfach nicht mehr, das ist der Fall wenn VIN unter 0,8V abfällt.

Gibt es da ein "Für" und "Wider"?

Für Trockenbatterien sicher kein Problem, eher sogar effizient, da alles rauszuholen. Mit meinen Eneloops habe ich schon manchmal Probleme beim Laden gehabt wenn die Zellenspannung so tief abfiel. Das würde ja aber auch passieren, wenn durch "hal.activity.sleepForever(hal);" der Reset angezogen wird und der Ruhestrom auf (eben gemessen) >2mA ansteigt.

Für mich sieht es aktuell so aus. Trockenbatterien leerlutschen, bei Akkus auf die Low-Batt Meldung reagieren.

[TomMajor]

Aus meiner Sicht ein weites Feld, das Handling/die Strategie für fast leere Batterien bei HM Geräten.
Kennst du meine BI Betrachtungen?
https://github.com/TomMajor/SmartHome/t ... Protection