Unbekanntes Max Device in peerList

[r-m-w]

Hallo zusammen,

ich habe seit Längerem einen persistenten 'rferror' in meinem MAX Wandthermostat (WT)
und versuche der Ursache auf d. Grund zu gehen.
Meine 4 MAX HTs sind über ein CUL device mit fhem verbunden und jeweils mit dem WT 'associated'.
In den readings d. WT (peerIDs und PeerList) taucht aber ein device auf, welches ich nicht kenne:
   'MAX_16ec24'
Auch nach einem deleateReading von peerIDs und PeerList, (und fhem restarts, etc.)
taucht es irgendwann wieder auf.
Im Event monitor sehe ich aber nichts von diesem device. 

Nun meine Frage:
+ kann dies die Ursache für den 'rferror' sein ?
+ bekomme ich dies nur durch ein 'factoryReset' des WT wieder weg ?

Wenn ja, was ist der beste 'workflow' bei einem factoryReset des WT ?
Muß ich ihn danach wieder mit fhem pairen: 'set cm pairmode'
und dann nur noch 'einseitig' mit meinen HTs assoziieren ?
Kann ich  dann noch mit 'restoreDevice' mein 'weekProfile' wiederherstellen ?

Sorry für die vielen Fragen aber meine Installation läuft recht zufriedenstellend ...
und ich will sie mir eigentlich nicht wegen des 'doofen' rferrors ruinieren   

Im Voraus mal Danke für eure Unterstützung
Gruß
Ralf

[Wzut]

hmmmm Reading löschen um Problem zu lösen ? Da würde ich doch lieber den Wert mit Tipp-Ex am Monitor übermalen ....
OK ernsthaft :
Wenn die Adresse 16ec24 immer wiederkommt kann man fast davon ausgehen das dein WT wirklich eine Nachricht an das Gerät schickt und wenn dieses dann nicht antwortet weil nicht vorhanden ergibt das im WT ein rferror.
Das da im Event Monitor nichts zu sehen ist : auch klar Hier kann nur ein verbose 5 Log des cm Device weiterhelfen, u.A. wird man dann sehen was das WT von dem 16ec24 wirklich will. OK wird dich nicht interessieren, du willst es nur weg haben.

Der elegante Weg ist eigenlich ein simples unpeering (deassocicate) , allerdings geht das im Webinterface nicht da es nicht in der DropDown Liste steht.
Ist aber kein Problem , du gibst den set <name> deassocicate 16ec24 einfach in der Kommandozeile ein.

Werksreset geht natürtlich auch, bei einem leeren Hirn vergisst es auch den Geist. Aber das ist wesentlich mehr Aufwand, da nachher sowohl ein Pairing ansteht ( ok ist easy beim WT ) als auch das Setzen aller Parameter (Readings/Weekprofile) inklusive der Peers (HTs).
Ich rate davon ab und würde zuerst den leichten Weg via deasso gehen, schlägt der fehl wären die Log Ausgaben bei verbose 5 für mich interessant.
- Pairmode setzen ist unnötig , das Device gibt es in FHEM ja bereits !
- Einseitiges peeren aller Peers (HTs) reicht, da die HTs von diese Aktion nichts mitbekommen haben und nach wie vor das WT als Chef kennen.
- wenn du zuerst ein saveConfig machst kannst du natürlich nach einem Werksreset alles wieder mit restoreDevice herstellen, dafür ist die Funktion ja da

Aber bevor du das alles machst, tue mir bitte noch einen Gefallen (ich habe da so einen Verdacht da du schon der Zweite mit dem Prob bist) :
Drücke an dem WT mal die Boost Taste länger bis der 30 Sekunden Countdown läuft. Läuft er bis 0 runter oder ist ganz schnell Schluss ?
Was zeigt nach dieser Aktion das Reading PairedTo im WT ?
Hast du zuvor MAXLAN benutzt und bist irgendwann auf den CUL umgestiegen ? 

[r-m-w]

Hallo Wzut,

Danke für die Hilfe.

