alexa-fhem test version mit proaktiven events

stefanru · 18 Februar 2020, 20:40:16

Eigentlich nicht,

welche Geräte hast du denn?
ContactSensor geht bei mir und MotionSensor.

Gruß,
Stefan

gvzdus · 18 Februar 2020, 22:51:14

Zitatgeht doch alles schon.

- der default ist in der eingecheckten version false.
- du kannst es mit "report" : true aktivieren.
- wenn du nicht alles melden willst: leg einen zweiten connection block an mit anderem filter und anderem report an.

Aber das ist doch arg durch die Brust ins Auge! Nächster Vorschlag: Nur das Reporten, was auch was nützt, eben:

MotionSensor
Fensterkontakte

Der Normalnutzer sollte doch die alexa-config.json überhaupt nicht anfassen müssen.

stefanru · 18 Februar 2020, 23:36:06

Na ganz so einfach ist es nicht.
Es gibt wohl mehr proaktiv reporting devices.
Habe verschiedene Listen gesehen.
Außerdem gibt es wohl auch Ideen das ganze auch auf Schlater usw auszudehnen.
Sieh z.B. hier:
https://www.alefo.de/forum/routinen-jetzt-geraete-als-trigger-6163-20#p52785

Was gehen wird und was geht liegt an Amazon und ist nicht so ganz einfach fix.

Aber mit nem Filter könnte man arbeiten.
Die Frage ist, ist der Overhead so groß?
Oder ist das eher zu vernachlässigen?

Ich kann nach wie vor nur minimale CPU Last bei dem Alexa Prozess erkennen weit unter 1% auf meine RPi3 und auch im Netzwerk erkenne ich keinen erhöhten Upstream.
Somit für mich völlig ok.

Klar wenn du nicht willst dass Amazon das erfährt, dann ok, aber sollte man dann eine alexa sich hinstellen?

Gruß,
Stefan

gvzdus · 19 Februar 2020, 00:22:10

Ich kam - wie erwähnt - auf etwa 10 Events / Minute - vermutlich hauptsächlich die Thermometer im Haus (4 mal LaCrosse). Ich sehe es auch so rum: Amazon liefert für einen sehr kleinen Betrag nicht nur die Hardware, sondern auch halbwegs das Versprechen eines "Life Time Services", den sich manche Anbieter von Smarthome-Clouds gerne fast zur den Kosten eines Echo-Dots vergüten lassen wollen - pro Jahr. Da sollte man m.E. für jede Seite auf die Ressourcen achten. Und seien es nur die Stromkosten für täglich 37,5 Mio. ausgehandelte SSL-Connections bei dieser Rate und 2.500 Nutzern.

Der andere Punkt: Im Moment treffe ich eine bewusste Entscheidung, Alexa z.B. nach der Temperatur der Heizung zu fragen. Ich nehme in Kauf, dass diese Information von Amazon verarbeitet wird, und das ist für den Zweck unausweichlich und vermutlich habe ich der langfristigen Speicherung irgendwo in den AGB zugestimmt. Der "pauschale Push" an Amazon von Unmengen Informationen, die nur in den wenigsten Fälle einen Mehrwert für mich haben, ist m.E. ein grundsätzlicher ästhetischer Verstoß gegen das Prinzip der Datensparsamkeit. Und eigentlich ist es doch unsere Verantwortung als Techniker, das für den Nutzer nicht zu einem "Du musst halt abwägen ob Ja oder Nein" zu machen, sondern niedrigschwellig sinnvolle Datensparsamkeit zu ermöglichen. Die Daten aller Sensoren des Hauses, die man mal grundsätzlich abfragen könnte, non-stop in die Cloud zu blasen, ist das absolute Gegenteil davon.

Ganz ehrlich: Im Moment halte ich ja noch mit meinem Namen für die Datenschutzerklärung von FHEM Connector her. Wenn der Push zum Default werden sollte, muss die umformuliert werden.

justme1968 · 19 Februar 2020, 11:37:13

der push ist nicht default! siehe oben. default ist aus.

gvzdus · 19 Februar 2020, 12:24:24

Zitatder push ist nicht default! siehe oben. default ist aus.

Das ist mir völlig bewusst. Aber Ziel muss doch eine "fummelfreie" Version sein! Zielsetzung war immer bei FHEM-Connector ein schlichtes "Läuft! Auf Anhieb!".

Vorab:

Das Feature ist großartig, und super, dass Du (und Amazon) es zum Laufen gebracht hast. Ich bin nie mit dem echodevice warm geworden, und jetzt gibt es die Möglichkeit, Alexa zu spontanen Ansagen zu bewegen. Mir fällt da der Solarüberschuss und Warnungen z.B. für "Tiefkühltruhe zu warm" ein - Dinge, die ich z.Zt. per Telegram-Bot mache.

Vorschlag:

Mein Vorschlag wäre - solange Amazon nur diese binären Events für den Nutzer sinnvoll umsetzen kann - folgende Skizze:

Push ist per Default an, aber kein klassisches Device wird gepusht
Für die Problematiken ".eventToken" bzw. "neue Skillverknüpfung nötig" benötigt es eine Meldung im alexa-Device-Status
Es gibt einen genericDeviceType 'pushState' (o.ä.), den man typischerweise einem Dummy-Device zuweist (zusammen mit einem alexaName). Diese Devices simulieren einen Kontakt oder MotionSensor und werden gepusht
Ob ich nun einen realen Motionsensor oder einen Kontakt, eine Schwellwertüberschreitung oder die Sonnenfinsternis in FHEM für den State dieses Devices als Quelle nehme, ist jeweils eine explizite FHEM-Regel.

So könnte man m.E. das Feature safe und nutzerfreundlich launchen.

MadMax-FHEM · 19 Februar 2020, 12:43:07

Zitat von: gvzdus am 19 Februar 2020, 12:24:24
Das Feature ist großartig, und super, dass Du (und Amazon) es zum Laufen gebracht hast. Ich bin nie mit dem echodevice warm geworden, und jetzt gibt es die Möglichkeit, Alexa zu spontanen Ansagen zu bewegen. Mir fällt da der Solarüberschuss und Warnungen z.B. für "Tiefkühltruhe zu warm" ein - Dinge, die ich z.Zt. per Telegram-Bot mache.

Ginge auch mittels echodevice-Modul

https://forum.fhem.de/index.php/topic,82631.msg747482.html#msg747482

Und dann ohne Events etc. an Amazon...

Gruß, Joachim

stefanru · 19 Februar 2020, 13:32:09

Hi,

also ich finde es auch toll wenn man alle features nutzen kann die amazon da bietet.
Ich finds toll dass ich den Bewegungsalarm nun auch direkt in der Alexa App benutzen kann als Trigger.

Mir war nicht bewusst dass es um den FHEM Connector geht.
Da könnte man durchaus irgendwie filtern.

Für mich wäre nur wichtig dass wenn ich meinen eigenen Skill verwende ich auch wenn ich will alles pushen kann, schon allein und ab und an zu testen ob Amazon nun doch eventuell neue Devices wie switche unterstützt.

Vielen Dank nochmal für eure tolle Arbeit.
Gruß
Stefan

justme1968 · 19 Februar 2020, 13:36:58

die aktuelle version mit zusätzlichen connection blöcken bleibt auf jeden fall. das ist sehr flexibel und geht so zu sagen schon out of the box.

zusätzlich könnte man ein zusätzliches attribut alexaPush einbauen das man setzt wenn man die events eins devices pushen möchte. das könnte man theoretisch noch erweitern um bestimmte characteristics zu pushen. das wäre aber etwas für später.

die frage ist halt: lohnt sich der aufwand überhaupt. ich bin ja immer noch der meinung mal sollte alles was möglich ist direkt in fhem machen. wenn man es zu einfache macht verleitet das dazu es nicht in fhem zu machen

. vielleicht sammeln wir mal was nur mit den events (und ohne echodevice) geht.

