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
EDIT: fhem / das Modul hat es gerade gerafft das es sich um den selben Sensor handelt, merkwürdig
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.
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. :-)