Aktualisierung peerIDs/peerList

Begonnen von Michael N., 01 Oktober 2022, 17:03:22

Vorheriges Thema - Nächstes Thema

Michael N.

Ich habe gerade versucht, eine Assoziation zwischen zwei MAX! Thermostaten zu entfernen. Das hat zunächst ohne Fehlermeldung funktioniert, aber in peerIDs/peerList stand die Assoziation noch drin. Deshalb habe ich es nochmal versucht, dabei aber eine Fehlermeldung (Invalid Command) bekommen.

Dann habe ich es beim anderen Thermostat probiert und es hat funktioniert. Unterschied: das andere Thermostat hatte zwei Assoziationen.

Nun kenne ich mich mit dem FHEM-Code nicht wirklich aus. Aber laut Log wird nach dem Entfernen der letzten Assoziation vom Thermostat für "peers:" gar nichts mehr gemeldet. Kann es sein, dass nach dem Entfernen der letzten Assoziation peerIDs und peerList nicht korrekt aktualisiert werden? Das würde es erklären. Denn bei dem Thermostat, das vorher zwei Assoziationen hatte, kommt die Meldung "peers: xxxx" mit der verbleibenden Assoziation und peerList und peerIDs werden richtig aktualisiert.

Wzut

Das Thema kann für den User leicht verwirrend sein. Zuerst muß man die drei Readings peers, peerList und peerIDs in zwei Gruppen teilen :
1. peerList und peerIDs werden immer dann um einen Eintrag erweitert wenn ein Funk Telegramm "gesehen" wurde zu einem anderen MAX Device.
D.h. diese beiden Readings als Liste sollten eigentlich niemals kleiner werden.

2. peers : Diese Liste wird gesteuert durch die Befehle associate und deassociate bzw. auf ein positives ACK nach einem der beiden Befehle.
D.h. viele User werden dieses Reading gar nicht haben wenn das peering vor dem Einsatz der Beta Module angelegt wurde.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Michael N.

Okay, offensichtlich habe ich die Beta-Module, denn ich bekomme das reading "peers:".

Hat es einen tieferen Sinn, dass peerIDs und peerList nur erweitert werden?

Wzut

Zitat von: Michael N. am 06 Oktober 2022, 09:40:22
Hat es einen tieferen Sinn, dass peerIDs und peerList nur erweitert werden?
Klar, woher soll die Information kommen das das Gerät in Zukunft nicht mehr mit einem Teilnehmer aus der Liste sprechen wird ?
Könnte man die Infos direkt aus dem MAX Device ziehen wäre das alles einfach, aber so muß man sich entweder mit Krücken behelfen bzw. den User in die Pflicht nehmen mit deletereading selbst Ordnung zu machen oder die Info ganz verschweigen wie die ganzen Jahre bisher.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Michael N.

Aber wenn (mal) "peers:" kommt und eine kürzere Liste liefert, warum werden dann peerIDs und peerList nicht auf den aktuellen Wert gesetzt?

Ich hatte in der Vergangenheit ein paar Experimente gemacht und musste auch mal ein Thermostat austauschen. Deshalb habe ich mich über peerIDs/peerList sehr gewundert. Ich habe die beiden jetzt mit deletereading entfernt und dann einfach eine Assoziation hergestellt, worauf vom MAX! der von ihm tatsächlich verwendete Wert kam. Jetzt stimmt peerIDs/peerList wieder. Deshalb verstehe ich nicht so ganz, wieso "peers:" die beiden nicht einfach überschreibt.