Web gui does not load any more relieable #1000
Comments
|
There wasn't changed anything regarding the webserver etc: v23.5.31...v23.6.1 |
|
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. |
|
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. |
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? |
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:
#1000 (comment)
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. |
|
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. |
|
the joy was only very short ... also this gets broken after a while. :-( |
|
I can confirm that there is some issue with showing live data in browser... It stop showing data in Firefox and EDGE browser... 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: |
|
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.
|
|
Network is looks ok without errors: But in console I get this error: |
|
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. |
|
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. Are you running any other software which accesses this endpoint very often? |
|
in my case node red queries /api/livedata/status every second. |
|
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). 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: |
If you get null then you are out of memory. You can either call the |
What do you see in the serial console if this happens?
I don't know what you HA is doing but it uses the same topics under |
|
My debugger has stop working(Im by acident pres some button)... Now Im get it working... |
|
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. |
|
@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. |
That doesn't make any sense. How many inverters have you connected? My default heap usage is at around 126kB with 3 inverters. The generation of the json response takes ~40kb. |
|
One inverter, hmt-2250-6t |
|
My with MQTT + 3 inverters(offline) have used 151kB and Free 130kB |
|
I also got issues under Details
|
|
@delacor which json file did you upload? can you show a screenshot of the json file? |
Ok, thanks for the hint. |
|
@delacor Factory reset does not delete the The best way when flashing a new type of firmware is a complete ESP erase. (Can be chosen in almost any flashing tools) |
|
I have the empty Live Data view when enabling MQTT. Doesn't seem to be a memory issue (according to the System view). JS console is showing "Uncaught TypeError: can't access property "inverters", this.liveData is null". Some sort of race condition? Setting the MQTT frequency to 60s (from 5s) didn't help. MQTT data flows as intended. Newest firmware. |
Please try a power cycle after the upgrade. (Not just reboot) |
|
Thanks. Unfortunately no luck. Both Firefox and Chrome, private browsing or not show the same console output and an empty Live View. MQTT and DTU polling frequency both set to 60s didn't help either. |
|
Did you reload the web ui properly after the firmware upgrade (CTRL+F5 or clearing the cache?) |
|
Yes. Multiple times and with new browsers/devices. Now the it seems to have made a sort of factory reset. Back to the base settings, local access point, no inverters, nothing configured. 🤷 Oh well. Will report back once I've configured everything again (must use that backup tool...). |
|
Ok. Everything is set up again. As soon as I enable MQTT (uses TLS, might be an additional strain on the ESP32 or additional cause for any kind of race conditions), the Live Data isn't shown anymore. Disabling MQTT makes the Live Data reappear. (Edit: MQTT Home Assistant auto discovery is enabled as well). |
|
Interestingly /api/prometheus/metrics shows "too many requests" and /api/livedata/status actually returns a "null", meaning an actual string with four characters/bytes. The response headers are: |
|
Thanks for your help. openDTU now sends MQTT messages reliably for 50 hours, the livedata/status still yields a string "null". /api/eventlog/status?inv=XXX works (even though getting the events by MQTT would be preferable), therefore I have all the data I need. Still a weird bug. 🤷 |
|
Version 23.9.18 solved this problem for me. Thank you! |
|
@tbnobody this might be a hint. On openDTU-onBattery we extended the datasets wich are handled by Here is an example where I put some logging in void WebApiWsLiveClass::loop()
{
// see: https://github.com/me-no-dev/ESPAsyncWebServer#limiting-the-number-of-web-socket-clients
if (millis() - _lastWsCleanup > 1000) {
_ws.cleanupClients();
_lastWsCleanup = millis();
}
// do nothing if no WS client is connected
if (_ws.count() == 0) {
return;
}
if (millis() - _lastInvUpdateCheck < 1000) {
return;
}
_lastInvUpdateCheck = millis();
uint32_t maxTimeStamp = 0;
for (uint8_t i = 0; i < Hoymiles.getNumInverters(); i++) {
auto inv = Hoymiles.getInverterByPos(i);
if (inv->Statistics()->getLastUpdate() > maxTimeStamp) {
maxTimeStamp = inv->Statistics()->getLastUpdate();
}
}
// Update on every inverter change or at least after 10 seconds
if (millis() - _lastWsPublish > (10 * 1000) || (maxTimeStamp != _newestInverterTimestamp)) {
try {
std::lock_guard<std::mutex> lock(_mutex);
DynamicJsonDocument root(4200 * INV_MAX_COUNT); // TODO(helge) check if this calculation is correct
JsonVariant var = root;
MessageOutput.printf("Calling /api/livedata/status jsonDocument capacity = %d.\r\n", root.capacity());
MessageOutput.printf("Calling /api/livedata/status FreeHeap = %d, MaxAllocHeap = %d.\r\n", ESP.getFreeHeap(), ESP.getMaxAllocHeap());
generateJsonResponse(var);
MessageOutput.printf("Calling /api/livedata/status JsonDocumentSize = %d (allocated %d).\r\n", root.memoryUsage(), 4200 * INV_MAX_COUNT);When DynamicJasonDocument::capacity() Actual I do further testing. But I guess I have to lower the max number of supported inverters from 5 to 3 for openDTU-onBattery. And we should check each createion of DynamicJasonDocument, if it was succuessfull. |
|
This should be fixed in version v24.2.12 as the live data entry point consumes at lot less memory. |
|
Yesterday I had the exact same problem. I have openDTU-onBattery 2024.03.07 . The ESP has a poor RSSI of -87. OpenDTU send all informations over MQTT to HA but the webpage is simply empty (white) without content. I've done a power cycle but with no success. The server is reachable but empty page. After a second power cycle and slightly new better positioning of the openDTU device I got a working webpage back. |
@AloisKlingler & @helgeerbe as JSON documents or parts of it can consume quite some memory before they are sent out: Details
{
"inverters": [
{
"serial": "114173212345",
"name": "HM-600",
"order": 0,
"data_age": 3,
"poll_enabled": true,
"reachable": true,
"producing": true,
"limit_relative": 100,
"limit_absolute": 600
},
...
],
"total": {
"Power": {
"v": 23.60000038,
"u": "W",
"d": 1
},
"YieldDay": {
"v": 1098,
"u": "Wh",
"d": 0
},
"YieldTotal": {
"v": 1612.475098,
"u": "kWh",
"d": 3
}
},
"hints": {
"time_sync": false,
"radio_problem": false,
"default_password": true
},
"vedirect": {
"enabled": false
},
"huawei": {
"enabled": false
},
"battery": {
"enabled": false
},
"power_meter": {
"enabled": true,
"Power": {
"v": 121.526001,
"u": "W",
"d": 1
}
}
} |
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
The text was updated successfully, but these errors were encountered: