Perl - Modul 10_RHASSPY.pm "professionalisieren"

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

Vorheriges Thema - Nächstes Thema

Beta-User

#240
Vermutlich war mein dummy-mapping (bzgl. decibel) nicht vollständig, aber in den Grundzügen scheint es so zu funktionieren - und übersichtlicher ist es m.E. auch noch :) .

"decibel" ist bisher auch keine Kategorie, die das Modul kennen würde. Kann also auch daran liegen.

Die deutschen Begriffe "Lautstärke usw. sollten jetzt auch wieder in den Mappings erkannt werden.

Ist denn sonst grade noch was offen?
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

Nicht viel erfreulicherweise. Und ich muss sagen, das, was tut, tut sehr zuverlässig. Echt gute Arbeit von dir!

Ich hab derzeit noch das:
- playWav liefert noch den Fehler
- getValue muss noch gut getestet werden. Funktioniert v.a. nicht mit [Device:Reading] Ausdrücken

set Rhasspy play siteId="wohnzimmer" path="/opt/fhem/test.wav"

In den Mappings wollen wir doch gar keine deutschen Begriffe?

drhirn

Ach ja, und das hier:

PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/10_RHASSPY.pm line 1947.

Das passiert in SetNumeric ständig bei allen Berechnungen. Ich weiß aber noch nicht, warum. Irgendwo bekommen wir eine falsche / keine Zahl zurück.

drhirn

Zitat von: Beta-User am 11 März 2021, 10:36:25
"decibel" ist bisher auch keine Kategorie, die das Modul kennen würde. Kann also auch daran liegen.

Brauchen wir das {Unit} überhaupt noch? Eigentlich nicht, oder?

drhirn

Und kannst du mir bitte schreiben, wie ein korrektes Mapping jetzt aussehen muss?

Beta-User

#245
Zitat von: drhirn am 11 März 2021, 10:59:41
Nicht viel erfreulicherweise. Und ich muss sagen, das, was tut, tut sehr zuverlässig. Echt gute Arbeit von dir!
Danke für die Rückmeldung!

ZitatIn den Mappings wollen wir doch gar keine deutschen Begriffe?
Jein. Wollen nicht, aber da die im Moment da sind, ist jetzt eben dieser Kompabilitäts-Layer eingezogen, und der fehlte an der Stelle noch.
Mittelfristig sollte man tatsächlich von den deutschen Begriffen weg, aber dann am besten auch gleich so, dass wir eben ein pct- oder brightness-Reading ohne Angabe eines Mappings erkennen können. Der User sollte m.E. den Anpassungsaufwand nur einmal haben bzw. ggf. können wir den ("umgezogenen") Kompabilitäts-Layer dann auch beibehalten, wenn wir diese Routine dann ggf. nur bei "reinit devices" durchlaufen...?

ZitatIch hab derzeit noch das:
- playWav liefert noch den Fehler
set Rhasspy play siteId="wohnzimmer" path="/opt/fhem/test.wav"
Sollte jetzt auch gefixt sein.

Zitat- getValue muss noch gut getestet werden. Funktioniert v.a. nicht mit [Device:Reading] Ausdrücken
Versuch's mal mit dieser Änderung in RHASSPY_getValue():

    # Soll Reading von einem anderen Device gelesen werden?
    if ($getString =~ m{:}x) {
        $getString =~ s{\[([^]]+)]}{$1}x; #remove brackets
        my @replace = split m{:}x, $getString;
        $device = $replace[0];
        $getString = $replace[1] // $getString;
        return ReadingsVal($device, $getString, 0);
    }


Zitat von: drhirn am 11 März 2021, 11:13:46
Brauchen wir das {Unit} überhaupt noch? Eigentlich nicht, oder?
Puh, du kannst Fragen stellen... Im Moment vermutlich sinnvoll für percent?

Zitat von: drhirn am 11 März 2021, 11:09:30
PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/10_RHASSPY.pm line 1947.
Das passiert in SetNumeric ständig bei allen Berechnungen. Ich weiß aber noch nicht, warum. Irgendwo bekommen wir eine falsche / keine Zahl zurück.
Habe ein Pflaster geklebt; die eigentliche Ursache ist aber woanders, aber dahin kommen wir ggf. später erst nochmal...

