Autor Thema: Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute  (Gelesen 1129 mal)

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 839
Habe das auch auf der Diskussionsseite von "Attribut" hinterlassen. Frage mich, ob die Weiterleitung schlau ist? Was, wenn ein einfacher User nach "Attribut" sucht? Ist dann fast ein bisschen viel Information.
Wär's nicht besser, eine eigene Seite "Attribut" zu haben, auf der erklärt wird, was ein Attribut ist. So wie bei Device/Gerät?

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #1 am: 18 Juni 2018, 11:56:12 »
+1 für eine eigene Seite dazu (oder den Link in ein "Normaluser-freundliches" Dokument)
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #2 am: 19 Juni 2018, 11:54:46 »
...neuen Artikel erstellt...https://wiki.fhem.de/wiki/Attribut
Bitte Diskussion dazu hier...
« Letzte Änderung: 19 Juni 2018, 11:57:00 von Beta-User »
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 839
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #3 am: 19 Juni 2018, 13:49:32 »
Zitat
Damit der Nutzer das Verhalten einer einzelnen Gerätedefinition zur Laufzeit individuell anpassen kann, gibt es in FHEM für jede Definition sogenannte Attribute.
Diese stehen dann dem Modul unmittelbar zur Verfügung um das Verhalten während der Ausführung zu beeinflussen.

Ist der zweite Satz nicht eigentlich überflüssig?

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #4 am: 19 Juni 2018, 13:58:34 »
...so ist das, wenn man sich bei großen Vorbildern bedient...

Habe den 2. Satz jetzt einfach gelöscht (Zitat: "Mehr Mut beim Löschen...") ;D

Aber bei der Gelegenheit: "zur Laufzeit" ist immer noch sehr technisch. Wäre hier nicht "beim Start und während des laufenden Betriebs" besser?
Und statt "Definition" "Gerät" (mit internem Link)?
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 839
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #5 am: 19 Juni 2018, 14:21:14 »
"zur Laufzeit" finde ich schon ok. Sollte jeder verstehen.

Zitat
Mit Hilfe dieses Moduls können auch den End-Anwendern auf einfache Weise vielfältige Einstellmöglichkeiten für zur Verfügung gestellt werden.

Abgesehen von dem Fehler, der mir erst jetzt auffällt: Ich glaube, End-Anwender ist im Falle von FHEM genauer zu spezifizieren ;)

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #6 am: 19 Juni 2018, 14:31:25 »
Abgesehen von dem Fehler, der mir erst jetzt auffällt: Ich glaube, End-Anwender ist im Falle von FHEM genauer zu spezifizieren ;)
...wir sollten Artikel zu User, Anwender und End-Anwender machen ::) ;D 8) :'( ....
Du hast evtl. dahingehend recht, das man das irgendwie noch aufhübschen könnte. Aber eigentlich bin ich schon froh, dass jemand diese "Nettigkeit" gesehen hat, ohne gleich darüber herzufallen ;D .
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline alanblack

  • Jr. Member
  • **
  • Beiträge: 90
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #7 am: 17 September 2018, 15:10:48 »
Zwei Gedanken dazu:
1. wenn ich es richtig im Kopf habe, sollte man darauf hinweisen, dass ein attr global userattr <attibuteListe> durchaus auch das eigene FHEM teilweise zerschießen kann, wenn man die dort evtl. schon vorhandenen User-Attribute überschreibt. D.h. man sollte die Liste nur erweitern, es sei dann, dass man genau weiß, was man tut.

2. Ich würde noch eine Abgrenzung zu Readings schreiben.
FHEM 5.8 auf raspi2 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #8 am: 17 September 2018, 15:26:25 »
Zwei Gedanken dazu:
1. wenn ich es richtig im Kopf habe, sollte man darauf hinweisen, dass ein attr global userattr <attibuteListe> durchaus auch das eigene FHEM teilweise zerschießen kann, wenn man die dort evtl. schon vorhandenen User-Attribute überschreibt. D.h. man sollte die Liste nur erweitern, es sei dann, dass man genau weiß, was man tut.
Habe den vorhandenen Text etwas erweitert und in einen Hinweis eingebettet, Danke für die Anregung.

