Iobroker.alexa2 v0.4+
-
Werte sind true und false je nachdem ob an oder aus.
Gesendet vom Handy …
-
Leider nicht.
Standardmässig steht es auf false.
Änder ich es auf true passiert nichts.
Lass ich den State von der VIS ändern, leert sich das Feld.
Steht nix mehr drin.
-
Dann musst du ein widget in vis nutzen was da den korrekten Wert reinschreibt.
Wenn beim normalen setzen auf Trennung passiert bitte debug log senden von so einem true setzen.
Gesendet vom Handy …
-
Selbst auf true passiert nichts.
Funktioniert das Shufflen eventuell nur bei Playlisten ODER bei Sendern ?
Hab das aus zeitgründen nicht testen können.
-
bei Sendern funktioniert Shuffle nie. Am Ende hängt es vom gespielten Medium ab.
Eine zufällig zusammengestellte Playlist (Spiele Musik von Madonna) mach Shuffle auch wenig sinn.
Wenn Du wissen willst ob es am Adapter oder an Amazon liegt: Debug Log als PN bitte!
-
Ok, müssen noch was tun … 1.1.0 auf GitHub ... bitte unterstützt beim Testen! Details zu den änderungen schicke ich später
-
Hi All,
Im latest und stable gibt es v1.1.0 … Bitte updaten. In der 1.0.0 gab es Probleme durch Anzahl und Geschwindigkeit von Requests und bevor das größere Auswirkungen auch mit Amazon hat bitte schnell und unbedingt updaten!
Nun zu den Details der Änderungen:
Kurz nach dem Release der Alexa2-Version die auch Smart-Home-Geräte steuern konnte gab es immer mal wieder Probleme mit der Cloud und Alexa-Anfragen, wie auch hier viewtopic.php?f=37&t=16882 diskutiert.
Unsere Ergebnisse zeigen das seit dem 6.9. die Anzahl der Amazon Requests die beim Cloud-Server landen um 700% angestiegen sind. Quasi von einem Tag auf den nächsten. Seitdem sind Sie dort oben.
Wir haben also analysiert was da passiert sein kann und können es zeitlich nur auf den Release der Smart-Home-Device-Steuermöglichkeiten im Alexa2-Adapter zurückführen. Mit Aussagen die ich so im Forum/Github gelesen habe (leider finde ich die gerade nicht mehr) das "alle 15 Sekunden der #queryAll-State getriggert wird" oder auch andere die es nur alle 5 Minuten tun ist diese Idee durchaus ein valider Grund für diesen Anstieg. Mal abgesehen davon das so eine "alle 15s Datenabfragen" Idee durchaus grenzwertig und sehr blauäugig ist, generiert Sie hohe Anfragen und Kosten für den Skill-Betreiber. Das solltet Ihr bitte immer im Hinterkopf haben.
Diese sehr hohe Anzahl Requests sorgen aktuell aber dafür das der Cloud-Server nicht immer alle bedienen kann und daher einige in Timeouts laufen und dann von Amazon mit den hier beschrieben Fehlern quittiert werden. Den Cloud-Server hier zu optimieren ist eine größere Infrastruktur- und Entwicklungs-Thematik die Zeit brauchen wird.
Aus diesem Grund habe ich mit Bluefox entschieden einerseits ein "Rate Limiting" für Statusabfragen generell in den Alexa2 Adapter einzubauen (Skill Updates maximal alle 10 Minuten, Echo-Plus Hub Updates maximal alle 5 Minuten, sonst Warnung im Log) UND zusätzlich alle Statusabfragen von Smart-Homegeräten die über Alexa2 über den ioBroker-eigenen Smart-Home-Skill kommen komplett zu deaktivieren diese sollten eh nicht wirklich sinnvoll sein weil am besten direkt steuern). Diese Änderungen sind in Adapter Version 1.1.0 enthalten. Diese Version ist ab spätestens morgen im Latest UND Stable.
Ich rufe hiermit Alle Nutzer auf diese Version zu updaten.
Wenn sich die Anzahl der Requests nicht wieder normalisiert werden wir härtere Maßnahmen ergreifen müssen und Nutzer die es hier weiterhin übertreiben auf Cloud-Server-Ebene hart blocken! Ich denke nicht das das im Interesse von Euch ist.
Bei Fragen wendet Euch bitte jederzeit an mich. Wenn Ihr Leute kennt die den Adapter nutzen aber das hier nicht lesen (und vllt sogar "Mitverursacher" der Probleme sind) bitte weist Sie darauf hin.
Ein kleines Feature kam aber auch noch rein: Über TuneIn-Station kann man nun auch Shows/Podcasts (p1234567) und einzelne "topics" (t123456789) abspielen.
Danke,
Ingo
-
Danke für die klare Ansage!
Ich möchte selbstverständlich nicht, dass andere durch eine zu große Zahl von Abfragen beeinflusst werden.
Auch ich habe in den letzten Tagen vermehrt mitbekommen, dass Anfragen von Alex nicht umgesetzt wurden, obwohl sie sauber quittiert werden.
Welche Optionen haben ich aber jetzt um folgenden Usecase zu realisieren:
Bluetooth Gerät in der Dusche.
Anschalten des Gerätes.
Alex verbindet sich diesem Gerät.
IoBroker bekommt das (hier ist das Problem) zeitnah mit.
Jetzt wird Alex aufgefordert Musik (was auch immer) abzuspielen.
Wenn es eine Anfrage von ca. 10mins gibt, dann bin ich schneller aus der Dusche draußen als ich Musik bekomme.
Gibt es eine Alternative?
Wenn nicht, kann ich zu Gunsten der Cloud auch meinen Logitech Pop einsetzen und nach dem Verbinden auf diese Weise Alexa aktivieren.
Danke dir!
Grüße Plasma
P.S. Cloud > Update!
-
Also Steuern geht mit dem Adapter immer noch Du kannst also z.B. immer noch "powerState" auf "true" setzen. Nur das lesen der Werte (des aktuellen Status) geht nicht mehr
Bzw: Wie genau hast Du das denn bisher gelöst? Sag genau und wir überlegen gemeinsam
-
so, dann erzähl ich mal wie ichs umgesetzt habe:
allgemein:
-
hab in der instanz das update auf 0 runtergefahren
-
über die wlan-anwesend meines handys (ping iVm. tr-064) hab ich einen trigger für das update gesetzt
-
diese update fragt in kurzen intervallen alle status von allen alexas ab (aber wer weiß das besser als du)
speziell:
-
bluetooth-gerät in einem zimmer in dem ich NICHT in rufweite zu alexa stehe (dusche)
-
bluetooth-gerät einschalten –> alexa verbindet sich automatisch --> durch o.g. update erfährt das über den iobroker
-
trigger auf datenpunkt (bluetooth gekoppelt) --> ausführung skript, das alexa startet um z.b. playlist oder radio zu spielen
wenn der datenpunkt nicht ständig aktuell gehalten wird, dann bekomme ich auch nicht zeitnah alexa dazu musik zu spielen.
--> folglich brauche ich alternativen:
1.) ich gebe alexa den befehl bevor ich mich in den raum (dusche) begebe
2.) externer trigger --> ich verwende hier logitech pop --> ifttt --> iobroker --> alexa soll musik spielen
3.) ohne musik duschen
es war halt sehr komfortabel, dass der iobroker mitbekommen hat wenn ich das bluetooth-gerät eingeschalten habe
-
-
Dann nochmal zur Klarstellung: das oben geschriebene theme in der 1.1.0 betrifft ausschließlich die abfragen der Werte für smart Home Geräte!!!
Alles andere wie Bluetooth und das was per Push Verbindung läuft hat damit nichts zu tun !! Das geht weiterhin so wie vorher und hat sich nix damit zu tun.
Es geht nur um #queryAll und #query unter Smart-Home-Devices.*
Gesendet vom Handy …
-
Gut,dass Du das nochmal so klarstellst.
Ich denke die Mehrheit (mich eingeschlossen) hier, hatte das nämlich anders verstanden
-
Dann ändert sich ja gar nichts bei mir und ich kann weiter meine Zustände der Alexas abfragen … und kann bequem mit musik duschen! :lol:
Danke dir
-
Auch von mir vielen Dank für die Entwicklungsarbeit des Adapters.
Ich wollte mit der neuen Version mit den Smart-Devices dafür Sorgen, dass die Kaffeemaschine nach einigen Minuten wieder von selbst ausgeschaltet wird, indem ich auf positive Flanke von powerState der Schaltsteckdose einen Timeout setze. Dafür wäre zumindest minütliches Pollen nicht schlecht.
Evtl ist es eine Lösung, dass Alexa via Routine oder Gruppe und CloudAdapter eine zweite Variable setzt, welche (in meinem Fall) "Kaffeemaschine läuft" zeitnah indiziert, ohne #query zu bemühen.
Oder Alexa setzt nur eine Cloud-Variable, die als Request an ioBroker funktioniert und das eigentliche Handling erledigt dann der RasPi.
Beide Fälle müssten den Servertraffic reduzieren, oder?
Fürs Verständnis:
Warum kann Alexa/Echo keine Pushnotifications für die Smart-Devices?
-
ch wollte mit der neuen Version mit den Smart-Devices dafür Sorgen, dass die Kaffeemaschine nach einigen Minuten wieder von selbst ausgeschaltet wird, indem ich auf positive Flanke von powerState der Schaltsteckdose einen Timeout setze. Dafür wäre zumindest minütliches Pollen nicht schlecht. `
Was ist das für ne Steckdose? Über was für einen Skill ist die angebunden?Evtl ist es eine Lösung, dass Alexa via Routine oder Gruppe und CloudAdapter eine zweite Variable setzt, welche (in meinem Fall) "Kaffeemaschine läuft" zeitnah indiziert, ohne #query zu bemühen.
Oder Alexa setzt nur eine Cloud-Variable, die als Request an ioBroker funktioniert und das eigentliche Handling erledigt dann der RasPi.
Beide Fälle müssten den Servertraffic reduzieren, oder? `
Meine Frage ist eher warum das überhaupt über Alexa/Cloud muss? Oder ist das eine Steckdose die du nicht in ioBroker integrieren kannst aktuell?Fürs Verständnis:
Warum kann Alexa/Echo keine Pushnotifications für die Smart-Devices? `
Die ganze Smart-Home-Devices nummer ist immer nur "auf Anfrage" … Auch Alexa kennt den aktuellen Status nicht wenn Sie nicht nachfragt. Inzwischen geht da vllt was, aber da müssen wir mindestens den Skill auf "v3" heben und weiss nicht ob es dann genau geht. Steht auf der Todo Liste
-
Das ist eine "TECKIN WLAN Smart Steckdose", die Über Smart Life gekoppelt ist.
Ich wüsste zumindest momentan nicht, wie ich die direkt in ioBroker ansteuern kann.
Mit einer Osram an der Hue Bridge z.B. geht das sicher "direkter".
Danke für die schnelle Antwort.
-
Ich kann verstehen das das blöd ist, aber die anderen Skill-Betreiber haben faktisch das gleiche Problem wie wir nur in kleinerem Mass-stab.
Aktuell schwierig.
-
an der stelle liebe ich meine Steckdose von AVM (dect200), die ich direkt an der fritzbox auslesen kann ohne traffic nach "außen" zu erzeugen
-
Das ist eine "TECKIN WLAN Smart Steckdose", die Über Smart Life gekoppelt ist.
Ich wüsste zumindest momentan nicht, wie ich die direkt in ioBroker ansteuern kann.
Mit einer Osram an der Hue Bridge z.B. geht das sicher "direkter".
Danke für die schnelle Antwort. `
Mach Tasmota drauf und binde sie mit dem Sonoff Adapter im IOBroker ein. Tasmota hat auch eine direkte Anbindung über EMU an Alexa, da brauchst nicht mal ein Skill.
-
Eine Idee die mir hier kommt ist, wenn die 11.0 die erwarteten Dinge für die ioBroker Infrastruktur fixt hier wieder etwas aufzulockern.
ioBroker Skill Geräte bleiben weiterhin nicht auslesbar. Daran ändern wir nichts
Für die anderen könnte ich den aktuell hart eingestellten "Block-zeitraum" konfigurierbar machen und über die Adapter-Konfiguration mit Hinweistext versehen. Dort steht dann der Wert der jetzt in der 1.1.0 drin ist als Default.
Wenn jemand weiss was er tut und es mit "bedacht" benutzt und er weiss das der dem Skill-Betreiber nit jeder Anfrage Kosten verursacht kann er die Block-zeit ändern … ist dann aber seine verantwortung ...
Ob das sinn macht - vor allem das letzte - weiss ich gerade nicht nicht so ganz ... muss ich mal zu nachdenken.
