A post was split to a new topic: Network requirements
That is extremely good information to have on the first run. 
HAHAHHA I NEVER would have thought of that, I would have edited the config. 
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:
- Disconnect it from my HVAC system and connect the old thermostat so I can work comfortably
- Try to debug the software to see why the GPIO pins arenāt getting flipped
- Fix the problem
- 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 
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
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.
Thanks! Iām excited to get this thing working, I started this months ago, and its still just a non-functional trinket sitting on my shelf because i was unable to get the display pins figured out. Once i get those, iād love to get to the gpio pins, and get the thing into service!
2 Likes
In all tests thus far, the icons in the UI show accurate status (flashing when the corresponding relay is closed, not flashing when the relay is open). The heat/cooking does not turn on when expected though: e.g., the room temperature is below the set point for heat or above it for cold and the GPIO pin never flips to a 1. Room temperature is always accurate on the UI.
It seem there may be several unrelated bugs that are making it more difficult to debug.
It seems that nothing ever works right the first time it boots, but a soft power cycle improves the situation. I canāt explain why this is the case, but it is what I am observing. Maybe some components arenāt initalzed in the correct order during the boot process?
The remainder of this post will be my notes from repeated tests. Iād rather be posting a conclusion, but I havenāt been able to figure it out yet.
Attempt 2 (soft reboot): The fan and coolingworked as expected without any fooling around.
The heat, on the other hand, did not have the flame icon flashing even though my heat is āautoā, the set point is at 26Ā°C, and the room temperature is 23.4Ā°C (with the comfort range set to Ā±1Ā°C). I donāt have any explanation as to why this is the case, but it seems like it is an issue with the software (OpenHAB?) not attempting to trigger the GPIO pin. This is an important distinction because it means maybe I should stop looking at the Linux kernel and the GPIO pins. Test ended without being able to get the heat working.
Attempt 3 (after a full shutdown & power cycle): software doesnāt change any GPIO values. Command line can flip them.
Attempt 4 (after a soft reboot): heat and fan both work, cooling never kicks on. In both this test and test 2, the first system I tried was operational and the other was not.
Attempt 5 (soft reboot): cooling and fan came on automatically, which was correct. Turning off the cooling did not disable the fan, but I flipped it on and off again and the fan did shut off the second time. The heat worked properly (aside from the fact that it turned on the fan, which is only used for the cooling system). Basically, everything worked acceptably well.
Attempt 6 (soft reboot): fan was on at boot (undesirable). Everything seemed to function correctly, however I did see a glitch where the heat was on (relay and icon) while the āheating offā was displayed. The relay did open when I turned the heating system off, but then it closed again just after the fan spun down. Turning the heating on and off again got it back into the correct state.
Attempt 7 (soft reboot): same as test 6. Cooling cme on automatically (as desired). Reproduced the glitch with heating. Here is the sequence:
a. Turn heat on, only fan activates
b. turn heat off, heat and fan activate
c. turn heat on, heat and fan remain active
d. turn heat off, heat deactivates and fan remains on
e. turn off fan
Attempt 8 (soft reboot): Heat is glitching same as before, but relays worked fine. Cooling worked fine. Now that I seem to have consistent results, time for a full power cycle.
Attempt 9 (full power cycle): same as test 3 however I did not manually trigger the relays from the command line.
Attempt 10 (soft reboot): everything worked more or less as expected. Had to turn the heat up quite a bit before it triggered the relays, but it did trigger them.
I am willing to put up with this error for my own system, but itās hard for me to recommend others get a HestiaPi with it being like this.
I am going to solder together another unit and go through all this testing again. That will also let me swap out the temperature sensors to see if I can figure out why I am not getting humidity data (bad part, maybe?)
I canāt quite conclusively say that all the hardware is good and we are only dealing with software issues, but that is what it looks like.
Very nice! Let us know whether you have any issues or if everything works on the first try. Cheers.
So I did get it booted up, and even hooked it up, but I was having some speed issues.
I will link it: