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

[homecineplexx]

@apollon77 said in Test Adapter Daikin-Cloud 0.4.0:

@homecineplexx Es gibt aussagen vomn Daikin die besagen das es sein könnte das effektiv maximal 24-48h geblockt ist auch wenns mehr heisst - WENN in der Zeit keine neuen requests kommen. Das gilt es zu verifizieren. Die Frage ist am Ende wie Du so viele Requests bekommen hast ... Könnte an einer ersten Version des Adapters gelegen haben, das wäre blöd, sollte aber in den aktuellen Versionen 0.4.6+ nicht mehr passieren.

Also lass mal nen tag aus und versuch nochmal und poste bitte was dannkommt

Danke für die Erweiterung des Adapters und danke für die Info...werd ich so machen

[Jensen]

@apollon77
Danke für die hervorragende Arbeit. Läuft auch bei mir wieder.
Ich vermisse climateControl.demandControl....
Wurde das von Daikin gestrichen?
Gruß Jens

[apollon77]

@jensen Ja, am besten Feedback an Daikin geben das es und wofür es gebraucht wird. Die haben aus Gründen bestimmte Daten nicht mehr verfügbar, aber vllt ändern Sie ja Ihre Meinung

[Hofmann IOBRF]

@apollon77
Der Adapter funktioniert wieder. Danke.
Eine Frage zum rateRemainingDay:
wie kommen diese Werte zustande? Ich frage alle 10 Minuten neue Werte ab und habe heute noch nichts gesteuert.
Kommen die von der API, oder werde sie vom Adapter berechnet?

[Armilar]

@hofmann-iobrf

interesssant, sah bei mir mit einer älteren Version des Adapter auch so aus... jetzt ist es aber sauber seit zumindest der 0.4.6 oder 0.4.7

also nichts gesteuert, nur abgerufen...

[Hofmann IOBRF]

@armilar ich hab 0.4.6
Aber alles andere Funktioniert wieder.
z.B. die Energiedaten:

[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.