Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

drhirn

Das mit dem M muss dir Beta-User beantworten.

Und bzgl. Sprache ist Mitarbeit herzlich willkommen. Ich kann zwar "einen Aschenbecher bitte" in ziemlichen vielen Sprachen. Aber ansonsten ist bei mir nach Englisch und Deutsch leider Schluss.

Beta-User

Vorab mal sorry für die übersehene "Unvollendete"...

Der Plan war eigentlich, an der Stelle zwei "Andockstellen" einzubauen, nämlich für Code ("rhasspyTweaks") und für das Auslesen eines zusätzlichen Readings (siteId2room_mobile1 etc.). Das klappt aber grade noch nicht so, wie ich mir das vorstelle, daher ein andermal mehr dazu.

Falls jemand Lust hat, das auszutesten bzw. weiter zu entwickeln, das ist mein aktueller Stand:
sub RHASSPY_roomName {
    my $hash = shift // return;
    my $data = shift // return;

    # Slot "Room" im JSON vorhanden? Sonst Raum des angesprochenen Satelites verwenden
    return $data->{Room} if exists($data->{Room});
   
    my $room;
   
    #Beta-User: This might be the right place to check, if there's additional logic implemented...
   
    my $rreading = makeReadingName("siteId2room_$data->{siteId}");
    $room = ReadingsVal($hash->{NAME}, $rreading, $data->{siteId});
    $room = $hash->{helper}{defaultRoom} if ($room eq 'default' || !(length $room));

    return $room;
}




Zitat von: laberlaib am 27 März 2021, 21:44:35
Und wie gut ist das bitte mit der Sprachkonfig? Hat auf Anhieb geklappt.
8)

Wäre natürlich nett, wenn du eine spanische Variante einstellen könntest...

Zitat
Die prefix-Geschichte für unterschiedliche Attribute, die geht noch nicht wenn ich das richtig verstehe.
ist das eine Rückmeldung oder eine Frage?!?

"Eigentlich" müßte das mAn. funktionieren, aber getestet habe ich es bisher nicht. Was (derzeit) NICHT geht, wäre das prefix im laufenden Betrieb zu ändern, aber eine zweite Instanz mit anderem (auch nachträglich geändertem) prefix sollte eigentlich ohne weiteres laufen.




Schon jemand mit den Timern rumgespielt? Leider paßt da scheinbar noch nicht alles, aber ich bekomme immerhin gelabelte Timer, und kann die auch - entgegen der Rückmeldung - abschießen...

Die sind jetzt als "temporary"-at angelegt und daher nur noch via list-Kommando zu sehen; weiß noch nicht, ob das eine gute Idee ist.

Hier noch der sentences-Teil zum labeln und testen:
[de.fhem:SetTimer]
labels=( Wecker | Eier | Kartoffeln | Tee )
( Lösche | entferne ){Cancel} [den] ( timer | wecker ) [<labels>{label}]




Das mit den fehlenden "m" sind tendenziell Typos, sollte man wohl noch verbessern.

Und das mit der gegenderten Form ist auch im deutschen ein Thema (z.B. bei Räumen), bisher habe ich dazu noch keine Idee. Wäre aber natürlich schon eleganter, wenn man das irgendwie gelöst bekäme - geht aber nicht, ohne dass der User irgendwas dazu irgendwo einstellt...
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

laberlaib

#Fehlends M:
Das zieht sich aber durch den Code durch, z.B. Zeile 1011:
$response = $hash->{helper}{lng}->{responses}->{DefaultCancelConfir};

Zitat von: Beta-User am 28 März 2021, 10:12:41
"Eigentlich" müßte das mAn. funktionieren, aber getestet habe ich es bisher nicht. Was (derzeit) NICHT geht, wäre das prefix im laufenden Betrieb zu ändern, aber eine zweite Instanz mit anderem (auch nachträglich geändertem) prefix sollte eigentlich ohne weiteres laufen.
Da muss ich mal "Folgefehler" rufen. in der README wird das define anders beschrieben, drum habe ich das nicht mit angegeben.
Ich wollte dann ja die cref aufrufen, was bei mir nicht funktionierte. Da ich das nun fixen konnte las ich das hier:
Zitatdefine <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Und kann neue Tests starten.

