CENTRAL-LINK von IP-Geräten löschen per Script (aka ReportValueUsage() bei HM Geräten)

[BanditDD]

Welchen Nachteil handele ich mir damit ein? Was funktioniert nach löschen der CENTRAL LINKS nicht mehr?

[Baxxy]

Steht alles schon geschrieben, lesen musst du selber.viewtopic.php?f=31&t=76196#p739398

[gunterc]

OK. Ich glaube, dass ich es jetzt weitgehend verstanden habe.
Wohl wissend, dass das meiste bereits gesagt wurde, möchte ich es noch mal mit meinen Worten zusammenfassen:

In der einfachsten Konstellation arbeiten die HM-Geräte zunächst weitgehend autark. Es wird keine CCU o.Ä. benötigt. Lediglich zur Verknüpfung untereinander ist eine Steuerung nötig. - Ich nenne die Steuerung im Folgenden einfach CCU.
Damit die CCU die Komponenten verknüpfen kann, muss sie sie kennen. Das geschieht beim 'Gerät anlernen'.

Habe ich z.B. einen Rollladenaktor (im Folgenden FROLL) und einen Taster (z.B. WRC2) angelernt, kann die CCU diese miteinander Verknüpfen. Ab jetzt könnte die CCU abgeschaltet werden, Taster und FROLL unterhalten sich direkt miteinander.

Grundsätzlich erfolgt die 'Unterhaltung' derart, dass ein Gerät etwas 'sagt', und das andere antwortet, wenn es angesprochen wird.
Im Beispiel mit FROLL ist keine wirkliche Antwort nötig: Wenn der Taster 'sagt': "Fahre runter", fährt der FROLL runter und hört auf, wenn die Zeit um ist, oder ein anderer Befehl vom Taster kommt. Ob FROLL arbeitet, wie lange, warum nicht etc., interessiert den Taster nicht.
Zur Sicherheit findet ein Handshake (Acknowledge, ACK) statt, sodass der Taster 'weiß', dass das Kommando verstanden wurde. Kommt diese Empfangsbestätigung nicht, wird das Kommando erneut geschickt. Wenn's nicht klappt, gibt der Taster irgendwann auf, die LED blinkt kurz ROT.

Ich weiß, dass wurde bereits alles gesagt. Ich möchte aber noch mal betonen, dass auf dem Taster hinterlegt ist, mit wem er sich unterhalten soll. So können mit einem Taster auch mehrere FROLL verbunden sein, oder alle. Das weiß der Taster. Und von jedem erwartet er ein ACK.

(Die CCU merkt sich vermutlich auch, was mit wem verknüpft wurde, aber eigentlich nur, um eine Verknüpfung auch wieder lösen zu können. Sie sollte das auch von den Geräten erfragen können (getLinks).)

Vorwort:
Nutzer externer Steuerungen (ioBroker / NodeRed / Homeassistant) kennen das.

Im Vorwort dieses Threads hat Baxxy auf Probleme mit iobroker oder anderen Steuerungen hingewiesen, ICH bin auf den Tread gestoßen, weil ich Taster-Kanäle nicht in MQTT gesehen habe.
Der Grund dafür ist, dass sich die CCU nicht für die Taster interessiert. Natürlich kriegt sie das ganze Gequassel aller Kommunikation mit, aber sie reagiert nur, wenn sie gemeint ist. Sie wird aber nicht über einen Tastendruck informiert. Warum auch. Der Taster redet ja direkt mit seiner Verknüpfung.

Das ändert sich, wenn auf der CCU ein Programm erstellt wird, das diesen Taster verwendet. DANN muss die CCU natürlich auch informiert werden.
Aus Sicht des Tasters ist die CCU jetzt ein Aktor, wie z.B. FROLL und jeder andere.

Genau wie im Fall von FROLL muss der Taster seine Kommunikation mit der CCU über Handshake absichern, der Taster muss also erfahren, dass er auch auf ein ACK von der CCU warten muss.

Hinweis: Somit ist klar, dass wie oben beschrieben, bei Abschalten der CCU der Taster nach wie vor auf seine Bestätigung wartet. Die CCU hat zu antworten, wie jeder andere Aktor auch. Sonst wird rot geblinkt.

Noch mal: letztlich ist nur auf dem Taster hinterlegt, mit wem er sich unterhält. Das Programm der CCU sendet diese Verknüpfung bei Anlegen eines Programms mit dem Taster durch einen Funktionsaufruf mit dem Inhalt, den Baxxy hier viewtopic.php?f=31&t=76196#p739398 vorgestellt hat. (DAS WAR MEINE RETTUNG )

Mit diesem Funktionsaufruf erfährt der 'Sender', also der Taster, denn der ist ja derjenige, der sendet und auf die Antwort wartet, mit welchem Empfänger, in diesem Fall also der CCU, denn die muss ja das ACK geben, er kommunizieren soll. Dieser Funktionsaufruf ist alles, was der Taster braucht, um seinen Status auch von der CCU verarbeitet zu wissen. Darum kann auch, wie an diversen Stellen erwähnt, das hierbei erstellte Programm wieder gelöscht werden. Die Info beim Taster wird nicht zurückgenommen. Die CCU wird also weiter informiert, kann mit dieser Info aber evtl. nichts mehr anfangen, weil das Programm ja gelöscht wurde.

Wie gerade erwähnt und auch in diesem Thread bemängelt (Murks" ) gibt es keinen Automatismus, die CCU vom Taster zu entkoppeln. Theoretisch wäre das sicher möglich, aber praktisch doch schwierig. Die CCU darf nämlich nicht einfach beim Taster abgemeldet werden, wenn das Programm gelöscht wird, weil es ja noch andere Interessenten auf der CCU geben kann, die sich auch für diesen Taster interessieren. Z.B. ein anderes Programm, oder wie in meinem Fall 'CCU-jack', also MQTT. Welche Daten von einer 'Zusatzsoftware' verwendet werden, weiß die CCU selbst hoffentlich nicht....
Aber auch das Scannen der anderen Programme der CCU wäre aufwendig.
Unter'm Strich hat man wohl im Fall der CCU einfach beschlossen: Das bleibt so.

Aber natürlich gibt es einen Funktionsaufruf zum Entkoppeln von Geräten, der wird auch benutzt, wenn eine Kopplung gelöscht wird, der Taster also z.B. nicht mehr mit FROLL reden soll. Aber der Aufruf wird eben nicht für die CCU benutzt.

Und das ist der zweite Funktionsaufruf von Baxxy [viewtopic.php?f=31&t=76196#p739398]: CENTRAL_LINK löschen.

Auch wenn es jetzt den Anschein haben mag, dass ich das alles verstanden habe (ich hoffe, das ist so ), gibt es doch noch was, was ich nicht verstehe.
Ein Fensterkontakt, oder ein Bewegungsmelder ist doch auch nichts anderes, als ein Taster. Und die werden offensichtlich von der CCU ständig abgehört. 'Offensichtlich', weil ich deren Statusänderung in MQTT sehe.

Noch eine Bemerkung zu den Nebenwirkungen:

Nebenwirkungen gibt es dann, wenn eben weitere Interessenten für ein Gerät auf der CCU existieren, an die man nicht gedacht hat. Die funktionieren dann eben auch nicht mehr....

[jp112sdl]

Ein Fensterkontakt ... ist doch auch nichts anderes, als ein Taster.

Doch, das Verhalten eines "SHUTTER_CONTACT" (Schließerkontakt) ist in der Homematic Welt etwas ganz anderes als ein "KEY" (Taster).
Zum Beispiel kann KEY sowas wie "kurzen / langen Tastendruck", was also nicht dazu geeignet ist, dauerhaft einen Kontaktzustand zu übermitteln.

Sieh den Fensterkontakt als Schalter. Nicht als Taster.