MainUI does not get updated after a few hours

Hi,

I want to display an OH3 MainUI overview page on a Raspberry Pi 3b with touchscreen. The Raspberry Pi is connected to my home network via wifi. OH3 (3.2.0) runs on an x86 Server inside a Docker container.

Everything runs fine for a few hours but then the displayed items on MainUI are not updated any more. I have to reload the page via the Help page to get it back to work.

Maybe this issue is related to the unreliable wifi connection. To proof that I disabled and re-enabled wifi on the Raspberry Pi. After doing so the Items also did not update any more.

A possible (but ugly) workaround is to reload the page every few hours or trigger reload on network reconnect.

Is there a better way to fix that problem?

Best regards,

Rash

Not without more information about why it stops updating after a time. Try opening the console log of the browser running MainUI and see if anything jumps out when it stops updating. Maybe there are errors with the SSE feed or something like that.

Related:

1 Like

I was thinking about the same approach

How do you want to

?

Basically what we need is to execute a javascript on the client.
You can do that with javascript injection, but I guess you will run into other problem like browser blocking this script.

Maybe some experts have a good idea?

It helped for me to delete those widgets, which are complex, i.e. which have more than ~8 items.

I checked the Firefox console log and found an error:

ERROR: The connection to http://<MY_OH3_SERVER>/rest/events/states was interrupted while the page was loading.
WARNING: SSE error
INFO: =!= Event source connection brokenā€¦

funny. While I was issueing a ticket here, your post came right in timešŸ˜€

Regarding the ā€œuglyā€ way:
I have also been thinking about either doing some javascript injection or in restarting the Raspi on network loss.

It helped for me to delete those widgets, which are complex, i.e. which have more than ~8 items.

My page has 13 Controls, most of them are oh-label-cell with trend item and analyzer action, but one is quite complex showing weather information (a modified version of the weather card from GitHub - rgrollfitz/oh3-widgets ).

Maybe the issue is related to timeouts or concurrency problems, maybe especially on slower devices.

could you do us a favour and remove that widget for a day and see if the problem persists?

No problem, I manage the OH configuration files in a git repository so I can easily modify the page and roll back after this test. I removed all widgets except the outdoor temperature.

Sorry for the long delay. I did extensive testing with different widget configurations and different network conditions.

Test environment:
The Raspberry Pi 3b is installed in the central corridor of our house. It is connected via wifi with mediocre signal strength. The device can connect to one of three access points in our house (same SSID, 2.4GHz, 802.11r handover).

For the first test I removed all widgets but one. The errors still occured.
For the second test I connected the device via GBit ethernet. This way I had no problems regardless of the number or complexity of widgets.
For the third test I moved the device near any of my wifi access points. This was as reliable as using ethernet cable.

Assuming the problem is related to the mediocre wifi connection I inspected all network related logs and found the problem in dhcpd:
About six seconds before the SSE error is logged in the browser dhcpd announces ā€œwlan0: carrier lostā€ and deletes address and route. In the same second the carrier is acquired again and the dhcpd restores address and route. This is finished at the same time when the Connection to /rest/event/states gets interrupted and the SSE error occurs.

So for me it looks like the event stream gets disconnected on any network glitch. It is easy to reproduce this with pulling a network cable for a second.

I think this issue really should be fixed to make 24/7 displays reliable. At least the Main UI should show that it is disconnected.

2 Likes

Good job! Unfortunately the ticket on Github does not get any attention. I assume it will not be fixed soon and maybe it will never be fixed.
Anyway, thank you very much for pursuing this further and to provide us with new information so that we can derive workarounds from that

Update: I tried to use the chromium web browser on the Raspberry Pi and then this error does not occur. So the error seems to be specific to firefox.
The bad news is that I already switched from chromium to firefox because with chromium loading the main page loads for a long time and results in a timeout (ChunkLoadError). Iā€˜ve already seen forum discussion about this error. one suggested solution was switching to firefoxā€¦

and it is also device specific.
On iOS I have this problem no matter if I use Chromium or Firefox