Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

drhirn


drhirn

Zitat von: Beta-User am 24 April 2021, 08:25:42
Hier dann noch der Versuch, den "Hue-Farbkreis" zu übersetzen:

[de.fhem:SetColor]
colors=( rot{Hue:0} | orangerot{Hue:15} | orange{Hue:30} | goldgelb{Hue:45} | ([(zitrus|zitronen)] gelb){Hue:60} | (gelb grün){Hue:75} | (grün gelb){Hue:90} | ((grass|hell) grün){Hue:105} | grün{Hue:120} | (dunkel grün){Hue:135} | (smaragd grün | wasser blau){Hue:150} | (türkis [grün] | grün blau ){Hue:165} | (türkis [blau] | blau grün ){Hue:180} | (azur [blau]){Hue:210}  | ([blau] violet){Hue:225} | ([marine] blau){Hue:240} | ([blau] violet){Hue:255} | (rosa){Hue:270} | (purpur [blau]){Hue:285} | (magenta [blau]){Hue:300} | (alt rosa){Hue:315} | (rubin rot){Hue:330} | (karmin rot){Hue:345} )
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (<colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] (<de.fhem:SetColor.colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


Damit ich auch wieder mal etwas sinnvolles beitrage:

Ich habe mir gerade einen Slot mit allen "HUE Farben" erzeugt, die ich so gefunden habe. Der heißt einfach hueColor:

braun:20
grüngelb:90
blaurot:330
leichtes grüngelb:75
grünblau:210
rot:0
grün:120
magenta:300
indigo:255
dunkelgrün:120
leichtes blaurot:345
zinnober:15
cyan:180
leichtes grünblau:225
leichtes blaugrün:135
limett:105
orange:30
blaugrün:150
gelb:60
blau:240
blaumagenta:315
grüncyan:165
violett:270
blaucyan:195
rotmagenta:315
safran:45


Und den dann in die sentences eingebaut, um den HUE-Wert einer Lampe zu ändern:

\[setze|färbe|stelle] [der|die|das] $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] [auf] [die Farbe] $hueColor{Hue}


Ist im Prinzip das gleiche, wie du auch gemacht hast. Nur übersichtlicher.
Deswegen meinte ich, dass wir das einfach in das Language-File einbauen. Und daraus einen Slot erstellen. Dann hat's jeder gleich zur Verfügung ohne sich zuerst einen Slot bauen zu müssen.
Geht aber natürlich so auch.



Ich bekomme da übrigens Komma-Werte für Hue (z.B. 57343.125). Ist das ein Problem oder soll das so sein?

Beta-User

Zitat
Ich bekomme da übrigens Komma-Werte für Hue (z.B. 57343.125). Ist das ein Problem oder soll das so sein?
Na ja, meine HUEDevices akzeptieren das so, es wird halt gerechnet. Nach Ausführung steht dann da wieder ein ganzzahliger Wert. Können auch zwecks besserer  Optik runden?

Zitat von: drhirn am 24 April 2021, 18:18:13
Damit ich auch wieder mal etwas sinnvolles beitrage:
Auch diese ganze Testerei usw. ist extrem wichtig!

Die Idee mit dem "slot aus config" finde ich umso besser, je länger ich darüber nachdenke!
Mit meinem sentence wollte ich v.a. erst mal eine Grundlage zum Testen bereitgestellt haben, slot ist eigentlich das Mittel der Wahl, ist aber m.E. dieselbe Kategorie wie userattr: Man denkt erst mal "watndat"?
Denke aber, es würde Sinn machen, das feature generisch auszulegen, also z.B. dann für jeden Eintrag im Abschnitt  "slots" dann auch einen solchen zu generieren. Dann könnten wir z.B. auch einen für Rgb und OnOff bereitstellen. Wenn der User die nicht mag, kann er entweder andere Inhalte in die configfile reinschreiben, oder eben den slot kopieren, abändern und dann einen eigenen Namen dafür vergeben.



Der Pi hängt jetzt zwar im Netz, aber sonst ist erst mal nicht viel. Vermute einen Anfängerfehler, hier die settings:

{
    "microphone": {
        "pyaudio": {
            "device": "0"
        },
        "system": "pyaudio"
    },
    "mqtt": {
        "enabled": "true",
        "host": "ip vom fhem-server",
        "port": "1884",
        "site_id": "Küche"
    },
    "sounds": {
        "aplay": {
            "device": "default:CARD=seeed2micvoicec"
        },
        "system": "aplay"
    },
    "text_to_speech": {
        "system": "nanotts"
    },
    "wake": {
        "system": "hermes"
    }
}


Zitat von: drhirn am 24 April 2021, 17:56:38
Huch. Warum das?
Die Dinger haben ein paar grundlegende Mängel, angefangen bei der SD-Karten-Thematik und der Nutzung der GPIO's, die v.a. Anfänger dazu verleiten, Server und Hardware in der Hausautomatisierung zu vermischen. (Aktuelles Beispiel: https://forum.fhem.de/index.php/topic,120658.0.html Wenn man schon einen ATMEga dazwischenklemmt, dann übermittelt man per USB und gut ist...)


Daher mag ich für alle zwecke, die man mit ebensolchen erledigen kann Microcontroller lieber. Daher auch noch ein Screenshot von dem ESP32-Ding, das als Mikro überraschend gut funktioniert, wenn man direkt reinspricht, aber halt bauartbedingt einen miesen Soundoutput hat...
(Es gibt den ESP32 auch als "backiges" Board mit spezieller Soundausstattung, an die man dann auch einen 3W-Speaker klemmen kann. Wäre eventuell auch einen Test wert...)
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 25 April 2021, 10:29:11Na ja, meine HUEDevices akzeptieren das so, es wird halt gerechnet. Nach Ausführung steht dann da wieder ein ganzzahliger Wert. Können auch zwecks besserer  Optik runden?
Wäre irgendwie schöner. Dachte nur, da gibt's vielleicht irgendwelche Vorgaben.

ZitatDenke aber, es würde Sinn machen, das feature generisch auszulegen, also z.B. dann für jeden Eintrag im Abschnitt  "slots" dann auch einen solchen zu generieren. Dann könnten wir z.B. auch einen für Rgb und OnOff bereitstellen. Wenn der User die nicht mag, kann er entweder andere Inhalte in die configfile reinschreiben, oder eben den slot kopieren, abändern und dann einen eigenen Namen dafür vergeben.
Meine Rede :D

ZitatDer Pi hängt jetzt zwar im Netz, aber sonst ist erst mal nicht viel. Vermute einen Anfängerfehler, hier die settings:
Wakeword fehlt. Das wird nur für die App an der Base konfiguriert. Ein regulärer Satellit macht das Wakeword selbst und überträgt dann an die Base nur, was gesprochen wurde.

ZitatDie Dinger haben ein paar grundlegende Mängel, angefangen bei der SD-Karten-Thematik und der Nutzung der GPIO's, die v.a. Anfänger dazu verleiten, Server und Hardware in der Hausautomatisierung zu vermischen.
Es ist wie bei allem: Man sollte schon wissen, was man tut. Das mit der SD ist ein Problem. Aber, das Ding war ja als billige Lernplattform gedacht. Konnte ja keiner ahnen, dass die so "missbraucht" werden. RPi und ESP sind für mich zwei paar Schuhe.

Zitat
(Es gibt den ESP32 auch als "backiges" Board mit spezieller Soundausstattung, an die man dann auch einen 3W-Speaker klemmen kann. Wäre eventuell auch einen Test wert...)
Hast du da einen Link bitte?

drhirn

#529
Hier die Config meines RPi-Satelliten:

{
    "intent": {
        "system": "hermes"
    },
    "microphone": {
        "pyaudio": {
            "udp_audio_port": "12202"
        },
        "system": "pyaudio"
    },
    "mqtt": {
        "enabled": "true",
        "host": "ip-der-base",
        "port": "12183",
        "site_id": "vorraum"
    },
    "sounds": {
        "system": "aplay"
    },
    "speech_to_text": {
        "system": "hermes"
    },
    "text_to_speech": {
        "system": "hermes"
    },
    "wake": {
        "porcupine": {
            "keyword_path": "porcupine_raspberry-pi.ppn",
            "udp_audio": "12202"
        },
        "system": "porcupine"
    }
}


Ahhh, blödes Timeout in den Screenshot mitgerutscht. Soll dich nicht nervös machen. Liegt dran, dass die Base nicht läuft.

Beta-User

Zitat von: drhirn am 25 April 2021, 10:44:53
Wäre irgendwie schöner. Dachte nur, da gibt's vielleicht irgendwelche Vorgaben.
Keine Vorgaben, round wird eingebaut...

Zitat
Meine Rede :D
;D ... ist ja schon gut, kommt bei Gelegenheit...

Zitat
Wakeword fehlt. Das wird nur für die App an der Base konfiguriert. Ein regulärer Satellit macht das Wakeword selbst und überträgt dann an die Base nur, was gesprochen wurde.
:-[ bin wohl zu doof für diese Sache... Jetzt habe ich (bis auf den abweichenden Port) fast alle Einstellungen auf identisch, wobei dann nur noch die porcupine_linux statt .*_pi angezeigt wird.
Will irgendwie noch nicht, das ganze.

Zitat
Es ist wie bei allem: Man sollte schon wissen, was man tut. Das mit der SD ist ein Problem. Aber, das Ding war ja als billige Lernplattform gedacht. Konnte ja keiner ahnen, dass die so "missbraucht" werden. RPi und ESP sind für mich zwei paar Schuhe.
Na ja, am Anfang konnte keiner ahnen, dass die Dinger so eine große Verbreitung finden.
Aber "irgendwann" hätte man ein SSD-Interface (M.2? auf die Rückseite) und eine (von mir aus über einen Kondensator gespeiste) RTC einbauen können...

Und ja, es sind zwei Paar Stiefel. Daher: Was man mit einer MCU erledigen kann, sollte man mAn. damit erledigen.

Zitat
Hast du da einen Link bitte?
Hoffe, mit den Suchworten aus dem ESP32-github-Dingens das richtige bestellt zu haben: https://smile.amazon.de/dp/B085ZLFBDB?psc=1&smid=AMW1WIDE8JCF7&ref_=chk_typ_imgToDp
Oder:
https://de.aliexpress.com/item/1005001889297112.html?albpd=de1005001889297112&acnt=494-037-6276&aff_platform=aaf&albpg=539263010115&netw=u&albcp=12554800262&pvid=0ac021fa-a99a-43ae-89c7-d86ef2759f01&sk=UneMJZVf&scm=1007.23534.124000.0&trgt=539263010115&terminal_id=dddd910e988e467bb38bfe40c3488535&needSmbHouyi=false&albbt=Google_7_shopping&src=google&crea=de1005001889297112&aff_fcid=87af2e3631fc4783bebac73b2d67a9ed-1619340281444-03840-UneMJZVf&gclid=EAIaIQobChMIxbfdyYCZ8AIVCrh3Ch2L8wV3EAQYAyABEgLdXPD_BwE&albag=127990761348&aff_fsk=UneMJZVf&albch=shopping&albagn=888888&isSmbAutoCall=false&aff_trace_key=87af2e3631fc4783bebac73b2d67a9ed-1619340281444-03840-UneMJZVf&rmsg=do_not_replacement&device=c&gclsrc=aw.ds

Jetzt lege ich das erst mal auf die Seite und genieße die Sonne...
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 25 April 2021, 12:14:47
:-[ bin wohl zu doof für diese Sache... Jetzt habe ich (bis auf den abweichenden Port) fast alle Einstellungen auf identisch, wobei dann nur noch die porcupine_linux statt .*_pi angezeigt wird.
Will irgendwie noch nicht, das ganze.
Da gibt's ja einen Refresh-Button neben "Available Keywords". Drück den mal und wähl dann "porcupine" aus.
Und oben gibt's den grauen Log-Button. Lass das mal mitlaufen, wenn du das nächste Mal ein Wakeword sprichst. Bzw. auch einen MQTT-Explorer.

ZitatAber "irgendwann" hätte man ein SSD-Interface (M.2? auf die Rückseite) und eine (von mir aus über einen Kondensator gespeiste) RTC einbauen können...
Macht's halt wieder teurer.

ZitatHoffe, mit den Suchworten aus dem ESP32-github-Dingens das richtige bestellt zu haben: https://smile.amazon.de/dp/B085ZLFBDB?psc=1&smid=AMW1WIDE8JCF7&ref_=chk_typ_imgToDp
Danke!

ZitatJetzt lege ich das erst mal auf die Seite und genieße die Sonne...
Tu das! Irgendwann, irgendwann hab ich dann auch mal Balkon, Terrasse oder Garten und kann das auch ;).

Beta-User

So ein M....

Also: stelle ich auf arecord, bekommt mosquitto_sub ordentlich was zu sehen.
TTS funktioniert auch, wenn ich über das WEB-Interface was ausgeben lasse.

Ergo: Hardware ist funktional, es ist irgendein 60cm-Problem...

Eigentlich sollte es doch auch möglich sein, mit dem Button einen Dialog zu eröffnen? Aber da sehe ich auch schlicht und ergreifend nichts via MQTT, weder irgendwelche Dialog-Management Messages, noch irgendwas, das nach Audio für die Intent-Recognition aussieht.
(Vermutlich zu viel Sonne, und jetzt ist auch der Weißburgunder lecker, also ein andermal wieder RTFM...)
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

#533
Nimm einfach meine Konfiguration. Die hat auf deinem auch funktioniert.
UDP für Wakeword und Audio Recording auf einen beliebigen Port stellen (ich nehm immer 12202), dann fließt nicht dauernd Audio über's Netzwerk sondern nur, wenn das Wakeword erkannt wurde.

Der Button tut standardmäßig nichts. Da müsstest du ein Script schreiben, dass den GPIO abgreift. Hab ich noch nie gemacht. Aber andere können da sicher mit Links oder Scripts helfen.

---edit---
Hier z.B.: https://community.rhasspy.org/t/using-respeaker-button-for-wake/370

Beta-User

#534
Nun ja, vermutlich war es keine gute Idee, den docker-Container direkt auf 2.5.10 zu heben, da scheint was schiefgegangen zu sein; sieht irgendwie so aus, als wäre pyaudio kaputt.

Leider klemmt sich der ESP32 mit einer Umlaut-siteId zuverlässig vom MQTT-Verkehr ab, dto. für die App. Mit etwas tricksen kann ich allerdings "Unterstrich"-listening-Readings erzeugen, immerhin...

Na ja, bei anderen Dingen war ich erfolgreicher:
- "slots" via languagefile sollten jetzt funktionieren, Beispiel anbei;
- es gibt jetzt auch noch "Gruppen-gDT"-slots;
- Farbe bei Hue kann man erzwingen, wenn man ein "special" setzt:
attr Licht_Essen rhasspySpecials colorForceHue2rgb:1
(kurz angetestet, scheint zu funktionieren)
- hue usw. wird auf Ganzzahl gerundet;
- es gibt ein weiteres color-special (noch ungetestet), "colorCommandMap":
Da schreibe ich mal die Syntax noch nicht auf, im Moment sieht es mir danach aus, als bräuchte ich eventuell eine Option, die nach Color, Hue, ... und Colortemp unterscheidet. Im Moment sollte man beliebige Werte (nur) aus Color nach irgendwas mappen können (wie die "alten" Colours "0='rgb FF0000'" ).
- die Funktionen, die als Timeraufrufe verwendet werden können, haben jetzt wieder den RHASSPY_-Prefix. Finde es besser, wenn man in fhemdebug sehen kann, wo die hingehören.

(Danke für das scrpit für den PGIO, schaue ich mir bei Gelegenheit mal an).
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

Bei mir läuft auch alles auf 2.5.10

Ist hue wirklich so verbreitet? Ich hab das noch nie verwendet. Immer nur RGB und PCT für die Helligkeit.

Was war das Problem beim Einbinden von Color.pm?

Und, derzeit kann ich keine Lampen regeln, die nur die Lichtfarben (ct) unterstützen, weil immer das rgb-mapping verlangt wird. Muss das so sein?

Ich hab gestern noch bei Delete $prefix definiert. Das hat gefehlt.

drhirn

Zitat von: Beta-User am 26 April 2021, 08:18:41
Im Moment sollte man beliebige Werte (nur) aus Color nach irgendwas mappen können (wie die "alten" Colours "0='rgb FF0000'" ).

Wie meinst du das?

Beta-User

Zitat von: drhirn am 26 April 2021, 08:28:00
Bei mir läuft auch alles auf 2.5.10
Der Pi hing gestern eine Zeitlang, ich dachte, er wäre abgeschmiert; evtl. ist dadurch was in pyaudio nicht richtig aktualisiert worden. K.A., ich werde den Container bei Gelegenheit nochmal pullen, vielleicht hilft das.

Zitat
Ist hue wirklich so verbreitet? Ich hab das noch nie verwendet. Immer nur RGB und PCT für die Helligkeit.
Kann ich nicht sagen, ob das "so verbreitet" ist. Meine beiden Farb-Typen konnten das eben, und ich finde das Konzept des 360°-Farbkreises eigentlich ganz einleuchtend.
Dagegen haben die RGBW-MiLights derzeit nicht mal ein rgb-Kommando (was ich auch erst festgestellt habe, nachdem die mit dem umgebogenen korrigierten ct-Code immer noch nicht wollten ::) ). Die wollen einen JSON mit den Einzelkanälen, was bisher wurst war, weil wenn Farbe, dann hue...

