Fehler: Lange Namen

[Shax]

Ich will doch garnicht diskutieren. Allerdings kommen die Werte von der Heizung das hat nichts mit Devicenamen zutun.

Ein Beispiel: Heizung:/system/heatSources/hs1/nominalFuelConsumption <- Nur das Heizung ist von mir. Schon extra kurz gewählt.
Die Werte dieser Länge werden abgeschnitten, sind aber "nur" 54 Zeichen lang. Da muss irgendwas die Sache beschneiden. Kann natürlich auch im Ploteditor sein. Dort ist es mit bei der Heizung aufgefallen.

Bei den neuen Homematic Wandthermostaten passiert es übrigens bei jedem einbinden (autocreate) das die Channel gekürzt werden, da diese längere Namen haben.
Ich will hier niemandem auf die Füsse treten, ich wollte lediglich berichten was bei mir passiert ist. Bei der Filevariante auf die ich zurück gegangen bin habe ich nun keine Probleme mehr.

[betateilchen]

Reden wir hier nun eigentlich von Namen eines device oder von Namen eines readings?

[betateilchen]

Homematic Wandthermostate habe ich selbst im Einsatz, da wurde bisher nie etwas abgeschnitten.

[Shax]

Beides.

Es tritt bei mir bei den Heizungswerten auf wenn ich einen Plot erstellen will (Siehe Grafik die ich gepostet habe)
und bei den Namen des HM-TC-IT-WM-W-EU, wird dieser per Autocreate eingebunden muss man sich die Channelnamen nach der Kürzung des Devicenamens wieder zusammenbasteln. War für mich jetzt kein Problem, denke nur das einige da Probleme bekommen könnten und erstmal wild den Fehler suchen.

Das Gerät wird erstellt mit HM-TC-IT-WM-W-EU_XXXXX und die Channel heißen dann statt _Climate nur noch _Cli oder statt _SwitchTr nur _Sw.

Ich denke dort begrenzt etwas und der Autocreate erstellt dann halt mit der gekürzten Variante.

[Shax]

Homematic Wandthermostate habe ich selbst im Einsatz, da wurde bisher nie etwas abgeschnitten.

Eventuell die alten? Die neuen haben diese Kennung: HM-TC-IT-WM-W-EU
Also schon etwas länger. Ist bei mir bisher bei jedem aufgetreten.
Ich dokumentiere es gerne beim nächsten. Ich binde noch einige ein.

[betateilchen]

Dein Anfangspost und der Screenshot darin beantworten meine Frage nicht und sind überhaupt wenig hilfreich.

[betateilchen]

Das Gerät wird erstellt mit HM-TC-IT-WM-W-EU_XXXXX und die Channel heißen dann statt _Climate nur noch _Cli oder statt _SwitchTr nur _Sw.

Code Auswählen Erweitern


12345678911234567892123456789312
HM-TC-IT-WM-W-EU_XXXXX_SwitchTr


Das sind 31 Zeichen. Wenn nach Sw abgeschnitten wird, sind das nur 25 Zeichen - das hat mit der configDB m.E. nichts zu tun.
In der configDB ist ein deviceName mit maximal 32 Zeichen festgelegt, bei dieser Festlegung hatte ich mich damals an DbLog orientiert, wo die Länge identlsch festgelegt war. Readings und deren Länge interessieren die configDB nicht.

Und auch meine TC sind die "Neuen":

Code Auswählen Erweitern

model      HM-TC-IT-WM-W-EU

und wurden alle korrekt angelegt.

[rudolfkoenig]

@betateilchen: gibt es einen Grund, warum die Laenge begrenzt wird?
@marvin78: mysql varchar darf laut Doku seit 10 Jahren 64k lang sein.

[betateilchen]

@betateilchen: gibt es einen Grund, warum die Laenge begrenzt wird?

Das musst Du nicht mich fragen, ich habe mich an DbLog orientiert, da es für mich keinen Sinn machte, in der configDB Devicenamen mit einer größeren Länge zuzulassen, als sie von DbLog überhaupt geloggt werden können.

Ob Boris oder Tobias seinerzeit in DbLog einen Grund hatten - keine Ahnung.

Aber mal ehrlich - überlange Devicenamen sind doch irgendwann überhaupt nicht mehr sinnvoll verwendbar.
Irgendeine verbindliche Konvention, in der die die maximale Länge für device, reading und attribute festgelegt wird, hielte ich durchaus für sinnvoll.

