warum so viele Dummies?

[Thorsten Pferdekaemper]

Apropos...
schau mal meine Frage zum Thema dummy an: https://forum.fhem.de/index.php/topic,69857.0.html

Warum sollte ich das? (Du hast das als Antwort auf meinen Beitrag gepostet, daher vermute ich einen Bezug, kann aber keinen finden.)

Keiner kann mir sagen, warum das $EVENT, welches nach commandref auch den rgb-Wert enthalten sollte, dies nicht tut....

Vielleicht weiß es einfach keiner. Trotzdem wäre das besser im entsprechenden Thread aufgehoben und nicht hier.
Übrigens hat Dir KernSani meiner Meinung nach schon einen guten Hinweis gegeben: Wahrscheinlich ist das ein Problem des ECMD-Moduls und Du solltest das ganze in den zugehörigen Forenbereich verschieben.
Gruß,
   Thorsten

[Beta-User]

Zu Ellert's Beitrag:

Bin da erst am Austesten, aber nach meinem Verständnis könnte man doch die Information der Weckzeit auch z.B. bei dem device (im Sinne von define), das dann zum Wecken dienen soll, direkt als Inhalt eines userattr ablegen. Eine Änderung des Attributs wird auch im Eventmonitor gemeldet, also sollte das auch im Rahmen eines notify auswertbar sein.
Die Frage ist dann nur, wie man das dann sinnvoll auf einer Oberfläche dargestellt bekommt. Da habe ich aber im Moment ein Beispiel vor Augen, wo das so ähnlich, wie es auch für Zeiten erforderlich wäre, über ein "commands"- Attribut einer Readingsgroup gelöst war.

Aber bevor ich hier ernsthaft ins Testen einsteige, lasse ich mich von Experten gerne eines besseren belehren .

Gruß, Beta-User

[Deckoffizier]

Hallo Thorsten Pferdekaemper,

NeuFehm hatte explizit geschrieben  im Forum .

Forum ist für mich im Forum und nicht ausschließlich alleine im Thread oder die Person,en.

Es müssen damit noch nicht mal die alten erfahrenen Hasen damit gemeint sein.

Wenn Du Dich oder diesen Thread, Bereich ausgrenzen wolltest aus der allg. Meinung von NeuFehm geht das für mich voll in Ordnung.
Wollte Dir auf keinen Fall zu nahe treten wenn wir es unterschiedlich "angenommen" haben.

Für meinen Teil lassen wir es gut sein .

Gruß
Hans-Jürgen

[NeuFehm]

ICh wollte mal "Enspannung" melden. Nein, es geht nicht um "Dich" (Thorsten Pferdekaemper). Ich hatte hier meinen Senf hinzugegeben, warum ich denke, dass man so viel mit dummys regelt und ein Beispiel gepostet. Die Reaktion war die, dass man mit klar machte, dass man das schon anders regeln könnte.... aber eben sagte einfach nicht wie. Und diese Antwortserie! ohne Lösung aber mit viel Kommentar war dann der Anlass dies mal als Denkanstoß zu formulieren. Es war reiner Zufall, dass ich direkt nach Dir gepostet hatte und bezog sich keinesfalls auf eine Deiner Aussagen.

Und nur "EIN" weiteres Beispiel, welches ich im Text erwähnt habe, war das Thema mit den Tütchen:
https://forum.fhem.de/index.php/topic,30946.msg355160.html#msg355160

[Ellert]

Zu Ellert's Beitrag:

Bin da erst am Austesten, aber nach meinem Verständnis könnte man doch die Information der Weckzeit auch z.B. bei dem device (im Sinne von define), das dann zum Wecken dienen soll, direkt als Inhalt eines userattr ablegen. Eine Änderung des Attributs wird auch im Eventmonitor gemeldet, also sollte das auch im Rahmen eines notify auswertbar sein.
Die Frage ist dann nur, wie man das dann sinnvoll auf einer Oberfläche dargestellt bekommt. Da habe ich aber im Moment ein Beispiel vor Augen, wo das so ähnlich, wie es auch für Zeiten erforderlich wäre, über ein "commands"- Attribut einer Readingsgroup gelöst war.

