Neues Modul HMCCU für Homematic CCU

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

Vorheriges Thema - Nächstes Thema

harway2007

habe mit cpan das Modul versucht zu laden
cpan install XML::Simple dann Neustart ...

erhalte dann diese Logfile Meldung und den Fehler Cannot load module HMCCU:

2015.09.21 11:47:33 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.

2015.09.21 11:47:33 0: Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.

erbitte Hilfestellung ..

Ralli

Was heißt "versucht" ?

Als root bzw. mit sudo nachinstallieren.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

#32
Zitat von: Ralli am 21 September 2015, 09:58:56
Ich hätte da aber mal einen anderen Ansatz bzw. eine andere Idee:

Statt die CCU2 über das Modul zu definieren und dann letztendlich immer mit diesem einen definierten Device zu arbeiten, fände ich es deutlich besser und sinnvoller, die tatsächlich in fhem darzustellenden, zu schaltenden bzw. zu nutzenden Geräte wie bislang auch zu definieren und als Typ (und Schnittstelle) das Modul zu nehmen, welches mit der CCU2 kommuniziert.

Anders ausgedrückt:

define MeinSchalter HMCCU MeineCCU2IP:Device DeviceHMID

Das hätte den unschätzbaren Vorteil, die Geräte wie bisher auch in fhem - mit allen Events, Triggern usw. - einbinden zu können, nur dass Schaltbefehle und Requests eben nicht mehr über die IOs für CUL_HM laufen sondern über die CCU2.

mm, Geräte schalten über die CCU aus FHEM heraus geht ja im Moment schon mit HMCCU:

set MeineCCU devstate MeinSchalterKanal true

Bei Deiner Variante wäre der set Befehl minimal einfacher (sprechender?):

set MeinSchalter devstate true

Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.

Oder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.
RPC und CCU ist ein weites Feld. Damit kann man sich die CCU abschiessen. Insofern würde ich gerne bei XML-API bleiben.

@harway2007:

Welche Fehlermeldung wirft "cpan install" ? Oder ist die Installation erfolgreich?

P.S. Bitte beachten: die aktuelle Version des Moduls gibt es ab sofort immer im SVN (Contrib Zweig, siehe Link im ersten Post).
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

#33
Zitat von: zap am 21 September 2015, 12:37:12
Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.

Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.

Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.

So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.

Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.

ZitatOder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.

Wenn ich ehrlich bin, wäre das im Endeffekt die perfekte Lösung. Weg vom (alleinigen) Pollen hin zu der Möglichkeit, auf "Anrufe" der CCU2 zu reagieren.

Edit:

Gerade gesehen, dass dies der Funktionalität von dem "alten" HMRPC-Modul entspricht  :o :

http://forum.fhem.de/index.php?topic=12642.0

Edit2:

Und überschneidet sich hiermit:

http://forum.fhem.de/index.php/topic,41060.msg332596.html#msg332596

Vielleicht solltet Ihr Euch zusammentun :).
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

Zitat von: Ralli am 21 September 2015, 13:05:23
Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.

Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.

So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.

Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.


Verstanden. Das mit den Räumen usw. hatte ich nicht bedacht. Die Erweiterung wäre ziemlich einfach. Mal sehen, wie schnell HMRPC einen stabilen Reifegrad erlangt ...

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

harway2007

@Ralli
hatte sudo bei cpan ... vergessen HMCCU wird jetzt geladen ...
DANKE ....


zap

Im contrib Zweig in Sourceforge (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/) gibt es nun ein weiteres Modul 88_HMCCUDEV.pm. Dieses Modul implementiert Client Devices für die CCU. 88_HMCCU.pm ist das IO Device.

Beispiel 1:

define Fenster1 HMCCUDEV WIN-WZ-1

"WIN-WZ-1" ist der Name des Tür-/Fenstersensors in der CCU.

Beispiel 2:

define Steckdose HMCCUDEV STEHLAMPE-WZ
attr Steckdose stateval on:true,off:false
set Steckdose devstate on
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

#37
Top! Und vielen Dank.

Aber ich hätte zwei Vorschläge:

1)

define Fenster1 HMCCUDEV CCU2:WIN-WZ-1


... wobei CCU2 hier die über das Modul HMCCU definierte CCU2 ist. Warum? Ganz einfach, so kannst Du mehrere CCU2s in fhem integrieren. Das könnte in manchen Situationen sinnvoll sein, wenn bspw. zwei oder mehr "Kreise" genutzt werden.

2)

set Steckdose (devstate) on


... das devstate sollte/könnte eigentlich überflüssig sein. Ich würde es als sinnvoll erachten, wenn Schaltzustände an das Device unmittelbar entsprechend der Standard-Art übermittelt werden könnten (also set Steckdose on, off, 0..100). Das Attribut stateval könnte stattdessen eventmap heissen.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

#38
Das mit den 2 CCUs ist jetzt schon möglich. Einfach im Attribut IODev ein anderes HMCCU Device angeben. Standard bei Client bzw. IO- Devices in FHEM.

Statt devstate kann man jetzt auch on und off direkt angeben. Allerdings muss man das Attribut stateval auf on:true,off:false setzen. Sonst wird on bzw off an die CCU geschickt. Die erwartet aber true oder false bei STATE. Das Attribut stateval legt gleichzeitig die möglichen set Befehle über die Texte vor den Doppelpunkten fest. "on:true,off:false,standby:lala" legt also on, off und standby als Set Befehle neben devstate und datapoint fest.

Außerdem kann man nun Devices als readonly, d.h. ohne Set Befehl anlegen. Sinnvoll z.B. für reine Sensoren. Dazu wird beim Anlegen des Devices einfach readonly an das Define Command angehängt, z.B.

define d_fenster HMCCUDEV TF-Wohnzimmer readonly


2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

Hallo zap,

bin jetzt seit längerer Zeit erst nochmal zum Experimentieren gekommen.

http://forum.fhem.de/index.php/topic,42212.msg345535.html#msg345535

Ich bin der Auffassung, dass die eierlegende Wollmilchsau das ideale wäre. Wenn in das HMCCU-Modul noch der HMRPC-Provider mit eingebaut würde und man so diese Möglichkeit (optional) mit nutzen könnte, und im Endeffekt Devices aus/mit beiden Kommunikationssträngen gefüttert und gesteuert werden könnten.

Vorteil: Ein Device definiert, welches echte Events generieren kann und alle Vorteile mit "übersetzten" set's und get's und den sonst von Dir eingebauten Benefits hat.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

dechris

Ich habe da mal so eine Verständnisfrage. Ich kann ja CCU2 Devices direkt über FHEM ansteuern. Würde ich denn per notify mitbekommen, wenn ein 6 Fach Taster gedrückt wurde? Würde gerne zu denn CCU2 gespeicherten Befehlen noch zusätzliche Aktionen per FHEM starten.

Ralli

Wenn per HMRPC angebunden, dann ja. Wenn per HMCCU angebunden, dann erst nach einer Zeitspanne X, wenn ein erneutes Polling durchgeführt wurde.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

#42
Wie ich schon an anderer Stelle geschrieben habe, glaube ich, dass die direkte Implementierung eines RPC Servers in FHEM zwar möglich, aber mit diversen Unwägbarkeiten verbunden ist (z.B. dass der ein oder andere Event von der CCU verloren geht oder FHEM "bockt").

m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.

Der Rückweg von FHEM zur CCU ist trivial bzw. mit den vorhandenen Methoden der CCU als HTTP-Request möglich, so wie das HMCCU heute schon macht.

In etwa so:


CCU ---(RPC)---> Collector-Prozess ---> Queue ---(Polling)--->FHEM

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

Zitat von: zap am 18 Oktober 2015, 13:43:36
m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.

Dieser Ansatz hört sich interessant an! Ggf. wäre auch da noch nicht einmal ein ständiges Polling notwendig, wenn man eine Möglichkeit findet, einen Interrupt auszulösen, sobald etwas in der Queue liegt. Aber, sei mir nicht gram, ich bin hier nur Theoretiker, mit meinen minimalsten Programmierkenntnissen kenne ich mich in der Struktur von fhem überhaupt nicht aus.

Das erinnert mich ein bisschen an die "normale" Einbindung eines IOs. CUL_HM macht es doch wahrscheinlich auch nicht anders. Die von den IOs empfangenen (und zu sendenden) Messages wandern in einen Stapel und werden der Reihe nach abgeholt und abgearbeitet.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

Die Problematik in diesem Fall liegt tiefer in der FHEM Architektur. Für die Bearbeitung der CCU Benachrichtigungen muss FHEM bzw. das HMRPC / HMCCU Modul permanent Netzwerkverbindungen der CCU entgegennehmen und abarbeiten muss. Da FHEM nicht multithreading fähig ist, muss das alles in der großen FHEM Hauptschleife passieren, was FHEM teilweise blockiert oder zu Problemen in der CCU führt.

Ich habe jetzt mal mit einem standalone Programm experimentiert. Grundsätzlich funktioniert die Kommunikation mit der CCU, mit Events gibt es jedoch Probleme (s.a. hendryks thread). Wenn ich das zum Laufen bekommen, steht der oben skiziierten Lösung vermutlich nichts mehr im Wege.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB