HestaPi stuck at 0°-screen (no. 15 of First boot ONE-tutorial)

It seems you have upgraded after you used the HestiaPi image.
The whitelist issue is something that appeared in 2.5 and therefore it is not merged in the official release.
Please use this workaround or simply don’t upgrade yet.
Everything you reported should go with this… btw the CPU load was indeed fine. It is just the UI that confuses during startup (maybe we should delay the first check of CPU load)

Hello again and thank you for you quick help again!

Yes, you are right, I did upgrade after the last-reflash, because I experienced problems.

Thank you for your hint to the workaround. I thought I’ll re-flash the SD-card instead of giving a try to the workaround. I re-flashed the SD-card and did not perform “sudo apt-get update” and “sudo apt-get upgrade” this time. Here is the SSH log after the fresh install:

pi@raspberrypi:~ $ uptime
 09:50:50 up 25 min,  1 user,  load average: 0.19, 0.12, 0.19
pi@raspberrypi:~ $ uptime
 10:04:11 up 39 min,  1 user,  load average: 0.03, 0.08, 0.10
pi@raspberrypi:~ $ python /home/pi/scripts/bme280.py
Chip ID     : 96
Version     : 0
Temperature :  26.27 C
Pressure :  1018.48516063 hPa
Humidity :  29.0394910303 %
pi@raspberrypi:~ $ uptime
 10:09:07 up 44 min,  1 user,  load average: 0.12, 0.10, 0.10
pi@raspberrypi:~ $ uptime
 10:24:22 up 59 min,  1 user,  load average: 0.17, 0.11, 0.09
pi@raspberrypi:~ $ openhab-cli showlogs

==> /var/log/openhab2/audit.log <==

==> /var/log/openhab2/events.log <==

==> /var/log/openhab2/openhab.log <==
    -> Export-Package: org.eclipse.smarthome.core.events; bundle-symbolic-name="                                                                                                                                                                           org.eclipse.smarthome.core"; bundle-version="0.10.0.oh240"; version="0.0.0"; use                                                                                                                                                                           s:="org.eclipse.smarthome.core.items,org.osgi.service.event,org.eclipse.smarthom                                                                                                                                                                           e.core.types"

        at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incSta                                                                                                                                                                           rtLevel(ModuleContainer.java:1634) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incSta                                                                                                                                                                           rtLevel(ModuleContainer.java:1613) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doCont                                                                                                                                                                           ainerStartLevel(ModuleContainer.java:1585) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispat                                                                                                                                                                           chEvent(ModuleContainer.java:1528) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispat                                                                                                                                                                           chEvent(ModuleContainer.java:1) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventM                                                                                                                                                                           anager.java:230) [?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even                                                                                                                                                                           tManager.java:340) [?:?]

All the time since I started the SSH session above, the LCD shows the screen from my first post. The web-interface does not work. The LCD reacts to the “i” button. In the Info-screen, all values are shown as “–”

I’ll leave this fresh install running for a while. I you have any clues what I could try, let me know.

You got all the issues together :frowning:
Try this over SSH and I believe this would be the last issue to tackle:

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

Thank you again for your quick help!

I inserted your commands. The webinterface worked after 30 min. Here is the SSH output:

pi@raspberrypi:~ $ uptime
 15:22:27 up 15 min,  1 user,  load average: 2.13, 1.75, 1.29
pi@raspberrypi:~ $ uptime
 15:35:49 up 28 min,  1 user,  load average: 1.91, 1.68, 1.47
pi@raspberrypi:~ $ python /home/pi/scripts/bme280.py
Traceback (most recent call last):
  File "/home/pi/scripts/bme280.py", line 173, in <module>
    main()
  File "/home/pi/scripts/bme280.py", line 161, in main
    (chip_id, chip_version) = readBME280ID()
  File "/home/pi/scripts/bme280.py", line 56, in readBME280ID
    (chip_id, chip_version) = bus.read_i2c_block_data(addr, REG_ID, 2)
IOError: [Errno 121] Remote I/O error
pi@raspberrypi:~ $ uptime
 16:41:55 up 34 min,  1 user,  load average: 1.55, 1.63, 1.49
pi@raspberrypi:~ $ python /home/pi/scripts/bme280.py
Traceback (most recent call last):
  File "/home/pi/scripts/bme280.py", line 173, in <module>
    main()
  File "/home/pi/scripts/bme280.py", line 161, in main
    (chip_id, chip_version) = readBME280ID()
  File "/home/pi/scripts/bme280.py", line 56, in readBME280ID
    (chip_id, chip_version) = bus.read_i2c_block_data(addr, REG_ID, 2)
