JSON Response does not reflect changed value (and updates are slooooooow...)

[sebnaf]

Hardware: V3

Changing a value like http://.../mqtt?payload=alw=1does still return the old, original value in the JSON Response. The changed value is only available in /status after 4-6s, which is something we cannot work with.

I'd expect

• the JSON response to reflect the changed value instantly
• the /status endpoint to reflect the correct value shorty after the change, not after several seconds.

Thank you

[sebnaf]

according to the documentation, this really seems to be a bug.

4. Rückgabewerte : Lokales WLAN / Hotspot Verbindung Rückgabe WLAN Hotspot Komplettes status JSON Objekt mit bereits geänderten Wert WLAN lokales Netzwerk Komplettes status JSON Objekt mit bereits geänderten Wert Bei jedem Status Request und jedem Kommando wird das Status JSON-Objekt zurückgegeben. Ein nicht erfolgreiches Kommando erkennt man daran dass sich der Wert im Status Objekt nicht geändert hat.

[sebnaf]

Any remarks here? Thank you

[amnesia106]

+1

[bacanol]

+1

[Sillium007]

+1

[Kanonkop]

+1

[Optic00]

+1 just ordered a v3 for a relative

[peterpoetzi]

This bug is fixed internally, we will release an firmware update very soon

[sebnaf]

Excellent news, thank you @peterpoetzi!

[amnesia106]

[sebnaf]

@peterpoetzi Ihr lasst hier einen Response 13s warten - das ist doch nicht wirklich elegant… Könnt ihr da bitte nochmals nachbessern?

sna@arbeitsgeraet  ~  time curl 'http://10.10.20.22/mqtt?payload=alw=1'

{"version":"B", ... ,"loa":0,"lch":507} curl 'http://10.10.20.22/mqtt?payload=alw=1'
0.00s user 0.00s system 0% cpu 13.417 total

[sebnaf]

@peterpoetzi Falls dieses Problem mit der API v2 nicht bestehen sollte, bitte ich umgehend um die Dokumentation, damit wir das umbauen können. Die 13s Wartezeit sind architektonisch noch schlimmer als der Fehler an sich.

[CHulkW]

+1

Da konnte ich eher mit dem Fehler leben, als mit der langen Wartezeit. So ist das leider wirklich nicht gut nutzbar. Ich habe bei mir auch 13s gemessen, scheint also kein Einzelfall zu sein.

[sebnaf]

Die ersten User melden einen Timeout. Es wäre wirklich gut zu wissen, ob das mit der API v2 besser funktioniert. Hat irgendjemand Zugang dazu oder kann sich @peterpoetzi bitte dazu äussern? Danke

[chilobo]

Auch bei mir wird die GO-E unter openhab nicht mehr initialisiert: Total timeout 5000 ms elapsed IP/status und IP/api/status liefern im Browser noch Daten, dauert ca. 7 s

Gibt es die Möglichkeit eines downgrades auf eine funktionierende Firmware?

[peterpoetzi]

Ich kann bestätigen dass bei manchen Usern die v1 API jetzt mehrere Sekunden zum Antworten braucht. Wir arbeiten hier an einem Bugfix

[sebnaf]

@peterpoetzi Danke. Da nun doch einige Implementationen seitdem ein Timeout liefern - mit welchem Zeithorizont dürfen wir hier rechnen?

[chilobo]

In Openhab habe ich die timeouts beim Lesen und Senden auf 10 s hochgesetzt. Jetzt klappt die Steuerung wieder. Na ja: fast immer. Ab und zu kommen noch timeout-Meldungen, vielleicht muss ich noch etwas zulegen. Bin jetzt auf 13 s gegangen und habe die Zeit für das Ausführen der Regel, gesteuert von den PW-Messwerten, auf 25 s hochgesetzt.

[sebnaf]

@chilobo Das wird wahrscheinlich nur mittelfristig etwas bringen, da das Timeout länger wird, je länger die Uptime ist. Hoffen wir auf einen baldigen Fix.

[chilobo]

Scheint zu stimmen. Warum wird das Timeout länger? Macht es dann Sinn:

• die Box ab und an im Sicherungskasten stromlos zu machen
• die Ladung neu zu starten
• oder reicht es, die Box aus- und wieder anzuschalten?

Habe gerade mal Letzteres probiert, scheint nicht sicher zu helfen.

[sebnaf]

Hallo @peterpoetzi, könnten wir bitte eine Aussage betreffend Zeithorizont Bugfix bekommen? Danke

[peterpoetzi]

Es handelt sich hier um eine Thread-Locking Problem, das bereits intern gelöst und und gerade getestet wird. Ein Update erwarte ich für heute 09.09

[sebnaf]

Danke für das Update. Das sind sehr erfreuliche News. Danke, dass ihr so schnell seid.

[amnesia106]

Update angekommen! time curl 'http://192.168.2.119/mqtt?payload=alw=1' real 0m0,497s user 0m0,000s sys 0m0,011s

Top! Danke!

[sebnaf]

Definitiv eine saubere Lösung nun, danke @peterpoetzi.