Hallo Zusammen,
mal eine Frage in die Runde:
Warum werden immer so viele Dummies benutzt?
Beispiel:
ein Dummy wird gesetzt um eine Sonos einzuschalten....
set DummySonos off
notify auf DummySonos --> set Sonos off
in gerfühlt 80-90% der Fälle kann ich dich direkt auf den Status des Realen Devices via ReadingsVal/Value bzw [Device:Reading] zugreifen und brauche gar keinen Dummy mehr
Mach ich eigentlich nur wenn ich im Webif oder Wandtablet noch einen Button für das Device haben möchte...
VG
Frank
Hi,
aus dem Einsteiger-PDF:
Zitat
In fhem können dummy-devices angelegt werden, die wie eine Variable genutzt werden können.
Außerdem wird im "Erste Schritte" Tutorial viel mit Dummys gearbeitet (das geht dort halt nicht anders).
Ich denke mal, daher sind Dummys vertraut.
Wahrscheinlich werden sie auch verwendet, um die Komplexität des eigentlichen Device zu verstecken. Sozusagen als Ersatz für ein schönes Frontend.
Gruß,
Thorsten
Also ich kann mich noch erinnern:
ich habe auch erst mal einen Dummy genommen bevor ich irgendein "echtes" Gerät angefasst habe...
...tue dies wie bereits geschrieben (nur) noch, wenn ich etwas einfach über einen eigenen Knopf (oder ein paar) steuern möchte oder etwas oder mir Zwischenwerte etc. merken will...
...ja könnte ich auch per userReadings direkt am Gerät tun...
...aber irgendwie will ich das immer noch nicht so recht "anfassen" ;)
Haben viele dummy so schlechten Einfluss?
Also ich meine jetzt nicht übertrieben viele, nur viele ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 03 März 2017, 10:54:41
Haben viele dummy so schlechten Einfluss?
Also ich meine jetzt nicht übertrieben viele, nur viele ;)
Hallo Joachim,
ich denke, der Einfluss auf die Performance ist nur bei wirklich schwacher Hardware signifikant. Hier ne Millisekunde, da ein paar Mirkosekunden da kann schon mal ein wenig zusammen kommen ...
Um den wirklich bewussten Einsatz ging es mit hier auch nicht - aber z.B. um den (besonderen) Zustand von einem Gerät zu "tracken" brauche ich doch kein Dummy ein SetReading in das Device erfüllt in meinen Augen den gleichen Zweck und ich muss mich bei der Einrichtung/Fehelersuche nicht durch "tausende" Devices hangeln ...
ich benutze auch dummies ;-) Diese werden von Außen mit Daten befüllt, damit ich keine Abhängigkeiten habe, die einen Haupt FHEM Start verhindern können :-)
Ich sehe das ähnlich wie die Frage neulich zum Thema "DoIf": Wo es mir Vorteile bringt bzw. es nicht anders elegant lösbar ist, verwende ich Dummies - sonst nicht.
Habe auch denke ich nicht mehr als 2 oder 3 im System momentan...
Hallo Wuppi68,
ich glaube Dummy klingt gerade am Anfang erstmal harmlos und ist ziemlich gut sichtbar und "greifbar" mit scheinbar null Systemeinfluss.
setReading oder userReadings kommt viiiel später, dort mache ich was mit dem Device was ich doch häufig gar nicht angelegt habe. Zumindest habe ich "selbst" nie Readings angelegt sondern ich habe "nur" define gemacht (oder autocreate hast gemacht). ;)
Da ist doch die Hemmschwelle viel größer.
Ich habe schon einige, sie vergegenständlichen doch häufig "virtuelle Instanzen".
Gruß Otto
Zitat von: r00t2 am 03 März 2017, 11:20:39
Ich sehe das ähnlich wie die Frage neulich zum Thema "DoIf":
...und genause wie beim DOIF-Thread ist das eine gute Gelegenheit sich mit den verschiedenen Aspekten des Konzepts auseinanderzusetzen.
Zitat von: Otto123 am 03 März 2017, 11:44:44setReading oder userReadings kommt viiiel später, dort mache ich was mit dem Device was ich doch häufig gar nicht angelegt habe. Zumindest habe ich "selbst" nie Readings angelegt sondern ich habe "nur" define gemacht (oder autocreate hast gemacht). ;)
Für mich ist das genau anders herum. Ich glaube, das ich in meinem Produktivsystem keinen einzigen Dummy habe. Entweder ich brauche ein Reading, das logisch zu einem schon existierenden Gerät gehört, dann mache ist das mit dem Attribut userReading oder dem Befehl setreading, oder ich brauche sozusagen ein neues "Hilfsdevice", dann ist das bei mir meistens ein at, welches sich selbst die benötigten Readings per setreading setzt.
Gruß,
Thorsten
Ich hab fast nur dummys :-)
Für meine Funksteckdosen hab ich welche um sie dann im Tablet UI anzuzeigen. Im Alarm Modul hab ich viele, um z.B. einen Alarm separat noch mal anzupassen (z.B. soll nach 20 Uhr keine Soundausgabe erfolgen wenn ein Fenster langer auf war, aber eine Telegramm Meldung raus gehen) Die dummys kann ich so nach belieben an oder ab schalten oder eine Zeit angeben.
Und mehrere die nur im Tablet UI angezeigt werden.
Gesendet von meinem Wileyfox Swift mit Tapatalk
Ich habe einige Dummys. Die meisten stammen aus der Anfangszeit. Im Rahmen der gegenwärtigen Aufräumaktion prüfe ich ob es nicht ohne geht. Eine Handvoll ist dadurch schon weg.
Grundsätzlich finde ich es nicht schlimm. Es ist am Anfang "übersichtlicher" und wie schon gesagt "vergegenständlicht" es.
Bequemlichkeit wird so auch unterstützt, man sieht den Status eines Dummys eben schneller als voneinander abhängige Readings.
Ich habe ca. 50 Dummies in meiner produktiven FHEM-Instanz.
Die meisten (ca. 50%) davon sind für die Verwendung in Frontends (Infopanel oder Alexa), entweder zum vereinfachten Schalten, oder zur Visualisierung.
Von den restlichen 50% sind wiederum ca. die hälfte (i.d.R. temporär) für irgendwelche Tests. Ja, ich teste durchaus diverse Logiken gerne mal in der Produktivumgebung ;D
Der Rest ist halt noch von "Früher" übrig, da könnte man sicher manches umbauen und bspw. auf Readings von echten Devices legen, aber es läuft ja auch so ;)
Gerade nochmal drübergeschaut: Da gibt es doch einiges an Optimierungspotenzial. Werde wohl demnächst mal etwas ausmisten.
Danke für den Denkanstoß!
Komme eben mal auf 3, nutze aber derzeit nur FHEMWEB als Frontend...
Die drei stehen für
- Ferien (vermutlich nach Einsteigerdokument),
- aktuelle Nutzungsart des Gästezimmers,
- Urlaub
Da ich mich grade etwas ins perl-coding einzudenken versuche, bin ich auch über die Frage gestolpert, wo ich ab besten bestimmte Informationen hernehme und abspeichere. Dabei hatte ich den Eindruck, dass viele, die etwas weiter waren als ich (aber keine Experten) dummies genau dafür nutzen und das dann häufig auch in einer größeren Anzahl.
Als Grund hierfür glaube ich nunmehr ausgemacht zu haben, dass fast allen der betreffenden User (wie mir auch) nicht klar war, wie mit userattr sinnvoll umzugehen ist (womit nicht die Behauptung verbunden ist, dass ich da jetzt den Durchblick habe) und es (meistens) am sinnvollsten ist, Einstellungen und Informationen, die für ein bestimmtes Gerät (im Sinne eines Gegenstandes in der Realität) gelten sollen, auch beim entsprechenden device (als dessen Entsprechung=define innerhalb FHEM) direkt abzuspeichern.
Auch der nächste Schritt, nämlich wie mit einer gespeicherten Information (bzw. deren Änderung) umzugehen ist, kann man sich dann auch wieder nur durch die Analyse (guter?) Beispiele (oder evtl. ganzer Module) erschließen. Wenn man sucht, findet man dazu tatsächlich einiges, herzlichen Dank an der Stelle an die, die ihre Beispiellösungen gepostet haben! :) :) :)
Jedenfalls auf die Schnelle sind zu dem Thema praktisch auch keine Grundlageninformationen im Wiki (oder Einsteiger-pdf) zu finden.
Frage an die versammelte Kompetenz hier: Wäre es nicht sinnvoll, dies (z.B. im Umfeld zu 99_myUtils) anhand eines einfach nachzuvollziehenden Beispiels für vorerst Ratlose wie (hoffentlich ehemals ::)) mich darzustellen? Anbieten würde sich m.E. eine Zwangsöffnung eines Rolladens (bei gesetzter Automatik), wenn man das Fenster öffnet oder Benni's Globale, flexible Fenster-/Tür-Offen-Meldungen (https://forum.fhem.de/index.php/topic,36504.0.html) (der code braucht aber mehr "drumrum" wie einen Nachrichtendienst).
Gruß, Beta-User
Zitat von: franky08 am 03 März 2017, 08:26:14
Mach ich eigentlich nur wenn ich im Webif oder Wandtablet noch einen Button für das Device haben möchte...
Zitat von: Benni am 05 März 2017, 08:06:37
Die meisten (ca. 50%) davon sind für die Verwendung in Frontends (Infopanel oder Alexa), entweder zum vereinfachten Schalten, oder zur Visualisierung.
Das geht im InfoPanel ganz ohne zusätzliche dummies.
Zitat von: betateilchen am 30 März 2017, 11:30:41
Das geht im InfoPanel ganz ohne zusätzliche dummies.
Im Prinzip ja, aber nicht, wenn man in FHEMWEB andere Status-Icons verwenden will, wie im InfoPanel.
Habe das inzwischen weitgehend so gelöst, dass ich für InfoPanel eine eigene FHEMWEB-Instanz eingerichtet habe, bei der ich dann ein anderes Icon-Set verwende.
Hast du noch eine bessere Methode auf Lager?
Es gibt Funktionen, die stehen nur dem dummy zur Verfügung. Beispielsweise kann man kein ECMD-Device einen Colorpicker zuweisen. Hier hilft ein dummy. ist der Wert ermittelt, kann man dann per notify die Werte übertragen. Dummy macht einfach alles mit, unabhängig vom verwendeten Device und dessen Möglichkeiten.
wenn ein ecmd device readings und set kommandos hat kann man auch den colorpicker verwenden.
ansonsten ist ein readingsproxy einfacher als ein dummy und ein oder mehrer notifys.
und wenn es nur um readings geht: sie kann man direkt ins original device stecken.
geht:
define RGBLampe dummy
attr RGBLampe room LED
attr RGBLampe setList rgb:colorpicker,RGB
attr RGBLampe webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
define colorInit notify global:INITIALIZED {use Color}
geht nicht:
define RGBLampe ECMDDevice MModul
attr RGBLampe IODev myMModul
attr RGBLampe room LED
attr RGBLampe setList rgb:colorpicker,RGB
attr RGBLampe webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
define colorInit notify global:INITIALIZED {use Color}
und widgetOverride?
wie geht das?
Zitat von: NeuFehm am 30 März 2017, 22:32:19
wie geht das?
Wie in der commandref beschrieben ;)
Haben wir deshalb so viele Dummies bei den Devices, weil wir so viele Dummies unter den Usern haben ? 8) 8)
Ernsthaft: Anfänger denken meist imperativ, können mit objektorientierter oder funktionaler Programmierung wenig anfangen. Insofern ist es in meinen Augen ganz natürlich, dass jeder Anfänger mit dutzenden von Dummies beginnt. Die Hoffnung bleibt, dass derjenige (oder diejenige) sich im Lauf der Zeit eines Besseren besinnt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 März 2017, 11:14:31Ernsthaft: Anfänger denken meist imperativ, können mit objektorientierter oder funktionaler Programmierung wenig anfangen.
Imperativ/deklarativ/funktional ist meiner Meinung nach eine andere Dimension als objektorientiert/datenorientiert/funktionsorientiert.
Zitat
Insofern ist es in meinen Augen ganz natürlich, dass jeder Anfänger mit dutzenden von Dummies beginnt.
Was ist denn bei einem Dummy mehr "imperativ" als z.B. wenn man ein Reading direkt an ein schon existierendes Device hängt?
Gruß,
Thorsten
Meine Hilfeerfahrung im Forum ist einfach so: Wenn 1+2=3 ist und der User fragt: Was muss ich tun, um von 1 auf 3 zu kommen,
dann kommt nicht etwa: 1+2=3, sondern entweder:
- "beschäftige Dich mal bitte mit Addition"
- "Du musst eine weitere Zahl addieren"
- "steht in der Commandref" (dass es unter "Addition" steht, wird meist verschwiegen)
- "wozu brauchts Du die 3?"
- ... usw.
Vor allem ist ärgerlich, dass FHEM bei weitem nicht 100% funktioniert und das, wenn man einen Fehler findet, erst einmal davon ausgegangen wird,
dass man ja dummie ist und die Wahrscheinlichkeit selbst den Fehler verursacht zu haben, ja viel größer ist, als das den "Entwicklern" ein Denkfehler unterlaufen sein könnte.
Aber man ist ja auf Hilfe angewiesen und versucht halt alles irgendwie zu deuten, was man hingeschmissen bekommt, weil das besser ist, als gar nix.
Eh ich kapiert habe, was mit "Tütchen" gemeint war und nach Wochen dann erfahren habe dass damit die " gemeint sind... naja...
Nichts für ungut. Nur ein Denkanstoß. Ich zähle mich auch zu den dummies aber ich glaube wir sind weger faul noch dumm, sondern einfach nur leichtgläubig genug gewesen, dass FHEM eine "logische" Anwendung ist und wir damit klar kommen könnten ;)
Trotzdem vielen Dank für jede Hilfe, die man uns Dummies zu Teil werden lässt ;)
Apropos...
schau mal meine Frage zum Thema dummy an: https://forum.fhem.de/index.php/topic,69857.0.html
Keiner kann mir sagen, warum das $EVENT, welches nach commandref auch den rgb-Wert enthalten sollte, dies nicht tut....
Zitat von: NeuFehm am 31 März 2017, 17:21:48
Meine Hilfeerfahrung im Forum ist einfach so: Wenn 1+2=3 ist und der User fragt: Was muss ich tun, um von 1 auf 3 zu kommen,...
Könntest Du mal sagen, auf welchen Beitrag in diesem Thread Du Dich beziehst? Insbesondere da Du etwas sagen wir mal "anklagend" formulierst, wäre es nett, wenn man das wüsste.
Gruß,
Thorsten
Hallo Thorsten Pferdekaemper,
klinke mich mal hier ein auch wenn ich mich damit unbeliebt mache.
Für meinen Teil würde mein Beitrag vom 29.03.2017 Icon Lampe Status grau behalten bei klick im Bereich Anfängerfragen als Beispiel schon mal passen.
Sehe aber dies nicht so verbissen ist eben alles auf freiwilliger Basis und das Leben geht weiter.
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 31 März 2017, 19:16:28
Für meinen Teil würde mein Beitrag vom 29.03.2017 Icon Lampe Status grau behalten bei klick im Bereich Anfängerfragen als Beispiel schon mal passen.
Zu was passen? Meinst Du damit, dass sich in diesem Thread hier jemand beschwert, weil in einem anderen Thread nicht richtig geholfen wurde? ...und das dann noch ganz ohne Hinweis darauf, auf was es sich bezieht? Wie soll man denn da erraten, was eigentlich gemeint ist?
Gruß,
Thorsten
Hallo Thorsten Pferdekaemper,
für mein Verständnis war dies eine allgemeine Aussage für den gesamten Forumsbereich also mindestens mehrmals zutreffend.
Da ich selber nicht in allen Bereichen gepostet habe würde ich mich selber nicht so weit aus dem Fenster lehnen und dies für allgemeingültig Erklären.
Obwohl ich beim vielen Lesen hier in mehreren Bereichen, mich auch so dieses Gefühl manchmal beschleicht vorsichtig ausgedrückt.
Du hattest nach einem Beispiel gefragt, so mag meine Antwort natürlich unterschiedlich im Auge des Betrachters liegen.
Gruß
Hans-Jürgen
Dummy benötigt man um Parameter übers FHEMWEB einzustellen.
Beispiel: Wecker mit einstellbarer Weckzeit
Der Wecker
defmod wecker at *10:25 {Log 1, "geweckt"}
Die Benachrichtigung des Weckers, dass seine Weckzeit geändert wird.
defmod modwecker notify du1:WZ.* set wecker modifyTimeSpec [du1:WZ]
Die einstellbare Weckzeit (WZ) als Reading im Dummy fürs Frontend
defmod du1 dummy
attr du1 readingList WZ
attr du1 setList WZ:time
attr du1 webCmd WZ
setstate du1 initialized
setstate du1 2017-03-31 20:05:13 state initialized
setstate du1 2017-03-31 20:18:54 WZ 08:25
Ich wüsste nicht, wie man das ohne Dummy lösen könnte, wenn man at und notify zur Lösung bevorzugt.
Mit DOIF ginge es ohne Dummy, das nur am Rande.
Zitat von: Deckoffizier am 31 März 2017, 19:44:32Du hattest nach einem Beispiel gefragt,
Nein, das hatte ich nicht. Ich hatte gefragt, auf welchen Beitrag in diesem Thread sich das bezieht, da ich davon ausgehe, dass wenn jemand einen Beitrag in einen Thread schreibt, dass sich dieser dann auch auf irgend etwas bezieht, was in dem Thread vorkam. Insbesondere hätte mich interessiert, warum das gerade als Antwort auf meinen Beitrag erscheint. Ich glaube nämlich, dass so ziemlich keiner der "Anklagepunkte" auf mich zutrifft.
Gruß,
Thorsten
Zitat von: NeuFehm am 31 März 2017, 17:27:03
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.)
Zitat
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
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
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
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
Zitat von: Beta-User am 31 März 2017, 21:13:33
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 )
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:35Die 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
atDas 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.
@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
Zitat von: Prof. Dr. Peter Henning am 02 April 2017, 09:51:01
@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:
Zitat von: Thorsten Pferdekaemper
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.
Zitat
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.
Zitat
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
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
Zitat von: ralfix am 02 April 2017, 14:41:02
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?
Zitat von: ralfix am 02 April 2017, 14:41:02
Was sollte daran schlecht sein?
Gruß Ralf
Die Anzahl der Module ;) Ich würde es mit einem machen.
Hat der Einsatz vieler dummies einen Einfluss auf die Performance?
Gibt es sonst irgendeinen anderen negativen Effekt?
Schöne Grüße
Jo
Zitat von: Jojo11 am 02 April 2017, 17:50:21
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..."
Zitat von: igami am 02 April 2017, 14:51:51
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
Ja es reicht auch ein Dummy. :)
Zitat von: Thorsten Pferdekaemper am 31 März 2017, 18:28:44
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 ...
::)
Zitat von: Benni am 08 April 2017, 11:36:43
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,
Also wenn das wirklich jemand so missversteht, dann fühlt er sich wohl zu Recht angesprochen...
Das will ich irgendwie nicht wirklich glauben.
Gruß,
Thorsten
Zitat von: igami am 31 März 2017, 05:56:23
Wie in der commandref beschrieben ;)
Also weil das hier stellenweise (nur stellenweise!!) so emotional war und ich an eine vergleichbaren Problem hänge, will ich mal vorurteilsfrei beschreiben, was einen hier in den Wahnsinn treiben kann. Bitte bis zum Ende lesen, bevor jemand antwortet, ich habe auch eine mögliche Lösung.
Ich lese also in der commandref
ZitatSpace separated list of name:modifier pairs, to override the widget for a set/get/attribute specified by the module author. Following is the list of known modifiers:
OK, irgendwas mit Leerzeichen. Jedes einzelne Element wird mit Doppelpunkt getrennt. Was genau ist dann "name"? Ein "set/get/attribut". Was ein Attribut ist, weiß ich dummy inzwischen. Aber ein set ist doch ein Befehl? Ich überschreibe dann den Befehl des Modulautors, würde ich jetzt vermuten.
Dann kommt eine Beispielliste, in der es schon losgeht: Da fehlen die Worte vor dem Doppelpunkt. Ist das zulässig oder nicht? Wäre es nicht sinnvoll, "name" drin stehen zu lassen? Wieso fehlt weiter unter colorpicker komplett der Doppelpunkt? Danach kommt "To the icon.* widgets listed below applies:" und da würde ich denken, das betrifft jetzt nur Icons. Statt dessen erscheint auf einmal "uzsuToggle,state1,state2 - dispay a toggle button with two possible states. the first is the active state" aus dem nichts, kein dummy weiß an dieser Stelle, was auf einmal "uzsu" hier macht (ich hielt das zuerst für einen Schreibfehler).
Wenn man weiß, wie es geht, ist das kinderleicht. Wenn man echter dummy ist, kann man verzweifeln.
Meine Lösung, die ich schon mal propagiert habe: Bitte, versucht Wiki-Einträge zu machen und zu pflegen. Bei dem von colorpicker habe ich nun versucht, mein Wissen ordentlich einzutragen (auch bei anderen mache ich das, wenn ich Zeit habe). Nur kapiere ich es immer noch nicht vollständig.
Wichtig erscheint mir zudem folgendes. Erklärungen sollten nicht alles in einen Mammut-Satz packen, sondern mehrere kleine Teilsätze enthalten. Konkretes Beispiel: "Beim jedem Seitenaufbau wird der Wert zum Initialisieren des colorpicker aus dem Reading mit dem gleichen Namen wie das set-kommando geholt". Das versteht man als dummy auch beim dritten Lesen nicht. Geschieht das nur beim Initialisieren des Gerätes? Des Seitenaufbaus? Welches set-Kommando, wird denn das beim Seitenaufbau aufgerufen? Fragen über Fragen eines dummies am Sonntagnachmittag...
deine änderungen an den beiden wiki seiten sind leider inhaltlich nur zum teil richtig und sie schmeissen setList, widgetOverride, set kommando und webcmd ducheinander.
was du oben als mamutsatz bemängelst ist weder besonders lang noch besonders komplex. einfach langsam von links nach rechts lesen. es ist übrigens nirgendwo von 'initialisierung des geräts' die rede. und natürlich geht es um das jenige set kommando für das der colorpicker eingesetzt wird.
es ist schade wenn du mit der vorhandenen doku nicht klar kommst, mit unvollständigem halbwissen noch mehr unklarheiten hineinzubringen ist aber leider auch nicht hilfreich. wenn du dir vorgenommen hast die doku zu verbessern finde ich das klasse. aber bitte erst wenn du die zusammenhänge so weit verstanden hast das es hinterher richtiger und nicht falscher wird.
Zitat von: andies am 08 Oktober 2017, 14:11:38
Meine Lösung, die ich schon mal propagiert habe: Bitte, versucht Wiki-Einträge zu machen und zu pflegen. Bei dem von colorpicker habe ich nun versucht, mein Wissen ordentlich einzutragen (auch bei anderen mache ich das, wenn ich Zeit habe). Nur kapiere ich es immer noch nicht vollständig.
Wichtig erscheint mir zudem folgendes. Erklärungen sollten nicht alles in einen Mammut-Satz packen, sondern mehrere kleine Teilsätze enthalten. Konkretes Beispiel: "Beim jedem Seitenaufbau wird der Wert zum Initialisieren des colorpicker aus dem Reading mit dem gleichen Namen wie das set-kommando geholt". Das versteht man als dummy auch beim dritten Lesen nicht. Geschieht das nur beim Initialisieren des Gerätes? Des Seitenaufbaus? Welches set-Kommando, wird denn das beim Seitenaufbau aufgerufen? Fragen über Fragen eines dummies am Sonntagnachmittag...
Wiki-Einträge sind sicher gut, allerdings wäre es natürlich noch besser, wenn die commandref selbst noch besser wird. Mit konstruktiven und konkreten Vorschlägen für commandref-Verbesserungen haben die Modulautoren sicher kein Problem (ich gehe mal einfach von mir aus), denn als Experte für ein Thema (und das ist der Modulautor vermutlich) ist es nicht unbedingt einfach Sachen verständlich zu beschreiben.
Obwohl mir der Bezug zu dummy-Devices hier nicht ganz klar ist. Dazu noch eine Anmerkung:
Manchmal sind dummy-Devices aus meiner Sicht eine gute Möglichkeit um Dinge zu realisieren, aber wie so häufig in der Software ist auch das häufig eine Geschmacksfrage und darüber kann man ja trefflich streiten ;)
Schreibt man solche Vorschläge zur commandref besser direkt dem Autor (sogar PM?) oder diskutiert man das eher im Forum?
Gesendet von iPad mit Tapatalk Pro
@andies: Ich würde normalerwewise einen Thread mit dem Vorschlag im Forum für das entsprechende Modul eröffnen und erst später den Autor per PM anschreiben, wenn es übersehen wird.
Zitat von: viegener am 08 Oktober 2017, 19:20:57
Obwohl mir der Bezug zu dummy-Devices hier nicht ganz klar ist. Dazu noch eine Anmerkung:
Tja, anscheinend wird hier mal wieder der Begriff Dummy nicht richtig verstanden.
Manch einer meint wohl hier geht's um "FHEM für Dummies (https://de.wikipedia.org/wiki/F%C3%BCr_Dummies)".
Aber wie du auch schon richtig bemerkt hast, ging es hier ursprünglich mal um die gehäufte Verwendung von Dummy-Devices (http://commandref.fhem.de/commandref_DE.html#dummy)
Vielleicht sollte man diesen Thread einfach mal schließen.
Sehe ich auch so und jetzt ist er zu :)