Z-Wave für 0.8 auf Debian Jessie

Deutsche Foren Installation
#1

Hallo,
Homegear 0.8.0-2398 mit Hue und Homematic läuft bei mir schon ewig stabil.

Jetzt wollte ich Z-Wave mit installieren, apt-get findet bei mir aber nur eine 0.7.39-2773. Zurück will ich eigentlich nicht, bei 0.7 fehlte damals auch irgendwas.
Version 0.8 scheint es nur noch für Stretch und Buster zu geben.
Problem ist nun, ich bin auf einem Odroid C1 und da geht max. Jessie.

Gibt es irgenwie noch ein Repository oder Archiv mit älteren 0.8 Versionen für Debian Jessie?

Ich hab jetzt schon eine Weile gesucht und nichts gefunden, vielleicht kann mir ja jemand helfen.

Danke
Martin

#2

Hui… “nur” noch Jessie ist natürlich nicht gut. Damit ist mitte nächsten Jahres dann sowieso Ende: https://wiki.debian.org/de/LTS

Es gibt aber für deinen Odroid C1 ein Armbian auf Basis von Debian Buster und auch Ubuntu Bionic: https://www.armbian.com/odroid-c1/ - ok, zugegeben Beta.

Die bessere Wahl scheint ein DietPi zu sein, ist ebenfalls debianbasiert ist. Das wäre dann in dem Fall ein Stretch: https://dietpi.com/

Ob nochmal Jessie Pakete gebaut werden, muss @sathya sagen.

#3

Der Odroid soll schon mittelfristig weg, aber aus dem Grund will ich da nichts neues aufsetzten. Läuft stabil hat ein USV Modul und muss auch laufen, sonst kriegt die Familie eine Krise.
Für eine zukünftige sanfte Migration habe ich schon von Bidcos Kommunikation zu Openhab auf MQTT umgestellt, Hue sollen folgen und Z-Wave ist noch am Openhab Binding soll aber auch an Homegear. Dann hätte ich die ganzen low-level Kommunikation einheitlich auf MQTT.

Ich bräuchte ja eigentlich auch keine aktuelles Build und eigentlich heißt es ja “das Internet vergisst nichts”.
Gemessen an der 0.7 sollte es ja im April 2019 noch einen Jessie 0.8 Version gegeben haben.

1 Like
#4

Wie gesagt, da ist @sathya Herr über die Pakete. Ich hol das auch immer nur aus dem Repo.

Hier liegen, wie du ja schon gemerkt hast, leider nur die 0.7er Pakete: https://apt.homegear.eu/Debian/jessie/

#5

Hallo @mjancom,

Jessie wird nicht mehr unterstützt, weil sich Homegear mit der alten g+±Version nicht mehr kompilieren lässt. Es war so umständlich, Jessie noch zu unterstützen, dass wir den Support beenden mussten. Es gab tatsächlich noch 0.8-Pakete. Da diese aber sehr viel Speicherplatz einnehmen, werden sie regelmäßig gelöscht und jetzt gibt es keine mehr. Die einzige Möglichkeit 0.8 zu verwende,n ist entweder, eine alte Homegearversion selbst zu kompilieren oder auf ein neueres System umzustellen.

Viele Grüße

Sathya

#6

OK, trotzdem vielen Dank

#7

Welchen Vorteil hat das?

Homegear exportiert alle Geräte egal welcher Technologie über das Homematic Protokoll nach openHAB. Das Homematic Binding ermittelt vollständig dynamisch die Geräteparameter (Kanäle etc.).

Unter einer “sanften” Migration würde ich verstehen, die einzelnen Services nach und nach auf die neue Plattform zu bringen, während die alte weiterläuft. So mach ich das, der komplette Umzug auf den PI4 passiert, sobald der PI4 von USB-Geräten booten kann.

In deinem Fall wäre es daher sinnvoll, Homegear auf eine Plattform zu bringen, die Buster unterstützt, während die anderen Dienste unter Jessi auf dem Odroid weiter laufen.

