In /etc/homegear/ befinden sich nur die Konfirguationsdateien, die Daten sind in einer sqllite-db in /var/lib/homegear/db.sql.
Aber sei bitte vorsichtig, ich habe bisher immer nur eine Kopie gemacht und mir diese dann angeschaut, niemals etwas verändert.
sudo homegear -r
fs 4
ls
ps <id>
config print
Hallo,
bedeutet das, das die Doku bezüglich der Konfigurationsdateien falsch ist?
z.B. hier oder hier oder hier
Dort ist nämlich überall angegeben, das die Konfigurationsdaten im Verzeichnis /etc/homegear/families/*.conf anzugeben sind.
Oder gibt es eine Art Vorrangsteuerung? z.B. Daten aus DB werden mit Daten aus config Files überschrieben, oder, oder, …
Wenn ja, wäre es hilfreich, wenn das in der Doku stehen würde. Oder finde ich das nur nicht oder habe es überlesen?
Ich wäre ja gern behilflich die Doku diesbezüglich zu verbessern, aber ich fürchte mit meinem Wissen nahe der Null-Linie könnte das gewaltig nach Hinten los gehen.
VG
Henning
Nein. Das ist alles richtig. Das ist die Konfiguration wie mit den einzelnen Familien kommuniziert wird.
Die Daten der Geräte der Familien befinden sich in der Datenbank. Meines Erachtens wolltest du Wissen, wo die Daten zu deinen Thermostaten stehen.
@fow0ryl, ich glaube du versteht ein paar Dinge falsch.
In /etc/homegear/families/*.conf werden die Familien konfiguriert. Je nach installiertem Modul, sind dort die zugehörigen Dateien abgelegt.
Die sqlite.db, die @job erwähnte, hält alle angelernten Geräte aller Familien.
Wo hängst du gerade?
Homegear ist als Kommandozeilentool ins Leben gerufen worden. Die Familienkonfiguration wurde und wird in den .conf files vorgenommen, die du ja auch ansprichst. Dazu gekommen ist dann vor einigen Jahren die Admin-UI, die vieles komfortabler macht. Die Admin-UI löst dabei die Konfiguration in Konfigurationsdateien nicht völlig ab. Einige Einstellungen lassen sich weiterhin ausschließlich im Dateisystem/ Konfigurationsdateien vornehmen. Was man in der Admin-UI konfiguriert, wird jedoch in der Regel nicht in den Konfigurationsdateien abgelegt, sondern in der Datenbank. In der Konsole hat man eben alle Möglichkeiten, in der UI wird man (noch) irgendwann an Grenzen stoßen. Was man verwendet, ist einem selbst überlassen. Wenn ich so darüber nachdenke, ist es schon fast bemerkenswert, dass du der Erste zu sein scheinst, der das hier öffentlich anspricht. 
Die Abhängigkeitsprobleme mit dem nightly sollten ab der 3128 gefixed sein.
Danke für deinen Input. Wenn mal wieder Langweile herrscht, kann ich ja ein paar Dinge davon im Guide berücksichtigen.
Hallo,
vielleicht liegt die Fragerei an meinem beruflichen Background …
Bevor ich in den (Vor-)Ruhestand gegangen bin, habe ich mich rund 30 Jahre mit COBOL auf dem Mainframe mit mehreren 100.000 parallelen Nutzern, 24x7 Betrieb, max. 8 Stunden Downtime im Jahr und das alles über ein Terminal mit 80 Zeichen und 24 Zeilen, herumgeplagt. Dagegen kommt mir selbst solche Dinge wie die bash als Teufelswerk aus einer fernen Zukunft vor 
Ich habe den MAX!-CUBE über die Admin-UI als CUNX konfiguriert. Aber in der max.conf taucht davon nichts auf. Daher habe ich mich gefragt, was ich falsch mache, bzw. nicht verstanden habe.
Schließlich war die Konfiguration auch nach einem reboot noch vorhanden…
Ich kann gut damit leben, das die Daten in einer SQL Datenbank landen. SQLite finde ich zwar nicht so doll, da ich anderweitig schon einen PostgreSQL Server laufen habe. Aber das ist ja bestimmt der Raspi Plattform geschuldet.
Werde mir die Datenbank bei Gelegenheit mal ansehen.
Die neue nightly Version werde ich natürlich ausprobieren. Vorher möchte ich aber noch ein Sicherungs-Image ziehen, damit ich im Katastophenfall nicht von vorn anfangen muss …
Gruß
Henning
@Sim
Gute Arbeit
Habe die nightly-0.8.0-3128 heute problemlos installieren können.
In der Admin UI ist mir aufgefallen, das unter Einstellungen -> System eine leere Seite mit der Überschrift “Systemeinstellungen” angezeigt wird. Ich weiß aber nicht, ob das evtl. vorher auch schon so war …
Und einen MQTT Broker kann man in der Admin UI leider auch (noch) nicht konfigurieren.
Glücklicherweise braucht man ja für die ersten Schritte nur die passende IP in der mqtt.conf eintragen.
Da ich mit MQTT noch nichts zu tun hatte, habe mir erst mal auf meinem Manjaro-Server den mosquitto installiert. Und auf meinem Notebook den MQTT-Explorer.
Nach einem Restart von Homegear kann ich dort schon Nachrichten sehen. So weit hat das schon mal geklappt.
Welche Protokolle sollte man denn verwenden? Gleichzeit Json, Plain und JsonObject macht ja wohl wenig Sinn. Gibt’s da abgesehen von Größe und Lesbarkeit der Nachrichten spezifische Vor- und Nachteile?
Ohne es überprüft zu haben, passen die vermutlich ohnehin alle in ein TCP Paket von rund 1500 Bytes…
Ich könnte mir vorstellen, das je nach Format unterschiedlich viel Rechenzeit auf dem Broker notwendig ist. Aber auch das dürfte erst bei hoher Last Auswirkungen zeigen.
Hallo,
ganz so gut wie gehofft läuft homegear jetzt doch nicht 
Ich habe zum ersten Mal in Node-Blue einen Eintrag gespeichert. Danach ist homegear tot.
Es ist auch völlig egal was ich in einen Flow schiebe und in welchem Zustand ich es deploye.
Ergebnis ist immer gleich. Auch nach einem Reboot des pi kommt homegear nicht mehr hoch …
pi@homegear(ro):~$ sudo systemctl status homegear
● homegear.service - Homegear
Loaded: loaded (/lib/systemd/system/homegear.service; enabled; vendor preset: enabled)
Active: deactivating (stop-sigterm) (Result: signal) since Mon 2020-12-28 10:05:09 CET; 1min 18s ago
Process: 23116 ExecStartPre=/etc/homegear/homegear-start.sh (code=exited, status=0/SUCCESS)
Process: 23127 ExecStart=/usr/bin/homegear -u homegear -g homegear -p /var/run/homegear/homegear.pid (code=killed, signal=SEGV)
Main PID: 23127 (code=killed, signal=SEGV)
Tasks: 1
CGroup: /system.slice/homegear.service
└─23056 sync
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.216 Debug: retries of RPC client ExampleClient1 set to 3
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.216 Debug: timeout of RPC client ExampleClient1 set to 15000000
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.216 Debug: hostname of RPC client ExampleClient2 set to 192.168.178.89
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.216 Debug: retries of RPC client ExampleClient2 set to 5
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.216 Debug: timeout of RPC client ExampleClient2 set to 30000000
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.217 Setting allowed core file size to “4294967295” for user with id 0 and group with id 0.
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.218 Core file size now is “4294967295”.
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.218 Setting maximum thread priority to “4294967295” for user with id 0 and group with id 0.
Dec 28 10:05:05 homegear homegear[23127]: 12/28/20 10:05:05.218 Maximum thread priority now is “4294967295”.
Dec 28 10:05:09 homegear systemd[1]: homegear.service: Main process exited, code=killed, status=11/SEGV
Ich befürchte du hast ein nightly, in dem homegear keinen großen Überlebenswillen hat. Das aktuelle 3128 (ja, die Version ist gleich, doch der Inhalt nicht der Selbe) wird vermutlich gehen.
Da scheint noch mehr kaputt gegangen zu sein…
Ein erneuter Installationsversuch bleibt hier hängen:
preparing to unpack libhomeger-base_current_raspian_buster_armhf.deb …
Der Versuch homegear zu stoppen scheitert ebenfalls:
systemctl stop homegear
Da scheinen Prozesse auf irgendwas zu warten …
root@homegear(rw):/tmp# ps -All |grep homegear
4 S 0 367 1 0 80 0 - 19305 futex_ ? 00:00:01 homegear-webssh
4 S 0 368 1 0 80 0 - 54200 futex_ ? 00:00:01 homegear-manage
4 S 0 12219 1 0 80 0 - 2013 do_wai ? 00:00:00 homegear-stop.s
Bei der Aktion ist mir noch aufgefallen, das die Build-Zeiten der nightly’s, die im Installer angezeigt werden, von denen auf der Download-Webseite abweichen.
Ein Hinweis auf der Webseite, das es sich um UTC handelt, während im Script Local-Time verwendet wird, koste nicht viel Aufwand, könnte aber hilfreich sein …
Werde mal schauen, ob ich das System wieder zum Leben erwecken kann.
VG
Henning
Ich benutze die 0.8.0-3093 vom 27.10.2020 problemlos. Wenn du also Probleme mit defekten Builds hast, kannst Du ja mal diese Version funktionieren: 20201127.
So, habe die Partitionen aus einer Sicherung wieder hergestellt und die nightly 0.8.0-3128 neu installiert.
Damit kann man in Node-Blue jetzt auch etwas speichern, ohne das das System komplett hängt.
Fragen zu Node-Blue werde ich ggf’s dann in einem separaten Thread stellen.
Hier bleiben jetzt erst mal 3 Fragen zur aktuellen Installation/Admin-UI offen. Da ich ja noch nie eine komplett lauffähige Installation hatte, kann ich leider auch nicht erkennen, ob es am aktuellen build liegt, oder ob es andere Gründe gibt.
In der Admin-UI wird unter Administration -> System eine leere Seite mit dem Text “Systemeinstellungen” angezeigt.
Feature oder Fehler?
Ich habe das Paket webssh installiert. Da ich dazu keine Beschreibung gefunden habe, weiß ich nicht was damit bewrikt werden soll.
Ich vermute mal, das es in der GUI eine Shell angezeigt werden sollte.
Doch wie ruft man die auf?
In der Admin-UI gibt es unter “Wartung -> Dienste” den Punkt “SSH-Passwort setzen”.
Wenn ich dort etwas angebe (ich bin in der GUI als “homegear” angemeldet)
kommt folgende Meldung:
SSH-Passwort setzen
Das Passwort konnte nicht gesetzt werden, ein interner Fehler ist aufgetreten:
User has a UID less than 1000 or UID could not be determined.
Da es keine weiteren Hinweise gibt, gehe ich mal davon aus, das das Passwort des angemeldeten Users gesetzt werden soll. Oder wie oder was?
@job
Sehr guter Hinweis. Wenn ich mit der aktuellen nightly nicht weiter komme, werde ich mal die genannte Version ausprobieren.
Gruß
Henning
Ich benutze Homegear und die AdminUI einige Zeit, aber diese 3 Punkte haben mich nie interessiert.
zu 1. Bei mir sind da Blöcke für mqtt & influxdb, Inhalte werden aber aus Berechtigungsgründen nicht angezeigt.
zu 2. und 3. ich benutze auschliesslich putty wenn ich von Windows oder ssh wenn ich von Linux aus zugreife.
Die interessanten Punkte befinden sich im AdminUI unter Inventar und Programmierung oder dem englischen Pedant, der Rest ist auch da. (sorry @micha )
Hallo zusammen,
@job: sorry wofuer? Kannst du mir mal einen Screenshot von deinem “Problem” zu Punkt 1 als PM senden bitte?
@fow0ryl: danke fuer dein Feedback, ich versuche mal zu helfen so gut ich kann.
Zu Punkt 1: kannst du bitte in der Admin-UI unter “Wartung” -> “Dienste” den Punkt “Umgebung” einmal auf “Entwicklung” aendern? Anschliessend sollte dir unter “Einstellungen” -> “System” eine Fehlermeldung angezeigt werden, von der braeuchte ich einmal einen Screenshot (auch gerne als PM …).
Zu Punkt 2: Das Homegear Webssh-Paket enthaelt eine Browsershell wie du schon richtig vermutet hattest. Sofern sie korrekt installiert wurde und der Dienst auch laeuft, solltest du unter “Wartung” den Punkt “Konsole” finden … allerdings nur, wenn der Nutzer mit dem du in der Admin-UI eingelogged bist den Experten-Modus aktiviert hat. Diesen kannst du unter “Einstellungen” -> “Benutzer” fuer den jeweiligen Benutzer aktivieren.
Zu Punkt 3: Das ist eine Einstellung die eigentlich einmal fuer vorinstallierte Systeme gedacht war: damit kann man das Kennwort einen bestimmten System-Benutzers setzen/aendern. Wenn dieser bestimmte Benutzer nicht vorhanden ist, bzw. eine UID < 1000 hat, kommt diese Fehlermeldung. Ich kann diese Einstellung in einer der kommenden Versionen herausnehmen, damit sollten dann da keine Irritationen mehr auftreten
– Micha
Hallo,
auch euch noch ein frohes Neues.
zu Punkt 1: Bei mir sah das so aus. kein Hinweis. Nix
Ich habe aus deinen Ausführungen zu Punkt 2 gefolgert, das es sein könnte, das einfach nichts angezeigt wird, weil beim Benutzer der Expertenmodus nicht eingeschaltet ist. Eine entsprechende Warnung wäre hilfreich.
Im Expertenmodus sieht das dann viel schöner aus …
Hoffe das deine Info letztlich in die Doku bzw. den Grundlagen Thread Einzug hält, damit auch andere davon profitieren können
Zu Punkt 2: Hat wunderbar geklappt. Hoffe das deine Info auch in die Doku bzw. den Grundlagen Thread Einzug hält, damit auch andere davon profitieren können
Ich finde es allerdings nicht ganz so glücklich, das man gleich als root angemeldet wird. Ein Passort wird nirgends abgefragt. Damit kann man unbewußt viel kaputt spielen …
Glücklicherweise ist das System (ro). Was aber bei Installationen, die nicht auf dem Standard Image beruhen, durchaus anders sein könnte.
Ich persönlich fände es besser, wenn man als der User angemeldet wird, der auch in der Admin-UI angemeldet ist. Zum root kann man sich dann ja immer noch per su machen. ist aber sicher Geschmackssache.
Zu Punkt 3: Ich kann nicht beurteilen, ob die Funktion für jemanden hilfreich ist.
Da du schreibst, das man das Kennwort “eines bestimmten Nutzers” setzen kann, wäre vielleicht auch ein Kompromiss denkbar.
Man bräuchte in der UI ja nur den Benutzer anzeigen, um den es geht. Die Funktion bliebe für alle bisherigen Nutzer erhalten und die Irritation für Unwissende ist beseitigt.
VG
Henning
Hey @fow0ryl,
ah, danke fuer die Screenshots 
Hm, also auch ohne Expert-User sollten in den Systemeinstellungen zumindest die Netzwerkeinstellungen zu sehen sein. Aus irgend einem (mir nicht sofort ersichtlichen) Grund koennen die wohl nicht ausgelesen werden 
Den User fuer das Webssh kannst du in der entspr. Konfigurationsdatei (/etc/homegear/webssh.conf) aendern.
– Micha
Naja, du machst dir die Mühe um die ganzen Sachen in die AdminUI zu bringen, und ich nutze sie nicht. War aber nicht sooo ernst gemeint.
Hey @job,
achsooo … ist ja nicht schlimm, solange es andere tun Und wg. “ernst” … war doch nen Smiley dahinter, so what? Passt 
– Micha
Na ja,
ich brauche eine Shell im Browser auch nicht unbedingt. Aber wenn andere Dinge nicht funktionieren, dann schaut und probiert man halt hier und da …
Letztlich war ja fast Alles eine Frage von fehlender bzw. unvollständiger Doku.
Habe gerade ein Update auf die nightly 0.8.0-3169 versucht. Geht natürlich auch nicht “out-of-the-box”
Da ich nicht weiß, wie man im Raspian einen Pfad für eine Userid dauerhaft erweitert, habe ich mir erst mal mit einem einfachen “export PATH=…” geholfen.
=> Das von homegear zur Verfügung gestellte Raspian Image sollte um die passende Pfad-Angabe erweitert werden.
Ich habe das InstallNightly.sh nun zwangsweise zig mal laufen lassen.
Dabei ist mir besonders negativ aufgefallen, das der Download jedes Mal stattfindet.
Ohne Squid auf dem Router ist das bei einer langsamen Leitung der Tod.
Und die Partition ist auch regelmäßig voll, da jeder Durchlauf ein neues /var/tmp/tmp.* anlegt.
Henning
