Kernfrage: wo kann ich gute Tutorials für Openhabian finden, die sich speziell auf Debian (auf "normaler" x86-Plattform) beziehen, anstatt eine Installation auf einem Raspi vorauszusetzen, und die speziell auch auf ZigBee eingehen?
Verwendete Hardware:
Thinclient Igel M340C, derzeit 2GB RAM, 2GB SSD.
ZigBee: per Sonoff ZigBee 3.0 USB Dongle Plus-E.
Installiertes System:
Debian stable, auf USB-Stick installiert, mangels zu kleiner SSD. Aufrüstung der Thinclient -HW ist geplant, ist vor allem ein physisches Platzproblem.
-----
Nun die lange Version, mit einigen konkreteren Fragen. Ich versuche derzeit, die Thematik besser zu verstehen.
Moin, zuerst eine kurze Vorstellung.
Bin Micha aus Chemnitz, derzeit Mitte 40. Ich war mit Linux relativ vertraut ab Ende 90er bis vor ca 10 Jahren. Ab dann war ich mehr und mehr ein DAU, ich habe ein wenig den Anschluss verloren.
Die Smarthome- Thematik finde ich interessant und habe begonnen, mir testweise ein paar Lampen und weitere Geräte zuzulegen. (ZigBee)
Ich bin aber ganz schnell an die Grenzen der proprietären Hersteller-Lösungen geraten, was ich alles andere als "smart" empfinde.
Daher habe ich nun einen Versuch gestartet, mich per Opensource dem Thema zu widmen.
Momentan versuche ich, per Openhabian diese Geräte zu steuern.
Leider sind die meisten Tutorials auf Englisch, was es für mich deutlich schwieriger macht, die Philosophie hinter Openhabian zu verstehen.
(Ich verstehe zum Beispiel nicht ganz die Definition der verschiedenen Openhabian-Objekte. Das ist für mich derzeit zu abstrakt, ich brauche vermutlich einfach ein paar gute konkrete Anwendungsbeispiele, möglichst ähnlich zu der Hardware und Software, die ich verwende (wesentliche Faktoren sind hier vermutlich "kein Raspi", "Debian" und "ZigBee" ))
Ein zweites Problem ist, dass die meisten Anleitungen voraussetzen, dass man Openhabian auf einem Raspberry installiert hat. So ein Gerät besitze ich bisher nicht, und bekanntlich sind diese derzeit auch sehr schlecht zu bekommen und völlig überteuert.
Stattdessen habe ich auf dem refurbished -Markt einen Thinclient erworben, ein Igel M340C.
Da ich davon ausgehe, dass es mehr und mehr User gibt, die aus ähnlichen Gründen nach Raspi-Alternativen suchen und ausprobieren, habe ich die Hoffnung, dass es auch mehr Anleitungen gibt
Soweit bin ich bisher gekommen:
Debian läuft,
Openhabian 3 ist installiert,
ein MQTT Broker läuft.
Ich habe den ZigBee Dongle zum Laufen gebracht und konnte auch mehrere Geräte damit verbinden.
Ich habe also ein paar Things anlegen können.
Das sind im Einzelnen eine Steckdose und ein Bewegungsmelder von Sonoff,
des weiteren eine Fernbedienung nebst LED-Lampe von Müller Licht (tint, Aldi).
Nun bin ich an dem Punkt angelangt, wo ich nur Bahnhof verstehe.
Ich verstehe nicht, wie ich es bewerkstelligen kann, dass eine Aktion an einem Gerät (zum Beispiel die Fernbedienung oder der Bewegungsmelder) etwas bewirkt bei anderen Geräten (zum Beispiel die Lampe oder die Steckdose)
Ich verstehe nicht mal, wie ich den jeweiligen Status einzelner Betriebszustände sehen bzw abfragen kann. Zum Beispiel, dass der Bewegungsmelder eine Veränderung registriert hat oder dass ein bestimmter Knopf der Fernbedienung betätigt wurde.
Oder wie ich Betriebszustände ändern kann, zum Beispiel Lichtfarbveränderungen der Lampe, Ein/Aus der Lampe.
Ich habe versucht, bei den einzelnen Things Channels anzulegen.
Nur bei der Steckdose scheint das was gebracht zu haben, ich kann sie über Openhabian manuell ein- und ausschalten.
Des weiteren konnte ich einen Channel des Bewegungsmelders verlinken, aber da passiert nix. Wenn ich "Analyze" aufrufe, sehe ich keine Änderungen im Status.
Ähnliches gilt für die Fernbedienung. Einen Channel konnte ich anlegen, der irgendwie ein "Dimmer" sein soll.
Andere sinnvolle Channels zeigt es nicht an.
Und bei der Lampe sehe ich auch nur zwei Channels, jeweils für die Änderung der Farbe, einmal deutsch, einmal Englisch.
Keine weiteren Channels, zum Beispiel für das Ein- und Ausschalten.
Die Fernbedienung wird übrigens meistens als "Offline" angezeigt, ohne weitere Fehlermeldung.
Das scheint sich einige Sekunden, nachdem ich Tasten betätigt habe, zu ändern, meistens nur auf "Unknown". Ich weiß nicht, ob das normal ist oder ob etwas falsch konfiguriert ist.
Hmm.
Ist das normal (dass so wenig Channels angezeigt werden) oder fehlt noch was wesentliches?
Kann ich irgendwo sehen, welche "Fähigkeiten " diese Things jeweils haben sollten?
Brauche ich vielleicht noch weitere Konfigurationsdaten bzw -dateien, die ich möglicherweise manuell hinzufügen muss?
Welche Openhabian -Werkzeuge sind zur Diagnose hilfreich? Welche Logs sind interessant? Wie kann ich am besten sehen, was "live" gerade passiert?
Und wie geht's dann weiter?
Wie "erkläre" ich den Geräten, was sie tun sollen?
Was genau sind zum Beispiel Channels, Profiles, Items, Models, Equipment? Am besten fände ich praxisbezogene Beispielerklärungen, damit es greifbarer wird, was gemeint ist. Sofern nur erklärt wird, wie sich diese einzelnen Begriffe jeweils zueinander verhalten, verstehe ich nur Bahnhof, weil dann der Anwendungsbezug völlig fehlt. (Ich brauche solche konkreten Bezüge zu Anwendungen (als Einstieg) , sonst bin ich mehr oder weniger gar nicht in der Lage, das zu verstehen. Das ist bei mir in allen Bereichen des Lebens so.)
Newbie-Probleme, Debian, ZigBee
-
udo1toni
- Beiträge: 13953
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Newbie-Probleme, Debian, ZigBee
Hallo Micha, willkommen im openHAB Forum!
Erst mal ganz zu Anfang: openHABian ist eine Scriptsammlung. Diese dient dazu, openHAB und diverse andere Software zu installieren.
openHABian ist KEIN Betriebssystem, und schon gar nicht exklusiv für den Raspberry. Pi.
openHABian ist NICHT die Software, die Du installiert hast.
openHABian ist momentan in Version 1.75 verfügbar, entweder vorinstalliert in einem Image (exklusiv für den Raspberry Pi) oder als kompakter Download von gerade mal 647 KByte, direkt von github als zip (oder alternativ auch mit git als Versionierungstool)
openHABian installiert, einmal von der Leine gelassen openHAB3.4.2 oder wahlweise auch openHAB2.5.12 (nur aus Kompatibilitätsgründen, nicht für Neueinsteiger empfohlen)
openHAB3 ist das, was Du recht durchgängig Openhabian nennst Mach Dir nichts draus, ist ein sehr gern genommener Fehler (und ich werde nicht müde ihn zu korrigieren...)
Keine Anleitung (jedenfalls keine mir bekannte) setzt zwingend einen Raspberry Pi als Plattform voraus. Es ist nur so, dass der Raspberry Pi seit etwa 7 Jahren eine etablierte Plattform für openHAB ist und vermutlich etwa 90 % der Installationen den Raspberry nutzen. openHAB selbst ist aber komplett in Java geschrieben, es setzt lediglich eine Java Engine voraus (abhängig von der Version von openHAB, openHAB1 lief unter Java 6 (glaube ich... ist halt schon ein paar Jährchen her), openHAB2 setzte Java 8 voraus, openHAB3 benötigt Java 11 und openHAB4 läuft unter Java 17. (openHAB4 ist kurz vor dem ersten Milestone, es ist momentan eher für Entwickler gedacht)
Wenn also nur die Installation auf einem Raspberry beschrieben ist, lass Dich davon nicht verunsichern. Das Gesagte gilt dann (fast) ohne Einschränkungen auch für jede andere Plattform, auf der openHAB läuft, sei es ein Windows, MacOS, GNU/Linux, FreeBSD , 32 Bit oder 64 Bit, es müssen nur ein paar Randbedingungen erfüllt sein, vor allem genug Arbeitsspeicher und ein robustes Laufwerk (openHAB schreibt quasi ohne Unterlass kleine Datenmengen auf den Speicher, womit vor allem Flash-Speicher (SD-Karten und gewöhnliche USB--Sticks) schwer zu kämpfen haben - Stichwort Wearout. Eine kleine SSD (notfalls ab 8 GByte aufwärts) ist besser als ein 32 GByte USB-Stick - es sei denn, er hätte einen "echten" Controller eingebaut (er verhält sich dann wie eine SSD, die auch in der Lage ist, die Schreibzugriffe gezielt über den gesamten Speicherplatz zu streuen und so die Speicherzellen "gleichmäßig" abzunutzen). Debian ist eine exzellente Plattform für openHAB - openHABian kann prima mit Debian verwendet werden, um openHAB und weitere Programme für die Heimautomation einzurichten.
Die offizielle Doku ist tatsächlich leider ausschließlich in englisch verfügbar, was es Einsteigern eventuell etwas schwer machen kann. Es gab für openHAB2 ein sehr gutes Buch von Marianne Spiller, leider gab es bisher keine Neuauflage für oppenHAB3 - und die Unterschiede sind zu groß, als dass man das Buch einem Neueinsteiger noch guten Gewissens empfehlen könnte.
Zu den Begrifflichkeiten innerhalb openHAB:
Die Anbindung externer Datenquellen - gleich welcher Art - erfolgt über sogenannte Bindings (oder salopp auch Addons) Unter openHAB3 stellt jedes Binding eine Art Things zur Verfügung. Ältere Versionen von openHAB unterstützen auch eine Andere Art der Konfiguration, dies stammt aus der openHAB1-Ära. Unter openHAB2 gab es dann ein spezielles Modul,m welches die alten Bindings nutzbar machte. Dieser Compatibility Layer (Kompatibilitäts-Schicht) ist in openHAB3 nicht mehr vorhanden. Wenn Du laos in älteren Anleitungen über Konfigurationsformen stolperst, die nicht über Things funktionieren, kannst Du diese Anlkeitung direkt überspringen.
Den nächsten Begriff habe ich damit schon eingeführt, das Thing. Ein Thing repräsentiert in openHAB ein Gerät. Damit ist erst mal "echte" Hardware gemeint, z.B. ein WLAN Zwischenstecker, oder eine HUE-Lampe, eine Wetterstation oder ein Dimmer, ein Auto, eine Kaffeemaschine, ein Fernseher usw. Es kann sich dabei aber auch um eine "gedachte" Hardware handeln, z.B. die Sonne, der Mond, die Wetterhorhersage, der Zugfahrplan, die Spritpreise einer Tankstelle... also allgemein Daten, die nicht unbedingt einem Gerät im Haushalt zuzuordnen sind...
Es gibt eine spezielle Form des Things, das ist die Bridge. Die Bridge konmmt überall dort zum Einsatz, wo es erwartungsgemäß mehrere Things geben könnte, welche über eine gemeinsame Schnittstelle angesprochen werden können, z.B. eine Zigbee Bridge, eine Homematic Bridge, eine knx Bridge usw. Oft gibt es innerhalb eines openHAB Systems nur eine Bridge für einen bestimmten Bus und alle Things die zu diesem Bus gehören, sind dann dieser einen Bridge zugeordnet. Man könnte aber durchaus auch mehrere Bridges des selben Typs verwenden, wenn das notwendig sein sollte.
Da ein Gerät (oder Thing...) oftmals mehrere Eigenschaften besitzt, hat jedes Thing einen oder mehrere Channel. Ein Channel ist eine einzelne Eigenschaft, z.B. bei dem oben zitierten WLAN Zwischenstecker der Schaltzustand. Ein weiterer Channel könnte dann die momentane Leistungsaufnahme sein, die Qualität des WLAN Signals usw.
Es gibt verschiedene Channeltypen, die abhängig vom Thing Typ sind, z.B. switch, number, rollershutter, dimmer, string... was man halt so braucht.
Bis zu diesem Punkt befinden wir uns bei openHAB immer noch auf einer hardwarebezogenen Ebene. Die Konfiguration ist hochgradig abhängig von der Art der verwendeten Hardware, auch wenn versucht wird, zumindest wo es geht, die Konfiguration zu vereinheitlichen. Aber ein per MQTT gesteuertes Gerät erwartet nun mal Topics, während ein KNX-Gerät über Gruppenadressen kommuniziert. Jeder Hersteller (oder besser jedes Protokoll) hat spezifische Eigenschaften, die individuell abgebildet werden müssen. Das geschieht mit den Things und den Channels.
Die Channel haben allerdings eine recht begrenzte Form, da es sich um einzelne Datenpunkte handelt, z.B. der Zeitpunkt des nächsten Sonnenaufgangs, das aktuelle Sternzeichen, die Menge an Haselnuss Pollen, der aktuelle Börsenkurs von Apple...
All das kommt mit einer sehr begrenzten Datenform aus, entweder es ist eine Zahl, ein Text, ein Datum (mit Uhrzeit), oder auch - es geht ja um Heimautomation - die Stellung des Rollladens, die Helligkeit der Lampe, die Schaltstellung der Steckdose, die Raumtemperatur (Soll/Ist) und ein paar Arten mehr.
Nun kommen die Daten ins eiugentliche "Herz" von openHAB, auf den openHAB Bus (das B steht für Bus). Auf diesem Bus sind die Werte nicht mehr hardwareabhängig. Es ist egal, ob eine Leuchte über MQTT, Zigbee, Z-Wave, Homeamtic oder knx gesteuert wird. Am Ende des Tages kann man sie ein- und ausschalten, vielleicht noch die Helligkeit oder gar die Farbe wählen, aber das war es dann. Diese Steuerung geschieht auf dem dem openHAB Bus, und sie ist völlig losgelöst von der Hardware. Diese Abstraktionsschicht ermöglicht erst, dass verschiedenste zueinander völlig inkompatible Systeme miteinander gemeinsam arbeiten können.
Alle Werte, die über die Channel in openHAB eintrudeln, können in Items gespeichert werden. Channel und Items sind sich sehr ähnlich, denn Items entsprechen eben auch einer einzelnen Eigenschaft. Nur eben nicht mehr hardwarebezogen.
Deshalb kann man in der UI (UserInterface - Benutzerschnittstelle) von openHAB ganz unabhängig von der verwendeten Hardware immer das gleiche Widget (äh... Schaltelement - Google liefert treffenderweise "Dingsbums" als Übersetzung
) verwenden, also z.B. eine Schaltfläche zum Schalten einer Lampe, egal, was das nun für eine Lampe ist.
Das Widget steuert das Item und zeigt dessen Zustand an. Das Item sendet den erhaltenen Befehl an den verknüpften Channel, der es über das Thing an das Binding weiterleitet, welches den Befehl über das entsprechende Steuerprotokoll an die eigentliche Hardware sendet. Die Hardware führt den Befehl aus und meldet den neuen Zustand über das Steuerprotokoll an das Binding, welches es an den Channel weiterleitet, der den Zustand des Items entsprechend anpasst, woraufhin das Widget den neuen Zustand anzeigt.
Es gibt verschiedene UIs für den Endanwender von openHAB - zur Konfiguration gibt es unter openHAB3 aber ausschließlich die Main UI. Findest Du eine Anleitung, in der von Paper UI die Rede ist, dann bezieht sich diese Anleitung auf oopenHAB2, dort hieß die Oberfläche so.
Als Oberflächen stehen neben der Main UI mit ihren Page nnoch die Basic UI und HABPanel zur Verfügung. Wer mag, kann auch noch Comet Visu verwenden (uralt, aber es gibt sicher Leute, die diese Eigenschaft von openHAB lieben). Man könnte grundsätzlich auch eine komplett eigene Visu entwickeln, dürfte aber eine Menge Arbeit sein. Für das Smartphone (Android/iOS) gibt es Apps, die zumindest Basic UI und Main UI anzeigen können.
Als weiteres wichtiges Element gibt es noch die Rules, mit denen sich Dinge automatisieren lassen. Erst Rules können aus einer Bedienoberfläche für computersteuerbare Geräte eine Smarthome Zentrale machen, die diesen Namen auch verdient.
Als einfachste Form mag die Rollladensteuerung gelten, welche stumpf zu einer bestimmten Uhrzeit die Läden öffnet und zu einer anderen Zeit wieder schließt. Das lässt sich noch ganz gut mit einer Zeitschaltuhr erledigen. Soll das ganze sonnenstandsgeführt sein (öffne kurz vor Sonnenaufgang, schließe bei bürgerlicher Dämmerung), wird es schnell eng bei konventionellen Steuerungen, zentral für alle Läden einer Gebäudeseite für Beschattung, andere Zeiten für Schlafräume, spezielle Zeiten für das Wochenende, Berücksichtigung der Schulferien und beweglichen Feiertage, Beschattung erst bei mehr als 23 °C, aber nur, wenn der Himmel nicht bewölkt ist... geht nur noch über eine passende Steuersoftware, konventionell nur nach Einwurf einer größeren Menge großer Geldscheine, aber nur vom Elektriker parametrierbar, der bei jeder Änderung die Hand aufhält...
Ein lustiges Beispiel ist auch die vollautomatische Weihnachtsbeleuchtung, welche pünktlich in der ersten Adventswoche beginnt und bis Mariä Lichtmess regelmäßig bei Einbruch der Dunkelheit bis 22 Uhr angeht, genauso wie morgens ab 6 Uhr bis es hell wird...
All das geht über die geschickte Verknüpfung von Ereignissen und Zuständen, welche auf dem openHAB Bus auftreten oder dort gespeichert sind.
Es gibt mitgeliefert drei verschiedene Programmieransätze in openHAB3, das ist die DSL (DomainSpecificLanguage - aufgabenspezifische Sprache), JavaScript udn Blockly (welches letztlich JavaScript Code erzeugt) - andere Programmiersprachen sind möglich und werden auch aktiv eingebaut, das meiste sind aber Nischenprodukte Ich persönlich bevorzuge die DSL, weil ich ein alter openHAB Hase bin seit OH1.0 dabei und da geb es nur das. Die DSL ist auf die Anwendung openHAB optimiert und es gibt eigentlich kein Steuerungsproblem, welches damit nicht lösbar ist - in vielen Fällen extrem elegant, was natürlich ein tiefes Verständnis der Zusammenhänge in openHAB voraussetzt. In den diversen Foren zu openHAB gibt es zehntausende Programmbeispiele, viele gute Lösungen, noch viel mehr Mist aber man kann viel über das System lernen, wenn man sich etwas intensiver mit den Rules beschäftigt.
Und noch ein Element ist die Persistence. Unter Persistenz versteht man allgemein das Speichern von Zuständen über einen beliebigen Zeitraum. Im Zusammenhang mit Hausautomation sind da vor allem Messreihen interessant (Temperaturverlauf verschiedener Sensoren, die im und ums Haus verteilt sind, Kesseltemperatur, Stromverbrauch usw.) MAn kann diese Daten in openHAB verwenden, um hübsche Charts zu erstellen, aber auch um z.B. Durchschnittswerte zu errechnen und anzuzeigen. Außerdem kann man die Persistence dazu verwenden, dass Schaltzustände über einen Neustart hinaus erhalten bleiben, wenn es außerhalb openHAB dafür keinen Speicher gibt. Ich habe z.B. einen Schalter, wenn jemand bei mir im Wohnzimmer übernachten will, damit die Rollläden nicht direkt bei Sonnenaufgang aufgehen. Der Schalter existiert aber nur in openHAB, also muss sich openHAB den Schaltzustand selbst merken - im Gegensatz zum Zustand des Lichts, da kann es über den Bus nachfragen, ob das Licht gerade an oder aus ist.
Das ist vielleicht ein erster kurzer Abriss über openHAB und einige Details - es gibt viel zu entdecken...
Erst mal ganz zu Anfang: openHABian ist eine Scriptsammlung. Diese dient dazu, openHAB und diverse andere Software zu installieren.
openHABian ist KEIN Betriebssystem, und schon gar nicht exklusiv für den Raspberry. Pi.
openHABian ist NICHT die Software, die Du installiert hast.
openHABian ist momentan in Version 1.75 verfügbar, entweder vorinstalliert in einem Image (exklusiv für den Raspberry Pi) oder als kompakter Download von gerade mal 647 KByte, direkt von github als zip (oder alternativ auch mit git als Versionierungstool)
openHABian installiert, einmal von der Leine gelassen openHAB3.4.2 oder wahlweise auch openHAB2.5.12 (nur aus Kompatibilitätsgründen, nicht für Neueinsteiger empfohlen)
openHAB3 ist das, was Du recht durchgängig Openhabian nennst
Mach Dir nichts draus, ist ein sehr gern genommener Fehler (und ich werde nicht müde ihn zu korrigieren...)Keine Anleitung (jedenfalls keine mir bekannte) setzt zwingend einen Raspberry Pi als Plattform voraus. Es ist nur so, dass der Raspberry Pi seit etwa 7 Jahren eine etablierte Plattform für openHAB ist und vermutlich etwa 90 % der Installationen den Raspberry nutzen. openHAB selbst ist aber komplett in Java geschrieben, es setzt lediglich eine Java Engine voraus (abhängig von der Version von openHAB, openHAB1 lief unter Java 6 (glaube ich... ist halt schon ein paar Jährchen her), openHAB2 setzte Java 8 voraus, openHAB3 benötigt Java 11 und openHAB4 läuft unter Java 17. (openHAB4 ist kurz vor dem ersten Milestone, es ist momentan eher für Entwickler gedacht)
Wenn also nur die Installation auf einem Raspberry beschrieben ist, lass Dich davon nicht verunsichern. Das Gesagte gilt dann (fast) ohne Einschränkungen auch für jede andere Plattform, auf der openHAB läuft, sei es ein Windows, MacOS, GNU/Linux, FreeBSD , 32 Bit oder 64 Bit, es müssen nur ein paar Randbedingungen erfüllt sein, vor allem genug Arbeitsspeicher und ein robustes Laufwerk (openHAB schreibt quasi ohne Unterlass kleine Datenmengen auf den Speicher, womit vor allem Flash-Speicher (SD-Karten und gewöhnliche USB--Sticks) schwer zu kämpfen haben - Stichwort Wearout. Eine kleine SSD (notfalls ab 8 GByte aufwärts) ist besser als ein 32 GByte USB-Stick - es sei denn, er hätte einen "echten" Controller eingebaut (er verhält sich dann wie eine SSD, die auch in der Lage ist, die Schreibzugriffe gezielt über den gesamten Speicherplatz zu streuen und so die Speicherzellen "gleichmäßig" abzunutzen). Debian ist eine exzellente Plattform für openHAB - openHABian kann prima mit Debian verwendet werden, um openHAB und weitere Programme für die Heimautomation einzurichten.
Die offizielle Doku ist tatsächlich leider ausschließlich in englisch verfügbar, was es Einsteigern eventuell etwas schwer machen kann. Es gab für openHAB2 ein sehr gutes Buch von Marianne Spiller, leider gab es bisher keine Neuauflage für oppenHAB3 - und die Unterschiede sind zu groß, als dass man das Buch einem Neueinsteiger noch guten Gewissens empfehlen könnte.
Zu den Begrifflichkeiten innerhalb openHAB:
Die Anbindung externer Datenquellen - gleich welcher Art - erfolgt über sogenannte Bindings (oder salopp auch Addons) Unter openHAB3 stellt jedes Binding eine Art Things zur Verfügung. Ältere Versionen von openHAB unterstützen auch eine Andere Art der Konfiguration, dies stammt aus der openHAB1-Ära. Unter openHAB2 gab es dann ein spezielles Modul,m welches die alten Bindings nutzbar machte. Dieser Compatibility Layer (Kompatibilitäts-Schicht) ist in openHAB3 nicht mehr vorhanden. Wenn Du laos in älteren Anleitungen über Konfigurationsformen stolperst, die nicht über Things funktionieren, kannst Du diese Anlkeitung direkt überspringen.
Den nächsten Begriff habe ich damit schon eingeführt, das Thing. Ein Thing repräsentiert in openHAB ein Gerät. Damit ist erst mal "echte" Hardware gemeint, z.B. ein WLAN Zwischenstecker, oder eine HUE-Lampe, eine Wetterstation oder ein Dimmer, ein Auto, eine Kaffeemaschine, ein Fernseher usw. Es kann sich dabei aber auch um eine "gedachte" Hardware handeln, z.B. die Sonne
, der Mond, die Wetterhorhersage, der Zugfahrplan, die Spritpreise einer Tankstelle... also allgemein Daten, die nicht unbedingt einem Gerät im Haushalt zuzuordnen sind...Es gibt eine spezielle Form des Things, das ist die Bridge. Die Bridge konmmt überall dort zum Einsatz, wo es erwartungsgemäß mehrere Things geben könnte, welche über eine gemeinsame Schnittstelle angesprochen werden können, z.B. eine Zigbee Bridge, eine Homematic Bridge, eine knx Bridge usw. Oft gibt es innerhalb eines openHAB Systems nur eine Bridge für einen bestimmten Bus und alle Things die zu diesem Bus gehören, sind dann dieser einen Bridge zugeordnet. Man könnte aber durchaus auch mehrere Bridges des selben Typs verwenden, wenn das notwendig sein sollte.
Da ein Gerät (oder Thing...) oftmals mehrere Eigenschaften besitzt, hat jedes Thing einen oder mehrere Channel. Ein Channel ist eine einzelne Eigenschaft, z.B. bei dem oben zitierten WLAN Zwischenstecker der Schaltzustand. Ein weiterer Channel könnte dann die momentane Leistungsaufnahme sein, die Qualität des WLAN Signals usw.
Es gibt verschiedene Channeltypen, die abhängig vom Thing Typ sind, z.B. switch, number, rollershutter, dimmer, string... was man halt so braucht.
Bis zu diesem Punkt befinden wir uns bei openHAB immer noch auf einer hardwarebezogenen Ebene. Die Konfiguration ist hochgradig abhängig von der Art der verwendeten Hardware, auch wenn versucht wird, zumindest wo es geht, die Konfiguration zu vereinheitlichen. Aber ein per MQTT gesteuertes Gerät erwartet nun mal Topics, während ein KNX-Gerät über Gruppenadressen kommuniziert. Jeder Hersteller (oder besser jedes Protokoll) hat spezifische Eigenschaften, die individuell abgebildet werden müssen. Das geschieht mit den Things und den Channels.
Die Channel haben allerdings eine recht begrenzte Form, da es sich um einzelne Datenpunkte handelt, z.B. der Zeitpunkt des nächsten Sonnenaufgangs, das aktuelle Sternzeichen, die Menge an Haselnuss Pollen, der aktuelle Börsenkurs von Apple...
All das kommt mit einer sehr begrenzten Datenform aus, entweder es ist eine Zahl, ein Text, ein Datum (mit Uhrzeit), oder auch - es geht ja um Heimautomation - die Stellung des Rollladens, die Helligkeit der Lampe, die Schaltstellung der Steckdose, die Raumtemperatur (Soll/Ist) und ein paar Arten mehr.
Nun kommen die Daten ins eiugentliche "Herz" von openHAB, auf den openHAB Bus (das B steht für Bus). Auf diesem Bus sind die Werte nicht mehr hardwareabhängig. Es ist egal, ob eine Leuchte über MQTT, Zigbee, Z-Wave, Homeamtic oder knx gesteuert wird. Am Ende des Tages kann man sie ein- und ausschalten, vielleicht noch die Helligkeit oder gar die Farbe wählen, aber das war es dann. Diese Steuerung geschieht auf dem dem openHAB Bus, und sie ist völlig losgelöst von der Hardware. Diese Abstraktionsschicht ermöglicht erst, dass verschiedenste zueinander völlig inkompatible Systeme miteinander gemeinsam arbeiten können.
Alle Werte, die über die Channel in openHAB eintrudeln, können in Items gespeichert werden. Channel und Items sind sich sehr ähnlich, denn Items entsprechen eben auch einer einzelnen Eigenschaft. Nur eben nicht mehr hardwarebezogen.
Deshalb kann man in der UI (UserInterface - Benutzerschnittstelle) von openHAB ganz unabhängig von der verwendeten Hardware immer das gleiche Widget (äh... Schaltelement - Google liefert treffenderweise "Dingsbums" als Übersetzung
) verwenden, also z.B. eine Schaltfläche zum Schalten einer Lampe, egal, was das nun für eine Lampe ist.Das Widget steuert das Item und zeigt dessen Zustand an. Das Item sendet den erhaltenen Befehl an den verknüpften Channel, der es über das Thing an das Binding weiterleitet, welches den Befehl über das entsprechende Steuerprotokoll an die eigentliche Hardware sendet. Die Hardware führt den Befehl aus und meldet den neuen Zustand über das Steuerprotokoll an das Binding, welches es an den Channel weiterleitet, der den Zustand des Items entsprechend anpasst, woraufhin das Widget den neuen Zustand anzeigt.
Es gibt verschiedene UIs für den Endanwender von openHAB - zur Konfiguration gibt es unter openHAB3 aber ausschließlich die Main UI. Findest Du eine Anleitung, in der von Paper UI die Rede ist, dann bezieht sich diese Anleitung auf oopenHAB2, dort hieß die Oberfläche so.
Als Oberflächen stehen neben der Main UI mit ihren Page nnoch die Basic UI und HABPanel zur Verfügung. Wer mag, kann auch noch Comet Visu verwenden (uralt, aber es gibt sicher Leute, die diese Eigenschaft von openHAB lieben). Man könnte grundsätzlich auch eine komplett eigene Visu entwickeln, dürfte aber eine Menge Arbeit sein. Für das Smartphone (Android/iOS) gibt es Apps, die zumindest Basic UI und Main UI anzeigen können.
Als weiteres wichtiges Element gibt es noch die Rules, mit denen sich Dinge automatisieren lassen. Erst Rules können aus einer Bedienoberfläche für computersteuerbare Geräte eine Smarthome Zentrale machen, die diesen Namen auch verdient.
Als einfachste Form mag die Rollladensteuerung gelten, welche stumpf zu einer bestimmten Uhrzeit die Läden öffnet und zu einer anderen Zeit wieder schließt. Das lässt sich noch ganz gut mit einer Zeitschaltuhr erledigen. Soll das ganze sonnenstandsgeführt sein (öffne kurz vor Sonnenaufgang, schließe bei bürgerlicher Dämmerung), wird es schnell eng bei konventionellen Steuerungen, zentral für alle Läden einer Gebäudeseite für Beschattung, andere Zeiten für Schlafräume, spezielle Zeiten für das Wochenende, Berücksichtigung der Schulferien und beweglichen Feiertage, Beschattung erst bei mehr als 23 °C, aber nur, wenn der Himmel nicht bewölkt ist... geht nur noch über eine passende Steuersoftware, konventionell nur nach Einwurf einer größeren Menge großer Geldscheine, aber nur vom Elektriker parametrierbar, der bei jeder Änderung die Hand aufhält...
Ein lustiges Beispiel ist auch die vollautomatische Weihnachtsbeleuchtung, welche pünktlich in der ersten Adventswoche beginnt und bis Mariä Lichtmess regelmäßig bei Einbruch der Dunkelheit bis 22 Uhr angeht, genauso wie morgens ab 6 Uhr bis es hell wird...
All das geht über die geschickte Verknüpfung von Ereignissen und Zuständen, welche auf dem openHAB Bus auftreten oder dort gespeichert sind.
Es gibt mitgeliefert drei verschiedene Programmieransätze in openHAB3, das ist die DSL (DomainSpecificLanguage - aufgabenspezifische Sprache), JavaScript udn Blockly (welches letztlich JavaScript Code erzeugt) - andere Programmiersprachen sind möglich und werden auch aktiv eingebaut, das meiste sind aber Nischenprodukte
Ich persönlich bevorzuge die DSL, weil ich ein alter openHAB Hase bin seit OH1.0 dabei und da geb es nur das. Die DSL ist auf die Anwendung openHAB optimiert und es gibt eigentlich kein Steuerungsproblem, welches damit nicht lösbar ist - in vielen Fällen extrem elegant, was natürlich ein tiefes Verständnis der Zusammenhänge in openHAB voraussetzt. In den diversen Foren zu openHAB gibt es zehntausende Programmbeispiele, viele gute Lösungen, noch viel mehr Mist aber man kann viel über das System lernen, wenn man sich etwas intensiver mit den Rules beschäftigt.Und noch ein Element ist die Persistence. Unter Persistenz versteht man allgemein das Speichern von Zuständen über einen beliebigen Zeitraum. Im Zusammenhang mit Hausautomation sind da vor allem Messreihen interessant (Temperaturverlauf verschiedener Sensoren, die im und ums Haus verteilt sind, Kesseltemperatur, Stromverbrauch usw.) MAn kann diese Daten in openHAB verwenden, um hübsche Charts zu erstellen, aber auch um z.B. Durchschnittswerte zu errechnen und anzuzeigen. Außerdem kann man die Persistence dazu verwenden, dass Schaltzustände über einen Neustart hinaus erhalten bleiben, wenn es außerhalb openHAB dafür keinen Speicher gibt. Ich habe z.B. einen Schalter, wenn jemand bei mir im Wohnzimmer übernachten will, damit die Rollläden nicht direkt bei Sonnenaufgang aufgehen. Der Schalter existiert aber nur in openHAB, also muss sich openHAB den Schaltzustand selbst merken - im Gegensatz zum Zustand des Lichts, da kann es über den Bus nachfragen, ob das Licht gerade an oder aus ist.
Das ist vielleicht ein erster kurzer Abriss über openHAB
und einige Details - es gibt viel zu entdecken...openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
-
Harka
- Beiträge: 303
- Registriert: 30. Apr 2021 13:13
Re: Newbie-Probleme, Debian, ZigBee
Moin,
mir haben die Videos vom BangerTECH ein gutes Stück weitergeholfen.
mir haben die Videos vom BangerTECH ein gutes Stück weitergeholfen.
-
Michatroniker
- Beiträge: 3
- Registriert: 9. Mär 2023 19:51
Re: Newbie-Probleme, Debian, ZigBee
Vielen Dank udo1toni für diese sehr ausführlichen Erklärungen.
ich bin jetzt nicht mehr ganz so irritiert und habe nun einiges "Futter" zum verdauen.
Die Installation auf USB-Stick ist wirklich nur als Provisorium gedacht. Ich plane nicht, es dauerhaft über Stick laufen zu lassen.
Immerhin habe ich die swap-Partition nicht ebenfalls auf dem Stick, sondern dafür muss die 2GB SSD herhalten.
Ich weiß noch nicht genau wie, aber ich will dem Igel mehr Speicher verpassen. Entweder finde ich eine kleinformatige SSD oder ich schaue mich nach Adapterlösungen um, so dass ich eine normale 2.5" SSD woanders platzieren und trotzdem mit dem SATA-Slot verbinden kann oder ich pflaster über nen Adapter eine mSATA oder M.2 SSD rein. ... oder ich rasiere den Kühlkörper ein bisschen, so dass eine 2.5" SSD passt, der ist nämlich im Weg ... so ähnlich... (ich habe noch zwei weitere solche Igels, erworben für 15 Euro pro Stück
)
Vielleicht nicht mal nötig, es ist nämlich auch ein undokumentierter mSATA Slot unter dem RAM-Riegel physisch vorhanden, vielleicht funktioniert der sogar
(bei späteren Versionen des M340C waren nur noch die Lötstellen des mSATA-Slots auf der Platine vorhanden, habe ich gelesen)
Oder: vielleicht schaffe ich es auch, mich soweit in OH reinzufuchsen, dass ich auf eine Universaldistro verzichten kann und suche mir was minimales Debian-ähnliches als Substrat für OH. (Ich bezweifle, dass ich ein aktuelles Debian auf 2GB unterbringen kann, wenngleich ich glaube, dass das grundsätzlich möglich wäre, vermutlich mit viel Handarbeit)
Kleine Frage dazu zwischendurch: ich brauche nicht unbedingt ein grafisches UI. Aber ein UI an sich finde ich sehr praktisch. Gibt es ein Text-UI? (Also sowas wie der Midnight-Commander als UI für den Umgang mit Dateien, anstatt per Prompt mit Dateien herumzuhantieren.)
In dem Fall bräuchte ich vermutlich auch keine Extra-Apps fürs Smartphone, denn dann könnte ich möglicherweise zB mit termux arbeiten.
Wenn ich fertig mit ziellosen Spielereien bin, wird mein erstes ernsthaftes Projekt vermutlich eine vernünftige Lichtsteuerung sein, für das Aufwecken und Schlafengehen daheim. das heißt, mit entsprechend angepassten Lichtfarben und jeweils sanft, also EIN/AUS per Rampe.
Der Wunsch "ich möchte Wecklicht und Einschlaflicht" war übrigens der konkrete erste Anlass, dass ich mich nach alternativen SmartHome-Plattformen umgeschaut habe - ich bin sehr unzufrieden mit den proprietären NonSmart-Angeboten.
Mein ausschlaggebender Frust war: ich habe eine Lampe, die hardwareseitig in der Lage ist, sowohl unterschiedliche Lichtstärken als auch verschiedenste Farben zu erzeugen. Die kann das sogar sanft ineinander übergehen lassen, es gibt von den Herstellern jeweils irgendwelche "Szenen", wo man unsinnige periodische oder zufällige oder akustisch gesteuerte Farb- und/oder Lichtstärkewechsel hat. Wer braucht sowas im Normalfall zu Hause im Alltag? Und warum kommt da keiner auf die Idee, einfach ein paar verschiedene sanfte Rampen als "Szene" anzubieten, was viel praktischer wäre? (Es gibt sicherlich LED-Leuchtmittel, die das können)
Ein weiteres kleineres Projekt wäre, einen Smartbutton von Lidl anders einzusetzen. Bisher geht nur: einmal betätigen EIN/AUS, doppelt Betätigen AUS/EIN, aber kein TOGGLE. Zumindest habe ich nicht herausgefunden, wie ich das mit der proprietären TUYA-App zum Togglen nutzen kann.. außer ein angesteuertes Gerät lässt sich direkt togglen, weil es diese Funktion mitbringt. (Ich habe Lampen, die das können, andere nicht)
Ich habe halt auch ein klitzekleines bisschen SPS-Erfahrung (S7 - KOP, FUP, bisschen AWL und kaum dieses grafische Zeugs, dessen Name ich vergessen habe. Leider nie Strukurierter Text, womit ich vermutlich am besten zurecht gekommen wäre. Und insgesamt so viel, dass ich sagen kann, dass ich von SPS-Programmierung beruflich die Finger lasse ), daher kann ich mir ein bisschen vorstellen, was theoretisch möglich sein müsste...
Soviel erstmal von mir dazu.
Vermutlich werden sich meine nächsten Fragen weiter um grundlegende Dinge drehen, aber mit konkreter Hardware und mit konkreten Zielen. Damit ich das anhand von Beispielen selber ausprobieren kann.
(kann sein, dass zwischendurch mal ein paar Tage vergehen, ich habe auch andere Baustellen )
ich bin jetzt nicht mehr ganz so irritiert und habe nun einiges "Futter" zum verdauen.
Die Installation auf USB-Stick ist wirklich nur als Provisorium gedacht. Ich plane nicht, es dauerhaft über Stick laufen zu lassen.
Immerhin habe ich die swap-Partition nicht ebenfalls auf dem Stick, sondern dafür muss die 2GB SSD herhalten.
Ich weiß noch nicht genau wie, aber ich will dem Igel mehr Speicher verpassen. Entweder finde ich eine kleinformatige SSD oder ich schaue mich nach Adapterlösungen um, so dass ich eine normale 2.5" SSD woanders platzieren und trotzdem mit dem SATA-Slot verbinden kann oder ich pflaster über nen Adapter eine mSATA oder M.2 SSD rein. ... oder ich rasiere den Kühlkörper ein bisschen, so dass eine 2.5" SSD passt, der ist nämlich im Weg ... so ähnlich... (ich habe noch zwei weitere solche Igels, erworben für 15 Euro pro Stück
)Vielleicht nicht mal nötig, es ist nämlich auch ein undokumentierter mSATA Slot unter dem RAM-Riegel physisch vorhanden, vielleicht funktioniert der sogar
(bei späteren Versionen des M340C waren nur noch die Lötstellen des mSATA-Slots auf der Platine vorhanden, habe ich gelesen)
Oder: vielleicht schaffe ich es auch, mich soweit in OH reinzufuchsen, dass ich auf eine Universaldistro verzichten kann und suche mir was minimales Debian-ähnliches als Substrat für OH. (Ich bezweifle, dass ich ein aktuelles Debian auf 2GB unterbringen kann, wenngleich ich glaube, dass das grundsätzlich möglich wäre, vermutlich mit viel Handarbeit)
Kleine Frage dazu zwischendurch: ich brauche nicht unbedingt ein grafisches UI. Aber ein UI an sich finde ich sehr praktisch. Gibt es ein Text-UI? (Also sowas wie der Midnight-Commander als UI für den Umgang mit Dateien, anstatt per Prompt mit Dateien herumzuhantieren.)
In dem Fall bräuchte ich vermutlich auch keine Extra-Apps fürs Smartphone, denn dann könnte ich möglicherweise zB mit termux arbeiten.
Wenn ich fertig mit ziellosen Spielereien bin, wird mein erstes ernsthaftes Projekt vermutlich eine vernünftige Lichtsteuerung sein, für das Aufwecken und Schlafengehen daheim. das heißt, mit entsprechend angepassten Lichtfarben und jeweils sanft, also EIN/AUS per Rampe.
Der Wunsch "ich möchte Wecklicht und Einschlaflicht" war übrigens der konkrete erste Anlass, dass ich mich nach alternativen SmartHome-Plattformen umgeschaut habe - ich bin sehr unzufrieden mit den proprietären NonSmart-Angeboten.
Mein ausschlaggebender Frust war: ich habe eine Lampe, die hardwareseitig in der Lage ist, sowohl unterschiedliche Lichtstärken als auch verschiedenste Farben zu erzeugen. Die kann das sogar sanft ineinander übergehen lassen, es gibt von den Herstellern jeweils irgendwelche "Szenen", wo man unsinnige periodische oder zufällige oder akustisch gesteuerte Farb- und/oder Lichtstärkewechsel hat. Wer braucht sowas im Normalfall zu Hause im Alltag? Und warum kommt da keiner auf die Idee, einfach ein paar verschiedene sanfte Rampen als "Szene" anzubieten, was viel praktischer wäre? (Es gibt sicherlich LED-Leuchtmittel, die das können)
Ein weiteres kleineres Projekt wäre, einen Smartbutton von Lidl anders einzusetzen. Bisher geht nur: einmal betätigen EIN/AUS, doppelt Betätigen AUS/EIN, aber kein TOGGLE. Zumindest habe ich nicht herausgefunden, wie ich das mit der proprietären TUYA-App zum Togglen nutzen kann.. außer ein angesteuertes Gerät lässt sich direkt togglen, weil es diese Funktion mitbringt. (Ich habe Lampen, die das können, andere nicht)
Ich habe halt auch ein klitzekleines bisschen SPS-Erfahrung (S7 - KOP, FUP, bisschen AWL und kaum dieses grafische Zeugs, dessen Name ich vergessen habe. Leider nie Strukurierter Text, womit ich vermutlich am besten zurecht gekommen wäre. Und insgesamt so viel, dass ich sagen kann, dass ich von SPS-Programmierung beruflich die Finger lasse
), daher kann ich mir ein bisschen vorstellen, was theoretisch möglich sein müsste...Soviel erstmal von mir dazu.
Vermutlich werden sich meine nächsten Fragen weiter um grundlegende Dinge drehen, aber mit konkreter Hardware und mit konkreten Zielen. Damit ich das anhand von Beispielen selber ausprobieren kann.
(kann sein, dass zwischendurch mal ein paar Tage vergehen, ich habe auch andere Baustellen
)-
mad-mike
- Beiträge: 403
- Registriert: 6. Jan 2021 18:05
Re: Newbie-Probleme, Debian, ZigBee
Moin.
Ich habe auch einige dieser Igel hauptsächlich zum testen, spielen.
Es gibt für kleines Geld passende SSD.
Habe da z.b. auch eine mit 64gb in den Igel gedrückt. Der steht derzeit inner Firma und Logt die Wärmepumpe mit.
Ich meine das sind half size SSD. mSATA.
Leider bin ich nicht so firm drin, und habe die aus dem Igel ausgebaut und bei EBay eine passende Größe gesucht.
Ich habe auch einige dieser Igel hauptsächlich zum testen, spielen.
Es gibt für kleines Geld passende SSD.
Habe da z.b. auch eine mit 64gb in den Igel gedrückt. Der steht derzeit inner Firma und Logt die Wärmepumpe mit.
Ich meine das sind half size SSD. mSATA.
Leider bin ich nicht so firm drin, und habe die aus dem Igel ausgebaut und bei EBay eine passende Größe gesucht.
Gruss mad-mike
openHABian 4.1.1 auf Raspberry Pi 4 Mod. b (8GB)
openHABian 4.1.1 auf Raspberry Pi 4 Mod. b (8GB)
-
udo1toni
- Beiträge: 13953
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Newbie-Probleme, Debian, ZigBee
Der Unterbau (also das OS...) sollte ohnehin besser erst gar keine grafische Oberfläche mitbringen.
openHAB selbst bietet seine UI ausschließlich über die Webschnittstelle an, alles andere läuft über die Shell.
openHAB selbst bietet seine UI ausschließlich über die Webschnittstelle an, alles andere läuft über die Shell.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
-
Michatroniker
- Beiträge: 3
- Registriert: 9. Mär 2023 19:51
Re: Newbie-Probleme, Debian, ZigBee
Hmm. Gibt es ein UI für die Shell? Oder bleibt dann nur sowas wie links2 oder andere Textbrowser als Umweg?
-
udo1toni
- Beiträge: 13953
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Newbie-Probleme, Debian, ZigBee
Du brauchst keine UI für eine Shell. Es ist im Gegenteil so, dass in der UI keine direkte Texteingabe zur Verfügung steht und deshalb ein Terminal emuliert werden muss. Irgendwie paradox, auf einem Rechner mit direktem Terminal eine UI zu starten, um dann (als einziges!) ein Terminal für die Shell zu emulieren.
Abgesehen davon arbeitest Du am besten überhaupt nicht lokal auf dem Server. Stattdessen loggst Du Dich per ssh auf dem Server ein, damit ersparst Du Dir eine extra Tastatur und Monitor (Maus gibt's ohnehin nicht). Ein Rechner ohne angeschlossene Tastatur und Monitor lässt sich nicht lokal durch Unbefugte bedienen, was ein netter Nebeneffekt ist.
Egal welche Plattform Du nutzt, ssh (Client) steht überall zur Verfügung. Unter Windows seit Version 1910 sogar als echtes Kommandozeilenprogramm.
Wenn Du etwas mehr Komfort haben möchtest, kannst Du z.B. zum de facto Standard PuTTY greifen, das bringt auch eine grafische Oberfläche zur Verwaltung der Sessions und der Konfiguration mit. Und es gibt noch jede Menge alternativer SSH Clients.
Wenn Du darauf bestehst, kannst Du sogar mit hterm oder webssh oder wie sie alle heißen eine Terminalemulation im Browser laufen lassen, in der Du dann die Secure Shell hast, das musst Du aber selbst zum Fliegen bringen
Gewöhnlich wird man ohnehin nur für die Wartung auf die Shell gehen, da bietet es sich an, das dann über VS Code mit zu erledigen - den gibt es kostenlos auch für alle wichtigen Betriebssysteme, und für VS Code gibt es ein Plugin, mit dem man openHAB komfortabel über Textdateien konfigurieren kann. Insbesondere bei der Entwicklung von Rules ist das effizienter als die UI.
Abgesehen davon arbeitest Du am besten überhaupt nicht lokal auf dem Server. Stattdessen loggst Du Dich per ssh auf dem Server ein, damit ersparst Du Dir eine extra Tastatur und Monitor (Maus gibt's ohnehin nicht). Ein Rechner ohne angeschlossene Tastatur und Monitor lässt sich nicht lokal durch Unbefugte bedienen, was ein netter Nebeneffekt ist.
Egal welche Plattform Du nutzt, ssh (Client) steht überall zur Verfügung. Unter Windows seit Version 1910 sogar als echtes Kommandozeilenprogramm.
Wenn Du etwas mehr Komfort haben möchtest, kannst Du z.B. zum de facto Standard PuTTY greifen, das bringt auch eine grafische Oberfläche zur Verwaltung der Sessions und der Konfiguration mit. Und es gibt noch jede Menge alternativer SSH Clients.
Wenn Du darauf bestehst, kannst Du sogar mit hterm oder webssh oder wie sie alle heißen eine Terminalemulation im Browser laufen lassen, in der Du dann die Secure Shell hast, das musst Du aber selbst zum Fliegen bringen
Gewöhnlich wird man ohnehin nur für die Wartung auf die Shell gehen, da bietet es sich an, das dann über VS Code mit zu erledigen - den gibt es kostenlos auch für alle wichtigen Betriebssysteme, und für VS Code gibt es ein Plugin, mit dem man openHAB komfortabel über Textdateien konfigurieren kann. Insbesondere bei der Entwicklung von Rules ist das effizienter als die UI.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
-
udo1toni
- Beiträge: 13953
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Newbie-Probleme, Debian, ZigBee
Du brauchst keine UI für eine Shell. Es ist im Gegenteil so, dass in der UI keine direkte Texteingabe zur Verfügung steht und deshalb ein Terminal emuliert werden muss. Irgendwie paradox, auf einem Rechner mit direktem Terminal eine UI zu starten, um dann (als einziges!) ein Terminal für die Shell zu emulieren.
Abgesehen davon arbeitest Du am besten überhaupt nicht lokal auf dem Server. Stattdessen loggst Du Dich per ssh auf dem Server ein, damit ersparst Du Dir eine extra Tastatur und Monitor (Maus gibt's ohnehin nicht). Ein Rechner ohne angeschlossene Tastatur und Monitor lässt sich nicht lokal durch Unbefugte bedienen, was ein netter Nebeneffekt ist.
Egal welche Plattform Du nutzt, ssh (Client) steht überall zur Verfügung. Unter Windows seit Version 1910 sogar als echtes Kommandozeilenprogramm.
Wenn Du etwas mehr Komfort haben möchtest, kannst Du z.B. zum de facto Standard PuTTY greifen, das bringt auch eine grafische Oberfläche zur Verwaltung der Sessions und der Konfiguration mit. Und es gibt noch jede Menge alternativer SSH Clients.
Wenn Du darauf bestehst, kannst Du sogar mit hterm oder webssh oder wie sie alle heißen eine Terminalemulation im Browser laufen lassen, in der Du dann die Secure Shell hast, das musst Du aber selbst zum Fliegen bringen
Gewöhnlich wird man ohnehin nur für die Wartung auf die Shell gehen, da bietet es sich an, das dann über VS Code mit zu erledigen - den gibt es kostenlos auch für alle wichtigen Betriebssysteme, und für VS Code gibt es ein Plugin, mit dem man openHAB komfortabel über Textdateien konfigurieren kann. Insbesondere bei der Entwicklung von Rules ist das effizienter als die UI.
Abgesehen davon arbeitest Du am besten überhaupt nicht lokal auf dem Server. Stattdessen loggst Du Dich per ssh auf dem Server ein, damit ersparst Du Dir eine extra Tastatur und Monitor (Maus gibt's ohnehin nicht). Ein Rechner ohne angeschlossene Tastatur und Monitor lässt sich nicht lokal durch Unbefugte bedienen, was ein netter Nebeneffekt ist.
Egal welche Plattform Du nutzt, ssh (Client) steht überall zur Verfügung. Unter Windows seit Version 1910 sogar als echtes Kommandozeilenprogramm.
Wenn Du etwas mehr Komfort haben möchtest, kannst Du z.B. zum de facto Standard PuTTY greifen, das bringt auch eine grafische Oberfläche zur Verwaltung der Sessions und der Konfiguration mit. Und es gibt noch jede Menge alternativer SSH Clients.
Wenn Du darauf bestehst, kannst Du sogar mit hterm oder webssh oder wie sie alle heißen eine Terminalemulation im Browser laufen lassen, in der Du dann die Secure Shell hast, das musst Du aber selbst zum Fliegen bringen
Gewöhnlich wird man ohnehin nur für die Wartung auf die Shell gehen, da bietet es sich an, das dann über VS Code mit zu erledigen - den gibt es kostenlos auch für alle wichtigen Betriebssysteme, und für VS Code gibt es ein Plugin, mit dem man openHAB komfortabel über Textdateien konfigurieren kann. Insbesondere bei der Entwicklung von Rules ist das effizienter als die UI.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet