HM-RC-2-PBU-FM liefert unlogisches battery-Reading

Begonnen von betateilchen, 05 Dezember 2017, 17:32:10

Vorheriges Thema - Nächstes Thema

betateilchen

Warum liefert der HM-RC-2-PBU-FM ein battery-Reading, obwohl er Unterputz direkt an der Netzspannung angeschlossen ist?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

loescher

Meinst du das LOWBAT im Kanal 0?
Das liefern bei mir auch z.B. die HM-LC-Sw1-Pl, obwohl die ja in der Steckdose stecken.
Ich dachte bisher, dass das alle HM Geräte liefern, quasi als "Norm".

LG,
Stephan.

Pfriemler

Es gibt keinen Kanal 0.
Ich habe mehrere HM-LC-SW1-PL2, die haben kein battery-Reading. Und was bitte soll LOWBAT sein?

Bei der fraglichen HM-RC-2-PBU-FM ist die Frage gerechtfertigt, wird von FHEM wie die bauähnliche (anschlusslose, weil batteriebetriebene) HM-PB-2-FM behandelt. Die Frage ist, ob das schon in den XMLs von eQ3 steckt oder in der HMConfig.pm eine fälschliche Alias-Zuordung stattfindet. Muss mir das nochmal ansehen, Martin ist für Vorschläge offen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

loescher

Das LOWBAT im HM-LC-SW1-PL2 gibts also nur bei mir... Hmm... Komisch.
Hier mal ein List des Geräts:


Internals:
   DEF        OEQ0816247
   IODev      d_ccu
   NAME       LichterGartenNord
   NR         69
   STATE      0
   TYPE       HMCCUDEV
   ccuaddr    OEQ0816247
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    HM-LC-Sw1-Pl-DN-R1 OEQ0816247
   ccutype    HM-LC-Sw1-Pl-DN-R1
   channels   2
   firmware   2.6
   statevals  devstate|on|off
   Readings:
     2017-11-29 22:16:42   0.AES_KEY       0
     2017-11-29 22:16:42   0.CONFIG_PENDING false
     2017-11-29 22:16:42   0.DEVICE_IN_BOOTLOADER false
     2017-11-29 22:16:42   0.DUTYCYCLE     false
     2017-11-27 21:07:20   0.LOWBAT        ok
     2017-11-29 22:16:42   0.RSSI_DEVICE   196
     2017-11-29 22:16:42   0.RSSI_PEER     60
     2017-12-11 07:45:04   0.STICKY_UNREACH 1
     2017-12-11 16:09:27   0.UNREACH       0
     2017-11-29 22:16:42   0.UPDATE_PENDING false
     2017-11-29 22:16:42   1.INHIBIT       false
     2017-12-14 07:45:08   1.STATE         0
     2017-12-14 07:45:08   1.WORKING       0
     2017-11-29 22:16:42   battery         ok
     2017-12-14 07:45:08   hmstate         0
     2017-12-14 07:45:08   state           0
   Hmccu:
     Dp:
       0.aes_key:
         VAL        0
       0.config_pending:
         VAL        false
       0.device_in_bootloader:
         VAL        false
       0.dutycycle:
         VAL        false
       0.lowbat:
         VAL        false
       0.rssi_device:
         VAL        196
       0.rssi_peer:
         VAL        60
       0.sticky_unreach:
         VAL        1
       0.unreach:
         VAL        0
       0.update_pending:
         VAL        false
       1.inhibit:
         VAL        false
       1.state:
         VAL        0
       1.working:
         VAL        0
Attributes:
   IODev      d_ccu
   Weihnachten LichterGarten
   group      WeihnachtsBeleuchtungAussen
   room       Weihnachten
   statedatapoint 1.STATE
   statevals  on:true,off:false
   userattr   Weihnachten Weihnachten_map structexclude


LG,
Stephan.

frank

mit deimem hmccu device bist du auf der falschen party.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html