Wo wir gerade beim Thema sind: Modultypen und Attributnamen sind in der configDB auf maximal 50 Zeichen begrenzt.


Lustig: noch ein Thread mit Längenproblem in DbLog: http://forum.fhem.de/index.php/topic,34969.0.html

[Shax]

Ich halte überlange Devicenamen auch für wenig Sinnvoll und habe sie auch umbenannt in deutlich kürzere.
Allerdings hatte der Autocreate die Channel dadurch zerhauen und wenn man gerade anfängt und nicht genau weiß wie
die heißen müssen dann ist das eine Hürde

Ich verstehe die Problematik schon, ich arbeite täglich mit Datenbanken, das war auch der Grund warum ich configDB und DBlog direkt genommen habe, da ich gerne auch Anbindungen programmiere und ich so deutlich einfacher an die Daten komme.

Ich bin wirklich begeistert wie hier gearbeitet wird und was jeder einzelne leistet. Ich werde wenn ich mich genug eingearbeitet habe auch meinen Teil beitragen. Programmieren ist nicht das Problem, nur erstmal alles verstehen und reinarbeiten.

[rudolfkoenig]

Code Auswählen Erweitern

Allerdings hatte der Autocreate die Channel dadurch zerhauen

Bevor das an autocreate kleben bleibt: autocreate zerhaut nix, sondern uebernimmt den Vorschlag vom meldenden Modul, in diesem Fall CUL_HM.

Ich bin eigentlich gegen eine vom FHEM generell erzwungene Laengenbegrenzung, allerdings sehr dafuer dass jeder (Modulautor und Anwender) nach Moeglichkeit verstaendliche aber darstellbare und kurze Bezeichner verwendet.

[betateilchen]

allerdings sehr dafuer dass jeder (Modulautor und Anwender) nach Moeglichkeit verstaendliche aber darstellbare und kurze Bezeichner verwendet.

*unterschreib*

[Shax]

Code Auswählen Erweitern

Allerdings hatte der Autocreate die Channel dadurch zerhauen

Bevor das an autocreate kleben bleibt: autocreate zerhaut nix, sondern uebernimmt den Vorschlag vom meldenden Modul, in diesem Fall CUL_HM.

Ich bin eigentlich gegen eine vom FHEM generell erzwungene Laengenbegrenzung, allerdings sehr dafuer dass jeder (Modulautor und Anwender) nach Moeglichkeit verstaendliche aber darstellbare und kurze Bezeichner verwendet.

Ich schließe mich dem an. Das macht absolut Sinn! Kurze Bezeichner sind gut und verwirren nicht unnötig.

[betateilchen]

Bevor das an autocreate kleben bleibt: autocreate zerhaut nix, sondern uebernimmt den Vorschlag vom meldenden Modul, in diesem Fall CUL_HM.

Soweit ich das sehe, werden die Channels von HM-Komponenten überhaupt nicht vom autocreate-Modul angelegt, sondern direkt in 10_CUL_HM.pm ab Zeile 5013:

Code Auswählen Erweitern


  # autocreate undefined channels
  my @chanTypesList = split(',',$culHmModel->{$mId}{chn});
  foreach my $chantype (@chanTypesList){
    my ($chnTpName,$chnStart,$chnEnd) = split(':',$chantype);
    my $chnNoTyp = 1;
    for (my $chnNoAbs = $chnStart; $chnNoAbs <= $chnEnd;$chnNoAbs++){
      my $chnId = $hash->{DEF}.sprintf("%02X",$chnNoAbs);
      if (!$modules{CUL_HM}{defptr}{$chnId}){
        my $chnName = $name."_".$chnTpName.(($chnStart == $chnEnd)?
                                '':'_'.sprintf("%02d",$chnNoTyp));
                               
        CommandDefine(undef,$chnName.' CUL_HM '.$chnId);
        $attr{CUL_HM_id2Name($chnId)}{model} = $md;
      }
      $attr{CUL_HM_id2Name($chnId)}{model} = $md;
      $chnNoTyp++;
    }
  }


[betateilchen]

Ich hab mal einen Bug eröffnet: https://git.fhem.de/bugzilla/show_bug.cgi?id=12

Mal schauen was Martin dazu meint (das Homematic Modul sehe ich als das Modul mit der größten Problemwahrscheinlichkeit in diesem Bereich)

Vielleicht sollte man der Frage nachgehen, welche Module für solche Probleme noch in Frage kommen und die Modulautoren darauf hinweisen.