Batteriestatus und Speicherung des letzten Wechsel

Begonnen von Amenophis86, 12 Januar 2018, 19:23:20

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

#450
Herzlich Willkommen !

Und auch hier gilt der Tipp: Einfach mal in die Datei MAINTAINER.txt schauen, dort kann man sehr gut sehen, welcher Code gewartet und weiter entwickelt wird.

pah

_fhemuser_

[OT]
@pah

Egal ob git, svn oder irgendeine andere Lösung zur Bearbeitung des Codes genutzt wird, es setzt voraus, dass es eine Benutzerverwaltung gibt die auch gepflegt werden muss. Das ist für diesen Teil nicht zu bewerkstelligen.

Zitat von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30
ZitatAber auch da sollte einer über den Code sehen bevor die Änderungen zusammen geführt werden.
Das ist absoluter Unsinn. Das zentrale Programm fhem.pl wird von Rudi König gepflegt, wichtige Design-Entscheidungen von ihm und einer kleinen Gruppe getroffen. Aber für die allermeisten Module ist nur der jeweilige Maintainer zuständig. Und wenn sie nicht funktionieren, werden sie eben nicht verwendet.
Bei den Modulen ist der Maintainer derjenige der den Code überprüft vor der Veröffentlchung. Also sieht einer über den geänderten Code. Ich sprach nicht davon, dass der ganze Code immer komplett geprüft werden muss.

Zitat von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30
ZitatAber selbt in Programmierteams arbeiten nicht mehrere Personen im gleichen Bereich an dem Code, was hier aber durchaus passiert.
Das ist doppelt unkorrekt. Selbstverständlich arbeiten in professionellen Teams durchaus verschiedene Entwickler an demselben Code. Hier in FHEM ist das wegen der verteilten Verantwortlichkeiten allerdings nicht die Regel.
Ja die Entwickler arbeiten am selben Code, aber nicht in der gleichen Struktur, im gleichen Absatz, im selben Block, an einer sub, oder wie man das auch immer nennen möchte. Hier auf FHEM bezogen am selben Modul.
So nach dem Motto: Viele Köche verderben den Brei.

[So genug OT]



fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Prof. Dr. Peter Henning

#452
ZitatBenutzerverwaltung gibt die auch gepflegt werden muss
Die gibt es auch für den gewarteten Code.

ZitatBei den Modulen ist der Maintainer derjenige der den Code überprüft vor der Veröffentlchung. Also sieht einer über den geänderten Code.
Ich schreib es ja ungern: Das ist immer noch falsch. Denn nur der Maintainer ändert den Code und checkt ihn ein. Gerne natürlich nach Vorschlägen anderer Nutzer - aber in der Regel nach sorgfältigen Tests, die nicht aus "drüber sehen" bestehen.

Zitatnicht in der gleichen Struktur,.... Hier auf FHEM bezogen am selben Modul.
Aber doch.

Abgesehen davon, dass dies nicht OT ist, sondern man offensichtlich überzogene Anforderungen in diesem Bereich des Forums korrigieren muss, steht es jedem frei, sich nicht mehr dazu zu äußern.

pah

MadMax-FHEM

So, es gibt ne neue Version ;)

Ich habe ein paar Dinge (ja, erst mal sehr wenige/Kleinigstkeiten ;) :-\ ) glatt gezogen (und hoffentlich nichts "kaputt gezogen" 8) ) aber v.a. die Berechnung der Batterielebensdauer eingebaut, siehe: https://forum.fhem.de/index.php?topic=82637.msg1308213#msg1308213 und https://forum.fhem.de/index.php?topic=82637.msg1042493#msg1042493

Damit steht im dummy "BatterieLebensdauer" die Lebensdauer der Batterie in Wochen. Somit hat man einen Überblick (evtl. "ausgelagert" in eine readingsGroup) wie lange die Batterien pro Device denn so halten/gehalten haben. Hilft evtl. auch bei einer Abschätzung, wann es denn wieder so weit sein könnte und ob evtl. die einen Batterie-Typen besser sind als die anderen oder ob beim Device in der Zeit mehr oder weniger "los war" o.ä.

Wer es nutzen möchte muss zusätzlich zum Einspielen der neuen Version entweder die Start-Routine noch mal anwerfen oder den dummy "BatterieLebensdauer" von Hand anlegen...

@TK67: es ist eine Mischung aus allem geworden ;)

