Homematic Manager 2.x

[NickHM]

also watching schon mal nicht, denn dann kommt bei jeder Änderung eine mail.

Ich habe den Stern mal ausprobiert.
Danke

[jp112sdl]

Ich hab mir für die Benachrichtigung ein Skript gebaut, das im Cron alle 4 Stunden läuft und bei einer neuen Version eine Pushover-Nachricht schickt.

Code: Alles auswählen

#!/bin/bash
versionfile=./hmm-version.txt

onlineversion=`wget -nv -q  -O- "https://api.github.com/repos/hobbyquaker/homematic-manager/releases/latest"|jq -r ".tag_name"`

[[ ! -f ${versionfile} ]] && touch ${versionfile}

latestversion=`cat ${versionfile}` 

if [  ! -z $latestversion ] && [ $onlineversion != $latestversion ]
then
  /usr/local/bin/pushover.sh -Txxxxxxxxx -Uxxxxxxxxxx "Neuer HomeMatic Manager $onlineversion !"
fi

echo $onlineversion > ${versionfile}

Hint: jq (lightweight and flexible command-line JSON processor) wird benötigt!


Das pushover.sh Shellskript habe ich mal mit angehängt

[Prof.Mobilux]

Hallo Sebastian,

Klasse Porjekt und schön, dass Du es wiederbelebt hast. Ich habe eine Frage:

Ich arbeite an einer Anbindung von Homematic an das Loxone System. Wir sind eine Gruppe Entwickler, die den "LoxBerry" ins Leben gerufen haben. Das ist eine Distribution für den Raspberry, die über Plugins erweitert werden kann und verschiedene Dienste bereitstellen kann oder Hardware an das Loxone System anbinden kann: https://www.loxwiki.eu/display/LOXBERRY/LoxBerry

Ich möchte nun ein Plugin entwickeln, welches über das OCCU-SDK, einem HM-MOD-RPI-PCB und vermutlich hm2mqtt.js die Homematic-Komponenten an das Loxone-System anbindet. Aktuell ist dazu noch de rUmweg über eine CCU2 notwendig (aufwendige Einrichtung).

Ich möchte dazu den Homematic-Manager als Webservice auf dem Raspberry bereitstellen. Dort läuft ein aktueller Apache2. Ist das möglich? Im GIT-Repo sehe ich einen www-Ordner, der so aber natürlich nicht funktioniert. Leider kenne ich mit node.js zu wenig aus, als dass ich das alleine lösen könnte

Würde mich freuen, wenn Du mir unter die Arme greifen könntest.

Grüße
Michael

[hobbyquaker]

Ich möchte dazu den Homematic-Manager als Webservice auf dem Raspberry bereitstellen.

Das ist im Moment leider nicht möglich. In Version 1.x war der Hm-Manager noch ein Web-Applikation, seit 2.x hab ich das auf Electron umgebaut und damit viele Abhängigkeiten im Frontend auf Electron. Für die Zukunft habe ich vor einen Buildprozess zu schaffen der beides baut, eine Web App und eine Electron App, aber das ist was größeres und ich kann nicht sagen wann ich dazu komm. Vielleicht wirds 2019 was, vielleicht aber auch nicht. Dazu kommt noch dass ich mich ein wenig vor so einem großen Umbau scheue da die Frontend-Technologie mittlerweile völlig veraltet ist (jQuery...) und ich daher denke dass man das Frontend eh komplett neu machen sollte... Was das vorhaben noch größer werden lässt...

Dir bleibt da (im Moment und wenn Du es schnell ahben willst) nur einen Fork zu machen und die ganzen Electron Abhängigkeiten rauszuwerfen, ein neues Backend und einen neuen Communication Layer zu bauen - oder Deinen Usern zu sagen dass die die verfügbare Electron App nutzen sollen.

Ich möchte nun ein Plugin entwickeln, welches über das OCCU-SDK, einem HM-MOD-RPI-PCB und vermutlich hm2mqtt.js die Homematic-Komponenten an das Loxone-System anbindet. Aktuell ist dazu noch de rUmweg über eine CCU2 notwendig (aufwendige Einrichtung).

Ein Gedanke zu Deinem Projekt im Allgemeinen: Der Hm-Manager ist imho nicht "Endusertauglich", das ist ein Tool für Leute die genau wissen was sie tun und fundierte Kenntnisse der Homematic-Geräte/Paramsets usw. haben. Man kann sich mit dem Ding auch massiv "in den Fuß schiessen". Warum nicht direkt auf CCU3/RaspberryMatic aufsetzen und eure "Zusätze" inklusive der Loxone Anbindung als Addon dafür bereitstellen? Oder auf RedMatic aufsetzen?

hm2mqtt.js habe ich übrigens "deprecated" - ich werde daran nichts mehr machen. Ist in RedMatic bzw. im MQTT Node von node-red-contrib-ccu aufgegangen.

[Prof.Mobilux]

