Automated build process (buster)

hestia_hacker · January 27, 2023, 8:28pm

I’m still working on the Buster build to continue pushing toward the ability to get OpenHab 3.
The current issue is that I’m getting a ClassNotFound exception when trying to run a script. Help wanted.

2023-01-27 15:05:36.526 [WARN ] [e.automation.internal.RuleEngineImpl] - Fail to execute action: 4
java.lang.RuntimeException: java.lang.ClassNotFoundException: org.eclipse.smarthome.model.script.actions.ScriptExecution cannot be found by com.eclipsesource.jaxrs.publisher_5.3.1.201602281253

/var/lib/openhab2/config/org/openhab/addons.config has exec in the list of bindings

The Exec Binding shows up as installed in the web UI (Paper UI → Add-ons → Bindings)

Uninstalling Exec Binding results in it being removed from addons.config. Reinstalling the binding
puts it back, but it still throws ClassNotFound exceptions when trying to run a rule.

So I’m not sure where to go from here. It’s acting as if the binding isn’t installed, but I’m not
sure how to resolve this.

The odd thing is that in stretch, I see the ExecBinding listed twice, once with version 2.5.12 and
once with 2.5.3. OpenHab 2.5.12 is what is installed, and clicking uninstall on the 2.5.12 line
causes the spinning circle to appear on the 2.5.3 line. Hopefully this will make more sense with some pictures.

Here’s Stretch:

And Buster:

I’ll keep poking around and trying to find the differences between the working and non-working images, but it’s getting to be a real slog since I don’t know things like where the .class files should be installed when the Exec binding is installed, where OpenHab is looking for said class files, and so forth. I can take this over to the OpenHab forums, but I have a feeling they’re going to suggest using OH3, which is great, but also more work than I am willing to take on right now.

HestiaPi · January 30, 2023, 8:03am

@rlkoshak do you have any suggestion on where to look?

rlkoshak · January 30, 2023, 9:25pm

Unfortunately it’s been a couple of years now since I’ve done anything of note with OH 2.x.

I’ve not seen this sort of error before and the first thing I’d double check is that you have the right Java installed (I think Zulu JDK 8 was recommended for 2.x).

