HM-CC-RT-DN nach Mqtt

[HiG]

Welchen Teil meinst Du?

Schrieb ja im Nachtrag...ja...es funktioniert

[Tentazione]

Knapp wunderbare (weil alles lief) 3 Jahre und eine kaputte SD-Karte (natürlich ohne Sicherung) später ....habe ich mal versucht nachzuvollziehen was wir da damals angestellt haben? #gruebel

Mein OH3 ist in den ewigen Jadggründen, da kann ich leider nicht mehr nachschauen....das OH2.5 funkt aber immer noch hervorragend in die MQTT-Queue hinein (da hab ich jetzt auch mal vorsorglich eine Sicherung erstellt ). Nun möchte ich aber gerne auch die Werte von aussen setzen. Im speziellen Fall die Soll-Temperatur und ob das Fenster offen ist. Diese Werte werden von einem anderem System in die MQ gepostet und ich möchte sie im OH2_5-System da rauslesen und setzen.

Meine bescheidenen Versuche und Kenntnisse auf diesem Gebiet treiben mich aber schnell an die Grenze des Machbaren. Vielleicht kann mir ja hier nochmal kurz auf die Sprünge helfen.

Was habe ich also

Es gibt folgende Thing-Definition

Code: Alles auswählen

Thing topic T_eg_heizung  "Heizung" @ "mqtt" {
    Type string : eg_ku_hz    "Heizung Kueche"        [ commandTopic="zb2mqtt/eg_ku_hz_02"]
    Type string : dg_of_hz    "Heizung Office"        [ commandTopic="zb2mqtt/dg_of_hz_02"]
    Type string : eg_hr_hz    "Heizung HWR"           [ commandTopic="zb2mqtt/eg_hr_hz_02"]
    Type string : eg_wc_hz    "Heizung WC"            [ commandTopic="zb2mqtt/eg_wc_hz_02"]
    Type string : eg_fu_hz    "Heizung Flur"          [ commandTopic="zb2mqtt/eg_fu_hz_02"]
    Type string : eg_wz_hz    "Heizung Wohnen"        [ commandTopic="zb2mqtt/eg_wz_hz_02"]
    Type string : og_bd_hz    "Heizung Bad"           [ commandTopic="zb2mqtt/og_bd_hz_02"]
    Type string : og_sz_hz    "Heizung Schlafen"      [ commandTopic="zb2mqtt/og_sz_hz_02"]
    Type string : og_sc_hz    "Heizung Schrank"       [ commandTopic="zb2mqtt/og_sc_hz_02"]
}

auf diese feuere ich aktuelle in einer Rule zusammengestellte JSON-Payloads wie z.b.

Code: Alles auswählen

{ "soll_temp" : 12.0, "ist_temp" : 19.80, "ventil" : 0, "battery" : 2.70, "signal" : 3, "batterylevel" : 0.0, "boost" : 0, "batterytype" : "2x AA/Mignon/LR06", "window" : 1, "active" : 1, "error" : "NO_FAULT", "firmware" : "1.4", "mode" : "AUTO-MODE"}

und es gibt eine ITEM-Definition

Code: Alles auswählen

String mq_eg_ku_hz  "Homematic2Mqtt Kueche"                                                                         { channel="mqtt:topic:xx57091363:T_eg_heizung:eg_ku_hz"[profile="follow"]}

Wie bekomme ich es hin, das wenn ich auf einen MQTT-Channel eine Nachricht lege (z.B. auf zb2mqtt/eg_ku_hz_02) das ich diese Daten in OH auslesen kann bzw. informiert werde das sie sich geändert haben.


Sorry für die umständliche Beschreibung

[udo1toni]

Bevor wir das Thema vertiefen (und weil dieser Thread schon ziemlich alt ist...)

Frage 1: Warum hast Du ein openHAB2.5 laufen? hast Du ein Binding, was (damals...) nicht für openHAB3 existierte? Kannst Du verifizieren, dass es auch unter openHAB4.3 keine native Unterstützung für die hardware gibt?
Frage 2: Welche Hardware überhaupt...?