#8

Zuerst einmal vorweg, das ist hier nur als Antwort auf die Frage/Anmerkung von job gedacht.
Ich will hier bezüglich Z-Wave 0.8 für Jessie nicht weiter rumjammern :blush:. Gibt’s es nicht mehr, habe ich verstanden und lässt sich schlussendlich auch anders lösen, nicht schlimm!

Also meine Gedanken (und die können auch falsch, bzw. zu kompliziert sein) zum Thema MQTT und Migration;

Meine Prämisse war, Homegear von einer Platform oder Version zu einer anderen -> Easy.
Openhab migrieren insbesondere mit Versionswechsel (man will ja was aktuelles) -> kann auch mal kompliziert werden.

Also erst mal zusätzlich zur Homematic auch Phillips Hue und Zwave auf Homegear bringen. Hue hab ich fertig, naja bei Zwave dann halt die Probleme.

Zum Thema warum MQTT:
Da haben sich im laufe diesen Jahres so einige Wifi Geräte mit Tasmota Firmware angesammelt (sind halt supergünstig). Nach etwas fluchen am Anfang, habe ich MQTT doch schätzen gelernt. Und wenn bei mir alle Geräte MQTT sprechen würden, finde ich das eigentlich auch ganz elegant.

Bei MQTT sprechen die Geräte ja nicht direkt miteinander, sondern alle schicken Befehle und Statusinformationen über einen Broker.

Also könnte ich auf einer neuen Plattform Openhab neu aufsetzten Alle Things, Items und Sitemaps dort einspielen, erst mal laufen lassen und basteln bis alles passt. Homegear würde ja gar nicht mitbekommen das irgendeine Temperatur in einer zweiten OH Instanz visualisiert wird oder ein Schaltbefehl über die Weboberfläche des alten oder neu OH getriggert wurde. Wenn das alles stabil läuft, könnte man die Rules (also Scripte) nach und nach zum neuen OH umziehen. Oder ich könnte parallel auch mal mit Home Assistant spielen oder diesen nur für Visualisierungen und Grafiken nutzen (das sah ja ganz schick aus)

Aus meiner Sich ist das feierabendtauglich, d.h. ich kann das alles in kleinen Häppchen und Zug um Zug umsetzen, kann jederzeit pausieren und stehe nicht unter dem Druck jetzt fertigzuwerden, weil sonst die Familie ungehalten wird.

Letzter Schritt wäre dann Homegear mit auf die neue Platform zu bringen und da hoffe ich ja, das läuft dann mal schnell und problemlos.

Da, dass ja mit Zwave in meinem aktuellen Homegear nichts wird, würde ich aktuell wahrscheinlich HG auf irgendeinem Raspi neu aufsetzten und diesen erst mal verwenden (Openhab bleibt natürlich da wo es ist). Wenn ich mir dann nächsten Jahr im Klaren bin, wie neue Smarthome Plattform (Docker?) aussieht, zieht HG halt noch mal um.

#9

Ich finde deinen Plan super. Ich selbst trenne Visualisierung (aktuell node-red-dashboard) und Automation (node-blue). Jegliche Kommunikation läuft über mqtt. Entweder bridget homegear transparent rüber oder das Gerät selbst sprich mqtt.

