Hallo,
im Moment darf ein Reading, das mit userReadings angelegt wird, keinen Punkt im Namen haben, sonst wird das Reading silently ignored.
Das ist recht einfach zu beheben, indem in der entsprechenden RegEx der Punkt zugefügt wird (siehe Patch).
Was mit diesem Patch nicht behoben wird, ist, dass userReadings keine Fehlermeldung o.ä. ausgibt, wenn der Name nicht dem RegEx entspricht.
- my $regexi= '\s*([\w-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
+ my $regexi= '\s*([\w-\.]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
Ich weiss nicht genau was \w-\. macht, aber a- und a-z ist ein gewaltiger Unterschied.
Kannst Du das bitte pruefen?
Zitat von: rudolfkoenig am 28 September 2014, 11:24:26
Ich weiss nicht genau was \w-\. macht
Kannst Du auf http://regex101.com/ ausprobieren, da bekommst Du hervorragende Erklärungen bei der Analyse einer Regex:
[\w-\.]+ match a single character present in the list below
Quantifier: Between one and unlimited times, as many times as possible, giving back as needed [greedy]
\w match any word character [a-zA-Z0-9_]
- the literal character -
\. matches the character . literally
Punkte in readings und im devicenamen produzieren in einigen frontends Fehler. Vorschlad ist eher das "silently" beseitigen. Dann bleibt Punkt verboten und user weiß es ...
vg
jörg
Sollte man dann nicht vielleicht die Frontends fixen...? ;)
Den Vorschlag, die Punkte komplett zu verbieten, unterstütze ich uneingeschränkt.
Beim devicename wäre das sogar sehr simpel umsetzbar, da dort bereits eine Prüfung auf "nur erlaubte" Zeichen stattfindet (die z.B. Leerzeichen bereits verbietet).
Bei den Namen von Readings wird das schwierig. Denn nicht alle Module bzw. deren Entwickler benutzen dir readings*Update Funktionen, die dafür eigentlich vorgesehen sind. Immer dort, wo die Readings im Modul direkt angelegt bzw. geändert werden, kann eine zentrale Prüfung nicht greifen. Nichtsdestotrotz würde ich auch bei den readings*Update Funktionen eine Prüfung auf erlaubte Zeichen befürworten.
Zitat von: Creideiki am 28 September 2014, 13:50:21
Sollte man dann nicht vielleicht die Frontends fixen...? ;)
Das ist wie Kopfschmerztablette: Es bekämpft die Auswirkung, aber nicht die Ursache. Es gibt keinen sinnvollen Grund, Punkte in Namen von devices, readings und attributes zu verwenden.
Es gibt aus Anwendersicht aber auch keinen Grund, sie zu verbieten. Der einzige Grund, den ich sehe, ist, dass man bei RegEx etwas mehr aufpassen muss.
Zitat von: betateilchen am 28 September 2014, 13:50:31
Den Vorschlag, die Punkte komplett zu verbieten, unterstütze ich uneingeschränkt.
Beim devicename wäre das sogar sehr simpel umsetzbar, da dort bereits eine Prüfung auf "nur erlaubte" Zeichen stattfindet (die z.B. Leerzeichen bereits verbietet).
Dann muss man den Benutzer, die solche Namen verwendet haben, auch eine (am besten automatische) Migration zur Verfügung stellen.
Eine Meldung beim fhem-Start (sowohl im Frontend als auch im Logfile), dass in der bestehenden Konfiguration Namen existieren, die deprecated sind, würde im Rahmen einer angemessenen Übergangszeit dafür m.E. völlig ausreichen. Bei einem neuen fhem-Release kann man dann die Unterstützung abschalten.
Zitat von: betateilchen am 28 September 2014, 14:27:40
Eine Meldung beim fhem-Start (sowohl im Frontend als auch im Logfile), dass in der bestehenden Konfiguration Namen existieren, die deprecated sind, würde im Rahmen einer angemessenen Übergangszeit dafür m.E. völlig ausreichen. Bei einem neuen fhem-Release kann man dann die Unterstützung abschalten.
Du hättest ja brecht, wenn man von Benutzer ausginge, die sich mit Administration zumindest ein wenig beschäftigen (wollen/können). Diejenigen, die einmal pro Jahr Update machen, werden ganz schön laut aufschreien ;)
ZitatSollte man dann nicht vielleicht die Frontends fixen...? ;)
schon, aber: dummerweise verwenden browser Punkte in der dom-notation. Frameworks bauen darauf auf. Regex hat mit dem Punkt auf was eigenes vor. Wird ein mühsamer Weg denen allen das abzugewöhnen ;)
vg
jörg
Punkt ist z.Zt. auch im Namen von Geraeten erlaubt, und beim Attribute/Reading/Hash-Eintrag wird es explizit ausgewertet: falls es mit Punkt beginnt, dann wird es erstmal nicht angezeigt, es sei denn man setzt showInternalValues.
Ich habe deswegen den Patch von Creideiki hinzugefuegt.
Wenn wir Punkt verbieten wollen, dann brauche ich erstens konkrete Probleme, und eine Ueberlegung, wo ueberall es verboten werden soll. Eine Warnung fuer Readings koennte man leicht in CommandSetReading einbauen, das wird beim Einlesen der Konfiguration aufgerufen.
ich bin dagegen den punkt zu verbieten. es ist ein gutes trennzeichen und optisch sehr viel weniger aufdringlich als ein underscore.
neben dem punkt um die anzeige zu unterdrücken verwenden viele 1wire readings den punkt.
alte db und filelog einzräge warten auch erst mal nutzlos.
die ànderung wäre also auch tiefgreifender als nur eine warnung anzuzeigen. es wäre genau so ein schnellschuss mit zweifelhaftem nutzen wie er hier oft kritisiert wird.
ich denke es wäre besser zu dokumentieren welche zeichen wo erlaubt sind damit man es beim imentieren von schnittstellen oder frontends nicht vergisst.
gruß
andre
Die vorgenommene Änderung funktioniert scheinbar nicht korrekt.
http://forum.fhem.de/index.php/topic,27566.0.html
die regex ist falsch. (oder zumindest von der perl version abhängig)
so ist es korrekt:- my $regexi= '\s*([\w-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
+ my $regexi= '\s*([\w.-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';oder so:- my $regexi= '\s*([\w-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
+ my $regexi= '\s*([\w\-.]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
es gibt noch ein paar andere permutationen die korrekt sind.
in der original version muss das - nur deshalb nicht maskiert werden weil es das letze zeichen innerhalb der eckigen klammern ist. der vorschlag von oben hängt den . hinter das -. dadurch wird es zum range operator. also den . entweder vor das - oder das - maskieren damit es seine wörtliche bedeutung bekommt/behält.
den . muss man innerhalb der eckigen klammern nicht maskieren.
regex101.com ist hier auch falsch oder zumidest nicht streng genug.
Damit my $regexi= '\s*([\w.-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*'; ist die Warnung schon al weg....
my $regexi= '\s*([\w.-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
Diese Variante wurde wg. der Demokratischen Mehrheit uebernommen.
Ok, ich habe es diesmal auch _mit gesetzten userReadings_ getestet.
Man sieht, dass ich normalerweise kein userReadings verwende.
Hm, sehr seltsam... ich hatte das mit userReadings getestet und hat auch funktioniert. Aber ich muß zugeben, dass ich gleich die geänderte Reihenfolge hätte nehmen sollen. Ich habe mich da auch auf regex101.com verlassen.
Entschuldigung.