Perl - Modul 10_RHASSPY.pm "professionalisieren"

[drhirn]

Hallo,

ich bin gerade leicht verwirrt, über die Umwandlung der Codierung von Perls 'lc'. Kann mich da bitte jemand aufklären?

Ich habe Geräte mit einem Attribut "raum". Den Inhalt dieses Attribute sammle ich (in einem Modul), wandle es mit 'lc' in Kleinbuchstaben um, und erstelle dann ein Reading. Jetzt mal so grob erklärt. Aber viel mehr passiert wirklich nicht.

Code Auswählen Erweitern

readingsSingleUpdate($hash, "test_" . lc($room), $room, 1);

Ist jetzt ein Attribut "raum" mit "Küche" befüllt, habe ich danach ein Reading, das test_k?che heißt.

Wenn ich das ganze aber umwandle

Code Auswählen Erweitern


$room = encode('iso-8859-1', $room);
readingsSingleUpdate($hash, "test_" . lc($room), $room, 1);

bekomme ich ein Reading test_küche.

Code Auswählen Erweitern

print setlocale(LC_CTYPE); meint en_US.UTF-8, meine FHEM-Instanz ist auf englisch eingestellt.

Sollte UTF-8 nicht Umlaute können? Oder irre ich mich jetzt da?
Freue mich über jede Erklärung - und v.a. Vorschläge, wie man's eleganter löst.

Stefan

[Beta-User]

Auch wenn ich nicht wirklich was zu utf-Fragen beitragen kann: Umlaute sind eigentlich keine erlaubten Zeichen in Reading-Namen.

Vielleicht hilft dir makeReadingName() (und goodReadingName()) als Stichwort zur Suche in fhem.pl weiter?

(Und wenn ich readingsSingleUpdate() irgendwo sehe, habe ich den Reflex, nach dem nächsten Vorkommen der Funktion zu suchen und zu ergründen, ob man das nicht besser per Bulk-update verarbeiten kann).

[drhirn]

Wiki tut's auch. Danke für den Hinweis! Da muss ich mir was überlegen. Eine Küche heißt nunmal Küche und keiner sagt Kueche

Und außerdem: Tu nicht schon wieder vom Thema ablenken
Aber, wenn wir schon dabei sind: Gibt's noch einen anderen Unterschied zw. single und bulk, außer, dass ich mit bulk gleich mehrere setzen kann?

[Beta-User]

...ablenken war nicht beabsichtigt...

Wenn du irgendwo Umlaute brauchst, solltest du das irgendwie anders lösen, ist halt schwierig eine Idee zu entwickeln, wenn man a) grundsätzlich keine vertiefte Erfahrung von der Materie utf hat und b) keine Infos, wie die Readings verwendet werden sollen...

single="kleines bulk", das ruft intern auch nur bulk auf. Der wesentliche Unterschied ist der: jedes bulk-Ende (also indirekt auch single) ruft die komplette Event-Verarbeitung auf. Es ist daher m.E. grundsätzlich sinnvoll, alle Readings (eines Devices) auf einmal zu schreiben. Siehe ggf. die "Beispielschleife" in https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify

[drhirn]

makeReadingName ist eine super Sache! Damit ist mein Problem gelöst.
Hätte es halt gerne verstanden.

Gut, dann hab ich das mit single/bulk eh richtig verstanden. Schau ich mir genauer an, ob ich das optimieren kann. Meine ersten Versuche waren nicht erfolgreich.

Danke dir!

[Beta-User]

Hätte es halt gerne verstanden.

Mal schauen, ob das noch jemand kompetentes erklärt...

makeReadingName ist eine super Sache! Damit ist mein Problem gelöst.

Thx für die Rückmeldung!

Ad OT:
Ist nur ein Reflex, ich habe halt bei meinen eigenen Modulen irgendwann gemerkt, dass da Potential drin war, und bis vor kurzem war ich da auch noch nicht so sensibel...
Und weil wir grade sowieso Teil-OT sind: Das RHASSPY-Ding bringt ja per default sowieso einen Broker mit, oder? Warum baust du das nicht generell nach MQTT2_CLIENT um? (Kann sein, dass du Rudi brauchst, damit das Modul als weiterer Client für die M2-IOs akzeptiert wird, ist aber vermutlich kein Hexenwerk).
(Ist schon klar, dass das für dich erst mal Zusatzufwand ist, aber nachfolgende User-Generationen würden es dir danken! Just my2ct.).

[drhirn]

Ich bin mir ganz sicher, dass das auch mit MQTT2_CLIENT funktionieren würde, ohne dass ich viel Arbeit reinstecken müsste. Ich glaub, ich hab das vor Langem mit dem Snips-Modul sogar mal ausprobiert. Es hatte bis gestern einfach noch keine Priorität.

[drhirn]

Fällt dir ein aktuelles Modul ein, bei dem ich mir das ansehen könnte?

[Beta-User]

Alles gut .
Falls du dabei Hilfe benötigst: Sag' Bescheid!

Einen echten "Hybriden", der mit beiden IO-Typen kann, findest du in MQTT_GENERIC_BRIDGE; da leitet Parse() nach onMessage() (oder so ähnlich) um und entfernt vorab "M2-Spezifika" (das "autocreate-flag").

(Es würde sich ggf. anbieten, die relevanten Teile aus MGB in eine eigene Lib auszulagern und das ganze zu packagen, falls noch nicht geschehen)

[drhirn]

Du wirst mit Sicherheit von mir hören. Ich hab nämlich keinen Plan

MQTT_GENERIC_BRIDGE hast du eh schon erwähnt. Das ist mir zu komplex. Ich bräuchte ein Modul, bei dem ich auch verstehe, was es tut.

[Beta-User]

...es tut zu einem wesentlichen Teil was sehr ähnliches wie deines: Es schaltet - veranlasst durch eingehende MQTT-Kommandos - FHEM-Geräte bzw. aktualisiert Readings .

(in die andere Richtung werden einfach Events in Topic+Message umgewandelt und an den Server geschickt, da, wo passende Attribute gesetzt sind).

Von daher könnte man den "Empfangs-Unterbau" auch bis zum Punkt "onMessage()" 1:1 kopieren . Vielleicht bin ich "mal lustig" und versuche mich in meiner ersten lib...

[drhirn]

Du kannst auch gerne in "meinem" Modul lustig sein. Das braucht eh dringend einen fachmännischen Blick.

[Beta-User]

Über "fachmännisch" kann man streiten...

Hab's mal nach perlcritic.com gepastet und "harsh" dagegen laufen lassen, das würde ich "zur Übung" auch mal empfehlen. Über die "Frgezeichen"-Symbole kommt dann jeweils auch eine Erläuterung, warum das im einzelnen als nicht so prickelnd angesehen wird...

Dann das ganze gepackaged, ich hoffe, beim Importieren keine wichtige Funktion übersehen zu haben, sonst gibt's crashes...

Anbei mal ein erstes Zwischenergebnis als Diskussionsgrundlage.
Kann dazu funktional nicht viel sagen, es lädt, ist aber sonst ungetestet...

[drhirn]

Das ist ja eine coole Seite! Ich staune
Danke für den Hinweis, sehe ich mir dann genauer an.

Und deine Version wird getestet.

[drhirn]

Es hat gut ausgesehen. Bis ich das Device mal gelöscht habe und neu anlegen wollte:

Undefined subroutine &main::RHASSPY_Define called at fhem.pl line 3830.

Das mit mit "package" und die Benennung von "subs" verstehe ich sowieso nicht. Ich habe mich da beim Umbau des Modules an das "DevelopmentModuleIntro" aus dem Wiki gehalten. Aber wenn ich mir da neuere Module ansehe, scheint das nicht mehr ganz aktuell zu sein, oder? Hast du da einen Tipp für mich, wo ich weitere Informationen finde?

Danke!