Neues Modul HMCCU für Homematic CCU

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

Vorheriges Thema - Nächstes Thema

zap

Ich habe eine neue Version von 88_HMCCU.pm eingecheckt (Link siehe 1. Post).

Es gibt nun ein neues Attribut "ccutrace", das eine bessere Fehleranalyse ermöglicht. Mit dem Attribut wird ein regulärer Ausdruck für CCU Geräteadressen und/oder CCU Gerätenamen festgelegt. Bei Ausführung der Befehle "get datapoint", "get devstate", "get update" oder "get deviceinfo" werden für die festgelegten Geräte ausführliche Informationen in das FHEM Logfile geschrieben (Loglevel 1).

@hometux: In Deinem Fall solltest Du das Attribut wie folgt setzen:

attr ccu ccutrace (LEQXXX6818|name_in_ccu)

XXX und name_in_ccu durch entsprechende Werte ersetzen.

Dann "get Verschluss_Schwingtor update" und "get Verschluss_Schwingtor deviceinfo" ausführen (für HMCCUDEV Device) und die Ausgabe in fhem Log per Forum-Mail an mich (damit Du die Orginaladressen und Namen nicht hier im Forum posten musst).
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

#196
Neue Version der Module 88_HMCCU* sowie vom RPC-Server ccurpcd.pl eingecheckt.

Fehlerbehebungen:



  • Befehl get rpcstate lieferte u.U. falsche Aussage über laufenden RPC-Server Prozess

Neue Funktionen:



  • Mit dem Attribut "rpcport" kann nun eine Liste von CCU Ports angegeben werden, um gleichzeitig Ereignisse von BidCos-RF (Port 2001) und Wired Devices (Port 2000) zu empfangen (attr name rpcport 2001,2000). Es werden dann 2 RPC-Server Prozesse gestartet. An den Namen der Queue-Files sowie an den Namen des RPC Server Logfiles wird die Portnummer angehängt, d.h. die Prozesse verwenden separate Dateien (z.B. ccurpcd_2000.log und ccurpcd_2001.log).
  • Mit dem Attribut "ccuget" kann die Methode festgelegt werden ("State" oder "Value"), mit der die get Befehle Datenpunkte auslesen. Per Default wird "Value" verwendet. Diese Methode liest die Werte von Datenpunkten aus der CCU. Die Methode "State" erzwingt hingegen das direkte Abfragen der Geräte. Das dauert zwar länger und belastet die Batterien der Geräte, es kann jedoch bei einigen Geräten notwendig sein, um korrekte Werte zu erhalten. Wenn in einem Client Device "ccuget" nicht gesetzt ist, aber im IO-Device, dann wird das Attribut vom IO-Device verwendet. Ich empfehle, das Attribut ccuget = "State" nur Device bezogen zu verwenden, d.h. bei den Devices, bei denen 'Value' nicht korrekt funktioniert.
  • Bei den Befehlen "get update" und "get deviceinfo" kann optional die Abfragemethode "State" oder "Value" angegeben werden (derzeit nur per Kommandozeile). Auf diese Weise kann getestet werden, ob das Setzen des Attributs "ccuget" sinnvoll ist. Der direkt im Befehl angegebene Parameter hat Vorrang vor dem Attribut 'ccuget'.

Beispiel für HMCCUDEV/HMCCUCHN Devices:


get mydevice update State


Beispiel für globales Update aller Devices (Vorsicht, stresst die CCU bei vielen Devices, die Angabe .* ist notwendig, da man beim update Befehl von HMCCU einen Device-Filter angeben kann):


get myIOdevice update .* State


Es wäre schön, wenn mal jemand mit BidCos und Wired Devices den Parallelbetrieb von 2 RPC-Servern testen könnte, d.h. die automatische Aktualisierung der Readings in FHEM (ich habe keine Wired Komponenten).

P.S. Die Doku HMCCU_Readme.txt habe ich noch nicht aktualisiert.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