Nach Drücken d. Boost-Taste bricht der Countdown nach 1 Sekunde ab
(..war mir in d. Vergangenheit schon öfter aufgefallen..., bspw. nach Batteriewechseln...)
Das PairedTo Reading im WT zeigt '123456', das ist mein CUL_MAX Device   
Nein, 'MAXLAN' hatte ich nie, hab mit raspi und CUL vor ca. 4 Jahren begonnen...

Das 'set Wandthermostat deassocicate 16ec24', bzw. '..deassocicate MAX_16ec24'
führte leider nur zu der Fehlermeldung:

Code Auswählen Erweitern

Wandthermostat, no MAX device found with address MAX_16ec24

Ich werde jetzt mal mit 'verbose 5' im cm schauen was dort erscheint ...
(interessiert mich schon 

Dannach werde ich es mit dem reset probieren (du hast mir das ja sehr schön mit dem
saveConfig und resetDevice beschrieben)

Danke nochmals, Gruß
Ralf

p.s.: woher kommen denn die vielen '..cm CUL1:ok' im cm-Logfile (ca. alle 3. Min)

[Wzut]

leg einfach einen Dummy an

Code Auswählen Erweitern

define myghost MAX HeatingThermostat 16ec24
attr myghost dummy 1


Wenn das WT sauber ist einfach den Dummy wieder löschen

[Wzut]

Nach Drücken d. Boost-Taste bricht der Countdown nach 1 Sekunde ab
<--snipp -->
p.s.: woher kommen denn die vielen '..cm CUL1:ok' im cm-Logfile (ca. alle 3. Min)

a. das ist gut, der Countdown bricht ab sobald das Re-Pairing durch ist. Sorgen muß man sich machen wenn er bis zum Ende läuft

b. bitte mal die komplette Zeile posten, kommt natürlich auf den Loglevel an, sieht aber aus wie der aktuelle state.
und btw. es gibt kein cm-Logfile, nur das normale Logfile von FHEM

[r-m-w]

Hi,

ich habe für das CUL_MAX ('cm') ein Logfile angelegt.

Code Auswählen Erweitern

define cm CUL_MAX 123456
...
define FileLog_cm FileLog ./log/cm-%Y.log cm

'Früher' waren dort immer Msg. Drops/'missing ACK' oder niedrige 'credit10ms' Werte abgelegt.
Jetzt scheint dort alle 3 Min. das 'state' Reading abgelegt zu werden.
Evtl. schalte ich das ab, weil ja sonst keine sinnvolle Info geschrieben wird.

Bei 'verbose 5' für das CUL_MAX erhalte ich keinerlei Fehlermeldung (bspw. beim Ausführen von
'set Wandthermostat deassociate 16ec24').
Es erscheint auch eine Zeile in der eine Msg. an das
nicht vorhandene Device gesendet wird ... den ghost '16ec24' 

Code Auswählen Erweitern

2020.11.08 19:54:41 5: cm, Send Queue is now empty
2020.11.08 19:56:59 5: cm, IODev CUL1, len 12, msgcnt 0E, msgflag 04, msgType WallThermostatControl, src 14e64e, dst 16ec24, group 0, payload 2CD9, rssi -78
2020.11.08 19:56:59 5: cm: dispatch MAX,0,WallThermostatControl,14e64e,2CD9
2020.11.08 19:56:59 5: MAX_Parse, MAX,0,WallThermostatControl,14e64e,2CD9

Das mit dem 'dummy' Device hat leider nicht geklappt.
Den WT reset werde ich mal probieren wenn ich am Wochenende Zeit finde.
Mittlerweile zeigen auch zwei meiner HTs einen rferror 
Das man das nicht zurücksetzen kann !?

p.s.: ansonsten läuft das 'WochenProgramm' aber zuverlässig.
       Das mit den 'rferrors' ist halt nur 'Kosmetik' ...

[Wzut]

OK, wenn du ein FileLog extra auf dein cm legst stimmt deine Aussage. Ich hatte allerdings nicht damit gerechnet das ein User die Readings extra loggt.
Du must einen Filter setzen damit state nicht mit Log landet (siehe command.ref FileLog) oder zumindest event-on-change-reading setzen damit der gleichbleibende state nicht jedesmal im Log landet.

Dein verbose 5 Log Abschnitt zeigt das das  WT wirklich ein Telegramm an diese Adresse schickt.
Setz doch bitte mal auch verbose 5 an diesem WT. Sobald du das  set Wandthermostat deassociate 16ec24 absetzt müssen Meldungen über den Vorgang im Log vorhanden sein, die wäre intressant.

Was deine rferrors an den HTs betrifft : sicher das es nicht am Attribut broadcastTimeDiff des cm liegt ? -> https://forum.fhem.de/index.php/topic,106258.0.html

[r-m-w]

Danke für den Hinweis mit dem attr 'event-on-change-reading'

Aber bei verbose 5 für das WT kommen beim Absetzen des 'deassociate' Kommandos keine zusätzlichen Ausgaben im Logfile 
Ich hab jetzt zusätzlich auch noch den dummy 'MAX_16ec24' in der peerList 

Bei verbose 5 für das cm (CUL_MAX) kommen einige Meldungen bzgl. 'TimeInformation' obwohl ich das attr 'broadcastTimeDiff' gar nicht gesetzt hab:

Code Auswählen Erweitern

2020.11.11 23:12:15 5: cm, IODev CUL1, len 12, msgcnt 36, msgflag 04, msgType WallThermostatControl, src 14e64e, dst 16e8b2, group 0, payload 22D9, rssi -72.5
2020.11.11 23:12:15 5: cm: dispatch MAX,0,WallThermostatControl,14e64e,22D9
2020.11.11 23:12:15 5: MAX_Parse, MAX,0,WallThermostatControl,14e64e,22D9
2020.11.11 23:12:15 5: Wandthermostat, desiredTemperature : 17, temperature : 21.7
2020.11.11 23:12:15 5: cm, IODev CUL1, len 14, msgcnt 36, msgflag 02, msgType Ack, src 16e8b2, dst 14e64e, group 0, payload 01180022, rssi -91
2020.11.11 23:12:15 4: cm, ACK from HT_Essecke_Links to Wandthermostat
2020.11.11 23:12:15 5: cm: dispatch MAX,0,Ack,16e8b2,01180022
2020.11.11 23:12:15 5: MAX_Parse, MAX,0,Ack,16e8b2,01180022
2020.11.11 23:12:15 5: MAX_Parse, MAX2,0,ThermostatState,16e8b2,180022
2020.11.11 23:12:27 5: cm, IODev CUL1, len 15, msgcnt 97, msgflag 05, msgType TimeInformation, src 1356b9, dst 123456, group 0, payload 140B178CD9, rssi -75
2020.11.11 23:12:27 4: cm, TimeInformation from HT_Wohnzimmer_Mitte to now is only 2 seconds. - ignoring !
2020.11.11 23:12:27 5: cm, IODev CUL1, len 15, msgcnt 97, msgflag 00, msgType TimeInformation, src 1356b9, dst 14e64e, group 0, payload 140B178CDA, rssi -76
2020.11.11 23:12:27 4: cm, TimeInformation from HT_Wohnzimmer_Mitte to Wandthermostat : 23:12:26 11.11.2020 , unknown (0, 2, 3)
2020.11.11 23:12:27 5: cm, IODev CUL1, len 14, msgcnt 97, msgflag 02, msgType Ack, src 14e64e, dst 1356b9, group 0, payload 01580422, rssi -72.5
2020.11.11 23:12:27 4: cm, ACK from Wandthermostat to HT_Wohnzimmer_Mitte
2020.11.11 23:12:27 5: cm: dispatch MAX,0,Ack,14e64e,01580422
2020.11.11 23:12:27 5: MAX_Parse, MAX,0,Ack,14e64e,01580422
2020.11.11 23:12:27 5: MAX_Parse, MAX2,0,WallThermostatState,14e64e,580422
2020.11.11 23:12:27 5: Wandthermostat, bat 0, rferror 1, panel 0, langateway 1, dst 1, mode 0, displayActualTemperature 4
2020.11.11 23:12:27 5: Wandthermostat, desiredTemperature 17
2020.11.11 23:12:32 5: cm, IODev CUL1, len 15, msgcnt 98, msgflag 05, msgType TimeInformation, src 1356b9, dst 123456, group 0, payload 140B178CDE, rssi -75
2020.11.11 23:12:32 4: cm, TimeInformation from HT_Wohnzimmer_Mitte to now is only 2 seconds. - ignoring !
2020.11.11 23:12:37 5: cm, IODev CUL1, len 15, msgcnt 99, msgflag 05, msgType TimeInformation, src 1356b9, dst 123456, group 0, payload 140B178CE3, rssi -76
2020.11.11 23:12:37 4: cm, TimeInformation from HT_Wohnzimmer_Mitte to now is only 2 seconds. - ignoring !

Ist der default von 10s aktiv, oder sollte ich den aktivieren ?

[Wzut]

Ist der default von 10s aktiv, oder sollte ich den aktivieren ?

ja sicher ist der mit 10 aktiv darum werden die Anfragen deiner HT ja nicht beantwortet da deren Zeitunterschied "nur" 2 Sekunden beträgt.
Wenn du es dir leisten kannst geh halt runter auf 2 oder 1 oder schalte es ganz ab mit 0. Bei 0 sollten die rferrors verschwinden.

Aber back to Topic : Mir gehen da nun langsam die Ideen aus, sieht aus als ob bei dir das Kommando komplett ignoriert wird.
Nun bleiben dir noch zwei Möglichkeiten : 1. meine aktuellen Beta Versionen ausprobieren oder halt 2. der Werksreset des WT   

[MaxHolstein]

Ich klinke mich hier mal ein, da ich auch das Problem mit unbekannten Devices in der peerList habe, z.B.

peerList Broadcast,MAX_0e3002,MAX_12340e

Beide Devices habe ich nicht, kann sie auch nicht per de-associate entfernen (unknown device) bzw. ein neues Device unter diesem Namen anlegen. Bei mir tritt das in 5 von 10 HT, in beiden WT und in einem von 5 Fensterkontakten auf. Ich beobachte auch, dass neue devices hinzugefügt werden, obwohl ich das System nicht anfasse.

Soweit ich sehe, läuft fhem dennoch wie erwartet, aber ein solchen zufälliges Verhalten macht mich halt stutzig.

Ich bin nicht auf dem letzten Update, mitten in der Heizperiode vermeide ich Updates soweit es geht. Das Max-Modul ist 10_MAX.pm 23290 2020-12-04 11:49:41Z Wzut $

Gibt es denn neue Erkenntnisse?

Schon mal vielen Dank!

[Wzut]

Ich habe es schon oft geschrieben : Schaltet das verdammte autocreate ab , wenn ihr nicht täglich neue Geräte in FHEm einbindet.
Und wenn mal etas Neues ansteht kann man es immer wieder kurz aktiv setzen.
Sobald der CUL ein zerstörtes aber plausibles Telegramm empfängt hat man ganz schnell ein Geistergerät.

Ob auf diese Art auch nicht vorhandene Geräte Einzug in das Reading PeerList finden konnte ich bei mir noch nicht beobachten,
hier würde nur helfen die Readings mal von Hand zu säubern und lange auf einem hohen verbose Level das CUL_MAX Device zu loggen.

[MaxHolstein]

autocreate ist bei mir immer abgeschaltet per attribute "disabled", womit diese Quelle der Geistergeräte wohl ausfällt.

Ist unter "Readings von Hand säubern" ein deassociate zu verstehen? Das scheint auch nicht zu funktionieren. Tatsächlich vorhandene Devices kann ich nicht aus der PeerList entfernen, der Befehl wird einfach ignoriert und die Geistergeräte lassen ohnehin nicht löschen (unknown device).

Letztes Maßnahme war dann, die readings peerIDs, peerList und peers von allen betroffenen Devices zu löschen und danach die Geräte per associate neu zu koppeln. Mal seh'n, ob as dauerhaft hilft.

[Wzut]

autocreate ist bei mir immer abgeschaltet per attribute "disabled", womit diese Quelle der Geistergeräte wohl ausfällt.

Richtig , es verhindert das ungewollt komplette Geräte angelegt werden. Du schreibst aber das du Gerät xy nicht von Hand anlegen kannst, das passiert eigentlich nur dann wenn es ein Device mt dieser Adresse in FHEM bereits gibt. Und woher kommt diess Device wenn nicht via autocreate ?
Tipp : der CUL_MAX Befehl get <name> deviceinfo <addresse> kann hier mehr verraten.

Ist unter "Readings von Hand säubern" ein deassociate zu verstehen?

NEIN auf keinen Fall

die readings peerIDs, peerList und peers von allen betroffenen Devices zu löschen und danach die Geräte per associate neu zu koppeln.

readingsdelete <name> <reading>  genau dies Art Wischmopp war gemeint. Erneutes associate ist unnötig und bringt auch nichts, die betroffenen Readings entstehen durch "abhören" des Funverkehrs zwischen verschiedenen Geräten.
Bsp:  FK schickt open an HT, dann bekommt der FK das HT in seine Liste und das HT die Addresse des FK. Empfängt der CUL nun ein teilweise zerstörtes Telegramm -> open von FK an xy landet xy in der PeerList obwohl es xy gar nicht gibt. Stört den normalen Betrieb aber in keiner Weise. 

[MaxHolstein]

Vielen Dank für die prompte Info und Hilfe! 

Und woher kommt diess Device wenn nicht via autocreate ?

Ich habe keine Ahnung! Das ist ja das eigentliche Thema dieser Diskussion.

Habe die betroffenen Readings gelöscht und Devices - soweit notwendig - wieder assoziiert; die Peer Readings wurden dann nach und nach wieder richtig gesetzt.

PS: "readingsdelete" kannte ich nicht - ist das dasselbe wie "deletereading" oder ein Tippfehler?

[Wzut]

Das ist ja das eigentliche Thema dieser Diskussion.

Ähh des Erstellers ? eher nein, sondern "nur" die Liste in peerList
Aber ich blick bei dir leider noch nicht so ganz durch, dachte das eigentliche Thema "wie kommt Device XA in die Liste von ABC "wäre jetzt geklärt.
Geräte die sich in FHEM verewigt haben und quasi einen Eintrag in $modules{MAX}{defptr} haben eine ganz andere. Solche Geräte kann man nicht nochmal erzeugen egal ab von hand oder via autocreate, weil das der punkt ist wo sich FHEM weigert und mit der meldung kommt das es dieses gerät bereits gibt.   

wieder assoziiert; die Peer Readings wurden dann nach und nach wieder richtig gesetzt.

warum machst du das ? Assozieren (peeren) bewirkt an dieser Stelle gar nichts. Das Gerät wird dich das Modul nicht ausgelesen - das geht bei MAX nicht. Das Reading ist lediglich ein Sammler von Informationen die irgendwann in irgendeiner Art halt mal aufgeschnappt wurden.
Der Sinn und Zweck ist eigentlich dem User ein Mittel an die Hand zu geben um prüfen zu können ob sein associate überhaupt beim Device angekommen ist, denn wird es nicht befüllt ist zu 100% davon auszugehen das das andere Gerät bisher nie ein Telegramm direkt an diess geschickt hat.

"readingsdelete" kannte ich nicht - ist das dasselbe wie "deletereading"

ja da war ich heute Morgen wieder auf der interen  Autoren Spur statt auf der Userebene.
User benutzen in der Kommandozeile "deletereading",  das wird FHEM intern zum Kommando  "CommandDeleteReading", möchte ich auf Perl Ebene ein Reading in meinem Modul löschen rufe ich die FHEM interene Funktion "readingsDelete" auf