Hilfe erbeten: zwei Türmelder peeren sich automatisch

[curt]

Wie sieht denn ein HW-reset bei Dir aus?

So, wie mir das in diesem Thread erklärt wurde: "delete Devicename", save. Dann 2x5sec Knöpfchen. Dann
set VCCU hmPairForSec 600, dann in der Zeit Knöpfchen kurz drücken. Dann getConfig, dann Knöpfchen kurz drücken. save.

[curt]

Nachtrag:
Und daran anschließend waren die Register (RegL_00.,RegL_01.) wirklich aller anderen Kontaktmelder weg. Und das kann man jetzt wirklich nicht mehr mit "curt ist zu doof um was zu speichern" begründen.

Diese Register von weiteren sieben Meldern waren monatelang da.

[pc1246]

@curt
Ich denke, wir glauben Dir alle, was Du schreibst. Was mich, persoenlich, etwas wundert, dass Du alles immer noch einmal nachfragst. Speziell zu deinem Reset, 2 mal 5Sec Knoepfchen druecken, kann jetzt vieles bedeuten! Das haettest Du als Aufforderung auch hinterfragt! Denn das Geblinke muss schon auch stimmen!
Beim getConfig gehe ich uebrigens mit den Anderen nicht konform, da ich eine andere Vorgehensweise nutze, die mich bisher immer sicher zum Ziel gebracht hat. Ich setze das getConfig ab, druecke das Knoepfchen, warte das das Blinken aufhoert, und falls es noch cmdsPending gibt, dann druecke ich das Knoepfchen erneut. Beim Thermostaten z.B. muss man das bis zu 3mal machen.
Was ich mir auch angewoehnt habe, ist nicht nur den save-Button auf der Oberflaeche zu druecken, sondern ab und an auch mal ein save in die Kommandozeile einzugeben.
Jetzt aber zurueck zum eigentlichen Thema, wie ist denn jetzt der Stand bei Dir?
Gruss Christoph

[Pfriemler]

Was ich mir auch angewoehnt habe, ist nicht nur den save-Button auf der Oberflaeche zu druecken, sondern ab und an auch mal ein save in die Kommandozeile einzugeben.

Welchen Unterschied macht das? Für mich passiert mit "Save config" aus der Navi-Leiste links und "save" in der Eingabezeile irgendwie das Gleiche.
Was sich gelegentlich mal empfiehlt, ist ein "set <hminfo> saveConfig".

Ich bin trotzdem auch völlig ratlos, warum gelesene Register wieder so schnell verschwinden.

curt, hast Du Zugriff auf die Dateien (Samba oder FTP) und kannst Du mal schauen, ob wirklich ein fhem.save geschrieben wird (bei mir ist das im im Log-Verzeichnis).
sollte so ähnlich aussehen (alle Werte aller Geräte sind alphabetisch sortiert)

Code Auswählen Erweitern

#Fri Feb 15 19:22:37 2019
setstate 1BattAkt2 off
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtDlyOff geLo
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtDlyOn geLo
setstate 1BattAkt2 2017-11-30 22:02:25 .R-HM_PB4Dis1_Btn_20-lgCtOff geLo
...


[curt]

Was mich, persoenlich, etwas wundert, dass Du alles immer noch einmal nachfragst.

Solche Probleme habe ich nicht zum ersten Mal. Von daher halte ich es für klug, das gemeinsam mit Fachleuten durchzugehen.

Übrigens hatte ich etwas vergessen: Einige Melder sind aus zweiter Hand, waren in magenta Telekom-Verpackung. Gleicher Typ, gleiches Aussehen.

Jetzt aber zurueck zum eigentlichen Thema, wie ist denn jetzt der Stand bei Dir?

Noch kein getConfig bei den beidem ausstehenden. Ich wollte zunächst Meinungen abwarten. Und heute abend habe ich keine Lust, mich ggf. schwarz zu ärgern.

curt, hast Du Zugriff auf die Dateien (Samba oder FTP) und kannst Du mal schauen, ob wirklich ein fhem.save geschrieben wird (bei mir ist das im im Log-Verzeichnis).

Zugang via ssh. - Ich drücke auf "Save config" im Browser, dann wird fhem.save in /opt/fhem/log mit korrektem Zeitstempel geschrieben. Einträge wirken auch aktuell.

Was bewirkt "set <hminfo> saveConfig" genau?

[martinp876]

set hm saveConfig speichert die HM-Device configuration - also alle registersettings (und auch die templates und template-zuweisungen). Per default wird es im File regSave.cfg geschrieben.

save speichert die FHEM-configuration - also defines und attribute. Ein HM saveConfig wird ebenfalls getriggert, ist also inclusive.

für devices wie ein SC welche von FHEM nur mit dem Config-button zur Kommuniation angeregt werden können ist es unabdingbar, das zu tun. Am saubersten ist es

