openHABian hassle-free openHAB Setup

i just upgraded my openHABian without any problems!
Now, i noted that the green LED (heart-beat) is not longer active :thinking:
First shock … my HABy is dead, but everything is working fine … puh
So, is this nice little features disabled in the latest release?

I don’t know the rationale, but yes, it’s intentional.

You might be interessted in this. :slight_smile:

Hi @ThomDietrich,
just to let you know, “Frontail” is currently not installable via openhabian-config on Debian stretch.

Reason is, that node.js version 7.x is refusing installation because “stretch” is “currently not supported”.
(I’ve raised an issue on github/nodesource on that…)

Workaround is to force installation of node.js 8.x instead of 7.x manually via

curl -sL | bash -
apt-get install -y nodejs

Afterwards, you can go back to openhabian-config and install Frontail from menu :wink:

not sure if this is openHABian related:

Failed installing 'openhab-binding-http1': Permission denied

is it?

I found the solution
I burned the image on SD using Win32DiskImager instead of Etcher.

All worked perfectly

Hi @mstormi,

I have exactly the same problem like @boob (openHABian hassle-free openHAB Setup).

[14:32:09] backup@openHABianPi:/var/log/amanda/server/openhab-dir$ amcheck openhab-dir
Amanda Tape Server Host Check
slot 1: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 2: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 3: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 4: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 5: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 6: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 7: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 8: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 9: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 10: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 11: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 12: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 13: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 14: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
slot 15: Error checking directory /srv/backup/slots/drive0/data/: No such file or directory
 volume ''
Taper scan algorithm did not find an acceptable volume.
(expecting a new volume)
ERROR: No acceptable volumes found
NOTE: host info dir /var/lib/amanda/openhab-dir/curinfo/openHABianPi does not exist
NOTE: it will be created on the next run.
NOTE: index dir /var/lib/amanda/openhab-dir/index/openHABianPi does not exist
NOTE: it will be created on the next run.
Server check took 3.801 seconds

Amanda Backup Client Hosts Check
Client check: 1 host checked in 4.530 seconds.  0 problems found.

(brought to you by Amanda 3.3.6) 

No manual configuration. Only the openhasbian-config.

My share is connected via SMB/CIFS in fstab and is on a Synology. Dir is reachable and writable. The slots dirs are created and then I try amcheck leading to the errors above. I tried it multiple times with the configuration tool.

Any idea?

Thanks in advance!

Hmm, I wonder where that ‘drive0’ is coming from.
Can you tell me what’s the path to NAS you entered and post your config file (/etc/amanda/openhab-dir/amanda.conf).
Try cd /srv/backup/slots; sudo ln -s . drive0 and then retry amcheck.
And please make a Github issue of it.

I have installed the current version, using OH2.1. Additional services are NodeRed and frontail. Other that this, my installation is standard on an RPI3. Now, since the new version I can see rolling in random failure messages I never saw with OH2. Just like

2017-07-14 22:14:21.628 [ERROR] [ssories.AbstractHomekitAccessoryImpl] - Type RL_Treppenhaus is a org.eclipse.smarthome.core.library.items.RollershutterItem instead of the expected org.eclipse.smarthome.core.library.items.SwitchItem


I am using KNX, have bound my installation to the HomeKit and the Hue Binding (to use Alexa) which, again, worked flawlessly with OH2.
Same applies to the Astro Binding, where Offsets are obvisously no longer respected AND the configuration for Offset or earliest/latest settings are getting deleted from time to time.

I already reinstalled the Astro Binding, run upgrades and rebooted several times. Still, no success.

Anyone an idea where I should start looking for the root cause? Really puzzled…


This seems to be a generic problem (not related to openHABian). A “general” note: openHAB 2.1 is more strict with regards to syntax when it comes to parsing configs (items, sitemaps, etc). There have been more checks implemented in the code (core and bindings according to my understanding). An error could exist in the configs and it would not show up in openHAB 2.0 but now (in 2.1) it will pop up.

I suggest that you open up a new thread, post this info (with the error) along with the configuration of your RL_Treppenhaus item

It looks like the Homekit binding doesn’t like your tag & item type combo :slight_smile:

Ah, that would explain the error. HomeKit currently does not support Rollershutters at all, therefore defining this KNX-Rollershutter-item as a light-item was a feasible workaround. Now as this is not really wrong behaviour by OH, it makes no sense to raise an request. It just means that OH2.1 will prevent us from some workarounds due to this strictness.


