Autor Thema: Batteriestatus und Speicherung des letzten Wechsel  (Gelesen 18862 mal)

Offline _fhemuser_

  • New Member
  • *
  • Beiträge: 31
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #30 am: 22 Januar 2018, 10:36:58 »
Ich bin gerade auf diesen thread gestossen und finde die Idee dahinter sehr gut, aber in den letzten Beitägen versucht ihr über die groupid einen Zwischenstatus zu speichern.
Das funktioniert nicht wenn der MAX-Cube und Fensterkontakte verwendet werden. Über die groupid werden die Fensterkontakte den passenden Heizungsreglern zugeordnet.

Readings Fensterkontakt hinzugefügt
MAXLAN_error 0
MAXLAN_errorInCommand
MAXLAN_initialized 1
MAXLAN_isAnswer 0
MAXLAN_valid 100
RSSI -75
battery ok
firmware 1.4
groupid 2
onoff 0
state closed
testresult 15
« Letzte Änderung: 22 Januar 2018, 11:28:19 von _fhemuser_ »
fhem in der aktuellsten Version auf:
Raspberry 2 mit SD-Karte | fhem2fhem
Raspberry 3 mit externer HDD | MAXCube | NanoCul433 | NanoCul868 | DbLog

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2392
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #31 am: 22 Januar 2018, 11:27:49 »
Wieso? Wenn eine GroupID vergeben wurde wird diese auf 0 gesetzt nach einem Tausch. Wenn keine vergeben wurde, dann muss der Nutzer nur eine fiktive einmalig vergeben um auf diese zu triggern, wenn sie wieder 0 ist. Nach dem Tausch wird dann entweder die alte wieder gesetzt, oder die fiktive.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1905
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #32 am: 22 Januar 2018, 11:29:36 »
ist doch schön dann gibt es ein Reading groupid - genau darum geht es erst einmal.
Die Frage ist allerdings wie verhält sich da das Reading bei Batt Wechsel ?
Ich kann das leider nicht nachstellen da ich schon ewig keine Original MAX Software mehr betreibe.
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Offline _fhemuser_

  • New Member
  • *
  • Beiträge: 31
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #33 am: 22 Januar 2018, 11:30:42 »
Die IDs werden im Cube passend zu den Geräten gespeichert und haben sich bei mir bisher beim Batteriwechsel in den Thermostaten nicht verändert. Bei den Fensterkontakten habe ich bislang noch keine Batterien getauscht.

Ich werde mal testweise alte Batterien in einen Fensterkontakt und in einen Thermosaten einbauen und testen.
« Letzte Änderung: 22 Januar 2018, 11:32:55 von _fhemuser_ »
fhem in der aktuellsten Version auf:
Raspberry 2 mit SD-Karte | fhem2fhem
Raspberry 3 mit externer HDD | MAXCube | NanoCul433 | NanoCul868 | DbLog

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1905
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #34 am: 22 Januar 2018, 11:32:50 »
OK, dann fällt auch das zum Thema Bat Wechsel Erkennung raus. D.h. es bleibt dann wohl wirklich nur die Alternative des Nachschauens auf eine lang anstehende Meldung.
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Offline _fhemuser_

  • New Member
  • *
  • Beiträge: 31
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #35 am: 22 Januar 2018, 12:37:58 »
Ich habe gerade mal bei einem Thermostaten eine leere und eine volle Batterie eingesetzt. Nach den Lernfahrten waren alle vorherigen Einstellungen bezüglich des Wochenprofils und der Kopplung mit dem Fensterkontakt wieder vorhanden.
Die Batterieleerwarnung wird in Kürze wohl detektiert.

Dann habe ich bei einem Fensterkontakt die Batterien entfernt und an ein regelbares Netzteil angeschlossen.
Auch hier bleibt die Zuordnung erhalten.
Bei Batteriespannungen unterhalb von 2,4 Volt wird nach längerer Zeit oder direkt beim Auslösen des Kontakts der Batterieleerstatus übermittelt. Bei Spanungen von ca 2 Volt funktioniert der Fensterkontakt garnicht mehr.
Wenn die Spannung wieder ansteigt, erlischt die Batteriewarnung. Eine zuerlässige Erkennung ob die Batterie getauscht wurde ist somit nicht möglich. Beim MAX!System werden leider keine Zwichenwerte übermittelt, aus denen man eine erneuerte Batterie ableiten könnte.
Auch die anderen Readings ändern sich nicht.

Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?
fhem in der aktuellsten Version auf:
Raspberry 2 mit SD-Karte | fhem2fhem
Raspberry 3 mit externer HDD | MAXCube | NanoCul433 | NanoCul868 | DbLog

Offline Mitch

  • Hero Member
  • *****
  • Beiträge: 2076
  • Give more - Expect less
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #36 am: 22 Januar 2018, 13:01:21 »
Grundsätzlich sehr nett, aber ich habe noch einige Probleme damit.

1. ich habe einige Devices, die zwar ein Reading battery haben, aber nicht mit einbezogen werden sollen
2. habe ich viel zu viele Logeinträge
FHEM auf Intel NUC mit Ubuntu Server, CUNOv2 - FHZ1300 - FritzDECT - 2x HM-LAN - Z-Wave - SIGNALduino@433 - SIGNALduino@868 - SignalESP@868 - miniCUL - DuofernStick - ESP Bridge - MQTT - HUE - MiLight - Sonos - Homebridge - Alexa - Nest Protect

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3704
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #37 am: 22 Januar 2018, 13:05:19 »
Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?

Da letztendlich "nur" ein "setreading BattWechselDummy Batterie gewechselt" ausgeführt wird lässt sich das machen...

Z.B. per webCmd etc.

Gruß, Joachim
FHEM 5.8 PI3: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf, ...
FHEM 5.8 PI2: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM 5.8 PI3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2392
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #38 am: 22 Januar 2018, 14:39:46 »
Hört sich an, als ob aus dem Codeteil eher ein Modul werden muss um allen Ansprüchen gerecht zu werden :D
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Mumpitz

  • Full Member
  • ***
  • Beiträge: 219
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #39 am: 22 Januar 2018, 19:57:15 »
hallo zusammen

ich wollte mir soeben das Script holen und es einmalig ausführen. Nun habe ich jedoch festgestellt, dass im git ein Modul 99_batterycheck.pm vorhanden ist. Leider finde ich jedoch keine entsprechende Doku wie man das Modul definiert...

Jemand eine Idee?

gruess

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3704
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #40 am: 22 Januar 2018, 20:17:41 »
Einfach nach /opt/fhem/FHEM kopieren.

Ist quasi eine weitere myUtils.pm

Kurz da nur Handy...

Gruß, Joachim
FHEM 5.8 PI3: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf, ...
FHEM 5.8 PI2: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM 5.8 PI3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Mumpitz

  • Full Member
  • ***
  • Beiträge: 219
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #41 am: 22 Januar 2018, 20:25:25 »
Einfach nach /opt/fhem/FHEM kopieren.

Ist quasi eine weitere myUtils.pm

Kurz da nur Handy...

Gruß, Joachim

habe ich gemacht, und dann?

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3704
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #42 am: 22 Januar 2018, 20:31:54 »
Siehe erster Post im Thread: z.B. Notify anlegen und Sub aufrufen lassen und zunächst die Initialisierungs-Sub manuell ausführen (sofern sich nix geändert hat)...

So lang ist der Thread ja noch nicht da kann man sich schon noch "durchquälen" ;)

Achja: reload 99_batterycheck.pm oder Neustart von fhem nicht vergessen...

Gruß, Joachim
« Letzte Änderung: 22 Januar 2018, 20:33:29 von MadMax-FHEM »
FHEM 5.8 PI3: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf, ...
FHEM 5.8 PI2: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM 5.8 PI3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2392
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #43 am: 22 Januar 2018, 20:40:59 »
Alternativ kannst du den Inhalt der Datei auch einfach in deine vorhanden 99_myUtils einfügen. Zum starten musst du nur die Funktion BatteryStart() ausführen. Das geht indem du in der Commandozeile { BatteryStart()} eingibst und Enter drückst. Vorher die entsprechenden Variablen anpassen.

Steht aber auch alles im ersten Post, außer wie man die Funktion aufruft ;)
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2392
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #44 am: 22 Januar 2018, 20:53:45 »
Wenn ich mir die Diskussion von heute ansehe, dann ist es bei MAX! wohl wirklich so, dass wir uns nur auf die Zeit einstellen müssen. Das ist ziemlich doof, gerade solange es sich um einen Code und kein Modul handelt. Mal sehen, ob ich das hinbekomme. Ist somit auch aufwendiger zu Programmieren. Versprecht euch nicht zu früh etwas, habe noch einen Test nächste Woche vor mir und bis dahin wenig Zeit zum programmieren. Mal sehen.

1. ich habe einige Devices, die zwar ein Reading battery haben, aber nicht mit einbezogen werden sollen
Aktuell werden nur HM Device, MAX! (nicht richtig), XiaomiFlower und Z-Wave unterstützt. Da es sich aktuell noch um einen Code und kein Modul handelt, wirst du die entsprechenden Device selbst "deaktvieren" müssen im Code. Nur mal Interessehalber, welche wären das und wieso?

Zitat
2. habe ich viel zu viele Logeinträge
Welche hast du denn? Aktuell kann es nur folgende geben:
# ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

Und dieser kommt, wenn deine Device mit HM / ZWave / MAX heißen. Dh wenn du sie nicht umbenannt hast. Ist das der Fall?

Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?
Ja eigentlich schon, wäre aber auch wieder ein eigener Code und spricht auch für ein Modul.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System