Automated build process (jessie)

Customization
1

Overview

This is a continuation from a thread about doing a manual installation on an existing Raspberry Pi. I’ve created a repo that has a script to automatically take a stock raspberry pi and transform it into a HestiaPi, which can also be used to create an image that can be flashed onto an SD card for anyone who wants to build their own image.

The images are available in the build pipeline (latest build).

The focus here will be on the Jessie build in order to minimize the differences between the official 1.2-dev image and the automatically generated image. Once that works, we can move on to more recent versions, which I’m sure will have all new problems (but hey, it’s cool, that’s just how these things go).

How you can help

These are listed starting with the thing that is the easiest and ending with the thing that is most helpful.

  1. Help test. Attempt to reproduce these issues so I know it’s not a hardware issue or something I’m doing wrong. Re-test to verify fixes when they’re available. Even testing on an emulated system (see the repo for the command to emulate a raspberry pi) would be helpful, and you don’t even need any hardware for that.
  2. Let me know where I should look to find more information about the issues
  3. Figure out what needs changed to fix the issue (e.g. “put ABC in the config located at XYZ”)
  4. Send in a merge request with the fix to the automated build script

Issues

Here’s the list of known issues (I’ll note when they are able to be reproduced by anyone in the community):

  1. Turnkey (the wifi setup) does not wait several minutes to allow the user to connect, select their access point’s SSID, and enter the password. This is an error, however if you’re fast enough, it’s possible to enter it before the system becomes unavailable. After a reboot, the pi will get an IP address.
  • /etc/rc.local is the same as in the 1.2-dev image
  • The turnkey script is effectively the same as the 1.2-dev image (there’s on code block that is commented out in 1.2-dev and instead it is just not executed in this image)
  1. Touchscreen is messed up. It’s hard to determine exactly how, but clicking on the info icon in the upper right does not register.
  • I mashed on the screen with a stylus so I could see the mouse cursor and it appears the touchscreen is rotated 90 degrees from the actual screen because moving right appears to move up.
  • However it’s not as simple as just being rotated because clicking in the top center of the screen causes the info button to get clicked
  • The calibration suggestions (from this post) were present
  • The 1.2-dev image does not have a /etc/X11/xorg.conf.d/ directory
  1. The info page never shows the local IP address (or any other information for that matter)
  • This is an error, but the IP address is shows when the HestiaPi boots, so it’s not a critical issue
  1. The UI shows “Off” and there’s would be no way to turn on the heat/cooling even if the touchscreen were functioning properly
  • The temperature and humidity are both showing zero
  • /home/pi/scripts/oneui/index.html is identical to the 1.2-dev image
  • /home/pi/scripts/kiosk-xinit.sh is functionally identical to the 1.2-dev image
  • Running the commands from that file manually gets the correct value for wlanip and wlanmac
  • /home/pi/scripts/openhabloader.html does contain the IP address
  • Accessing the OpenHAB web UI (on port 8080) shows the initial setup screen
  • After manually going through the setup, the BasicUI can be selected, but it is missing all the HVAC controls. Only links to the configuration and info pages are there.

Workarounds

These are things you can do now to work around these problems.

  1. Enter the password quickly
  2. None
  3. Watch for the IP address on boot
  4. Manually navigate to HESTIAPI_IP:8080, enable javascript, and click the Standard setup button. There seem to be additional steps required, but I’m not yet sure what they are.

Solutions

These are where I believe the solutions lie. If you can help with getting us closer (like location of scripts that should block until the wifi password is entered, LCD settings, curl commands, etc.), please chime in with whatever you have.

  1. Unknown
  2. Unknown. Probably involves the calibration config file, but I don’t understand what those numbers mean or how to derive the correct settings
  3. Unknown, might get fixed when #4 is fixed?
  4. I do try to go through the OpenHAB initial setup when building the image. It’s likely that there just needs to be some additional curl commands.
2

Good day @hestia_heacker

