UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Armilar]

@hofmann-iobrf

Kannst dann auf die 0.4.7 updaten... Sieht gut aus :blush:

[Hofmann IOBRF]

@armilar Normalerweise sollte der Wert stabil bleiben, weil es ein rollendes Fenster ist. D.h. es werden immer die Anzahl der Requests der letzten 24h betrachtet.
So weit es in der Doku steht.
Warum es zu solchen Sprüngen kommt wie bei mir, oder warum es bei dir abnimmt kann ich nicht verstehen.

[Armilar]

@hofmann-iobrf

Genauer betrachtet, finde ich darauf auch keinen Reim ;-)

In meiner gedanklichen Welt hatte ich eigentlich ab 0 Uhr eine 200 erwartet:

stattdessen eiert der Wert wild herum und stabilisiert sich erst um 8:02 Uhr

??? :blush:

[maximal1981]

mal danke für das Update

ein paar Fragen:

• bleibt daikin-cloud.0.info.rateLimitMinute immer auf 20, egal was man in den Einstellungen einträgt (ich hab es glaub ich selbst erkannt, geht auf 20 bei true, ist ja schon später
• zählt nur die Abfrage zum rateLimit, oder auch wenn man Werte über Scripte ändert, die werden dann ja an die api geschickt, und in weiterer Folge kommt die Steuerung über die cloud retour
• wann endet das langsame Datenabfrageintervall wieder, oder könnte man das noch einbauen

[apollon77]

@hofmann-iobrf Die kommen aus HTTP Headers von jeder Antwort von den Daikin Servern. Kommen also von Daikin. Ich habe keine Ahnung warum die so schwanken.

[apollon77]

@hofmann-iobrf Es ist glaube nicht ganz so einfach- also nicht rollierend 24h ... Ich glaube eher sie zählen den aktuellen tag und kennen den vortag. Dann wird je nachdem wieviel vom aktuellen Tag schon vergangen ist der aktuelle counter und ein "zeitlicher Rest Anteil des Vortags" genommen.
Damit errechnen Sie die aktuellen Requests und entscheiden ob ok oder nicht oder wie lang gepsert ist (was die Response angeht). Die Sperre ist aber dynamisch.

Das erklärt auch warum man auf 15 Tage sperrzeit kommen kann wenn man an einem Tag 3000 Requests gemacht hat (also 200 und 2800 weitere während man rate limitiert war).
Wenn man also am Tag danach keine Requests macht bauen sich die 2800 "zu viel" vom Vortag über den Tag hin ab und sollten am Tagesende weg sein ...

Der 15 tage gesperrt User hat auch dann geschrieben das er nach 43h offline Zeit dann bei 170 Requests "übrig" war.

Also ergo: Es ist rechnerisch rollierend, aber nicht real rollierend

Ich überlege gerade ob man daraus was für Sperrzeiten des Adapters ableiten kann. Mal schauen

[Kymchy]

@armilar said in Test Adapter Daikin-Cloud 0.4.0:

@hofmann-iobrf

Kannst dann auf die 0.4.7 updaten... Sieht gut aus :blush:

Mir wurde die Version 0.4.6 als Update auf 0.3.0 angeboten, die einst via Github installiert worden war.
Habe ich dann so installiert und soweit läuft jetzt alles, aber ein Update auf 0.4.7 wird mir jetzt nicht mehr angeboten.

Wie mache ich jetzt ein Update auf 0.4.7? Einfach wieder drüber installieren via Github Link?

viele Grüße
Kymchy

[apollon77]

@kymchy 0.4.7 ist im Beta Repo

[maximal1981]

@apollon77 :

ist das ein Fehler? Auf und ab dreht sie sich aber
Send state change for %ID%.climateControl.onOffMode with value=on to climateControl : onOffMode : undefined

und könntest du meine Fragen oben bitte beantworten?

[apollon77]

@maximal1981

bleibt daikin-cloud.0.info.rateLimitMinute immer auf 20, egal was man in den Einstellungen einträgt (ich hab es glaub ich selbst erkannt, geht auf 20 bei true, ist ja schon später

Keine Ahnung ... frag Daikin ... Wir geben die Werte aus die von denen kommen. Ich habe aber auch schon 19 gesehn.

zählt nur die Abfrage zum rateLimit, oder auch wenn man Werte über Scripte ändert, die werden dann ja an die api geschickt, und in weiterer Folge kommt die Steuerung über die cloud retour

Alles was werte Setzt kostet einen call und dann das pollen. am Ende macht Debug log an. Immer wenn neue rate limit infos kommen gabs auch nen Call.

wann endet das langsame Datenabfrageintervall wieder, oder könnte man das noch einbauen

... wann immer Du den State auf false setzt. Aktuell gibts da keine zeitlogik, sondern einen state den Ihr setzen können wann immer slow ausreicht und wann es wieder öfter sein muss. Ja man könnte noch eine Zeitsteuerung einbauen, aber da war in der zeit aktuell nicht drin und man müsste auch überlegen wie man das genau macht. Könnt Ihr Euch ja mal überlegen, aber fürchte dann kommen ganz komplexe Dinge raus und das ist im JavaScript Adapter besser aufgehoben :-)

[maximal1981]

@apollon77 sagte in Test Adapter Daikin-Cloud 0.4.0:

... wann immer Du den State auf false setzt. Aktuell gibts da keine zeitlogik, sondern einen state den Ihr setzen können wann immer slow ausreicht und wann es wieder öfter sein muss. Ja man könnte noch eine Zeitsteuerung einbauen, aber da war in der zeit aktuell nicht drin und man müsste auch überlegen wie man das genau macht. Könnt Ihr Euch ja mal überlegen, aber fürchte dann kommen ganz komplexe Dinge raus und das ist im JavaScript Adapter besser aufgehoben :-)

achso, ich habe das den Wert im slow-Mode als Uhrzeit verstanden. Steht ja nach dem installieren 1800 drin, dachte mir, ergibt sinn, da Sonnenstand tiefer ist. Deswegen auch die Frage, um welche Zeit es wieder ins normale pollen geht.

das hast eh mitbekommen (oder ist das eine Rückmeldung aus der Cloud?):

Send state change for %ID%.climateControl.onOffMode with value=on to climateControl : onOffMode : undefined

[apollon77]

@maximal1981 Da sist schon korrekt so.

[apollon77]

Version 0.4.8 geht gerade auf npm.

Wir optimieren hier die Rate Limit Wartezeit auf maximal 24h und versuchen es dann nochmals.
Und zusätzlich hat der Adapter jetzt einen Schutz davor gleiche Werte nochmals zu senden. Default ist das so eingestellt - man kann es überschreiben ist dann halt selbst dafür verantwortlich keinen Blödsinn zu treiben :-)

Dieser Modus hat die Chance vielen zu helfen vor allem wenn Skripte ggf komische Dinge immer wieder gleich setzen. Es hat natürlich die "gefahr" das wenn man es am Adapter vorbei zb einschaltet der Adapter bis "polling Interval" spöter davon nicht weiss und man es somit nicht ausschalten kann weil der Adapter denkt das es doch aus ist.

Wäre super wenn Ihr Euch die Version ansehen und testen könntet dann geht die Zeitnah auch ins Stable wenn ich Rückmeldungen habe. Danke

Ingo

[Jensen]

Irgendwas stimmt doch da nicht.
Rate Remaining Day springt hoch und runter, ich kann aber keine Logik erkennen.

[Derda 0]

Ich bekomme den Adapter nicht zum laufen. Admin ist schon länger auf https umgestellt. Einrichtung der Instanz scheint einwandfrei zu funktionieren. In Schritt 7 popt ein Fenster auf, in dem ich auf "I agree" drücke und danach ein Fenster "OAuth OK". Dann Save&Close. Instanz wird aber nicht grün. Im log steht:

Any ideas?

Danke im Voraus
Bodo

[Armilar]

@derda-0

Wenn ich das richtig interpretiere, ist der Adapter ist der Ansicht, dass du den Token (d.h. Client ID und Client Secret) unter Punkt 3 nicht eingetragen hast...

[Armilar]

@apollon77

Von meiner Seite alles okay - Keine Probleme festgestellt seit dem 12.07 mit Update 0.4.8

[Derda 0]

@armilar

Hab Client ID und Secret noch einmal eingetragen und erhalte weiterhin "No tokens existing":

Um auf Nummer sicher zu gehen, hatte ich eine erste App bei Daikin wieder gelöscht und eine neue angelegt. Bei beiden dasselbe Verhalten.

[Armilar]

@derda-0

• Popup-Blocker ausschalten, falls im Browser aktiv
• Speicher dir mal die Redirect-URL von Punkt 4 weg
• App bei Daikin löschen
• App neu anlegen mit Redirect-URL
• Client-ID und Client-Secret unter 3 eintragen
• Punkt 7 ausführen

[Derda 0]

@armilar

Danke für die Unterstützung! Hat aber leider bisher nicht zum Erfolg geführt.

Habe den Adapter noch einmal gelöscht und neu installiert. Den Iobroker-Container neu gestartet.

Habe alle Schritte noch einmal durchgeführt, mal mit Edge statt Firefox. Bei Punkt 7 geht ein Tab auf:

Wenn ich da auf "I agree" klicke, ändert sich der Fensterinhalt, kurz erscheint "Proxy" und dann sieht der Tab so aus:

Und danach diesselben Fehlermeldungen im log.