Zitat von: drhirn am 11 März 2021, 11:28:14
Und kannst du mir bitte schreiben, wie ein korrektes Mapping jetzt aussehen muss?
Die "verständlichen Schlüsselworte" sind in $internal_mappings->{Change}, also "lightUp" bis "setDown".
Funktionieren sollte, was dort in {Type} zu finden ist, also insbesondere:
SetNumeric:currentVal=pct,minVal=0,maxVal=255,cmd=pct,step=1,type=brightness\
SetNumeric:currentVal=temperature,minVal=0,maxVal=255,cmd=temperature,step=1,type=temperature\
SetNumeric:currentVal=volume,minVal=-40,maxVal=20,cmd=volume,step=0.5,type=volume
Das Mapping scheint man nur zu benötigen, wenn es mehrere SetNummeric gibt, oder?

(Der mittelfristige Plan wäre, z.B. pct dann direkt brightness zuzuordnen mit minVal=0 und maxVal=100 (bzw. 99 für TYPE=ZWave), so dass man da nur was angeben muss, wenn man es anders haben will...? "temperature" und "volume" sind "doppelt" und daher eigentlich unnötig.)

Fyi: Habe mal das rhasspy-deb auf einem meiner Server installiert (x86), und die App hat auch Kontakt aufgenommen. Viel mehr ist aber noch nicht passiert...
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

Zitat von: Beta-User am 11 März 2021, 12:06:42
Jein. Wollen nicht, aber da die im Moment da sind, ist jetzt eben dieser Kompabilitäts-Layer eingezogen, und der fehlte an der Stelle noch.
Mittelfristig sollte man tatsächlich von den deutschen Begriffen weg, aber dann am besten auch gleich so, dass wir eben ein pct- oder brightness-Reading ohne Angabe eines Mappings erkennen können.

Die User müssen dann eh noch mehr umbauen. Ich wäre daher fast dafür, dass wir einen "harten Schnitt" machen.

ZitatPuh, du kannst Fragen stellen... Im Moment vermutlich sinnvoll für percent?

Wenn im Mapping ein map=percent steht, soll in Prozent gerechnet werden. Sonst eh nicht.

ZitatFyi: Habe mal das rhasspy-deb auf einem meiner Server installiert (x86), und die App hat auch Kontakt aufgenommen. Viel mehr ist aber noch nicht passiert...

Cooool :)

Beta-User

Zitat von: drhirn am 11 März 2021, 13:24:48
Die User müssen dann eh noch mehr umbauen. Ich wäre daher fast dafür, dass wir einen "harten Schnitt" machen.
Bin noch nicht sicher, ob wir es nicht so hinbekommen, dass auch weiter die "alten" Vorgehensweisen und Werte erlaubt bleiben (und nur nicht mehr "beworben" werden).

Mein Ziel wäre eher, das so zu machen, dass es
- "international verwendbar" ist (weitestgehend done, oder?) und
- für Neueinsteiger ggf. mit deutlich weniger Aufwand einzurichten ist, v.a., wenn bereits mappings für andere Lösungen da sind.

Im Moment bedeuten die Umbauten "hinter der Fassade" einfach, dass jemand, der jetzt einsteigt dann eben direkt die englischen Begriffe im Mapping verwenden und die englischen "keywords" an das Modul übergeben sollte, that's all...

So, wie es jetzt gebaut ist, bedeutet es an fast allen Stellen (außer der Auswertung des mappings!) eigentlich nur, dass es einen kleinen Overhead gibt, wenn man entweder die deutschen oder keine keywords angibt; wer es "richtig macht", bekommt auch ohne Umschweife ein passendes Ergebnis ;) .

ZitatWenn im Mapping ein map=percent steht, soll in Prozent gerechnet werden. Sonst eh nicht.
Das stimmt jedenfalls im Moment nicht, und ich meine auch, an der Logik an sich nichts gedreht zu haben. Wenn man Unit=>percent (bzw. bisher: "Prozent" ) übergeben hat, wird auch in Prozent gerechnet, und das finde ich - jedenfalls bis dato -auch ok so. Das gilt umso mehr, da man ggf. später auf den "Luxus" eines expliziten Mappings verzichten können soll ;) .


ZitatCooool :)
Mal sehen, wie "cool" das ist; werde jetzt erst mal verstehen müssen, wie der Dienst funktioniert und dann auch, was mir ggf. noch an scripten fehlt; der Debian-Way ist dann doch etwas anders als Docker, und für eine eventuell Sprachausgabe muss ich mir auch was ausdenken, falls es nicht über das Handy zu machen wäre... Alles noch "black box".
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

Zitat von: Beta-User am 11 März 2021, 13:45:06
Das stimmt jedenfalls im Moment nicht, und ich meine auch, an der Logik an sich nichts gedreht zu haben. Wenn man Unit=>percent (bzw. bisher: "Prozent" ) übergeben hat, wird auch in Prozent gerechnet, und das finde ich - jedenfalls bis dato -auch ok so. Das gilt umso mehr, da man ggf. später auf den "Luxus" eines expliziten Mappings verzichten können soll ;) .

Also, laut Tyraz:
Zitat
Erläuterung zu map=percent:
Ist die Option gesetzt, werden alle numerischen Stellwerte als Prozentangaben zwischen minVal und maxVal verstanden.
Bei einer Lampe mit minVal=0 und maxVal=255 und map=percent verhält sich also Stelle die Lampe auf 50
genauso wie Stelle die Lampe auf 50 Prozent.
Dies mag bei einer Lampe mehr Sinn ergeben als Werte von 0...255 anzusagen.
Beim Sollwert eines Thermostats hingegen wird man die Option eher nicht nutzen,
da dort die Angaben normal in °C erfolgen und nicht prozentual zum möglichen Sollwertbereich.

Aber ja, spricht nichts dagegen, es so zu machen.

Zitat
Mal sehen, wie "cool" das ist; werde jetzt erst mal verstehen müssen, wie der Dienst funktioniert und dann auch, was mir ggf. noch an scripten fehlt; der Debian-Way ist dann doch etwas anders als Docker, und für eine eventuell Sprachausgabe muss ich mir auch was ausdenken, falls es nicht über das Handy zu machen wäre... Alles noch "black box".

Debian ist eigentlich sogar einfacher. Sofern die Installation problemlos durchläuft und keine Requirements fehlen.
Wie gesagt, ich stehe zur Verfügung, wenn's Fragen gibt.

drhirn

Modul kann noch immer nicht rechnen ;)

Ich bekomm unreproduzierbar bei "mach lampe dunkler"

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "mach lampe lightDown", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "lampe"}, "slotName": "Device", "rawValue": "lampe", "confidence": 1.0, "range": {"start": 5, "end": 10, "rawStart": 5, "rawEnd": 10}}, {"entity": "Value", "value": {"kind": "Unknown", "value": ""}, "slotName": "Value", "rawValue": "", "confidence": 1.0, "range": {"start": 11, "end": 10, "rawStart": 11, "rawEnd": 10}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "lightDown"}, "slotName": "Change", "rawValue": "dunkler", "confidence": 1.0, "range": {"start": 11, "end": 20, "rawStart": 11, "rawEnd": 18}}], "sessionId": "wohnzimmer-snowboy-67f0563c-282d-4035-b486-7cc373587b55", "customData": null, "asrTokens": [[{"value": "mach", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "lampe", "confidence": 1.0, "rangeStart": 5, "rangeEnd": 10, "time": null}, {"value": "lightDown", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 20, "time": null}]], "asrConfidence": null, "rawInput": "mach lampe dunkler", "wakewordId": "snowboy", "lang": null}

PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/10_RHASSPY.pm line 1971
Das ist hier:

                # Stellwert um Wert x ändern ("Mache Lampe um 20 heller" oder "Mache Lampe heller")
                #elsif ((!defined $unit || $unit ne 'Prozent') && defined $change && !$forcePercent) {
                elsif ( ( !defined $unit || !$ispct ) && defined $change && !$forcePercent) {
                    $newVal = ($up) ? $oldVal + $diff : $oldVal - $diff;
                }


Reproduzierbar wird aber gar nicht gerechnet. Das Reading wird aktualisiert, ändert sich aber nicht.

Aktuelles Mapping:

SetNumeric:currentVal=pct,minVal=0,maxVal=100,cmd=pct,step=1,type=brightness


Generell gibt's bei allen Arten von Satz hin und wieder Use of uninitialized value-Meldungen. Das kann ich aber nicht reproduzieren.

Aber, damit ich nicht nur schlechte Nachrichten habe:
"lampe um 10 prozent heller" funktioniert

Beta-User

#250
Glaube, die Ursache gefunden zu haben:
Da wurden teils Hashes mit leerem Inhalt erzeugt, '' ist halt nicht undef...



OT:
Da wir hier jetzt die ganze Zeit eigentlich eher Rhasspy-spezifisches diskutieren, bin ich nicht mehr sicher, ob der Thread noch im richtigen Forenbereich ist ::) ...

Zitat von: rudolfkoenig am 11 März 2021, 12:37:20
Im Development Bereich des Forums [...] das Ziel ist aber Signal/Noise Ratio hoch zu halten, damit man das Abonnieren fuer Maintainer zu Pflicht machen kann.
Wir machen grade ziemlich viel "noise"...

(Für spezielle Fragen zu Rhasspy@Debian würde ich aber so oder so bei Bedarf einen separaten Thread aufmachen).
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