Zitat
2. Ich würde noch eine Abgrenzung zu Readings schreiben.
Darfst gerne einen Vorschlag machen oder einen Wiki-Zugang beantragen ;) .
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline alanblack

  • Jr. Member
  • **
  • Beiträge: 90
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #9 am: 17 September 2018, 16:00:13 »
Habe den vorhandenen Text etwas erweitert und in einen Hinweis eingebettet, Danke für die Anregung.
Darfst gerne einen Vorschlag machen oder einen Wiki-Zugang beantragen ;) .
Wiki-Zugang ist schon vorhanden.   8)
Aber wenn Ihr hier so ausführlich über diese Definition diskutiert... Ich bekomme schon fast ein schlechtes Gewissen wegen der Änderungen, die ich im Wiki ohne Diskussion vorgnommen habe. ::)
Wie wäre es:

== Attribute <=> Readings ==
Vereinfacht gesagt sind die Attribute zur Eingabe in das Gerät, Readings im Gegensatz dazu eher zur Ausgabe vom Gerät gedacht. Das äußert sich insbesondere dadurch, dass zum einen Attribute in FHEMWEB geändert werden können, Readings aber nicht (durch den Befehl "setreading" schon) und zum anderen bei der Anzeige von Werten diejenigen von Readings automatisch per Longpoll aktualisiert werden hingegen diejenigen von Attributen nur beim Neuladen der Seite.
FHEM 5.8 auf raspi2 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4287
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #10 am: 17 September 2018, 16:36:49 »
Wiki-Zugang ist schon vorhanden.   8)
Aber wenn Ihr hier so ausführlich über diese Definition diskutiert... Ich bekomme schon fast ein schlechtes Gewissen wegen der Änderungen, die ich im Wiki ohne Diskussion vorgnommen habe. ::)
Na ja, hier geht es um zentrale Begrifflichkeiten, da darf man schon eine Weile länger an den Dingen feilen als anderswo...

Zitat
== Attribute <=> Readings ==
Vereinfacht gesagt sind die Attribute zur Eingabe in das Gerät, Readings im Gegensatz dazu eher zur Ausgabe vom Gerät gedacht. Das äußert sich insbesondere dadurch, dass zum einen Attribute in FHEMWEB geändert werden können, Readings aber nicht (durch den Befehl "setreading" schon) und zum anderen bei der Anzeige von Werten diejenigen von Readings automatisch per Longpoll aktualisiert werden hingegen diejenigen von Attributen nur beim Neuladen der Seite.
Hmmm, da sind m.E. ein paar Sachen drin, die tatsächlich irgendwo erwähnt werden dürften.

Das mit dem Einstellen von attr über FHEMWEB habe ich oben im Artikel ergänzt.

Vorschlag: "Abgrenzung zu Readings" als eigenen Abschnitt nach ReadingsGroup.
Zubeachten wäre aber m.E. das aus https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Readings:
Zitat
Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt. Sie geben den Status des Gerätes wieder und erzeugen Events innerhalb von FHEM auf die andere Geräte reagieren können
Auch, wenn man über manches im Detail streiten könnte (das mit dem "Erzeugen" stimmt so nicht, es ist der Modulcode, der festlegt, ob das Setzen eines Readings Events erzeugt oder nicht), sollte man das im Großen und Ganzen als Basis nehmen.
Im Ergebnis stelle ich mal folgendes zur Diskussion:

Abgrenzung zu Readings
Als Readings werden demgegenüber Daten bezeichnet, die von einem Gerät gelesen und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden. Typischerweise werden sich im laufenden Betrieb ändernde Zustände oder Meßwerte in Readings zwischengespeichert und jede Aktualisierung ist in der Regel mit einem [[Event]] verbunden. Readings werden nicht in der [[Konfiguration]] gespeichert, sondern in einem eigenen Bereich, der sog. statefile.
Zwar kann auch hier vom Nutzer über die Kommandozeile direkt Einfluß auf den aktuellen Wert genommen werden, in der Regel ist es jedoch eher zu empfehlen, dies vom entsprechenden Modulcode erledigen zu lassen.

Anmerkung: Ausgenommen von der direkten Reading-Setz-Abstinenz sind ggf. Dummy-Devices, da kann es sich anbieten, eine setList und readingList anzulegen, um zusammengehörende Informationen zwischenzuspeichern.

Meinungen?
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline JoWiemann

  • Tester
  • Hero Member
  • ****
  • Beiträge: 2459