1 Like

I think that this is the case.

I am also waiting for the rollershutter support in Homekit :slight_smile:

Textual thing config?
Altitude is now part of the geo location …

Nope. The location is correct. Funny thing is, i can see the dusk-start and dusk-stop event fire. Just not when it is expected :slight_smile:

CivilDusk ended today 21:54. With Offset set to “-10” the END-Event should have triggered 21:44, right?
The log stated 21:54 for CivilDusk End instead… (AND it did not run my rollershutters…)

What do you mean by “texual thing config” please, can you specify the question a litte bit more, please?

The items are all textual, as I am using KNX. The astro binding offset I configured in the paper UI. Does this answer your question?

astro:sun:home [ geolocation="52.5200066,13.4049540,100", interval=60 ]

This also applies to the config via PaperUI:

Before the change:56.123456,7.123456, after the change: 56.123456,7.123456,100 (where 100 is the altitude, but that is optional):

So if you have things files for astro and are using altitude, you have to adapt those.

BTW, my offsets and channel triggers are working fine with 2.1 and now 2.2 …
Also note another issue with the astro binding (if openHAB or the binding hasn’t been restarted for a while):

1 Like

Ah, ok.
In this case no, the astro binding is only configured using PaperUI. Only the bindings, items, sitemaps, rules, persistence and transforms are using textual config.

The error you posted I haven’t run into yet. Interestingly enough, with the original HassbianVersion for OH 2.0 it ran for several weeks without any problems. Seems this error has been introduced by the most recent version?


First of all - Great job. I really appreciate openHABIAN and had so far never really problem with it. More and more i am using the additional tools from the menue. Recentyl i installed mosquitto with openhabian and stop my mosquitto pi for that. transfer worked like a charm.

Netxt step is to use grafana with openhabian and my influx db. Influx is installes on my NAS as a docker service. Starting to install grafana i recognized that it installs influx as well on my raspi. Becaus of my NAS Influxdb i do not need any further installations.

Is it possible to divide those two topics in the menue?


You sir are a genius. Really. I have been struggling for a l o n g time. I want to automate some functions in my mobile home but most (if not all) tutorials assumed I would have ethernet access.
I want to run all this from my 12v DC.
And now I can using a RPi version 3 and a Huawei mobile wifi device

Fantastic work, much appreciated

1 Like

Sorry guys - anybody here has issues with astro binding since upgrade to openhab 2.1?
I have this simple rule, it worked til i upgraded:

rule "Spegni luce cucina all’inizio dell’alba"
Channel ‘astro:sun:home:civilDawn#event’ triggered START
sendCommand(Luce_Esterna_Cucina, OFF)

these are my triggered events:

2017-07-13 02:59:00.125 [ChannelTriggeredEvent ] - astro:sun:home:astroDawn#event triggered START
2017-07-13 04:03:00.096 [ChannelTriggeredEvent ] - astro:sun:home:astroDawn#event triggered END
2017-07-13 04:03:00.134 [ChannelTriggeredEvent ] - astro:sun:home:nauticDawn#event triggered START
2017-07-13 04:52:00.128 [ChannelTriggeredEvent ] - astro:sun:home:civilDawn#event triggered START
2017-07-13 04:52:00.131 [ChannelTriggeredEvent ] - astro:sun:home:nauticDawn#event triggered END
2017-07-13 05:30:00.257 [ChannelTriggeredEvent ] - astro:sun:home:civilDawn#event triggered END

i also noticed that during installation i got this:

2017-07-08 11:55:46.062 [temChannelLinkRemovedEvent] - Link ‘DawnStart_Time => astro:sun:home:civilDawn#start’ has been removed.
2017-07-08 12:17:48.683 [ItemChannelLinkAddedEvent ] - Link ‘DawnStart_Time-astro:sun:home:civilDawn#start’ has been added.

any idea?

Hi just an update. I noticed that

  • astro:sun:data e astro:moon:data were not initialized
  • to initialize them, paper UI asked me also altitude (i don’t remember i filled this info months ago)

so what i did:

  1. removed and reinstalled astro binding via paper UI
  2. filled in altitude data
  3. run an apt-get upgrade, lot of stuff upgraded

this morning all my rules are fired correctly.