Rudimentär getestet...

Bzgl. generellem Umbau überlege ich noch...
Zeit würde es werden...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

_fhemuser_

#454
Hier noch eine kleine Erweiterung damit im Status des BatterieStatus dummy auch die Geräteanzahl angezeigt wird und nicht die ???

attr BatterieStatus stateFormat anzahl
attr BatterieStatus userReadings anzahl {my $anz = grep( m/ */, ( keys %{$hash->{READINGS}} ));; return $anz - 1;;},
Kleiner Nachteil. In der Readingsgroup wird anzahl mit aufgeführt und versucht mit einem Batterieicon darzustellen.

Gruß
_fhemuser_
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

MadMax-FHEM

#455
:)

EDIT: musste erst ganz kurz überlegen, was der "smiley" am Ende bedeuten soll... Klar: 3 Fragezeichen... ;)

Wobei ich ja für die Anzeige readingsGroup nutze...

Die dummy sind bei mir nur "Hilfskonstrukte" ;)

Danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

TK67

Zitat von: MadMax-FHEM am 25 März 2024, 17:49:20@TK67: es ist eine Mischung aus allem geworden ;)

Thx Joachim,
ist eine sehr gute Mischung geworden, läuft alles bestens.  :)   


Gruß TK67
FHEM auf Raspberry Pi 3 Model B+

_fhemuser_

#457
Wie ich unter https://forum.fhem.de/index.php?msg=1308144 geschrieben hatte, wurden einige Sensoren mit 0% eingetragen aber keine Alarme versandt.

Nach langer Suche fand ich heraus, dass die MQTT Devices mit % Werten in battery eine falschen Weg einschlagen.

unter https://forum.fhem.de/index.php?msg=1308082 wurde bereits ungefähr in Zeile 100 der Eintrag erweitert.
Zitatif($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice")


der muss um MQTT_Device erweitert werden.
Zitatif($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice" && $TYPE ne "MQTT2_DEVICE")
für MQTT Device mit battery % gibt es einen eigenen Abschnitt ab Zeile 425

[edit]
Und bei Zeile 430 muss HUEDevice hinzu gefügt werden
Zitat##############################################
# MQTT2_DEVICE that have battery Reading showing percentage!
##############################################
  elsif($BatteryType[0] eq "battery"  && ($TYPE eq "MQTT2_DEVICE" || $TYPE eq "HUEDevice"))
[/edit]

Gruß
_fhemuser_

fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

MadMax-FHEM

Zitat von: _fhemuser_ am 27 März 2024, 13:25:24der muss um MQTT_Device erweitert werden.
Hab's eingebaut, Version hängt an.

Allerdings wie ihr merkt wird es (langsam) "unübersichtlich" und bei dem ein oder anderen gibt es dann Devices, die "sowohl als auch" haben und dann tauchen diese u.U. doppelt auf o.ä. (gibt es ja bereits, siehe: https://forum.fhem.de/index.php?topic=82637.msg1308143#msg1308143).

Aber ein Komplettumbau ist nicht ganz so schnell umgesetzt... :-\

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

_fhemuser_

@Joachim,

Vielleicht wäre ein etwas anderer Ansatz für die Filterung und die anschließende Auswertung und Anzeige interessant.

Ich hatte ja schon bei allen Geräten ein userReading angelegt in dem aus den vohandenen battery, battery_low, usw immer ein Prozentwert erstellt wird. Damit hat man eine identische Variable bei allen Geräten die immer die gleiche Wertigkeit hat.

Dann habe ich aus der Datei 99_Batterycheck.pm ab Zeile 70 bei denen die if Zweige starten, alles gelöscht und nur einen Zweig eingerichtet.

Damit wird die ganze Datei deutlich übersichtlicher.

Daraus folgt, dass in den if elseif Zweigen nur eine Zeile steht in der die Werte angeglichen werden und anschließend der Ausführungsteil abgearbeitet wird, und der Ausführungsteil nicht mehrfach vorhanden sein muss.

Im Anhang mal meine Version ohne if elseif Bedingungen.

Gruß
_fhemuser_
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

MadMax-FHEM

Ja, userReadings ist auch eine Möglichkeit...
Neben der mit Attribut.

Weil, ein Attribut wird es eh geben: BatteryTyp ;)
Und evtl. weitere "Einstellungen"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)