CUL_HM daten sortieren im nächsten update

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

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.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

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

Am Mittwoch, 12. Dezember 2012 14:16:31 UTC+1 schrieb Martin:
>
> 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
>
> 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.
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> 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


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

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

Am Mittwoch, 12. Dezember 2012 19:49:20 UTC+1 schrieb Martin:
>
>
> 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
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

Scheint ich habe das gleiche Problem wie es unter:

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

beschrieben ist

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 16. Dezember 2012 17:27:56 UTC+1 schrieb Christoph Zimmermann:
>
> Scheint ich habe das gleiche Problem wie es unter:
>
> https://groups.google.com/forum/?fromgroups#!topic/fhem-users/IGTbSWlnyGY
>
> beschrieben ist
>

sollte korrigiert sein
sorry
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[C. Zimmermann]

                                               

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com