Zitat von: Beta-User am 28 März 2021, 10:12:41
Wäre natürlich nett, wenn du eine spanische Variante einstellen könntest...

https://github.com/laberlaib/fhem-rasspy-some-data

Da mach ich eine config-es.cfg und ein paar sentences.inis
Extra dafür mal einen github-Account gemacht und mich damit beschäftigt. Wie man das dann vererben, verlinken, commiten, pullen o.ä. kann, das finde ich auch noch irgendwie raus.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

Beta-User

Na ja, das mit dem "m" ist kein reiner Typo; hatte da mal "confirmation" stehen, aber das ist eben lang...

Habe nichts dagegen, wenn wir uns da auf einen "guten" Standard verständigen würden; hatte ja schon früher mal geschrieben, dass die Struktur der Sprachkonfig halt mal irgendwie auf die Schnelle entstanden ist ::) .

Scheint so, dass die cref jedenfalls was die Optionen in der DEF angeht, einigermaßen verständlich und vollständig zu sein scheint. Meine Empfehlung wäre auch, immer die param=xy-Schreibweise zu verwenden, einfach, weil andere das dann ggf. so nachmachen ;) . (Es ist m.E. weniger fehleranfällig)
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

JensS

Super, da hat sich ja eine ganze Menge getan.
sub RHASSPY_roomName {
    my $hash = shift // return;
    my $data = shift // return;

    # Slot "Room" im JSON vorhanden? Sonst Raum des angesprochenen Satelites verwenden
    return $data->{Room} if exists($data->{Room});
   
    my $room;
   
    #Beta-User: This might be the right place to check, if there's additional logic implemented...
   
    my $rreading = makeReadingName("siteId2room_$data->{siteId}");
#Ein ReadingsName wird erzeugt aber kein Reading angelegt, welches dann aber abgefragt wird?
    $room = ReadingsVal($hash->{NAME}, $rreading, $data->{siteId});
    $room = $hash->{helper}{defaultRoom} if ($room eq 'default' || !(length $room)); #Greift das noch, da $room im vorigen Schritt mindestensauf  $data->{siteId} gesetzt wird?

#Sollte man hier die Möglichkeit abbilden, wenn ein Satellit in einem Raum (z.B. Veranda) ohne zugeordnete Geräte steht und man in der Küche sagt: "Starte den Brötchen Timer in der Veranda in 10 Minuten!"?
#Dazu kann fetchSiteIds genutzt werden.

    return $room;
}

Zitatdefine <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Cool, da hat man viele Anpassungsmöglichkeiten bereits in der Definition.  8)

Zitatlabels=( Wecker | Eier | Kartoffeln | Tee )
Bei uns gab es heute zum Frühstück frisch aufgebackene Brötchen.  ;)

Ich finde es super, dass Rhasspy dank vieler Unterstützung an Bandbreite gewinnt. Wenn es einen stabilen Zwischenstand inkl. CustomIntents gibt, würde ich wieder mit von der Partie sein.

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

#155
Zitat von: JensS am 28 März 2021, 12:00:23
Super, da hat sich ja eine ganze Menge getan.
8)

Zitat

#Ein ReadingsName wird erzeugt aber kein Reading angelegt, welches dann aber abgefragt wird?
Na ja, die Funktion zur Erzeugung eines Namens ist das eine, an der Stelle ging es aber in der Tat erst mal darum, ein (anderweitig erzeugtes und z.B. mit setreading gesetztes) Reading abzufragen. Bauchgefühl sagt, dass das sogar funktioniert, aber intensiver Testen konnte ich noch nicht.