Dir bleibt da (im Moment und wenn Du es schnell ahben willst) nur einen Fork zu machen und die ganzen Electron Abhängigkeiten rauszuwerfen, ein neues Backend und einen neuen Communication Layer zu bauen - oder Deinen Usern zu sagen dass die die verfügbare Electron App nutzen sollen.

Das wird es dann wohl werden - das andere ist mir "eine Nummer zu groß" Ist ja aber auch OK - die Funktion ist ja identisch. Der Webservice hätte sich nur gut ins "Gesamtbild" eingefügt.

Ein Gedanke zu Deinem Projekt im Allgemeinen: Warum nicht direkt auf CCU3/RaspberryMatic aufsetzen und eure "Zusätze" inklusive der Loxone Anbindung als Addon dafür bereitstellen? Oder auf RedMatic aufsetzen?

Unser Konzept ist ein etwas anderes. Das Hauptsystem ist bei unseren Usern der Loxone Miniserver. Homematic nutzen viele eigentlich nur auf Grund der großen Vielzahl an Sensoren/Aktoren und weil diese recht preiswert sind. Daher braucht niemand der Loxoner eine CCU oder ein RaspberryMatic. Auch die ganzen Script-Funktionen sind für uns unwichtig, da die Logik komplett auf dem Loxonesystem läuft. Der LoxBerry stellt bei uns eine Vielzahl an AddOns für das Loxone-System bereit - z. B. Wetterserver, 1-Wire-Anbindung, Logitech Media Server Anbindung usw. Ein zusätzliches AddOn wäre dann eben die Homematic-Anbindung.

hm2mqtt.js habe ich übrigens "deprecated" - ich werde daran nichts mehr machen. Ist in RedMatic bzw. im MQTT Node von node-red-contrib-ccu aufgegangen.

Das habe ich leider gesehen Letztendlich mag ich den MQTT-Gedanken, deswegen möchte ich es trotzdem probieren. Wenn es nicht (mehr) funktionieren sollte, müsste ich einen eigenen TCP-Daemon schreiben, der mit dem RFD kommuniziert.

[hobbyquaker]

Das Hauptsystem ist bei unseren Usern der Loxone Miniserver.

Ah verstehe, dachte das basiert auf einem weiteren Pi, so macht das natürlich Sinn

Wenn es nicht (mehr) funktionieren sollte, müsste ich einen eigenen TCP-Daemon schreiben, der mit dem RFD kommuniziert.

Funktionieren sollte das schon noch, allerdings werde ich selbst da nichts mehr dran machen da ich es selbst gar nicht mehr nutze, die MQTT Anbindung wird bei mir komplett über RedMatic bewerkstelligt. Aber auch da ist es ja möglich einen Fork zu machen und bei Bedarf selbst Fehler zu beheben oder Dinge hinzuzufügen.

[hdiessner]

Hallo Sebastian,

danke für Deine super Arbeit.
Ich versuche gerade hm2mqtt durch RedMatic zu ersetzen, komme aber bei der Beschreibung im Wiki (https://github.com/HM-RedMatic/RedMatic/wiki/Flow-MQTT) nicht weiter.
MQTT Subscribe Node ---> CCU MQTT Node ---> MQTT Publish Node
wirft einen Fehler: "no interface found for channel <Serialnumber des HM Device>"
RedMatic läuft auf einem Raspberrymatic (RPi 3+), Mosquitto in einem Docker Container auf einer Diskstation.

Mit hm2mqtt habe ich HM Devices steuern können über MQTT messages und die Devices haben ihren Status über MQTT messages ausgegeben. Kann ich dies auf einfache Weise mit dem CCU MQTT Node nachbilden? Könnte eine Erweiterung des Wiki Beitrags für mehr Klarheit sorgen (etwa die Konfigurationen der Nodes)?

Danke und Gruß

Herwig

[hdiessner]

Ha, hab es selbst gefunden - hier war die Ursache des gesamten Problems: https://github.com/HM-RedMatic/node-red ... /issues/36
Jetzt läufts.

Gruß
Herwig

[HMNutzer]

Servus,

danke für das tolle Tool.
Gibt es irgendwo eine Beschreibung der Felder, die ich übersehen haben könnte?
Im Reiter Funk werden oben die Interfaces aufgeführt; daneben ist eine Spalte mit der Überschrift "Description". Die Zeilen darunter sind leer. Ich würde da gerne reinschreiben, welche ID welches LAN-Gateway bzw. die CCU/RM ist.
Kann mir bitte jemand sagen, wie ich die Inhalte bearbeiten kann?

[NickHM]

Hallo

bei mir ist das Beschreibungsfeld nicht grundsätzlich leer.
Wobei der Typ der Zentrale nicht stimmt, denn wie man an der FW deutlich sieht ist es eine 3.x
Das ist aber wohl ein eq-3 Problem, wenn man mit einem Backup der CCU1 / 2 migriert.