Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Doch lieber Rgb-Werte übergeben

Ich hab kaum Erfahrung mit Farben was Lampen betrifft. Ich weiß nur, dass ich immer RGB schalte. Weil ich's logischer finde. Und einfacher.
Und wenn's auch einfacher in der Umsetzung wäre, wäre ich fast dafür, dass wir das so machen. Bis ein Feature-Request kommt.
Und verzichten eben wirklich auch rhasspyColors

[Beta-User]

Ich hab kaum Erfahrung mit Farben was Lampen betrifft. Ich weiß nur, dass ich immer RGB schalte. Weil ich's logischer finde. Und einfacher.

Vorab: Die sentences für den "Rgb"-Key umzuschreiben wäre vermutlich kein Problem.

Bin aber tendenziell dagegen, weil RGB eben immer auch einen Helligkeitswert forciert. Meine aktuelle Idee dazu wäre, zu diesem Zweck etwas in "specials" einzubauen, so dass man bei Leuchten, die eigentlich einen "hue"-Setter haben dann RGB erzwingt. Sollte relativ einfach im Code einzubauen sein.

Damit hätte man wieder ein Bausteinchen mehr in Richtung: default-Verhalten an einem Gerät gefällt dir nicht => setze einen tweak bzw. ein special. ("colors=forceHue2RGB=1")

Ein weiteres wäre dann, auch für die Konvertierung von Colortemp fixe RGB-Werte zu erzwingen (das klappt nämlich bei meinen RGBW-MiLights nicht, und das hängt nicht nur an den Bugs, die ich in _ct2rgb reingemogelt hatte (das schaue ich mir nochmal in Ruhe an)). Weiß aber noch nicht, was da dann der beste Weg wäre.

Und verzichten eben wirklich auch rhasspyColors

...wenn wir grade beim Verzichten sind: Ich würde auch rhasspyChannels mittelfristig eher anderswo verorten und daher von vornherein das Attribut nicht "global" hinterlegen.

Hintergrund:
- Eigentlich ist das auch eine "Sonderregelung" für lediglich einzelne Devices, und mit globalen Attributen sollte man m.E. sparsam sein.
- Man könnte es vermutlich mehr oder weniger 1:1 in "specials" einbauen, indem man einfach ein "channel=" davorsetzt und dann diese Zeilen einer Sonderbehandlung zuführt. Sollte auch ohne größere Klimmzüge umzusetzen sein.

Meinungen dazu?

[drhirn]

Was Lampenfarben betrifft bin ich vorbehaltlos. Ich will sagen "schalte die lampe auf rot" und FHEM soll das tun. Wie, ist mir egal

...wenn wir grade beim Verzichten sind: Ich würde auch rhasspyChannels mittelfristig eher anderswo verorten und daher von vornherein das Attribut nicht "global" hinterlegen.

Hintergrund:
- Eigentlich ist das auch eine "Sonderregelung" für lediglich einzelne Devices, und mit globalen Attributen sollte man m.E. sparsam sein.
- Man könnte es vermutlich mehr oder weniger 1:1 in "specials" einbauen, indem man einfach ein "channel=" davorsetzt und dann diese Zeilen einer Sonderbehandlung zuführt. Sollte auch ohne größere Klimmzüge umzusetzen sein.

Meinungen dazu?

Keine gute .
rhasspyChannels ist für mich extrem wichtig. Darüber läuft bei mir sehr viel. TV-Kanäle, TV-Apps, Lichtszenen, etc. Dementsprechend umfangreich ist das Attribut auch teilweise befüllt. Und somit sollte es leicht zu konfigurieren sein. Ob jetzt extra ein userattr anlegen einfacher ist, als "specials" zu befüllen ist natürlich fraglich.
Wir können's wieder optional machen. War ja nicht meine Idee, dass automatisch global zu setzen

[Beta-User]

Ging nicht darum, die Funktionalität von "channels" entfallen zu lassen oder zwanghaft eine andere Syntax zu verordnen. Wer es hat: alles gut...

Werde bei Gelegenheit mal versuchen, das entsprechend aufzugleisen, dass es _auch_ über "specials" abgebildet ist.
Aber vor dem Gang ins svn sollte man m.E. auch das Attribut (wieder) deaktivieren, hoffe, zur Deaktivierung noch spätestens morgen ein update liefern zu können.

"scene" ist sowieso noch ein spezielles Thema. Vermutlich dann auch in "specials" zu verorten, aber darum kümmere ich mich erst, wenn "colors" läuft... Grob skizziert: 'scene=<techname>="schalte den Fernesmodus ein"' könnte dann den Satz an Rhasspy übermitteln und daraus einen Eintrag im  "SetScene"-Intent generieren, mit '(schalte den Fernesmodus ein){Scene:techname} {Device:<alias>)'

