CUL_HM daten sortieren im nächsten update

328 views
Skip to first unread message

Martin

unread,
Dec 11, 2012, 2:17:30 AM12/11/12
to fhem-...@googlegroups.com

Update CUL_HM

hier eine zusammenfassung des nächsten update von CUL_HM. Dies ist notwendig, da das "aufräumen" der Variablen nicht geraeuschlos passiert. Es wird Meldungen beim update oder restart geben aber keine Probleme im Betrieb.

Die Datenstruktur in CUL_HM wird aktualisiert und den FHEM standards angepasst. Daher wird es nach dem update zu Fehlermeldungen nach dem neustart geben - dass gewisse Attribute nicht korrekt seien.

Was ist zu tun?
Nach dem update das config neu speichern.

Die Details:
Attribute - Variablen mit denen der User Einstellungen an der Entity vornehmen kann.
- Protokoll-ereignisse werden von attr nach 'allgemein' verschoben
- 'channel_xx' und 'device' werden von Attr nach 'allgemein' verschoben
- 'peerList' wird in attr nicht mehr dargestellt, sondern Readings

Noch offen:
Folgende Attribute sind eigentlich readings und sollten entsprechend verschoben werden:
devInfo, firmware

Sonstiges:
Registerinhalten erhalten den prefix "set_" wenn der Wert nicht durch ein lesen der Inhalte bestätigt wurde. das ist konform zum Verhalten anderen Kommandos

Das Attribut "autoReadReg" wird eingeführt. Wenn man diese  Variable '1' setzt wird nach einem neustart/reboot automatisch ein "getConfig" ausgeführt.
Anwenden sollte man es auf device. Es kann auch auf Channel angewendet werden, ist aber nicht effektiv, da dies sowieso  beim 'device' mit ausgeführt wird.
Anwenden sollte man es NICHT bei devices die nur auf 'config' reagieren, also nur antworten, wenn man 'anlernen' auslöst.
Anmerkung: Die Verabeitung erfolgt zeitverzögert um die Last zu verteilen. Es wird nicht wiederholt - es ist also möglich, ein erfolgreiches auslesen wird also nicht garantiert.
Siehe auch commangref


Gruss
Martin

Christoph Zimmermann

unread,
Dec 12, 2012, 6:53:19 AM12/12/12
to fhem-...@googlegroups.com
Hallo Martin,

erstmal vielen Dank für die viele Arbeit und Mühe die du in die HM-Implementierung steckst.

Ich habe dein Update zum Anlass genommen, mal meine Config etwas zu entrümpeln und habe testweise einen Aktor (HM-LC-SW2-FM) nochmals gepairt. Hierbei werden folgende Zeilen in die Config eingetragen:

define LichtSchreibtisch_Sw_01 CUL_HM 17568601
attr LichtSchreibtisch_Sw_01 model HM-LC-SW2-FM
attr LichtSchreibtisch_Sw_01 room CUL_HM
define FileLog_LichtSchreibtisch_Sw_01 FileLog ./log/LichtSchreibtisch_Sw_01-%Y.log LichtSchreibtisch_Sw_01
attr FileLog_LichtSchreibtisch_Sw_01 logtype text
attr FileLog_LichtSchreibtisch_Sw_01 room CUL_HM

Leider erschließt sich mir nicht ganz der Zweck dieses zusätzlichen pseudo Devices. Es wäre toll, wenn es mir jemand erklären könnte.

Martin

unread,
Dec 12, 2012, 8:16:31 AM12/12/12
to fhem-...@googlegroups.com
Hallo Christoph

Das es Device und Kanaele gibt ist dir bekannt, nehme ich an. Ansonsten evtl das Einsteigerdoc ansehen, da habe ich mich in einer Erklaerung versucht.

Ich hole einmal etwas aus:
FHEM unterscheidet nicht zwischen Device und Kanal - ich nenne es entities.
Das Device ist der untere layer des Geraets, Kanaele sind sozusagen die Anwendungen. FHEM allgemein unterstuetzt keinen Bezug zwischen diesen Entites. Dies ist aber aus verschiedenen Gründen notwendig - in erster Linie wegen des Protkolls. Aber auch einige Einstellungen (Register) sind pro device - pair-mit-Zentrale, interne Kanaele freischalten... - und habe Auswirkungen auf alle Kanaele.
Der saubere Ansatz ist also immer ein device und 1-n kanaele als entities zu definieren - eben die Hirarchie.

