Boots, but can't connect to web page

Get help!
1

Got my new Hestia Pi from the crowd funding project to replace the last one I built myself (it stopped controlling the furnace after a few months). US version. I’ve connected it to my wifi, it boots up, but I cannot load the web page (Firefox can’t establish a connection to the server at 10.0.31.117:8080), nor does the touch screen seem to function. The screen displays “Off” - 0 degrees and 0 percent humidity, no reactions when I press anything. I can SSH into it, I’ll post the output from “top” below, but after several reboots, but otherwise it does not seem to function. Now, I do only have the power connected - I wanted to make sure it was operational before installing it fully, but I don’t think that is the issue.

Tasks: 113 total,   1 running, 112 sleeping,   0 stopped,   0 zombie

%Cpu(s): 1.6 us, 1.6 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem: 444528 total, 373352 used, 71176 free, 26488 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 196948 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1552 pi 20 0 5100 2476 2084 R 1.6 0.6 0:06.30 top
66 root -51 0 0 0 0 S 0.3 0.0 0:01.49 irq/86-mmc1
749 openhab 20 0 211668 78572 13232 S 0.3 17.7 1:22.78 java
1536 root 20 0 0 0 0 S 0.3 0.0 0:00.58 kworker/u2:2
1538 pi 20 0 9704 3968 3256 S 0.3 0.9 0:01.23 sshd
1 root 20 0 23892 4008 2788 S 0.0 0.9 0:06.77 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.80 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
8 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
9 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
14 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockd
17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 watchdogd
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 rpciod
20 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 xprtiod
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 nfsiod
32 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kthrotld
33 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
34 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
35 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
36 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
37 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
38 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
39 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
40 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
41 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
42 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
43 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
44 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset

2

FYI, by “I’ve only connected the power” I mean as far as furnace connections. I have the temp/humid sensor and the display connected.

3

Log posts:
==> /var/log/openhab2/events.log <==
2020-01-25 23:18:39.878 [vent.ItemStateChangedEvent] - MyHumi changed from 31.5 to 31.4

==> /var/log/openhab2/openhab.log <==
2020-01-25 23:18:51.684 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP POST request at 'items/TempSetpointF' for the unknown item 'TempSetpointF'.

==> /var/log/openhab2/events.log <==
2020-01-25 23:19:01.345 [vent.ItemStateChangedEvent] - MyHumi changed from 31.4 to 31.3

==> /var/log/openhab2/openhab.log <==
2020-01-25 23:19:01.358 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'convertproxy': The name 'PreviousTempReading' cannot be resolved to an item or type; line 180, column 6, length 19
4

Ran apt-get update / apt-get upgrade. I can connect via web now, but still no temp or humid displays on lcd

5

OK, so the display eventually came up. The touch interface does not seem to be working though. I can set the temperature via the web interface, but it takes a good minute or two for updates to show on the screen. Running openhab-cli showlogs, I do not see it taking the inputs from the screen temp adjustments, but it does register the web interface temperature adjustments. Takes a good full 2-3 minutes for the settings to show up on the LCD - is that normal?

6

No :slight_smile:

Not sure if apt-get update / apt-get upgrade was a good idea that early. Can you run top for me to see CPU load? I would expect it to be very high hence the delay.
If this doesn’t change, I would suggest to reflash the card from the image from our website for ONE.

Please use code fences for logs in your posts by selecting the text and select the preformatted text button from the toolbar. I edited your posts :wink:

7

Interesting. I suspect this means you are now running OH 2.5 instead of 2.4. it’s interesting and good to know that everything sense to work just fine after the upgrade. That’s high on my list of things to do.

I couldn’t tell from your output above if top is saying whether the CPU it maxed out or not. It takes a good 15 minutes it more for the HestiaPi to fully boot. Have you waited long enough? You can tell when it’s truly done boring when top says the CPU had dropped below 20%. When it’s 80-100% that means it’s still parsing and leading the rules. And until the first rule runs to initialize everything, the UI will be as you described.

8

I think I may have had a similar issue this morning. I’m happy to share data if it’s helpful, otherwise feel free to ignore this message.

I’ve got a prebuilt Touch v6, which I had working without being connected to my (UK) boiler, because I wanted to command the boiler control using a TASMOTA’d Sonoff Basic over MQTT, and just didn’t get around to finishing the job. V6 ran well on it.

Anyway, I flashed an SD with Hestia One yesterday, adding WiFi credentials was very smooth, I’ve never had a problem logging in through SSH, but couldn’t access http://:8080 (“Unable to connect”), and my HestiaPi’s screen read “OFF”, and showed Zeros. The info button worked, but showed no information even though the HestiaPi splash screen displays its IP during boot-up. I’m not sure that OpenHab was doing anything.

I left the install to run overnight, so it had time, and I’ve reflashed and tried reinstalling this morning, md5 hashes look right, it’s running on a 32GB SD card so hopefully plenty of space, the pi running off maybe 2.4a through an accessible usb socket (underpowered potentially, though it’s worked later on). Top showed cpu 97% idle.

On the third or fourth time I reflashed the SD card and started again, OpenHab continued the setup (doing lots of CPU work in the process this time), which I don’t think it had before, and eventually (after maybe half an hour or more) it started reading temp/humidity and triggering the boiler relay. Hurrah! I was able to access OpenHab through the browser right from the point where the Pi entered AP mode (i.e. 192.168.4.1).

I’m not sure why the installation seemed to stall before. If there is some kind of log (etc) that I could share if I could replicate it (assuming it’s an issue that needs addressing), I’d be happy to contribute.

Part of the issue for me was that I didn’t know what to expect from the installation process, except that at some point the UI would update as it mentions in the instructions for One, and after 10h or so it hadn’t.

9

It seems to be running fine now. Perhaps the update? Also, the screen seems to be defective - I replaced it will an older one I had from my previous build, and I can now control it via the LCD. Which brings up the next question - how do I get a replacement screen?

10

I had waited about an hour earlier in the process, CPU load was around 2%-5%.

11

Did you try connecting the LCD without being mounted to the case?

12

Sorry for the long delay, I have much to update (later). Basically, I did try with the case off, still no touch. I had a touch screen from my last HestiPi that died, and that touch screen works on this unit.

13

So in the new HestiaPi from CrowdSupply, the new LCD does not register touch events but swapping the LCD with another but identical LCD, touch events register as normal. Correct?

14

I bought two. One worked, one didn’t.

As usual, all the ones that work are the same, but the ones that don’t aren’t.

I connected just the blue and red wires to the terminals at the end. It came up, and finally just displayed “0 degrees”; on the “(i)” screen everything was blank. It connected to my wifi, but did not respond to port 8080. Logging in with ssh did work, though.

I wrote in, and (someone) wrote back suggesting I run the following.

sudo systemctl stop openhab2
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo reboot

and wait a half hour.

It worked. Now I have two Hestia Pis that work.

1 Like
15

Sorry for the long delay again, crazy pandemic. No, swapping the LCD with a known-good LCD still does not work. The touch issue seems to be with the CrowdSupply HestiaPi iteself. I have two HestiaPi’s and two LCDs. Touch works with either LCD on the old HestiaPi, no touch working on the CrowdSupply HestiaPi, regardless of LCD.

16

Please try the resoldering technique thoroughly. We believe there are some bad solder points that do not keep a valid connection all the time and trigger this weird behaviour. Focus on the pins that are used by the LCD ignoring the ones marked as NC.

17

I’ll give that a go - thanks!

18

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