Ungewolltes Autocreate für unbenutzte Kanäle von CUL_HM Devices

[clang]

Hallo zap, hallo *,

seit einem Update von vor etwa zwei Wochen werden mit jedem Neustart die Devices für die von mir nicht genutzten Kanäle von CUL_HM devices angelegt. Das wären z.B. für einen Heizungsregler HM-CC-RT-DN die Kanäle:

     ClimaTeam, Climate, Weather, WindowRec und remote.

Interessant ist, daß nicht nur mit dem Atttribut ignoreTypes von autocreate nichts dagegen auszurichten ist, sondern die Geräte werden auch angelegt, wenn autocreate disabled ist. Daher vermute ich mal, daß das nicht so gewollt, sondern ein Fehler ist ist. Im normalen Log mit verbose=1 taucht hierzu keine Meldung auf.

Den Betrieb hält das zwar nicht auf, aber hier summiert sich das hier auf fast 70 devices im Raum Unsorted. Das macht das Auffinden von frisch angelernten Geräten zwar nicht unmöglich, aber sie stören schon etwas.

Ich setze Raspbian GNU/Linux 9 (stretch) mit Kernel 4.9.59+ und Perl v5.24.1 ein.

Die letzte Version von 10_CUL_HM.pm, die hier eingesetzt wurde und das Problem nicht hatte, war

Code Auswählen Erweitern

$Id: 10_CUL_HM.pm 18042 2018-12-23 18:18:36Z martinp876 $

die Version seitdem mit diesem Problem ist die

Code Auswählen Erweitern

$Id: 10_CUL_HM.pm 18915 2019-03-16 06:21:19Z martinp876 $

Da mit dieser neuen Version für mein System das erste mal die Geräte-UUIDs eingeführt wurden, traue ich mich auch nicht ohne weiteres, einfach auf die alte Version zurückzufallen.

Kann ich noch etwas für die Analyse tun?

TIA Chris

[LuckyDay]

Kanäle die man nicht benützt, oder braucht, löscht man nicht! ,
sondern verschiebt sie in einen Raum z.B. CUL_HM.

Du bedienst , nutzt Fhem einfach falsch.

[zap]

Nett, dass du mich direkt ansprichst. Allerdings kann ich dir nicht helfen, da ich mit CUL_HM nichts zu tun habe und es auch nicht verwende.

[clang]

Hey zap,

sorry, da habe ich wohl etwas durcheinander gebracht, dieses Mißverständis hatte ich schon länger ...

[clang]

Kanäle die man nicht benützt, oder braucht, löscht man nicht! ,
sondern verschiebt sie in einen Raum z.B. CUL_HM.

Du bedienst , nutzt Fhem einfach falsch.

Aha, vielen Dank für den Hinweis! Hierzu habe ich allerdings nichts in irgendeiner Dokumentation zu fhem gelesen, daß das quasi best practise wäre. Insofern würde mich interessieren, wie sich das begründet und wo das dokumentiert ist.

Zudem ist für autocreate dokumentiert, daß keine Devices beim Neustart automatisch angelegt werden, wenn dieses Device disabled ist, oder wenn der Typ in ignoreTypes angegeben wird. Das funktioniert hier ganz korrekt seit drei Jahren, und seit der genannten Änderung nicht mehr.

Insofern halte ich es durchaus für möglich, das daß veränderte Verhalten einen (vermutlich ungewollten) Fehler darstellt, hierzu würde mich dann doch eher der Kommentar des Modul-Eigners/Maintainers interessieren.

TIA Chris

[LuckyDay]

Also das Device willst du haben aber nicht alle Cannels

und autocreate ist nicht für Cannels da , genauso wie ignore !

[clang]

Also das Device willst du haben aber nicht alle Cannels

und autocreate ist nicht für Cannels da , genauso wie ignore !

Na, darum geht es wohl kaum. Autocreate bezieht sich nicht nicht auf den Unterschied zwischen physischen Geräten und seiner Kanäle, sondern auf fhem devices. Dabei ist gleichgültig, ob dieses fhem device ein physisches Gerät anspricht oder den Kanal eines physischen Geräts.

Leider kommt das durch  leicht irreführende Verwendung des Wortes device für eine Gerätedefinition im Sinne von fhem nicht so klar heraus, deshalb kann man das leicht verwechseln.

[clang]

