fhem.pl anpassen für stateFormat

[Markus Bloch]

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.

[immi]

thanks

[herrmannj]

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

[viegener]

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?

[herrmannj]

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

[Martin Fischer]

mal so als hinweis:

es gibt dafür extra ein modul: notice. das hatte ich seinerzeit im zuge des rewrites der update und fheminfo module mitentwickelt.

es müsste nur von den entwicklern angewendet werden

[rudolfkoenig]

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.

[Benni]

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 

[Wernieman]

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

[justme1968]

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­ßen­tem­pe­ra­tur' 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.

[betateilchen]

Vielleicht könnte man ja statt einer Positiv- eine Negativliste verwenden? Also nur auf Zeichen prüfen, die nicht erlaubt sind/sein sollen.

[justme1968]

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. 

[viegener]

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

[justme1968]

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. 

[Markus Bloch]

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:


[ ] { } ( ) , . : ; * + ? \ / @ % $ ^