Bei ein-Kanal-Devices und aus historischen Gründen unterstützt FHEM-CUL_HM auch, dass der erste Kanal im Device abgebildet werden kann.

Neu ist in diesem Zusammenhang, dass beim Anlernen (bei jedem Empfangen einer Device_Info) die Variablen auf den Stand gebracht werden (serialNo, Model, Class,...) und es werden alle Kanaele instanziiert, die noch nicht existent sind.
Eine Ausnahme ist das ein-Kanal-Device. Hier wird der Kanal im Device abgebildet - also in einer Entity - der Oberhead ist nicht gerechtfertigt.

Auch die Fernbedienungen sind so organisiert - man kann hier aber auch bei der alten Darstellung mit den Btn bleiben. Dann kann man aber dem Schalter keinen Namen geben, das peering nicht auslesen und AES nicht steuern.

Du kannst also den Kanal 01 in deinem Setup wieder löschen und das Device benutzen fuer diesen Kanal. Den Kanal 02 wirst du wohl behalten, nehme ich an. Sematisch muss dir klar sein, dass der Protokol-stack immer auf den Device stattfindet. Das geht nicht anders. Dann ist deine Installation nicht mehr symetrisch - also Device und Kanal01 in der ersten Entity, Kanal 02 in der 2. Entity, beide benutzen die erste Entity zum senden...
Wenn du nur 'on' und 'off' benutzt ist das ganze ziemlich egal...

Falls du noch Fragen oder Anregungen hast, gerne

Gruss
Martin

Christoph Zimmermann

unread,
Dec 12, 2012, 8:44:52 AM12/12/12
to fhem-...@googlegroups.com
Vielen dank für die Erläuterung Martin

Ich hatte scheinbar den Wechsel der Hierarchie im CUL_HM Modul nicht ganz mitbekommen,ist natürlich absolut logisch.

Grüße

Christoph Zimmermann

unread,
Dec 12, 2012, 9:18:34 AM12/12/12
to fhem-...@googlegroups.com
Nachtrag: Ich habe nun testweise den HM-LC-SW2-FM komplett aus der Konfig entfernt. Anschließend über set <> hmPairForSec 300 ein Re-Pairing bzw. Autocreate erzeugt. Wie du bereits erklärt hast, wurden die Einträge aufgeteilt nach Device und Kanäle:

define CUL_HM_switch_175686 CUL_HM 175686
attr CUL_HM_switch_175686 devInfo 020100
attr CUL_HM_switch_175686 firmware 1.9
attr CUL_HM_switch_175686 hmClass receiver
attr CUL_HM_switch_175686 model HM-LC-SW2-FM
attr CUL_HM_switch_175686 room CUL_HM
attr CUL_HM_switch_175686 serialNr IEQxxx
attr CUL_HM_switch_175686 subType switch

define FileLog_CUL_HM_switch_175686 FileLog ./log/CUL_HM_switch_175686-%Y.log CUL_HM_switch_175686
attr FileLog_CUL_HM_switch_175686 logtype text
attr FileLog_CUL_HM_switch_175686 room CUL_HM

define CUL_HM_switch_175686_Sw_01 CUL_HM 17568601
attr CUL_HM_switch_175686_Sw_01 model HM-LC-SW2-FM
attr CUL_HM_switch_175686_Sw_01 room CUL_HM

define FileLog_CUL_HM_switch_175686_Sw_01 FileLog ./log/CUL_HM_switch_175686_Sw_01-%Y.log CUL_HM_switch_175686_Sw_01
attr FileLog_CUL_HM_switch_175686_Sw_01 logtype text
attr FileLog_CUL_HM_switch_175686_Sw_01 room CUL_HM

define CUL_HM_switch_175686_Sw_02 CUL_HM 17568602
attr CUL_HM_switch_175686_Sw_02 model HM-LC-SW2-FM
attr CUL_HM_switch_175686_Sw_02 room CUL_HM

define FileLog_CUL_HM_switch_175686_Sw_02 FileLog ./log/CUL_HM_switch_175686_Sw_02-%Y.log CUL_HM_switch_175686_Sw_02
attr FileLog_CUL_HM_switch_175686_Sw_02 logtype text
attr FileLog_CUL_HM_switch_175686_Sw_02 room CUL_HM

Von Haus aus ist aber nun in FHEM nur Kanal 1 (über die Devicedefinition nicht über die Kanaldefinition) als Schalter ansprechbar. Kanal 2 ist muss erst manuell das attr subtype switch zugewiesen werden. Ist dies wirklich so gewollt?

Martin

unread,
Dec 12, 2012, 1:49:20 PM12/12/12
to fhem-...@googlegroups.com

Von Haus aus ist aber nun in FHEM nur Kanal 1 (über die Devicedefinition nicht über die Kanaldefinition) als Schalter ansprechbar. Kanal 2 ist muss erst manuell das attr subtype switch zugewiesen werden. Ist dies wirklich so gewollt?

nein, ist nicht so gewollt. 
ein bug aus der Umstellung (gib also bis gestern). Alle deviceparameter sind im device. Werden nachher einen Update einstellen.
Also alle deviceparameter wie model, subtype,... sind im device und werden von dort gelesen. Sind ja fuer alle Kanaele gleich.
Ausnahme ist model - dies muss gesetzt werden und wird es auch automatisch. Es wird ausserhalb von CUL_HM vom WEB-frontend benutzt.

Gruss
Martin


Christoph Zimmermann

unread,
Dec 16, 2012, 4:52:24 AM12/16/12
to fhem-...@googlegroups.com
Hallo Martin,

danke fürs Fixen des Autocreates. Habe es gerade getestet und funktioniert soweit, jedoch hat sich irgendwo ein Bug in der 10_CUL_HM Rev. 2326 eingeschlichen. Hier habe ich das Problem, dass ich permanent Missing Acks von meinen Aktoren bekomme. Tausche ich die CUL_HM gegen die rev. 2321 läuft alles ohne Probleme.
Falls ich dir irgendwie beim Debuggen helfen kann gib bescheid.

Viele grüße

Christoph

Christoph Zimmermann

unread,
Dec 16, 2012, 11:27:56 AM12/16/12
to fhem-...@googlegroups.com
Scheint ich habe das gleiche Problem wie es unter:

https://groups.google.com/forum/?fromgroups#!topic/fhem-users/IGTbSWlnyGY

beschrieben ist

Martin

unread,
Dec 16, 2012, 2:27:42 PM12/16/12
to fhem-...@googlegroups.com

sollte korrigiert sein
sorry
Martin

Christoph Zimmermann

unread,
Dec 16, 2012, 3:32:49 PM12/16/12
to fhem-...@googlegroups.com
Super vielen Dank fürs schnelle Reagieren.

Hab noch eine Frage bzgl der best practice Konfig:

Ich hab meinen HM-LC-SW2-FM frisch gepairt, dann bekomme ich folgendes Ergebnis:

define CUL_HM_switch_175686 CUL_HM 175686
attr CUL_HM_switch_175686 devInfo 020100
attr CUL_HM_switch_175686 firmware 1.9
attr CUL_HM_switch_175686 hmClass receiver
attr CUL_HM_switch_175686 model HM-LC-SW2-FM
attr CUL_HM_switch_175686 room CUL_HM
attr CUL_HM_switch_175686 serialNr IEQ0xxx

attr CUL_HM_switch_175686 subType switch
define FileLog_CUL_HM_switch_175686 FileLog ./log/CUL_HM_switch_175686-%Y.log CUL_HM_switch_175686
attr FileLog_CUL_HM_switch_175686 logtype text
attr FileLog_CUL_HM_switch_175686 room CUL_HM
define CUL_HM_switch_175686_Sw_01 CUL_HM 17568601
attr CUL_HM_switch_175686_Sw_01 model HM-LC-SW2-FM
attr CUL_HM_switch_175686_Sw_01 room CUL_HM
define FileLog_CUL_HM_switch_175686_Sw_01 FileLog ./log/CUL_HM_switch_175686_Sw_01-%Y.log CUL_HM_switch_175686_Sw_01
attr FileLog_CUL_HM_switch_175686_Sw_01 logtype text
attr FileLog_CUL_HM_switch_175686_Sw_01 room CUL_HM
define CUL_HM_switch_175686_Sw_02 CUL_HM 17568602
attr CUL_HM_switch_175686_Sw_02 model HM-LC-SW2-FM
attr CUL_HM_switch_175686_Sw_02 room CUL_HM
define FileLog_CUL_HM_switch_175686_Sw_02 FileLog ./log/CUL_HM_switch_175686_Sw_02-%Y.log CUL_HM_switch_175686_Sw_02
attr FileLog_CUL_HM_switch_175686_Sw_02 logtype text
attr FileLog_CUL_HM_switch_175686_Sw_02 room CUL_HM

Wie du meintest erst das Device, dann die Kanäle + die entsprechenden Filelogs. Umbenannt und mit anständigen Rooms und Koords versehen sieht das dann so aus:

# Buero
define LichtBuero CUL_HM 175686
attr LichtBuero devInfo 020100
attr LichtBuero firmware 1.9
attr LichtBuero hmClass receiver
attr LichtBuero model HM-LC-SW2-FM
attr LichtBuero room CUL_HM
attr LichtBuero serialNr IEQ0xxx
attr LichtBuero subType switch
define FileLog_LichtBuero FileLog ./log/LichtBuero-%Y.log LichtBuero
attr FileLog_LichtBuero logtype text
attr FileLog_LichtBuero room CUL_HM

define LichtSchreibtisch CUL_HM 17568601
attr LichtSchreibtisch model HM-LC-SW2-FM
attr LichtSchreibtisch room Buero
attr LichtSchreibtisch fp_Groundfloor 652,412,1,Schreibtisch
define FileLog_LichtSchreibtisch FileLog ./log/LichtSchreibtisch-%Y.log LichtSchreibtisch
attr FileLog_LichtSchreibtisch logtype text
attr FileLog_LichtSchreibtisch room Buero

define LichtMalecke CUL_HM 17568602
attr LichtMalecke model HM-LC-SW2-FM
attr LichtMalecke fp_Groundfloor 721,569,1,Malecke
attr LichtMalecke room Buero
define FileLog_LichtMalecke FileLog ./log/LichtMalecke-%Y.log LichtMalecke
attr FileLog_LichtMalecke logtype text
attr FileLog_LichtMalecke room Buero

Über LichtMalecke und LichtSchreibtisch kann ich dann die einzelnen Kanäle des Devices steuern. Stimmt das so, falls ja änder ich mal den Wiki Eintrag.

Was mir noch aufgefallen ist: in andFHEM wird nur das Device LichtBuero gefunden. Ich muss erst den Kanälen das attribut subtype switch zuweisen damit sie in andFHEM auftauchen. Dann habe ich aber 3 Switches (1 Device, 2 Kanäle = LichtBuero,  LichtMaleck,  LichtSchreibtisch). Habe nun nach der Möglichkeit gesucht das Device (LichtBuero) zu verstecken, leider aber nichts gefunden. Hast du evtl. eine Idee wie man mit der Problematik umgeht?

Grüße

Martin

unread,
Dec 17, 2012, 7:24:00 AM12/17/12
to fhem-...@googlegroups.com
Hallo Christoph


Über LichtMalecke und LichtSchreibtisch kann ich dann die einzelnen Kanäle des Devices steuern. Stimmt das so, falls ja änder ich mal den Wiki Eintrag.

sieht gut aus. Der User sollte sich ueberlegen wieviele Logfiles er anlegen will. Dies kann eine ganz schoen lange liste ergeben, ist (fuer mich) schwierig zu handlen und kostet performance.

Was mir noch aufgefallen ist: in andFHEM wird nur das Device LichtBuero gefunden. Ich muss erst den Kanälen das attribut subtype switch zuweisen damit sie in andFHEM auftauchen.
habe ich nicht gewusst. mir wiederstrebt es, hier einen sybtype reinzukopieren...Dies ist kein Attribut den Kanals sondern des Device. Nachdem andFHEM dies sowieso speziell fuer HM gemacht hat koennten sie auch die Methode 'get param' benutzen.... da erhalten die den richtigen Wert fuer den channel.
 
Dann habe ich aber 3 Switches (1 Device, 2 Kanäle = LichtBuero,  LichtMaleck,  LichtSchreibtisch). Habe nun nach der Möglichkeit gesucht das Device (LichtBuero) zu verstecken, leider aber nichts gefunden. Hast du evtl. eine Idee wie man mit der Problematik umgeht?
du koenntest mit verschiedenen rooms arbeiten? und den 'deviceroom' nicht darstellen?

Gruss
Martin
Reply all
Reply to author
Forward
0 new messages