This screen continually is counting down and showing loading. Waiting 45+ minutes. Also to verify touch, I swiped the screen and the logo was selected and “moved”. So, I am happy to see the touch function work as I was thinking it didn’t. Please see attached image. What can I do about the “Loading Loop”? Current firmware I’m using is hestia-pi-ONE-v1.4-dev-bullseye-6185.img.xz
Device responds to web interface and SSH.
Decided to flash v1.1 and I no longer have an infinite Loading… page but now the OpenHAB fails to download Addons while configuring the UI.
2023-12-10 01:03:04.313 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed in$
Error downloading mvn:org.openhab.binding/org.openhab.binding.exec/2.4.0
v1.4-dev is the best image to use. My guess is that something went wrong with flashing the SD card. The fastest way to get up and running should be to just re-flash it.
If you are able to take an image of the SD card that’s not working, I can try to figure out what, specifically, is going wrong. I am curious as to what’s happening here, but it seems like trying to have you run a bunch of ps commands from the shell would be a very long and tedious process.
I’m not sure v1.1 will work anymore. IIRC, OpenHAB changed where they store their plugins. I believe that was the sunset of bintray that caused addons to stop installing.
I can’t remember exactly what I did differently to fix that. It might have been a newer version of OpenHAB2.
reflashed v1.4. Still stuck at loading. I see that my average cpu load never drops below 2.0 and the script is set to wait until it does:
if (($(echo "$(top -b -n1 | grep "load average:" | awk '{print $(NF-2)}' | cut -d, -f1) > 2.00" | bc -l))); then
top - 16:48:23 up 20 min, 1 user, load average: 2.84, 3.10, 2.72
Flashed v1.2: 5 to 10 minutes into Loading…, cpu load dropped below 2.0, so then the oneui screen was started. Showed values of 0 (zero) and took another 5 minutes for openhab to catch up and start pushing out data updates to oneui.
CPU load looks good:
top - 18:02:06 up 42 min, 1 user, load average: 1.09, 1.21, 1.34
Touchscreen responds when I swipe as I can see the I-beam cursor follow my finger, however, tapping on Info, Fan, Cool, Heat icons has no response.
Is there a log to look at touch events?
Is there anything in OpenHAB that I should set, verify or review?
There is no log for touch events that I am aware of, but if you get the cursor or could drag the loading screen, it seems like the clicks are getting though the driver, X11, window manager and registering with the application (which is a web browser).
The touchscreen UI is interacting with a fullscreen web browser, so my guess is that the webpage that is not responding. The question is why? I don’t have an immediate answer to that question, but I have some ideas…
If my theory is correct, that it is the UI webpage that is not responding, I would expect the OpenHAB UI to work just fine. I would also expect the changes to appear on the web UI with a delay (or possibly not at all, depending on how hosed the UI is).
IIRC, your load averages look high for both the v1.2 and v1.4 images. There was a big jump in reported load averages in v1.3 and later, but everything seemed to respond well despite the supposed load averages, so I’m not sure if it’s a difference in reporting or kernel configuration with regards to task switching or what. Once the system is booted and settles down, I’d expect around 0.2 load averages with v1.2 and around 1.0 load averages with v1.3 and v1.4.
Expected boot time is about 15 minutes, but if you leave it running for a few hours or perhaps overnight it would remove all doubt as to what that steady state load averages would be.
We are all using the same hardware except for the SD card, so it’s strange that you’re getting different performance. Others here on the forum have reported that using a faster SD card made a difference. Personally, I have just been using whatever I have lying around and haven’t had any issues, but I think that’s the best lead we have on a root cause right now. It could explain why your load averages are higher than what I and others are seeing, even across different versions of the disk image.
Tools like iotop can show you how much the SD card is being accessed after the system is booted, which could be insightful. To see swap usage, use free -h. I expect it will be non-zero and a slow SD card would affect memory access to anything that is swapped out. I would expect this to just make things slow, not unresponsive, but I’m running low on ideas.
Once we get this figured out, I’ll make sure to update the troubleshooting section of the owner’s manual.
Changing settings via the OpenHAB UI on a laptop, shows up on oneui page on the RPi.
I looked at /dev/input. I have mice, mouse0, and event0. I cat each of those and all of them generated binary data to my ssh session when I swiped or tapped the screen. So system level inputs are triggering, I just don’t know if they are correct or if oneui is trying to handle those events.
I installed xinput_calibrator and ran it. Attempting to tap the first “x” had no response and the xinput-calibrator timed out.
OK, so the browser isn’t locked up and it seems like your clicks are registering and going somewhere, but not to the applications that we want them to go to.
This is a bit of a long shot, but try SSHing into the pi and running this:
git clone https://github.com/goodtft/LCD-show.git
cd LCD-show
./rotate.sh 90
./rotate.sh 0
If that doesn’t work, I’ll want to know about the chips on the back of the LCD screen. I expect that the main chip on there will either say “2046 H1526” or “XPT2046 1914” and it’ll look like one of these photos.
It’s also possible you’re running into an issue that, as far as I know, only @HestiaPi has run into. If that’s the case there is a known fix.
If that fix works for you, I’d be willing to send you a new screen if you’re willing to send me that one. This is a problem I’ve been unable to reproduce and if I had the hardware I could work on trying to find some configuration that works with all these variations of these 3.5" screens which all seemingly use the same chip. I can’t guarantee I’d be successful, but having the hardware that doesn’t work as expected makes it a whole lot more likely!
Also until we get this sorted out, please do all tests with the cover off so we can be sure that’s not compounding the issue. You’re probably already doing so, but I wanted to make sure to mention it in case that wasn’t already the case.
All tests have been with the cover off.
How is it that the driver isn’t installed?
pi@raspberrypi:~/LCD-show $ ./rotate.sh 90
Please install the LCD driver first
Usage: sudo ./xxx-show. xxx: MHS35,LCD35,MPI3508 etc.
evtest produces events:
Event: time 1702440808.654901, type 3 (EV_ABS), code 0 (ABS_X), value 839
Event: time 1702440808.654901, type 3 (EV_ABS), code 1 (ABS_Y), value 3573
Event: time 1702440808.654901, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 186
Event: time 1702440808.654901, -------------- EV_SYN ------------
I think that repo only checks to see if you installed it from that directory. There’s probably some file you could create to indicate to the script that the driver is installed, but it would probably be easier to just run the install script again.
And thanks for the tip about evtest. I might add that to the troubleshooting section of the owner’s manual. It looks like a nice debugging tool.
I ran the install script of LCD-show and ./rotate 90 was accepted then the pi rebooted.
Then ./rotate 0 and another reboot.
And the side-effect of the LCD35-show install is the boot hangs at system-ifup.slice, although I can SSH. OneUI is not loading. kweb process is not listed, so perhaps xserver is not starting
Picture of my screen attached. Also I was assuming you knew but I purchased this hestiapi from your tindie store.
That’s the right chip on the screen.
Based on your debugging, this sounds like a software issue. I can try to reproduce this problem on the v1.2 image. It will take me a bit because it’s a busy time of the year and I only keep the v1.4 images on hand. The 1.2 version is old and I didn’t make that image so I am not intimately familiar with it.
I test every unit that I assemble with the case fully assembled to avoid these problems. I can’t test the kits that I sell, naturally, but I have used the same make and model parts in units that I assembled, so I am confident the hardware is all compatible.
I go through all this testing because electronics components frequently silently swap out parts with (supposedly) compatible ones. Many times they are compatible; but sometimes not. 
I was able to reproduce and then resolve the issue you faced with the v1.4 image. Use a faster SD card. I switched from a generic to a name brand and the same image went from never getting past the loading screen to booting without any problem with the exact same software image.
So I should have listened to @ed1023 when they posted about using a fast SD card. I had been using SD cards that I had lying around up until recently and apparently they were all fast ones.
I tried to save money with the new batch of SD cards that I ordered so I can try to get the price of the assembled units down. Apparently that was not a good plan because now I have a bunch of SD cards that can not be used in the HestiaPi.
If you bought the SD card from me, reach out to me on Tindie’s website and I can can give you a partial refund for the SD card.
Where is the event code for oneUI touchscreen events?
The UI is just a browser. I’m not sure if you mean javascript events, X11 events, window manager events, or some other type of events that might occur for each tap on the screen.
The answer would likely be the LCD-show repo, which provides the driver for the screen, but I’m not sure what you are trying to do, so the code you are looking for could be in one of those other places.
Yes, I was curious about the event handlers of the oneui page loaded in the browser.
Which brand and type? The one that came with the purchase is a SanDisk Ultra Class 10, 16GB.
I was able to reproduce the issue with a Kexin brand SD card without any indication of the speed.
When I switched to a Kingston rated at U3 (30MB/sec), the problem went away.
Can you reflash the v1.4 image onto the Kingston SD card and see if that fixes the issue?