ALLE Geräte auf "Protokolliert" stellen

[blackhole]

1. ^^ Wie mache ich das?

Vermutlich läuft das auf Handarbeit hinaus. Zielgerichtete Skripte können eventuell helfen.

2. Wie kann ich erkennen, wie hoch der Zähler für IDs ist?

Code: Alles auswählen

cat /etc/config/homematic.regadom|grep -e "<id>"|wc -l

[alchy]

Was BadenPower sagen will, ist wahrscheinlich, daß die Aktivierung der Protokollfunktion so wie gepostet einfach falsch ist.
Und, seiner Art geschuldet macht er wieder mal leider nur Andeutungen.
Also lass das bitte lieber mit dem Script.
Ich bin ne Weile hier kaum online, also kann ich nicht mehr helfen.

Alchy

[Daimler]

Hi,

interessantes Thema.
Produktiv - auch ~ 3 Jahre seit Umstieg auf LXCCU / Yahm, immer wieder per Restore Vorgänger eingelesen.

Code: Alles auswählen

# cat /etc/config/homematic.regadom|grep -e "<id>"|wc -l
16568
#

Testsystem - ~ 2 Jahre, zur Zeit ~ 20 Geräte

Code: Alles auswählen

# cat /etc/config/homematic.regadom|grep -e "<id>"|wc -l
3425
#

[BadenPower]

Was BadenPower sagen will, ist wahrscheinlich, daß die Aktivierung der Protokollfunktion so wie gepostet einfach falsch ist

Nein, das hätte ich dann ganz klar geschrieben.

Es geht nur um den unnötigen Datenmüll, welcher übrigbleib und Geistervariablen.

Wird eine Protokollierung aktiviert, dann legt die CCU im Falle eines Kanals für jeden darin enthaltenen Datenpunkt ein Protokoll-Objekt mit eigener ID an.
Wird eine Protokollierung aufgehoben, dann bleiben alle Objekte zur Protokollierung auf der CCU gespeichert und werden nicht mehr gelöscht.

Und zusätzlich gibt es auch hier gibt es Geistervariablen, also bestehende Zuordnungen (IDs), welche keinem Objekt mehr zugeordnet sind, aber später zu Problemen führen können, wenn die ID wieder belegt wird und zwar mit etwas, was nicht protokolliert werden kann.


Also ich habe auf meinem "cleanen" System mit nur 56 Geräten, über 1700 Datenpunkten, über 700 Systemvariablen und über 250 Programmen mit einer Hand voll Protokollierungen bereits über 20000 verbrauchte IDs. Wenn ich jetzt noch alles protokolliert stelle (und auch wieder zurück), dann kommen nochmals knapp 2500 Ids dazu.

1. ^^ Wie mache ich das?

Vermutlich läuft das auf Handarbeit hinaus. Zielgerichtete Skripte können eventuell helfen.

Per Skript, oder noch besser per HM-Internals, welche alle Online wären, wenn es da nicht ein kleines Problemchen der Skriptbefehl-Verifizierungsmöglichkeit gäbe.
.

[alchy]

Dann ziehe ich meine Vermutung zurück.
Hätte aber durchaus auch sein können das ich da etwas nicht bedacht hätte, war ja ein Schnellschuss.
Allerdings würde ich sagen, das das grep nicht die korrekte Anzahl der benutzten Ids bringen dürfte, allerdings auch aus dem Bauch heraus.

Alchy
Viel zu warm zum denken

[blackhole]

Allerdings würde ich sagen, das das grep nicht die korrekte Anzahl der benutzten Ids bringen dürfte, allerdings auch aus dem Bauch heraus.

Ich denke, Dein Bauch irrt sich. Ziemlich sicher sogar. Was meine CCU2en angeht, sogar 100%ig.
Lass einfach die letzte Pipe (|wc -l) einmal weg, dann siehst Du auch, warum das so stimmt.
Und falls Du auf die oids hinaus willst, damit klappt das genau so (<id> halt durch <oid> ersetzen).