Die Frage für mich ist grade nur, warum dein Umzug so viel Umstand sein soll?

  • Homegear auf neuem Pi installieren
  • /etc/homegear/*(inkl. Unterverzeichnisse) und /var/lib/homegear/* rüber kopieren
  • homegear-alt stoppen
  • Hardware umstöpseln (falls vorhanden)
  • homegear-neu starten

Eventuell muss man ein paar alte Konfigurationsparameter rausnehmen und/oder anpassen. Das siehst du aber dann beim Start.
Als Backup hast du immer noch den Odroid als Backup.

#10

@mjancom, meine Frage bezog sich nur darauf, warum du alles auf mqtt umstellst? Alles, was du machen möchtest, geht auch mit der Bidcos-Schnittstelle. Ist zwar elegant, alles über das gleiche Protokoll zu haben, aber wo ist der Vorteil?

Das ist immer ein Fehler! Niemals auf eine neue Hardware mit Versionswechsel. Entweder das Eine oder Andere.

openHAB hardwareseitig umziehen dauert bei mir auch nur max. eine halbe Stunde.

  • openhab-cli backup
  • openhab-cli restore
  • openhab-cli clean-cache

Allerdings habe ich alles in Dateien und keine Hardware direkt. Alles ist nur über Bridges (mqtt, hue, homegear) angebunden.

#11

Erst einmal sorry, ich kann aktuell nicht so schnell antworten.
Zum Jahresende ist das beruflich und privat alle sehr eng.

@ pmayer

Ich bin da Deiner Meinung, der homegear Umzug sollte kein Thema sein.
Falls das so rüberkam -> Missverständnis.

Vielleicht ist das bei meinem vielen Geschwafel etwas untergegangen, aber aktuell gibt es noch keine neue Plattform als Nachfolger zum Odroid.

Nach den Odroid Erfahrungen, fände ich eine Raspi ganz gut. Selbst für meine alten 1B gibt es ein aktuelles Image.
Raspi4 habe ich schon zwei (die machen aktuell aber andere Sachen und nicht im Dauerbetrieb). Für den Odroid habe ich eine Mini USV als Shield, das hätte ich für die neue Lösung auch gerne. Es scheint PI4/PI3 kompatible zu geben. Aber das Ding wird sowieso schon heiß und dann ein Shield drauf, was die Luftzufuhr noch mehr behindert!
Dann ist da noch das Thema Buster. Gefühlt halt schon fast da, aber auch nur fast. Außerdem denke ich noch über Docker nach.
Also wollte ich das ins Q1 nächsten Jahres verschieben und in der Zwischenzeit, das ganze vorbereiten, System entschlacken, alles schon mal auf MQTT, soviel wie möglich auf Homegear schieben, etc, etc.

Wie schon gesagt, ich nehme zwischenzeitlich einen Raspi4 und mach eine aktuelles Homegear drauf. Das kann dann auch Zwave (Yippiiiiii) und wird dann hoffentlich auch ohne SSD und USV min. 2-3 Monate durchhalten.

@ job
Du kennst die Protokolle sicherlich viel besser als ich. Bidcos war für mich immer so eine Art Blackbox. Geht, aber keine Ahnung was da passiert. Wenn man per Bidcos eine altes und neues OH auch parallel betreiben kann ist das für mein Szenario ja schon nah beieinander.

Bleibt für mich noch das Thema alles auf einem Protokoll.
Es gibt Diverse MQTT Tools um Fehler zu suchen oder auf die schnelle Daten zu visualisieren.
Vielleicht liege ich da ja falsch, aber ich hatte auch das Gefühl, mal eben Node Red oder Home Assistant anbinden (auch wenn es nur zum testen ist) geht mit MQTT einfacher?

Zum Thema Openhab Migration bzw. Update.
Du hast sicherlich recht das nicht in einem zu machen. Aber nach der Migration würde ich sicherlich auch OH aktualisieren wollen.

Ich bin bei OH schon relativ lange, seit irgendeiner niedrigen 1.x Version und bin aktuell bei 2.5M4.
Da war bei jedem Update das Log in der Konsole immer dauerrot.

  • Fehler in Rules weil sich was geändert hat
  • Things oder Items müssen angepasst werden
  • Nach dem x-ten Cache/ Tmp leeren/Neustart tritt eine Fehlermeldung nicht mehr auf, warum die Versuche vorher es nicht gebracht haben keine Ahnung. Bei letzten mal war es Cache und Tmp leeren neu starten und dann noch mal neustarten.
  • Irgendeine Java Umgebungsvariable muss angepasst werden
  • etc, etc

Klar bin ich nicht der IT Super Guru und das Hauptproblem sitzt wahrscheinlich vorm Bildschirm. Deshalb versuche ich das Thema Openhab Migration/Upgrade soweit wie möglich vom produktiv System Haus zu entkoppeln.

Damit mich hier keine falsch versteht, Openhab ist super !!!

  • Was es so an Bindings gibt (Amazon Echo, Harmony, AV Receiver, etc).
  • Die Art wie Rules geschrieben werden finde ich sehr angenehm
  • Alle Konfigurationen in Text Files (wenn man möchte)
  • Hat man so eine Update oder Grundinstallation erst mal durchgezogen und alle Anfangs- Wehwehchen ausgemerzt läuft das trotz “riesenfunktionsumfangs” superstabil.

D.h. wenn nicht der Drang wär immer mal was neues cooles auszuprobieren oder ein neues Gadget dranzuhängen hätte ich den Stress nicht :blush:
Aber ist ja auch Hobby und wenn es dann läuft ist man schon ein bisschen stolz.

2 Likes
#12

Nicht wirklich. ;-.)
Übrigens habe ich mich auch vertan, Bidcos ist das Protokoll mit dem Homegear mit den Homematic-Geräten spricht, wir meinen aber beide das Protokoll über das openHAB mit der CCU oder Homegear spricht. Wie auch immer das heisst. :wink:

Es ist kein Problem, in Homegear mqtt einzuschalten, dann wird alles auch über mqtt transportiert. Wenn du allerdings deine Homematic Geräte nur über mqtt nach openHAB bringen willst, musst du alle Geräte haarklein in openHAB per Hand konfigurieren. D.h. jedes topic für jedes Gerät eintragen. Diese Arbeit nimmt dir das Homematic-Binding ab, weil es Homegear nach den Geräten/Kanälen fragt.

Die Konfiguration von mqtt ist nicht gerade unaufwendig, daher hat mich der Nutzen interessiert. Ich habe gerade erst 99% meiner mqtt Anbindung auf Version 2 des mqtt-Bindings portiert, daher kenne ich den Aufwand ganz gut. Mit Version 2 musst du sogar alles doppelt konfigurieren, einmal für das Thing und dann nochmal für die Items. Mit dem 1er hast du ja nur die Items konfiguriert.

#13

Das sehe ich auch so.
Ich hab ja MQTT in OH erst mit dem 2er Binding angefangen.
Things und Item Definition sind schon fummelig.
Keine Ahnung ob das wirklich so kompliziert seien muss.
Im Prinzip gibt man bei beiden fast das gleiche ein.

Was (zumindest bei meiner aktuellen Version) auch sehr nervig ist, dass sobald ich eine Thing Definition einmal falsch hatte.
Z.B. zwei Things an ein MQTT Topic gebunden (Paste&Copy Fehler) oder eine falsch/fehlende Transformation habe ich immer so Geistereffekte.
D.h. obwohl jetzt alles korrekt ist, immer noch Fehlermeldung True passt nicht zu ON/OFF oder ein Schalter aktiviert immer noch zwei Lampen obwohl ich die Thing Definition korrigiert habe.
Da hilft noch nicht mal ein restart des Bindings sondern nur ein OH neustart :frowning:

An der Stelle kann ich, den hier schon mal geäußerten Wunsch, nach einer Art Alias MQTT Struktur für Homegear nur unterstützen.
Also das neben dem sicherlich eindeutigen
hg/hg/plain/37/1/STATE
auch was selbst definiertes wie
lampen/eg/wz/sideboard/links/STATE gehen würde.

#14

Ja, das muss.

Es fehlt nur eine Abstraktion, nämlich der ThingTyp. Diesen musst du bei jedem Thing mitkonfigurieren, daher wirkt das doppelt. Der ThingTyp wird normalerweise über das Binding konfiguriert, da es aber bei mqtt komplett frei ist, muss der Anwender in der Konfiguration des Things den ThingTyp mitmachen.

1 Like