ZitatCool, da hat man viele Anpassungsmöglichkeiten bereits in der Definition.  8)
Ja. Man muss halt ein gewisses Gefühl dafür haben, was im jeweiligen Anwendungsfall sinnvoll ist bzw. an welcher "Schraube" man denn am besten dreht. In den meisten Fällen sollte es "für Umsteiger" ganz ohne Parameter gehen, empfehlen würde ich im Moment useGenericAttrs, auch wenn das noch nicht vollständig mit allem möglichem "durchgetestet" ist V.a. bei "mehrsprachigen" Systemen ist es m.E. einfacher, auf diesen "gemeinsamen Nenner" Bezug zu nehmen, sonst muss man auch die mappings 2x konfigurieren (wg. unterschiedlicher prefixe).

ZitatBei uns gab es heute zum Frühstück frisch aufgebackene Brötchen.  ;)
;D Hast du das Keyword dafür ergänzt, oder eben Kartoffeln gebacken...?

Was Timer angeht, habe ich noch etwas am Rückmelde-Code beim Setzen gefeilt, das sollte jetzt in allen Fällen was sinnvolles liefern. Man muss dazu aber auch die Sprachdatei mal wieder mit anfassen. Daher habe ich in dem Zug auch gleich den "Typo" rausgebügelt (hoffe ich jedenfalls).

ZitatWenn es einen stabilen Zwischenstand inkl. CustomIntents gibt, würde ich wieder mit von der Partie sein.
CustomIntents sollten eigentlich seit einiger Zeit schon wieder laufen, (bzw. wenn nicht auch schnell zu reparieren sein), und auch bei shortcuts sollte jetzt Perl wieder in beiden Varianten ausgeführt werden.

Ein paar Anmerkungen noch zu dem Witze-Code:
- Eigentlich wäre es besser, eine generische "ReadRandomLine"-Funktion zu verwenden und dann zum einen den (relativen) Pfad mit zu übergeben und die Anweisung, ob das letzte Zeichen einer Zeile weggeschnitten werden soll. Dann kann man das nämlich für verschiedene Zwecke benutzen (z.B. über "rhasspyTweaks" zum Verlesen verschiedener "wird gemacht!"-Varianten ;) und auch mit unterschiedlichen "Quellen".
- Das mit dem Speicher und der zu verwendenden Lesefunktion mag korrekt sein, aber "wegen der paar Bytes" würde ich mir noch nicht den Kopf zerbrechen, zumal das ja nach Beenden der Funktion auch schon wieder Geschichte ist.
- @JensS: Was steht denn in Witzearray[124] bzw. Witzearray[0]... ;) ?



Neben den oben angesprochenen Themen gibt es in der angehängten Version jetzt auch noch "SetNumericGroup".
Auf die Schnelle habe ich folgende sentences dazu zusammengeklöppelt:
[de.fhem:SetNumericGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]
[de.fhem:SetNumericGroup]
Scheint grundsätzlich zu funktionieren, allerdings bin ich noch nicht ganz zufrieden mit dem, was am Ende rauskommt - allerdings eher von der Seite her, was erkannt wird und welche Geräte daher angesprochen werden. Muss mich da erst mal noch etwas intensiver mit den Wechselwirkungen zwischen unterschiedlichen Sätzen und den "keywords" "probability" und "confidence" etc. auseinandersetzten.
Und evtl. dann noch Bestätigungsanforderung (optional?) mit einbauen...?

Ansonsten sind noch ein paar Kleinigkeiten geändert (z.B. List::Util any und uniq), aber nachdem es sonst keine Klagen gab, würde ich mal annehmen, dass man das ganze als "stabilen Zwischenstand" bezeichnen könnte.


In Bezug auf  'generische "ReadRandomLine"-Funktion' vielleicht noch eine Anmerkung:
Eventuell ließe sich über eine ähnliche Funktion auch noch komplexerer "gender-spezifischer" Antwortcode realisieren. Setzte aber (vermutlich) voraus, dass wir die Struktur eher wieder flacher gestalten (also "timerSet0" statt "timerSet->{0}" und alle Antworten über RHASSPY_getResponse() anfragen (dann könnte man da den Zusatzcode optional aufrufen lassen). Ist aber alles noch nicht abschließend durchdacht und vermutlich auch nicht so einfach umzusetzen...



Was im Moment noch nicht getestet ist, ist die Reaktion auf eine Bestätigung - ohne dass noch was offen ist (bzw. insgesamt das Thema Bestätigung), und mein Logfile sollte ich ggf. auch nochmal intensiver ansehen (da scheint aber nichts gravierendes schief zu laufen).

Sonst würde ich mal behaupten, dass jetzt eigentlich ein "guter" Zeitpunkt für den Umstieg sein sollte; würde die kommenden Wochen eher dann für Fehlerkorrekturen (sofern erforderlich) nutzen und ggf. dann zu gegebener Zeit wieder auf "rhasspyTweaks" etc. zurückkommen?
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

#156
Frage an die Rhasspy-Experten: Wo kann man näheres erfahren über das dialog-Management?

Hintergrund: RHASSPY_respond antwortet immer auf dem Topic "endSession" - damit wird also die aktuelle Sitzung beendet. "Eigentlich" wäre es nach meinem Verständnis logischer, wenn man sowas wie die Bestätigungsanfrage nicht unter "endSession"-Flagge versenden würde, sondern innerhalb derselben Session abhandelt.
Mein Wunschgedanke: Die weiteren Dialoge ließen sich einschränken, z.B. ginge eine Bestätigung nur innerhalb einer laufenden/noch offenen Sitzung, oder man könnte sowas wie einen Auswahldialog starten ("Du willst eine Temperatur wissen. Welcher Seensor soll ausgelesen werden, im Wohnzimmer sind folgende drei verfügbar?").

Falls also jemand irgendeinen zielführenden Link hat, mit dem man schnell auf des Pudels Kern kommt: her damit...
(Und falls jemand genau weiß, dass das (derzeit?) nicht klappen kann, wäre das auch interessant.)

EDIT: ich antworte mir mal selbst... Unter https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_continuesession gibt es ein paar Hinweise in diese Richtung.
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

Es gibt das Dialogue-Management: https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager

Ich weiß aber nicht, wie man da tun muss. Und kann mich auch nicht erinnern, dass ich funktionierende Beispiele gelesen hätte. Vielleicht findet sich im Forum was? https://community.rhasspy.org/

Beta-User

#158
Hmm, also:
Man müßte wohl die response auf einen anderen Topic (continueSession) schreiben, im Moment ist das hart auf endSession vercodet, aber es sollte nicht allzu schwierig sein, da ein flag reinzubasteln, um die response bei Bedarf auf einen anderen Pfad umzuleiten :) .

Dann kann man auch einen intentFilter mitgeben. Klingt danach, als könnte man damit (nur) die Confirmation freischalten?

Und weiter unten liest man zu "hermes/dialogueManager/configure:" "Name of intent - enable: bool - true if intent should be eligible for recognition"
Das liest sich so, als könnte man über diesen Mechanismus bestimmte Dinge standardmäßig ausschalten... Das könnte also der Weg sein, Confirmation ansonsten abzuschalten?

Muss ich bei Gelegenheit mal durchspielen und testen... (Wird aber dauern)
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

JensS

#159
@Beta-User
Danke für deine ausführlichen Antworten. Dann schaue ich mal, wie ich demnächst die Migration durchführe. Im Moment drängen andere Dinge und Zeit ist aktuell knapp.

Rhasspy ist aus Snips entstanden und es gibt viele Ähnlichkeiten. Schau dir mal die Beschreibung von Snips an. Die ist auf jeden Fall ausführlicher.
https://docs.snips.ai/reference/dialogue#continue-session
https://docs.snips.ai/articles/platform/dialog/multi-turn-dialog

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Danke für die Links!

Das Beispiel mit dem Flughafen ist schon mal sehr anschaulich, das geht genau in die Richtung "welches Schweinderl hätten's denn gern?".

Na ja, vor einem solchen Auswahldialog sollte erst mal der "einfache" soll ich wirklich?"-Dialog in Shortcuts sauber laufen, dann sehen wir weiter...

Ansonsten @JensS: Kein Stress mit der Umstellung, läuft ja erst mal alles so, wie du das haben willst!

@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?
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 01 April 2021, 11:32:33
@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?

Naja. Also ich hab schon lange nichts mehr getestet. Ich weiß nicht mal, was alles neu ist. Muss ich mir zuerst zusammen suchen. Hab eventuell in den nächsten Tage wieder etwas Zeit.

drhirn

Ähm

Zitat
response
Optionally define alternative default answers. Available keywords are DefaultError, NoActiveMediaDevice and DefaultConfirmation.
Example:

DefaultError=
DefaultConfirmation=Klaro, mach ich

Beta-User: Was never part of the code? Use configFile instead!

Ist im Code und funktioniert ;)

Beta-User

#163
Na ja, richtig neu sind "nur" die "Group"-Intents, das mit der (optionalen) Bestätigung bei Shortcuts und bei Timern die modifizierten Rückmeldungen und die Optionen, ein Label draufzukleben und abzubrechen.
Alles andere sind entweder Optionen und/oder Änderungen "unter der Haube", die man als Anwender eigentlich optimalerweise gar nicht bemerken sollte - bzw. die einfach laufen sollten, wie das mit der spanischen Sprachfile und zwei RHASSPY-Instanzen parallel.

Was z.B. @JensS (vermutlich) interessiert, ist die Frage, ob man einfach so 1:1 von 0.2.0 auf 0.4.6a wechseln kann, also Modul & Interface tauscht und die Sprachfile einspielt, und das war es schon...?

Zitat von: drhirn am 01 April 2021, 12:04:25
Ist im Code und funktioniert ;)
Das ist dann in der Tat eine "regression", denn in den aktuellen Versionen funktioniert das nicht mehr, genauer gesagt, sollte es auch in der 0.2.0 schon nicht mehr funktioniert haben, weil die zwei Zeilen auskommentiert sind, die das bereitgestellt hatten:
https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm#L1033 und #L1034

Das in der Form wiederaufleben zu lassen, macht aber aus naheliegenden Gründen mAn. keinen Sinn. Es wäre aber auch kein großes Problem, dieses Attribut (verdeckt?) weiterleben zu lassen und den Attribut-Inhalt dann einfach in den Sprachhash zu übernehmen...

Bin da aber im Ergebnis leidenschaftslos, das kann dann ggf. auch die "Andockstelle" für zufällige Rückmeldungen (einen aus einer File oder einem Array...) sein :P .EDIT: Kommando zurück, das mit der response-Auswertung steht immer noch da, nur eben woanders, *Augenreib*
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

laberlaib

Zitat von: Beta-User am 01 April 2021, 11:32:33
@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?
Ich frag mal kurz meinen Arbeitgeber, meine Homeschoolingtochter sowie den vermeintlichen Pfuscher von Lieferant der Parksysteme unserer Wohnanlage, ob diese Schlussfolgerung korrekt ist  ;)

Mit Bezug: Ich musste den Stecker ziehen, nachdem sich neben der MQTT-Bridge und dem sonstiges Testen die Wakewordeinstellung als sehr empfindlich rausgestellt hat und Jarvis quasi im Technebeat gehupt hat.
Seit heute habe ich eine Woche frei und es sind Schulferien; es könnte also wieder zu spontanen, ausschweifenden Rückmeldung meinerseits kommen.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)