Ich habe noch einmal geschaut, tatsächlich werden die Geräte für die ungewollten Nebenkanäle nicht mit autocreate angelegt. Vielmehr macht das die im neuen Modul 10_CUL_HM.pm die neue Funktion CUL_HM_updtDeviceModel, aufgerufen wird es für den fhem startup durch CUL_HM_updateConfig, per timer getriggert durch CUL_HM_Notify. Folgerichtig wirkt sich weder das Dekativieren von autocrate noch das Attribut ignoreList aus.

Das ganze scheint mit der Implementation des neuen Attributs modelForce und/oder den neuen IDs zusammenzuhängen. Ist es richtig, daß mit Hilfe dieses Konstrukts sowohl alle Devices eine ID bekommen sollen, die noch keine haben, als auch das neue Attribut modelForce das Setzen des Attributs model erzwingen können soll?

Mir ist nur nicht klar, warum CUL_HM_updtDeviceModel bei jedem (!) Startup die (noch) nicht existierenden devices für die Nebenkanäle anlegt, zummal, wenn meine Konfiguration schon seit Monaten bereits für alle devices eine ID hat und das Attribut modelForce noch keine Anwendung gefunden hat. Gibt es dafür eine technische Notwendigkeit ?

Thanx Chris

[clang]

Nachdem sich nun längere Zeit niemand zum Thema gemeldet hat, hier mein Workaround für alle, die weder Hauptspeicher noch Laufzeit für fhem devices vom Typ CUL_HM verschwenden wollen, die sie nicht benötigen - das sind bei mir mittlerweile 90 Stück, was in meiner Konfiguration immerhin 20% der Gerätedefinitionen ausmacht.

Um das Anlegen dieser devices beim Startup zu verhindern, wird ein Patch der Moduldatei benötigt, der - bis zu einer entsprechenden Anpassung des Moduls - leider nach jedem Update wiederholt werden muß. Diesen Patch wende ich seit nun seit einem Jahr an und fhem funktioniert seitdem problemlos weiter. Das bestärkt mich zumindest in meiner Einschätzung, daß diese fhem devices für den Betrieb nicht erforderlich sind.

Um möglichst wenig Änderungen am Code vorzunehmen, wird nur die if-Abfrage entschärft, die in der Funktion CUL_HM_updateConfig() beim Startup die nicht benötigten fhem devices anlegt. Dabei wird die Abfrage auf den Typen 'startUp' geändert auf den - nicht existenten - Typen 'startUp_disabled'. Somit wird der problematische Code-Block nicht mehr ausgeführt.

Hier der Befehl:

Code Auswählen Erweitern

sudo sed -i -e 's/$type eq "startUp"/$type eq "startUp_disabled"/' /opt/fhem/FHEM/10_CUL_HM.pm

Besser als ein derartiger Patch wäre natürlich, daß das Modul durch den Entwickler (martinp876 ?) angepasst wird, sei es daß dieser Block entfernt wird oder zumindest durch ein Attribut an- oder ausschaltbar gemacht würde - letzteres für den Fall, daß diese unbenutzten devices doch einen bestimmten Zweck erfüllen.

Wenn man den Patch nicht automatisiert ausführt und dessen Ausführung nach einem Update vergessen hat, und dann die Geräte doch wieder angelegt wurden, hilft der Aufruf folgender Funktion, die alle Geräte im Raum 'Unsorted' löscht und das Ergebnis ins Log schreibt - im Raum 'Unsorted' darf sich zu diesem Zeitpunkt natürlich nichts mehr befinden, was man noch benötigt

Diese Funktion habe ich in meine 99_myUtils.pm gesetzt und über einen Menüeintrag aufrufbar gemacht. Alternativ kann man sie natürlich auch manuell über den Befehl

Code Auswählen Erweitern

{RemoveUnsortedDevices()}
aufrufen. Nach der Ausführung ist die Konfiguration zu sichern.

Code Auswählen Erweitern


sub
RemoveUnsortedDevices()
{
  my @AllDeviceList = devspec2array("(.*)");
  my $AllDeviceCount =  scalar(@AllDeviceList);

  my @UnsortedDeviceList = devspec2array("(.*):FILTER=room=");
  my $UnsortedDeviceCount =  scalar(@UnsortedDeviceList);

  if ($UnsortedDeviceCount > 0) {
    Log 1, "RemoveUnsortedDevices: Deleting $UnsortedDeviceCount unsorted of $AllDeviceCount devices";
    foreach my $d (@UnsortedDeviceList){
      CommandDelete(undef,$d);
    }
    @AllDeviceList = devspec2array("(.*)");
    $AllDeviceCount =  scalar(@AllDeviceList);
    Log 1, "RemoveUnsortedDevices: $AllDeviceCount devices remaining";
    fhem("save");
  } else {
    Log 1, "RemoveUnsortedDevices: none of $AllDeviceCount devices unsorted"
  }
}


