fhem.pl anpassen für stateFormat

[zap]

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

Code Auswählen Erweitern


$st =~ s/\b([A-Za-z\d_\.-]+)\b/($r->{$1} ? $r->{$1}{VAL} : $1)/ge;


wäre folgendes hilfreich (\: eingefügt):

Code Auswählen Erweitern


$st =~ s/\b([A-Za-z\d_\.\:-]+)\b/($r->{$1} ? $r->{$1}{VAL} : $1)/ge;


[rudolfkoenig]

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?

[betateilchen]

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.

[justme1968]

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.

[rudolfkoenig]

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?

[zap]

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.

[rudolfkoenig]

Aber 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.

Wenn 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.

[zap]

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).

[justme1968]

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.

[krikan]

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.

[zap]

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.

[Wzut]

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

Code Auswählen Erweitern

attr name groupPorts TV=1,2 Media=4,5,6 
oder wäre ein 

Code Auswählen Erweitern

attr name groupPorts TV=1 2,Media=4 5 6
schöner/logischer gewesen ? 

[CoolTux]

@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

[Wzut]

@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.

[rudolfkoenig]

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.