I clicked on the latest build link (https://0xacab.org/hestia/raspberrypi-automation/-/pipelines/105973) and am getting a 404 error.

I will try to use your scripts to build the image but want to compare it against what you are producing.

Joel

4

@hestia_hacker

What screen are you using or is it all VM.
I am using this one. https://www.digikey.com/en/products/detail/seeed-technology-co-ltd/308010014/5482538 when I run 1.2-dev image (still have to build your image) I boot up the image is 180 rotated, and after running LCD35-show 180 both touch and display are correct.

Joel

5

My apologies. I had the permissions set incorrectly so only developers were able to see the CI/CD pipelines, which I didn’t notice because I was logged in so the link worked fine for me. It should be fixed now.

I have the same screen. I’ll try running commands from the LCD package manually (like rotate.sh 180) and see if that helps me. Thanks for the suggestion.

6

I built a new image on my private server (to keep the load down on our generous host: 0xacab). You should be able to download it here. Once we have this last issue sorted out, I’ll upload it to 0xacab so the image is publicly available in a more reasonable place.

Edit to add: I also created a copy of the filesystem and /boot to make it easier for people to take a look at the files in the image without having to set up any hardware nor VMs. The commands that are being run are listed here and they should match the official instructions for installation.

Issue #1 - Turnkey doesn’t wait for user

Edit: Fix is in testing now. I’m modifying kiosk-xinit.sh in my build scripts. @HestiaPi Feel free to put this change directly into GitHub - HestiaPi/hestia-touch-openhab: OpenHAB2 files for HestiaPi Touch model if you’d like.

No progress in fixing this. Help needed.

As mentioned before, this problem is a UI (and thus usability) issue. Turnkey does start and the instructions to connect to the HESTIA access point show up for a couple seconds but then the UI moves on. However, it’s still serving up that access point and you can connect to it and choose your network and supply the password as long as you already know the process. Turns out you don’t need to be fast about it either. It seems to be up for a while, but I haven’t timed it to see if or when it ceases to be available.

Issue #2 - Touchscreen errors

Fixed by calling ./rotate.sh 90; ./rotate.sh 0 after running LCD35-show. This puts the maintainer’s 99-calibration.conf file in place and updates some things in /boot. Thank you @ed1023 for the pointer.

Issue #3 - Info page not populated

Fixed. The problem was that there were missing bindings and transformations

Issue #4 - OpenHAB not working as expected

Fixed. Same problem as issue #3

7

@hestia_hacker

Thank you for your work! I am trying to get familiar with HestaPi and hope to get a working unit together from spare parts I have laying around. Right now I am using a Pi 3B and 3B+ and have tried loading various images on each with limited success. I was not able to get your image to boot on my 3B+, but it did work on my 3B with one hiccup: after connecting to it to set the wifi network and password it seemed to hang up, but after cutting and reapplying the power it worked fine. (has anyone though about prompting for the country code in the setup? I have to remember to go change UK to US in the wpa_supplicant file. :slightly_smiling_face:)

One problem that I ran into that is not specific to your image (it also happens in the official dev 1.2 image) is that the mapping of the touch on the screen seems to be flipped on the diagonal from the image (the image is oriented and displayed correctly) . For instance the information button (circled i) and the minus temperature box seem mapped ok, but I have to tap along the right edge under the information button to switch between fan, cool, and heat and I have to tap above the minus box to increase the temperature. I was wondering if this is something that has been experienced by others, or if I’m on my own here.

8

as the LCDs around the market are not that standardised, the orientation and chip options vary greatly causing the issue you face. Look in the manual instructions

as well as the suggestions above about the LCD. It really depends on the model you bought and unfortunately you would need to use trial error :slight_smile:

9

Thanks @ame, I appreciate the feedback. I just got done testing the latest image to come out of the proverbal oven and it’s working well on my Raspberry Pi Zero W. Artifacts · jessie_hestiapi (#323741) · Jobs · Hestia Hacker / Raspberrypi Automation · GitLab

I’m not sure why my image wouldn’t boot on the 3B+.

After you enter your password, it will turn off the HESTIAPI access point and it should reboot shortly thereafter. I’m running it on a Pi Zero, so it takes about 54 seconds before it reboots. I’d expect a 3B to go faster, but at least that gives you an upper bound on how long to expect before it reboots itself. At any rate, I’m glad to hear that manually power cycling it worked for you.

I’m in the US and I did not have to change anything in the wpa_supplicant file in order to connect to wifi.

The temperature should default to Fahrenheit, which I always switch to Celcuis in the web UI. I think this is pretty reasonable. Most thermostats default to either one or the other and have the user manually change it if they don’t like the default.

As @HestiaPi mentinoned, the LCD touch screens will vary based on the specific hardware being used. I am using says “XPT2046 Touch Controller” on it. This aligns with the LCD35 from the LCD-show repo. You can try running the scripts in there to set up one of the other models and see if you can get the screen working properly.

10

Thanks to @HestiaPi and @hestia_hacker,

My LCD is now reacting correctly to touch events. When I found the post Third party LCD calibration - swapped axes I realized that was exactly the problem I was having (however my 99-calibration.conf was located in /etc/X11/xorg.conf.d/, matching the Manual Installation wiki, not the path in the post).

As for it not working in my 3B+, is may be an SD compatibility issue. When I put it in the 3B+, all that happens is the power (red) LED blinks. The LED flash on twice, stays on for a moment, then goes into a loop of 4 flashes followed by 3 quick flashes and then stays on for a moment before repeating. I haven’t found a definitive meaning for this in my web searches.

Also, the country code in the wpa_supplicant file does not keep things from working. I’m just pointing out that it means that the wifi is operating under the wrong country’s regulations - though honestly I don’t know what the implications of that are.

When my system hung, it was after the reboot when it should connect to my network. Actually i can’t say if it had successfully connected to my network as it was already in my DHCP server from booting previous images. It may have connected or not, I just know that after awhile it was not present in my network (at least at the IP assigned by DHCP). With no activity and no network, I thought it safe to kill and reapply the power (it was well after a couple of minutes).

So at this point it is running on my bench hooked up to some relays but not connected to anything. I can click through the various settings and the info screen and see the relays going on and off. Though I’m getting the feeling that some aspects of the UI are not working correctly.

What I’m seeing (and my observations are not in great depth; also please let me know if I’ve gone too off topic and should start a new post), and gleaning from a brief look at the html and javascript, is that there should possibly be animated images when the HVAC is running (such as heat or fan). In my case the icons just disappear when running and come back when stopped. Also I noticed references to .vue files in the javascript but find no files with that extension on my system. I don’t think this is just a problem with the @hestia_hacker build, as I saw the same behavior with the 1.2 dev build (I could never get the 1.1 release to work because it seemed to want to load files from some dead URLs).

If someone could point me to some background to understand how the UI is implemented or what it should look and act like in operation, I would appreciate it.

11

Your last message seems like good time to split into a new thread, since it’s not about testing the automated build image for Jessie.

I can say that the files for the web interface are located here: hestia-touch-openhab/index.html at ONE · HestiaPi/hestia-touch-openhab · GitHub

It’s not formatted to be human readable and I’m not sure what was used to generate the site. That’s about the best I can do. The difficulty to modify the UI is what has stopped me from going in and trying to make changes to it.

One of the changes I’d like to make to the UI is to only display the humidity if there’s a humidity sensor and maybe show a dash when the temperature is not known, rather than saying it’s zero degrees.

12

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.