Vermutlich muss der mapping-Analyse-Code nochmal verändert werden, denn nachdem ich jetzt mal z.B. gesehen habe, wie das z.B. für zigbee2mqtt-Farb-Leuchten gemacht ist, fehlen da noch wichtige Details, v.a. zu HEX (das scheint aber nur "kleingeschriebenes" rgb zu sein)...

Zitat
Was war das Problem beim Einbinden von Color.pm?
Die Funktion wird nicht exportiert und fehlt daher in @INC. Hatte keine Neigung, dem grade intensiver nachzugehen...

Zitat
Und, derzeit kann ich keine Lampen regeln, die nur die Lichtfarben (ct) unterstützen, weil immer das rgb-mapping verlangt wird. Muss das so sein?
Wie machst du das genau?
Über den Color-slot kann es nicht funktionieren, bei mir waren da ein paar Weiß-Elemente mit dabei, die explizit in "Colortemp" übergeben wurden/werden. Vermutlich muss man dafür einen separaten slot anlegen und dann diesen slot als alternativen Farbwert in sentences.ini hinterlegen.
Ggf. hilft mir ein RAW-listing vom Zieldevice?

ZitatIch hab gestern noch bei Delete $prefix definiert. Das hat gefehlt.
stimmt.
Löschen bzw. umbenennen der Attribute ist aber eh' noch ein Thema...