Kleiner Bugfix für 88_HMCCU.pm eingecheckt. Befehl "get devstate" sollte nun wieder funktionieren. Sorry. Hatte gestern Abend alles getestet bis auf get devstate. Und genau da einen riesen Bock eingebaut ;-)
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

hometux

Hallo zap,

Das neue Release sieht richtig gut aus! get devstate funktioniert wie erwartet und der rpc Dienst arbeitet mit Wired und Wireless Port gleichzeitig.

Herzlichen Dank!

zap

#199
Habe gerade neue Versionen der Module (88_HMCCU*) eingecheckt. Ich nenne die Version jetzt mal die "Rauchmelder Version". hometux weiß, wovon ich rede ;-)

Hintergrund: Aus mir unerfindlichen Gründen funktioniert die Homematic Script Funktion EnumUsedIds() bei Rauchmeldern für die Datenpunkte im Kanal 1 (hier liegt STATE) nicht. Das hatte Auswirkungen auf die Befehle "get update", "get channel" und "get deviceinfo". Der Fehler tritt interessanterweise auch bei XML-API auf. Das habe ich nun behoben, d.h. diese Funktion wird einfach nicht mehr verwendet. Ich denke, das ist ein Bug in der CCU Software.

Außerdem habe ich noch eine neue Funktion eingebaut: HMCCU berücksichtigt nun auch RPC Delete Device Events. D.h. wenn in der CCU ein Gerät gelöscht wird, das in FHEM als Device vorhanden ist, wird dieses Device als "Deleted" markiert und kann nicht mehr für Set/Get Aktionen verwendet werden. Das FHEM Device bleibt jedoch bis zum nächsten Restart (ohne Funktion) erhalten.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

christoph_j

Hallo zap,

welche Attribute müssen gesetzt werden, um den HM-LC-BL1-FM Funk-Jalousieaktor aus FHEM mit dem HMCCUDEV bedienen zu können? Mir fehlt die Möglichkeit per Schieberegler die Position bestimmen zu können.

Gruß,
Christoph

zap

Hmm, damit habe ich mich noch nicht beschäftigt. Ich nutze Tablet-UI. Dort genügt es, im Widget den entsprechenden Datenpunkt anzugeben.

HMCCU ist sehr generisch gehalten, d.h. die verschiedenen Homematic Typen erfahren keine Sonderbehandlung wie z.B. un CUL_HM.

Ich weiß nicht, was hier mit FHEM Bordmitteln wie webCmd usw. möglich ist.

Der Kanal und Datenpunkt, über den die Steuerung erfolgt, ist Dir bekannt?

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

christoph_j

Hallo zap,

ja, dass ist mir bekannt. Funktioniert auch mit set super, hatte gedacht ich hätte was übersehen.

Gruß,
Christoph

zap

#203
Ich habe gerade eine neue Version von 88_HMCCUDEV.pm eingecheckt. Das ist ein erster Versuch, für einen Datenpunkt eines Devices alternative Steuerelemente (z.B. Slider) bereitzustellen. Es gibt nun ein neues Attribut "controldatapoint". Damit wird eine Datenpunkt festgelegt, der mit dem Befehl "set xxx control Wert" gesetzt werden kann. Format des Datenpunktes ist Kanalnummer.Datenpunkt.

Beispiel: Bei einem Heizungsthermostaten soll ein Slider zur Einstellung der Zieltemperatur angezeigt werden.

1) Zunächst das Attribut "controldatapoint" auf den Kanal/Datenpunkt setzen, mit dem die Zieltemperatur eingestellt wird:

attribute mydev controldatapoint 2.SET_TEMPERATURE

2) Webcmd und WidgetOverride definieren:

attribute mydev webCmd control
attribute mydev widgetOverride control:slider,10,1,30

Der Befehl "set mydev control nn" setzt den Datenpunkt 2.SET_TEMPERATURE auf den gewünschten Wert nn.