It’s weird that the error goes away with removal of the Exec binding because, despite the name of the missing class, ScriptExecution is actually where the Action createTimer is (and `callScript but the HestiaPi code doesn’t use that) and has nothing to do with the Exec binding. It’s part of the core platform. Uninstalling the Exec binding shouldn’t change this one way or the other.

I’m not sure what’s going on there either but I think it’s a separate problem. OH 2.5 was basically frozen for about a year while OH 3 was prepared. There were no changes in OH core between 2.5.1 and 2.5.12. The only changes were updates to the add-ons and core was modified so that any 2.5.x add-on can run on any 2.5.x core.

Why it’s showing a 2.5.12 and a 2.5.3 version of the add-on is weird and not something I’ve seen before also.

The Buster screen shot is what I would expect to see.

The best first place to look is the Karaf Console. The Console | openHAB

There are a number of commands there that let you list the bundles and see the status of various parts of the OH subsystem.

But ultimately there really isn’t anything you can do to fix this sort of error by rooting around in the installed class files. Anything you do would be undone immediately upon a clearing of the cache.

And now that I mention it, that should probably be the first thing to do.

`sudo openhab-cli clear-cache`

should work (it could be “clearCache”, I’m going from memory). If not see Clear the Cache - Runtime - openHAB Community for manual steps.

If this remains a big problem, it might be worth looking to jump to OH 3.4.1 (it might be less work overall if the above and a fresh install don’t work). Note that the next version of OH which will be released in June is OH 4.

The add-on jar files/kar files end up in /var/lib/openhab/cache if you ever do want to dig down into where the actual add-ons are installed to. Clearing the cache will delete everything there forcing OH to download and install them again. That should fix the “two versions” problem.

I’m not sure what could be wrong for the first error though. That class has nothing to do with the Exec binding. It doesn’t even provide executeCommandLine.

hestia_hacker · January 31, 2023, 7:26pm

Thanks for all the pointers. It’s very helpful to know that the error message is not related to Exec.

I think you might be right about it making sense to update both the operating system and OpenHAB at the same time. I’m going to take a look at that.

I plan on using this guide to get me started with updating the scripts to work in OpenHAB 3. If there is a better guide, feel free to point me to it.

rlkoshak · January 31, 2023, 8:03pm

That’s a good start. But there will be a few things not covered by that tutorial which will need to be handled.

the call to executeCommandLine changed in OH 3 and we use that in a few places.
the GPIO binding we’re using is the old 1.x version (there wasn’t a 2.x version at the time the config was rewritten) and the new 2.x binding works fundamentally differently from the 1.x version (we’ll need to create Things and link Channels to Items instead of doing all the config on the Items).

I think those are the only two things with the configs that absolutely have to change. As part of 2 we should migrate the GPIO Items to become managed just like the rest of the Items.

There might be one or two breaking changes in the add-ons to deal with (it’s more than two years now since I upgraded so my memory is hazy) but I don’t think so.

Long term the things that need to be done include:

rewrite the rules using the JS Scripting add-on (the current rules are written in ECMAScript 5.1, JS Scripting provides ECMAScript 11) or rewrite the rules using Blockly so it’s easier for end users to read and understand the code, though even moving to the JS Scripting add-on will improve that.—
Update Items and rules to take advantage of Units of Measurement so we don’t have to maintain two different copies of everything, one for degrees C and the other for degrees F.
Consider replacing Sitemaps with MainUI Pages. The nice part in doing that is that charting is built right in and we can’t get rid of MainUI anyway so may as well use it. If we do, we should consider adapting the Semantic Model for Items. If not, we should consider recreating the Sitemap to be managed so that all the configs are the same.

But none of the above are required to move to OH 3. They are just things that HestiaPi would benefit from once we do move to OH 3.

hestia_hacker · February 5, 2023, 12:14am

Thanks for all the pointers on getting our configs updated to be OH3 compatible. I’m still going to work on that, but I’ll save that for another thread.

I managed to get everything working on buster using real hardware (built on a pi3, tested on a HestiaPi (the pi Zero)). I’m working on making sure it’s repeatable so I can have a script to build an image.

The thing that helped get me over the hump was to use ansible and to also run tests with building everything on both real hardware.

I ran into troubhle with kweb on Debian 11 (bullseye), in that libwebkitgtk-3 doesn’t exist there and kweb isn’t compatible with libwebkit2gtk-4, but I’ll save that for another thread as well.

Hopefully in a few days, I’ll have another post in this thread with a buster image to test.

hestia_hacker · February 23, 2023, 4:33am

I have some very good news: I got a hestiapi build working on buster (32-bit), with OpenHAB 2. I switched from shell scripts to ansible and that seems to have fixed whatever was causing that weird class not found error.

The bad news is I think I am about to get kicked off of the GitLab instance that was hosting the images (because they are not set up to handle several gigabytes of artifacts).

I’ll sort that out soon enough, but mainly I just wanted to share the good news.

HestiaPi · February 28, 2023, 5:35am

Have you got the chance to run it on hardware too even without touchscreen drivers to get an idea on the performance?

hestia_hacker · February 28, 2023, 5:55am

Yeah. The setup takes a while but the normal operation is plenty responsive. I don’t have the exact amount of time for each step, but I can time it when I create the next image.

No issues with touch screen registration either. Hopefully others will have the same results on that front.

hestia_hacker · February 28, 2023, 9:32pm

The punchline is that the new image is about 1 minute slower for the one-time setup process (as compared to the official 1.2-dev image), but the boot time after setup is about 30 seconds faster with the official image. I’d call this a win.

The latest image can be downloaded from the CI page of my automation project’s new home.

@Derekjon94 and others: If you’re willing to help test, that link above is the buster image to test. It should be functionally equivalent to the official 1.2-dev image, but with a newer base OS.

Here are the timing numbers in case anyone wants to do a more detailed comparison when trying to reproduce my test results.

Buster image:

7:08 - Asks me to connect to the AP
7:08 - Allows me to enter my creds
7:56 - Done entering creds
8:41 - AP screen disappears
13:00 - Splash screen appears
22:04 - GUI appears
22:33 - GUI is usable

Post-setup boot time: 9:33


Official 1.2-dev image:
5:00 - Asks me to connect to the AP (screen then disappeared and took me to the thermostat's "Off" screen before I could enter creds)
6:34 - Allows me to enter my creds
7:07 - Done entering creds
7:47 - AP screen disappears
11:16 - Splash screen appears
19:35 - GUI appears
21:01 - GUI is usable

Post-setup boot time: 9:59

To be clear: I consider the post-setup boot time to be from the moment it is connected to power to when the unit is functional as a thermostat (able to change temperature settings, turn heat/cooling on and off, etc.).

It does not mean that the heat has actually turned on if it was supposed to, nor does it mean that the info page is fully filled out.

HestiaPi · March 6, 2023, 5:09am

@hestia_hacker wow… it didn’t take you that long after all… impressive work!
Guys can I ask anyone willing to help to flash that image above on a second SD card and try it out temporarily for a few hours trying out the various commands and features and report back here any findings? When you are done, put back the original SD you had till we release an official release.

HestiaPi · March 8, 2023, 8:05am

really great work! Congrats… everything seem fine. Below are some passed test and 3 failed which are easy.
FAIL:

Touchscreen calibration - screen is pretty much useless as touches are registered in wrong positions
EU mode - I remember there were some minors issues even with previous rules with hot water. Will check further and get back with the fix so that you could incorporate it
Boost rules do not start counting down (even with rule Initialization called as this had solved this in previous build after a power failure)

PASS:
Using BasicUI only from a desktop browser.
US MODE:

Trigger heating and cooling with:
- Auto
- Setpoint change up and down
Trigger secondary heating with same methods as above + adjusting the threshold
Manual trigger fan
All UI elements seems to show the correct information and respond as they should

Regarding the timings you mentioned, I didn’t keep a stopwatch and they seem right but the most important result is that it is equally responsive as before which I thought we would never achieve this although there is high CPU usage of ~1.80 even after 1h!

As most of the above are OH related, the actual upgrade work is pretty much done… Do you think upgrading OpenHAB is now closer?

Edit:
Actions I took for Fail #2 are below:
PaperUI > Rules > “Hot Water Control” Change action to:

var OPENHAB_CONF = Java.type('java.lang.System').getenv('OPENHAB_CONF');
load(OPENHAB_CONF + '/automation/lib/hestia/utils.js');

logInfo("hotwater", "Turning " + command + " the hot water: mode = " +
        items["HotWaterMode"]);
if(command == ON) commandIfDifferent("MainSwitch", ON);
commandIfDifferent("HotWaterPin", command);
events.sendCommand("HotWaterMode", items["HotWaterMode"]); // update the LCD

and press the “Tick” icon to save.

hestia_hacker · March 9, 2023, 6:05pm

Good to hear that many things are working as expected.

Fail 1: I’ve tested with all the screens I have and was unable reproduce your test result. The screens I purchased are the Kuman SC06 and the PCB has “XPT2046 Touch Controller” printed on it. Upon closer inspection, one of the boards has a different markings on the central IC. It looks like it’s a compatible chip, likely the one that I received from the initial crowd funding campaign. The oddball is “2046 H1526” and the others all have a chip that reads “XPT2046 1914”. I attached pictures below in case that is helpful if figuring out what the difference is between our test setups. Hopefully this is a hardware difference, because if your LCD controlled matches either of these, then I’m at a loss for what’s causing the difference in test results, or how we should proceed.

Fail 2: Can you add this fix to the automation_rules.json file in the hestia-touch-openhab repo (or whatever other file in the repo might be appropriate if that’s not the right one)? If so I can re-build the image so we can verify the automated process gets the changes and that the changes fixes the issue.

Fail 3: I was not able to reproduce this test result. Below is what my screen looked like a couple minutes after I pressed boost. Note that the countdown has dropped from 10 minutes to 8 minutes

OpenHAB 3 status

As for OpenHAB 3 update, it sounds like there’s not a whole lot of change to do, but to be honest, I need a break from the software side of the HestiaPi for a few weeks. I’ve been fighting to get an OS with security updates for many months and it’s been wearing. Plus I still don’t really understand the concepts behind Things, Items, Channels, Bindings and Rules, let alone what has been set up in the HestiaPi and how it all ties together. So even though it’s probably not that many changes to the OpenHAB configs, I expect that it will take me a fair amount of effort.

When I do come back to the OH3 update, I’m going to study this page along with the OpenHAB docs and the configs in the UI on my HestiaPi. I’ll probably also create additional HestiaPi documentation because that’s helps me understand things better.

Photos

HestiaPi · March 10, 2023, 9:23am

Made below commit on ONE branch:

Regarding Fail #1, I followed these steps, without installing the driver of course, simply downloaded, extracted and installed the xinput-calibrator deb file and run the calibration tool producing these:

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "ADS7846 Touchscreen"
        Option  "Calibration"   "254 3910 3716 1476"
        Option  "SwapAxes"      "1"
        Option "InvertX" "1"
        Option "InvertY" "1"
EndSection

and copied to /etc/X11/xorg.conf.d/99-calibration.conf (replacing old entry) and it seems to work fine now. I doubt this will work on both you and me. Not sure what to make of it if you tested on the crowdfunding campaign LCD which is what I (only) have here too.

jrtaylor71 · March 10, 2023, 7:31pm

Bootup not getting completed. Looks like rc.local is not exiting. Also do you need to have avhi, bluetooth, ModemManager and alsa running?

pi@raspberrypi:~ $ sudo systemd-analyze blame
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
pi@raspberrypi:~ $ sudo systemctl list-jobs
JOB UNIT                                 TYPE  STATE  
103 rc-local.service                     start running
 84 serial-getty@ttyS0.service           start waiting
  1 graphical.target                     start waiting
 67 systemd-update-utmp-runlevel.service start waiting
 83 getty.target                         start waiting
 90 getty@tty1.service                   start waiting
  2 multi-user.target                    start waiting

7 jobs listed.

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Feb24 ?        00:01:17 /sbin/init
root         2     0  0 Feb24 ?        00:00:00 [kthreadd]
root         6     2  0 Feb24 ?        00:00:00 [mm_percpu_wq]
root         7     2  0 Feb24 ?        00:00:00 [rcu_tasks_rude_]
root         8     2  0 Feb24 ?        00:00:00 [rcu_tasks_trace]
root         9     2  0 Feb24 ?        00:00:45 [ksoftirqd/0]
root        10     2  0 Feb24 ?        00:00:00 [kdevtmpfs]
root        11     2  0 Feb24 ?        00:00:00 [netns]
root        13     2  0 Feb24 ?        00:00:00 [kauditd]
root        15     2  0 Feb24 ?        00:00:00 [khungtaskd]
root        16     2  0 Feb24 ?        00:00:00 [oom_reaper]
root        17     2  0 Feb24 ?        00:00:00 [writeback]
root        18     2  0 Feb24 ?        00:00:07 [kcompactd0]
root        33     2  0 Feb24 ?        00:00:00 [kblockd]
root        34     2  0 Feb24 ?        00:00:00 [blkcg_punt_bio]
root        35     2  0 Feb24 ?        00:00:00 [watchdogd]
root        36     2  0 Feb24 ?        00:00:00 [rpciod]
root        37     2  0 Feb24 ?        00:00:00 [kworker/u3:0-hci0]
root        38     2  0 Feb24 ?        00:00:00 [xprtiod]
root        39     2  0 Feb24 ?        00:00:03 [kswapd0]
root        40     2  0 Feb24 ?        00:00:00 [nfsiod]
root        41     2  0 Feb24 ?        00:00:00 [iscsi_eh]
root        42     2  0 Feb24 ?        00:00:00 [iscsi_destroy]
root        43     2  0 Feb24 ?        00:00:00 [dwc_otg]
root        44     2  0 Feb24 ?        00:00:00 [DWC Notificatio]
root        45     2  0 Feb24 ?        00:03:19 [vchiq-slot/0]
root        46     2  0 Feb24 ?        00:00:00 [vchiq-recy/0]
root        47     2  0 Feb24 ?        00:00:00 [vchiq-sync/0]
root        48     2  0 Feb24 ?        00:00:00 [zswap-shrink]
root        55     2  0 Feb24 ?        00:00:00 [mmc_complete]
root        57     2  0 Feb24 ?        00:00:02 [jbd2/mmcblk0p2-]
root        58     2  0 Feb24 ?        00:00:00 [ext4-rsv-conver]
root        60     2  0 Feb24 ?        00:00:00 [ipv6_addrconf]
root        89     1  0 Feb24 ?        00:00:02 /lib/systemd/systemd-journald
root       116     1  0 Feb24 ?        00:00:01 /lib/systemd/systemd-udevd
root       129     2  0 Feb24 ?        00:00:00 [vchiq-keep/0]
root       130     2  0 Feb24 ?        00:00:00 [SMIO]
root       138     2  0 Feb24 ?        00:02:09 [spi0]
root       143     2  0 Feb24 ?        00:00:00 [mmal-vchiq]
root       144     2  0 Feb24 ?        00:00:00 [mmal-vchiq]
root       147     2  0 Feb24 ?        00:00:00 [mmal-vchiq]
root       148     2  0 Feb24 ?        00:00:00 [mmal-vchiq]
root       149     2  0 Feb24 ?        00:00:00 [mmal-vchiq]
root       176     2  0 Feb24 ?        00:00:00 [cfg80211]
root       177     2  0 Feb24 ?        00:00:00 [brcmf_wq/mmc1:0]
root       178     2  0 Feb24 ?        00:00:19 [brcmf_wdog/mmc1]
systemd+   236     1  0 Feb24 ?        00:01:19 /lib/systemd/systemd-timesyncd
root       275     2  0 Feb24 ?        00:00:00 [irq/160-ads7846]
root       280     1  0 Feb24 ?        00:00:00 /usr/sbin/rsyslogd -n -iNONE
avahi      281     1  0 Feb24 ?        00:00:07 avahi-daemon: running [raspberrypi.local]
message+   282     1  0 Feb24 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root       283     1  0 Feb24 ?        00:00:00 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon
root       284     1  0 Feb24 ?        00:00:00 /usr/sbin/cron -f
root       285     1  0 Feb24 ?        00:00:03 /usr/lib/accountsservice/accounts-daemon
avahi      289   281  0 Feb24 ?        00:00:00 avahi-daemon: chroot helper
root       290     1  0 Feb24 ?        00:00:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
nobody     292     1  0 Feb24 ?        00:00:01 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event*
root       298     1  0 Feb24 ?        00:00:00 /lib/systemd/systemd-logind
root       304     1  0 Feb24 ?        00:00:00 /usr/sbin/ModemManager --filter-policy=strict
root       336     1  0 Feb24 ?        00:00:00 /usr/sbin/rngd -r /dev/hwrng
daemon     365     1  0 Feb24 ?        00:00:00 /usr/sbin/atd -f
root       398     1  0 Feb24 ?        00:00:00 /usr/lib/policykit-1/polkitd --no-debug
root       407     1  0 Feb24 ?        00:00:01 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
root       417     2  0 Feb24 ?        00:00:00 [kworker/u3:1-hci0]
root       418     1  0 Feb24 ?        00:00:00 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:a0:dd:fb
root       431     1  0 Feb24 ?        00:00:00 /usr/lib/bluetooth/bluetoothd
root       486     1  0 Feb24 ?        00:00:00 /sbin/dhcpcd -q -w
mosquit+   491     1  0 Feb24 ?        00:02:00 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
openhab    493     1  5 Feb24 ?        00:59:36 /usr/bin/java -Dopenhab.home=/usr/share/openhab2 -Dopenhab.conf=/etc/openhab2 -Dopenhab.runtime=/usr/share/openhab2/runtime -Dopenhab.userdata=/var/lib/ope
root       496     1  0 Feb24 ?        00:00:00 /bin/sh -e /etc/rc.local start
root       514     1  0 Feb24 ?        00:00:00 /usr/sbin/sshd -D
dnsmasq    556     1  0 Feb24 ?        00:00:29 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --tru
root       974   496  0 Feb24 ?        00:10:02 fbcp
Debian-+   986     1  0 Feb24 ?        00:00:00 /usr/sbin/exim4 -bd -q30m
pi        1075     1  0 Feb24 ?        00:00:00 /lib/systemd/systemd --user
pi        1076  1075  0 Feb24 ?        00:00:00 (sd-pam)
root      1087     1  0 Feb24 ?        00:00:00 /usr/bin/sudo /usr/bin/python3 /home/pi/scripts/raspberry-pi-turnkey/startup.py
root      1088   496  0 Feb24 ?        00:00:00 su -l pi -c sudo xinit /home/pi/scripts/kiosk-xinit.sh
root      1089  1087  0 Feb24 ?        00:00:05 /usr/bin/python3 /home/pi/scripts/raspberry-pi-turnkey/startup.py
root      1090  1088  0 Feb24 ?        00:00:00 sudo xinit /home/pi/scripts/kiosk-xinit.sh
root      1099  1090  0 Feb24 ?        00:00:00 xinit /home/pi/scripts/kiosk-xinit.sh
root      1100  1099  2 Feb24 tty2     00:24:41 /usr/lib/xorg/Xorg :0
root      1108  1099  0 Feb24 ?        00:00:00 /bin/bash /home/pi/scripts/kiosk-xinit.sh
root      1137  1108  0 Feb24 ?        00:00:00 matchbox-window-manager -use_titlebar no -use_cursor no
root      1168  1108  0 Feb24 ?        00:00:00 unclutter
root      1184  1089  0 Feb24 ?        00:00:00 [startup.sh] <defunct>
root      1213   514  0 Feb24 ?        00:00:00 sshd: pi [priv]
pi        1235  1213  0 Feb24 ?        00:00:00 sshd: pi@pts/0
pi        1236  1235  0 Feb24 pts/0    00:00:00 -bash
root      2223  1108  5 Feb24 ?        01:02:49 kweb -KJ /home/pi/scripts/oneui/index.html
root      6096     2  0 06:25 ?        00:00:01 [kworker/0:0H-mmc_complete]
root      7835     2  0 07:03 ?        00:00:02 [kworker/u2:1-events_unbound]
root     14156     2  0 09:25 ?        00:00:00 [kworker/0:2H]
root     17233     2  1 10:35 ?        00:00:29 [kworker/0:1-events_power_efficient]
root     17680     2  0 10:45 ?        00:00:00 [kworker/u2:2-brcmf_wq/mmc1:0001:1]
root     18110     2  1 10:55 ?        00:00:17 [kworker/0:2+events]
root     18573     2  0 11:05 ?        00:00:00 [kworker/0:3-events_power_efficient]
root     18844     2  0 11:11 ?        00:00:00 [kworker/0:1H-mmc_complete]
root     18854     2  0 11:11 ?        00:00:00 [kworker/u2:0-brcmf_wq/mmc1:0001:1]
root     18862     2  1 11:11 ?        00:00:02 [kworker/0:0-events]

jrtaylor71 · March 10, 2023, 9:40pm

It also looks like turnkey is not exiting either after wifi is setup and gets stuck.

su -l pi -c 'sudo xinit /home/pi/scripts/kiosk-xinit.sh'

Pushing the script to the background allows rc.local to exit normally and bootup finish.

su -l pi -c 'sudo xinit /home/pi/scripts/kiosk-xinit.sh &'

HestiaPi · March 11, 2023, 12:35pm

could it be a faulty card or an incomplete flash process? I have flashed that particular image 4 times so far and tested the out-of-box scenario and it never failed apart from the 3 fail points.

hestia_hacker · March 11, 2023, 6:20pm

@HestiaPi I’ve kicked off a new build which will pull in your git commit.

I. Can you confirm that the chip on the back of your LCD has “2046 H1526” printed on it? I’d like to see if I can find some way to reproduce the issue so we can see if there’s a way to get a unified config that works for everyone. It may be unlikely, but I’m still interested in solving it. Failing that, maybe we can make it easy to patch.

II. Can you confirm that you are not seeing the boost countdown like I’m seeing on my pi? I want to make sure I didn’t misundersand and have it be an issue where the countdown occurs but the heat doesn’t shut off after 10 minutes or something like that.

@jrtaylor71’ I am able to reproduce all of your findings. In my experience they do not interfere with the normal operation of the thermostat, but they are areas for improvement.

A. I’ve verified that running kiosk-xinit.sh in the background does not cause any problems. I’ll put this in the next round of changes.

B. I can see turnkey is still running as well. I checked and after the setup process I see that cat /home/pi/scripts/raspberry-pi-turnkey/status.json says the status is “connected”, which is what I would expect. When I traced through the code, I see that this is behaving as designed (but not as expected, IMO). If you look near the bottom of /home/pi/scripts/raspberry-pi-turnkey/startup.py, you’ll see a while True: time.sleep(60000).

My guess is that the author is concerned about startup.sh taking a long time to execute and if startup.py (which is the parent process) exits, it might kill the children. I can patch around that by having startup.sh kill startup.py.

I also see an attempt to reach out to a server run by Google, which is going to fail on any environment where the thermostat is blocked from reaching out to the internet. It’s a completely useless call, as it supposedly determines the IP address, which it then does nothing with. I’ll likely remove that as well.

C. I don’t think we need avahi-daemon, bluetooth, ModemManager, alsa-state, or alsa-restore. I will disable them in my next round of changes.

Thank you both for testing and providing the feedback! I’ll get these things fixed and post back here when I have an updated image ready for the next (and hopefully final) round of testing.

hestia_hacker · March 11, 2023, 6:52pm

Oh, since we’re updating the hestia-touch-openhab repo, I just realized I another request.

Currently I’m replacing the sleep 20 in kiosk-xinit.sh with:

if grep -q "hostapd" /home/pi/scripts/raspberry-pi-turnkey/status.json; then sleep 500; else sleep 21; fi

This is because the LCD screen flips over to the thermostat UI instead of continuing to display the page instructing the user to enter their wifi credentials. This behavior of flipping away from the “enter your creds” after 20 seconds is not new, it was also present in the 1.2-dev image.

In case you’re wondering why I’m replacing the sleep 20 with a sleep 21 for the code path of “we have wifi already set up”, it’s because I want to make sure my script is idempotent. I don’t want to make this replacement multiple times in the event my ansible playbook was run multiple times. If the change is put in the hestia-touch-openhab repo it can remain a sleep 20 and I’ll remove the patch-up process from my image building scripts.

hestia_hacker · March 17, 2023, 5:00pm

New image is available for testing. Setup and boot times are about the same as the previous image.

Changes from the last iteration:

Hot water control fix that was committed to the hestia-touch-openhab repo should be in here
Run kiosk-xinit.sh in the background so rc.local exits
Disabled unnecessary services (avahi-daemon, bluetooth, ModemManager, alsa-state, and alsa-restore)
Turnkey process no longer runs forever when wifi is already set up

Issues that I am still unable to reproduce:
A. LCD touch screen issues. All of my screens work fine. @HestiaPi’s screen does not. @jrtaylor71 Can you tell us what LCD touchscreen you are using and whether it works?
B. Boost timer. It works fine for me. @HestiaPi reports the timer doesn’t count down. @jrtaylor71 Can you test this and confirm it works or let us know is you can reproduce the issue?