Zitat von: drhirn am 26 April 2021, 10:03:36
Wie meinst du das?
Im Moment sollte sowas hier funktionieren:
attr Licht_Essen rhasspySpecials colorCommandMap:0='rgb FF0000' 120='rgb 00FF00' 240='rgb 0000FF'Damit würde aus einer im JSON-Element "Color" übergebenen Zahl der betreffende Befehl zugeordnet (ist "hinten" nicht auf rgb beschränkt, und wenn "vorne" ein RGB steht und RGB übergeben wurde, müßte es auch klappen). Oder wenn "grün" übergeben wurde, kann man eine heu-Befehl daraus basteln usw. usf.
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 26 April 2021, 10:39:50und ich finde das Konzept des 360°-Farbkreises eigentlich ganz einleuchtend.

Ja, ist nicht blöd.

ZitatWie machst du das genau?
Über den Color-slot kann es nicht funktionieren, bei mir waren da ein paar Weiß-Elemente mit dabei, die explizit in "Colortemp" übergeben wurden/werden. Vermutlich muss man dafür einen separaten slot anlegen und dann diesen slot als alternativen Farbwert in sentences.ini hinterlegen.
Ggf. hilft mir ein RAW-listing vom Zieldevice?

Gar nicht merke ich gerade, weil mir das HUE Modul das nicht (mehr) zur Verfügung stellt!? War der Meinung, ich hätte das mal gemacht. Das Reading ist nämlich da.

define HUEDevice6 HUEDevice 6  IODev=hueBridge2
attr HUEDevice6 userattr light lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 light_map structexclude
attr HUEDevice6 IODev hueBridge2
attr HUEDevice6 alias hueFloorLamp01Wz
attr HUEDevice6 color-icons 2
attr HUEDevice6 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEDevice6 group Wohnzimmer
attr HUEDevice6 icon hue_filled_lightstrip
attr HUEDevice6 model FLS-H3
attr HUEDevice6 room Wohnzimmer->Licht,Beleuchtung,HUEDevice
attr HUEDevice6 subType dimmer
attr HUEDevice6 webCmd pct:dimDown:dimUp:toggle:on:off

setstate HUEDevice6 on
setstate HUEDevice6 2021-04-24 15:19:20 alert select
setstate HUEDevice6 2021-04-24 15:19:20 bri 254
setstate HUEDevice6 2021-04-24 15:19:20 colormode ct
setstate HUEDevice6 2021-04-24 15:19:20 ct 500 (2000K)
setstate HUEDevice6 2021-04-26 10:56:36 onoff 1
setstate HUEDevice6 2021-04-26 10:56:36 pct 100
setstate HUEDevice6 2021-04-25 22:42:26 reachable 1
setstate HUEDevice6 2021-04-24 15:19:20 rgb ffb16e
setstate HUEDevice6 2021-04-26 10:56:36 state on



ZitatIm Moment sollte sowas hier funktionieren:
attr Licht_Essen rhasspySpecials colorCommandMap:0='rgb FF0000' 120='rgb 00FF00' 240='rgb 0000FF'Damit würde aus einer im JSON-Element "Color" übergebenen Zahl der betreffende Befehl zugeordnet (ist "hinten" nicht auf rgb beschränkt, und wenn "vorne" ein RGB steht und RGB übergeben wurde, müßte es auch klappen). Oder wenn "grün" übergeben wurde, kann man eine heu-Befehl daraus basteln usw. usf.

Aha. Nett!

Das Licht-Thema nervt. Sollen wir's vorläufig lassen und uns auf etwas anderes konzentrieren? Und bezüglich Licht im Forum mal nach schlauen Ideen fragen?

Beta-User

#539
Zitat von: drhirn am 26 April 2021, 11:07:07
Das Licht-Thema nervt. Sollen wir's vorläufig lassen und uns auf etwas anderes konzentrieren? Und bezüglich Licht im Forum mal nach schlauen Ideen fragen?
Ja, finde es auch nervig, _glaube_ aber, ein paar mehr setter bereits eingefangen zu haben; müßte nur zum Testen mal ein paar passende Devices bauen, die hex, color_temp usw-Setter haben...

Vorab aber die eher wichtige Sache:
Zitat von: drhirn am 24 April 2021, 16:55:43
Das Problem liegt hier:
$decoded  = decode_json(encode($cp,$json))
Der default für $cp ist jetzt "UTF-8".

Davor war es:
$decoded  = decode_json(encode_utf8($json))
Nun sollte man annehmen, das sei dasselbe. Ist es aber nicht: https://perldoc.perl.org/Encode#encode_utf8
Zitat
Equivalent to $octets = encode("utf8", $string). [...]
WARNING: do not use this function for data exchange as it can produce $string with not strict utf8 representation! For strictly valid UTF-8 $string representation use $string = decode("UTF-8", $octets [, CHECK]).
Aha... utf8 und UTF-8 sind nicht dasselbe, und das steht auch so in der Doku, siehe https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8

Augenreib, aber na ja... Vermutlich wäre es daher sinnvoll, mal "utf8" zum default zu erklären (bzw. über die DEF vorzugeben; das ist jetzt in der Fassung anbei so, ich weiß aber noch nicht, ob das nicht an anderer Stelle unangenehme Nebenwirkungen hat!).

Sorry für den "lapsus"!

Zitat von: drhirn am 26 April 2021, 11:07:07
Gar nicht merke ich gerade, weil mir das HUE Modul das nicht (mehr) zur Verfügung stellt!? War der Meinung, ich hätte das mal gemacht. Das Reading ist nämlich da.
Das Verhalten von Leuchten ist manchmal "komisch". Die HUEDevice "sollten" es eigentlich können, wenn es das Leuchtmittel hergibt; da wäre bei der speziellen Leuchte dann interessant, was "getAllSets()" auswirft?
Kann nicht sagen, ob justme1968 da was dran rumgebastelt hat, und ob das nicht auch ein Überbleibsel von einer Gruppensteuerung sein könnte...
Habe btw. auch eine MiLight-Fernbedienung, die irgendwie manchmal (vermittelt durch den Eigenbau-MiLight-Hub) "komische" Rückmeldungen aus dem Farbrad bringt; das scheint teilweise auch davon abzuhängen, in welchem Modus die grade ist. In diese Richtung scheint auch "colormode" zu gehen? (Endlose Weiten...).

ZitatUnd bezüglich Licht im Forum mal nach schlauen Ideen fragen?
Ja, vielleicht, nein...

Da ich schon bei geschlagenen zwei (!) Gerätetypen nicht auf einen eigenen Nenner komme, befürchte ich, dass das zu nichts führt, weil die Vorstellungen davon, wie das sein müßte dann wieder sehr weit auseinandergehen.
Ich _glaube_ daher, dass wir die Hue- und Rgb-Optionen halbwegs funktional haben sollten (will sagen: den Rgb-slot in der language-file drin) und das mit dem Mapping (ohne separates Attribug) klappen sollte. Dann ist es so universell, dass man 80/20 behaupten kann, dass es funktioniert.
Bin guten Mutes, dass wir genau diesen Stand erreicht haben. Mein verbliebenes "Colortemp"-Problem sollte dann dadurch gelöst werden, dass ich einfach einen passenden setter für die MiLight-MQTT2-Devices generiere. (Das ist kein Hexenwerk...).
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