[Tentazione]

MoinZen Udo

warum? Weil es immer zu meiner Zufriedenheit lief. Und ich ungerne auf gut laufenden Systemen Updates einspiele. Das zerschießt mir meist die Konfiguration oder es läuft hinterher gar nix mehr. #soifz Ist mir gestern erst wieder beim Mosquitto-Update auf meiner Synology passiert. Auf einmal ging der anonymoe Zugriff nicht mehr.

Als ich dieses System aufgesetzt habe, gab es kein Openhab 3 Ich habe (das mittlerweile verstorbene) andere System dann seinerzeit mit Openhab 3 aufgesetzt,

Das ganze läuft auf einem Raspi 2 mit HM-MOD-RPI-PCB und Homegear. Weitere Bindings sind das Homematic und das Mqtt-Binding.

Und die Frage wäre ja...würde sich mein Wunsch mit Openhab 4.3 einfacher umsetzen lassen? Muss ich nicht (neben der Konfiguration des Neusystems) möglicherweise meine alten Sachen erst portieren?

[udo1toni]

Sind die zwei Systeme voneinander unabhängig? oder steuerst Du das eine System mit dem anderen? Gewöhnlich hat man ein openHAB System, nicht zwei oder gar mehr. Ausnahme: Man hat ein Binding, welches unter der aktuellen Version nicht zur Verfügung steht.
openHAB1.x(!) verwendete ein komplett anderes Modell in Bezug auf die Bindings. Mit openHAB2 kam das neue Binding Modell, welches dann auch AutoDiscovery ermöglichte (soweit das durch die entsprechende Technik hinter dem Binding überhaupt möglich ist).
openHAB2 hatte aber noch eine Kompatibilitätsschicht, um auch die openHAB1 Bindings ausführen zu können. Nur deshalb steht openHAB2 in der letzten Version 2.5.12 überhaupt noch zur Verfügung. Wenn ich mich richtig erinnere, läuft dieses aber nur unter Java8 (oder vielleicht noch Java11, aber keinesfalls ein aktuelles Java). Das letzte OS, welches Java8 anbietet, ist vermutlich Debian Jessie, was seit vielen Jahren keine Sicherheitsupdates mehr bekommt. Es ist also mit einem großen Risiko behaftet, ein so altes System weiter zu betreiben.

Natürlich, wenn Du mit dem Funktionsumfang zufrieden bist und das System rein lokal betreibst, musst Du nicht updaten, aber irgendwann macht's dann halt puff und das System ist Vergangenheit, genau wie mit dem jüngeren System. Und da helfen auch keine Backups, die schützen Dich allenfalls vor einer defekten SD-Karte (wenn es sich um ein Komplett-Backup der gesamten SD-Karte handelt), helfen Dir aber nicht, das System auf neuer Hardware wiederzubeleben.

Ich nutze hier überhaupt keine Hardware für openHAB, stattdessen läuft das System virtualisiert auf einem Proxmox wobei der halt "ehda" ist. Allerdings kann man Proxmox wunderbar auf älteren Rechnern installieren,die müssen lediglich amd64/x86 als Hardware verwenden und sollten etwas RAM mitbringen, für ein kleines System reichen aber schon 4 GByte aus, um mehrere Container parallel zueinander laufen zu lassen. Vorteil: die Hardware mag kaputt gehen, aber der Container läuft unverändert auch auf der nächsten Hardware.
Alternativ zu Proxmox kann man das auch mit Docker machen, Proxmox kann halt auch echte VMn laufen lassen (Windows, CentOS, wie sie alle heißen, sogar MacOS wäre möglich), deshalb ist es bei mir Proxmox.
Docker kann man sogar auf einem Raspberry laufen lassen, allerdings sollte es dann mindestens ein Pi4 mit mindestens 4 GByte RAM sein, besser ein Pi5 mit 8 GByte RAM, und wenn man an dieser Stelle ist, kann man auch gleich einen alten NUC in der Bucht schießen, der dann nicht nur mindestens 8 GByte RAM hat, sondern auch einen viel potenteren Prozessor, eine SSD, ein Gehäuse und ein Netzteil.
Der Pi ist nur deshalb die empfohlene Plattform, weil er die kleinste Option ist und früher tatsächlich auch die günstigste Variante, zumal die meisten Bastler "irgendein" Gehäuse und Netzteil eh rumliegen haben.

