Neues Modul HMCCU für Homematic CCU

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

Vorheriges Thema - Nächstes Thema

chris1284

Zitat von: tobox am 29 September 2016, 14:04:41
Gibt es irgendwelche Nachteile, wenn man FHEM an eine CCU2 anbindet,

man könnte als nachteil sehen das du nach dem define der HMMCUDEv oder HMCCUCHN noch vieles in fhem an attributen setzen musst um das device userfreundlich schaltbar zu machen. die cul_hm devices sind quasie nach dem autocreate fertig.

Zitat
sind die Verknüpfungen und Events einfach nur "anders", und im Endeffekt lässt sich über FHEM trotzdem alles steuern und realisieren.

die selben, nur das du sie nicht umständlich über ellenlange fhembefehle und register erstellen musst sondern einfach nur in der ccu zusammen klickst. in fhem hast du mit dem peeren dann ncihts mehr zu tun

Pfriemler

Da sag ich Danke für diese Zusammenfassung :-)

Zitat von: chris1284 am 29 September 2016, 14:59:56
man könnte als nachteil sehen das du nach dem define der HMMCUDEv oder HMCCUCHN noch vieles in fhem an attributen setzen musst um das device userfreundlich schaltbar zu machen. die cul_hm devices sind quasie nach dem autocreate fertig.
Also ich habe auch noch eine Menge Handarbeit üblicherweise, insbesondere sind die Namen nicht immer benutzerfreundlich. Homematic-Martin gibt sich aber unglaubliche Mühe, alles so einfach wie möglich zu gestalten, aber jedes neue Gerät ist eine neue Herausforderung (die er bisher immer bewundernswert gemeistert hat). Das wird aber in der CCU2 meist recht komfortabel integriert, siehe RGBW-Modul oder die Innensirene. Vor allem etwas seltsame Geräte sind in der CCU quasi ab Werk integriert.

Zitatdie selben, nur das du sie nicht umständlich über ellenlange fhembefehle und register erstellen musst sondern einfach nur in der ccu zusammen klickst. in fhem hast du mit dem peeren dann ncihts mehr zu tun
Wenn man die Syntax einmal verinnerlicht hat, geht es eigentlich auch in FHEM einfach, aber die Einstiegschwelle ist deutlich höher. Zudem hat Martin die "templates" entwickelt, mit der sich ganze Registersätze auf einmal setzen lassen. Aber in der CCU gibt es für viele einfache Aufgaben wie einen Treppenlichtautomaten einen eigenen Eintrag in einer Klickdown-Liste. Was der CCU m.W. fehlt, sind Backup und Restores. Einen defekten Aktor durch einen anderen zu ersetzen, indem man seine Registerprogrammierung komplett in den Ersatz überträgt, das hat schon was...

Ich hatte wegen der Klick-und-fertig-Oberfläche auch einmal eine CCU2, aber da war das HMCCU noch nicht so ausgereift wie jetzt. Jetzt bin ich sogar am Überlegen, meinen ganzen Zoo von gut 30 Geräten wieder auf eine CCU umzuziehen. Aber zwei Geräte, zwei (völlig unterschiedliche) Oberflächen ...
Letztlich muss jeder selbst wissen, was er für sich besser findet.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

chris1284

warum ist setlist als attribut eigentlich nicht verfügbar? würde hier weiterhelfen weil ich dann den slider einbauen könnte für level und color
Zitat von: chris1284 am 28 September 2016, 21:52:32
hi,

ich bräuchte mal hilfe beim rgbw contoller da ich mit den ganzen attributen um die hmccu devices userfreundlich nutzbat zu machen auf kriegsfuß stehe.
er ist mit 3 channels als je hmccuchn eingeunden. ziel ist in userfreundlich schaltbar zu machen.

chn1 - helligkeit - az_rgbw_01_dim soll in fhemweb on/off/dimslider können
chn2 - color - az_rgbw_01_color soll im fhemweb wie wiflight rgb, colorpicker können
chn3 - auto - az_rgbw_01_auto da weiss ich noch nicht was er können soll. die programme 0-6 starten (stop und 1-6 die 5 standardprogramme)
vielen dank schon mal

chris

eddie8

Hallo zusammen,