Code Auswählen Erweitern

set <sc> clear msgEvents
set <sc> getConfig
<config button drücken - KEIN RESET>
<prüfen, dass cmd_done zu sehen ist>

nun steht auch 00000000 in den peerIds. Das ist bei allen so.
ein "save" würde sich jetzt anbieten, damit FHEM diese information sichert.

Zitat von: Pfriemler am 14 Februar 2019, 12:27:36
    Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.
Bei mir kann man das ja besichtigen.

kann ich nicht erkennen. Da hast du ein alleinstellungsmerkmal.

Noch kein getConfig bei den beidem ausstehenden. Ich wollte zunächst Meinungen abwarten. Und heute abend habe ich keine Lust, mich ggf. schwarz zu ärgern.

nun, wenn du kein getConfig ausführst können wir dir nicht helfen und könnten uns schwarz ärgen .
Du kannst den Ablauf gerne sniffen. Dann kann ich genau nachvollziehen, was das System macht und muss mich nicht auf deine subjektiven Beochachtungen stützen. Bitte 'sniffen' aus dem Wiki beachten und das Problem nach der Aktion schildern.

[OdfFhem]

save speichert die FHEM-configuration - also defines und attribute. Ein HM saveConfig wird ebenfalls getriggert, ist also inclusive.

Ist dieses Verhalten neu bzw. muss man das "inclusive" irgendwo aktivieren?
Ich habe natürlich eine fhem.cfg, aber "find /opt/fhem -name *.cfg" liefert definitiv keine regSave.cfg.

[martinp876]

Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.
Ich habe verstanden dass saveConfig ( und loadConfig) funktionieren.

[Pfriemler]

Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.

Hm ... gerade getestet: "save" erneuert fhem.cfg und fhem.save, aber regSave.cfg bleibt auf dem Stand des gestrigen manuellen Speicherns.
OldFhem hat offenbar noch gar keine Datei.
edit: Oder meinst Du den Befehl "set <hminfo> save" - Speichern von Temperaturlisten (lt. commandref)?

Trotzdem erklärt das nicht den Gedächtnisverlust bei curt: die Infos zu den Registern stecken auch in fhem.save und das sollte immer aktuell sein.

[OdfFhem]

Ich habe bislang nie ein manuelles "set <hminfo> saveConfig" ausgeführt und bislang auch noch nie ein regSave.cfg beim "Save config" erzeugt.

Nun habe ich einmal "set <hminfo> saveConfig" manuell ausgeführt und es wurde erwartungsgemäß ein regSave.cfg erzeugt.

Automatisch scheint hier aber nichts angestossen zu werden ...

[curt]

Das Verhalten ist uralt.
Was passiert bei set hm saveConfig? Da sollte ein file angelegt werden. Das gleiche bei save.

Würdest Du bitte präziser formulieren?
Welches Verhalten ist uralt? - Mein fhem ist eigentlich immer aktuell.
Bei save wird fhem.save und fhem.cfg aktualisiert. Eine regSave.cfg habe ich nicht.

OldFhem hat offenbar noch gar keine Datei.

Ich auch nicht.

Trotzdem erklärt das nicht den Gedächtnisverlust bei curt: die Infos zu den Registern stecken auch in fhem.save und das sollte immer aktuell sein.

Mit martinp876 haben wir nun aber den, der es wissen müsste:
Martin,
9 Melder  HM-SEC-SC-2 sowie 1 Melder HM-SEC-SCo. Alle sind seit längerem in Betrieb. Auf Anraten wechselte ich von Busware-CC1101 auf HM-MOD-UART. Da VCCU vorhanden, war das ohne Probleme. Alle Register bei allen Meldern vorhanden, alles prima.

Irgendwann stellte ich fest, dass zwei Melder UNTEREINANDER gepeert waren, das wollte ich loswerden. Der Fortgang ist in diesem Thread zu lesen. Beachte bitte insbesondere #13, da ist der spannende Punkt: Mit der Neuanmeldung der beiden fraglichen Melder verloren ALLE ANDEREN Melder ihre Register.

Ich habe nun so verstanden: Die sind in fhem gespeichert, die kann man gar nicht verlieren. Da kann mal der falsche Wert drin stehen, aber man kann die nicht verlieren. Ist das so richtig? Oder kennst Du eine Situation, in der das möglich erscheint?

Martin,
was käme als Ursache noch in Frage?

Wäre es möglich, dass ich auf einen bislang nicht erkannten Bug in Deinen Modulen gelaufen bin?

[martinp876]

1) Pfriemler hat nominell recht: ein "save" löst kein "hm saveConfig" aus. Aber ein "hm archConfig" wenn man "attr hm autoArchive 1" gesetzt hat. HAtteich schon wieder vergessen. Der Unterschied arch und save ist, dass bei arch nur Änderungen aus dem laufenden Betrieb gespeichert werden. Daher wurde auch kein neues File angelegt oder geändert. Save speichert bedingugnslos. Mache ein getConfig und dann ein Save - dann wird das file angelegt.

2) das kein File angelegt wird kann ich mir nicht vorstellen. Das file wird sich auf dem Default-pfad von FHEM finden - also mal im fhem und fhem/FHEM nachsehen.

3) Uralt sind mehrere Jahre. Sollte präzise genut sein, schaue ich jetzt nicht nach

4) bei meinem test wurde ein fhem/regSave.cfg nach einem save angelegt.

5) die Register werde auch aus dem Statefile nachgeladen. Da verlasse ich mich nicht drauf, hatte ich schon zu viele verluste. Daher nutze ich "attr hm autoLoadArchive 1"

Irgendwann stellte ich fest, dass zwei Melder UNTEREINANDER gepeert waren, das wollte ich loswerden

würde ich auch loswerden. Leider kann ich es nicht sehen oder nachvolluziehen.

Mit der Neuanmeldung der beiden fraglichen Melder verloren ALLE ANDEREN Melder ihre Register.

Das ist schlecht. Leider kann ich es nicht nachvollziehen und kann nicht sehen, was du gemacht hast. Wenn du das nachstellen kannst bin ich an einem log interessiert. Das beinhaltet: list der fraglichen devices (eines wird reichen) mit den Registern, anmelden mit sniffen, list der fraglichen devices welche die Register verloren haben

Beachte: wenn das getConfig gestartet wird werden alle Register-Readings dieser Sektion gelöscht. Schlägt das Lesen fehl sind auch keine  Register mehr da. Ein konsequentes vorgehen: wenn du die Register von "jetzt" haben willst und das fehlschlägt wird dir nicht vorgegaukelt "hat doch geklappt". Die gespeicherten Register in regConfig.cfg werden erst nach erfolgreichem Lesen überschrieben - ein Unterschied zu den "einfachen Readings" - und dem autoLoadArchive.

Die sind in fhem gespeichert, die kann man gar nicht verlieren

a) falsch
b) was ist fhem?
c) regConfig.cfg und autoLoadArch sollte das so unterstützen (wenn kein Bug ), fhem.state nicht. Da gibt es Lücken

Da kann mal der falsche Wert drin stehen, ...

falscher Wert verstehe ich nicht. Kenne ich nicht. Fehlen ja.

was käme als Ursache noch in Frage?

Für was jetzt? Das Fehlen von Registern/peerings oder das seltsame peeren? 2teres habe ich noch nie gehört.

Wäre es möglich, dass ich auf einen bislang nicht erkannten Bug in Deinen Modulen gelaufen bin?

bei bisher unbekannten Dingen das so, das sie bisher noch nicht bekannt sind. Also klares "ja". Allerdings kann ich den Hergang noch nicht nachvollziehen - ausser dass ich mich bei Registern auf das statefile verlasse und verlassen würde.
=> solltest du das korrekt eingestellt haben und das Fehlen von Registern immernoch stattfinden bitte mitteilen.

Korret ist (für mich)

Code Auswählen Erweitern

attr hm    autoArchive 1
attr hm    autoLoadArchive 1_load
attr hm    autoUpdate 0:3
attr hm    hmAutoReadScan 30

optional (weil ich meine settings file im getrennten Dir sehen will):

Code Auswählen Erweitern

attr hm    configFilename regConfig.cfg
attr hm    configTempFile tempList.cfg
attr hm    configDir  setup
attr hm    webCmd     update:protoEvents:rssi:peerXref:configCheck:models:msgStat:clear Protocol

und dann erst einmal ein

Code Auswählen Erweitern

set hm savConfig

[curt]

@martinp876

Teile der von Dir vorgeschlagenen Konfiguration waren mir neu. Das habe ich bei mir nun so nachgetragen. Danke!

Nein, noch kein getConfig bei den beiden nicht vollständigen Türmeldern, dafür fehlten mir die Nerven. Und auch noch keine Lösung bei meinen drei Rauchmeldern: Denen fehlt seit Deinem verunglückten Modul-Update das "model", da steht jeweils ein HASH. Dafür habe ich noch gar keine Lösung - bei einem kann ich (verbaut) kein Knöpfchen drücken.

Ich melde mich wieder, wenn ich neues zu melden habe.

[curt]

Alle Türmelder sind nun sauber, die beiden Türen wollten auch nicht wieder heiraten.

Ersatzweise haben die drei Rauchmelder (direkt nach dieser Aktion) vergessen, dass sie einen Chef haben:

Code Auswählen Erweitern


PairedTo missing/unknown
    HM_5A5754
    HM_5A6710
    HM_5A6737


Andererseits wissen die drei ihr "model" auch nicht, da steht immer noch "HASH...".