Da ich immer wieder nach den gültigen Zeichen für automatisch angelegte Readings/Devices suche, habe ich das jetzt mal in zwei Subs verpackt:
sub validDeviceName($;$) {
my ($name, $repl) = @_;
$name =~ s/:/_/g; #replace ":" by "_"
$name =~ s/[^A-Za-z\d_\.]/$repl?$repl:""/eg; #remove or replace with $repl
return $name;
}
sub validReadingName($;$) {
my ($name, $repl) = @_;
$name =~ s/:/_/g; #replace ":" by "_"
$name =~ s/[^a-zA-Z0-9\.\/_-]/$repl?$repl:""/eg; #remove or replace with $repl
return $name;
}
Vielleicht ist das ja von allgemeinen Interesse und könnte in 99_Utils.pm/fhem.pl so oder ähnlich aufgenommen werden...
Einen Wiki Eintrag in https://wiki.fhem.de/wiki/DevelopmentModuleAPI würde ich dann ergänzen.
Wozu ist $repl gut?
Mit einem falschen Inhalt (wie "?") kann man damit ungueltige Namen generieren.
Ich würde hier 2 Ansätze vorschlagen:
1. Eine einheitliche Funktion die prüft ob überhaupt ein übergebene Parameter ein gültiger Device-Name / Reading-Name ist. Es gibt mittlerweile mehrere Stellen in fhem.pl und auch ausserhalb wo Regexp definiert sind zur Prüfung auf gültigen Zeichen. Das würde ich mir wünschen zu vereinheitlichen und Funktionen zur Prüfung in fhem.pl bereitstellen wo die Gültigkeit an einer einzigen Stelle geprüft wird.
Dies ist insbesondere bei der Prüfung von manuell eingegebenen Definitionsnamen notwendig.
2. Wie von dev0 vorgeschlagen, eine Konvertierungsfunktion anzubieten für Readings-Namen die man dynamisch aus externen Content generieren möchte, wo alle unerwünschten Zeichen entfernt oder durch "_" ersetzt werden.
Gruß
Markus
ZitatWozu ist $repl gut?
Individualität ;) Ist aber verspielt und nicht wichtig, kann also weg. Mir geht es bei dem Vorschlag um einen einheitlich Weg, der zentral verwaltet wird, damit ich mich nicht mehr darum kümmern/nachdenken muß.
Ich habe die Funktionen
goodDeviceName
makeDeviceName
goodReadingName
makeReadingName
zu fhem.pl hinzugefuegt.
Danke! Auch für die Ergänzung des Wikis.
Ich habe für mich auch so eine sub, allerdings ersetze ich noch die Umlaute:
sub string2name($) {
my %mutated_vowelmap = ("ä" => "ae", "Ä" => "Ae", "ü" => "ue", "Ü" => "Ue", "ö" => "oe", "Ö" => "Oe", "ß" => "ss");
my $mutated_vowelkeys = join ("|", keys(%mutated_vowelmap));
my $string = shift;
$string =~ s/($mutated_vowelkeys)/$mutated_vowelmap{$1}/g;
$string =~ s/[^A-Za-z0-9\.\_]/./g;
return $string;
}
Ich nutze das um Gerätenamen aus Raumnamen abzuleiten (z.B. Küche).
Hier noch ein kleiner Patch:
Index: fhem.pl
===================================================================
--- fhem.pl (revision 14931)
+++ fhem.pl (working copy)
@@ -2475,7 +2475,7 @@
return "Please define $old first" if(!defined($defs{$old}));
return "$new already defined" if(defined($defs{$new}));
return "Invalid characters in name (not A-Za-z0-9.:_): $new"
- if($new !~ m/^[a-z0-9.:_]*$/i);
+ if(!goodDeviceName($new));
return "Cannot rename global" if($old eq "global");
%ntfyHash = ();
Danke, eingecheckt, und aus der rename Fehlermeldung das : entfernt, ist ja nicht mehr zulaessig.
Zitat von: igami am 20 August 2017, 08:30:01
Ich habe für mich auch so eine sub, allerdings ersetze ich noch die Umlaute:
Funktioniert halt nur innerhalb FHEM bzw. ggf. auf dem gleichen System. Sobald man Daten von einem externen System unter anderer Plattform abholt, muss man natürlich den dort eingestellten Zeichensatz berücksichtigen. Das kann dann beliebig komplex werden.
Zitat von: zap am 20 August 2017, 14:13:14
Funktioniert halt nur innerhalb FHEM bzw. ggf. auf dem gleichen System. Sobald man Daten von einem externen System unter anderer Plattform abholt, muss man natürlich den dort eingestellten Zeichensatz berücksichtigen. Das kann dann beliebig komplex werden.
Das ist aber Aufgabe des entsprechenden Moduls den Zeichensatz der Hardware zu berücksichtigen und ggf. zu konvertieren, bevor man aus den Daten Readingsnamen oder Devicenamen ableitet.
Gruß
Markus
Wenn der Zeichensatz falsch ist wird es doch auch nicht als Umlaut erkannt. Ich benutze das nur innerhalb von FHEM, da sollten der Zeichensatz passen.
sub
goodDeviceName($)
{
my ($name) = @_;
return ($name && $name =~ m/^[a-z0-9._]*$/i);
}
habe ich in meinem Code in etwa geändert zu
sub goodDeviceName {
my $name = shift // return;
return ($name =~ m/^[a-z0-9_][a-z0-9._]*$/i);
}
Leider ist ja der Programmcode nicht dokumentiert, aber in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM steht ja, dass ein Punkt nicht an erster Stelle stehen darf. Das fängt mein Code ab, siehe beigefügtes Testfile.
Punkt an ersten Stelle dient (wie im Unix) zum Verstecken.
Siehe auch https://fhem.de/commandref_modular.html#showInternalValues
Zitat von: rudolfkoenig am 18 März 2020, 11:30:51
Punkt an ersten Stelle dient (wie im Unix) zum Verstecken.
Siehe auch https://fhem.de/commandref_modular.html#showInternalValues
Ok. ;-)
Dann wäre ich fast wieder bei
sub goodDeviceName_new {
my $name = shift // return;
return ($name =~ m{\A[a-z0-9._]*\z}xmsi);
}Dank meiner Microtestsuite sehe ich aber einen Unterschied: Der alte Code betrachtet den Namen '0' (Null) als nicht valide, der neue schon.
Wie ist da das gewünschte Verhalten? Will man führende Zahlen in Namen haben oder nicht?
Edith:
Will man "einen einzelnen Punkt" als validen Namen haben oder nicht?
Ein einzelner Punkt macht wenig Sinn, und bei fuehrenden Zahlen waere ich auch dagegen, das wird aber sicher bereits verwendet.
Achtung: Aenderungen an dieser Routine nehme ich nur bei konkreten und schwerwiegenden Problemen an, da ich hier kuerzlich schon Schiffbruch mit der Laengenbegrenzung erlitten habe.
Zitat von: rudolfkoenig am 18 März 2020, 12:45:31
Ein einzelner Punkt macht wenig Sinn, und bei fuehrenden Zahlen waere ich auch dagegen, das wird aber sicher bereits verwendet.
Achtung: Aenderungen an dieser Routine nehme ich nur bei konkreten und schwerwiegenden Problemen an, da ich hier kuerzlich schon Schiffbruch mit der Laengenbegrenzung erlitten habe.
Deswegen frage ich ja detailiert nach der gewünschten Verhaltensweise, damit ich ggf. die Regex entsprechend "richtig machen" kann.
Derzeit wird eben ein einzelner Punkt akzeptiert und die '0' nicht, '1' aber schon. etc. Wenn Du hier mal konkret schreiben könntest was gewollt ist und was nicht, dann kann ich schon eine "bombensichere" Regex basteln.
edit:
Und ich würde dann gerne
ZitatDevice-Namen dürfen aus den Zeichen a-z, A-Z, 0-9, Unterstrich _ und Punkt . bestehen, wobei ein Punkt nicht an erster Stelle stehen darf. Sie werden später sehen, dass der Punkt in perl und damit FHEM eine besondere Bedeutung hat, wenn möglich sollten Sie daher auf seine Verwendung in Device-Namen verzichten.
(https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM) präzisieren, Wiki kennt mich aber nicht. WIe bekomme ich da Zugriff?
ZitatWenn Du hier mal konkret schreiben könntest was gewollt ist und was nicht, dann kann ich schon eine "bombensichere" Regex basteln.
Ich wuensche mir erstmal keine Aenderung, solange es keinen triftigen Grund dafuer gibt.
Sonst habe ich (gefuehlt) 10 Stunden Support-Aufwand um irgendwelche kuriosen Faelle auszudiskutieren, die bisher niemanden gestoert haben.
Wiki Account gibt es vom Wiki-Admins: https://wiki.fhem.de/wiki/FHEMWiki:Administratoren
Ich waere bei den erwaehnten Artikel vorsichtig: Benutzer (insb. Anfaenger) sollten keine Devices mit . am Anfang anlegen, das duerfte selten sinnvoll sein.
Generell verbietet/prueft FHEM moeglichst wenig, es sei denn, es gibt deswegen konkrete Probleme.
Zitat von: rudolfkoenig am 18 März 2020, 13:54:12
Ich wuensche mir erstmal keine Aenderung, solange es keinen triftigen Grund dafuer gibt.
Sonst habe ich (gefuehlt) 10 Stunden Support-Aufwand um irgendwelche kuriosen Faelle auszudiskutieren, die bisher niemanden gestoert haben.
Ok. Ich verstehe den Wunsch (unnötigen?) Supportaufwand zu vermeiden. Leider sehe ich aber auch, dass wir offensichtlich unterschiedliche Definitionen von "triftiger Grund" haben. Für mich ist bereits ein triftiger Grund etwas am Code zu ändern, wenn der Code eigentlich etwas anderes macht als was man glaubt, dass er macht.
Aber gut, kann sein, dass ich da ein wenig obsessiv bin. Vermutlich einfach nur zu viele Horrorfilme gesehen, wo die Heimautomatisierung die Hausbewohner terrorisiert. ;-)