HestiaPi ONE - Detailed BOM

I would love to help with this, or am willing to send some high quality photos once I get it right. :stuck_out_tongue:
As you can see from my picture here, even with that header, the pins have lots of space.
If its wiring the furnace up that becomes a problem, I think my (accidentally wrong) power supply may help. Hahaha sooo many adventures.

2 Likes

Sorry, I was away on vacation.

I think your method of attaching the pi will be fine, as long as you have stand offs or spacers between the mounting holes and the pcb so that when you put the screws into the back plate to mount it you don’t put stress on the Pi’s board.

The relays are the real clearance nightmare. :wink: Which is why the display spacing has to be just right.

Always happy to have more contributors to the docs. I haven’t built my own HestiaPi until now, so the documentation in the manual is just what was copied from the wiki. I have been taking fairly detailed pictures as I go and plan on updating the manual as soon as I have a fully functional unit. That, in combination with photos others have taken, should make for a pretty sweet guide!

The manual also seems like it should contain the BOM as well. Again, this was an oversight on my part on account of having never personally built one and that info was not on the wiki, but rather on the website. We are building up a pretty good list here in this thread, so I plan on using that as a starting point.

As for an update on my build, all the hardware is together and short of needing to reflow any bad joints, it should be done by the end of the day.

1 Like

When I update the manual, I will also be adding troubleshooting information. For example, if the SD card is not properly flashed, you will get a blank screen. If your reset button doesn’t work, check it with a meter and if it doesn’t work, reflow the switch; if it does work, trace back until you find the solder joint that is faulty. (Can you guess what problems I’ve personally run into so far?)

That brings me to my next point, I went through the initial setup, and got it connected to my wifi. Now I am getting booted up, but it is not fully operational. If just says “Off” and clicking the “Off” button has no effect. Clicking the info button in the top right works, so I know it is not a touchscreen issue. The info page is empty though…

I’ve waited over an hour hoping that maybe it was just being slow and would magically start working. It did not. Any ideas on what this might be? I tried rebooting, just in case that’d help, but no dice. Any ideas on easy ways to troubleshoot this? I can try port scanning my network to find it and SSHing in, but if it really doesn’t have an IP address, that’s obviously not going to work. If it is getting an address, then I feel like this is a bug that it is not showing up on the info page.

I assume you connected initially to the WiFi network HESTIAPI and entered your home’s WiFi credentials which would trigger a reboot, right? Some times we have noticed that after the reboot if your try to access the webpage before the LCD is fully loaded, it can cause some issues and block the proper initialisation of the OH setup. This is only for the first boot. Try reflashing the SD to be sure nothing wrong is left behind.

1 Like

A post was split to a new topic: Network requirements

That is extremely good information to have on the first run. :stuck_out_tongue: HAHAHHA I NEVER would have thought of that, I would have edited the config. :slight_smile:

Update: I reflashed the SD card and the results were the same. The IP address does appear earlier in the boot process and I am able to log in via SSH, but I am not sure where to look next.

Is there a script that I can run which should update the info screen? Logs that should show things booting? Any scripts I can run to test out the hardware?

I’d like to confirm all the hardware (specifically the relays) is working so we can wrap up the BOM and close out this thread and I can take software support to a new thread.

The scripts that I have run manually have worked fine. It just seems like it gets stuck and the interface for heating/cooling/fan never come up. Load average is under 2, so I’m not sure what the deal is.

For kicks, I tried the 1.2 dev image and I found that pulled up the UI. It is an unreasonable hour right now, so I’ll take it down to the bench and test out the relays tomorrow… er today?.. After I sleep! That’s it.

Please go to 1.2 dev. It was called dev as we released it without all the testing we usually do but it has been proven to be better and much faster.
Regarding the relay testing, in the standard PCB setup, after removing from mains and the case, I would check for continuity the lines of the relays that reach the Pi from the top of the Pi (touch the tip of the male pin header) till the bottom of the PCB or even better the first solder point.
If all looks good, then google some python command to simply turn that GPIO HIGH or LOW and check. If you have solid state relays, thin black ones, rather than blue block-type ones, you won’t hear a thing and testing with a multimeter their contacts will also confuse you as they respond to AC currents only.

OK, I have results and they are mixed. After yesting continuity from the pi to the relays, i decided to use the testing procedure of: hook it up to my live heating and cooling systems and see what happens.

We’ll start with the bad, as usual. Using the LCD UI to attempt to turn on the cooling, fan and heat resulted in nothing happening. Same for using the web interface. The BME sensor reads 0% humidity in the UI and when running ./getBMEhumi.sh, which is not correct. That’s all the bad news, the rest is positive.

The good news is that when I toggle the GPIO pins using bash, the system does turn on.

This means a number of things:

  • The relays in this thread are acceptable
  • My soldering skills seem to be sufficient
  • The issue is in software, which I feel is a good thing
  • It should be possible to debug by looking at that value of GPIO pin

I used Controlling Raspberry Pi GPIO Pins from Bash Scripts: Traffic Lights | simonprickett.dev as a guide, but the punchline is this:

