Perl - Modul 10_RHASSPY.pm "professionalisieren"

Begonnen von drhirn, 18 Februar 2021, 17:02:31

Vorheriges Thema - Nächstes Thema

Beta-User

#120
...und noch ein letzter für heute: prefix in Variablenform, samt Löschen der Attribute bei Löschen des RHASSPY-devices... (weiß noch nicht, ob das in der Testphase so glücklich ist, aber das kann man ja mit einem einfachen return an der richtigen Stelle vorläufig verhindern...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: JensS am 28 Februar 2021, 11:51:49
@drhirn: Hab die gestrige Version von Beta-User installiert. Läuft alles - bis auf die Shortcuts natürlich.
[...]
(Danke für den Mut zum Testen und die Rückmeldung!)

...das mit "natürlich" ist seltsam. Ein list (kein RAW) vom RHASSPY-Device wäre hilfreich, damit ich sehen kann, dass das Attribut sauber ausgewertet wird.

@drhirn: Zur Attributbeschreibung ist auch m.E. noch eine Korrektur in der cref erforderlich (gg. dem, was in deiner letzten github-Version steht): parseParams kann den Teil nach dem "=" nur als zusammengehörig erkennen, wenn es irgendwie "geklammert" wird. Und FHEM-Kommandos gehen zwar, aber wenn, dann muss man die "Kürzel" "i" _und_ "f" setzen, sonst wird es als Perl interpretiert:

i="mute off" f"=set receiver mute off"
oder
mute off='fhem("set receiver mute off")'

Die "alte Notation" sollte auch gehen, dann wird es als Perl ausgeführt

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Was hattest du im Kopf, als du dich für die Buchstaben "i" und "f" entschieden hast?

Beta-User

Zitat von: Beta-User am 25 Februar 2021, 18:05:14
Hab's mal mit diesen Attributinhalten versucht, aber noch nicht vollständig durchgetestet
attr RHASSPY shortcuts ton aus={fhem ("set RXV777 off")}\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="ton an" p={fhem ("set $NAME on")} n=RXV777

Die Änderungen bzgl. der Auswertung des Attributs kann man an einfachsten in einem list sehen.
Also funktionieren sollten:
i => intent (damit muss eine Zeile starten, damit nicht alte Syntax unterstellt wird, Leerzeichen können vorher kommen)
f => FHEM-Kommando
p => Perl-Kommando (hat Vorrang vor "f")
n => Name des zurückzugebenden Devices (für longpoll ;) ); sonst wird der Rückgabewert versucht
r => Response (sonst der Rückgabewert)

Wollte es nicht so lange haben, und die Buchstaben/Anfänge waren alle unterschiedlich... (Ist aber kein Muss und schnell geändert).

Ansonsten: Hut ab, du scheinst die Änderungen wirklich alle zumindest grob überflogen zu haben!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Perfekt, ich danke vielmalst!

Natürlich sehe ich mir die Änderungen an. Passiert bei einem DIFF zwangsläufig ;). Aber ich will ja wissen, was du da machst. Auch wenn ich manchmal viel nicht verstehe.

Mal schauen, ob ich heute noch zum Testen komme.

Beta-User

Aufgrund der Info von JensS: Irgendwo ist noch ein Typo drin, es gibt jetzt zwei keys in helper->shortcuts; In Zeile 1208 (github) sollte wohl klein geschrieben werden.
(Ist aber eher nicht die Ursache)

Ansonsten würde mich der Attributwert interessieren, ich vermute eine Doppelung von ' und {. Benötigt wird nur eines, ich kann's aber grade nicht nachstellen...

Zitat von: drhirn am 28 Februar 2021, 12:28:50
Perfekt, ich danke vielmalst!

Natürlich sehe ich mir die Änderungen an. Passiert bei einem DIFF zwangsläufig ;) . Aber ich will ja wissen, was du da machst. Auch wenn ich manchmal viel nicht verstehe.
Na ja, an der einen oder anderen Stelle meine ich, dass da was verändert wurde, und das (bis auf die benannte Stelle in der cref) sinnvoll! Darfst gerne nachfragen, wenn was unklar ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachtrag noch zum Thema "r": muss zugeben, dass ich diesen Teil erst mal nur "angedacht" hatte und mich zunächst auf die Perl- und FHEM-Unterscheidung konzentriert hatte, damit das sauber erkannt und auch ausgeführt wird. (Daher war das "r" bis vorhin auch noch nicht offen aufgetaucht...)

Von daher ist die "response"-Logik vermutlich noch nicht ausgereift, mir ging es vorrangig erst mal darum, (auch) das sauber aufzulösen, den (via list sichtbaren) Hash zu schreiben und für die Basisfunktion klarzumachen, wo bei der Ausführung dann was hergeholt/referenziert wird.
@drhirn & JensS: Wollt ihr versuchen, das zu fixen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Die Kleinschreibung ist mal der Grund, warum updateSlots jetzt überhaupt wieder funktioniert.

Ansonsten bekomme ich immer den "DefaultError" als Response zurück, obwohl richtig geschalten wird (inkl. "Longpoll"-Aktualisierung). Das versuche ich gerade zu ergründen.

drhirn

Morgen Beta-User,

wie könnten wir die Sprache (wo) anders setzen? Ich habe nämlich gerade das Rätsel gelöst, warum die bei mir immer englisch ist, obwohl überall deutsch eingetragen ist: Das passiert immer nach einem Reload des Moduls. Ändere ich das Attribut, stimmt's wieder. Bis zum nächsten Reload.
Hast du eine Idee?

Beta-User

#129
Moin!

Bei der Sprache bin ich mir nicht sicher, ob es was bringen würde, die in DEF reinzubasteln, ich habe jedenfalls das Verhalten auf dem Testsystem nicht, dass ein reload die Sprache ändern würde. Von daher: ratlos. Ggf. erst mal übergangsweise hart (anders) vercoden?

Grundsätzlich bin ich aber am Überlegen, ob es nicht besser wäre, das Modul auf "parseParams" umzustellen, dann wäre es z.B. auch einfacher möglich, weitere Parameter einzuführen (z.B. useAlexaRooms=true). Wirkt sich halt auf "define", "set" und "get" aus...

Anbei auch noch eine Version, die zumindest grade nicht rumzickt, was $mutuated_vovels angeht (deine Commits von vor 45 Min sollten drin sein). Kannst du kurz testen, ob das die Ersetzungen wie beabsichtigt macht (oder das ganze in den Abgrund zieht...)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

#130
Schlechte Nachricht:
Can't use an undefined value as a HASH reference at ./FHEM/10_RHASSPY.pm line 1036

Zeile 1036 ist
my $mutated_vowels = \%languagevars{$language}->{mutated_vowels};

Und außerdem, falls das hilft:

PERL WARNING: %languagevars{...} in scalar context better written as $languagevars{...} at ./FHEM/10_RHASSPY.pm line 1038, <$fh> line 114.
PERL WARNING: Useless use of push with no values at ./FHEM/10_RHASSPY.pm line 1108, <$fh> line 114.
PERL WARNING: Reference found where even-sized list expected at ./FHEM/10_RHASSPY.pm line 57, <$fh> line 114.

Beta-User

#131
OK, vielleicht ein paar kleine Schritte weiter...

parseParams ist jetzt aktiv, was ggf. dazu führt, dass set nicht mehr geht ::) . Dafür kann man jetzt in der DEF die Sprache angeben, das Attribut ist weg.
Na jedenfalls, _wenn_ das mit set alles noch funktioniert, sollten die Voraussetzungen dafür vorhanden sein, dass man ggf. auch "alexaName" usw. mit auswertet. Sowas müßte dann in einen ähnlichen Parser wie das Shortcut-Ding, nur eben über alle Geräte ausgewertet und in den internen helper-Hash gepackt...

Könnte sein, dass das mit den Umlauts jetzt geht und dann auch die Rückmeldungen für Timer-Befehle in de und en funktionieren 8) . Ist aber nicht wirklich getestet...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Blöde Frage: Warum sollte ich alexaName auswerten wollen?

Beta-User

Na ja, nach meinem möglicherweise unvollständigen Verständnis gibt es viele Parallelen zwischen praktisch allen Sprachsteuerungslösungen.

Ich fände es z.B. als siri-Nutzer wenig intuitiv, wenn ich für eine weitere Lösung nochmal "dasselbe" Attribut (unter anderem Namen) anlegen müßte und nicht einfach (z.B. zum Testen) sagen könnte: "Nimm alle Geräte, die auch im Alexa-Room sind und verwende die alexa- oder siri-Namen" und die bereits vergebenen mappings aus dem homebridgeMapping..."

(Ich habe noch keinen Schimmer, inwieweit das vergleichbar ist und ob ich mit dem Bachgefühl richtig liege, aber diese "sortierten Lookups" bei jedem Durchlauf sehen mir nicht optimal aus, that's all...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Das ist schon richtig. Könnte aber natürlich auch sein, dass ich mit einer Alexa nicht die selben Geräte steuern möchte. Aber ist wahrscheinlich eher selten der Fall (außer man testet - wie ich - schon seit Jahren eine "beste" Lösung). Weiß auch nicht, was da schlauer ist.

Zitat
Zeile 1295: "Beta-User: warum eigentlich nicht direkt nur den Befehl absetzen...?"

Geht auch. Ich bin es einfach so gewohnt, dass ich mir zuerst die "Config" zusammenschreibe und danch den Befehl bastle. Macht's für mich übersichtlicher. Und ich kann den Befehl dann einfach nur kopieren und irgendwo anders genau so wieder einfügen.