Neues Modul HMCCU für Homematic CCU

[Loredo]

Super! Klasse, dass es voran geht!

2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden.

Das ist prima, bisher hatte ich mir ein Userreading dafür angelegt:

Code Auswählen Erweitern


attr FL_Light userReadings pct:.*1.LEVEL.* {  return int((ReadingsVal($name, $name."-".substr($trigger, 2, -2), "0") + 0.005) * 100); }



Allerdings brauche ich das Reading nach wie vor unter diesem Namen, damit ich den Fhem-Standard erhalte und mittels devspec ordentlich schalten kann. Wenn du auf der Agenda für V3.4 die verkürzten Readingnamen stehen hast, kannst du bitte auch bedenken, dass es eine Lösung geben muss, um auf die Fhem Standards Readings zu kommen, ggf. gleich inkl. entsprechendem Setter, so dass man sich eventMap sparen kann? Dann kann man endlich problemlos und ohne viel Aufwand mehrere Devices unterschiedlichen Typs mit Komma getrennt adressieren oder eine Structure verwenden.
Prima wäre deshalb, wenn man eine Mapping-Tabelle definieren könnte, die dann jeweils vorwärts und rückwärts verwendet wird, so dass man schließlich die Readings nur noch so erhält, wie man sie braucht.

Wie füge ich nun aber bei obigem Befehl noch eine Ramptime und einen Timer hinzu?

Ich habe bei mir z.B. bisher folgendes über HMLAN laufen gehabt und bekomme es mit der CCU2 per Fhem nun überhaupt nicht mehr gescheit ans laufen (Licht 5min an und keine Rampup-Zeit):

Code Auswählen Erweitern


DOELSEIF
(
  [FL_Motion:?motion] and
  [?HouseMode:state] eq "evening"
)
(
  set FL_Light:FILTER=pct=0 pct 15 600 0,
  set FL_Light:FILTER=pct!=0 pct [FL_Light:pct] 600 0
)


Ich hatte das wie folgt angepasst, aber es funktioniert nicht ordentlich:

Code Auswählen Erweitern


DOELSEIF
(
  [FL_Motion:?motion] and
  [?HouseMode:state] eq "evening"
)
(
  set FL_Light datapoint 1.ON_TIME 600,
  set FL_Light datapoint 1.RAMP_TIME 0,
  set FL_Light:FILTER=pct=0 pct 15,
  set FL_Light:FILTER=pct!=0 pct [FL_Light:pct]
)


Mit Hilfe des neuen Attributs ccuscaleval wirds jetzt etwas einfacher.

Also habe ich hier einmal die Definition einiger Geräte von mir, die gerne mit in den Standard ausgenommen werden können:

HM-LC-Dim1T-FM (HomeMatic Funk-Abschnitts- dimmer)

Code Auswählen Erweitern


ccureadingformat name ccuscaleval LEVEL:0.01
cmdIcon pct%200%200%202:general_aus
controldatapoint 1.LEVEL
devStateIcon .*set_.*:light_control@orange .*100.*:light_light_dim_100@orange:pct%200%200%202 on:light_light_dim_100@orange:pct%200%200%202 .*1[0-9].*:light_light_dim_10@orange:pct%200%200%202 .*2[0-9].*:light_light_dim_20@orange:pct%200%200%202 .*3[0-9].*:light_light_dim_30@orange:pct%200%200%202 .*4[0-9].*:light_light_dim_40@orange:pct%200%200%202 .*5[0-9].*:light_light_dim_50@orange:pct%200%200%202 .*6[0-9].*:light_light_dim_60@orange:pct%200%200%202 .*7[0-9].*:light_light_dim_70@orange:pct%200%200%202 .*8[0-9].*:light_light_dim_80@orange:pct%200%200%202 .*9[0-9].*:light_light_dim_90@orange:pct%200%200%202 .*[1-9].*:light_light_dim_00@orange:pct%200%200%202 .*0.*:light_light_dim_00:pct%20100%201800%201 off:light_light_dim_00:pct%20100%201800%201
event-on-change-reading pct,.*1.LEVEL.*
eventMap /control:pct/control 0:off/control 100:on/
stateFormat pct
statechannel 1
userReadings pct:.*1.LEVEL.* {  return ReadingsVal($name, $name."-".substr($trigger, 2, -2), "0"); }
webCmd pct%200%200%202
widgetOverride pct:slider,0,1,100


[chris1284]

vielen dank, läuft soweit ohne fehler

ein kleiner bug ist noch aufgefallen: nach dem fhem start zb der state eines devices true/false ist wird auch true / fals angezeigt statt den substitute werden. diese greifen dann erst wieder wenn man das gerät schaltet. ist mi bisher aber nur bei geräten aufgefallen die vor dem fhem-restart on waren (also korekt true ersetzt) und danach auch. false/off geräte habe fein die "ausgeschaltet glühlampe" als symbol und nicht false

FHEM Update --> einwandfrei!!!
- Verkürzte Readingnames --> fidne ich gut, machts übersichlicher und bringt weniger frickelei in der readingsgroup mit sich was regexp angeht!
- Erweiterung HMCCUCHN um on-for-timer  --> das fehlt mir aktuell wirklich

[Loredo]

Mir ist aufgefallen, dass ein und das selbe Reading mal die Werte 0/1 haben und dann mal false/true hat.



on-for-timer wird leider Fhem ausgeführt statt auf dem HM Gerät selbst. Hier müsste man das mit dem control/datapoint Kommando als weitere Parameter hinten mit angeben können, damit es im Gerät ausgeführt wird:


Parameter 1: Level
Parameter 2: Ontime
Parameter 3: Ramptime

[chris1284]

die einfach schalter bausätze machen schon on-for-timer selbst. das rawding working steht in der zeit auf 1 und die aktor led blink in der zeit.

[Loredo]

die einfach schalter bausätze machen schon on-for-timer selbst. das rawding working steht in der zeit auf 1 und die aktor led blink in der zeit.

Das ist gut zu wissen, aber es funktioniert eben leider nicht in der Kombination Dimmwert+Dauer bei einem Dimmer.

[Loredo]

Ich habe nun nach dem gestrigen Update einmal die Mehrzahl meiner Homematic Geräte versucht nach Fhem Standard vorzukonfigurieren.
Die dafür angepasste HMCCUConf.pm sowie einen Screenshot habe ich mal angehängt.

Neue Devices dabei:
HM-Sec-MDIR
HM-Sec-MDIR-2
HM-LC-Bl1-SM
HM-LC-Dim1T-FM
HM-LC-Dim1TPBU-FM
HM-LC-SW2-PB-FM
HM-OU-LED16

Bereits enthaltende Devices habe ich teils verbessert.
Insbesondere habe ich versucht die STATE Values von CUL_HM nachzuempfinden und außerdem die wichtigsten Readings nach Fhem Standard wie z.B. battery,level,pct,motor sowie dazu passende Setter (sofern sinnvoll) definiert. Außerdem habe ich bei den meisten Devices sinnvolle Vorbelegungen für die Bedienung mit FHEMWEB hinterlegt (devStateIcon,cmdIcon,icon,widgetOverride,webCmd).

Eigentlich scheint es mir damit jetzt recht gut nutzbar zu sein 



Gruß
Julian

[zap]

@Loredo und chris1284, Zu Euren Fragen und Anmerkungen:

Allerdings brauche ich das Reading nach wie vor unter diesem Namen, damit ich den Fhem-Standard erhalte und mittels devspec ordentlich schalten kann. Wenn du auf der Agenda für V3.4 die verkürzten Readingnamen stehen hast, kannst du bitte auch bedenken, dass es eine Lösung geben muss, um auf die Fhem Standards Readings zu kommen, ggf. gleich inkl. entsprechendem Setter, so dass man sich eventMap sparen kann?

Von einem FHEM Standard bei Readingnames ist mir nichts bekannt. Meinst Du Readingnames analog CUL_HM? Es war nie meine Absicht, CUL_HM nach zu bauen. Eine Lösung für individuelle Readingnames wäre vermutlich ein Attribut in der Art "attr ccumapnames Datenpunkt:Reading,Datenpunkt:Reading". Ich werde aber nicht fest Namen wie "pct" einbauen. HMCCU verfolgt einen generischen Ansatz. Das hat den Vorteil, dass neue Homematic Geräte sofort nutzbar sind. In CUL_HM muss immer erst der Entwickler aktiv werden und wenn ich mir den Quellcode von CUL_HM anschaue mit x Fallunterscheidungen sehe ich meine Entscheidung bestätigt.

Wie füge ich nun aber bei obigem Befehl noch eine Ramptime und einen Timer hinzu?

Ich habe leider keinen Dimmer. Aber wenn Du einen in FHEM mit HMCCUDEV anlegst, kannst Du wie folgt vorgehen:

Code Auswählen Erweitern


set mydimmer datapoint n.ON_TIME 600
set mydimmer datapoint n.RAMP_TIME 5   # Das ist optional
set mydimmer datapoint n.LEVEL 0.5


Den letzten Befehl kannst Du per Attribut ccuscaleval anpassen, damit er Werte von 0-100 akzeptiert.

Mit dem Set Befehl on-for-timer geht das auch kürzer. Dieser Befehl steht zur Verfügung, wenn ein Gerät einen Datenpunkt ON_TIME bereitstellt:

Code Auswählen Erweitern


attr mydimmer statedatapoint n.LEVEL
attr mydimmer statevals on:1.0,off:0.0
set mydimmer on-for-timer On-Time [Ramp-Time]


Nachteil: Es kann nur ein Zielwert für LEVEL verwendet werden (was mir gerade aufgefallen ist, das geht sicher noch besser, demnächst)

ein kleiner bug ist noch aufgefallen: nach dem fhem start zb der state eines devices true/false ist wird auch true / fals angezeigt statt den substitute werden

Das ist seltsam. Nach dem Start des RPC-Servers wird ein "get update" ausgeführt, das alle Geräte Readings aktualisiert. Dabei sollten auch die true/false Werte gemäß dem Attribut Substitute ersetzt werden. Es dauert nach dem Start von FHEM aber ggf. 1-2 Minuten, bis der RPC-Server läuft. Hast Du Fehler im Logfile, dass Readings oder Datenpunkte nicht aktualisiert werden konnten?

Mir ist aufgefallen, dass ein und das selbe Reading mal die Werte 0/1 haben und dann mal false/true hat.

Die RPC-Schnittstelle der CCU schickt 0/1, Homematic Script hingegen false/true (EQ-3 Logik . Daher sehen meine Substitutes immer so aus (z.B. für ein Fenster):

Code Auswählen Erweitern


attr mydev substitute (1|true):open,(0|false):closed


on-for-timer wird leider Fhem ausgeführt statt auf dem HM Gerät selbst. Hier müsste man das mit dem control/datapoint Kommando als weitere Parameter hinten mit angeben können, damit es im Gerät ausgeführt wird:

Verstehe ich nicht. Kannst Du das näher erläutern? Ich sehe schon: ich brauche einen Dimmer.

Noch eine Anmerkung zum Thema Rauchmelder: Ein Rauchmelder lässt sich nicht per Homematic Script oder RPC auslösen. Daher geht das mit HMCCU nicht. CUL_HM ist hier einfach näher am Protokoll unterwegs. Daher funktioniert es dort.

[zap]

Ich habe nun nach dem gestrigen Update einmal die Mehrzahl meiner Homematic Geräte versucht nach Fhem Standard vorzukonfigurieren.
Die dafür angepasste HMCCUConf.pm sowie einen Screenshot habe ich mal angehängt.

Vielen Dank!!!! Ich schaue es mir an und übernehme es in das nächste Release.

Die on-for-timer Geschichte ist wohl noch nicht so richtig durchdacht meinerseits. Das geht wirklich noch besser. Liegt halt daran, dass ich das nur mit einer normalen Steckdose getestet habe (ohne Dimmer Funktion).

[chris1284]

eine frage zur HMCCUConf.pm. sollten die attribute die da stehen bei einem define eigenständig geladen werden?
von den ganzen attributen wurde zb bei noch nie eines autom. gesetzt (was auch ganz gut ist wenn ich sehe das da cmdIcons gesetzt werden, nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?! 
kann man in fhem irgendwie sagen das es die config / ein teil der config anziehen und auf device xyz anweden soll?

[zap]

eine frage zur HMCCUConf.pm. sollten die attribute die da stehen bei einem define eigenständig geladen werden?
von den ganzen attributen wurde zb bei noch nie eines autom. gesetzt (was auch ganz gut ist wenn ich sehe das da cmdIcons gesetzt werden, nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?! 
kann man in fhem irgendwie sagen das es die config / ein teil der config anziehen und auf device xyz anweden soll?

Das automatische Laden der Attribute aus HMCCUConf.pm wäre noch eine Idee ... Im Moment werden diese Attribute per "set xy defaults" gesetzt. Eine Filterung bzw. Unterscheidung UI relevanter Attribute (cmdIcon usw) und anderer Attribute würde auch Sinn machen.

Die Idee hinter set defaults war, erst mal so viele Attribute wie möglich zu setzen und danach diese manuell anzupassen oder die überflüssigen zu löschen. Ich wollte damit einfach ein wenig Komfort für die verwöhnten CUL_HM Nutzer bereitstellen

[Loredo]

Das automatische Laden der Attribute aus HMCCUConf.pm wäre noch eine Idee ... Im Moment werden diese Attribute per "set xy defaults" gesetzt. Eine Filterung bzw. Unterscheidung UI relevanter Attribute (cmdIcon usw) und anderer Attribute würde auch Sinn machen.

Die Idee hinter set defaults war, erst mal so viele Attribute wie möglich zu setzen und danach diese manuell anzupassen oder die überflüssigen zu löschen. Ich wollte damit einfach ein wenig Komfort für die verwöhnten CUL_HM Nutzer bereitstellen

Ich sehe darin vor allem eine enorme Zeitersparnis. Meinetwegen kann auch zwischen UI und Funktion unterschieden werden, auch wenn ich nicht weiß was die Leute da immer mit Bevormundung meinen... entweder ich lade ein Template und passe die Settings hinterher meinen Vorstellungen an oder ich lasse es eben bleiben; es wird ja niemand gezwungen die Voreinstellungen beizubehalten.


Gleichwohl bin ich der Meinung, wenn man gute Voreinstellungen auch für die UI hat, dass viele Nutzer dabei gar noch etwas lernen, weil sie eben die ganzen Kniffe der verschiedenen Attribute und wie diese zusammenspielen schon gar nicht mehr überblicken können (da hilt reines lesen der CommandRef nämlich auch schon bald nicht mehr). devStateIcon beispielsweise wirklich korrekt auf alle möglichen STATE-Werte einzustellen und gleichzeitig noch für sinnvolles schalten zu verwenden, ist gar nicht so leicht.
Deshalb: Ich finde es klingt immer etwas arrogant anzunehmen, dass man es selbst besser kann als ein Template es einem vielleicht per Voreinstellung vorschlagen (nicht vorgeben!) würde. Die wenigsten User sind echte Gurus und diejenigen Gurus sollen dann doch, pardon - gefälligst, ihren Beitrag dazu leisten, dass die Templates mega gut werden. Ich persönlich kann mir einfach nicht vorstellen, dass jemand freiwillig gerne Stunden pro einzelnem Device verbringen möchte es zu konfigurieren, wenn andere das auch schon durchlebt haben. Bei 20 unterschiedlichen Devices braucht man da schonmal locker mehrere Arbeitstage. Und bei der Vielzahl an teils notwendigen Attributen und klitzekleinen Details, die direkt zu Fehlern führen können, ist auch ein Kopieren auf weitere Devices sehr mühsam. Die Templates sind deshalb nicht nur was für dumme, faule CUL_HM Menschen... 


So, genug gejammert, einen hab ich noch...


Der default-Setter sollte bitte eigentlich ein Getter sein. Wenn ich in FHEMWEB nämlich den Zugriff für normale Nutzer (=Nicht-Administratoren) beschränken möchte, dann begrenze ich in der Regel die FHEM-Befehle auf "set". Auch wenn die Oberfläche nicht alle Setter direkt anbietet, so kann ein Nutzer jedoch wissentlich die direkte URL aufrufen, um die Konfiguration eines vorhandenen Devices so zu überschreiben. Das sollte vermieden werden.
(die Bezeichnung des "get"-Befehls ist dabei IMHO nicht so wortwörtlich zu nehmen, aber auch mangels alternativem Admin-Only Befehl; dazu gab es in der Developer-Ecke schon viel Diskussion, jedoch ohne Outcome). Beim HMCCU Master Device muss diese Trennung nicht unbedingt sein; man kann dort den Zugriff auch auf Deviceebene sperren (konsequenter wäre es allerdings).


Was auch toll wäre, wäre ein neuer Getter unter dem HMCCU Master Device, welcher eine Auswahlliste aller in der CCU definierten Devices zeigt und für die sich dann passend ein HMCCUDEV oder HMCCUCHN Device anlegen lässt. Aktuell muss man immer zwischen Fhem und der CCU hin und her wechseln und sich mühselig die Namen und Seriennummern raussuchen. Das würde helfen, dass man die vorhandenen Devicenamen aus der CCU auch direkt in Fhem so anlegt.


Was mich noch zu einem Hinweis führt: Damit die userReadings in meinen Beispielen in der HMCCUConf.pm kürzer sind wird davon ausgegangen, dass die Devicenamen in der CCU und in Fhem gleich sind. Andernfalls lässt sich nicht so einfach auf die Readingsnamen schließen (solange das mit den Readingsnamen ansich nicht gelöst wurde zumindest). Damit die userReadings zwischen Devices einigermaßen portabel bleiben, wird dort über aus dem verwendeten Trigger der Readingsname gebildet. Ist zwar auch nur bedingt schön, weil man auch die substr() Anweisung bei der Änderung des Triggers peinlich genau anpassen muss. Aber es ist immerhin kürzer und portabler, als es für jedes einzelne Device individuell mit den Device-spezifischen Readingnamen reinzuschreiben. Ich denke dieses Beispiel zeigt ganz gut, dass man an dieser Stelle nochmals überlegen sollte, ob die Readingsnamen tatsächlich jemals diesen Präfix des Devicenamen brauchen oder ob man den nicht einfach weg lassen kann 


Übrigens noch etwas (sorry - wenn's sprudelt, dann sprudelt's  ): Die Readingnamen für Kanal 0 werden immer mit einem Punkt "." an den Devicenamen angeschlossen. Bei den höheren Kanälen (1,2,3 ...) ist es ein Bindestrich. Das ist inkonsequent und sollte vereinheitlicht werden. Auch hier zeigt sich bei Nutzung der userReadings wieder eine gemeine Stolperstelle, bei der man den substr() Befehl entsprechend angleichen muss. Besonders gemein ist das auch, weil LOWBAT z.B. mal im Kanal 0 liegt und mal im Kanal 1 und man diese Anweisungen nicht einfach so kopieren kann, sondern dann je nach Device-Typ bzw. Kanal-Struktur wieder richtig anpassen muss.
Solange diese Stoplersteine so sind, helfen die Templates nochmals in mehrfacher Weise diese zu vermeiden - besonders weil Fehler in userReadings oftmals aufwändig zu debuggen sind.

[...] nur lowbat statt batterie_state geholt wird oder zb lowbat false in no statt ok substitiert wird)?!

Der durch CUL_HM eingeführte Standard für die Batterie ist nunmal "ok" und "low". Alle Beispiele, vorhandenen Scripts (auch hier im Forum) etc sind eben zumeist auf diese Values ausgelegt. Daher macht es Sinn diese eben auch so beizubehalten. Ziel sollte doch sein, dass man auch ohne vermeidbare Schmerzen von CUL_HM auf HMCCU umsteigen kann (und ggf. wieder zurück).

[chris1284]

Deshalb: Ich finde es klingt immer etwas arrogant anzunehmen, dass man es selbst besser kann als ein Template es einem vielleicht per Voreinstellung vorschlagen (nicht vorgeben!) würde.

ich finde es da ehr arrogant  zu meinen mein Template sei das beste und es deshalb per default zu verteilen / usern aufzwingen zu wollen (evtl kann der user es ja doch besser /will es garnicht so)

Die lösung das template optional einzubindne fände ich super (ich schaue da nur die teile ab die ich brauche für meine anforderungen da ich FHEMWEB nicht als UI zum schalten benutze, ich schaue sie auch nur selten an und brauche daher keine bunten buttons oder bildchen,sondern brauche nur reine funktionsbereitstellung für TUI).

noch besser: die optionen
- nutze default-template [defaul]
- nutze user-template
- nutze garkein template

dies schön per attribut in der ccu konfigurierbar machen. so macht man alle glücklich (anfänger/faule , faule individualisten und die "do it yourself leute")

wie zap schon sagte will er das modul so generisch wie möglich halten und das finde ich gut. alles kann nur weniges muss (und das sollte nur das sein was die funktionalität sichert und dazu brauchts nunmal keine buttons oder bildchen oder web-cmds)

Der durch CUL_HM eingeführte Standard für die Batterie ist nunmal "ok" und "low".

mag sein, interessiert mich aber nicht wirklich. und da man hier ja glücklicherweise mit hmccu nicht wirklich eingeschränkt wird finde ich es gut das template nicht nutzen zu müssen!

Was auch toll wäre, wäre ein neuer Getter unter dem HMCCU Master Device, welcher eine Auswahlliste aller in der CCU definierten Devices zeigt und für die sich dann passend ein HMCCUDEV oder HMCCUCHN Device anlegen lässt. Aktuell muss man immer zwischen Fhem und der CCU hin und her wechseln und sich mühselig die Namen und Seriennummern raussuchen.

hier wäre ein autocreate (per attribut aktivier und deaktivierbar) evtl. besser. ich persönlich muss zum anlegen irgendiwe keine namen und seriennummern mühselig kopieren..... 

[Loredo]

ich finde es da ehr arrogant  zu meinen mein Template sei das beste und es deshalb per default zu verteilen / usern aufzwingen zu wollen (evtl kann der user es ja doch besser /will es garnicht so)

Wer lesen kann... niemandem soll was aufgezwungen werden. Wir reden wohl auch leicht aneinander vorbei, obwohl wir im Kern nicht weit voneinander weg sind. Das Template muss niemand benutzen, darf/kann es aber. Das muss auch überhaupt nicht automatisch passieren, nachdem ich ein Device frisch definiert habe. Den Setter/Getter dazu aufzurufen wird jeder noch selbst schaffen...

wie zap schon sagte will er das modul so generisch wie möglich halten und das finde ich gut. alles kann nur weniges muss (und das sollte nur das sein was die funktionalität sichert und dazu brauchts nunmal keine buttons oder bildchen oder web-cmds)

mag sein, interessiert mich aber nicht wirklich. und da man hier ja glücklicherweise mit hmccu nicht wirklich eingeschränkt wird finde ich es gut das template nicht nutzen zu müssen!

Von "müssen" hat niemand was geschrieben. Es war, ist und bleibt nach meinem Verständnis ein Zusatzangebot.


Gegen den generischen Ansatz des Moduls ansich spricht ja auch gar nichts, da verstehst du (oder versteht ihr) mich offenbar vollkommen falsch.
Ich spreche ja davon, dass sich die HMCCU Devices harmonisch in eine Fhem Installation einfinden können (nicht jeder hat nur HM Geräte, sondern auch jede Menge anderer Gerätetypen). Da gehört es zum generischen Ansatz dazu, dass eine Austauschbarkeit des Backends möglich wird und man auch HM-Geräte zusammen mit nicht-HM-Geräten handhaben kann. Das hat auch nichts mit der UI zu tun, sondern damit, dass man z.B. für die einfache Nutzung der :FILTER Funktion in eigenen Scripts und Automationen die selben Readingnamen benötigt. Dafür haben sich bei den anderen Modulen einfach gewisse Standards herausgebildet. Wenn sich HMCCU nicht daran angleichen lässt, wird es für die wirklichen Nerds einfach nicht nutzbar sein/werden, weil es einfach zu sehr eine Sonderlocke bleibt und ich einmal an anderer Stelle in Fhem gelerntes nicht für HMCCU wiederverwenden und anwenden kann.
Ich habe verstanden, dass genau diese Sonderlocke eben durch den generischen Ansatz vermieden werden soll. Das finde ich ja großartig und prima; alles was ich sage ist, dass das noch nicht weit genug zu Ende gedacht ist und es deshalb Möglichkeiten geben muss an die Fhem Standards heranzukommen. Wie meine HMCCUConf Beispiele zeigen geht das auch heute schon, ist aber eben sehr mühselig und für jemanden, der die Fhem Standards nicht kennt auch schwer umzusetzen. Da helfen dann die Templates schon sehr. Anfängern kann man deshalb nur raten die Templates dann auch zu nutzen, damit das HMCCU Setup auch später ohne großen Mehraufwand erweiterbar bleibt und man im Laufe der Zeit alle Funktionen (heutige und zukünftige) von Fhem nutzen kann. Diese bleiben einem halt verwehrt, wenn man die HMCCU-Devices nicht von Anfang an entsprechend anlegt. Jeder hat die Freiheit sich bewusst dagegen zu entscheiden. Einigen Leuten sollte man aber auch ehrlicherweise sagen, welche Einschränkungen sie sich damit für eine spätere Erweiterung und Komplexisierung der Fhem Automationen ins Haus holen. Wer dann - wie du, chris1284 - sich trotzdem für seinen eigenen Weg entscheidet, der kann das ja tun und wird um Gottes Willen nicht dafür verurteilt oder gebrandmarkt! Ich möchte eben nur anmerken, dass man einige User, die mit Fhem noch keine jahrelange Erfahrung mit komplexen Setups haben, auch die Möglichkeit geben muss sie vor einem Chaos zu bewahren und Fhem für sie sonst irgendwann eher eine Negativerfahrung wird. In der Doku zu den Templates sollte dann deshalb auch ganz klar darauf hingewiesen werden, warum sie da sind und insbesondere was die Ziele sind und weshalb es Sinn macht sich an Fhem Standards zu orientieren. Wenn man all das weiß und es doch anders macht kann man sagen "You've been warned, we made you aware of it!".

[chris1284]

ist doch ehr die frage, wer gibt die fhem standards für die readingsbezeichnung vor(das ältere modul? rudi? )...
denn es gibt keinen festgelegten reading-bezeichnungsstandard in fhem (wenn ja, habe ich die doku noch nicht finden können). Nur weil ein  großteil etwas auf eine bestimmte art und weise macht, macht es das nicht zum standard 

Ich finde das durchaus sinnvoll das ein readings für auswertungen gleich ist (battery, humditity, temprature, usw) aber wer sagt zb ob nun set_tempratue oder desired-temp, BATTERY_STATE oder batteryLevel für alle thermostate (max,hm,fs20, usw suw) einzusetzen ist? das ist denke ich ein grundlegendes problem aller module

[Loredo]

ist doch ehr die frage wer gibt die fhem standards vor...

Ist wie immer demokratisch in Fhem: Einer hat es mal vorgemacht, andere haben sich ggf. daran orientiert und nun haben es mehrere Module (wenn auch nicht unbedingt alle) eben so implementiert. Das sind dann quasi Defacto-Standards, für die es sich lohnt einmal darüber nachzudenken was denn dagegen spricht, sich denen ebenfalls anzuschließen. Im Zweifel setzt für mich auch das Modul den Standard, welches die größte Nutzerschaft hat (siehe Stats).


Nur weil es ein Problem ist, was einige andere Module auch haben, muss man doch nicht bei einem neuen Modul diese Fehler wiederholen oder ignorieren? Wir lernen doch alle dazu, oder nicht