Aber bevor ich hier ernsthaft ins Testen einsteige, lasse ich mich von Experten gerne eines besseren belehren .

Gruß, Beta-User

Ich kenne nur eine Lösung ohne Dummy, unter Verwendung von DOIF, die ich hier nicht verschweigen möchte.

Die Definition kann über Raw definition importiert werden ( https://wiki.fhem.de/wiki/Import_von_Code_Snippets )

Code Auswählen Erweitern

defmod Wecker DOIF ([[$SELF:WZ]])  {Log 1, "geweckt"}
attr Wecker do always
attr Wecker readingList WZ
attr Wecker setList WZ:time
attr Wecker webCmd WZ

setstate Wecker initialized
setreading Wecker WZ 08:35

Die Zeitangabe erfolgt indirekt, sie wird daher in einer eckigen Doppelklammer angegeben. Diese Art der indirekten Zeitangabe ist DOIF spezifisch und kann in anderen Modulen nicht verwendet werden.

$SELF bezieht sich auf den Eigennamen des DOIF. Damit bedeutet [[$SELF:WZ]] das gleiche wie [[Wecker:WZ]]. In dem Reading WZ steht die Weckzeit.

Das Attribut do always ist erforderlich damit jeden Tag geweckt wird, analog zum * im at

Das Attribut readingList gibt ein Reading (WZ) an, das über set gesetzt werden kann.

Das Attribut setList bestimmt welche Werte gesetzt werden und bestimmt das im Frontend angezeigte Widget; hier: time.

Das Atttribut webCmd zeigt das Widget im Frontend an.

[Prof. Dr. Peter Henning]

@Thorsten: Du schriebst etwas von "anderer Kategorie" - nein, eben nicht. Die genannten Programmierparadigmen sind sehr genau definiert, kann ich Dir gerne im Detail auseinandersetzen.

Es geht wirklich um eine Frage der Denkweise - funktionale Programmierung beispielsweise kennt eben keine Zustandsvariablen (aka Dummies).

LG

pah

[Thorsten Pferdekaemper]

@Thorsten: Du schriebst etwas von "anderer Kategorie" - nein, eben nicht.

Das Wort "Kategorie" kam in meinem Beitrag glaube ich nicht vor. Wahrscheinlich beziehst Du Dich auf das hier:

Imperativ/deklarativ/funktional ist meiner Meinung nach eine andere Dimension als objektorientiert/datenorientiert/funktionsorientiert.

Ich hatte mich dabei vor Allem auf Deine Unterscheidung "imperativ vs. objektorientiert" bezogen. Meiner Meinung nach ist aber das Grundparadigma der meisten Sprachen, die sich "objektorientiert" schimpfen eigentlich imperativ. Oder anders gesagt: "imperativ" und "objektorientiert" schließt sich nicht aus. Genauso gibt es auch deklarative objektorientierte Sprachen (z.B. F-Logik) und man kann natürlich auch in Java weitestgehend ein funktionales objektorientiertes Paradigma einhalten, aber es geht auch funktional datenorientiert. Das meinte ich mit "andere Dimension": Man kann die Begriffe aus der ersten Liste beliebig mit Begriffen aus der zweiten Liste kombinieren.

Die genannten Programmierparadigmen sind sehr genau definiert, kann ich Dir gerne im Detail auseinandersetzen.

Das ist nicht unbedingt nötig. Mein Studium ist zwar ungefähr 20 Jahre her, aber einiges ist dann doch hängengeblieben.

Es geht wirklich um eine Frage der Denkweise - funktionale Programmierung beispielsweise kennt eben keine Zustandsvariablen (aka Dummies).

Vermutlich verstehe ich jetzt so ungefähr, was Du gemeint hast: Anstatt neue Variablen einzuführen kann man auch Funktionen verketten. Das könnte tatsächlich manchmal eine Möglichkeit sein, Dummys loszuwerden. Tatsächlich sehe ich auch fast tagtäglich viele unnötige Variablen (nicht in FHEM, sondern bei der Beschäftigung, für die ich bezahlt werde).

Gruß,
   Thorsten

[ralfix]

Hallo Dummy-Kritiker,

mein letzten beiden Dummy habe ich gerade für Waschmaschinensteuerung erstellt.
Eines um den Status der Maschine zu abstrahieren, und mit devStateIcon zu visualisieren.
Geschaltet wird es vom Stromverbrauch per notify.

Und ein zweites Dummy um per FHEMWEB die Startzeit der Wachmaschine einstellen zu können, welches wiederum
per notify auf ein AT per modifyTimeSpec wirkt.

Für Fall Nr.1 sehe ich keine sinnvolle Alternative.
Fall Nr.2 musste ich leider machen, weil AT kein setList kennt.

Grundsätzlich benutze ich Dummy immer, wenn ich ein Variable zum Schalten im Frontend
oder zur Statuserfassung brauche. Finde ich praktisch, elegant und gut konfigurierbar.
Was sollte daran schlecht sein?

Gruß Ralf

[igami]

Hallo Dummy-Kritiker,

mein letzten beiden Dummy habe ich gerade für Waschmaschinensteuerung erstellt.
Eines um den Status der Maschine zu abstrahieren, und mit devStateIcon zu visualisieren.
Geschaltet wird es vom Stromverbrauch per notify.

Und ein zweites Dummy um per FHEMWEB die Startzeit der Wachmaschine einstellen zu können, welches wiederum
per notify auf ein AT per modifyTimeSpec wirkt.

Für Fall Nr.1 sehe ich keine sinnvolle Alternative.
Fall Nr.2 musste ich leider machen, weil AT kein setList kennt.

Grundsätzlich benutze ich Dummy immer, wenn ich ein Variable zum Schalten im Frontend
oder zur Statuserfassung brauche. Finde ich praktisch, elegant und gut konfigurierbar.
Was sollte daran schlecht sein?

Warum reicht denn icht ein dummy dafür aus?

[Damian]

Was sollte daran schlecht sein?

Gruß Ralf

Die Anzahl der Module Ich würde es mit einem machen.

[Jojo11]

Hat der Einsatz vieler dummies einen Einfluss auf die Performance?
Gibt es sonst irgendeinen anderen negativen Effekt?

Schöne Grüße
Jo

[Damian]

Hat der Einsatz vieler dummies einen Einfluss auf die Performance?
Gibt es sonst irgendeinen anderen negativen Effekt?

Schöne Grüße
Jo

Wenn es nicht Tausende sind, dann wirst du es nicht merken.

Es geht aber aus Sicht eines Programmierers in die Richtung: "Am Anfang sind globale Variablen ganz praktisch..."

[ralfix]

Warum reicht denn icht ein dummy dafür aus?

Hast recht, eigentlich reicht ein Dummy. Da werde ich wohl noch etwas optimieren.
Danke für den Denkanstoß.
Gruß Ralf

[ralfix]

Ja es reicht auch ein Dummy.

[Benni]

Könntest Du mal sagen, auf welchen Beitrag in diesem Thread Du Dich beziehst?

Nun, wenn ich ihn richtig verstanden habe, bezieht er sich nicht auf einen bestimmten Beitrag, sondern auf den Begriff "Dummie" im Thread-Titel. Damit fühlt er sich anscheinend angesprochen, ohne zu wissen, dass damit Dummy-Devices gemeint sind, um die es ja in diesem Thread geht.

Hätte halt mal mehr lesen sollen als nur die Überschrift.
Der Erste Beitrag hätte ja eigentlich schon gereicht .

Aber so ist das eben ...