Natürlich lässt sich dann das Homematic Modul so nicht mehr betreiben. Variante 1: Du lässt (ausschließlich) Homegear weiter auf dem Pi laufen und bindest das per IP an. openHAB kann damit umgehen auch schon in Version 2, wenn ich mich nicht komplett falsch erinnere.
Variante 2: ein USB-Stick, der die Aufgabe übernimmt und in den Container durchgereicht wird.

Selbstverständlich kannst Du openHAB aber auch weiter nativ auf einer Hardware Deiner Wahl betreiben. Nur: irgendwann musst Du die austauschen, und zu diesem Zeitpunkt muss das darauf laufende System so dicht wie möglich am aktuellen Stand sein, sonst verlierst Du mit einem Schlag alles.

Je nach Komplexität Deines Setups hast Du für einen Umstieg eine Menge Arbeit vor Dir - dafür hast Du ja aber bisher nichts gemacht ich habe damals das Update auf die 2er Generation lange aufgeschoben (fast zwei Jahre) und beim Update auf 3 war ich auch nicht der Schnellste aber zumindest habe ich mich bis zum Umstieg jeweils intensiv mit beiden Versionen beschäftigt, was schon hilfreich war.
Der Umstieg von 3 auf 4 war aber in einer Stunde erledigt, weil ich schon viel vorbereitet hatte - ich hatte das Produktivsystem konsequent aktuell gehalten, das war immer mal wieder mit ca. 10 Minuten Aufwand verbunden, lief aber ohne große Komplikationen (und ich nutze ausschließlich Textkonfiguration,d.h. ich muss alle Anpassungen immer manuell vornehmen).

Auch openHAB4 unterstützt uneingeschränkt die Textkonfiguration, soweit es den von openHAB2 bekannten Teil betrifft. Die MainUI (Nachfolger von PaperUI) muss jedoch immer über die Webschnittstelle konfiguriert werden (oder direkt über die API, aber das ist eine andere Geschichte)
Das heißt: alles, was Du unter /etc/openhab2/ konfiguriert hast, kannst Du zunächst in ein aktuelles System übernehmen. Jedoch werden v1-Konfigurationen nicht funktionieren (z.B. Items mit etwas anderem als {channel="..."})
Alles, was als v1 Binding installiert war, muss komplett neu gemacht werden. Things, die über die UI angelegt wurden, müssen vermutlich neu angelegt werden. Das ist aber noch der geringste Teil.
Viel aufwändiger sind dann meist die Rules, weil sich dort doch einiges geändert hat, insbesondere wurde Joda Time durch JavaTime ersetzt. Dabei sind viele Schlüsselbegriffe in beiden Bibliotheken vorhanden, nur leider teilweise mit unterschiedlichem Verhalten. Alles, was Timer und Berechnung von Zeitstempeln betrifft, muss also ziemlich sicher angepasst werden.

Dafür bekommst Du aber auch eine Menge "als Entschädigung für die Mühe", die UI ist übersichtlicher und bietet viel, viel mehr Optionen, es gibt Units of Measurement, d.h. die Einheit wird mit dem Wert mitgeführt und openHAB kann deshalb vollautomatisch zwischen verschiedenen Einheiten umrechnen (z.B. °C in K, mm in km, KbiByte im MByte usw.), es gibt wesentlich komfortablere Möglichkeiten, Timer anzulegen, man kann aus diversen Programmiersprachen auswählen, um Rules zu erstellen, mit Ephemeris können Feiertage berechnet und ausgegeben werden, buchstäblich hunderte neue Bindings bieten neuer IoT Hardware Zugang zu openHAB, es wurde eine native Webansicht auf das Logging integriert... die Liste gegenüber openHAB2.5.12 ist lang. Sehr lang...

