Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
* Erinnere mich um 16:45 uhr an .... oder
* Stelle Wecker auf 15:00 uhr
Man sieht den unterschied auch in der Alexa app - dort kann man nur Erinnerungen anlegen und wecker an/ausschalten (aber nicht neue anlegen)
Gruß
T.
Alle meine Echos sind im gleichen Account.
Kam gerade heim und hatte ne volle Platte weil jedes Log mehr als 1GB groß war
Leider ist da auch nicht mehr bei zu steuern als schon von Thorsten...
Kann gerne noch etwas anders testen wenn es hilft!
Hattest du das Logging ergänzt was ich weiter oben beschrieben habe? Dann könnte ich mal sehen, warum das CSRF nicht aus dem Cookie File gelesen werden kann.
Noch läuft meine Alexa... wenn man mal auf den Fehler wartet ...
Aber ich habe nochmal wegen den Alarmen geschaut.
Folgenes habe ich festgestellt:
Einen neuen Wecker auf dem SPOT => kommt nicht im Baustein an.
Einen reminder auf dem SPOT => kommt an
Einen neuen Wekcer auf dem DOT => kommt an :-)
Einen neuen Wekcer auf dem Echo (der eigentlich garkeinen Alexa-Controll hat) => kommt an auf dem SPOT Baustein?!?!
Der SPOT heißt "Schlafzimmer" - als Ausgabe kriege ich hier den Wecker vom Wohnzimmer:
danach gehts wieder wie wild weiter.......
Also das CSRF scheint zu fehlen... ich denke im Fehlerhandling müsste man in diesem Fall was ins Log schreiben ... und entweder neu Einloggen (versuchen) oder den Baustein zeit X pausieren - dann neuer Versuch...
Hast du denn mal ins Cookie File geschaut, ob da wirklich kein CSRF Eintrag mehr drin steht?
Was auch noch ganz interessant wäre: Tritt das Problem auch auf, wenn du nur einen Echo steuerst?
BTW: Machst du das mit einer Instanz, bei der du ständig die Inputs änderst oder hast du je Echo eine LBS Instanz?
Ggf. könnte man einen weiteren Eingang spendieren, über den man dem LBS sagt, ob er der Cookie-Master ist. Vielleicht würde das schon helfen. Denn auf meinem Testsystem läuft eine Instanz schon seit Wochen und ich habe diesbezüglich noch keinen Fehler bekommen.
Hi
ich habe 6 Alexas (Echos, Dots, ein Spot) im Account. 4 Bausteine sind aktiviert. Es werden nicht ständig irgendwelche änderungen durchgeführt - wobei der Status aller 4 Bausteine auf "aktualisierung alle 10 sek (E36=10)" eingestellt ist.
Geschaltet wird nur bei enntsprechenden Events: Radio ein wenn man in die Küche oder ins Bad kommt - Radio aus wenn keiner mehr da ist....
Im .alexa-cookie ist derzeit kein CSRF drinnen...
Hab den cookie gerade mal gelöscht ( wird neu erstellt ) wieder ohne CSRF
Wenn ich hier (andere IP) auf alexa.amazon.de gehe und einen sender (auf einem DOT zuhause) starte kommt ein CSRF (chrome - developer tools).
Ich vermute, das Amazon wie auch die meisten anderen APIs, die Anzahl der Aufrufe pro Sekunde, pro Minute, pro Stunde, pro Tag limitiert.
Bei 4 Geräten sind das >100.000 API Calls, da je Zyklus bis zu drei API Calls gemacht werden (searchDevices(), getStatusInfo(), checkNotifications())
Das würde auch dazu passen, dass das Problem immer nach einer bestimmten Zeit auftritt. Und vermutlich ist es auch dann nach einer bestimmten Zeit wieder okay.
Ein Workaround könnte sein, dass man das Aktualisierungsintervall nur auf 5-10 Sekunden stellt, wenn die Daten wirklich benötigt werden, also sie z.B. gerade in der VISU angezeigt werden.
Mittelfristig werde ich mal prüfen, ob ich es ähnlich wie bei den HUE LBS aufbauen kann. Ein Alexa Control API LBS und je Device ein Alexa Control Device LBS. Der API LBS übernimmt dann die API Calls und verteilt die Status Infos an die Device LBS. Ich bin aber auch nicht sicher, ob das funktioniert, da man ja nicht mit einem HTTP Call des Status mehrerer Echos abfragen kann.
Zunächst müsste man ohnehin mal herausbekommen, ob es tatsächlich am Limit der API Calls liegt. Ihr könnte ja mal die Zeit stoppen, bis der Fehler auftritt. Und danach mal die Wartezeit verdoppeln (z.B. 20 Sekunden). Dann sollte es doppelt so lange funktionieren.
Ein Workaround könnte sein, dass man das Aktualisierungsintervall nur auf 5-10 Sekunden stellt, wenn die Daten wirklich benötigt werden, also sie z.B. gerade in der VISU angezeigt werden.
Ich habe zwar mit Alexa rein gar nichts am Hut, aber genau das Thema ist gar nicht so einfach lösbar, wenn man eine Visu mit mehreren Usern nutzt. Es wäre gut, wenn man auf irgend eine Weise ein KO setzen könnte, wenn irgend ein User auf einer Visu-Seite. Oder gibt es da schon was, was ich bislang übersah. Derzeit setze ich ein Flag, wenn ich eine bestimmte Seite aufrufe, aber das funktioniert nicht sinnvoll für mehrere User. Ich nutzde das gleichfalls für dynamische Abfragefrequenzen - bei mir aber eher ModBus, bzw. Multicast
Nachtrag:
Müsste das nicht irgendwo in der DB stehen, welcher User/Visu gerade auf welcher Seite steht und wäre nicht ein LBS denkbar, der als String-Werteliste alle Seiten-ID ausgibt?
Ausgelöst durch einen Trigger, den man auf seinem Menü-Include einfach bei jedem Seitenwechsel per KO auslöst, also last-sparsam wäre. Dahinter könnte man dan auswerten, ob im String bestimmte ID vorkommen, für die ein Flag gesetzt werden soll, z.B. ein Alexa-Flag-KO oder ein Energie-Flag-KO setzen und entsprechend daran z.B. die Abfragefrequenz hängen.
Zuletzt geändert von saegefisch; 09.05.2018, 22:32.
Grund: Nachtrag
Frage: Fragt jeder Baustein jede info für jedes Gerät ab (also serarch devices, getstatusinfo, checknotifications)?
Das würde heißen jede zusäzliche Alexa - ob gemanaged oder nicht - erzeugt zusätzliche Last?
Wenn dem so ist - währe es hilfreich nur einen Baustein zu verwenden und diesen "dynamisch" umzuschalten?
Ich habe jetzt mal auf 60sek intervall umgestellt... die nächsten Tage bin ich erstmal unterwegs (leider kein Feiertag :-( ).
serachDevices() und checkNotifications() laufen auf Amazon Account Level, d.h. sie liefern alle Geräte, sowie alle Alarme aller Geräte zurück. Daher würde es reichen, wenn diese beiden Funktionen nur von einem (separaten) LBS ausgeführt werden. Das searchDevices() kann man ggf. auch weiter optimieren. Im Moment dient es dazu sicherzustellen, dass man vor dem getStatusInfo() auch wirklich alle Amazon Devices kennt, die online sind. Ansonsten würden ggf. Geräte fehlen oder man würde versuchen den Status von Geräten zu holen, die nicht mehr online sind.
getStatusInfo() muss von jedem LBS ausgeführt werden und liefert auch nur den Status EINES Echo Devices. Da lässt sich eigentlich nicht viel optimieren, außer halt das Update-Intervall anzupassen.
Updates werden allerdings noch auf sich warten lassen, da ich derzeit noch einige echte Baustellen im Garten habe.
bei mir funktioniert dieser Baustein nur zum Teil.
Bei mir wird die automatische Anmeldung nicht funktionieren da ich bei Amazon ZweiFaktor Authentifizierung aktiviert habe (und aus Erfahrungen im Freundeskreis nicht wieder von weg möchte).
Wenn ich meine Werte manuell Eintrage funktioniert es, leider aber nicht für längere Zeit. Der Baustein zeigt dann auch über A10 = 0 an das er den Dot nicht kontrollieren kann. Wenn ich den Cookie Wert neu setze funktioniert es wieder.
Hat da jemand Lösungen/Suchansätze für mich? Oder hab ich da Pech gehabt?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar