Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute

Begonnen von drhirn, 18 Juni 2018, 11:50:46

Vorheriges Thema - Nächstes Thema

drhirn

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?

Beta-User

+1 für eine eigene Seite dazu (oder den Link in ein "Normaluser-freundliches" Dokument)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#2
...neuen Artikel erstellt...https://wiki.fhem.de/wiki/Attribut
Bitte Diskussion dazu hier...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

ZitatDamit 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?

Beta-User

...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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

"zur Laufzeit" finde ich schon ok. Sollte jeder verstehen.

ZitatMit 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 ;)

Beta-User

Zitat von: drhirn am 19 Juni 2018, 14:21:14
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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

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 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Zitat von: alanblack 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.
Habe den vorhandenen Text etwas erweitert und in einen Hinweis eingebettet, Danke für die Anregung.

Zitat2. Ich würde noch eine Abgrenzung zu Readings schreiben.
Darfst gerne einen Vorschlag machen oder einen Wiki-Zugang beantragen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 17 September 2018, 15:26:25
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 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Zitat von: alanblack am 17 September 2018, 16:00:13
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:
ZitatDaten, 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JoWiemann

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

Ellert

#12
Zitat von: Beta-User am 17 September 2018, 16:36:49


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

marvin78

Zitat von: Ellert am 17 September 2018, 18:37:06


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.

alanblack

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

Zitat von: Beta-User am 17 September 2018, 16:36:49


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 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons