Smart Home openHAB Installation Teil 2 – openHAB 2
Update 12.11.2020
Ab Dezember 2020 habe ich das Glück, ein Eigenheim zu besitzen. Mit dem Umzug werde ich mein Smart Home zukünftig mit Home Assistant steuern, sodass die Serie Smart Home openHAB Installation nicht länger fortgeführt und gepflegt wird.
Im zweiten Teil der Reihe Smart Home openHAB Installation geht es nun im ersten Schritt um die Installation von openHAB 2.
Betriebssystem Installation
Die Software installiere ich manuell auf einer Ubuntu Linux Distribution in einer VMware ESXi Umgebung als virtuelle Maschine. Dazu erstelle ich als erstes eine VM mit folgender virtueller Hardware:
- 2 vCPU
- 4 GB vRAM
- 40 GB vDisk (thin-provisioned)
Danach installiere und konfiguriere ich Ubuntu Server 18.04 LTS ohne GUI und ohne weitere Komponenten. Lediglich folgende Einstellungen habe ich während dem Setup vorgenommen:
- Konfiguration einer statischen IP Adresse
- Mirror für die Installationssourcen: http://de.archive.ubuntu.com/ubuntu
- als Konfiguration für die Disk habe ich folgende Option ausgewählt: Use An Entire Disk And Setup LVM
- Installation von OpenSSH server für den Remote Zugriff
Admin/Root Modus (sudo) aktivieren
Nach der Installation lassen sich alle weiteren Konfigurationsschritte per SSH Verbindung durchführen. Um nicht jeden Befehl einzeln per sudo zu elevaten, schalte ich den Root-Modus dauerhaft ein:
sudo -i
Hinweis: Bei einem Exit oder einem Reboot wird der Root-Modus beendet und muss entsprechend jeweils neu aktiviert werden.
Betriebssystem Konfiguration
Zwar habe ich bei der Installation angegeben, dass die komplette Disk mit LVM (Logical Volume Manager) verwendet werden soll, allerdings bewirkt dies nur, dass die ganze Disk partitioniert wird. Trotzdem legt der Installer in der Partition dann nur ein Volume mit 3.9 GB an; der Rest der Partition wird erstmal nicht verwendet. Daher erweitere ich im ersten Schritt den Speicher des angelegten Volumes auf die maximal mögliche Größe der Partition:
lvextend --resizefs -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
Zum Vergleich, die Ausgabe von df -h
vor der Änderung:
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 395M 2.9M 392M 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 3.9G 3.1G 654M 83% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/loop0 90M 90M 0 100% /snap/core/7917
/dev/loop1 90M 90M 0 100% /snap/core/7713
/dev/sda2 976M 114M 795M 13% /boot
/dev/sda1 511M 6.1M 505M 2% /boot/efi
tmpfs 395M 0 395M 0% /run/user/1000
…und nach der Änderung:
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 395M 2.9M 392M 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 38G 3.1G 34G 9% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/loop0 90M 90M 0 100% /snap/core/7917
/dev/loop1 90M 90M 0 100% /snap/core/7713
/dev/sda2 976M 114M 795M 13% /boot
/dev/sda1 511M 6.1M 505M 2% /boot/efi
tmpfs 395M 0 395M 0% /run/user/1000
Als nächstes deaktiviere ich IPv6, da ich es in meiner Infrastruktur nicht benötige.
sysctl -w net.ipv6.conf.all.disable_ipv6=1 sysctl -w net.ipv6.conf.default.disable_ipv6=1 sysctl -w net.ipv6.conf.lo.disable_ipv6=1 sysctl -w net.ipv6.conf.<Interface-Name>.disable_ipv6=1 sysctl -p
Ob IPv6 auch wirklich deaktiviert ist, lässt sich mit folgendem Befehl prüfen (0=aktiviert, 1=deakviert):
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
Danach stelle ich die Zeitzone ein und konfiguriere meinen internen NTP-Server als Zeit-Quelle.
timedatectl set-timezone Europe/Berlin nano /etc/systemd/timesyncd.conf
In die Datei timesyncd.conf
konfiguriere ich mit folgendem Eintrag meinen lokalen NTP Server:
NTP=<lokale NTP-Server IP>
Die restlichen, bereits vorhandenen NTP Einträge lösche ich.
Zusätzlich deaktiviere ich die automatischen APT Update und Cleanup Services, da ich die Updates manuell vornehmen möchte:
systemctl disable apt-daily.service systemctl disable apt-daily.timer systemctl disable apt-daily-upgrade.timer systemctl disable apt-daily-upgrade.service
Abhängige Komponenten
Im nächsten Schritt installiere ich alle Komponenten, die für OpenHAB 2 benötigt werden. Dazu zählt der HTTPS Support, SAMBA zum Zugriff auf die OpenHAB Konfigurationsdateien und eine Java Runtime – in meinem Fall verwende ich Zulu 8 JDK. Da Zulu JDK nicht im Ubuntu Standard-Repository verfügbar ist, füge ich vorher den Repository Key dem System hinzu, danach das Repository und abschließend installiere ich das Paket.
# Installation: HTTPS Support apt-get install apt-transport-https # Installation: SAMBA Core Komponenten apt-get install samba samba-common-bin # Konfiguration: Zulu 8 JDK Repo Key Authentication apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0xB1998361219BD9C9 # Zulu 8 JDK Repo apt-add-repository 'deb http://repos.azulsystems.com/ubuntu stable main' # Update: APT Package apt-get update # Installation: Zulu 8 JDK apt-get install zulu-8 # Konfiguration: Zulu 8 JDK File Capability setcap 'cap_net_raw,cap_net_admin=+eip cap_net_bind_service=+ep' $(realpath /usr/bin/java)
Zulu 8 JDK legt bei der Installation auch einen Java Keystore für CA Zertifikate an. Der Keystore mit wird einem Standard-Passwort (changeit
) gesichert. Das Passwort habe ich mit dem KeyTool geändert. Dabei muss einmal das o.g. Standardpasswort eingegeben werden und zweimal das neue Passwort.
keytool -storepasswd -keystore /usr/lib/jvm/zulu-8-amd64/jre/lib/security/cacerts
openHAB 2 Installation
Auch openHAB 2 ist nicht im Ubuntu Standard Repository verfügbar. Entsprechend lade ich auch hier einen Public Key herunter und importiere diesen und die entsprechenden Repositories und installiere anschließend das openHAB 2 Paket und das Addon Paket. Abschließend starte ich den openHAB 2 Dienst und konfiguriere den automatischen Start des Dienstes beim Systemstart.
# Konfiguration: openHAB Repo Key Authentication wget -qO - 'https://bintray.com/user/downloadSubjectPublicKey?username=openhab' | apt-key add - # openHAB Primary Repo echo 'deb [trusted=yes] https://dl.bintray.com/openhab/apt-repo2 stable main' | tee /etc/apt/sources.list.d/openhab2.list # openHAB Alternative Repo (optional) echo 'deb [trusted=yes] https://openhab.jfrog.io/openhab/openhab-linuxpkg stable main' | tee /etc/apt/sources.list.d/openhab2.list # Update: APT Packages apt-get update # Installation: openHAB & AddOns apt-get install openhab2 apt-get install openhab2-addons # openHAB Service starten systemctl start openhab2.service # openHAB Service Autostart konfigurieren systemctl daemon-reload systemctl enable openhab2.service
SAMBA Konfiguration
Um auf die Konfigurationsdateien von OpenHAB 2 zugreifen zu können (z.B. mit Visual Studio Code), werden entsprechende SAMBA Shares benötigt. Dazu sind nur wenige Konfigurationsschritte notwendig.
Als erstes ändere ich das Passwort des Benutzers openhab, welcher während der OpenHAB 2 Installation automatisch angelegt wird, und ändere den Owner (User/Group) des OpenHAB 2 Programmordners:
smbpasswd -a openhab chown -hR openhab:openhab /etc/openhab2
Danach editiere ich die SAMBA Konfigurationsdatei:
nano /etc/samba/smb.conf
In der [global] Section der Konfigurationsdatei smb.conf
passe ich den bestehenden Eintrag WORKGROUP
mit meinem Workgroup-/Domain-Namen an.
[global] WORKGROUP = <Workgroup-/Domain-Name>
Um die Shares anzulegen füge ich in die Datei smb.conf
zusätzliche Konfigurationen hinzu. Ich lege 3 Shares an, einen für die Benutzerdaten (userdata
), einen für die Konfigurationsdateien (config
) und ein Share für die Logs (logs
). Der Einfachheit halber konfiguriere ich einen Gastzugriff (Zugriff ohne Login) und nutze dafür den openhab User. Sicherer ist es natürlich, die Shares mit Authentifizierung abzusichern.
[userdata] comment=openHAB2 Userdata path=/var/lib/openhab2 browseable = yes writeable = yes guest ok = yes force user = openhab force group = openhab create mask = 0777 directory mask = 0777 [config] comment = openHAB2 Site Configuration path = /etc/openhab2 browseable = yes writeable = yes guest ok = yes force user = openhab force group = openhab create mask = 0777 directory mask = 0777 [logs] comment=openHAB2 Logs path=/var/log/openhab2 browseable = yes writeable = yes guest ok = yes force user = openhab force group = openhab create mask = 0777 directory mask = 0777
Abschließend starte ich den SAMBA Service neu, um die neuen Shares zu publizieren.
# Restart SMB systemctl restart smbd.service
openHAB 2 Initialkonfiguration
Nachdem alle Komponenten installiert und konfiguriert sind, geht es an die initiale Konfiguration von OpenHAB 2. Dazu rufe ich über einen Browser die OpenHAB 2 Server URL https://<OpenHAB-Server>:8443
auf und installiere folgende UIs:
- PaperUI
- Classic UI
- HABmin
- HABPanel
openHAB 2 Konsole (Karaf)
Neben den Web UIs verfügt openHAB 2 auch über eine Command Line Konsole. Standardmäßig ist ein Zugriff darauf nur über den lokalen Server selbst möglich. Ein Remote Zugriff wird nicht zugelassen. Um die Konsole auch von einem externen Client aus aufzurufen, ist die Datei $OPENHAB_CONF$/services/runtime.cfg
anzupassen. Der für den Zugriff verwendete Parameter lautet:
org.apache.karaf.shell:sshHost = 0.0.0.0
Der Parameter ist standardmäßig auskommentiert. Um den Remote Zugriff zu aktivieren, entferne ich lediglich die Auskommentierung (#
) vor dem Parameter.
Da die Freischaltung des Remote Zugriffs natürlich ein Sicherheitsthema ist, sollte zwingend das Passwort für den User openhab
(Standardpasswort: habopen
) geändert werden:
sudo sed -i -e "s/openhab = .*,/openhab = <Passwort>,/g" /var/lib/openhab2/etc/users.properties
Ein weiteres ToDo um die Sicherheit nach der Freischaltung des Remote Zugriffs wieder zu erhöhen ist es, den Port der Karaf Konsole von deren Standard-Port 8101 auf einen alternativen Port zu ändern. Diesen passe ich wie folgt an:
sudo sed -i -e "s/sshPort = .*/sshPort = <Port>/g" /var/lib/openhab2/etc/org.apache.karaf.shell.cfg
Auch für die Änderung der Username/Passwort Kombination und des Ports ist ein Neustart des openHAB 2 Services erforderlich.
openHAB 2 Konfigurationsdateien
openHAB bietet mehrere Konfigurationsschnittstellen mit unterschiedlichem Funktionsumfang (siehe hier). Vor dem Start der eigentlichen Einrichtung sollte man sich Gedanken machen, welche Konfiguration man verwendet. Ich habe mich primär für Paper UI und Text-File basierte Konfiguration entschieden. Paper UI verwende ich ausschließlich zur Konfiguration von Systemeinstellungen und zur Installation von Add-ons. Zwar bietet die Paper UI eine recht nützliche Autodiscover Funktion, allerdings speichert Paper UI die Things und Items nicht in Text-File Konfigurationen, sondern in einer internen Json Datenbank (System-Side-Database). Mir persönlich liegt es, die komplette Konfiguration an einem Speicherort zu haben. Daher konfiguriere ich alle Things, Items, Rules, Sitemaps, etc. per Visual Studio Code mit Text-Files. Das ist etwas aufwändiger, hilft mir allerdings, die Übersicht über die Gesamtkonfiguration zu behalten.
Als nächstes mache ich mir Gedanken, wie ich meine Konfigurationsdateien aufbauen will. Auf folgende Punkte habe ich mich dabei festgelegt:
Namenskonvention
- Groß-/Kleinschreibung:
- things: meine Things schreibe ich alle komplett klein, also z.B.:
ntp:ntp:internal
- items: meine Items schreibe ich mit Großbuchstaben am Wortanfang, also z.B.:
Groundfloor_Livingroom_Light_1
- things: meine Things schreibe ich alle komplett klein, also z.B.:
- Sprache:
- things/items: meine Things/Items, sowie das Label dazu, definiere ich in Englisch
- sitemaps: erst in den Sitemaps definiere ich die deutschen Labels, die dann auch in den Control UIs angezeigt werden
- Labels:
- things/items: in den Labels der Things/Items wähle ich lange, aussagekräftige Namen, aus denen das Binding sowie der Zweck des Things/Items deutlich hervorgeht, z.B.:
"Hue Light: Livingroom Light 1 Color Temperature"
oder"Weather Data (Current): Barometric Pressure [%.1f %unit%]"
- things/items: in den Labels der Things/Items wähle ich lange, aussagekräftige Namen, aus denen das Binding sowie der Zweck des Things/Items deutlich hervorgeht, z.B.:
- Icons:
- Für Icons verwende ich einen ausschließlich klein geschriebenen Dateinamen. Zudem sind Icons nach dem Binding (oder einer Kurzversion davon) benannt, um sie zuordnen zu können, z.B.:
astro_moon.png
. Icons, die keinem Binding zuzuordnen sind, benenne ich nach ihrem Einsatzgebiet, z.B. für Zimmer-Icons in der Sitemap:sitemap_livingroom.png
.
- Für Icons verwende ich einen ausschließlich klein geschriebenen Dateinamen. Zudem sind Icons nach dem Binding (oder einer Kurzversion davon) benannt, um sie zuordnen zu können, z.B.:
Labels/Icons
Sowohl in .items Dateien, als auch .sitemap Dateien können das Label (Anzeigename), als auch das Icon konfiguriert werden, welches in den UIs angezeigt wird. Natürlich muss man jedoch nicht alles doppelt angeben, es reicht, sich für eine Variante (oder eine Kombination) zu entscheiden.
Ich habe mich trotzdem für die „doppelte“ Arbeit entschieden und konfiguriere Label und Icon in beiden Dateien. Allerdings mit ein paar Unterschieden. Die Labels in den .item Dateien dienen nur der Übersichtlichkeit/Nachvollziehbarkeit der Items und sind eher ein Kommentar, bzw. dienen der Anzeige in den UIs. Außerdem ist das Label in den Items in Englischer Sprache verfasst. Das eigentliche Label für die Sitemaps in Deutsch konfiguriere ich in den .sitemap Dateien. Bei den Icons ist es ähnlich. In den .item Dateien konfiguriere ich oftmals lediglich ein Standard-Icon, damit etwas sinnvolles angezeigt wird. Meine Custom Icons konfiguriere ich erst in den .sitemap Dateien.
Dynamische Icons
openHAB unterstütz auch die Verwendung von eigenen Icons im PNG oder SVG Format. Generell reicht 1 Icon pro Verwendungszweck (also z.B. „kodi.png“ für Kodi Media Player). Unterstützt werden allerdings auch dynamisch angezeigte Icons anhand eines Status oder eines Prozentwerts. Hier einige Beispiele:
- Status
- Statusabhängige Icons folgen folgender Namenskonvention:
<Iconname>-<Status>.<Dateityp>
, z.B.:- Licht Status
- Licht allgemein:
light.png
- Licht Status = ON:
light-on.png
- Licht Status = OFF:
light-off.png
- Icon-Angabe in Items:
<light>
- Icon-Angabe in Sitemaps:
icon="light"
- Licht allgemein:
- Fehler Status
- Fehler allgemein:
error.png
- Fehler Status = NO_FAULT:
error-no_fault.png
- Icon-Angabe in Items:
<error>
- Icon-Angabe in Sitemaps:
icon="error"
- Fehler allgemein:
- Licht Status
- Statusabhängige Icons folgen folgender Namenskonvention:
- Zahlenzwerte
- Zahlenwertabhängige Icons dienen z.B. der Darstellung von Prozenzwerten und folgen folgender Namenskonvention:
<Iconname>-<Unterer_Wert>.<Dateityp>
, z.B.:- Dimmer Status (analog dazu z.B. auch Batterie Status)
- Dimmer allgemein =
dimmer.png
- Dimmer 0% (aus) =
dimmer-0.png
- Dimmer 1-24% =
dimmer-1.png
- Dimmer 25%-49% =
dimmer-25.png
- Dimmer 50%-74% =
dimmer-50.png
- Dimmer 75%-100% =
dimmer-75.png
- Icon-Angabe in Items:
<dimmer>
- Icon-Angabe in Sitemaps:
icon="dimmer"
- Die Schritte lassen sich beliebig definieren (z.B. auch in 10er Schritten, etc.)
- Dimmer allgemein =
- Dimmer Status (analog dazu z.B. auch Batterie Status)
- Zahlenwertabhängige Icons dienen z.B. der Darstellung von Prozenzwerten und folgen folgender Namenskonvention:
Sitemap: home.sitemap
Als nächstes erstelle ich mir eine Sitemap home.sitemap
. Die Sitemap definiere ich als Default Sitemap in der openHAB Paper UI für die Classic UI und Basic UI.
In die Sitemap konfiguriere ich im ersten Schritt das Grundgerüst meiner Sitemap (Etagen/Räume/etc.). Da ja im jetzigen Zustand teilweise benötigte Things/Items noch nicht existieren, wird das Gerüst erst in den nächsten Schritten ausgebaut/vervollständigt und um alle Komponenten der Hausautomatisierung erweitert. Das Grundgerüst dient nur dem Zweck, sich schon mal Gedanken zu machen, wie die Sitemap strukturiert sein soll. Der Großteil der Sitemap besteht aus Frames (also Abschnitten) und Textelementen.
sitemap home label="Home Control" { Frame label="Datum" { Text item=Date label="Datum/Uhrzeit" icon="time" } Frame label="Gewerke/Schnellzugriff" { Text item=Lights label="Beleuchtung" icon="lightbulb" Text item=Heating label="Heizung" icon="radiator" } Frame label="Etagen/Räume" { Text item=Groundfloor label="Erdgeschoss" icon="groundfloor" { Text item=Groundfloor_Livingroom label="Wohnzimmer" icon="sofa" Text item=Groundfloor_Bedroom label="Schlafzimmer" icon="bedroom" Text item=Groundfloor_Wardrobe label="Diele" icon="wardrobe" Text item=Groundfloor_Kitchen label="Küche" icon="kitchen" Text item=Groundfloor_Bathroom label="Badezimmer" icon="bath" } Text item=Basement label="Untergeschoss" icon="cellar" { Text item=Basement_Floor label="Keller/Gang" icon="corridor" Text item=basement_Hobbyroom label="Hobbyraum/Büro" icon="office" } Text item=Outdoor label="Außenbereich" icon="garden" { Text item=Outdoor_Terrace label="Terrasse" icon="terrace" Text item=Outdoor_Garden label="Garten" icon="lawnmower" } } Frame label="Wetter" { Text item=Weather label="Wetter" icon="sun_clouds" Text item=Astro label="Astronomische Daten" icon="sunrise" } Frame label="Sonstiges" { Group item=Presence label="Anwesenheit" icon="presence" Group item=Monitoring label="Monitoring" icon="network" } }
Randnotiz: Darstellung von Werten in der Sitemap
In der o.g. initialen Sitemap werden noch keine Werte und/oder Stati angezeigt. Diese werden dann später i.d.R. durch Variablen deklariert, z.B. Lautstärke. Wichtig dabei ist zu verstehen, für welchen Item-Typ welche Variable zu nutzen ist. Das orientiert sich zum größten Teil an den Typen der Java Klassenformatierung.
Einfache Beispiele dafür sind:
- String/Text: [%s] -> gibt einen einfachen Textwert aus
- Number/Zahl: [%d] [%d %%] -> gibt eine einfach Zahl aus, bzw. eine Zahl mit Prozent
Komplizierter wird’s dann bei Werten, die in einem bestimmten Format ausgegeben werden sollen, z.B.:
- Number/Temperatur: [%.1f °C] -> gibt die Temperatur mit 1 Nachkommastelle an
- Location/Koordinaten: [%2$s°N %3$s°O %1$sm] -> gibt die Koordinaten Nord mit 2 Stellen und 2 Nachkommastellen an, die Koordinate Ost mit 3 Stellen und 2 Nachkommastellen, sowie die Höhe über Normalnull ohne Nachkommastelle in Metern an.
Update 20.12.2019: Upgrade von openHAB 2.4.0 auf openHAB 2.5.0
Im Dezember 2019 war es noch kurz vor Weihnachten soweit: openHAB 2.5 wurde veröffentlicht. Das Update habe ich wie in den folgenden Zeilen beschrieben durchgeführt.
Upgrade openHAB 2
Das Upgrade des openHAB 2 Cores muss im Gegensatz zur den Addons (siehe unten) manuell angestoßen und durchgeführt werden:
sudo -i apt-get install openhab2=2.5.0-1
Sollte das Upgrade unterbrochen werden (bei mir ist das passiert, weil ich die alte und neue runtime.cfg vergleichen wollte und aus dem Vergleich nicht mehr rausgekommen bin), lässt sich das Setup wie folgt fortsetzen:
dpkg --configure -a
Upgrade openHAB 2 Addons
Die openHAB 2 Addons aktualisieren sich während der „normalen“ Update Installation mit:
sudo -i apt-get update apt-get upgrade
Version-Check
Nach dem Upgrade lässt sich das erfolgreiche Update wie folgt prüfen:
dpkg --list | grep openhab2
War das Upgrade erfolgreich, sieht die Ausgabe wie folgt aus:
ii openhab2 2.5.0-1 all openhab2 ii openhab2-addons 2.5.0-1 all openhab2-addons
Update 02.02.2020/07.02.2020/28.03.2020/19.05.2020/23.06.2020/30.07.2020/30.10.2020:
Upgrade von openHAB 2.5.0 auf openHAB 2.5.x
Upgrade openHAB 2 & openHAB 2 Addons
Im Gegensatz zur Major Release lässt sich der Patch Release inkl. Addons per normalem Update des Systems installieren.
sudo -i apt-get update apt-get upgrade
Version-Check
Nach dem Upgrade lässt sich das erfolgreiche Update wie folgt prüfen:
dpkg --list | grep openhab2
War das Upgrade erfolgreich, sieht die Ausgabe wie folgt aus.
Nach dem Update auf 2.5.1:
ii openhab2 2.5.1-2 all openhab2 ii openhab2-addons 2.5.1-2 all openhab2-addons
Nach dem Update auf 2.5.2:
ii openhab2 2.5.2-1 all openhab2 ii openhab2-addons 2.5.2-1 all openhab2-addons
Nach dem Update auf 2.5.3:
ii openhab2 2.5.3-1 all openhab2 ii openhab2-addons 2.5.3-1 all openhab2-addons
Nach dem Update auf 2.5.4:
ii openhab2 2.5.4-1 all openhab2 ii openhab2-addons 2.5.4-1 all openhab2-addons
Nach dem Update auf 2.5.5:
ii openhab2 2.5.5-1 all openhab2 ii openhab2-addons 2.5.5-1 all openhab2-addons
Nach dem Update auf 2.5.6:
ii openhab2 2.5.6-2 all openhab2 ii openhab2-addons 2.5.6-2 all openhab2-addons
Nach dem Update auf 2.5.7:
ii openhab2 2.5.7-1 all openhab2 ii openhab2-addons 2.5.7-1 all openhab2-addons
Nach dem Update auf 2.5.8:
ii openhab2 2.5.8-1 all openhab2 ii openhab2-addons 2.5.8-1 all openhab2-addons
Nach dem Update auf 2.5.9:
ii openhab2 2.5.9-1 all openhab2 ii openhab2-addons 2.5.9-1 all openhab2-addons
Nach dem Update auf 2.5.10:
ii openhab2 2.5.10-1 all openhab2 ii openhab2-addons 2.5.10-1 all openhab2-addons
Quellen:
https://www.openhab.org/
Auch hier wieder vielen Dank für deine Ausführungen!
Nach dem ich gestern OpenWeatherMap und das Astro-Binding in mein openHAB eingebaut habe wollte ich mich nun an Dynamischen Icons versuchen. Auf der Suche nach SVG Icons habe ich viele Seiten gefunden auf denen man Icons kostenlos runter laden kann. Leider meist mühselig einzeln. Hast du einen Tipp wo ich Sets finde zB für die Darstellung der Mondphasen?
Oder gibt es eine allgemeine Plattform für openHAB Icons (für diverse Bereiche) die ich bis jetzt nur nicht gefunden habe?
Gruß
David
Servus und danke für dein Feedback.
Icons sind bei mir auch problematisch. Habe mir die auch mühsam zusammengesucht, wobei ich aber PNGs verwende, da ist die Auswahl größer.
Für Astro hab ich leider nichts, aber für Wettter gibt’s hier eine Seite, mit dynamischen SVGs (https://github.com/bramkragten/weather-card/tree/master/icons/animated). Ist zwar für Home Assistant, aber passt bestimmt auch für openHAB.
Gruß
Andreas
Dank Dir … das ist ja schon mal was 😉