Da im Sommer openHAB5 kommt, möchte ich noch auf ein kleines Details hinweisen , nämlich, dass openHAB5 nur noch 64 Bit unterstützen wird. Basis wird dann Java21 sein, und mutmaßlich wird das openHABian Image für den Pi4/5 dann kurze Zeit später auf debian Trixie aufsetzen. Schon aus diesem Grund ist man gut beraten, schon jetzt eine aktuelle Hardware zu beschaffen.

[Tentazione]

Nein...ich steuerte beide miteinander. Wie gesagt das OH2_5 ist nur! für die Heizungssteuerung zuständig. Da sind keine Kontakte und/oder Sensoren wie Fensterkontakte oder Bewegungsmelder drauf. Die sind auf anderen Systemen verdrahtet.

Proxmox (auf einem NiPoGi AK2 Plus Mini PC) nutze ich auch für Home Assistant, Oracle Datenbank, IOBroker...und alles schreibt und/oder liest sich seine benötigten Dinge aus dem MQTT-Broker. Sozusagen die allgemein gültige Schnittstelle ähnlich wie EDI oder VDA. Hab ich mir mal irgendwann überlegt, funktioniert auch ganz gut und ich kann das beste aus allen Welten nutzen #flöt Und ich kann ja dann im nächsten Jahr mal schauen ob ich OH5 auf meinen Proxmox einziehen lassen möchte.

Ich brauch jetzt nur nen Ansatz wie ich auf Änderungen von aussen (z.B. Fenster auf) mein Heizkörpertheromostat steuern kann. ICh hab mir schon mal ein paar Beiträge über Deine Waage oder die von Peter_Pan angeschaut. Die dort benannten "Lösungen" scheinen aber bei mir nicht zu laufen. Denn wenn ich eine Nachricht in die MQ lege...kommen die anscheinend nicht an. Ich erhalte keine Meldung das sich irgendein Zustand geändert hat.

Du lässt (ausschließlich) Homegear weiter auf dem Pi laufen und bindest das per IP an. openHAB kann damit umgehen auch schon in Version 2, wenn ich mich nicht komplett falsch erinnere.
Variante 2: ein USB-Stick, der die Aufgabe übernimmt und in den Container durchgereicht wird

Variante 1 lief ja bislang bei mir. Und wenn der alte Raspi 2 mal aufgibt...dann überlege ich eh den USB-Stick für die Homematic-Steuerung zu besorgen (wenn es den dann noch gibt)

Ich hoffe ich konnte Dir meine Ideen etwas plausibler machen. Es scheitert wahrscheinlich nur an Kleinigekeiten. Wäre aber schon wenn sich das irgedwie lösen lässt.

Nachtrag: Ich hab gerade noch mal geschaut....das CalDav-Binding zu Einbindung meines Synology-Kalenders ist da auch noch drauf. Das brauchte ich für die Steuerung der Heizung an gewissen Terminen/Events

[udo1toni]

Wozu drei Systeme? Es braucht nur exakt ein System, welches als Zentrale arbeitet. Auf dem Pi2 ist das nicht gut aufgehoben, auch Home Assistant möchte da etwas mehr Wumms haben. (By the way... Home Assistant verwendet Docker. Immer.)

Was die Kommunikation mit mqtt betrifft, so ist das jedenfalls kein allgemeines Problem, ich steuere hier diverse Dinge über mqtt, das habe ich auch schon unter openHAB1 gemacht, es wird sich also um ein Konfigurationsproblem handeln.
Aber wie schon erwähnt... der wichtigste Punkt ist, dass Du Dich für ein System entscheidest, auf dem alles läuft, ob nun openHAB oder Home Assistant, ist letztlich egal, aber diverse Systeme maximal komplex miteinander zu verbinden ist kein guter Ansatz.

[Tentazione]

ok. Hab ich verstanden! Schade

[udo1toni]

Warum schade? Was ich heraus lese, ist, dass Du Dir bisher sehr viel Arbeit gemacht hast, die halt unnötig ist.