# See if pin 18 is on or not
cat /sys/class/gpio/gpio18/value
# Turn GPIO pin 18 on
echo 1 > /sys/class/gpio/gpio18/value
# Turn GPIO pin 18 off
echo 0 > /sys/class/gpio/gpio18/value
  • Pin 18 is fan
  • Pin 23 is cooling
  • Pin 12 is heating

Side note: As a warning, some cooling units do not automatically turn on the fan when the cooling is turned on (some do), so make sure you flip that off when you’re done testing. Otherwise you risk not hearing the compressor running, leaving it go constantly and burning it out.

While the relays were the most important thing to test, there is also the reset button (works fine), and the BME sensor: temperature and pressure work, but the humidity does not (always reads zero). I don’t really need to know the humidity, but it’d be nice, and it really should work.

I am also happy to report that a 5V 500mA power supply is enough current to power the pi, screen and relays.

Next steps for me:

  1. Disconnect it from my HVAC system and connect the old thermostat so I can work comfortably
  2. Try to debug the software to see why the GPIO pins aren’t getting flipped
  3. Fix the problem
  4. Submit a pull request

For the others in this thread that are following along, please forge ahead and report your results back here. It is important that others can reproduce these results. If you get different results, it may help determine where the issues lie.

In conclusion, I think the BOM is solid and it will just be a matter of sorting out some software issues.

What do you get for the temperature from the command line (leave LCD and web GUI out for easier elimination for now)? If you get 0 or not an actual value try bellow command shown with the expected output (76)

pi@raspberrypi:~/scripts $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- 76 --

If you are getting a different value than 76, that’s the address of the i2c bus (not chip id), then your chip is slightly different model and you need to edit ~/scripts/bme280.py to change 76 (top lines - one instance only) to whatever value you got. Save and run ~/scripts/bme280.py again. If it worked apply the same change to both ~/scripts/bme280F.py and ~/scripts/bme280C.py for consistency.

We are talking about the G3MC-202P-DC5 relays, right? That’s great news and strange at the same time as 10 samples we got didn’t get triggered by Pi Zero.

It sounds like he’s saying his werent triggered either, at least not by the software, only when he manually triggered them via gpio. thats an important distinction.

No, it’s not :slight_smile: the difference is at electrical level and regardless of how the Pi sets its GPIO LOW or HIGH the voltage is still the same, so if you can get the Pi to control the relay, Im happy (and as I said before, very puzzled). Please confirm complete and accurate model/part number. A photo or two would help too.

Yes, to all. Those are the relays, I am saying they do work when the GPIO pins are flipped, and that the GPIO pins are not being flipped by the stock software.

Picture of the component:

Some info about my system:

  • It’s a US system
  • I don’t have a common wire (hence the need for an external 5V supply)
  • The heating and cooling have separate hot wires, which I combined (so if they are separate transformers supplying the 24V AC, they are in phase)

The BME sensor issue is not resolved. Below is the exact output from the relevant commands. Temperature value is correct.

pi@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- 76 --
pi@raspberrypi:~ $ ./scripts/bme280.py
Chip ID     : 88
Version     : 1
Temperature :  77 F
Pressure :  994.022775087 hPa
Humidity :  0.0 %

Glad to hear those relays work. Maybe ill finally finish mine and order that header block that you used for the display. Then I just need to work out power, since I’m also on a 2-wire heating system.

So my only guess is that something went wrong on the first boot. I remember accessing the web UI too early caused an issue and we got that problem even by leaving a tab open on our browser. I would suggest reflashing the card, and once you set the WiFi details on the webpage, leave it alone (close any browser or app that could be polling in the background) for 15 minutes and try again.
The sensor and the relays look totally fine. No need to touch them :slight_smile:
I cannot understand why my mouser-supplied relays behave differently…?

I’d be interested to hear if you have different results. If not, maybe I’ll have figured out what’s going on with the GPIO pins not triggering and have some advise (or a patch) for everyone.

Hey @hestia_hacker did you ever get the relays figured out? I ordered the pins for the display, but they havent arrived yet.

I found some interesting results. TL;DR root cause remains elusive, but I may have found a kinda terrible workaround.

First, I saw this same problem on my original HestiaPi (from the croundfund) where the A/C wasn’t coming on during our mini-conference! Rebooting it fixed the problem, but I fear that it will only return until we get to the root of this matter.

I booted up my new device, since that is where the problem has been reproducible (plus I am not too keen on experimenting on my production unit in the middle of August). I found that upon booting, it was not flipping the GPIO pins (according to /sys). I manually flipped one (echo 1 … as root). That held. When I used the LCD to turn it off, I checked the value and the pi was able to turn off the GPIO pin. Next, I tried using the LCD to turn on the fan again and it worked just fine.

I repeated this process with the cooling pin and the heating system. The pattern seemed consistent: after manually toggling it, the LCD controls (and the app) worked fine.

I am now going to reboot many times and try these things in different orders and as different users. I did check the permissions on the gpio pins and they’re rwx by the gpio group, of which the pi user is a member. This seems correct, so we’ll see if I can find a real workaround here.

As a side note, it takes quite a while for the gpio12 smylinks to get placed by… well the kernel I guess. So putting something to flip them low on boot will need to be aware that this would likely have to be a blocking action.

I’ll let you know what I find, but each reboot is about 15 minutes, so it might be a while before I have any real results.