[drhirn]

Ging nicht darum, die Funktionalität von "channels" entfallen zu lassen oder zwanghaft eine andere Syntax zu verordnen. Wer es hat: alles gut...

Hab ich auch nicht so verstanden.

Werde bei Gelegenheit mal versuchen, das entsprechend aufzugleisen, dass es _auch_ über "specials" abgebildet ist.
Aber vor dem Gang ins svn sollte man m.E. auch das Attribut (wieder) deaktivieren, hoffe, zur Deaktivierung noch spätestens morgen ein update liefern zu können.

"scene" ist sowieso noch ein spezielles Thema. Vermutlich dann auch in "specials" zu verorten, aber darum kümmere ich mich erst, wenn "colors" läuft... Grob skizziert: 'scene=<techname>="schalte den Fernesmodus ein"' könnte dann den Satz an Rhasspy übermitteln und daraus einen Eintrag im  "SetScene"-Intent generieren, mit '(schalte den Fernesmodus ein){Scene:techname} {Device:<alias>)'

Was ich noch nicht verstanden habe ist, warum wir nicht einfach das Attribut als userattr belassen

[Beta-User]

Gute Frage...

Evtl. irgenr wann mal c, ct und r-Optionen...?

[drhirn]

Könnte ich doch auf mit dem eigenen Attribut machen. Oder nicht?

[drhirn]

Ich hab mir mein Codierungsproblem jetzt den ganzen Tag angesehen. Und irgendwann mal eine ganz alte Version (0.4.3) hergenommen. Damit passt alles. Ich weiß nur nicht, warum.

[Beta-User]

Ich hab mir mein Codierungsproblem jetzt den ganzen Tag angesehen. Und irgendwann mal eine ganz alte Version (0.4.3) hergenommen. Damit passt alles. Ich weiß nur nicht, warum.

Werde mir mal ein diff zwischen den beiden Versionen ansehen, mal schauen.

Habe grade mal versucht, dem ESP32 die siteId "Küche" zuzuweisen, aber da bekommt er scheinbar keinen Kontakt zur base; mit "wohnzimmer" und "buero" geht es hingegen. Ist daher etwas schwierig zum schnellen Testen, muss wohl doch bei Gelegenheit mal den Pi ins WLAN lassen...

Könnte ich doch auf mit dem eigenen Attribut machen. Oder nicht?

Ja, nein, vielleicht; bin wie gesagt unsicher...

Meine Sorge: Zu viele mögliche Attribute sind m.E. wirklich übersichtlicher, und gerade Einsteiger tun sich mit dem Konzept "userattr" gerne schwer. Daher tendiere ich eher zu der Überzeugung, dass man - neben den "Haupt-RHASSPY-Attributen" eigentlich nur noch eines braucht. Das kann dann zwar viele unterschiedliche Inhalte haben, aber typischerweise für eine "Geräte-Art" eben immer nur eine kleine Auswahl.
Im Moment bin ich aber an der Hinsicht in etwa noch genaus "blind" wie ich es vor kurzem noch zu "Color" war. Bei "Color" handelt es sich mAn. eigentlich nur um eine Unterart von Set..., von daher ist das da "eindeutiger" in dem generischen rasspyMapping anzusiedeln.

Kann aber auch verstehen, dass da ggf. Sorgen bestehen, dass die Syntax "schwierig" ist. Andererseits: Wenn es mehr oder weniger dasselbe ist wie z.B. in "shortcut", wird es (hoffentlich) schnell ein paar Leute geben, die Beispiele parat haben und/oder Einsteigern helfen können. Wir werden sehen, ist vorläufig nicht so wichtig, da eine Entscheidung in die eine oder andere Richtung zu treffen (wichtiger wäre z.B. das Kodierungsproblem).


Vielleicht im Nachgang zu der Funktionsnamensthematik noch: Es gibt einen Punkt, der uns uU. dabei rausgegangen ist: Wenn die Funktion via InternalTimer verwaltet wird (oder werden kann), dann sollte sie in "fhemdebug timerList" möglichst zuordenbar sein. Kann also sein, dass man das an einigen wenigen Stellen nochmal checken sollte... 

[drhirn]

Werde mir mal ein diff zwischen den beiden Versionen ansehen, mal schauen.

Das Problem liegt hier:

Code Auswählen Erweitern

$decoded  = decode_json(encode($cp,$json))
Also konkret im decode_json. Danach kommt nur Müll raus. Aber ich versteh zum einen nicht, warum plötzlich. Und zum anderen nicht, wie ich's lösen könnte.

