Neues Modul HMCCU für Homematic CCU

Begonnen von zap, 19 August 2015, 19:45:30

Vorheriges Thema - Nächstes Thema

Ralli

 :)

Top - vielen Dank, dass Du Dich weiter darum kümmerst - ich denke, dass das der vielversprechendste Ansatz ist!
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

zap

So, der RPC Server läuft soweit. Weiß nicht, ob ich mich darüber freuen soll, bedeutet nun noch etwas Arbeit  ;):

- Einbindung der RPC Server Ausgabe in HMCCU
- Ergänzung der Device-Names um die benutzerdefinierten Namen aus der CCU (ich mag diese LE00xyz Bezeichnungen nicht)
- Evtl. autocreate von FHEM Devices
- Handling möglicher Fehlersituationen
- ...

Um es gleich vorweg zu sagen: Vermutlich wird die neue Version von HMCCU/HMCCUDEV nur auf Linux und MacOSX laufen. Und auf XML-API will ich auch nicht verzichten, da es Informationen liefert, an die ich per RPC nur schwer oder gar nicht ran komme. Wird also so eine Art Mischbetrieb werden.

Demnächst mehr in diesem Kino.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Ralli

#47
zap, gaaaanz große Klasse. Vielen vielen Dank!

Und genau so (als Mischbetrieb) hatte ich mir das in meiner theoretischen Naivität vorgestellt :).

Edit:

Da hat eq-3 heute ein paar Spezifikationen neu in den Download-Bereich eingestellt, z.B.

http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/Tutorials/HM_XmlRpc_API.pdf

Ausserdem ist die Firmware 2.15.5 der CCU2 erhältlich.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

EdgarM

zap,

das hört sich echt gut an. Falls du Hilfe benötigst, kannst gerne auf mich zu kommen.

grüße

zap

@EdgarM: Danke für das Angebot. Im Moment läuft es aber ganz gut  :)

@Ralli: Die Doku kenne ich. RPC ist auch keine Thema mehr. Den RPC-Teil habe ich fertig, d.h. ein separates Perl-Script, das als RPC Server im Hintergrund läuft und für FHEM die Nachrichten der CCU in einer Queue bereitstellt.

Einziges Fragezeichen hier: Der RPC-Init-Call, also die Registrierung der Callback-URL bei der CCU, dauert sehr lange (2-3 Minuten). Keine Ahnung warum. Wäre aber nur beim FHEM Start relevant.

Nun fehlt noch die Verbindung zu HMCCU. Nächste Woche habe ich Urlaub. Da könnte es was werden.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Ralli

Hallo zap,

viel Erfolg ;).

Um die Devices, die man über HMCCU definiert, auch bspw. in (gemischte!) Strukturen einbinden zu können, wäre es wichtig, die wichtigsten Standard-Kommandos verwenden zu können und den state entsprechend zu setzen. Also bei mir wären das bspw.

set device on
set device off
set device toggle
set device on-for-timer
set device on-till
set device statusRequest
set device 0..100 [x y] # x y für Dimmer mit Rampe und Zeit
set device red|orange|green
set device ilum x y
set device desired-temp 5..30|on|off
set device controlMode auto|manu
usw.

Aber ich meine, das hättest Du - zumindest teilweise - auch schon eingebaut.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

philipp485

Erstmal großes Lob für die Mühe! Nachdem es beim Hausbau noch an der Baugenehmigung hakt habe ich in der Zwischenzeit endlich einen kleinen Rechner als FHEM-Server aufgebaut und bin gerade am Rumspielen mit der CCU2-Einbindung. Aber leider bekomm ichs nicht ans Laufen...irgendwie scheint er die URLs zur Abfrage falsch zusammenzubauen. Wahrscheinlich hab ich nur einen kleinen (Denk-)fehler irgendwo.

Nehmen wir als Beispiel das HM-Thermometer ... meine CCU ist als "CCU2" defined.
Schicke ich nun ein "get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE" los bekomme ich den Fehler "HMCCU: CCU2 Error during CCU request".

Im FHEM-Log sehe ich als Aufruf-URL:
http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1.TEMPERATURE").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value()

Rufe ich die im Browser auf bekomme ich als Rückgabe im XML:
<r1>BidCos-RF.LEQxxxxxxx:1.TEMPERATURE</r1>

Jetzt habe ich mal etwas rumprobiert und bei Eingabe folgender URL im Browser: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQ0799970:1.TEMPERATURE").Value() bekomme ich als Rückgabe im XML:
<r1>10.200000</r1>
also den korrekten Temperaturwert.

Hier noch der komplette Log-Auszug:

2015.10.25 00:05:08 4: FHEMWEB:192.168.0.39:54912 POST /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE; BUFLEN:0
2015.10.25 00:05:08 5: Cmd: >get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE<
2015.10.25 00:05:08 4: HttpUtils url=http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxx:1.TEMPERATURE").Value()
2015.10.25 00:05:08 4: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): HTTP response code 200
2015.10.25 00:05:08 4: HttpUtils http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): Got data, length: 114
2015.10.25 00:05:08 5: Triggering CCU2 (1 changes)
2015.10.25 00:05:08 5: Notify loop for CCU2 Error
2015.10.25 00:05:08 1: HMCCU: CCU2 Error during CCU request
2015.10.25 00:05:08 4: name: /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE / RL:1112 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.10.25 00:05:08 4: Connection closed for FHEMWEB:192.168.0.39:54910: EOF


Jetzt frage ich mich, was denn bei mir falsch läuft, dass das nicht klappt.  :(

zap

#52
Du gibst im GET Befehl die korrekte Adresse (d.h. vollständige) Adresse eines Datenpunktes an. Das hatte ich bisher in HMCCU nicht berücksichtigt, werde es aber in der kommenden RPC-Version des Moduls einbauen. Bis dahin gilt folgendes Format für die Angabe eines Datenpunktes:

Channel-Name.Datenpunkt

In Deinem Beispiel wäre Datenpunkt=TEMPERATURE. Nun musst Du noch den Namen des Kanals in Deiner CCU rausbekommen. Wenn Du in der CCU "Einstellungen / Geräte" aufrufst, steht der in der Spalte Name. Hier nun den Namen auswählen, der auf den richtigen Kanal (beim Thermostaten HM-TC-IT-WM-W-EU ist das Kanal 1) verweist.

Bei der neuen Modulversion werde ich etwas mehr Intelligenz in die Namens-/Kanal-/Adressangabe einbauen.

Zur Verdeutlichung  ein kleiner Auszug aus meiner CCU Konfiguration:


<device name="KL-AZ-TH" ise_id="4927" unreach="false" sticky_unreach="false" config_pending="false">
  <channel name="KL-AZ-TH:0" ise_id="4928" visible="" operate="">...</channel>
  <channel name="KL-AZ-TH:1" ise_id="4957" visible="true" operate="true">
    <datapoint name="BidCos-RF.LEQ1462664:1.TEMPERATURE" type="TEMPERATURE" ise_id="4959" value="18.100000" valuetype="4" valueunit="°C" timestamp="1445769481" operations="5"/>
    <datapoint name="BidCos-RF.LEQ1462664:1.HUMIDITY" type="HUMIDITY" ise_id="4958" value="65" valuetype="16" valueunit="%" timestamp="1445769481" operations="5"/>
  </channel>


Hinter "datapoint name" steht der Name des Datenpunktes. Adressiert wird der momentan in HMCCU aber über den "channel name", den man in der CCU frei vergeben kann sowie den Teil des datapoint names hinter dem letzten Punkt (hier "TEMPERATURE" oder "HUMIDITY").

Das Ganze ist meiner Faulheit geschuldet, mir die kryptischen Datenpunktnamen merken zu müssen. Ich habe den Kanälen sprechende Namen gegeben. Das kann ich mir leichter behalten  ;)

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

#53
Ich habe eine neue Version von HMCCU (IO-Device) und HMCCUDEV (Client-Devices) im Contrib Zweig abgelegt (Link siehe 1. Post).

Die Adressierung von CCU-Kanälen wurde komplett überarbeitet. Die set und get Befehle akzeptieren nun folgende Angaben:

Channel-Name[.Datapoint]
[Interface.]Channel-Address:Channel-Number[.Datapoint]

Das Modul benötigt die Perl-Module XML::Simple und File::Queue.

Das Modul HMCCU enthält bereits Attribute und Programmcode für die folgende Version, die einen RPC-Server enthalten wird. Die RPC Attribute können noch nicht verwendet werden.

Bei der Definition eines HMCCU Devices in FHEM wird die Devicelist der CCU gelesen. Daher muss nach dem Update auf die aktuelle Version FHEM neu gestartet oder das HMCCU Device neu angelegt werden. Wenn in der CCU ein neues Gerät angelegt wird, muss der Befehl get <name> devicelist in FHEM ausgeführt werden.

Bitte die Datei HMCCU_Readme.txt im Contrib Verzeichnis lesen. Dort ist auch die Verwendung von Client Devices beschrieben.

Noch was: das Attribute stateval wurde in statevals umbenannt.

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

EdgarM

Hi zap,

danke schon mal für den Ausblick auf die RPC Version ;)

Abermal eine Frage:

Ich habe das neue Modul geholt, alles gelöscht und die hmccu wieder neu erstellt, neu gestartet und get hmccu devicelist augeführt.

Leider sehe ich keinerlei Information, dass etwas passiert. Sollten einträge erstellt werden dadurch? in einer Datei?

grüße
und Danke

zap

Du musst "get devicelist" nur ausführen, wenn sich an Geräten in der CCU etwas geändert hat. Die Geräte werden beim FHEM Define automatisch gelesen.

Sehen kann man das Einlesen am Internal DevCount in der Ansicht des HMCCU Devices. Dort sollte eine Zahl > 0 stehen. Derzeit legt HMCCU nicht automatisch irgendwelche Client Devices (Modul HMCCUDEV) an.

Wenn ein HMCCU Device definiert ist, kannst Du CCU Gerätekanäle bzw. Datenpunkte auslesen, z.B.

get <devname> datapoint <addresse>.<datenpunkt>

get <devname> datapoint <channel-name>.<datenpunkt>

Im HMCCU Device wird der ausgelesene Wert dann als Reading gespeichert. Alternativ können für einzelne Geräte mit HMCCUDEV auch Client Devices angelegt werden.

Wichtig ist nur: get devicelist muss mindestens einmal ausgeführt worden sein. Sonst kennen weder HMCCU noch HMCCUDEV Befehle die Kanalnamen oder Kanaladressen. Dann geht nix. Und wenn man das HMCCU Modul reloaded, muss get devicelist ebenfalls ausgeführt werden.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Tscherno

Zap! Das ist genau das Modul, welches ich vermisst habe. Ich verstehe, dass sich mit der FHEM-Architektur nicht leicht ein XML-RPC für die CCU bauen lässt, aber das hier ist als Übergangslösung perfekt. Ich habe mir eine Zeitlang OpenHAB nur aus dem Grund angeschaut, weil die eine ziemlich gute Anbindung an die CCU haben. Leider ist die Unterstützung für den RFXTRx, weswegen ich hauptsächlich zusätzlich zur CCU etwas brauche, miserabel. Ausserdem ist die Entwicklung für FHEM gefühlt wesentlich aktiver. Die Architektur von OH dahingegen ist natürlich schon nett... Allerdings bin ich mehr Freund von Perl ;) Lassen wir das, ich will hier keine Diskussion FHEM vs. OH vom Zaun brechen, vielleicht baut ja mal jemand eine Brücke...

Worum es mir eigentlich geht: Ich habe eben etwas mit deinem Modul gespielt. Lief leider erstmal nicht. Grund: Ich bekomme einen Timeout bei der Devicelist. Meine CCU ist durchaus ziemlich voll. Das Problem konnte ich schnell lösen, ich habe den Timeout beim entsprechenden GetFileFromURL auf 10 Sekunden gesetzt, das reicht mir. Vielleicht könntest Du dazu einen Parameter bei der Deklaration hinzufügen?

