OpenDTU
OpenDTU copied to clipboard
tbnobody
Web gui does not load any more relieable
What happened?
After the update to the latest 23.6.1 the webgui starts failing to load after some time.
The api call for fetching live data json still works flawless (and fast). Power cycle helps, but after some time again the webgui is not reachable any more.
This does not happen with 23.5.31. I downgraded to this version and it stays reachable also with web gui.
Wifi signal is between -72 and -78.
To Reproduce Bug
I tried to narrow down, but i could not. 😞
Expected Behavior
Webgui should stay available.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
23.6.1
Relevant log/trace output
No response
Anything else?
No response
There wasn't changed anything regarding the webserver etc: https://github.com/tbnobody/OpenDTU/compare/v23.5.31...v23.6.1 Only the sunset calculation was changed. Have to tried clearing your browser cache or use a private tab?
I saw the changeset, and that's why i have reverted and flashed to the new several times to see if it is firmware based. Yes, different browsers, different end devices too, ...
Did you try to power cycle the ESP or did you just use the web based reboot feature?
as I cannot reach the GUI I need to powercycle. the esp is mounted in a IP65 case outside the house, so I need to do this by the circuit breaker.
Meine Live Ansicht zeigt auch nichts mehr an. Der Rest der GUI läuft. Ein Neustart über die Software ist nicht möglich. Es erscheint eine Fehlermeldung: "Fehler beim interpretieren der Daten" Hardreset ist derzeit nicht möglich, da ich aus dem Urlaub nur VPN Zugriff habe.
Meine Live Ansicht zeigt auch nichts mehr an. Der Rest der GUI läuft. Ein Neustart über die Software ist nicht möglich.
Completly different behavior.... In your case the web interface is in the browser cache and the API is not working anymore. Which version are you running?
Wifi signal is between -72 and -78.
Just based on personal experience, see #836, but I noticed that signal strength below -60/-65 could trigger strange activities on the openDTU side. Nonetheless, any AP/Router and esp32 board mix may exhibit different behaviours and I didn't updated yet to latest FW
Ich habe eben die aktuelle Version zur Sicherheit installiert. Jetzt habe ich eine Anzeige der Live Daten aber die DTU hat keine Verbindung zum WR mehr. PS, jetzt ist die DTU gar nicht mehr erreichbar. Ich kann erst in einer Woche wieder Realdaten liefern, dann bin ich wieder vor Ort.
BlueMail for Android herunterladen
Am 5. Juni 2023, 13:32, um 13:32, tbnobody @.***> schrieb:
Meine Live Ansicht zeigt auch nichts mehr an. Der Rest der GUI läuft. Ein Neustart über die Software ist nicht möglich.
Completly different behavior.... In your case the web interface is in the browser cache and the API is not working anymore. Which version are you running?
-- Reply to this email directly or view it on GitHub: https://github.com/tbnobody/OpenDTU/issues/1000#issuecomment-1576541600 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
@tbnobody I have reverted commits 114ebb2 and 5558dff (the "under the hood" changes of 23.6.1) and it now works for me again. if somebody else wants to try: firmware.zip
But then it's only a problem with your browser. Because these data get just downloaded to your browser and executed there. This has nothing todo with the code on the ESP.
if I would not have tried several browsers and several end units (mobile phone, win11 client, two different win10 clients, debian 11 linux) I would be the same opinion. it's really weird. I also can see the relieable livedata json comming trough.
the joy was only very short ... also this gets broken after a while. :-( in browser debug tools I can see: http://192.168.0.247/js/app.js net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)
I can confirm that there is some issue with showing live data in browser... It stop showing data in Firefox and EDGE browser...
Firefox:
EDGE:
After Refresh(CTRL+F5) it for few ms show text "Live Data" and progress circle and then they disapear...
And I can confirm that it's working for > 5 days without any problems:
But this not help. What do you see in the serial console (not the web based one) in the moment when you refresh the page?
In monitor I see only this:
17:38:15.582 > Websocket: [/livedata][211] connect
17:38:16.293 > Websocket: [/livedata][210] disconnect
If you enter the development tools of your browser, there should be a tab called "network" where you can see all the requests your browser is performing. Following background:
- at first the web page is loaded from the esp (index.html and app.js) or is loaded from the cache.
- then, depending on the page a get request is performed to load the dynamic data. In case of the live view it's the first initial data.
- all periodically loaded updates are coming from a web socket.
The 150byte for the Websocket response looks wrong. This would also explain the error in the console. I would bet that if you click onto the livedata line in the network tab and the look at the response data (maybe separate tab) you will see an empty or null response. Question is just why. If there would be too less memory you should see a message in the serial output.
Do you mean this:
Maybe just idea can be maybe password related because password include special characters and also special character "@" ?
Do you mean this:
Maybe just idea can be maybe password related because password include special characters and also special character @ ?
my password does not contain any special character.
Im also try clear cokies DTU has lose dark mode, language settings and logout me. Then Im relogin and it didn't help. Enable "Allow readonly access to web interface without password " also do not help.
hm no, cookies etc don't have any impact on the backend. The frontend is completly independent of the backend. It just communicates using the api endpoints and exchanges json data.
if the web socket reply stays empty are you still able to call the /api/livedata/status endpoint and do you get a proper response?
Are you running any other software which accesses this endpoint very often?
in my case node red queries /api/livedata/status every second. if I do this by browser, I get normally a speedy response. sometimes if fetches the half, the other half comes a moment later (but wthout timeout). and sometimes only "null" is displayed.
In my case DTU is not in production and I have enabled MQTT and integrated it into home assistant. I have prepared zero export automation in HA but do not work(Is disabled) beacause inverters are currently offline(In process of installing). I don't set/request over MQTT or WEB API anything...
If I call /api/livedata/status from browser I get null response.
In MQTT Explorer I see updates in solar/dtu status and inverters reachable/producing/last_update. But onder HA binary_sensors I don't see that update will be send... Maybe this updates are send only on change or if inverters are online?
Maybe one thing. Im update FW few days ago maybe at same day or next day after release. But looks like DTU reset one day ago:
in my case node red queries /api/livedata/status every second.
If you get null then you are out of memory. You can either call the /api/livedata/status endpoint OR the websocket. Both is not possible. Collecting this data and preparing the whole request requires ~40kb of continous memory. This is not always given. (The ESP has 300kb of memory)
The web API was never intended to be called every second. You will not even get new data from the inverter every second.
If I call /api/livedata/status from browser I get null response.
What do you see in the serial console if this happens?
But onder HA binary_sensors I don't see that update will be send... Maybe this updates are send only on change or if inverters are online?
I don't know what you HA is doing but it uses the same topics under solar/#. So if this topics are update everything is fine and the problem relies most likley on the HA side.
My debugger has stop working(Im by acident pres some button)...
Now Im get it working... Im change in MQTT settings "Publish Interval" from 5 seconds to 15 seconds and after save Live View start working. Now Im change it back to 5 seconds and still work... I will leave debugger connected and see if it will again disapear and what will be in debug log...
I will add an additional exception handler in the next release. the current one only shows messages if there is too less memory. but maybe there is something different. (will push this later)
I had in settings -> DTU settings the "Poll Interval" set to 3 seconds. Since I changed this to 10 Seconds, it is running much more stable. (just removing the secondly polling of the live statistics did not help)
@tbnobody just a question - in system info I can see "Heap" normally at around 150kB and very seldom at around 100kB
what does the RAM mostly consume? the communication to the inverter and processing it's data, or the json'ing and offering by HTTP? If the second, would it be an option to have a shorter e.g. "/api/livedata/totals" endpoint which only offers current total (overall, day, power) of all inverters?
Thanks. :-)
//btw: the reason for "each second" was for me to be lazy and just enslave the opendtu in the same node red flow as my fronius inverters are. I am collecting secondly data (and processing them at current production, current consumption, current grid usage, etc) from all of them for visualization.