gerade Einsteiger tun sich mit dem Konzept "userattr" gerne schwer.

Stimmt. Kenn ich aus eigener Erfahrung.

Vielleicht im Nachgang zu der Funktionsnamensthematik noch: Es gibt einen Punkt, der uns uU. dabei rausgegangen ist: Wenn die Funktion via InternalTimer verwaltet wird (oder werden kann), dann sollte sie in "fhemdebug timerList" möglichst zuordenbar sein. Kann also sein, dass man das an einigen wenigen Stellen nochmal checken sollte... 

Ja, genau. Was? Kein Wort verstanden

[Beta-User]

Das Problem liegt hier:

Code Auswählen Erweitern

$decoded  = decode_json(encode($cp,$json))
Also konkret im decode_json. Danach kommt nur Müll raus. Aber ich versteh zum einen nicht, warum plötzlich. Und zum anderen nicht, wie ich's lösen könnte.

Vielleicht ist an der Stelle die Info bzgl. utf8 verloren gegangen. Muss mal schauen. "ganz früher" stand da mal ausdrücklich utf8, dann wollte jemand was anderes haben, usw.. Fand das gestern seltsam, dass es nicht im list auftaucht und vermute ein Problem bei der Initialisierung oder beim Abholen von dem Ort, an dem es stehen sollte.

Jetzt erst mal eine Version, die
a) auch Channels als userattr vorsieht (cref ist angepaßt) und
b) eine reparierte _ct2rgb enthält. Sieht von der HEX-Darstellung her ok aus.

Stimmt. Kenn ich aus eigener Erfahrung.

(Fand das früher auch "häh...?!?"...)
...und so gibt es eben für alles mögliche Pro- und Contra-Argumente....

Ja, genau. Was? Kein Wort verstanden

Da geht es darum, dass man manchmal zu debugging-Zwecken als Entwickler auch mal anschaut, welche Timer grade warum laufen. Und wenn das "unleserlich" ist, was man angezeigt bekommt, ist das nicht schön...
(ggf. einfach mal "help fhemdebug" ansehen, ist durchaus interessant).

[drhirn]

Vielleicht ist an der Stelle die Info bzgl. utf8 verloren gegangen. Muss mal schauen. "ganz früher" stand da mal ausdrücklich utf8, dann wollte jemand was anderes haben, usw.. Fand das gestern seltsam, dass es nicht im list auftaucht

Ja. Aber zum einen wurde das schon lange umgebaut. Zum anderen ist's das selbe Problem, wenn ich die Zeile wieder so wie früher einbaue. Und Dumper ist halt leider auch keine Hilfe, weil der wieder anders codiert.
Probier einfach mal aus, was bei dir bei einem Umlaut in der siteId passiert. Ich glaub echt, es liegt an mir. Aber ich hab jetzt schon diverse Neu- und Testinstallationen auf diversen Systemen hinter mir und komm nicht drauf, wo der Unterschied zu vor ein paar Tage ist.

Da geht es darum, dass man manchmal zu debugging-Zwecken als Entwickler auch mal anschaut, welche Timer grade warum laufen. Und wenn das "unleserlich" ist, was man angezeigt bekommt, ist das nicht schön...
(ggf. einfach mal "help fhemdebug" ansehen, ist durchaus interessant).

Ahhhhhh. Man dankt!

[Beta-User]

Ja. Aber zum einen wurde das schon lange umgebaut. Zum anderen ist's das selbe Problem, wenn ich die Zeile wieder so wie früher einbaue. Und Dumper ist halt leider auch keine Hilfe, weil der wieder anders codiert.
Probier einfach mal aus, was bei dir bei einem Umlaut in der siteId passiert. Ich glaub echt, es liegt an mir. Aber ich hab jetzt schon diverse Neu- und Testinstallationen auf diversen Systemen hinter mir und komm nicht drauf, wo der Unterschied zu vor ein paar Tage ist.

Teste mal (ca.) in Zeile 336

Code Auswählen Erweitern

    $hash->{encoding} = $h->{encoding} // q{UTF-8};

Große Hoffnung habe ich nicht, aber eventuell ist das Problem, dass der Hash an der Stelle überhaupt da ist.

Wie gesagt: zum Testen bräuchte ich noch einen Satelliten, denn das mit dem ESP32 wollte grade auf die Schnelle nicht...

[drhirn]

Kein Unterschied.

Naja, du hättest noch einen Satelliten

[Beta-User]

Schon klar, und mit dem werde ich das dann auch testen.

(Auch wenn der betreffende sehr gut aussieht: Ich mag Pi's einfach nicht. Ist ähnlich wie mit ESP8266...)