Mein erster Versuch war es, einen Schalter zu setzen. Ich würde nämlich als erstes Projekt gerne etwas mit Homebridge (läuft bereits) bauen um meine Homematic-Aktoren zu steuern. Der erste Versuch sieht so aus:

define CCU HMCCU 192.168.1.10
define Licht_Buero HMCCUDEV JEQ0295121 1
attr Licht_Buero IODev CCU
attr Licht_Buero room Homematic,Homekit

So weit, so gut, die Daten werden von der CCU korrekt ausgelesen, Anbindung passt scheinbar.

Bei einem "set  Licht_Buero devstate 1" crasht mir allerdings FHEM:
2015.11.26 10:29:25 4: FHEMWEB:192.168.1.23:9811 POST /fhem&fw_id=67&room=Homematic%2CHomekit&cmd=set++Licht_Buero+devstate+1; BUFLEN:0
2015.11.26 10:29:25 5: Cmd: >set  Licht_Buero devstate 1<
2015.11.26 10:29:25 4: HttpUtils url=http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1")
2015.11.26 10:29:25 4: http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): HTTP response code 200
2015.11.26 10:29:25 4: HttpUtils http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): Got data, length: 115
2015.11.26 10:29:25 5: Triggering CCU (1 changes)
2015.11.26 10:29:25 5: Notify loop for CCU OK
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 208.

Zeile 208 => usleep (100000);

Ich glaube usleep ist ein Teil von Time::HiRes welches ich nicht hatte und welches auch nicht geladen war. Ich habe die beiden usleep-Aufrufe auf sleep(1) geändert, damit klappt es.

Nächste Frage: Kann man FHEM irgendwie sagen, dass es sich dabei um einen Schalter handelt?


zap

Ja, Time::Hires wird benötigt. Was meinst Du mit "Schalter"? Sowas in der Form:

set Licht_Buero on

Das sollte mit der aktuellen Version schon gehen:

attr CCU statevals on:true,off:false

Danach bietet Dir das Device im Webinterface automatisch die Links on und off an.

Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)

Muss nur noch die Doku anpassen.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Ralli

Zitat von: zap am 26 November 2015, 11:57:17
Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)

Muss nur noch die Doku anpassen.

Ich verbeuge mich ;) !
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

zap

#59
Neue Version mit RPC Server ist nun verfügbar (s. 1. Post in diesem Thread).
Bitte die Voraussetzungen (Perl-Pakete) insbesondere für den RPC-Server beachten (Datei HMCCU_Readme.txt).

Änderungen / Neuerungen:


  • RPC Server als separater Prozess
  • Verwendet native Homematic Script für die Kommunikation mit der CCU (kein XML-API mehr erforderlich)
  • Separate Module für IO, CCU-Geräte und CCU-Kanäle
  • Änderungen an Readings im IO Device können an Client-Devices propagiert werden
  • Ausführung beliebiger Homematic Scripts aus FHEM heraus. Ergebnisse werden als Readings gespeichert

Einschränkungen:

Die RPC Schnittstelle der CCU unterstützt nur BidCos Geräte. Daher aktualisiert der RPC Server z.B. keine CUxD Geräte. Diese müssen per AT Device mittels get Befehl aktualisiert werden.

Nach dem Starten des RPC-Servers vergehen exakt 3 Minuten, bis die ersten Events aus der CCU in FHEM ankommen. Das scheint eine Eigenart der CCU zu sein. Während dieser 3 Minuten reagiert das Web-Interface der CCU sehr träge bis gar nicht.

Der RPC-Server aktualisiert nur Readings/Datenpunkte von definierten Devices. Alle anderen Events werden ignoriert.

Die Kommunikation zwischen dem RPC-Server und FHEM erfolgt über eine Datei basierte Queue. Wer Angst um seine SD-Karte hat, kann die Queue in eine RAM-Disk legen. Wie das geht, ist in HMCCU_Readme.txt beschrieben.


2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)