warum das .eventToken solche probleme macht ist mir noch nicht klar. das ist schon immer drin und sollte bei jedem der den connector nutzt einfach gehen. ausnahme: es ist mehr als ein skill im einsatz. da muss ich noch nachbessern. das steht schon lange auf der liste.

justme1968 · 19 Februar 2020, 17:59:46

also... ich habe da mal was gebaut und ganz mutig direkt eingecheckt...

man kann wie bisher den default für eine fhem connection im alexa-fhem config file über einen parameter setzen. (achtung: der name des parameters hat sich geändert: proactiveEvents)

neu, und für die meisten besser ist aber das hier:

es gibt jetzt ein alexaProactiveEvents attribut in fhem das man pro device setzen kann:

0 -> es werden keine events erzeugt
1 -> es werden events für dieses device erzeugt

der default ist 0 bzw. das was im config file von hand gesetzt wurde.

wenn man alexaProactiveEvents im alexa device selber auf 0 setzt, wird das event reporting für diese fhem instanz deaktiviert. das überschreibt also das aktivieren per attribut pro device.

bei der gelegenheit habe ich auch endlich den fehler gefunden der in alexa-fhem die direkte reaktion auf attribut änderungen zur laufzeit verhindert hat. d.h. man kann das alexaProactiveEvents attribut zur laufzeit setzen, ändern oder löschen und es hat ohne neustart von alexa-fhem (und ohne gerätesuche) sofort auswirkungen (gilt auch für alexaName).

d.h. man könnte z.b. über das alexaProactiveEvents attribut im alexa device das reporting mit einem at/notify/... an andere bedingungen knüpfen. wie z.b. es ist jemand zuhause, oder eben nicht, oder nur tags über, oder nur nachts, ...

ps: wer jetzt sein .eventToken attribut 'repariert' hat, bei dem geht dann auch das set <alexa> add um zur laufzeit ein neues device hinzuzufügen und alexa bekannt zu machen. hierbei gibt es zumindest unter iOS auch eine nachricht auf handy oder watch. das geht deutlich schneller als immer eine 50 sekunden lange geräte suche zu starten.

justme1968 · 19 Februar 2020, 18:58:06

ps: wenn das so weit geht wäre es wieder mal was fürs wiki... also freiwillige vor

gvzdus · 19 Februar 2020, 19:11:37

Wer nörgelt und labert, fühlt sich natürlich geehrt, seinen Senf auch noch in den Wiki gießen zu dürfen

Ich mach's, und vielen Dank!

justme1968 · 19 Februar 2020, 19:21:20

sehr löblich. ebenfalls besten dank

stefanru · 19 Februar 2020, 22:32:50

Wow,

so schnell wie du die dinger im Moment raushaust kann ich garnicht testen

Habe mit der neusten Version aber ein Problem.
Habe in alexa-fhem.cfg "proactiveEvents": "true" gesetzt.
Aber es wird nicht mehr reported.
Ist es Pflicht das alexaProactiveEvents attribut zu setzen?
Wie kann ich alle Geräte reporten lassen?

P.S.: Es geht sobald ich das attribut am Device setze.
Es geht leider nicht in der Config oder am Alexa Device. Ist das ein Fehler oder so gewollt?

GRuß und Danke,
Stefan

gvzdus · 20 Februar 2020, 00:02:33

Redaktionskonferenz der BILD-Zeitung ist vorbei, der Abschnitt "Aktiv Routinen starten" im Wiki fertig.

Wäre nett, wenn jemand gegenliest! Der Stil ist der Originalstil von FHEM-Connector (erst sagen, warum das sehr genial ist, dann mehr Text & die Einrichtung, dann Fehlersuche).

Btw: Bei mir kommen die angezeigten Bewegungssensoren als Triggerquelle in der Alexa-App offenbar nicht aus FHEM, sondern vom noch installierten Hue-Skill. Aber dafür funktioniert es auch nicht. Vielleicht, weil dann ja die im Hue-Bridge-Gefängnis Eingekerkerten über Alexa in die freie IFITT-Welt Botschaften senden könnten. Ist aber natürlich kein FHEM-Problem.