IOError: [Errno 121] Remote I/O error
pi@raspberrypi:~ $ uptime
 16:55:55 up 48 min,  1 user,  load average: 0.16, 0.36, 0.76
pi@raspberrypi:~ $ python /home/pi/scripts/bme280.py
Traceback (most recent call last):
  File "/home/pi/scripts/bme280.py", line 173, in <module>
    main()
  File "/home/pi/scripts/bme280.py", line 161, in main
    (chip_id, chip_version) = readBME280ID()
  File "/home/pi/scripts/bme280.py", line 56, in readBME280ID
    (chip_id, chip_version) = bus.read_i2c_block_data(addr, REG_ID, 2)
IOError: [Errno 121] Remote I/O error

The sensor data is shown as zero, but the touch screen now completely responds. I am not sure if I am using the touch screen too fast. If I increase or decrease the temperature by repeatedly pushing the “+” or “-” signs too quickly, the setpoint temperature takes some time, until it is steady again:
I have uploaded a quick video showing the effect here (it will be available online for 7 days): Video

It is interesting, that the dicrect readout of the BME 280 now fails, although it worked before. Any suggestions what we can try next?

Does this return the sensor readings ok as before?
python /home/pi/scripts/bme280.py

Make sure the sensor wire is pushed all the way in with the correct polarity.

Good hint, although I thought I did not touch any sensor wires, I measured them with the oscilloscope. 3.3V, GND, SDL and SCK were ok on the plug, but not on the sensor board. I assumed, that the connector contac was not good. This was correct. After moving the sensor connector, several times, the display showed temperature and humidity values.

Strangely, after touching the screen, after each touch, some elements disappeared, until it was completely black at the end (not shown):

I rebooted it again.
15 min after boot, the display showed the screen from my first post. The webinterface looks like this:

19 min after boot, the temperature and humidity value is displayed.

20 min after boot, the flame, water drop and shower symbol is shown.

22 min after boot, I pressed on the flame symbol. The setpoint temperature was set to 70 °, which I could adjust to 23.5°. After reaching 23.5°, the touch screen stopped responding. I could set a new setpoint via webinterface, which was now fully available. Here is the SSH history

pi@raspberrypi:~ $ uptime
 18:42:35 up 8 min,  1 user,  load average: 1.49, 1.55, 0.95
pi@raspberrypi:~ $ uptime
 18:49:33 up 15 min,  1 user,  load average: 1.51, 1.42, 1.11
pi@raspberrypi:~ $ python /home/pi/scripts/bme280.py
Chip ID     : 96
Version     : 0
Temperature :  26.1 C
Pressure :  1018.64328579 hPa
Humidity :  30.4451281832 %
pi@raspberrypi:~ $ uptime
 18:53:15 up 19 min,  1 user,  load average: 2.56, 1.66, 1.26
pi@raspberrypi:~ $ uptime
 18:53:52 up 20 min,  1 user,  load average: 4.70, 2.38, 1.52
pi@raspberrypi:~ $ uptime
 18:54:45 up 20 min,  1 user,  load average: 2.77, 2.21, 1.51
pi@raspberrypi:~ $ uptime
 18:56:01 up 22 min,  1 user,  load average: 2.93, 2.35, 1.61

So now the webinterface and the sensor works, but not the touchscreen.

So I used the command
openhab-cli showlogs
to have a look, what is going on.

pi@raspberrypi:~ $ openhab-cli showlogs

==> /var/log/openhab2/audit.log <==

==> /var/log/openhab2/events.log <==
2020-03-22 19:04:17.925 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 26.1
2020-03-22 19:04:17.945 [ome.event.ItemCommandEvent] - Item 'MyHumiProxy' received command 31.0
2020-03-22 19:04:18.055 [nt.ItemStatePredictedEvent] - MyHumiProxy predicted to become 31.0
2020-03-22 19:04:18.152 [vent.ItemStateChangedEvent] - MyHumiProxy changed from 31.1 to 31.0
2020-03-22 19:04:28.146 [vent.ItemStateChangedEvent] - MyHumi changed from 31.0 to 30.9
2020-03-22 19:04:28.301 [ome.event.ItemCommandEvent] - Item 'MyTempProxy' received command 26.1
2020-03-22 19:04:28.347 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 26.1
2020-03-22 19:04:28.370 [ome.event.ItemCommandEvent] - Item 'MyHumiProxy' received command 30.9
2020-03-22 19:04:28.448 [nt.ItemStatePredictedEvent] - MyHumiProxy predicted to become 30.9
2020-03-22 19:04:28.518 [vent.ItemStateChangedEvent] - MyHumiProxy changed from 31.0 to 30.9

