CUL_HM Analysen und hoffentlich Erweiterungen
unimatrix
ich bin mir nicht sicher, aber ich glaub hier ist es besser als in der Users-Gruppe. Ich würde gerne dazu beitragen, den Funktionsumfang der Homematic-Intergraion per CUL_HM zu erweitern und versuche nun den Funkverkehr zu analysieren. Ich habe auch eine CCU so dass ich vergleichen kann, wass die macht. Was z:B. in FHEM bisher fehlt, ist die Unterstützung von virtuellen Direktverbindungen. IM Homematic-System sind diese jedoch wichtig und bieten teilweise Funktionen, die durch eine reine zentrale Steuerung nicht gegeben ist. Das liegt daran, dass die Aktoren Features haben, die nur durch Direktverknüpfung aufrufbar sind, nicht jedoch einfach so von einer Zentrale.
Ich habe nun mal den Datenverkehr bei so einer AKtion mit der CCU mitgeloggt. Ich hätte gerne Feedback, ob ihr glaubt, dass mein Analyseansatz zum Erfolg führen kann. Ich hätte auch - falls dies überhaupt vorliegt - gerne Informationen darüber, wie die Entwickler bei den bisher unterstützten Geräten und Funktionen dabei vorgegangen sind, den Payload jeweils zu verstehen. Gibt es eine Referenz in der man weiss, was z.B: die Commands A0 oder 80 bedeuten, usw.
Hier habe ich also mal eine Verknüpfung eines virtuellen Kanals angelegt, dann einen Parameter dieser Verknüpfung geändert und dann den Knopf mal "gedrückt"
die 13C86C ist die CCU, der 162CF0 ist ein 1-Kanal Funkdimmer.
Kopplung Virt.Taste 30 in CCU mit Dimmerschlaf
11:34:28 nr: 4C cc: A0 ty: 01 s: 13C86C d: 162CF0 pl: 01 01 13 C8 6C 1E 00 ....l..
11:34:28 nr: 4C cc: 80 ty: 02 s: 162CF0 d: 13C86C pl: 00 .
11:34:28 nr: 4D cc: A0 ty: 01 s: 13C86C d: 162CF0 pl: 01 04 13 C8 6C 1E 03 ....l..
11:34:28 nr: 4D cc: A0 ty: 10 s: 162CF0 d: 13C86C pl: 03 01 00 00 00 32 64 00 FF 00 FF 01 12 22 23 .....2d......"#
11:34:28 nr: 4D cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
11:34:28 nr: 4E cc: A0 ty: 10 s: 162CF0 d: 13C86C pl: 03 0E 20 00 14 C8 0A 05 05 00 C8 0A 0A 04 04 .. ............
11:34:29 nr: 4E cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
11:34:29 nr: 4F cc: A0 ty: 10 s: 162CF0 d: 13C86C pl: 03 81 00 00 00 32 64 00 FF 00 FF 24 12 22 23 .....2d....$."#
11:34:29 nr: 4F cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
11:34:29 nr: 50 cc: A0 ty: 10 s: 162CF0 d: 13C86C pl: 03 8E 20 00 14 C8 0A 05 05 00 C8 0A 0A 04 04 .. ............
11:34:29 nr: 50 cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
11:34:29 nr: 51 cc: A0 ty: 10 s: 162CF0 d: 13C86C pl: 03 00 00 ...
11:34:29 nr: 51 cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
---
Änderung eines Parameters dieser Verknüpfung: Rampenzeit von 0.5 Sekunden auf 1 Sekunden erhöht
11:35:58 nr: 5A cc: A0 ty: 01 s: 13C86C d: 162CF0 pl: 01 05 13 C8 6C 1E 03 ....l..
11:35:58 nr: 5A cc: 80 ty: 02 s: 162CF0 d: 13C86C pl: 00 .
11:35:58 nr: 5B cc: A0 ty: 01 s: 13C86C d: 162CF0 pl: 01 08 13 0A ....
11:35:58 nr: 5B cc: 80 ty: 02 s: 162CF0 d: 13C86C pl: 00 .
11:35:58 nr: 5C cc: A0 ty: 01 s: 13C86C d: 162CF0 pl: 01 06 ..
11:35:58 nr: 5C cc: 80 ty: 02 s: 162CF0 d: 13C86C pl: 00 .
---
Betätigen des virtuellen Tasters in der CCU:
11:37:11 nr: 5D cc: A0 ty: 40 s: 13C86C d: 162CF0 pl: 1E 01 ..
11:37:12 nr: 5D cc: 80 ty: 02 s: 162CF0 d: 13C86C pl: 01 01 14 10 3A ....:
11:37:14 nr: 5E cc: A4 ty: 10 s: 162CF0 d: 13C86C pl: 06 01 C8 00 ....
11:37:14 nr: 5E cc: 80 ty: 02 s: 13C86C d: 162CF0 pl: 00 .
Rudolf Koenig
> Direktverbindungen.
Kannst Du uns erklaeren, wozu diese gut sind? Ich fuehle mich wie ein HM
analphabet, auch wenn ich fuer wesentliche Teile von CUL_HM verantwortlich bin.
> Ich h�tte gerne Feedback, ob ihr glaubt, dass mein Analyseansatz zum Erfolg
> f�hren kann.
Ich glaube schon, jedenfalls war das auch was ich gemacht habe, ohne dabei zu
wissen, wie es eigentlich gedacht ist. Du bist also im Vorteil :)
> Gibt es eine Referenz in der man weiss, was z.B: die Commands A0 oder 80
> bedeuten, usw.
Mir sind an Doku nur die XML Dateien bekannt, aber da ich diese nicht wirklich
verstehe, habe nach eine Weile aufgehoert diese zu lesen. A0/80 verstehe ich
leider auch nicht wirklich, aber neuere CUL_HM Versionen geben diese Bytes dank
Johan als Bitfeld analog zum rpd.exe in debug Modus aus (attr CUL
hmProtocolEvents + info timer im telnet). Leider wissen wir (d.h. ich) noch
nicht wirklich, was die einzelnen bits bedeuten.
> Hier habe ich also mal eine Verkn�pfung eines virtuellen Kanals angelegt,
> dann einen Parameter dieser Verkn�pfung ge�ndert und dann den Knopf mal
> "gedr�ckt"
Ich habe das mit anderen Befehlen auch so gemacht, und dann versucht das
nachzustellen. Manchmal hat es geklappt, manchmal nicht. Evtl. hilft Dir das
raw Befehl beim experimentieren.
unimatrix
http://www.homematic.com/fileadmin/pdfs/einleitungen/HM_XmlRpc_V1_502__2_.pdf
Was dort allerdings nicht dokumentiert ist, sind die Parameter aller Paramsets. Diese lassen sich nur interaktiv mit dem Aufruf GetParamsetDescription abfragen.
Um zu erklären, wozu die virtuellen Direktverknüpfungen gut sind, versuche ich das mal am Beispiel eines Unterputz-Dimmers 1 Kanal nachzuvollziehen und zu beschreiben (Typ HM-LC-DIM1T-FM)
Dieser Dimmer hat neben der Funkansteuerung auch einen Eingang für fest verdrahtete Taster. Ich habe meine bestehende Elektroverkabelung dazu verwendet, so dass ich den Dimmer nun von mehreren Stellen aus ganz normal per "Draht" antriggere.
Im Dimmer wird dazu für diese feste Verdrahtung ein sogenannter "Link" angelegt. Dieser Link hat das gleiche bzw. ähnliche Paramset, also die gleichen einstellbaren Parameter wie alle anderen Links, die man z.B. von anderen Tastern (also Funksendern, Fernbedienungen, Tasterschnittstellen, aber auch Fensterkontakten, Bewegungsmeldern, usw.) herstellen kann. Bei Homematic können in einem Aktor glaub ich bis zu 100 Links mit jeweils komplett eigenen Einstellungen abgespeichert werden.
Also: Drücke ich den fest verdrahteten Taster soll der Dimmer z.B mit einer Ramp-On-Zeit von 3 Sekunden auf 80% gehen, dann 10 Minuten an bleiben und dnan mit einer Ramp-Down-Zeit über 10 Minuten wieder aus gehen. Das lange festhalten des Tasters soll den Dimmer abwechselnd heller oder dunkler dimmen. All das sind Einstellungen.
Eine Fernbedienung könnte zusätzlich verlinkt sein, die kann den Dimmer aber z.B. nur Einschalten mit einer Einschaltdauer von 60 Minuten, völlig anderen Ramp-On/Ramp-Down Zeiten, etc. etc.
Dabei können die einzelnen Links auch verschiedene Prioritäten haben, z.B. soll ein gedrückter Taster wichtiger sein als ein Bewegungsmelder usw.
Das alles völlig ohne Zentrale, abgesehen davon dass man sie zur Konfiguration braucht (oder eben den LAN-Adapter) hat sie damit nichts zu tun.
Was ich bei mir auch nutze ist, dass ich (im Moment per Cron-Job, aber wie ist egal) die Parameter dieser festen Verbindungen zeitgesteuert ändere. Je nach Tageshelligkeit soll nämlich mein Flurdimmer eine andere Einschalthelligkeit haben, z.B: nachts reicht es (auf dem WEg ins Bad) wenn er auf 20% geht. Zwischen 19 und 21 Uhr hab ich ihn als Einschlafliht konfiguriert. Der Taster schaltet ihn ein und er geht dann langsam ueber 30 Minuten aus.
Nun zu den virtuellen Links. Die Parameter sind die gleichen, aber ich habe eben viel mehr Taster (die ich nicht wirklic habe). Da ich aber das oben beschrieben Verhalten des Aktors nicht DIREKT über die Zentrale erreichen kann (weiteres Beispiel: Auf Tastendruck blinkt der Dimmer mit definierbaren Patterns und Helligkeiten)) "drückt" man in der Zentrale stattdessen den virtuellen Taster, auf den dann der Aktor gemäß den in ihm gespeicherten Einstellungen für diesen Knopf reagiert (das Verhalten ist immer im Aktor gespeichert). So einen Taster kann ich natürlich auch mit 10 verschiedenen Aktoren verbinden. Drücke ich den virtuellen Taster habe ich eine völlige Gleichzeitigkeit im Verhalten aller Aktoren. Würde ich die Aktoren über die Zentrale ansteuern schalten die Aktoren alle in Ruhe nacheinander. Ein virtueller Taster kann also ein festes Lichtszenario aktivieren, usw.Außerdem bieten sich so Ansätze für hohe Wiederverwendbarkeit.
Hier mal die ParamsetDescription so eines Links beim Dimmaktor als Anhang. Abgefragt so (nutze den Wrapper von Olli um an den XMLRPC Server zu kommen)
echo "REQ RF getParamsetDescription IEQ0039150:1 IEQ0039150:1" |nc localhost 6770 >tmp.txt
echo "REQ RF getLinks IEQ0039150:1" |nc localhost 6770 >tmp2.txt
echo "REQ RF getParamset IEQ0039150:1 IEQ0039150:1" |nc localhost 6770 >tmp3.txt
echo "REQ RF getParamset IEQ0039150:1 IEQ0063770:3" |nc localhost 6770 >tmp4.txt
Ich werde mit RAW weiter experimentieren und versuchen die Funkabfolgen zu ermitteln die man braucht um gewisse Dinge zu erzielen. Das werde ich dann erstmal aufschreiben (in der Hoffnung keine Abmahnung zu bekommen). Vll hilft es wem. Ob ich selbst in der Lage bin da dann viel am Code damit zu erweitern, schauen wir dann mal :)
unimatrix
Ich konnte per FHEM (mit raw - Befehlen) neue Direktverknüpfungen von virtuellen Tastern zu meinem Dimmaktor erstellen. Ich habe außerdem verschiedene Parameter dieses links bearbeitet. Auch das Blinken (braucht meine Frau) liess sich konfigurieren. Ebenfalls kann man dann die Taste auch virtuell drücken.
Bei dem ganzen Testen ist mir aufgefallen, dass per hmProtocolEvents ja die Bedeutung der meisten Bytes in Klammern schon dahinter steht. Kommt das aus dem XML oder hat das schon früher jemand richtig in der Bedeutung verstanden?
Also das ist bis hierher alles total einfach, was dann die ABstrahierung dieser Funktion in FHEM angeht das ist eine ganz andere Frage.
Rudolf Koenig
> Bedeutung der meisten Bytes in Klammern schon dahinter steht. Kommt das aus
> verstanden?
Weder noch, ich habe mich von den rpd.exe Ausgaben inspirieren lassen. Und in
CUL_HM_DumpProtocol sind einige Umwandlungen von $cmd zu sehen (0B->0A, 84->A4,
etc), was von groben Unverstaendnis der Materie zeugt :)
unimatrix
Aber inzwischen hat hier so viel funktioniert, dass ich nicht mehr "zurück" will daher werd ich mir son Teil besorgen. Den CUL-Stick brauch ich eh für parallelen FS20 Betrieb.
Lustigerweise habe ich ja aus den Aktoren durch senden von RAW-Messages schon mehr "herausgeholt" als die CCU überhaupt kann. UNd was auch funktioniert hat: Das manuelle Verstellen der Heizungsventile. Das geht bei HM so nämölich nicht, man muss das mit den teuren Thermostaten machen. Das ist allerdings insofern trickreich, als dass die Ventile nur immer ganz kurz zyklisch in Empfang sind um Energie zu sparen. Sie synchronisieren sich auf diesen Zeitpunkt mit den Thermostaten. Dieses Verhalten müsste FHEM irgendwie nachstellen. Dazu muss ich noch mehr Testen.
Am Sonntag, 4. März 2012 10:43:20 UTC+1 schrieb Rudolf Koenig:
> Bei dem ganzen Testen ist mir aufgefallen, dass per hmProtocolEvents ja die
> Bedeutung der meisten Bytes in Klammern schon dahinter steht. Kommt das aus
> dem XML oder hat das schon fr�her jemand richtig in der Bedeutung
Rudolf Koenig
Dazu hatten wir schon 'ne Diskussion bzw. diverse Experimente: ein FHT80b
sendet regelmaessig, das HM-CC-TC nach einem mir nicht nachvollziehbaren
Intervall. Wenn Du dazu was genaues hast...
unimatrix
ich will aber erst einmal leicht anfangen. Ich habe die Dimmerfunktion um das setzen der gewünschten Rampensteilheit erweitert. Man kann nun optional zusätzlich zum Dimmwert und der Einschaltdauer (das ging schon) die gewünschte Rampensteilheit mit angeben. Den Standard habe ich auf "hart" gelassen, wobei ich das lieber umstellen würde auf das, was auch die CCU macht (0,5s) - das dürfte auch die Glühbirnen schonen.
Frage aber nun: Darf ich so eine Änderung hier als Patch anhängen oder irgendwem mailen oder oder oder? Die Änderung ist natürlich kompatibel zum früheren Aufruf, der neue Parameter ist ja optional hinten dran.
VG, unimatrix
Rudolf Koenig
> schonen.
Du darfst das machen wie Du willst: die bisherige Loesung ist nicht absichtlich
gewaehlt worden.
> Frage aber nun: Darf ich so eine �nderung hier als Patch anh�ngen oder
> irgendwem mailen oder oder oder?
Ja oder ja(mir). Wichtig: 1. commandref.html auch aendern, da CUL_HM
"Produktiv" ist. 2. Bitte gut testen, da ich keine Dimmer habe aber auch weil
ich nicht hinterher-testen will. Laengerfristig solltest Du das direkt in SVN
modifizieren.
unimatrix
Am Montag, 5. März 2012 17:33:00 UTC+1 schrieb Rudolf Koenig:
> Den Standard habe ich auf "hart" gelassen, wobei ich das lieber umstellen
> w�rde auf das, was auch die CCU macht (0,5s) - das d�rfte auch die Gl�hbirnen
> schonen.Du darfst das machen wie Du willst: die bisherige Loesung ist nicht absichtlich
gewaehlt worden.
> Frage aber nun: Darf ich so eine �nderung hier als Patch anh�ngen oder
> irgendwem mailen oder oder oder?
Ja oder ja(mir). Wichtig: 1. commandref.html auch aendern, da CUL_HM
"Produktiv" ist. 2. Bitte gut testen, da ich keine Dimmer habe aber auch weil
ich nicht hinterher-testen will. Laengerfristig solltest Du das direkt in SVN
modifizieren.
SVN - gerne, wenn gewünscht. Ich bin neu hier und und will auf keinen Fall etwas kaputt machen. Einen Testing-Branch oder so gibt es nicht oder? Für diese popelige Änderung kein Thema aber wenn man mal mit den Thermostaten anfängt....
Ich bin eher unerfahren mit Open-Source-Projekten, sollte ich irgendeinen Mist posten oder gar coden bitte direkt drauf aufmerksam machen :)
Patch beinhaltet natürlich auch geänderte commandref.html
WIKI-Seite http://fhemwiki.de/wiki/HM-LC-DIM1T-FM_1-Kanal-Dimmer_UP passe ich an, falls Patch akzeptiert ist.
VG
unimatrix
Der Datensatz ist auch identisch für den internen Taster eines aktors.
Die Bedeutung für vieles ist z.B. hier erklärt: http://www.homematic-inside.de/tecbase.html?view=item&item_id=440
Beschrieben wird der Aktor durch folgende Sequenz:
CMD:A001 Payload: 01 (Kanal) 05(config start) xxxxxx (Adresse des Tasters, eigene für internen Taster) xx (Tasterkanal, 01 bei intern) 03 (Nummer der Paramlist)
CMD:A001 Payload: 01 (Kanal) 08(config write index(also ein schreiben per key/value und nicht per offset) xxyyxxyyxxyyxxyy...hierbei steht xx für die Adresse und yy für den jeweiligen Wert. (siehe unten)
CMD:A001 Payload: 01 (Kanal) 06(config end)
########
Hier die einzelnen Datenwerte, den Byte-Nummern zugeordnet
01: MSB: SHORT_CT_RAMPOFF; LSB: SHORT_CT_RAMPON
02: MSB: SHORT_CT_OFFDELAY; LSB: SHORT_CT_ONDELAY
03: MSB: SHORT_CT_OFF; LSB: SHORT_CT_ON
04: SHORT_COND_VALUE_LO
05: SHORT_COND_VALUE_HI
06: SHORT_ONDELAY_TIME
07: SHORT_ON_TIME
08: SHORT_OFFDELAY_TIME
09: SHORT_OFF_TIME
0A: LSB: SHORT_ACTION_TYPE; Bit5: SHORT_MULTIEXECUTE; Bit6: SHORT_OFF_TIME_MODE; Bit7: SHORT_ON_TIME_MODE
0B: MSB: SHORT_JT_OFF; LSB: SHORT_JT_ON
0C: MSB: SHORT_JT_OFFDELAY; LSB: SHORT_JT_ONDELAY
0D: MSB: SHORT_HT_RAMPOFF; LSB: SHORT_JT_RAMPON
0E: Bit5: SHORT_OFFDELAY_BLINK; Bit6: SHORT_ON_LEVEL_PRIO; Bit7: SHORT_ONDELAY_MODE
0F: SHORT_OFF_LEVEL
10: SHORT_ON_MIN_LEVEL
11: SHORT_ON_LEVEL
12: SHORT_RAMP_START_STEP
13: SHORT_RAMPON_TIME
14: SHORT_RAMPOFF_TIME
15: SHORT_DIM_MIN_LEVEL
16: SHORT_DIM_MAX_LEVEL
17: SHORT_DIM_STEP
18: SHORT_OFFDELAY_STEP
19: SHORT_OFFDELAY_NEWTIME
10: ???
1A: SHORT_OFFDELAY_OLDTIME
81: MSB: LONG_CT_RAMPOFF; LSB: LONG_CT_RAMPON
82: MSB: LONG_CT_OFFDELAY; LSB: LONG_CT_ONDELAY
83: MSB: LONG_CT_OFF; LSB: LONG_CT_ON
84: LONG_COND_VALUE_LO
85: LONG_COND_VALUE_HI
86: LONG_ONDELAY_TIME
87: LONG_ON_TIME
88: LONG_OFFDELAY_TIME
89: LONG_OFF_TIME
8A: LSB: LONG_ACTION_TYPE; Bit5: LONG_MULTIEXECUTE; Bit6: LONG_OFF_TIME_MODE; Bit7: LONG_ON_TIME_MODE
8B: MSB: LONG_JT_OFF; LSB: LONG_JT_ON
8C: MSB: LONG_JT_OFFDELAY; LSB: LONG_JT_ONDELAY
8D: MSB: LONG_HT_RAMPOFF; LSB: LONG_JT_RAMPON
8E: Bit5: LONG_OFFDELAY_BLINK; Bit6: LONG_ON_LEVEL_PRIO; Bit7: LONG_ONDELAY_MODE
8F: LONG_OFF_LEVEL
90: LONG_ON_MIN_LEVEL
91: LONG_ON_LEVEL
92: LONG_RAMP_START_STEP
93: LONG_RAMPON_TIME
94: LONG_RAMPOFF_TIME
95: LONG_DIM_MIN_LEVEL
96: LONG_DIM_MAX_LEVEL
97: LONG_DIM_STEP
98: LONG_OFFDELAY_STEP
99: LONG_OFFDELAY_NEWTIME
90: ???
9A: LONG_OFFDELAY_OLDTIME
Wie man das alles einbaut, weiss ich grad auch noch nicht...zumal ein Kanal bis zu 100 Links haben kann. Das wäre eine sehr lange Baumstruktur...sollte man die in das $hash der Kanäle mit rein packen? Müsste man ja auch im fhem.save cachen. Auslesen ist dann notwendig, falls nicht im Cache, falls man solche Werte per set ändern will, die sich ein Byte teilen, weil man Bytes ja nur im ganzen schreiben kann, also müssen die anderen Bits vorher ausgelesen werden. Und dann ist mir auch noch unklar, wie so ein set aussehen soll, wo der User vll 10 Parameter gleichzeitig setzen will, das müsste man ja irgendwie als Key/Value-Paare angeben. Und noch weiter gedacht bräuchte man später noch höher abstrahierte Profile, also fertige Parametersammlungen für sinnvolle Anwendungen (Einschlaflicht, Aufwachlicht, etc.) damit das auch für die breite Masse interessant ist...
Und dann sind die SEts bei den meisten GEräten unterschiedlich. Kodiert man das alles hart in den Code oder sollte man das lieber aus Config-Dateien einlesen, in denen das Datenmodell der einzelnen Gerätetypen z.B. in XML beschrieben ist. Wenn man das zu Ende denkt dann entwickelt man sich seinen eigenen Bidcos-Service...
Ich denke ich sollte mal alles in eine richtige Dokumentation zusammenschreiben zumindest für die Aktoren, die ich zu Hause habe.
Jan-Hinrich Fessel
Am 09.03.2012 um 22:38 schrieb unimatrix:
> Anbei mal der dekodierte Datensatz einer Direktverknüpfung Taster -> Dimmaktor (gültig für alle Tasterarten, Fernbedienungen, etc und für alle Dimmertypen)
> Der Datensatz ist auch identisch für den internen Taster eines aktors.
[...]
Weia.
> Und dann sind die SEts bei den meisten GEräten unterschiedlich. Kodiert man das alles hart in den Code oder sollte man das lieber aus Config-Dateien einlesen, in denen das Datenmodell der einzelnen Gerätetypen z.B. in XML beschrieben ist.
Die XML-Beschreibungen liegen ja im CCU-Image (firmware/rftypes). Da steht keine Angabe zum Copyright bei. Allerdings sind die XML's nicht im Open-Source tarball. Vielleicht sollte man bei eQ3 fragen, ob man die benutzen darf.
> Wenn man das zu Ende denkt dann entwickelt man sich seinen eigenen Bidcos-Service...
Wär doch schick. Nur, wenn man das zu Ende denkt, könnte eQ3 gleich den Laden hier kräftig sponsern, die CCU offen machen, uns alle Specs geben und Geld mit Hardware verdienen statt jahrelang an einer .001 Softwarerelease rumzudoktern...
> Ich denke ich sollte mal alles in eine richtige Dokumentation zusammenschreiben zumindest für die Aktoren, die ich zu Hause habe.
Freu ;-)
Grüße
Oskar
Rudolf Koenig
Ich sehe hier Bausteine einer Programmiersprache, kann aber noch nicht
vorstellen, wie ein Programm aussschaut. Koenntest Du uns ein Beispiel nennen?
Wie lang kann ein Programm sein? Kannst Du was ueber Links erzaehlen?
Ist das sonst nicht dokumentiert? Das wuerde bedeuten, dass diese
Funktionalitaet in der CCU noch groesstenteils brach liegt, da keiner es
bedienen kann.
> Kodiert man das alles hart in den Code oder sollte man das lieber aus
> Config-Dateien einlesen, in denen das Datenmodell der einzelnen Ger�tetypen
> z.B. in XML beschrieben ist.
Auslagern in XML o.ae. erscheint mir deswegen sympatischer, weil damit schon
eine Modularisierung vorgegeben wird, und 10_CUL_HM jetzt schon zu gross ist.
Die eQ3 XML's kommen nur mit vorheriger Genehmigung von eQ3 ins fhem, und da
sehe ich schwarz.
> Wenn man das zu Ende denkt dann entwickelt man sich seinen eigenen
> Bidcos-Service...
Dagegen habe ich auch nichts, das Problem was ich hier sehe ist, dass es die
meisten freiwilligen Mitarbeiter abschreckt, weil zu komplex.
Happy Fhem User
Lassen sich die Parameter von vorhandenen Devices auslesen? Oder läuft
da die Kommunikation nur in die eine Richtung zum Device hin?
unimatrix
Am Samstag, 10. März 2012 09:52:10 UTC+1 schrieb Rudolf Koenig:
> http://www.homematic-inside.de/tecbase.html?view=item&item_id=440Ich sehe hier Bausteine einer Programmiersprache, kann aber noch nicht
vorstellen, wie ein Programm aussschaut. Koenntest Du uns ein Beispiel nennen?
Wie lang kann ein Programm sein? Kannst Du was ueber Links erzaehlen?
Ist das sonst nicht dokumentiert? Das wuerde bedeuten, dass diese
Funktionalitaet in der CCU noch groesstenteils brach liegt, da keiner es
bedienen kann.
> Kodiert man das alles hart in den Code oder sollte man das lieber aus
> Config-Dateien einlesen, in denen das Datenmodell der einzelnen Ger�tetypen
> z.B. in XML beschrieben ist.
Auslagern in XML o.ae. erscheint mir deswegen sympatischer, weil damit schon
eine Modularisierung vorgegeben wird, und 10_CUL_HM jetzt schon zu gross ist.
Die eQ3 XML's kommen nur mit vorheriger Genehmigung von eQ3 ins fhem, und da
sehe ich schwarz.
> Wenn man das zu Ende denkt dann entwickelt man sich seinen eigenen
> Bidcos-Service...Dagegen habe ich auch nichts, das Problem was ich hier sehe ist, dass es die
meisten freiwilligen Mitarbeiter abschreckt, weil zu komplex.
Ich will da nichts zu großes anfangen, nur vorher einmal über die Richtung überlegen. Es wäre glaub ich schon ein Mehrwert, wenn man einige wichtige Parameter von FHEM aus setzen kann, z.B. On-Zeiten und so etwas...
Schon jetzt kann man ja prinzipiell alles setzen, in dem man in die fhem.cfg die richtigen RAW_Befehle reinpackt...so nutze ich es inzwischen auch, genau so hat bei mir FHEM interne virtuelle Tasten, ich schicke das alles als RAW ab...
unimatrix
01 -> neuer Link
02 -> device Info (man bekommt Firmware, Seriennummer, etc zurück)
03 -> get Peer List (man kommt alle Verknüpfungspartner des Kanals genannt, mit der Info kann ich dann die einzelnen Verknüpfungen adressieren)
04 -> ganzes Paramset auslesen, dahinter wird Peer Adresse, Peer Channel und das gewünschte Paramset angegeben. Das oben genannte ist Paramset 3 ("LINK"), es gibt noch weitere Einstellungen, z.B. bei welcher Temperatur ein Aktor abschalten soll und sowas...
Kurz: Man kann die gesamte Konfiguration aller HM-Geräte über Funk auslesen. Und das sind ja bis zu 5 KByte, die man pro Aktor gespeichert haben kann. In einen Aktor passen 100 Verknüpfungen, die sich die Kanäle dann aber teilen.
Rudolf Koenig
> ich gepostet habe.
D.h. bei einem Dimmer kann man 50 virtuelle Taster (== geraet:kanal
Kombinationen) mit jeweils 2(short/long) x 26 Parameter bestuecken (== 100
Parametersaetze). Das ist kein wirkliches Programmieren, sondern 26 Parameter
fuer ein im Dimmer eingebautes Programm setzen. Eigentlich fehlt nur noch die
Beschreibung der Parameter.
Was macht man mit Links? Koenntest Du bitte ein konkretes Programm
(Einschlaflicht oder so) hier posten? Kann man sowas wie 3-mal blinken bauen?
Ist ein "devicePair" auch nichts anderes, als so ein virtueller Taster?
Von dem was ich hier verstanden habe, muessten diese Parameter pro Device
definiert sein (externe Definition oder im Programm fest verdrahtet), und der
Benutzer muesste diese mit einem Befehl setzen koennen, z.Bsp Vorschlag:
set dimmer virtual 1 device:channel short onTime:7 offTime:7...
das waere im READINGS unter VIRTUAL_01_SHORT sichtbar, und man koennte es auch
mit
get dimmer virtual 1 short
vom Geraet auslesen um es im READINGS zu speichern. Ich wuerde diese Parameter
zunaechst im Frontend nicht per dropdown oder aehnliches unterstuetzen, sondern
mich auf Doku und Beispiele verlassen.
Realisieren: ich glaube mit CUL_HM_pushConfig gibt es schon was in dieser
Richtung.
unimatrix
Am Samstag, 10. März 2012 12:31:53 UTC+1 schrieb Rudolf Koenig:
> Das "Programm" ist genau so lang wie eben die Anzahl der Paramter ist, die
> ich gepostet habe.D.h. bei einem Dimmer kann man 50 virtuelle Taster (== geraet:kanal
Kombinationen) mit jeweils 2(short/long) x 26 Parameter bestuecken (== 100
Parametersaetze). Das ist kein wirkliches Programmieren, sondern 26 Parameter
fuer ein im Dimmer eingebautes Programm setzen. Eigentlich fehlt nur noch die
Beschreibung der Parameter.
Was macht man mit Links? Koenntest Du bitte ein konkretes Programm
(Einschlaflicht oder so) hier posten? Kann man sowas wie 3-mal blinken bauen?
Ist ein "devicePair" auch nichts anderes, als so ein virtueller Taster?
Sowas wie 3 mal, 10 mal blinken etc. nutze ich übrigens als optische Rückmeldung wenn ich mein Haus in den Abwesenheitszustand oder sowas versetze. Im Wohnzimmer habe ich z.b. einen ALLES AUS-Knopf (da fährt auch der Fernseher runter usw.) da blinkt eine indirekte Beleuchtung erstmal 15 Sekunden, in der Zeit kann man das ganze noch durch einen weiteren Tastendruck "abbrechen" :)
Ein Einschlaflicht ist ganz einfach. Die meisten Parameter spielen keine Rolle. Vereinfacht gesagt geht das Licht bei Tastendruck innerhalb 0.5 Sekunden an (schafft man es in dieser Zeit nochmal zu drücken ist es sofort an. Wobei an hier mit 50% eingestellt ist (man will ja einschlafen)). Nach 600 Sekunden fängt das Licht an, in die Ramp-Off Phase zu gehen die mit 1800 Sekunden eingestellt ist. Ich versuche mal ein komplizierteres Beispiel zusammenzustellen. Grundlage ist das Verständnis der Grafik in meinem oben geposteten Link. Es muss einem klar sein, welche Phasen die Homematic Dimmer haben. (OFF; OFFDELAY; RAMP-ON; ON; ONDELAY; RAMPOFF)
SHORT_ACTION_TYPE=1
SHORT_CT_OFF=0
SHORT_CT_OFFDELAY=0
SHORT_CT_ON=0
SHORT_CT_ONDELAY=0
SHORT_CT_RAMPOFF=0
SHORT_CT_RAMPON=0
SHORT_JT_OFF=1
SHORT_JT_OFFDELAY=2
SHORT_JT_ON=2
SHORT_JT_ONDELAY=2
SHORT_JT_RAMPOFF=2
SHORT_JT_RAMPON=3
SHORT_OFFDELAY_TIME=0.00
SHORT_OFF_LEVEL=0.00
SHORT_OFF_TIME=111600.00
SHORT_OFF_TIME_MODE=0
SHORT_ON_LEVEL=0.50
SHORT_ON_TIME=600.00
SHORT_ON_TIME_MODE=0
SHORT_RAMPOFF_TIME=1800.00
SHORT_RAMPON_TIME=0.50
Von dem was ich hier verstanden habe, muessten diese Parameter pro Device
definiert sein (externe Definition oder im Programm fest verdrahtet), und der
Benutzer muesste diese mit einem Befehl setzen koennen, z.Bsp Vorschlag:
set dimmer virtual 1 device:channel short onTime:7 offTime:7...
für normalen Taster, wobei der 2. Tasterkanal genutzt wird
set dimmer addLink channel:01 link:meinTaster linkchannel:02
set dimmer setParam channel:01 paramset:meinTaster linkchannel:02 short_on_time:600.00 short_rampon_time:2.00 short_rampoff_time:4.00 .....
set dimmer getLinks
set dimmer getParams channel:01 paramset:meinTaster
set dimmer getParams all
für virtuellen:
set dimmer addLink channel:01 link:fhem linkchannel:24
set dimmer setParam channel:01 paramset:fhem linkchannel:24 .....
allgemeine settings:
set dimmer setParam channel:01 paramset:master logging:0
dann drücken der Taste in FHEM:
set <irgendein hm device> virtualKey 24 long
Martin Fischer
> [...]
>
> Der Dimmer weiss nicht, ob eine Taste virtuell ist. Der Begriff ist vll
> irreführend. Ein normaler Wandtaster hat vll 4 Kanäle. Die CCU-Software
> simuliert sich selbst als Taster mit 50 Kanälen. Dem Aktor ist das egal. Im
> Aktor wird nur gespeichert, lieber Aktor, du hast jetzt einen Link mit
> Device 0x123456 Kanal 2. Fertig. Ob 0x123456 dann FHEM selbst oder ein
> echter Taster ist, ist gleich. Das Pairing ist nichts anderes, als dass man
> dem Aktor genau das sagt. Bei HM wird zwar auch dem Taster gesagt, dass er
> jetzt den Aktor xy steuert, das ist aber nicht wirklich nötig, es geht auch
> ohne. Mehrwert hat man bei Fernbedienungen oder Fensterkontakten, die
> selbst eine optische Rückmeldung über den Erfolg geben, weil die dann das
> ACK auswerten. es wäre also eher sowas wie:
heisst das folglich auch, das ein aktor sowohl mit fhem _und_ _ccu_ gekoppelt
sein könnte, wenn beide einen anderen kanal nutzen?
nur mal so aus reiner neugier, da es ja immer heisst, das vor nutzung in fhem
der aktor von der ccu entkoppelt werden muss.
oder lieg ich da falsch?
unimatrix
heisst das folglich auch, das ein aktor sowohl mit fhem _und_ _ccu_ gekoppelt
sein könnte, wenn beide einen anderen kanal nutzen?nur mal so aus reiner neugier, da es ja immer heisst, das vor nutzung in fhem
der aktor von der ccu entkoppelt werden muss.oder lieg ich da falsch?
das entkoppeln des Aktors vor Nutzung in FHEM hat meiner Erfahrung nach den einzigen Vorteil, dass man dann den Aktor per Autocreate in die fhem.cfg bekommt. Denn sonst reagiert ein Aktor nicht auf einen Pairing-Request, denn er kann nur mit einer Zentrale gepairt sein.
Ich habe bei mir nun seit einiger Zeit sowohl CCU als auch CUL bzw. inzwischen HMLAN parallel laufen, beide mit der gleichen ID, d.h. ich habe FHEM auf die ID eingestellt, die die CCU schon immer hatte. Das führt nur dazu, dass jedes Gerät, wenn es etwas an diese ID oder an 000000 (Broadcast) sendet, sowohl von der CCU als auch von FHEM ein ACK bekommt. Soweit ich das mit meinen Geräten beobachtet habe, ist das aber überhaupt nicht schlimm und ich konnte keinen wahrnehmbaren Effekt feststellen.
Ich habe einfach alle Geräte manuell in die Config eingetragen. Dazu lautscht man einfach ne Weile mit. Die Geräte, die von alleine mal was senden (Thermostate, Stellantriebe) kriegt man anhand ihrer Werte raus (ich wusste ja, welches Thermostat gerade 20,4 Grad anzeigt, also konnte ich als das gesendet hat, die 6-Byte-Adresse zuordnen) und die anderen Geräte schaltet man einfach mit der CCU...dann sieht man auch die Adressen.
Mit Kanälen hat das aber nichts zu tun. Jeder Aktor hat genau eine Adresse, egal wie viel Kanäle er hat.
Wenn ich im Moment ein Licht manuell an mache dann aktualisiert sich sowohl der Zustand in der CCU als auch in FHEM.
Martin Fischer
> [...]
> das entkoppeln des Aktors vor Nutzung in FHEM hat meiner Erfahrung nach den
> einzigen Vorteil, dass man dann den Aktor per Autocreate in die fhem.cfg
> bekommt. Denn sonst reagiert ein Aktor nicht auf einen Pairing-Request,
> denn er kann nur mit einer Zentrale gepairt sein.
Ok! danke für die Ausführung!
Gruss Martin
Rudolf Koenig
> der aktor von der ccu entkoppelt werden muss.
Das Problem ist eher dass mWn nur eine Zentrale zugelassen ist, d.h. wenn ein
Geraet mit dem CCU schon gekoppelt ist, dann muss die CCU das Geraet explicit
mit fhem koppeln, damit dieser von fhem Befehle annimt. Und dazu muesste fhem
fuer die CCU eine Fernbedienung oder aehnliches simulieren.
Es waere interessant zu wissen, ob ein so gekoppelter fhem dem Geraet weitere
Schalter per devicepair beibringen kann.
unimatrix
Im Aktor ist immer genau ein Gerät als Zentrale gespeichert. Nur diese Speicherung macht ein "koppeln" aus.
Ich habe das CUL_HM inzwischen weiter verstanden. Du hast als Paring Remote-Switch schon genau das drin, was man für alle Parings braucht, auch für virtuelle Taster. Das könnte man sehr leicht mit einbauen (wenn ich mich noch sicherer fühle, probier ichs gerne)
Hades
Ich selbst bin leider nicht wirklich in der Lage, hier etwas Sinnvolles beizutragen, finde die Diskussion aber sehr spannend und vielversprechend und bewundere Eure Arbeit!! Deshalb wollte ich fragen, ob die Entwicklung hier schon irgendwie zu einem Ergebnis gekommen ist. Gibt es evtl. eine Übersicht der raw-Befehle oder sogar eine Implementation für einen einfachen user wie mich? Ich würde z.B. gerne mit langem Tasterdruck (Hardware-Taster) ein on-for-timer senden oder zu bestimmten Uhrzeiten einen Hardware-Tatser deaktivieren, d.h. dass ein Druck darauf eben kein Licht schaltet ....
LG
Alex.