Batteriestatus und Speicherung des letzten Wechsel

kennymc.c · 02 Juni 2019, 14:11:23

Xiaomi Sensor


Internals:
   DEF        WSDCGQ01LM 0x00158d000215933c BK_Sensor
   FRIENDLYNAME BK_Sensor
   FUUID      5c5de5e9-f33f-ed56-1602-add78fd2ca5d81e4
   IODev      mqtt
   MODEL      WSDCGQ01LM
   NAME       BK_Sensor
   NOTIFYDEV  WSDCGQ01LM 0x00158d000215933c BK_Sensor
   NR         140
   SID        0x00158d000215933c
   STATE      Temperatur: 30.5 °C | Luftfeuchtigkeit: 38 %
   TYPE       XiaomiMQTTDevice
   Helper:
     DBLOG:
       humidity:
         DBLogging:
           TIME       1559476864.28189
           VALUE      38
       last_seen:
         DBLogging:
           TIME       1559476864.28189
           VALUE      1559476864181
       linkquality:
         DBLogging:
           TIME       1559476864.28189
           VALUE      81
       temperature:
         DBLogging:
           TIME       1559476864.21724
           VALUE      30.5
   READINGS:
     2019-06-02 14:01:04   battery         ok
     2019-06-02 14:01:04   battery_level   100
     2019-06-02 14:01:04   humidity        38
     2019-06-02 14:01:04   last_seen       1559476864181
     2019-06-02 14:01:04   linkquality     81
     2019-06-02 14:01:04   temperature     30.5
     2019-06-02 14:01:04   transmission-state incoming publish received
     2019-06-02 14:01:04   voltage         3025
   message_ids:
   subscribe:
     zigbee2mqtt/BK_Sensor
     xiaomi/0x00158d000215933c/#
   subscribeExpr:
     ^zigbee2mqtt\/BK_Sensor$
     ^xiaomi\/0x00158d000215933c.*$
   subscribeQos:
     xiaomi/0x00158d000215933c/# 0
     zigbee2mqtt/BK_Sensor 0
Attributes:
   DbLogExclude .*
   DbLogInclude humidity,temperature,linkquality,battery_level,last_seen
   IODev      mqtt
   alias      Klima Balkon
   event-on-change-reading humidity,temperature:0.2,linkquality,battery_level,last_seen
   group      KlimaXiaomi
   homebridgeMapping history:size=1024 StatusLowBattery=BK_Sensor:battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW batteryVoltage=BK_Sensor:voltage,factor=1000,name=Voltage,format=FLOAT history:size=1024
   mqttPublish temperature:topic={"EPSD/Temp/BK"} humidity:topic={"EPSD/Hum/BK"} temperature:retain=1 humidity:retain=1
   room       Balkon,Favoriten,Homebridge,ZigBee
   stateFormat Temperatur: temperature °C | Luftfeuchtigkeit: humidity %
   userattr   EPSDAlias:textField-long EPSDDefaults:textField-long EPSDDisable:both,incoming,outgoing EPSDPublish:textField-long EPSDSubscribe:textField-long mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long

Einer der 2 HM Fenstersensor mit Ausrufungszeichen scheint jetzt den korrekten Batteriestatus zu zeigen. Bei einem anderen ist das Symbol aber noch vorhanden

Code Auswählen


Internals:
   DEF        2BD7F1
   FUUID      5c5de5ee-f33f-ed56-b73c-91731d343b5b22a6
   IODev      hmusb
   NAME       SZ_Fenster
   NOTIFYDEV  global
   NR         574
   NTFY_ORDER 50-SZ_Fenster
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   peerList   SZ_Thermostat_WindowRec,
   READINGS:
     2019-06-02 05:09:10   Activity        unknown
     2018-09-02 15:42:41   D-firmware      2.4
     2018-09-02 15:42:41   D-serialNr      LEQ0566785
     2019-05-30 12:55:37   battery         ok
     2019-05-30 12:55:37   contact         closed (to vccu)
     2019-06-02 05:09:12   peerList        SZ_Thermostat_WindowRec,
     2019-05-30 12:55:37   state           closed
     2019-05-30 12:55:37   trigger_cnt     24
   helper:
     HM_CMDNR   35
     mId        0030
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     20
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2BD7F1,00,00,00
       rxt        2
       vccu       vccu
       p:
         2BD7F1
         00
         00
         00
       prefIO:
         hmusb
     mRssi:
       mNo        
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   DbLogExclude .*
   DbLogInclude state,battery,trigger_cnt
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   028:00
   actStatus  unknown
   alias      Fenster Schlafzimmer
   autoReadReg 5_readMissing
   devStateIcon closed:fts_window_1w@green open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow
   expert     2_full
   firmware   2.4
   genericDeviceType ContactSensor
   group      HomematicFenstersensor
   homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW history:size=1024 ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
   model      HM-SEC-RHS
   mqttPublish state:topic={"EPSD/Con/SZ"} state:retain=1
   peerIDs    00000000,2D30D803,
   room       Favoriten,HomeMatic,Homebridge,Schlafzimmer
   serialNr   LEQ0566785
   subType    threeStateSensor