==> /var/log/openhab2/openhab.log <==
java.lang.NullPointerException: null
        at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleContextHelper.getContext(RuleContextHelper.java:68) ~[?:?]
        at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.lambda$2(RuleEngineImpl.java:339) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

==> /var/log/openhab2/events.log <==
2020-03-22 19:04:38.510 [vent.ItemStateChangedEvent] - MyHumi changed from 30.9 to 31.3
2020-03-22 19:04:38.681 [ome.event.ItemCommandEvent] - Item 'MyTempProxy' received command 26.1
2020-03-22 19:04:38.723 [ome.event.ItemCommandEvent] - Item 'MyHumiProxy' received command 31.3
2020-03-22 19:04:38.775 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 26.1
2020-03-22 19:04:38.870 [nt.ItemStatePredictedEvent] - MyHumiProxy predicted to become 31.3
2020-03-22 19:04:39.075 [vent.ItemStateChangedEvent] - MyHumiProxy changed from 30.9 to 31.3
2020-03-22 19:04:48.884 [vent.ItemStateChangedEvent] - MyHumi changed from 31.3 to 30.9
2020-03-22 19:04:49.024 [ome.event.ItemCommandEvent] - Item 'MyTempProxy' received command 26.1
2020-03-22 19:04:49.064 [ome.event.ItemCommandEvent] - Item 'MyHumiProxy' received command 30.9
2020-03-22 19:04:49.112 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 26.1
2020-03-22 19:04:49.197 [nt.ItemStatePredictedEvent] - MyHumiProxy predicted to become 30.9
2020-03-22 19:04:49.347 [vent.ItemStateChangedEvent] - MyHumiProxy changed from 31.3 to 30.9

When I am tapping on the touch screen no entry in the log is shown. The screen is constantly updated with new sensor values.
Do you have another idea, what we could try?

When you reboot, leave it alone for 30 minutes (an update exists that drops this to 15 minutes but the whitelist issue needs to be resolved until we release it).
Touching the LCD should not produce anything in the OH logs. Assemble everything carefully and try once more.

I’ll be submitting an update soon that drops this to 10 (from white screen to fully functioning, not just a restart of OH). I can drop it even further if we explore the delaying the check for CPU load before switching over you mentioned above (I’ll bring up the details on github when I submit the initial PR). I’m really close but I want to document the Rules a bit more to help you review the changes and there is one annoying thing I’m trying to change (in US mode, if Heating or Cooling are to turn on the device and the FanMode is ON after a reboot, I want the Heating/Cooling interface to be shown by default after the reboot and right now the Fan screen is showing). There is a timing issue here I think that I need to sort out.

Note: OH 2.5.3 which was released last week fixes the Exec binding whitelist binding bugs. No more need for the workaround.

Anyway, expect a PR this week.

@gon, if you want to be a tester I can provide the changes in a Google Drive and you can try it out. I don’t have a set of upgrade procedures written yet though.

Dear HestiaPi, dear rlkoshak, thank you for your help.

I did not respond yet, because my results stayed the same after several tries.

Sure, I can try your changes, but don’t expect too much from me (I am not good at linux). A flashable SD card image would be perfect

During the quarantine period we will not be able to upload large files like flashable images, so you will wait a little longer for that.

Is the screen white and blank during this 10-30 minute boot time?

No. You should be seeing the boot sequence at the beginning and then the screen with some symbols and a couple of 0.
If yours is blank check the screen is inserted correctly. Be careful even a one pin mistake can kill the LCD

Dear terrarium,
I powered one of my hestia Pi’s up to see how it looks like. I did not install a new image. I used an already installed image, so results may be different with a new one.
After applying power, the tested HestiaPi showed a white screen for 30 minutes. I could access its website. I guess I should try a new image. I’ll report my experience here.

Shouldn’t the web interface still work even if the screen won’t?

See here

It may be the case that the LCD is not inserted fully

Yea I thought that might be the case and I tried it on a rpi 3b+ that I confirmed to be functional and couldn’t get it to work. Is it the case that the web interface will only work with a functioning touch screen?

I don’t think so. There may be 2 separate problems. Try this for the LCD:


And the commands from the wiki step 15 for the web interface.

ok looks like im almost there. Am i going to be in trouble if i upgraded to OH 2.5?

Search this forum if you want to upgrade OH but we are working on a major upgrade that will address any issues related to that soon

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