Hallo zusammen!
Mir ist aufgefallen das wenn Geräte zu lange Namen haben, dass diese abgeschnitten werden.
Bei Homematic ist mir das aufgefallen bei den Thermostaten die per Autocreate angelegt wurden und Channel wie z.B. Climate nur nich _Cli hießen.
SwitchTR beim Wandthermostat wurde zu _Sw usw usw.
Jetzt bei der Buderus KM200 ist es fast nicht möglich Plots anzulegen da es immer wieder zu Fehlern führt, Beispielsweise:
/system/sensors/temperatures/hotWater_t2 wird zu /system/sensors/temperatures/ho
Das hatte ich sowohl in der File Variante, als auch jetzt in ConfigDB. Ist da irgendwo eine Variable mit zu wenigen Zeichen hinterlegt?
Wäre super wenn da jemand Ansatzpunkte hätte wo man da nachschauen könnte. Ich bin in Perl noch nicht ganz so fit, lerne es aber gerade fleissig.
Grüße
Shax
ZitatMir ist aufgefallen das wenn Geräte zu lange Namen haben, dass diese abgeschnitten werden.
Wo denn? Ich kann es nicht nachvollziehen, mit einem Namen der Laenge 80+ habe ich kein Problem, gerade probiert.
Hier mal auf die schnelle ein Beispiel, das mit dem Wandthermostat kann ich erst später dokumentieren wenn ich mal wieder eins einbinde:
(http://www.ip-team.org/beispiel2.jpg)
Dort sieht man die Variablen abgeschnitten, das passiert auch bei den Wandthermostaten so (nicht nur bei Plots).
Ergänzung:
# $Id: fhem.pl 8192 2015-03-11 06:29:43Z rudolfkoenig $
# $Id: configDB.pm 7949 2015-02-12 22:04:09Z betateilchen $
# $Id: 00_CUL.pm 8176 2015-03-08 18:37:04Z martinp876 $
# $Id: 10_CUL_HM.pm 8175 2015-03-08 18:31:38Z martinp876 $
# $Id: 57_Calendar.pm 7701 2015-01-24 20:16:37Z borisneubert $
# $Id: 93_DbLog.pm 6573 2014-09-19 17:08:11Z tobiasfaust $
# $Id: 70_ENIGMA2.pm 8122 2015-03-01 14:26:30Z loredo $
# $Id: 01_FHEMWEB.pm 8097 2015-02-26 06:47:28Z rudolfkoenig $
# $Id: 98_JsonList.pm 5177 2014-03-09 16:16:17Z rudolfkoenig $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 8125 2015-03-01 16:54:09Z rudolfkoenig $
# $Id: 99_Utils.pm 7914 2015-02-08 11:14:10Z rudolfkoenig $
# $Id: 98_autocreate.pm 8138 2015-03-02 19:26:54Z rudolfkoenig $
# $Id: 98_configdb.pm 8012 2015-02-16 21:31:50Z betateilchen $
# $Id: 73_km200.pm 0042 2015-03-04 20:00:00Z Matthias_Deeke $
# $Id: 91_notify.pm 8165 2015-03-07 14:35:16Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 8158 2015-03-06 10:16:46Z justme1968 $
# $Id: 98_telnet.pm 8017 2015-02-17 11:10:16Z rudolfkoenig $
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $
Ich frage mich, warum du sie nicht einfach umbenennst?
Diese Werte kommen von der Heizung und sind teilweise noch deutlich länger. Ich kann das "Heizung:" davor umbenennen aber die Heizungsvariablen wüsste ich nicht das ich die einfach ändern kann.
Bei den Wandthermostaten hab ich natürlich die Channel wieder in die richtigen Namen (und kürzere, da standen so richtig lange HM-XXXXX-323454 usw), allerdings wollte ich den Fehler melden und nicht um ihn herumarbeiten ;)
Da ich das Problem mit einem FileLog als Quelle nicht nachstellen kann, vermute ich DbLog als Ursache.
DBLog kommt mit Beispiel-SQL Files. In denen ist die Länge der Device-Namen tatsächlich begrenzt auf 30 oder 60 Zeichen. Das lässt sich aber in der eigenen Installation sehr einfach anpassen, in dem man die Anzahl der möglichen Zeichen direkt in der DB erhöht, falls man tatsächlich nicht mit der Standardzeichenzahl zurecht kommt. Es handelt sich in der Spalte um den Datentyp VARCHAR. Dieser kann bis zu 255 Zeichen aufnehmen.
Da ich sehr fit mit MySQL bin, habe ich das als erstes gemacht. Leider keine Lösung des Problems. Es liegt scheinbar nicht an der MySQL.
Kann ich von configDB ohne weiteres auf file zurückmigrieren? Quasi so wie zu configDB hin? Dann teste ich es mal dort.
Zum Problem habe ich noch etwas hier im Forum gefunden:
http://forum.fhem.de/index.php?topic=22926.0
Dort wird geschrieben das 32 Zeichen bei der Entwicklung als ausreichend betrachtet wurden.
*** Update: Gerade die ConfigDB zurück zu File migriert. Mal sehen was nun passiert. Ich berichte.
configDB hat nichts mit DBLog zu tun.
Ich weiß schon was der Unterschied zwischen configDB und DBLog ist, ich habe es in beiden geändert. Es hat nichts bewirkt.
Übrigens: Filelog keine Probleme, nichts abgeschnitten. Der Fehler ist bei dem Datenbank Ding zu suchen. Ich habe die Zeichen dort auf 100 gesetzt gehabt und er hat sie trotzdem abgeschnitten...
Für mich ist das Problem gelöst, aber ich denke das der Fehler angegangen werden sollte. Da man bei so Dingen wie der Heizung nicht einfach die Variablen kürzen kann ist das eine starke Einschränkung.
ZitatIch habe die Zeichen dort auf 100 gesetzt gehabt und er hat sie trotzdem abgeschnitten...
Du hast nach der Änderung auch das Modul neu geladen?
So wie ich das sehe, ist die Spalte DEVICE bei der aktuellen DBLog Version auf 64 Zeichen begrenzt. Das reicht nicht?
Das ist übrigens kein Fehler. Works as designed.
Zitat von: Shax am 13 März 2015, 10:35:20
Für mich ist das Problem gelöst, aber ich denke das der Fehler angegangen werden sollte.
Die gleiche Diskussion haben vor längerem hier im Forum schon einmal geführt. Für mich ist das kein Fehler und ich habe derzeit keine Pläne, das in der configDB zu ändern. Und mir soll bitte auch niemand erzählen, dass man einen devicename nicht durch Umbenennen auf eine sinnvoll nutzbare Länge bringen kann.
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.
Reden wir hier nun eigentlich von Namen eines device oder von Namen eines readings?
Homematic Wandthermostate habe ich selbst im Einsatz, da wurde bisher nie etwas abgeschnitten.
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.
Zitat von: betateilchen am 13 März 2015, 10:58:57
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.
Dein Anfangspost und der Screenshot darin beantworten meine Frage nicht und sind überhaupt wenig hilfreich.
Zitat von: Shax am 13 März 2015, 11:01:39
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.
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":
model HM-TC-IT-WM-W-EU und wurden alle korrekt angelegt.
@betateilchen: gibt es einen Grund, warum die Laenge begrenzt wird?
@marvin78: mysql varchar darf laut Doku (http://dev.mysql.com/doc/refman/5.0/en/char.html) seit 10 Jahren 64k lang sein.
Zitat von: rudolfkoenig am 13 März 2015, 11:27:21
@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
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.
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.
Zitat von: rudolfkoenig am 13 März 2015, 12:15:27
allerdings sehr dafuer dass jeder (Modulautor und Anwender) nach Moeglichkeit verstaendliche aber darstellbare und kurze Bezeichner verwendet.
*unterschreib*
Zitat von: rudolfkoenig am 13 März 2015, 12:15:27
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.
Zitat von: rudolfkoenig am 13 März 2015, 12:15:27
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:
# 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++;
}
}
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.
In der Tat setze ich ein CUL ein und nutze das Modul CUL_HM.
Bei der Heizung setze ich das Modul KM200 ein. Dort wird aber alles richtig angezeigt, die Probleme tauchen erst bei Plots auf.
Hallo Zusammen
Zitat von: betateilchen am 13 März 2015, 10:56:48
Reden wir hier nun eigentlich von Namen eines device oder von Namen eines readings?
Von den Readings.. Zumindestens beim km_200 Modul.
Das km-200 Modul liest die Reading genau so aus wie ich sie auch als Reading darstelle.
Sie sind hierachisch aufgebaut und in anhand Ihres Namens direkt zu verstehen.
Siehe fhemwiki Buderus Web Gateway (http://www.fhemwiki.de/wiki/Buderus_Web_Gateway#Anhang_A_-_Liste_bekannter_Services)
Aus den Gruenden dass
a) Die Services noch laengst nicht alle entdeckt sind
b) Die Namen bereits jetzt schon gekuerzt sind: E.g.: hc1 = "heating circuit 1"
c) Die Namen in der jetzigen Form direkt verstaendlich sind
habe ich Vorbehalte diese Namensgebung zu aendern und ggf. durch einen kryptischen Code zu aendern e.g.: /heatingCircuits/hc1/heatingCurveSetting/decrement in 0881544711
Aus diesem Grunde moechte ich mich hiermit an die/den Entwickler des DbLog Moduls appellieren, doch einmal zu untersuchen ob ein Reading nicht bis auf die bereits erwaehnten 255 Zeichen ausdehnbar ist.
Sollte dies individuell machbar sein, so waere eine kleine Anleitung fuer die betroffenen User "erste Sahne".
Danke!
Gruss
Sailor
Alias Author des 73_km200 Moduls
Zitat von: Sailor am 14 März 2015, 21:03:31
moechte ich mich hiermit an die/den Entwickler des DbLog Moduls appellieren, doch einmal zu untersuchen ob ein Reading nicht bis auf die bereits erwaehnten 255 Zeichen ausdehnbar ist.
Das könnte man für neue DbLog Anwender wahrscheinlich problemlos umsetzen, es löst aber nicht das Problem, das Anwender, die jetzt schon mit DbLog arbeiten, bekommen können.
Da verschiedene Datenbanktypen eingesetzt werden können und nicht jede dieser Datenbanken ein "alter table" vollständig unterstützt, kann nicht einfach eine bestehende Datenbankdefinition geändert werden, ohne dass es dazu einer vollständigen Datenmigration bedarf. Und damit dürfte der eine oder andere Anwender, der DbLog "nur" benutzt, hoffnungslos überfordert sein.
Derzeit ist die Länge eines Readings in DbLog mit 64 Zeichen definiert.
Hallo betateilchen
Zitat von: betateilchen am 16 März 2015, 14:28:14
Das könnte man für neue DbLog Anwender wahrscheinlich problemlos umsetzen, es löst aber nicht das Problem, das Anwender, die jetzt schon mit DbLog arbeiten, bekommen können.
Da verschiedene Datenbanktypen eingesetzt werden können und nicht jede dieser Datenbanken ein "alter table" vollständig unterstützt, kann nicht einfach eine bestehende Datenbankdefinition geändert werden, ohne dass es dazu einer vollständigen Datenmigration bedarf. Und damit dürfte der eine oder andere Anwender, der DbLog "nur" benutzt, hoffnungslos überfordert sein.
Derzeit ist die Länge eines Readings in DbLog mit 64 Zeichen definiert.
OK verstanden. Und wie würde die Lösung für Jemanden lauten, der bereit ist die alte db zu löschen und mit einer neuen 255er .db Datei neu anzufangen.
Ich vermute, wir reden nur darüber die .db-Datei mit einer neuen Feldgröße neu anzulegen, oder müssen wir noch weiteres (in der fhem.cfg) modifizieren?
Gruss
Sailor
Sorry, aber ich bin doch für DbLog nicht zuständig. Deshalb kann (und will) ich Dir hier keine Änderungstipps geben.
Zitat von: betateilchen am 18 März 2015, 16:15:14
Sorry, aber ich bin doch für DbLog nicht zuständig. Deshalb kann (und will) ich Dir hier keine Änderungstipps geben.
OK, dann werde ich mal den Author anschreiben... Danke
Sailor