Viel zu warm zum denken

Merk man kaum ...

Viel Spaß und gute Erholung.

[BadenPower]

Allerdings würde ich sagen, das das grep nicht die korrekte Anzahl der benutzten Ids bringen dürfte, allerdings auch aus dem Bauch heraus.

Ich denke, Dein Bauch irrt sich. Ziemlich sicher sogar.

Nein, Alchys Bauch irrt sich in diesem Punkt nicht.

Durch den Datenmüll kommz hier ein falsches Ergebnis zustande, da sich in der regadom doppelte/drei- und vierfache Einträge befinden.

Sortiere einfach einmal die Ausgabe, welche Du erhälst, wenn Du den letzten Pipe wegläßt. Hier findest Du dann Mehrfachausgaben der gleichen ID. Oder vergleiche einmal die Anzahl, wenn Du alle Objekte per Skript ermittelst.
.

[blackhole]

Keine Frage, der Einzeiler zählt natürlich nur die Gesamtzahl aller definierten IDs.

Durch den Datenmüll kommz hier ein falsches Ergebnis zustande, da sich in der regadom doppelte/drei- und vierfache Einträge befinden.

Wenn mit Deiner Aussage ("nur 65535 IDs") lediglich eindeutig vergebene IDs gemeint sind, muss man sich ja keinerlei Sorgen machen, da der "Müll" nur aus nicht relevanten, mehrfach vergebenen (also nicht eindeutigen) IDs besteht.

In diesem Fall würde ich Deine Warnung allerdings nicht verstehen, da Die Wahrscheinlichkeit eines Überlaufs dann ja gegen Null geht und Aufräumen keinen Mehrwert hätte (bezogen auf die Anzahl freier IDs).

[BadenPower]

Wenn mit Deiner Aussage ("nur 65535 IDs") lediglich eindeutig vergebene IDs gemeint sind, muss man sich ja keinerlei Sorgen machen, da der "Müll" nur aus nicht relevanten, mehrfach vergebenen (also nicht eindeutigen) IDs besteht.

Nein, es gibt in der regadom Müll, Müll und Müll.

1. Kategory:
Mehrfache Einträge der gleichen ID.
Läßt die reagdom unnötig wachsen und ein Backup benötigt mehr Platz und die Erstellungdauer wird unnötig verlängert.

2. Kategory:
IDs, welche sich in Zuordnungen befinden, aber momentan keinem vorhandenen Objekt zugeordnet sind. (Ergebnis Geistervariablen und falsche/fehlerhaft Objektaufrufe)

3. Kategory:
Vom System angelegte Objekte, welche beim "nicht mehr verwendet werden" immer noch vorhanden bleiben und nicht gelöscht werden. Wie zum Beispiel im Falle der Protokollierung.

4. Kategory
Löscht man dann ein zugehöriges Gerät, dann werden daraus zum Teil Objekte, welche überhaupt keine Funktion mehr haben, da sie auf nichts zugreifen und mit nichts im Zusammenhang stehen, aber immernoch eine ID belegen.

Und die HistoryDPs, also die Protokollier-Datenpunkte gehören zu den Kategorien 3 bzw. 4.
.

[blackhole]

Na ja, selbst wenn 2, 3 und 4 eindeutige IDs verwenden braucht man sich wohl keine Sorgen zu machen.
Bei meiner Größenordnung (etwas über 100 HM-Geräte mit Programmen und Sysvars in ähnlicher Größenordnung) werde ich es wohl nie schaffen über 10000 eindeutige IDs zu kommen.
Es mag sein, dass man es auf die Spitze treiben kann, das wird aber wohl im realen Betrieb eher nicht relevant sein.
Vorher-/Nachherwerte von fischmir wären aber auf jeden Fall interessant.