[martinp876]

ja, die Auswirkung ist nach der Korrektur zu ModelId dazu gekommen.
Ich werden verhindern, dass bei reboot Kanäle autocreated werden.
Alles andere bleibt - so auch das Erstellen von Kanälen, wenn man bspw forceModel setzt. Das ist essentieller Bestandteil des Kommandos.
Ich werden nie empfehlen auch nur einen Kanal zu löschen - weiter werden ich auch nicht testen, was passiert, wenn Kanäle fehlen.
Solltest du dann einmal einen Kanal benötigen ist es deine Sache, diesen zu erstellen. Du entfernst dich mit dem Löschen vom empfohlenen Vorgehen.
Ich hoffe, das einsparen des Arbeitsspeichers lohnt sich (ist der so knapp bei dir?).

Weather ist bei jedem RT genutzt, da hier die genutzte (gemessene) Temperatur übermittelt wir
Climate nutze ich natürlich wenn mehrere HK in einem Raum sind
Remote nutze ich zur Nachtschaltung per direkt gepeertem Button

Ungenutzte Kanäle schiebe ich in den "Unused" room, aus dem ich sie wieder holen kann.

have fun

[clang]

Hi Martin,

ja, die Auswirkung ist nach der Korrektur zu ModelId dazu gekommen.
Ich werden verhindern, dass bei reboot Kanäle autocreated werden.

Vielen Dank, das ist prima und macht den Patch überflüssig!

Alles andere bleibt - so auch das Erstellen von Kanälen, wenn man bspw forceModel setzt. Das ist essentieller Bestandteil des Kommandos.

Das war ja auch nicht gemeint.

Ich werden nie empfehlen auch nur einen Kanal zu löschen - weiter werden ich auch nicht testen, was passiert, wenn Kanäle fehlen.

Dann wirst Du das jetzt wohl in Zukunft erst einmal abfragen müssen
Nein, im Ernst: selbstverständlich kann man den Anwender dazu auffordern, einen Test erst nach neuem Anlernen duchzuführen.
Vieleicht sollte man das sogar, das halte ich ohnehin für ein ideales Vorgehen bei Tests, und so habe ich das jetzt auch beim problematischen Unterputzschalter gemacht, sogar immer mit Factory Reset (die Daten kommen gleich noch).

Ich würde Vorgaben für einen vernünftigen Test als Voraussetzung für Deine Hilfe auch explizit in die Doku schreiben.
Z.B. der Artikel zum Sniffen hilft richtig gut weiter, und wenn man in diesen oder in einen weiteren Grunsatzartikel zu Thema Homematic Support außerdem (!) noch reinschreibt:

   Vor einem Test ist das Gerät neu anzulernen, ggf. unbenutzte Kanäle sind frühestens nach Abschluß eines Tests wieder zu entfernen.

dann braucht man sich über den Punkt gar keine Gedanken mehr zu machen, und eine derartige Vorgabe wäre gänzlich unnötig.
Ausserdem: sollte ein Problem im Test dann plötzlich nicht mehr auftreten, hat der Anwender gleich selbst die Fehlerursache gefunden. Win-Win!

Solltest du dann einmal einen Kanal benötigen ist es deine Sache, diesen zu erstellen.

Also über diesen Punkt bin ich ja schon mehrfach ganz aus Versehen gestolpert... oops, da steht ja was in "Unsorted" - ach ja, ich hab ja neu angelernt Also NP

Du entfernst dich mit dem Löschen vom empfohlenen Vorgehen.

Zunächst mal:
ich habe in 2016/2017 echt viel gelesen und es soeben nocheinmal geprüft, aber derartiges ist mir weder als Empfehlung noch als Vorgabe untergekommen.

Nehmen wir die mal offensichtlichtsten Dokumente
    https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM
    https://wiki.fhem.de/wiki/Quick-Start
und wohl besonders maßgebend
    https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
Da würde man eine solche Vorgabe doch am ehesten erwarten, aber steht nichts dazu, daß man Geräte für unbenutzte Kanäle nicht löschen soll.
Wo also steht denn bitte diese Vorgabe?

Ich hoffe, das einsparen des Arbeitsspeichers lohnt sich (ist der so knapp bei dir?).

Nein, es geht zuerst um Dinge, die gar nicht benötigt werden. Aber na gut, da hast Du einen Punkt, seit Raspi 3 im letzten Jahr wäre das nicht mehr sooo wichtig

Das ist wohl auch mehr eine Philosophiefrage: nichts zu tun, was nicht technisch notwendig ist.
Ist vielleicht auch ein wenig beruflich bedingt, ich mache Integration von Software in Server- und Arbeitsplatzsysteme, und muß in der Regel ungenützte oder riskante Features aus Sicherheitsgründen eher entfernen oder abschalten, damit das ganze einen Sicherheitsaudit besteht.
Aber nicht falsch verstehen: natürlich spielt Sicherheit hier keine Rolle!

Weather ist bei jedem RT genutzt, da hier die genutzte (gemessene) Temperatur übermittelt wir
Climate nutze ich natürlich wenn mehrere HK in einem Raum sind
Remote nutze ich zur Nachtschaltung per direkt gepeertem Button

Heizungskatoren sind wirlich das beste Beispiel, normalerweise braucht man von den vorhandenen (waren das nicht sechs?) nur zwei Kanäle.
Ok, Du brauchst drei, aber auch das wäre für mich kein Grund, die unbenutzten nicht zu entfernen.

Und bezüglich direkt peeren ist dann die Doku wieder unvollständig. Den Anwendungsfall finde ich z.B. total spannend, aber ich wäre gar nicht erst darauf gekommen, daß das überhaupt geht.
Denn laut
  https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
siehe Abschnitt Grundlagen geht das gar nicht, hier heisst es:

  Achtung: Ist ein Device gepairt, werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen.
  Man kann u.a. keine Kanäle mehr direkt peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM.

Zug guter Letzt, aber natürlich wichtig: ich habe einen Heidenrespekt vor dem Code in 10_CUL, und die anderen Teile habe ich noch nicht einmal angesehen. Und wie jeder fhem/Homematic User muß auch ich Dir deutlich Dank sagen - dies sei hiermit mit Nachdruck geschehen!

Thnx Chis

[Otto123]

Und bezüglich direkt peeren ist dann die Doku wieder unvollständig. Den Anwendungsfall finde ich z.B. total spannend, aber ich wäre gar nicht erst darauf gekommen, daß das überhaupt geht.
Denn laut
  https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
siehe Abschnitt Grundlagen geht das gar nicht, hier heisst es:

  Achtung: Ist ein Device gepairt, werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen.
  Man kann u.a. keine Kanäle mehr direkt peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM.

Hi,

ich nenne das immer Wunschlesemodus, Du unterschlägst hier und für Dich die Fortsetzung des Satzes: Siehe peeren
und peeren ist ein Link, da steht wie es geht. In dem Original Satz Deines falschen Zitates oben ist direkt hervorgehoben!
Für Dich nochmal so:
Direktes Peeren -> An beiden Geräte über die Anlerntaste.
Dazu der andere Fall: Peeren über die Zentrale - indirektes Peeren.
Verständlich?

Auch hervorgehoben in dem Peering Artikel:

Achtung: Das in vielen mitgelieferten HomeMatic-Anleitungen beschriebene Peering von Kanälen ohne Zentrale funktioniert nur, wenn keines der beiden Geräte gepairt ist. Im Folgenden gehen wir davon aus, dass beide Geräte bereits mit einer HomeMatic-Zentrale (z.B. FHEM) gepairt sind.

Gruß Otto

[martinp876]

Nur ein paar Kommentare:
Ich teste wenn, dann mit allen Kanälen. Die Testabdeckung hier ist am grössten. Nicht anders herum. Deinen beruflichen Ansatz verstehe ich. hier trifft es nicht zu.

Der rt hat nach eq3 nomenklatur 7 Kanäle, 0 bis 6. Plus das device. kanal0 und device fasse ich zusammen.
Benötigt werden alle.
04 clima ist die primäre steuerung.
01 braucht man bei externen temperatur sensoren. Das ist bei einsatz eines tc sowieso gesetzt. Ich brauche es in ein paar Zimmern da der Sensor remote sein muss. Ein einfacher tempsensor
02 ist climate. Mittlerweile weiss ich dass te für team steht. Hier ist der tc geteamt.
03 winrec. Selbsterklärend. Habe ich nun nicht, aber den internen.
05 der 2. Teamkanal. In manchen Zimmern habe ich mehrere rt. Hier ist teaming angesagt.
06 remote ist ein cooles Element um bspw die nachtabschaltung zu setzen. Ohne zentrale! Oder das hochfahren.

Ausser 03 sind bei mir alle in Betrieb. Nicht bei jedem rt, korrekt!

Wie du es nutzt ist deine Sache