ads' corner

The openHAB display in the kitchen is still the problem child. Occasionally it just stops, other times it does not refresh the HABpanel, even though it has a connection to the openHAB server. Then there is the problem with the network card in the Pi. And - ok, that's a server-side problem - occasionally the weather stops updating. All in all that's a lot of trouble for a display which is just supposed to run standalone.

In the latest iteration I looked into activating the integrated hardware watchdog in the Raspberry Pi. Checking the temperature it never goes above ~55°C celcius, even though the display is in an almost closed frame and can't exchange much heat with the environment. But nevertheless occasionally the Pi just halts, and stops operating.

Don't you love it when things suddenly stop working?

In my openHAB installation I have a check which verifies that the weather data is up to date. Otherwise it restarts the openhab2 service. And this check stopped working ... Leaving the kitchen display not updated for a longer time. The same display where I expect the entire installation to "just work", and don't create so many different problems. Seems to be a hard problem to have an openHAB installation without any trouble ...

openHAB is a stream of pure joy when it comes to debugging. Especially when all I want is a small display in the kitchen, working autonomous and without the need to restart it all the time or login to fix issues.

The latest installment of that endeavor was a black screen in the browser, with no way to even get to the usual HABpanel controls. After some debugging, it turns out that the file "habpanel.config" (/var/lib/openhab2/config/org/openhab/habpanel.config) on the openHAB server was destroyed, or more accurate: shortened to 4829 bytes. Lucky me I have this file in my Ansible playbooks, and whenever there is a change, a copy of this file is fetched to my Ansible host. From there it goes into my backups, and I can restore a couple dozen versions back, if needed. So not all is bad, but still something is not working as expected. First I installed a copy of this file from my backups - but turns out shortly later the file is shortened again. Later I figured that the file is always shortened when the openHAB service restarts. This particular instance was still running openHAB 2.4, and I used this opportunity to upgrade to 2.5, test my Playbooks (and exclude the one config file from everything) and see if the problem persists. It does. Except that after upgrading to 2.5 the file is no longer shortened to 4829 bytes, but to 4875 bytes.

Every time that happens, the file ends somewhere in the middle of the HABpanel panel configuration - and naturally the HABpanel service can no longer read that file and shows a blank screen. I would wish that it rather shows an error message, or does something useful here, but oh well.

For a while (and mostly because I was busy with other tasks) I helped myself by changing the owner of "habpanel.config" and the directory this files lives in to "root:root". This threw a couple other errors into the logfile, but helped somewhat because the config file got no longer destroyed when the service restarted.

In our Home Automation system, I read weather data from OpenWeatherMap. I blogged about the implementation before. The weather data provides an icon which can be used to show the current weather:

Image	homeCurrentIcon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:current#icon" }
Image	homef03Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours03#icon" }
Image	homef06Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours06#icon" }
Image	homef09Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours09#icon" }
Image	homef12Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours12#icon" }
Image	homef15Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours15#icon" }
Image	homef18Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours18#icon" }
Image	homef21Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours21#icon" }
Image	homef24Icon		"Icon"		{ channel="openweathermap:weather-and-forecast:home:forecastHours24#icon" }

On the openHAB server side, this reads the picture data into the Item itself:

2020-02-20 00:39:38.476 [vent.ItemStateChangedEvent] - homeCurrentIcon changed from raw type (image/png): 3801 bytes to raw type (image/png): 2773 bytes
2020-02-20 03:59:47.156 [vent.ItemStateChangedEvent] - homeCurrentIcon changed from raw type (image/png): 2773 bytes to raw type (image/png): 2565 bytes
2020-02-20 04:19:48.006 [vent.ItemStateChangedEvent] - homeCurrentIcon changed from raw type (image/png): 2565 bytes to raw type (image/png): 2922 bytes

The really interesting question is: how can I display this icon directly in HABpanel. The available documentation is sparse to non-existent.

The Raspberry Pi in the kitchen runs relatively stable, but recently the browser (which is showing the openHAB HABpanel) popped up a warning in the upper right corner. That's annoying, because this area in HABpanel shows the outside temperature.

Before investigating what's going on, I had to figure out a way to get a screenshot of the display - without running into the kitchen with my mobile phone. And without attaching a keyboard all the time (to press the "Print" button).

The openHAB HABpanel we have in the kitchen runs on a Raspberry Pi and uses a touchscreen display. The browser starts in fullscreen mode, and shows a specific HABpanel screen for this display. That's all nice, but by default the mouse cursor is in the way. Let's get rid of it.

In one of my earlier blog posts I reported that occasionally the HABpanel will disconnect from the server. Turns out it's not HABpanel, but it's the Pi itself which is causing the trouble. Part of the problem why it took me so long to investigate is that the display is in the kitchen, and someone had to have a look and spot the small red error message. To work around that problem, I hooked the device up in the network monitoring, and had an alarm triggered when the device is not reachable. Sure enough, that happens occasionally.

Because I moved /var/log to a small RAM disk to avoid wearing out the SDcard, all logs are lost once the device is rebooted. Had to bring keyboard and mouse to the kitchen in order to save the logfiles once the device was no longer reachable over the network.

The new display showing HABpanel works quite nice. But occasionally the fullscreen browser will lose the network connection. As far as I can see, it's not a Wi-Fi problem of the Raspberry Pi, but still annoying: in the morning the browser shows a small red warning that the connection to the openHAB server is lost, time is still correct, but temperature and the status of other devices is outdated. To fix that, I have to leave fullscreen mode, hit reload - and then there is no keyboard for going into fullscreen mode again (that's using the F11 key).

The Raspberry Pi with the touch display for the home automation system is coming along nicely. One problem to solve: how to display the openHAB HABpanel, and which browser to use?

Firefox and Chrome don't run on Raspbian. However "Chromium" (the open source part of the Chrome browser) is. That's a good start. But how to start the browser automatically, and in full screen?

Recently I installed a Raspberry Pi with Raspbian, and attached a touchscreen to it. The device is supposed to work as a display for our openHAB home automation system. All nice and shiny, except the Pi occasionally disconnects from the Wi-Fi - apparently in order to safe power. Once the network device is needed, the Wi-Fi is reconnected. That is the default setting.

That is quite annoying, because the HABpanel will lose it's connection to the openHAB server, and no longer show widget updates. Some widgets like "time" will just continue to work, but other widgets like status of the washing machine, or the current outside temperature just show the last state, and never update.