Fehler im Modul HMS?

Begonnen von chris1284, 10 Dezember 2017, 18:46:25

Vorheriges Thema - Nächstes Thema

chris1284

Moin,

ich habe den einen mapleCUL im Lacrosse Mode laufen und an einem Sensor die Batterie gewechselt.
Ich habe dann gewartet bis das neue Device angelegt wurde, das alte gelöscht und dann dem neue den alten Namen gegeben.Es wird nun stet sein neues Device angelegt obwohl die Definitinen gleich sind. Liegt dies an dem Bat replaces reading? Muss ich nur warten und später umbenennen?

ZitatInternals:
   CFGFN     
   CODE       430a
   DEF        430a
   IODev      mapleCUL433
   LASTInputDev mapleCUL868
   MSGCNT     55
   NAME       HMS100T_430a
   NR         256
   STATE      T: 0.8  Bat: replaced
   TYPE       HMS
   mapleCUL868_MSGCNT 55
   mapleCUL868_RAWMSG 810e04xx0511a001430a000041080000
   mapleCUL868_RSSI -74.5
   mapleCUL868_TIME 2017-12-10 18:46:39
   READINGS:
     2017-12-10 18:46:39   battery         replaced
     2017-12-10 18:46:39   state           T: 0.8  Bat: replaced
     2017-12-10 18:46:39   temperature     0.8
     2017-12-10 18:46:39   type            HMS100T
Attributes:
   DbLogExclude .*
   IODev      mapleCUL433
   room       HMS


chris1284

EDIT: fhem / das Modul hat es gerade gerafft das es sich um den selben Sensor handelt, merkwürdig

rudolfkoenig

Genau kann ich das Problem noch nicht erklaeren, vmtl. fehlt noch etwas in der Beschreibung.

Das HMS Modul pflegt einen internen Hash, um die Suche nach dem FHEM-Geraet anhand der Hardware-ID effizient durchfuehren zu koennen. Beim Loeschen eines Geraetes wird dieser Eintrag entfernt, und falls kein Eintrag gefunden wird, dann ein neues FHEM-Geraet via autocreate angelegt. Beim Batteriewechsel wird immer(?) ein neuer Code vergeben, d.h. das erzeugt immer ein neues FHEM-Geraet. Es sei denn, man verwendet die "Wildcard" HMS-Ids (1000+x, siehe Doku), damit kann man aber nur ein HMS-Geraete-Typ pro FHEM-Installation betreiben.

Moegliche Loesungen:
- Wildcard-ID
- Nach dem automatischen Anlegen des Geraetes Code-Neu merken, Neu entfernen, und mit modify Code-Neu im Altgeraet setzen. Modify ist hier gleich define, und pflegt den Modul-internen Hash.

Ralph

Zitat von: rudolfkoenig am 11 Dezember 2017, 09:47:11
... Beim Batteriewechsel wird immer(?) ein neuer Code vergeben, d.h. das erzeugt immer ein neues FHEM-Geraet. Es sei denn, man verwendet die "Wildcard" HMS-Ids (1000+x, siehe Doku)...

Moin, eben dies beobachte ich auch bei mehreren Rauchmeldern RM100-2.
ich benutze die Wildcard-ID 1003, alle melden sich regelmäßig darunte, aber mit unterschiedlichen Exact-IDs, die benutze ich zum Aufsplitten der Protokolle in verschiedene LOGs.

Seltsam ist, dass die Echt-Alarm-Meldungen nicht über die Wildcard-ID, sondern über eine FHT-Meldung kommen. Deren ID ist die hexadezimale Mäuseklaviereinstellund mit einem dd vorne dran (dd0a h).
Der FHT wird automatisch beim ersten Alarm ( als Thermo ) angelegt und geistert dann so herum.
In dessen Meldung ist der STATE mit 3 Fragezeichen, das Reg-Val sonstiges_80 ist 1 , wenn der Alarm da ist, sonst 0 , es kommt allerdings immer etwas verzögert um ca. 10 Sekunden.
Ich werde dann eben doppelt aus,
Die Echt-Alarme per FHT mit Meldung aufs Handy und die Protokolle in Datei-LOGs zur nachträglichen Funktionskontrolle.

Irritierend ist das aber schon. Hat auch eine Weile gedauert, bis ich kapierte, wie es geht. :-)
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen