Hallo,
leider funktioniert die Ersetzung mit dem Attribut stateFormat nicht, wenn im Readingname ein Doppelpunkt vorkommt. Wäre es möglich, die entsprechende Zeile in fhem.pl wie folgt abzuändern?
Statt
$st =~ s/\b([A-Za-z\d_\.-]+)\b/($r->{$1} ? $r->{$1}{VAL} : $1)/ge;
wäre folgendes hilfreich (\: eingefügt):
$st =~ s/\b([A-Za-z\d_\.\:-]+)\b/($r->{$1} ? $r->{$1}{VAL} : $1)/ge;
Das ist natuerlich moeglich, ich finde es nur etwas befremdlich, wenn im Namen weitere Sonderzeichen auftauchen.
Es gibt schon drei Zeichen zum trennen von Woertern im Readingnamen (siehe den alten Regexp), ich faende es gut aus Sicht der Benutzer, wenn nicht jedes Modul seine eigene Schreibweise findet. Es gibt jetzt schon die Syntax [device:readingname] (in DOIF bzw. in set), bei sowas wie [Lampe:dim:duration] waere ich als Benutzer verwirrt.
Ich lass mich aber gerne umstimmen.
Welche Module kamen auf diese Idee?
Das Problem tauchte gestern zuerst hier auf: http://forum.fhem.de/index.php/topic,45779.0.html und wurde dann in eine entsprechende Rubrik reproduziert.
Irgendwie wird das mit den device:reading Kombinationen immer unübersichtlicher. Man muss von Modul zu Modul überlegen, wie es jetzt gerade richtig wäre. Ein Problem, das es allerdings auch noch in anderen "Listen" gibt, die einmal mit Leerzeichen getrennt sind und andere, die mit einem Komma unterteilt werden.
Das irgendwann zu standardisieren fände ich irgendwie viel nützlicher, als immer mehr "zulässige" Syntaxkombinationen zu schaffen.
da es für die reading namen keine vorgaben bezüglich der erlaubten zeichen gibt und diese natürlich nicht überprüft werden kann es ganz schnell passieren das ein : in einen reading namen rutscht. ob es eine mac adresse ist oder ein windows pfad mit laufwerk, oder ... wenn möglich sollte man es aber da ändern.
beim konkreten stateFormat problem könnte man auch einfach auf die {...} perl variante mit ReadingsVal verweisen.
bei den unterschiedlichen trennzeichen für listen wäre es in der tat schön nur 1 (oder 2) varianten zu haben und nicht noch mehr. leider passen die rahmen bedingungen des jeweiligen moduls nicht immer dazu.
Da drei "gewichtige" Stimmen gegen die Aufname sprechen, kommt : bis auf Weiteres nichts ins Regexp.
Um den weiteren Wildwuchs der ReadingsNamen zu stoppen, moechte ich etwas dagegen tun. Alternativen:
- in readingsBeginUpdate
- in setstate
- eins der beiden kombiniert mit featurelevel
Faellt auch was besseres ein oder habt ihr Gegenaurgumente?
Mir geht es bei der Verwendung des Doppelpunkts darum, Werte aus der Homematic CCU in Homematic Namenskonvention darzustellen bzw. zu speichern. D.h.
Interface.DeviceAddress:ChannelNumber.Datapoint
Aber natürlich kann man sich auch andere Usecases wie z.B. die schon erwähnte Mac-Adresse, Windows Pfadnamen oder IPv6 Adressen vorstellen.
Wenn jetzt nachträglich Reglementierungen eingeführt werden, die einige Sonderzeichen verhindern, müssten ggf. diverse Module angepasst werden.
In HMCCU habe ich inzwischen einen Workaround eingebaut. D.h. stateFormat kann bleiben wie es ist. Kritischer wird es, wenn der : nicht mehr als Readingname verwendet werden darf.
Bzgl stateFormat kann man natürlich ReadingsVal benutzen, was aber bei einer Kombi mehrerer Readings schnell unübersichtlich und fehlerträchtig wird.
Zu Standadisierungen in Open Source Projekten: entweder man macht es von Anfang an, oder man lässt es. Nachträglich Standardisieren führt meist zu mehr Chaos als vorher.
ZitatAber natürlich kann man sich auch andere Usecases wie z.B. die schon erwähnte Mac-Adresse, Windows Pfadnamen oder IPv6 Adressen vorstellen.
Das sind wunderbare Beispiele dafuer, was _nicht_ ins Readings Name gehoert, sondern ins Wert.
ZitatWenn jetzt nachträglich Reglementierungen eingeführt werden, die einige Sonderzeichen verhindern, müssten ggf. diverse Module angepasst werden.
Das ist mir schon irgendwie klar, deswegen frage ich hier nach weiteren Meinungen.
Zitat von: rudolfkoenig am 18 Dezember 2015, 12:12:41
Das sind wunderbare Beispiele dafuer, was _nicht_ ins Readings Name gehoert, sondern ins Wert.
Jep, klassischer Denkfehler meinerseits. Dann bleibt eigentlich nur der Fall übrig, wenn ein Modul ein Gerät oder eine Schnittstelle einbindet, die bestimmte Sonderzeichen verwendet (wie im Fall Homematic).
wenn man z.b den freien plattenplatz als readings wert hat kann es schon passieren das der : im windows pfad als reading name auftaucht. entsprechende fälle lassen sich auch für die anderen beispiele konstruieren.
der : ist aber trotzdem ungeschickt weil er z.b. bei filelog und dblog probleme macht und bei dbblog nicht mit \x3a maskiert werden kann.
Zitat von: rudolfkoenig am 17 Dezember 2015, 17:26:20
bei sowas wie [Lampe:dim:duration] waere ich als Benutzer verwirrt.
Mische mich als Benutzer mal ein :):
Ja, dabei wäre ich sehr irritiert. Ich bin doch froh, wenn ich meinen Perl-/FHEM-Code zusammenbekomme. Treten dann noch solche Merkwürdigkeiten auf, dann sind Probleme vorgezeichnet (Regexp und Co.).
Mit der fehlenden Einheitlichkeit bei Listen (Komma, Leerzeichen usw.) habe ich auch regelmäßig meine Schwierigkeiten.
Einen "Wildwuchs-Stop" wünsche ich mir gerade als Benutzer. Selbst wenn es kurzzeitig zu Problemen wegen der Anpassungsbedürftigkeit von Modulen kommt, sollte es langfristig besser/einfacher werden. Die @/% - Abschaffungsthematik wird mittlerweile auch schon ruhiger und es war aus meiner Benutzersicht sehr sinnvoll, da ich mich nicht mehr mit @@ oder @,.. und drumherum beschäftigen muss.
Ohne Standardisierung wird es mMn immer undurchsichtiger. Darum könnt ihr ruhig Mut zur Standardisierung und zum "Zöpfe abscheiden" haben.
Zitat von: justme1968 am 18 Dezember 2015, 15:25:40
wenn man z.b den freien plattenplatz als readings wert hat kann es schon passieren das der : im windows pfad als reading name auftaucht. entsprechende fälle lassen sich auch für die anderen beispiele konstruieren.
der : ist aber trotzdem ungeschickt weil er z.b. bei filelog und dblog probleme macht und bei dbblog nicht mit \x3a maskiert werden kann.
Ja, da hast Du recht. Außerdem ist da noch betateilchens Argument mit der Verwendung des : als Trenner in DOIF. Da wären dann ggf. 2 oder mehr Doppelpunkte zu berücksichtigen mit vermutlich unvorhersehbaren Auswirkungen.
Ich denke ich werde in HMCCU den Doppelpunkt durch was anderes ersetzten.
Zitat von: krikan am 18 Dezember 2015, 15:50:56
Mit der fehlenden Einheitlichkeit bei Listen (Komma, Leerzeichen usw.) habe ich auch regelmäßig meine Schwierigkeiten.
Auch als Modul Autor steht man irgendwann an dem Punkt "wie setze ich es um".
Bsp bei meinem letzten Modul kann eine oder mehre Listen in einem Attribut übergeben werden, ich habe mich für die Version Listenname=n1,n2,n3<BLANK><nächste Liste> entschieden
attr name groupPorts TV=1,2 Media=4,5,6 oder wäre ein
attr name groupPorts TV=1 2,Media=4 5 6schöner/logischer gewesen ?
@Wzut
Ich denke ersteres wäre besser. Meine Meinung.
Mal so im allgemeinen, finde ich das gerade was Readingskonventionen an geht mehr Einheitlichkeit und vor allem Vorgaben besser wären. Und das ganze dann ins Wiki um Developeranfänger wie mir was in die Hand zu geben.
Grüße
@CoolTux , Zustimmung
Als ich in meinem ersten Modul z.B. die Einheiten mit in den Readingswerten hatte haben mich die Betatester fast ans Kreuz genagelt frei nach dem Motto "die haben in Reeadings nichts zu suchen,die machen nur die Weiterverarbeitung unnötig schwer" und dabei fand ich das so hübsch ..... :)
Allerdings habe ich mich überzeugen lassen und wäre heute selbst froh wenn alle Entwickler sich auch daran halten würden.
readingNames: ab sofort wird in setstate (was zum Einlesen der statefile, und setzen von Readings) verwendet wird, der reading Name auf A-Za-z\d_\.- geprueft, und eine Warnung ausgegeben, falls er auch andere Zeichen enthaelt.
Ich musste mich selbst an der Nase fassen: das FHT Modul generiert beim aktivierten FHT-Debugging in culfw reading Namen wie FHT:ack. Ich habe das so geloest, das in FHT->StateFn das Reading in FHT_ack umbenannt wird, und das Umbennen dem Benutzer mitgeteilt wird.
@WZut: bei den Attributen wuerde ich auch zum Trennen per Leerzeichen tendieren. Zum splitten koennte man die Funktion attrSplit() aus fhem.pl verwenden, was nach Leerzeichen trennt, es sei denn, das erste Zeichen ist , oder /.
Wird von eventMap verwendet. Wenn jemandem eine deutlich bessere Loesung einfaellt, dann kann man das zentral aendern.
Hallo Rudi,
Das finde ich eine gute Lösung. Das betrifft aber nur die Namen der Readings? Richtig? Nicht deren Inhalt?
Ist das jetzt fest, dann würde ich versuchen das im Wiki im Developerbereich irgendwo fest zu halten.
Grüße
Ich kenne jemanden, dem es dieses Wochenende (und vermutlich über Weihnachten) mit Sicherheit nicht langweilig werden wird...
2015.12.19 19:05:35 3: WARNING: unsupported character in reading .RegL_00: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:35 3: WARNING: unsupported character in reading .RegL_07: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:35 3: WARNING: unsupported character in reading .RegL_01: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:35 3: WARNING: unsupported character in reading .RegL_07: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:36 3: WARNING: unsupported character in reading .RegL_01: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:36 3: WARNING: unsupported character in reading .RegL_01: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:36 3: WARNING: unsupported character in reading .RegL_01: (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
2015.12.19 19:05:36 3: WARNING: unsupported character in reading .RegL_03:self01 (not A-Za-z\d_\.-), notify the CUL_HM module maintainer.
Das ist nur ein Auszug aus meinem Startup-Log, da kommen diese Meldungen seitenweise...
Da habe ich mit meiner naiven Anforderung was ausgelöst ::)
Wenn wir gerade dabei sind: Devicenames dürfen Doppelpunkte enthalten. Wie reagieren Module wie DOIF oder auch das Attriubt userReadings darauf? Da werden die Doppelpunkte ja für Trennung zwischen Device und Reading verwendet.
@Rudi
Möchtest Du deine Änderung nicht besser erst nach den Feiertagen und dem Jahreswechsel in Umlauf bringen? Du würdest damit vermutlich dem einen oder anderen Entwickler unnötigen Streß in den nächsten Tagen durch hier im Forum auftauchende "Ich hab da eine Fehlermeldung im Log"-Threads von ahnungslosen Anwendern ersparen.
Grundsätzlich finde ich Deine angedachte Änderung SUPER!
Ok, auskommentiert. Kanns sich jemand bitte hier nach dem 1.1 melden?
ZitatDevicenames dürfen Doppelpunkte enthalten.
Muesste logischerweise dann auch bemaengelt werden. Andere Meinungen?
Zitat von: rudolfkoenig am 19 Dezember 2015, 21:06:17
Ok, auskommentiert. Kanns sich jemand bitte hier nach dem 1.1 melden?
Ja, ich werde dich dran erinnern :)
Zum Thema Devicenamen mit Doppelpunkten: Wenn ich ich recht erinnere, gab es schonmal eine angeregte Diskussion hier im Forum zu dieser Thematik. Da ging es entweder um devicenamen oder deren Länge - ich muss mich mal auf die Suche machen. Grundsätzlich finde ich Sonderzeichen auch in devicenames und in attributen grenzwertig.
Zitat von: rudolfkoenig am 19 Dezember 2015, 21:07:36
Muesste logischerweise dann auch bemaengelt werden. Andere Meinungen?
Im Gegenteil -> Zustimmung!
vg
joerg
ebenfalls Zustimmung
Auch hier Zustimmung. Für Devicenamen und Attribute sollte die gleiche regexp zur Prüfung auf ungültige Chars gelten wie in diesem Thread für readings vereinbart wurde.
Gruß
Markus
Zitat von: Markus Bloch am 20 Dezember 2015, 10:58:57
Auch hier Zustimmung. Für Devicenamen und Attribute sollte die gleiche regexp zur Prüfung auf ungültige Chars gelten wie in diesem Thread für readings vereinbart wurde.
Gruß
Markus
Ebenfalls Zustimmung, die "identifier" sollten soweit möglich einheitlichen Regeln gehorchen.
Ich finde insgesamt die Initiativen gut einiges an "Wildwuchs" wieder einzufangen gut, auch wenn der eine oder ander Benutzer auf die Nase fällt. Auf längere Sicht hilft es allen, wenn einheitliche Abgrenzungen, Trennzeichen und "special character" verwendet werden können.
Zitat von: viegener am 20 Dezember 2015, 21:56:03
Ebenfalls Zustimmung, die "identifier" sollten soweit möglich einheitlichen Regeln gehorchen.
Ich finde insgesamt die Initiativen gut einiges an "Wildwuchs" wieder einzufangen gut, auch wenn der eine oder ander Benutzer auf die Nase fällt. Auf längere Sicht hilft es allen, wenn einheitliche Abgrenzungen, Trennzeichen und "special character" verwendet werden können.
Bei den Devicenames gibt es ja bereits ein zulässiges Set an Zeichen. FHEM zeigt die zulässigen Zeichen an, wenn man bei define ein unzulässiges eingibt. Der Doppelpunkt wird als zulässiges Zeichen angezeigt. Leider hat aber der ein oder andere Modulautor den Doppelpunkt als Trenner zwischen Device und Reading verwendet. Daraus könnte sich so was ergeben:
DevicenameTeil1:DevicenameTeil2:Reading
Das könnte z.B. bei DOIF oder auch userattr zu Problemen führen.
Damit will ich sagen, dass es zwar einfach ist, für Device- oder Readingnames einen Standard festzulegen, aber schwierig, die Modulautoren dazu zu bringen, diese Regeln zu beachten.
Zitat von: zap am 21 Dezember 2015, 12:53:47
Damit will ich sagen, dass es zwar einfach ist, für Device- oder Readingnames einen Standard festzulegen, aber schwierig, die Modulautoren dazu zu bringen, diese Regeln zu beachten.
Nö, das ist ganz einfach. Wenn man die Zeichen nicht mehr zulässt, werden die devices nicht mehr angelegt. Aufgrund der dann hier im Forum zu erwartenden Tread-Flut werden die betroffenen Modulautoren nicht umhinkommen, das anzupassen.
Allerdings würde ich dafür plädieren, solche grundlegenden Änderungen generell mit einer vierwöchigen Vorlaufzeit anzukündigen, um genau diesem Thread-Storm zu entgehen.
In den AGB von technischen Geräten finden sich solche Änderungen immer hinter dem Satz "Änderungen, die dem technischen Fortschritt dienen, bleiben ausdrücklich vorbehalten und können ohne Ankündigung erfolgen.". Auch bei fhem sehe ich durchaus einen Fortschritt, wenn wir durch eine solche Änderungen einen technischen Fortschritt im Sinne einer einfachen, logischen und nachvollziehbaren Standardisierung erreichen.
Zitat von: zap am 21 Dezember 2015, 12:53:47
Bei den Devicenames gibt es ja bereits ein zulässiges Set an Zeichen. FHEM zeigt die zulässigen Zeichen an, wenn man bei define ein unzulässiges eingibt. Der Doppelpunkt wird als zulässiges Zeichen angezeigt. Leider hat aber der ein oder andere Modulautor den Doppelpunkt als Trenner zwischen Device und Reading verwendet. Daraus könnte sich so was ergeben:
Damit will ich sagen, dass es zwar einfach ist, für Device- oder Readingnames einen Standard festzulegen, aber schwierig, die Modulautoren dazu zu bringen, diese Regeln zu beachten.
Mein Hinweis sollte eigentlich sagen: Alle "identifier" sollten soweit möglich einheitlichen Regeln gehorchen. Damit meinte ich Readings, Attribute, Devicenamen, Optionen für set/get usw. Dann ist es auch einfacher eindeutige Trennzeichen zu erzeugen. Für mich hat der Doppelpunkt in einem "Identifier" nichts zu suchen und der Doppelpunkt wird ja auch für die notify-Syntax verwendet.
Ja bei sovielen Modulautoren wird das mit den Regeln immer etwas schwierig, deshalb sind solche (auch nachträglichen) Vereinheitlichungen ja gut. Und wie man an der 5.7 sieht es beruhigt sich schon wieder...
Zitat von: rudolfkoenig am 19 Dezember 2015, 21:07:36
>>Devicenames dürfen Doppelpunkte enthalten.
Muesste logischerweise dann auch bemaengelt werden. Andere Meinungen?
just to avoid misunderstandings
$hash->{NAME}
should avoid strange characters
$hash->{DeviceName}
should be allowed to use special char e.g. /dev/ttyACM0@57600 or 10.0.2.2:5444
It's about the name of identifiers (readings, attributes, set/get commands, ....), not their values. So $hash->{DeviceName} can still contain an @ as Part of their value.
thanks
Zitat von: betateilchen am 21 Dezember 2015, 13:10:57
Nö, das ist ganz einfach. Wenn man die Zeichen nicht mehr zulässt, werden die devices nicht mehr angelegt. Aufgrund der dann hier im Forum zu erwartenden Tread-Flut werden die betroffenen Modulautoren nicht umhinkommen, das anzupassen.
Allerdings würde ich dafür plädieren, solche grundlegenden Änderungen generell mit einer vierwöchigen Vorlaufzeit anzukündigen, um genau diesem Thread-Storm zu entgehen.
In den AGB von technischen Geräten finden sich solche Änderungen immer hinter dem Satz "Änderungen, die dem technischen Fortschritt dienen, bleiben ausdrücklich vorbehalten und können ohne Ankündigung erfolgen.". Auch bei fhem sehe ich durchaus einen Fortschritt, wenn wir durch eine solche Änderungen einen technischen Fortschritt im Sinne einer einfachen, logischen und nachvollziehbaren Standardisierung erreichen.
Udo, you are right.
but there may a more impacting consequence on top:
if some user has device names which will be made invalid by the change, and he or she made a restart, the device will not be defined any more because of that invalid characters. So a following "save" will overwrite the existing config and this device will be lost.
There should be a long warning period with clearly visible and multiple user warnings. May be some type of auto-rename or so.
Again: I assist to do that change.
regards
joerg
Zitat von: herrmannj am 21 Dezember 2015, 21:46:27
Udo, you are right.
but there may a more impacting consequence on top:
if some user has device names which will be made invalid by the change, and he or she made a restart, the device will not be defined any more because of that invalid characters. So a following "save" will overwrite the existing config and this device will be lost.
There should be a long warning period with clearly visible and multiple user warnings. May be some type of auto-rename or so.
Again: I assist to do that change.
regards
joerg
Would it be an idea to check PRE-update on any mismatches to the new policy? Could be done as part of the update check?
Wäre es denkbar vor dem update auf Probleme zu den neuen Regeln hinzuweisen, vielleicht als Teil des udpate check?
Zitat von: viegener am 21 Dezember 2015, 23:18:34
Would it be an idea to check PRE-update on any mismatches to the new policy? Could be done as part of the update check?
Wäre es denkbar vor dem update auf Probleme zu den neuen Regeln hinzuweisen, vielleicht als Teil des udpate check?
Ich denke so etwas in der Art wäre optimal. Vielleicht hat Rudi eine Idee.
Mein Vorschlag wäre eine 99er Datei dafür (die ja nach einem Neustart ausgeführt wird). Die könnte den Check durchführen und MOTD + LOG entsprechend setzen. Mit so einer Konstruktion könnte man generell Punkte checken die depraced sind und Meldungen dazu erzeugen.
Wenn die im SVN liegt würde die ja mit einem update automatisch verteilt und gestartet, oder liege ich da falsch ?
vg
joerg
mal so als hinweis:
es gibt dafür extra ein modul: notice (http://fhem.de/commandref.html#notice). das hatte ich seinerzeit im zuge des rewrites der update und fheminfo module mitentwickelt.
es müsste nur von den entwicklern angewendet werden ;)
Ich will zunaechst nur eine Warnung beim Starten ausgeben, genauso wie beim Reading.
Evtl. kann die Warnung beim Wechsel auf 5.8 dann verschaerft werden.
Eventuell könnte man auch einen Verweis auf den entsprechenden Forums-Thread (bspw. "Forum #45788") direkt in der Warnmeldung mit angeben.
Damit hat dann auch der Benutzer sofort eine erklärende Anlaufstelle für die gerne mal als Fehlermeldung interpretierten Warnmeldungen im Log, bzw. beim Start ;)
Nur mal als Anregung:
Für "security" Warnungen wird doch die motd Angepasst. Kann für eine Warnung bezüglich solcher "Änderungen" es nicht auch erfolgen?
So bekommen mehr "User" es mit (hoffentlich) und können reagieren
bei den reading namen bin ich etwas hin und her gerissen. bestimmte zeichen wie der : machen probleme und sollten deshalb verboten werden.
aber so lange die reading namen auch direkt angezeigt werden ist nur a-z zu haben aber eigentlich zu wenig. keine umlaute, keine kyrillischen oder sonstigen zeichen um fhem auch im nicht deutschsprachigen raum zu verwenden. von so einfachen dingen wie 'Außentemperatur' und ähnlichem ganz zu schweigen.
das 'projekt' mit einheiten und standardisierten namen liegt ja erst mal wieder auf eis und nicht jeder möchte eine readingGroup verwenden um readings in seiner sprache anzuzeigen. aber wir leben im 21 jahrhundert und es gibt utf-8 und jeder rechner sollte in der lage sein im user interface nicht nur 7bit ascii anzuzeigen.
Vielleicht könnte man ja statt einer Positiv- eine Negativliste verwenden? Also nur auf Zeichen prüfen, die nicht erlaubt sind/sein sollen.
ich glaube das wäre die bessere variante. vor allem da fhem untern zwar utf-8 verwendet aber als byte sequenz utf-8 bzw. \w und regex je nach perl version probleme macht.
Zitat von: betateilchen am 22 Dezember 2015, 11:19:38
Vielleicht könnte man ja statt einer Positiv- eine Negativliste verwenden? Also nur auf Zeichen prüfen, die nicht erlaubt sind/sein sollen.
Es wäre dann aber wichtig alles jenseits ASCII mitauszuschliessen, sonst haben wir Smilies in den Readingnamen für freundliche Werte ;)
ascii ist ja eben nicht genug wenn es mehr als nur deutsch sein soll. und sogar für deutsch nicht wenn man umlaute & co erlaubt.
Zitat von: betateilchen am 22 Dezember 2015, 11:19:38
Vielleicht könnte man ja statt einer Positiv- eine Negativliste verwenden? Also nur auf Zeichen prüfen, die nicht erlaubt sind/sein sollen.
Ja durchaus. Was ich da als relevant für die Negativliste sehe sind folgende Zeichen:
[ ] { } ( ) , . : ; * + ? \ / @ % $ ^
bis auf . und / finde ich das gut. der . macht keine probleme und wird an vielen stellen verwendet. das gleiche gilt für /.
Nunja der Punkt eigentlich um Verwechslungen und Missgeschicke bei Regexp-Prüfungen zu vermeiden.
Der Slash mag sein, dass er keine Probleme macht, aber mal ehrlich, was hat der in einem Identifier zu suchen?
der punkt ist ideal um hierarchisch zu trennen. dazu wird er viel verwenden. der slash taucht z.b. beim plattenplatz überwachen auf.
Ich denke das Semikolon sollte auch eher ausgeschlossen werden.
Dafür verstehe ich wenn man den Punkt als Strukturierungselement erhalten möchte.
Das mit den non-ASCII-Zeichen sollte aber gut überlegt werden, das mit den Smilies ist ja nur als Witz gedacht, aber schon die Umlaute bereiten immer wieder Probleme, da wir immer wieder auch mit externen Systemen kommunizieren, die zum Teil sehr eigenwillige Vorstellungen haben (Perl selbst hat gelegentlich schon eigenwillige Meinungen über den Inhalt von Strings).
Wie wäre es generelle Unicodezeichen (non-Ascii) nicht explizit auszunehmen aber nicht für Identifier zu empfehlen?
Stimmt, dass Semikolon hatte ich nur vergessen, ist aber auch meine Meinung das auszuschließen (wegen Kommando-Verkettungen).
Daher nochmal mein Vorschlag:
[ ] { } ( ) , . : ; * + ? \ / @ % $ ^
Na so trivial ist es mit der Negativliste auch nicht. Tipp mal "man ascii" in einem shell-Fenster, und ueberlege fuer alle angezeigten Character, ob es in einem Device-,Reading-, oder Attributnamen sinnvoll waere. Ich finde auf Anhieb noch nul-bis-space ! " # & ' < > = ` | ~
Wenn wir Umlaute wollen, kommt die nicht zu unterschaetzende Umstellung auf interne UTF Darstellung dazu, d.h. alle Schnittstellen, die interne IDs nach "aussen" kommunizieren, eine Konvertierung durchfuehren muessen, sonst faellt gzip/write/etc auf die Nase. Bisher fahren wir die entgegengesetzte Strategie: alles was reinkommt, muss nach "ein-Byte" Zeichen konvertiert werden, und alles was rausgeht, ist egal.
Bisher gab es fuer Devicenamen ein alias Attribut, und Reading/Attribut war nicht begrenzt.
Wenn wir anfangen zu begrenzen, dann bleibt Reading/Attribut zunaechst aussen vor.
NUL würde ich auschliessen, auch wenn es perl ist und nicht C ;D
Im Ernst, Du hast völlig Recht, die Liste muss wohl noch erweitert werden (was dann auch wieder die Frage stellt, ob eine Positivliste nicht besser wäre). Also hier man der Versuch einer vollständigen (ASCII-)Liste, mit Info was erlaubt sein könnte --> unten:
Bei einigen bin ich mir sehr unsicher, ob es potentiell nicht doch erlaubt sein sollte (z.B. warum kein $ oder @).
Ausserdem die Frage, ob es noch einen Unterschied zwischen dem ersten Zeichen und dem Rest geben sollte (viele Sprachen machen da einen Unterschied)...
HEX 00-20 / NUL bis SPACE - NEIN
HEX 21 - ! - ??
HEX 22 - " - NEIN
HEX 23 - # - NEIN
HEX 24 - $ - NEIN
HEX 25 - % - NEIN
HEX 26 - & - ??
HEX 27 - ' - NEIN
HEX 28/29 - () - NEIN
HEX 2A - * - ??
HEX 2B - + - ??
HEX 2C - , - NEIN
HEX 2D - - - NEIN
HEX 2E - . - JA
HEX 2F - / - ??
HEX 30-39 - 0-9 - JA
HEX 3A - : - NEIN
HEX 3B - ; - NEIN
HEX 3C - < - NEIN
HEX 3D - = - NEIN
HEX 3E - > - NEIN
HEX 3F - ? - NEIN
HEX 40 - @ - ??
HEX 41-5A - A-Z - JA
HEX 5B - [ - NEIN
HEX 5C - \ - NEIN
HEX 5D - ] - NEIN
HEX 5E - ^ - ??
HEX 5F - _ - JA
HEX 60 - ` - NEIN
HEX 61-7A - a-z - JA
HEX 7B - { - NEIN
HEX 7C - | - NEIN
HEX 7D - } - NEIN
HEX 7E - ~ - ??
HEX 7F - DEL - NEIN
Ich würde den "." nicht erlauben. Er wird in Regexp verwendet ... sonst müssen wir anfangen, dort mit Quotas zu arbeiten...
Aus den gleichen Gründen auch Zeichen wie "*"
Zitat von: rudolfkoenig am 23 Dezember 2015, 13:47:39
Wenn wir anfangen zu begrenzen, dann bleibt Reading/Attribut zunaechst aussen vor.
äh... darf ich daran erinnern, dass wir hier ursprünglich über readings diskutierten und der Vorschlag der Ausweitung auf device und attribute danach aufkam?
Zitat von: Wernieman am 23 Dezember 2015, 14:17:48
Ich würde den "." nicht erlauben. Er wird in Regexp verwendet ... sonst müssen wir anfangen, dort mit Quotas zu arbeiten...
Aus den gleichen Gründen auch Zeichen wie "*"
Kannst Du mir auf die Sprünge helfen? Mir fällt gerade kein Fall ein, wo Namen von devices etc als Regexp verwendet werden? Wenn man nach einem Devicenamen etc in einem Ausdruck sucht, würde ich schon heute eher Index verwenden, denn es kann ja heute nicht ausgeschlossen werden.
??
Wenn ich bei mir z.B. bei den Logfiledefinitionen nachschaue:
./log/MacFritzboxLog-%Y.log Fritzbox:mac_.*
Wenn jetzt in "Fritzbox", welches ein Device ist, ein "." enthalten währe, also z.B.
Fritz.box:mac_.*
Würde dieses auf alles matchen, wie z.B. Fritz-box, Fritz1box, Fritz2box .. ohne das einem 0815-User es bekannt ist.
Oder habe ich es jetzt falsch verstanden?
Sollte der . in Devicenamen verboten werden, ist hier wohl die Hölle los. Alleine deshalb:
http://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html (http://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html)
Ich sehe da auch keinerlei Problem. Wenn man mit Regexp arbeitet, sollte auch 0815-User sich informieren, wie das geht.
Zitatsollte auch
Genau dort sehe ich das Problem ;o)
Zitat von: Wernieman am 23 Dezember 2015, 15:20:01
Wenn ich bei mir z.B. bei den Logfiledefinitionen nachschaue:
./log/MacFritzboxLog-%Y.log Fritzbox:mac_.*
Wenn jetzt in "Fritzbox", welches ein Device ist, ein "." enthalten währe, also z.B.
Fritz.box:mac_.*
Würde dieses auf alles matchen, wie z.B. Fritz-box, Fritz1box, Fritz2box .. ohne das einem 0815-User es bekannt ist.
Danke, das hilft! Ich hatte nur aus Modulsicht gedacht und dabei war mir kein Fall geläufig. Wobei das Problem jetzt auch bei Events (und anderen Stellen) auftreten könnte. Damit haben gibt es eigentlich schon jetzt ein Problem für die Nutzer.
ich finde diesen fall nicht kritisch.
zum einen ist der fall nicht häufig (sonst würde das jetzt schon probleme machen) und zum anderen matched es im problemfall auf zu viele devices. was dann recht schnell sichtbar ist und man kann fragen und helfen.
schlimm wäre es wenn es auf zu wenig devices matchen würde oder devices nicht sichtbar sind.
Auch wenn es jetzt "Klinisch" scheint, aber wie soll der User ein Regex für "Fritz.box", in meinem Beispiel, realisieren?
Fritz\.box
der knackpunkt ist ja der das das problem nur auftritt wenn er ein Fritz.box und ein Fritz1box hat und im notify nur auf eine von beidem reagieren möchte.
wenn er eine Fritz.box hat und sonst nichts gibt es kein problem. wenn er eine Fritz1box und Fritz2box hat die er getrennt anspricht hat er kein problem. wenn er beide ansprechen will hat er auch kein problem.
O.K. Quoten geht also ....... blöde Frage: Gibt es dazu einen Eintrag im Wiki??
Zitat von: Wernieman am 23 Dezember 2015, 15:35:41
Genau dort sehe ich das Problem ;o)
Ich nicht wirklich.
Zitat von: Markus Bloch am 23 Dezember 2015, 13:20:10
Stimmt, dass Semikolon hatte ich nur vergessen, ist aber auch meine Meinung das auszuschließen (wegen Kommando-Verkettungen).
Daher nochmal mein Vorschlag:
[ ] { } ( ) , . : ; * + ? \ / @ % $ ^
Veto...
OWServer sowie OWDevice nutzt '/' und '.' dient oftmals als Abgrenzung. Alle meine Definitionen (>550) in meiner FHEM Hauptinstanz nutzen im Devicenamen einen '.'. In einigen Modulen, wie auch in anderen eigenen Funktionen tauchen diese zum Teil auch in den Readings auf.
Zitat von: marvin78 am 23 Dezember 2015, 15:23:57
Sollte der . in Devicenamen verboten werden, ist hier wohl die Hölle los. Alleine deshalb:
http://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html (http://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html)
Ich sehe da auch keinerlei Problem. Wenn man mit Regexp arbeitet, sollte auch 0815-User sich informieren, wie das geht.
;)
verwende ebenfalls Punkte um zu trennen.
In der Praxis scheint es auch im allgemeinen (der Allgemeinheit :-) keine Probleme damit zu geben - oder ?
vg
joerg
es gibt nur einen einzigen fall in dem es probleme macht. alles andere geht mehr oder weniger gut: http://forum.fhem.de/index.php/topic,45788.msg378825.html#msg378825 (http://forum.fhem.de/index.php/topic,45788.msg378825.html#msg378825)
Bei so wenig Problemen sehe ich auch keinen Grund den Punkt zu entfernen. Ausserdem gibt es immer noch die Möglichkeit, das auch für die Benutzer zu erklären.
Vielleicht kann man ja sogar noch einige von den anderen Zeichen erlauben?
Zitat von: rudolfkoenig am 19 Dezember 2015, 21:06:17
Ok, auskommentiert. Kanns sich jemand bitte hier nach dem 1.1 melden?
*ERINNERUNG*
Die Warnung bei : im Readingsnamen ist in setstate scharfgeschaltet, Benutzer kriegen also nach einem Neustart eine Warnung.
Bei : im Devicenamen wird ein "interaktives" define abgelehnt, beim Einlesen aus der fhem.cfg wird nur eine Warnung generiert.
In TcpServerUtils wurde bisher nach dem Accept ein device mit dem Namen $type:$caddr:$port angelegt, das habe ich jetzt ordnungshalber auf ${name}_${caddr}_${port} geaendert. Ich hoffe, dass das keine Probleme verursacht, sicher bin ich aber nicht.
Weitere Sachen wie Umlaute schauen wir erst, nachdem diese Aenderung abgeklungen ist.
Vielleicht wäre es sinnvoll, diese Änderung unter "Ankündigungen" zu dokumentieren. Auch auf die Gefahr hin, dass es dort übersehen wird, ist es zumindest nicht in einem mehreren Seiten langen Thread - so wie jetzt gerade - untergegangen.
Erledigt, und dabei eine Weile mit "keine Smileys benutzen" gekaempft, es funktioniert im Vorschau nur halb.
Zitat von: rudolfkoenig am 03 Januar 2016, 14:50:58
es funktioniert im Vorschau nur halb.
wie einiges anderes an dieser Forumsoftware auch *lach*
Zitat von: Martin Fischer am 23 Dezember 2015, 22:28:00
Veto...
Veto!
Es kommen schon die ersten Probleme: http://forum.fhem.de/index.php?topic=46745 (http://forum.fhem.de/index.php?topic=46745)
Und Nu?
wie oben schon geschrieben: ich wüsste nicht warum ein / probleme machen sollte. er wird auch noch an anderen stellen gebraucht. ich würde ihn erlauben.
Habe / zu den erlaubten Buchstaben bei Readingnamen hinzugefuegt.
Sorry, bin etwas durcheinander, wer was will, und was Konsens ist.
Hallo Rudi,
Deine Warnungen im log sind inzwischen bei mir aufgeschlagen
http://forum.fhem.de/index.php/topic,46718.0.html
Ich nutze in statistics den Doppelpunkt, um ein verstecktes Reading aus dem Gerätenamen und dem Gerätewert zu erzeugen. Der Doppelpunkt war für mich das einzige sichere Zeichen, das nicht in Geräten oder Readings vorkommt. Mir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.
Gibt es eine Zusammenfassung in der wiki anhand der ich verstehen kann, was die neuen Restriktionen für Modulautoren sind? Evtl. Auch warum.
Wenn nicht, wäre es möglich eine zu schreiben?
Gruss tupol
Zitat von: tupol am 04 Januar 2016, 23:56:07
Ich nutze in statistics den Doppelpunkt, um ein verstecktes Reading aus dem Gerätenamen und dem Gerätewert zu erzeugen. Der Doppelpunkt war für mich das einzige sichere Zeichen, das nicht in Geräten oder Readings vorkommt. Mir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.
wegen: http://sourceforge.net/p/fhem/code/10208/
siehe dazu auch die commandref zu devspec.
Gruß
Markus
ZitatMir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.
Zu "Mir ist jetzt nicht klar": Das ist genau hier in diesem Thread zu lesen.
Zu "ploetzlich": In meinen "Belehrungen" nach der Erteilung der SVN-Schreibberechtigung steht
Zitat- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
Beim Entfernen des Doppelpunkts habe keine Gegenargumente gehoert, nur "Zustimmung".
Sorry, ich hatte gerade Tomaten auf den Augen: Fuer Internalvalues gibt es keine Einschraenkungen, nur fuer Readings.
Zitat von: rudolfkoenig am 05 Januar 2016, 08:26:36
Zu "ploetzlich": In meinen "Belehrungen" nach der Erteilung der SVN-Schreibberechtigung steht
- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
Beim Entfernen des Doppelpunkts habe keine Gegenargumente gehoert, nur "Zustimmung".
Also ich habe beide Foren abonniert. Nur konnte ich in "Developer" nichts dazu finden.
Zudem ist das mit dem Abonnieren etwas vertrackt. Ich werde mit Emails geflutet, wenn ich mich per Email benachrichtigen lasse. Es gibt keine Möglichkeit, sich
nur über neue Themen per Email benachrichtigen zu lassen. So wie ich es verstehe, geht Deine derzeitige "Belehrung" davon aus, dass man entweder die Email-Benachrichtigung einschaltet oder ständig die Foren nach relevanten Themen bzw. Antworten durchsucht. Beides kann ich nicht bewerkstelligen.
Es wäre für mich einfacher mitzuarbeiten, wenn es eine Möglichkeit gibt, sich in größeren Abständen gezielt über vorgeschlagene Änderungen am
Framework informieren zu können. Die derzeitige Vorgehensweise über das Forum ist für mich nicht handelbar. Ich kriege es erst mit, wenn es zu spät ist. Wobei "spät" relativ ist, weil das anscheinend einfach so kurzfristig durchgezogen wurde.
Eine Abstimmungsfunktion (nur) für Developer bei neuen Features fände ich übrigens auch sinnvoll.
InternalValues sind Readings mit Punkt am Anfang (attr global showInternalValues). Ich benötige Werte, die von FHEM vor dem Neustart
gespeichert werden und zumindest bei einem List sichtbar sind. Gibt es dafür auch andere Lösungen? Dann hätte ich auch kein Problem mehr mit dem Doppelpunkt.
ZitatAlso ich habe beide Foren abonniert. Nur konnte ich in "Developer" nichts dazu finden.
Sorry, wieder meine Schuld. Wir sind ja im Sonstiges, eigentlich haette im Developer dafuer ein Thema geben muessen. Ich versuche demnaechst aufzupassen.
ZitatEs gibt keine Möglichkeit, sich nur über neue Themen per Email benachrichtigen zu lassen.
Das muss aber gehen, da bei mir genau das aktiviert ist. Ich vermute es reicht dafuer auf Bereichs-Ebene die emails zu aktivieren. Ich habe auch Verstaendnis dafuer, wenn jemand keine Zeit fuer die vielen Mails hat, dann braucht man sich aber nicht zu beschweren. Aber wie gesagt, war meine "Ruege" in diesem Fall komplett fehl am Platz, da ich mich an meine eigenen Regeln nicht gehalten habe.
ZitatInternalValues sind Readings mit Punkt am Anfang (attr global showInternalValues).
Da habe ich dich missverstanden. InternalValues ist fuer mich das, was bei "list" und in FHEMWEB unter Internals gezeigt wird, und die per "InternalVal()" abgefragt werden koennen. Das Attribut showInternalValues ist aus dieser Sicht ungluecklich benannt (*seufz*), wir reden in deinem Fall ueber Readings.
Nach etwas Nachdenken ueber dein Problem schlage ich vor, diese Regexp-Pruefung nur auf "immer Sichtbare" (also kein . am Anfang) Readings zu beschraenken, haette aber gerne Meinungen dazu.
Einverstanden.
Wäre es möglich, Werte abzuspeichern, die nicht unter {READINGS} laufen. Dann hätte ich/wir das Problem nicht.
Vielleicht kann sich ein Forum-Admin mal meine Einstellungen anschauen. Derzeit bekomme ich entweder all Emails oder keine. Auch kann ich im nachhinein nicht mehr ein Thema "abwählen" zu dem ich einmal etwas geschrieben habe.
Schau dir mal die Funktionen setKeyValue() und getKeyValue in fhem.pl an.
Die sind genau dafür gedacht. Nutze ich in FB_CALLLIST um die Anrufliste abzuspeichern und bei Start wieder einzulesen.
Gruß
Markus
ZitatNach etwas Nachdenken ueber dein Problem schlage ich vor, diese Regexp-Pruefung nur auf "immer Sichtbare" (also kein . am Anfang) Readings zu beschraenken, haette aber gerne Meinungen dazu.
finde ich gut und passt ja auch.
Hidden/Internal Values dürfen anderen Regeln gehorchen und evtl benötigte Flexibilität bleibt erhalten.
vg
jierg
Habs eingecheckt.
Zitat von: rudolfkoenig am 05 Januar 2016, 12:22:58
Das muss aber gehen, da bei mir genau das aktiviert ist. Ich vermute es reicht dafuer auf Bereichs-Ebene die emails zu aktivieren.
Auf der Übersichtsseite eines Unterforums den Button "Benachrichtigen" klicken
(http://up.picr.de/24200842su.jpg)
Zitat von: Markus Bloch am 05 Januar 2016, 12:51:40
Schau dir mal die Funktionen setKeyValue() und getKeyValue in fhem.pl an.
Die sind genau dafür gedacht. Nutze ich in FB_CALLLIST um die Anrufliste abzuspeichern und bei Start wieder einzulesen.
Das passt glaube ich nicht richtig. setkeyvalue ist doch mehr für Passwörter. Ich ändere ja die Readings nach jedem Geräte:Wert-Update. Das sind zu viele Schreibprozesse. Sichern reicht eigentlich pro Shutdown oder einmal täglich.
Zitat von: betateilchen am 06 Januar 2016, 10:50:24
Auf der Übersichtsseite eines Unterforums den Button "Benachrichtigen" klicken
Danke. Hatte ich gemacht. Ich bekomme aber trotzdem keine Emails. Vermute, es liegt an den Emaileinstellungen.
x Erhalte Newsletters, Ankündigungen und wichtige Benachrichtigungen via E-Mail.
x Benachrichtigung einschalten, wenn du einen Beitrag oder eine Antwort schreibst
x Die Antwort auf das Thema an die E-Mail anfügen
Für abonnierte Themen und Boards wie folgt benachrichtigen: Sofort-nur zur ersten ungelesenen Antwort
Benachrichtige mich bei abonnierten Themen: Gar nicht
Wenn ich letzteres ändere, werde ich auch mit Emails über Themenbeiträge geflutet. Ich benötige aber den Filter "Ungelesene Antworten zu deinen Beiträgen." und der ist glaube ich weg, wenn ich die zweite Checkbox abwähle.