leider scheitere ich derzeit auf sämtlichen Wegen der Homeatic-Integration in FHEM (Fritzbox, Hue, Intertechno-Funksteckdosen laufen alle).

Nun dachte ich, ich hätte hier die Eierlegende Wollmilchsau gefunden, scheitere aber an anderer Front: Beim installieren von RPC::XML::Server in perl. Ist hier durch Zufall noch jemand mit FHEM auf einer Synology unterwegs und hat das Modul installieren können? Nutze die Perl Distribution aus dem Paket-Zentrum, die per ipkg macht nur einen segfault beim aufrufen, ist also auch keine Alternative.

für alle Zuschriften Dankbar!

Gruß
Eddie8

chris1284

#799
40€ in die hand nehmen und eine pi kaufen wäre die lösung. warum sich selbst und fhem zwangskastrieren? diese günstigen home nas sind nur halbwegs als nas zu gebrauchen, mehr aber auch nicht
(unur meine meinung). evtl hilft das weiter, das ist definitiv ehr was für den nas-bereich https://forum.fhem.de/index.php/topic,9649.msg53769.html#msg53769 . martin wäre also ein guter ansprechpartner

chris1284

#800
hallo zap, warum kennen channel kein control? so kannman diese nicht mit controls belegen was sehr schade ist
die beschreibung aus der chmdref zu hmccuchn ist somit verkehrt meine ich
Zitatcontroldatapoint <datapoint>
Set datapoint for device control. Can be use to realize user defined control elements for setting control datapoint. For example if datapoint of thermostat control is SET_TEMPERATURE one can define a slider for setting the destination temperature with following attributes:
attr mydev controldatapoint SET_TEMPERATURE attr mydev webCmd control attr mydev widgetOverride control:slider,10,1,25

das geht irgendwie nur bei devices. und controldatapoint müsste dann, wenn es nur für devices geht, mehrere werte annehmen können so das man zb für alle 3 chn je ein slider bauen kann

eddie8

@chris1284:
Es scheiterte weniger an den 40€ (eine PI3 hab ich) als am Starrsinn, das auch so hinzubekommen, schließlich ist die Performance von dem NAS mehr als ausreichend. Schade, dass es an sowas banalem wie der Perl-Distribution scheitert.
Bin jetzt aber auf den PI3 umgezogen, 3 Abende basteln vs. 2 Stunden PI einrichten und alles drin. Insofern danke für den Hinweis! Ja, das hat seine Vorzüge, wenn es auch ein Workaround und keine Lösung des Problems ist. ;)

chris1284

das proble ist halt neben perl auch der treibersupport. hättest du diese eine perl modul zum laufen bekommen wärest du evtl beim nächsten modul mit einem anderen perl modul wieder gescheitert.

Vorhand

Hallo,
hab eine Frage zu Systemvariablen. In fhem im Bild "DeviceOverview" werden die Eigenschaften von HMCCU dargestellt. Unter Readings sieht man alle Systemvariablen der CCU-2. Allerdings nicht aktualisiert. Erst mit dem Start des scripts HMTEST.SCR aktualisieren sich die Werte.
In der Homatic sind Temperaturen, die ich über den wiffi-pump in die CCU schreibe, dort aber nicht als Kurve darstellen kann. In fhem wäre das wesentlich einfacher.
Wie kann ich in fhem die Variablen auslesen und z.B. zur Anzeige bringen und für ein LogFile nutzen?
Danke.

Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

zap

Urlaub muss auch mal sein. Daher sorry, wenn ich die letzten 2 Wochen etwas schweigsam war. Ich werde versuchen, die Fragen in den nächsten Tagen zu beantworten. Stay tuned ...
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

zap

#805
So, hier mal einige Antworten:

@SaschaHL: Du hast vermutlich im IO-Device das Attribut rpcqueue falsch gesetzt. Dieses Attribut legt den vollen Prefix der Queue-Files inkl. Verzeichnis fest. Wenn das Attribut nicht gesetzt ist, ist der Default /tmp/ccuqueue. Wenn Du das Attribut nicht setzt, benötigt fhem Schreibrechte im Verzeichnis /tmp. In Deinem Fall kannst Du das Attribut auf /opt/fhem/tmp/ccuqueue setzen, wenn Du Dein angelegtes Verzeichnis nutzen willst. Ansonsten lösche das Attribut. FHEM sollte eigentlich Schreibrechte in /tmp haben.

@aski71: Die Fehlermeldung "use of uninitialized value $ct" kommt daher, dass eines der Module, die Du verwendest, das Internal "TYPE" nicht gesetzt hat. Sehr seltsam, da das FHEM Standard ist. Ist unschön, sollte aber für HMCCU keine Auswirkungen haben.
Nach dem Reboot der CCU muss der RPC-Server neu gestartet werden, da die CCU beim Reboot die registrierten RPC-Abnehmer (hier FHEM) vergisst.

@bumbumb: Ich nehme an, Dein notify ist falsch. Schreibe doch mal als Reaktion auf Dein notify EVTPART1 in ein anderes Dummy. Dann siehst Du, ob es grundsätzlich funktioniert.

@chris1284: Zu Deiner Frage bzgl. Webdarstellung später. Muss ich mir im Detail anschauen. Bei HMCCUCHN ist aufgrund eines Bugs in der FHEM Oberfläche der Befehl "set control" nicht vorhanden. Per Kommandozeile sollte er aber funktionieren. Wird korrigiert.

@vorhand: Die CCU Systemvariablen werden von der CCU leider nicht über die RPC-Schnittstelle aktualisiert. Daher bekommt FHEM Änderungen nicht mit. Ich empfehle Dir, in FHEM ein AT Device einzurichten, mit dem regelmäßig der Befehl "get xy vars .*" ausgeführt wird. Das Intervall würde ich nicht zu klein wählen (versuche mal 5 oder 10 Sekunden) um die CCU nicht zu sehr zu belasten.


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

Vorhand

Danke - soll ein AT-Device einrichten!?
Könntest du ein paar Zeilen Code als Beispiel schreiben?
Die Ansprache der Systemvariablen in fhem gelingt mir nicht.
Grüße
Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

zap

Zitat von: Vorhand am 06 Oktober 2016, 12:49:43
Danke - soll ein AT-Device einrichten!?
Könntest du ein paar Zeilen Code als Beispiel schreiben?
Die Ansprache der Systemvariablen in fhem gelingt mir nicht.
Grüße

Ungefähr so: Wenn Dein IO-Device CCU2 heißt, aktualisiert das folgende AT-Device die Variablen Readings in FHEM jede Minute:


define updatevars at +*00:01:00 get CCU2 vars .*


Bei CCU2 das Attribut ccureadings auf 1 setzen. Um eine Variable in der CCU zu setzen, muss diese zunächst in der CCU angelegt werden. Dann kannst Du in FHEM z.B. folgendes machen:


set CCU2 var Test Wert


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

Vorhand

#808
Hallo zap, das Setzen der Variablen geht super.
Wie kann ich sie in fhem auslesen und weiterverarbeiten?
Mein Versuch des FileLog:
define FileLog_d_ccu FileLog ./log/d_ccu-%Y-%m.log d_ccu:.*
geht leider nicht!
Was mache ich falsch?
Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

zap

Dein Log-Statement sieht soweit gut aus. Es bewirkt, dass alle Trigger-Meldungen vom Device d_ccu und Änderungen von Readings in das Logfile geschrieben werden. Wenn Dein IO-Device d_ccu heißt, musst Du zunächst dafür sorgen, dass die Readings überhaupt geschrieben werden:


attr d_ccu ccureadings 1
attr d_ccu event-on-change-reading .*


Ggf. event-on-change-reading durch event-on-update-reading ersetzen, wenn bei jeder Aktualisierung ein Logfle Eintrag geschrieben werden soll.

Nun einmal manuell eine Variable aus der CCU abfragen. Angenommen, die Variable heißt "TEST", dann lautet der Befehl:


get d_ccu vars TEST


Nun muss zunächst ein Reading TEST im FHEM-Device d_ccu erscheinen und außerdem ein Eintrag im Logfile geschrieben werden. Gleiches Spiel für alle Variablen:


get d_ccu vars .*


Um das zu automatisieren, das oben beschriebene AT verwenden, um den get Befehl regelmäßig auszuführen.

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