Ich vermute, das battery Reading muss sich nach dem Start des Bots einmal aktualisieren, damit es richtig erkannt wird? Das würde erklären, warum über Nacht eins der Devices jetzt keinen Fehler mehr zeigt.

Amenophis86 · 02 Juni 2019, 14:37:54

Der Typ XiaomiMQTTDevice wird noch nicht unterstützt. Du müsstest dir einen Block mit batteryLevel suchen, kopieren und anpassen.

Zu HomeMatic, normal wird zu Beginn einmal alles abgefragt. Ein ! Kann es geben, wenn der ActionDetector das Gerät zB als tot meldet. Schwer zu sagen warum es bei dir so war.

kennymc.c · 03 Juni 2019, 18:07:35

Ich hab das Skript entsprechend angepasst aber nach einem reload und einem erneutem {BatteryStart()} tauchen die Devices immer noch nicht auf. Ich hab auch schon versucht alle angelegten dummys und notifys zu löschen.

Code Auswählen


   ##############################################
  # XiaomiMQTT Devices
  #############################################
 elsif($BatteryType[0] eq "battery_level"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
 {
   $ActBatLevel = ReadingsNum($Device, "battery_level", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }

Die HM Devices werden jetzt alle korrekt angezeigt. Vermutlich liegt es am ActionDetector, der bei mir irgendwie seltsame Werte anzeigt hat.

MadMax-FHEM · 03 Juni 2019, 18:25:36

Füge doch am Anfang mal eine Logausgabe ein, um zu sehen, ob der Zweig überhaupt "getroffen" wird:

Code Auswählen


   ##############################################
  # XiaomiMQTT Devices
  #############################################
 elsif($BatteryType[0] eq "battery_level"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
 {

  Log3(undef, 3, "Battery for XiaomiMQTTDevice");

   $ActBatLevel = ReadingsNum($Device, "battery_level", "0");

   if($ActBatLevel > 75)

Wenn die Ausgabe nicht kommt, ist was an dieser "Abfrage" schief oder eine zuvor macht etwas "kaputt"...

~~Wie sieht das split bzgl. BatteryType aus!?~~

EDIT: hab grad geschaut, das sollte passen...

Und evtl. mal (glaube aber nicht, dass es was macht) bei der ReadingsNum-Abfrage eine 0 statt einer "0", weil ReadingsNum immer eine Zahl liefert...
...aber ich denke Perl wandelt das eh passend um

EDIT: bzw. mal ganz an den Anfang eine Logausgabe: Log3(undef, 3, "Battery-Function Device: $Device Event: $Event");

Edit2: und es kommen nat. nur Werte bzw. werden "berechnet" und in den Dummy geschrieben, wenn auch Events mit battery_level kommen! Wie oft wird denn aktualisiert!? Wenn nicht, dann einfach mal zu Test: setreading BK_Sensor battery_level 99

Gruß, Joachim

kennymc.c · 03 Juni 2019, 21:12:59

Zitat von: MadMax-FHEM am 03 Juni 2019, 18:25:36Edit2: und es kommen nat. nur Werte bzw. werden "berechnet" und in den Dummy geschrieben, wenn auch Events mit battery_level kommen! Wie oft wird denn aktualisiert!? Wenn nicht, dann einfach mal zu Test: setreading BK_Sensor battery_level 99

Gruß, Joachim

Daran lag es wohl. Da die HM Devices ja direkt nach dem Einrichten ohne Event auftauchen, dachte ich, dass das bei den Xiaomi genauso ist. Da die Sensoren aber nur sehr selten ihren Status updaten, waren sie wohl nicht direkt mit in der ReadingsGroup. Ein manuelles ändern des Reading hat aber geholfen.

MadMax-FHEM · 03 Juni 2019, 21:32:32

Na dann...

Kann der Code ja übernommen werden

Gruß und viel Spaß, Joachim

Amenophis86 · 04 Juni 2019, 09:06:04

freut mich, dass es geht. Allerdings eine Frage dazu, welchen Branche hast du genutzt? no-BatteryStatusBot oder Master? Es sieht mir sehr nach Master aus, da die Variable BatteryStatusBot in deinem Code vorkommt. Ich würde dir empfehlen eher no-BatteryStatusBot zu nehmen. In diesem Fall hätten deine Geräte Xiaomi Geräte eigentlich auch erkannt werden müssen auf Grund des Zweiges für alle nicht direkt definierten Geräte, fällt mir aber eben erst ein. Weiterhin ist der Zweig auch wesentlich weiter entwickelt, als der Master Zweig.

kennymc.c · 04 Juni 2019, 18:55:30

Ich hab den master Branch genutzt. Mit dem no-BatteryStatusBot geht es auch direkt ohne Bearbeitung des Skripts. Um die Prozentanzeige bei den Xiaomis direkt zu nutzen müsste ich es aber nochmal anpassen, oder?

Amenophis86 · 04 Juni 2019, 20:11:39

Normal müsstest du bei diesem nichts mehr machen oder wird etwas fehlerhaft angezeigt? Werde aus deinem Post nicht ganz schlau.

kennymc.c · 04 Juni 2019, 21:20:27

Ich hab es so verstanden, dass wenn es kein Reading mit BatterLevel gibt (bei den Xiaomis heißt es ja battery_level) hängt der Batteriestatus nur vom ok / low Wert aus dem battery Reading ab und ist dadurch ungenauer.

Amenophis86 · 05 Juni 2019, 10:36:31

Ah das ist korrekt. Ich hatte nicht gesehen, dass das Reading battery_level heißt. Da könntest du den Modulauthoren auch mal anschreiben und darauf hinweisen, dass man sich auf einen Standard geeinigt hat. Mehr dazu findet man hier: Topic und Wiki.

Also ja, dann müsstest du im anderen Zweig auch wieder Anpassungen vornehmen. Wenn es bei dir jedoch jetzt läuft ist die Frage, ob du die Arbeit auf dich nehmen willst.

kennymc.c · 05 Juni 2019, 19:44:14

Ich hab im Github Repository des Moduls mal ein entsprechendes Issue erstellt. Allerdings übernimmt das Modul im Prinzip nur die Namen aus der ZigBee2MQTT Bridge, die mit Fhem aber nichts zu tun hat und auch unabhängig davon läuft.

Amenophis86 · 05 Juni 2019, 20:13:32

Dann wirste schwierigkeiten bekommen, dass die das anpassen. Alternativ kannst du dir ein UserReading anlegen, welches den Wert von battery_level übernimmt und batterLevel heißt

kennymc.c · 06 Juni 2019, 15:39:48

Das Modul selbst gibt es ja nur für Fhem also könnte das schon etwas bringen. Ein UserReading wäre zwar eine Lösung, eventuell wäre es für die Zukunft aber besser, wenn man die zu erkennenden Readings für den Status oder Prozentangabe für alle Devices einfach selber z.B. über ein Attribut in einem Dummy festlegen könnte.

Madstar2409 · 21 August 2019, 11:22:26

Hallo,

ich bin relativ frisch mit FHEM unterwegs. Ich bin vor einiger Zeit auf das Modul gestoßen und konnte es auch gut nutzen bis heute. Ich habe nämlich meine Fensterkontakte von MAX auf XIAOMI gewechselt und diese per MQTT2_DEVICE eingebunden. Habe auch den Batteriebot neu gestartet aber er erkennt leider die Battery Readings nicht.

Hier mal die Readings einer der Fensterkontakte:

Readings
associatedWith   MQTT2_MQTT2Broker   19.08.2019 09:45
battery     86     21.08.2019 11:07
contact     true     21.08.2019 11:07
linkquality     99     21.08.2019 11:07
voltage     2975     21.08.2019 11:07

Ich habe das Modul auch schon mit den folgenden erweitert:

Code Auswählen

 ##############################################
  # MQTT2_DEVICE Devices
  ##############################################
 elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
 {
   if(ReadingsVal($Device, "battery", "na") eq "low")
   {
     $ActBatLevel = 0;
   }
   else
   {
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
   }

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
 }

Leider ohne Erfolg. Hat jemand eine Idee?