Analoge Vorgehensweise für einen Rolladenaktor. Da ich mich mit dem webCmd-Konstrukt nicht auskenne, weiß ich leider nicht, wie man den Slider dazu bringt, immer den aktuell eingestellten Wert anzuzeigen. Bei mir zeigt er immer irgendeinen Wert an. Wenn ich den Slider bewege, wird aber der eingestellte Datenpunkt korrekt gesetzt. Vielleicht hat ja jemand einen Tipp ...

So richtig überzeugt mich die antiquierte FHEM Oberfläche nicht. Möglicherweise werfe ich das Feature wieder raus.

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

christoph_j

Hallo zap,

vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.

Hier mein Code:
define Rolladen.Wohnzimmer HMCCUDEV Rolladen_Wohnzimmer 1
attr Rolladen.Wohnzimmer IODev CCU2
attr Rolladen.Wohnzimmer controldatapoint 1.LEVEL
attr Rolladen.Wohnzimmer statechannel 1
attr Rolladen.Wohnzimmer statedatapoint LEVEL
attr Rolladen.Wohnzimmer webCmd control
attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1


Danke,
Christoph

zap

#205
Zitat von: christoph_j am 21 Januar 2016, 21:43:28
Hallo zap,

vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.

Hier mein Code:

attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1

Hat vermutlich mit den Werten <1 zu tun. Lies mal das hier:

http://forum.fhem.de/index.php/topic,44104.msg359791.html#msg359791

und versuche mal folgendes (auf jeden Fall bei Start und Ende die ".0" mit angeben:


attr Rolladen.Wohnzimmer widgetOverride control:slider,0.0,0.01,1.0


BTW: Bist Du sicher, dass Du so kleine Schritte einstellen möchtest? m.E. sollten ganze Prozentschritte reichen (s. Beispiel).

Wie gesagt, kenne mich damit nicht wirklich aus und habe derzeit keinen Rolladen-Aktor im Einsatz.

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

christoph_j

Hallo zap,

jetzt funktioniert es. Am ende fehlte noch ne 1:

attr Rolladen.Wohnzimmer widgetOverride control:slider,0.00,0.01,1.00,1

Das sind jetzt 100 Positionen die eingestellt werden können.

Gruß,
Christoph

zap

#207
Die 3 HMCCU Module unterstützen nun FHEM Widgets (z.B. Slider Controls). Dazu wurde in HMCCUDEV und HMCCUCHN ein neues Attribut "controldatapoint" eingeführt. Mit diesem Attribut wird der Datenpunkt festgelegt, der mit dem Widget geändert werden soll. Wenn dieses Attribut gesetzt ist, wird beim Aktualisieren des Datenpunkts ein Reading "control" gesetzt. Dies ist erforderlich, damit das Widget den aktuellen Wert anzeigt.

Beispiel: Ein Wandthermostat hat im Kanal 2 einen Datenpunkt SET_TEMPERATURE, mit dem die Zieltemperatur gesetzt wird. Die Einstellung soll mit einem Slider in 1 Grad Schritten zwischen 10 und 25 Grad erfolgen:

attr mydev controldatapoint 2.SET_TEMPERATURE
attr mydev webCmd control
attr mydev widgetOverride control:slider,10,1,25


Bitte beachten: Bei Devices vom Typ HMCCUCHN muss für "controldatapoint" nur ein Datenpunkt angegeben werden, da der Kanal bereits durch das Device vorgegeben ist.

Der Screenshot zeigt 3 Wandthermostate mit den aktuellen Werten für Temperatur, Luftfeuchte, Zieltemperatur und Taupunkt sowie einem Slider zum Einstellten der Zieltemperatur.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

hometux

Hall zap,

Mit dem RM-Release werden bei mir seit ca. einer Woche die Rauchmelder richtig ausgelesen - Vielen Dank!

luke666s

Danke erstmal für die klasse Arbeit...
Kann es sein, dass es Probleme mit Homematic Device Namen gibt wenn diese ein " " also quasi ne Leerstelle enthalten? Ich kann sie nämlich nur über die Adresse einbinden. Wenn ich dann aber was schalten will, gibt es einen "script fehler".
Wo finde ich die scripte auf dem raspi?