Automatische Erzeugung der HMID aus der CUL definition

[Otto123]

Hallo Rudi,

ich finde die automatische Erzeugung einer hmId aus der Definition eines CUL äußerst ungünstig. Die meisten User wissen nicht wenn sie mit HM anfangen, dass sie ein hmId brauchen. Ist ja für sie nicht schlimm, das Modul regelt das ja.
Damit geht diese Information an Ihnen oft komplett vorbei, bis der CUL mal neu definiert wird. Plötzlich ist ein Problem da. Siehe aktueller Fall.

Ich stelle den Antrag: 
Entweder

erzeugt das Modul keine hmId mehr automatisch, damit muss der User sich aktiv kümmern. -> wäre konsequent aber bringt sicher Probleme mit bestehenden Systemen mit sich.

Oder es wird wenigsten nicht einfach stillschweigend und UNSICHTBAR eine aus der DEF produziert (F1 + FHTID)    sondern daraus wenigstens das attr hmId ordentlich gesetzt, wenn es nicht schon vorhanden ist.

Sind nur Ideen, vielleicht gibt es bessere.

Gruß Otto

[rudolfkoenig]

Zur Klarstellung, auch fuer die Anderen: Ein CUL wird mit einem ID (in der Doku FHTID genannt) definiert, beim autocreate haengt dieser ID vom Linux Geraetenamen ab. hmId wird fuer HomeMatic benoetigt, und ist (falls nicht explizit gesetzt) F1<FHTID>.
Du haettest gerne entweder eine Fehlermeldung, falls hmId nicht gesetzt ist (da muss aber Martin als CUL_HM Maintainer auch mitmachen), oder hmId als Attribut explizit beim Definieren angelegt.

Was ich nicht verstehe: Wenn der Benutzer das CUL mit einem anderen ID definiert, wieso erwartet er, dass es mit dem vorher gepaarten Geraeten funktioniert? Ich meine in so einem Fall wuerde keiner der beiden Vorschlaege was bewirken, da der Benutzer das hmId Attribut genauso aendern wird.

Ich weiss nicht genau, welchen Wiki-Artikel Mike73 im verlinkten Beitrag meint, aber offensichtlich fehlt da der Hinweis, dass FHTID auch im HomeMatic Kontext relevant ist.

Btw. das ist eher ein HM Problem, und ich verwende kein HM. Will sagen, ich haette kein Problem damit, Martins Wunsch zu uebernehmen.

[Otto123]

Ich hatte wirklich schon öfter den Supportfall in etwa dieser historischen Reihenfolge des Users:
Er kauft einen CUL, kopiert die Zeilen aus dem Wiki oder irgendeinem Artikel im Internet. Dort steht dann gerne eine Zahl hinter der Definition 0000 oder 1234. Ich glaube in dem Moment weiß er nichts von FHTID oder hmId.
Er arbeitet mit dem CUL
Er stellt fest es gibt HM, kauft Komponenten, macht irgendwie ein Pairing. Funktioniert wenn er Glück hat. Er weiß immer noch nichts von einer hmId. Keine Theorie, nie ein Handbuch gelesen immer nur das Minimum gemacht. Geht einfach ...
Irgendwann wird alles neu gemacht, nach Monaten und Jahren, andere Beschreibung was weiß ich. Hinter die DEF wird wieder irgend eine Zahl geschrieben, dass daraus eine hmId abgeleitet wird ist ihm nicht bewusst.
Erst wenn nichts mehr geht und einer es ihm sagt.

Der Fall mit Mike73 ist exemplarisch und gerade aktuell, ich hatte schon jemanden der hat mit mir gestritten: Er brauchte nie eine hmId und es ging trotzdem  Er wusste sie nicht mehr und die fhem.cfg war weg.

Ich bin der Meinung: Wenn man HM macht muss man wissen, dass man eine hmId braucht und man muss die festlegen und sich irgendwie "merken".
Von mir aus soll die automatisch aus der FHTID abgeleitet werden, aber sie sollte dann auch sichtbar im attr <> hmId stehen. Da kann sie geändert werden und da gehört sie hin.

Gruß Otto

[rudolfkoenig]

Er wusste sie nicht mehr und die fhem.cfg war weg.

In diesem Fall hilft aber ein explizit angezeigtes oder gar selbst erstelltes hmId auch nicht.
Mir ist noch nicht klar, wie ich Benutzer zu einem funktionierenden Backup zwingen soll

[Otto123]

Ja Rudi das ist klar. 
Für mich war an der Stelle schlimmer: Ihm war nicht bewusst sich je darum gekümmert zu haben!

Ich sehe schon, ich habe es schwer 

[Otto123]

Ich habe da mal wieder einen Fall 
https://forum.fhem.de/index.php/topic,83765.msg772548.html#msg772548

Und leider keinen Patch als Vorschlag 

[martinp876]

Sinnvoll ist tatsächlich immer eine vccu zu nutzen.
Ich habe leider immer noch nicht eingebaut, eine automatisch zu definieren.
Wäre sie immer da würde es den Anwender nicht verunsichern, eine definieren zu müssen.
Dann wäre alles viel klarer.