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.
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.
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.
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ā¦
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.
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.
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ā¦