OBSOLETE - See v10.2 instead.
[Download Link REMOVED]
Google Drive 1.6GB
Filename: hestia-pi-touch-v10.1.zip
MD5 Hash: 7cb36f79316e5e1181bd9cd2b1b47007
Version 10.1 Details:
1 Like
As @Greylinux first noticed, this image produces a high CPU usage (~2.0 reported from top)! Something is obviously not optimised in Stretch. Has anyone come up already with the optimisation needed?
More info on this thread…
not sure if this can help
top - 18:20:18 up 6 days, 4:36, 2 users, load average: 2.87, 2.66, 2.42
Tasks: 111 total, 1 running, 80 sleeping, 0 stopped, 2 zombie
%Cpu(s): 10.7 us, 10.7 sy, 0.0 ni, 77.7 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
KiB Mem : 443864 total, 35108 free, 273556 used, 135200 buff/cache
KiB Swap: 102396 total, 4 free, 102392 used. 121364 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1171 pi 20 0 380160 50704 20680 S 6.1 11.4 601:17.56 chromium-browse
303 root 20 0 303968 163524 4972 S 2.9 36.8 455:49.06 java
21136 root 20 0 0 0 0 I 2.6 0.0 0:10.63 kworker/0:0
955 pi 20 0 557928 41908 23484 S 2.3 9.4 218:32.86 chromium-browse
22785 pi 20 0 8236 3248 2672 R 1.9 0.7 0:01.86 top
522 root 20 0 36576 1556 1508 S 1.0 0.4 93:01.66 fbcp
870 pi 20 0 137020 32004 5560 S 0.6 7.2 56:18.53 lxpanel
37 root 1 -19 0 0 0 S 0.3 0.0 23:12.70 vchiq-slot/0
42 root -51 0 0 0 0 S 0.3 0.0 2:14.15 irq/86-mmc1
22732 root 20 0 0 0 0 I 0.3 0.0 0:00.31 kworker/u2:1
22754 pi 20 0 11648 3772 3008 S 0.3 0.8 0:00.34 sshd
1 root 20 0 27000 4256 3544 S 0.0 1.0 0:17.88 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.43 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 16:08.66 ksoftirqd/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
9 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
11 root 20 0 0 0 0 S 0.0 0.0 0:00.91 khungtaskd
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
13 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
15 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 crypto
16 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
17 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 watchdogd
18 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rpciod
19 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 xprtiod
22 root 20 0 0 0 0 S 0.0 0.0 0:08.63 kswapd0
23 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 nfsiod
33 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kthrotld
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 iscsi_eh
35 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 dwc_otg
36 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 DWC Notificatio
38 root 1 -19 0 0 0 S 0.0 0.0 0:05.17 vchiq-recy/0
39 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 vchiq-sync/0
40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 vchiq-keep/0
41 root 10 -10 0 0 0 S 0.0 0.0 0:00.00 SMIO
45 root 20 0 0 0 0 S 0.0 0.0 2:19.66 mmcqd/0
46 root 20 0 0 0 0 S 0.0 0.0 0:46.66 jbd2/mmcblk0p2-
47 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ext4-rsv-conver
48 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ipv6_addrconf
73 root 20 0 9616 3780 3616 S 0.0 0.9 0:06.66 systemd-journal
100 root 20 0 14540 1856 1716 S 0.0 0.4 0:02.64 systemd-udevd
131 root 20 0 0 0 0 S 0.0 0.0 12:53.53 spi0
147 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 cfg80211
151 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 brcmf_wq/mmc1:0
152 root 20 0 0 0 0 S 0.0 0.0 1:36.91 brcmf_wdog/mmc1
183 systemd+ 20 0 17264 2304 2228 S 0.0 0.5 0:02.83 systemd-timesyn
209 root 20 0 5288 2004 1948 S 0.0 0.5 0:02.34 cron
211 root 20 0 22848 1924 1612 S 0.0 0.4 0:00.89 rsyslogd
216 message+ 20 0 6608 2584 2260 S 0.0 0.6 0:01.76 dbus-daemon
239 nobody 20 0 5288 1748 1732 S 0.0 0.4 0:10.01 thd
241 avahi 20 0 6484 2640 2408 S 0.0 0.6 0:17.36 avahi-daemon
251 avahi 20 0 6388 968 908 S 0.0 0.2 0:00.00 avahi-daemonI managed to get and Openhabian image to run as pi (as it runs OH as “openhabian” user by default) with the UI showing all the values I wanted but all the time I was working on my Pi 3B+ and once I was happy I moved to my zero and noticed high load average again with top (higher than 2).
So I started reducing load to see what breaks it…
I killed chromium-browser. Waited 5 minutes. The load average was marginally lower but still higher than 2! I disabled the boot to desktop option so now the LCD boots to console with autologin as pi and again the change was very small.
Finally I stopped openhab2 service and this is where I am:
top - 10:22:00 up 33 min, 2 users, load average: 1.90, 1.90, 1.87
Tasks: 80 total, 1 running, 51 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 6.2 sy, 0.0 ni, 93.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 443860 total, 231388 free, 34076 used, 178396 buff/cache
KiB Swap: 102396 total, 102396 free, 0 used. 356980 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1559 root 20 0 0 0 0 I 2.9 0.0 0:02.85 kworker/0:1
1507 pi 20 0 8104 3128 2656 R 1.6 0.7 0:18.08 top
...
Any hints? I’ll try and start again from a fresh openhabian image and work on a zero (it will take ages…).
Does anyone think by installing components on a higher specs board (Pi 3B+) actually installs different configurations as if it would with the Zero? Not sure if this is true but if it is I would expect it to adjust on each boot according to the board it is loading on.
So my suspicion was right… I did everything but the LCD Touch driver and the load was kept <0.3.
Once I install the driver though:
wget http://www.hestiapi.com/download/LCD-show-180331.tar.gz;
tar xvf LCD-show-180331.tar.gz;
cd LCD-show/;
sudo ./LCD35-show;
the problems started.
I found out there is a newer driver. Looking into it…
I don’t know if this is of interest . Tested on raspberry pi zero with Rasbian stretch.
Is the CPU load “normal” after you installed it. I just got a new driver from Waveshare today to test later on.
Sorry I rushed that post, I’m currently away so I myself haven’t tested this but the user on that post suggested that they had tested it on a pi zero I found the thread whilst browsing a solution.
I’ll test it first then 
Dude! Its working! I get around 0.5 CPU load reported on top! The UI feels also a bit more responsive too! Need to do my proper timing checks.
One bad thing though (which is also important for me) is that the driver is a binary executable with no code published for me to compile. I run just in my test unit but I’m not feeling sure I want that in the official release. Will get back to that later.
Will check the other driver I received now and report here…
This is great news hopefully though the waveshare drivers works and we won’t need the binary executable.
It worked too!
Been struggling for 10 days with no solution. Got 2 on the same day! 
Waveshare driver works fine. It just needs a little calibration in terms or rotation of touch events. I can take it from here and will post update instructions and (in a few days) a new image uploaded!
Thanks Tim!!!
Brilliant !!!
All the hard work was you . 
I look forward to the update instructions
Which distro are you on? I’m finding it hard to “fix” 10.1 so I’m thinking of “forking” my installation steps right before the LCD drivers. If you can get there, then what else needs to be done is via SSH:
wget http://www.hestiapi.com/download/LCD-show-170703.tar.gz;
tar xvf LCD-show-170703.tar.gz
cd LCD-show/;
sudo ./LCD35-show;
it will automatically reboot at the end. When it wakes up you will notice the touch events register in flipped X-Y axis manner. To fix that, SSH into it and:
sudo nano /home/pi/scripts/openhabloader.sh
and add at line 20 (above the cd command)
xinput --set-prop 'ADS7846 Touchscreen' 'Coordinate Transformation Matrix' 0 -1 1 1 0 0 0 0 1
then mkdir/touch missing directories/file like below
$ cat /etc/X11/xorg.conf.d/99-calibration.conf
Section "InputClass"
Identifier "calibration"
MatchProduct "ADS7846 Touchscreen"
Option "MinX" "3413"
Option "MaxX" "62121"
Option "MinY" "60949"
Option "MaxY" "4244"
Option "SwapXY" "1"
Option "InvertX" "1"
Option "InvertY" "1"
EndSection
If you want pixel-perfect touch precision, after killing chromium,
sudo pgrep chromium | xargs kill -9
install the provided calibration utility (maybe the distro’s provided package works too but not sure)
sudo dpkg -i ./LCD-show/xinput-calibrator_0.7.5-1_armhf.deb
and select on the LCD [Start Menu] > Preferences > Calibrate Touchscreen
If it is really hard to find your way around it I think you can call the executable on LCD from SSH like this:
sudo DISPLAY=:0.0 xinput_calibrator
Copy your LCD’s results in that previous file (/etc/X11/xorg.conf.d/99-calibration.conf)
Reboot, give it maybe 15 minutes and check again with top to see if CPU is normal (around maybe <0.4)
Unfortunately I couldn’t get this to work i installed the driver and when it reboots it show the Boot text then fails to load the desktop or the habpanel it just displays the boot text and occasionally flashes/glitches to the display of the hestiapi countdown.
I had to reinstall the previous driver to restart back to the Habpanel .
I’m using the 10.1 image so I’m unsure what has happened.
the web site shows that the latest driver is 180817 is this not the one they suplied ?
I might have to wait for the image .
Yes, that was the behaviour I got by installing the second driver over the first.
To install the first one run:
wget http://www.hestiapi.com/LCD-show.tar.gz;
tar xvf LCD-show.tar.gz;
cd LCD-show/;
sudo ./LCD35-show;
Maybe checking the install script you can spot what needs to be undone before running the second driver. And yes… It is an older version they sent that actually works for Stretch 
Mmmm! Interesting I’ve compared both scripts and I can’t seem to find what’s either being left behind or missing . It appears that both scripts change the same files so I can’t work it out .
I think as I say it will be easier to wait for the image rather than install manually and then install the drivers .