Autor Thema: Perl - Modul 10_RHASSPY.pm "professionalisieren"  (Gelesen 12272 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14916
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #240 am: 11 März 2021, 10:36:25 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #241 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!

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?

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #242 am: 11 März 2021, 11:09:30 »
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.

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #243 am: 11 März 2021, 11:13:46 »
"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?

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #244 am: 11 März 2021, 11:28:14 »
Und kannst du mir bitte schreiben, wie ein korrektes Mapping jetzt aussehen muss?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14916
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #245 am: 11 März 2021, 12:06:42 »
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!

Zitat
In 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...?

Zitat
Ich 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);
    }

Brauchen wir das {Unit} überhaupt noch? Eigentlich nicht, oder?
Puh, du kannst Fragen stellen... Im Moment vermutlich sinnvoll für percent?

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

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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #246 am: 11 März 2021, 13:24:48 »
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.

Zitat
Puh, 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.

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

Cooool :)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14916
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #247 am: 11 März 2021, 13:45:06 »
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 ;) .

Zitat
Wenn 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 ;) .


Zitat
Cooool :)
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #248 am: 11 März 2021, 13:51:39 »
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.

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #249 am: 11 März 2021, 15:21:52 »
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 1971Das 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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14916
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #250 am: 11 März 2021, 15:42:13 »
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 ::) ...

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).
« Letzte Änderung: 16 März 2021, 13:08:44 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1647
Antw:Perl - Modul 10_RHASSPY.pm "professionalisieren"
« Antwort #251 am: 11 März 2021, 16:00:47 »
Alles klar, machen wir das so. Hier geht's weiter: https://forum.fhem.de/index.php/topic,119447.0.html
Zustimmung Zustimmung x 1 Liste anzeigen

 

decade-submarginal