Antw:Weiterleitung Attribut -&gt; DevelopmentModuleIntro#Attribute
« Antwort #11 am: 17 September 2018, 16:54:50 »
Hm, wenn man sich Readings vom CUL, Signalduino anschaut, dann ist das mit dem „in für Menschen verständlicher Form“ schwierig zu vermitteln. Readings sind m.E. Einfach nur Rückmeldungen von Devices. Darunter gibt es dann Klassen von Rückmeldungen die z.B physische Zustände beschreiben, aber auch z.B. Wetterereignisse, Fahrpläne usw.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3189
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #12 am: 17 September 2018, 18:37:06 »

Anmerkung: Ausgenommen von der direkten Reading-Setz-Abstinenz sind ggf. Dummy-Devices, da kann es sich anbieten, eine setList und readingList anzulegen, um zusammengehörende Informationen zwischenzuspeichern.

Meinungen?
In diesem Zusammenhang sollte auf jeden  Fall DOIF erwähnt werden. Auch dort besteht die Möglichkeit über readingList, setList, webCmd und webCmdLabel eigene Readings  (nicht zu verwechseln mit userReadings) zu verwenden, um die Logik zu parametrisieren oder Werte zu speichern.

Aber auch in anderen Time- und Eventhandlern kann der Benutzer in eigenen Readings gefahrlos Werte speichern.

Es sind oft keine Dummys notwendig.

Das Setzen von eigenen Readings sollte nicht zur Ausnahme abgestempelt werden, es ist eine gute Möglichkeit ohne Dummys Werte zu speichern.

Siehe auch: https://forum.fhem.de/index.php/topic,68310.0.html
« Letzte Änderung: 17 September 2018, 18:40:47 von Ellert »
Zustimmung Zustimmung x 1 Liste anzeigen

Offline marvin78

  • Hero Member
  • *****
  • Beiträge: 5212
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #13 am: 18 September 2018, 06:47:53 »


Das Setzen von eigenen Readings sollte nicht zur Ausnahme abgestempelt werden, es ist eine gute Möglichkeit ohne Dummys Werte zu speichern.



Genau so ist es. Ich nutze eigene Readings in fast allen Devices, damit die Readings auch logisch an der Stelle gespeichert sind, an die sie gehören. setreading ist ein FHEM Befehl und schon alleine deshalb ist es nicht als Ausnahme zu behandeln. Dummys erscheinen für den Anfänger zunächst weniger "gefährlich" aber das heißt nicht, dass Werte in dummys speichern tatsächlich die bessere Methode ist.

Offline alanblack

  • Jr. Member
  • **
  • Beiträge: 90
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #14 am: 18 September 2018, 09:45:41 »
Ääähh... diskutieren wir hier jetzt über Sinn und Zweck des Einsatzes von setreading? Oder von programmtechnische Feinheiten rund um Readings? Dann macht der Titel "Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute" nicht viel Sinn.  ;D
Leute, Ihr werdet stark OT.


Abgrenzung zu Readings
Als Readings werden demgegenüber Daten bezeichnet, die von einem Gerät gelesen und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden. Typischerweise werden sich im laufenden Betrieb ändernde Zustände oder Meßwerte in Readings zwischengespeichert und jede Aktualisierung ist in der Regel mit einem [[Event]] verbunden. Readings werden nicht in der [[Konfiguration]] gespeichert, sondern in einem eigenen Bereich, der sog. statefile.
Zwar kann auch hier vom Nutzer über die Kommandozeile direkt Einfluß auf den aktuellen Wert genommen werden, in der Regel ist es jedoch eher zu empfehlen, dies vom entsprechenden Modulcode erledigen zu lassen.

Anmerkung: Ausgenommen von der direkten Reading-Setz-Abstinenz sind ggf. Dummy-Devices, da kann es sich anbieten, eine setList und readingList anzulegen, um zusammengehörende Informationen zwischenzuspeichern.

Finde ich gut soweit. Das mit "für Menschen verständlichen Form" würde ich aber weglassen. Und deine Anmerkung müsste in ein Topic "Reading", welches IMHO genauso angelegt gehört wie Attribut hier und in Folge dessen auch ein Topic "Internal".
FHEM 5.8 auf raspi2 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433

 

decade-submarginal