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

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 833
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: 4001
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: 4001
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: 833
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: 4001
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: 833
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: 4001
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: 67
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: 4001
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: 67
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: 4001
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: 2440
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: 3143
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: 5204
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: 67
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

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #15 am: 18 September 2018, 11:16:55 »
Danke für die Rückmeldungen.

Eigentlich war ich vom Bauchgefühl her auch geneigt, hier sehr viel offensiver "setreading" und die Nutzung von (eigenen) Readings im Allgemeinen zu erwähnen. Neulich hat mich aber die Aussage eines (m.E. erfahrenen) Developers etwas irritiert, er "schreibe nicht gern in fremden Devices rum" (als Reaktion auf den Vorschlag, bestimmte Infos einfach in Readings beim betroffenen (Aktor-) Device zu speichern).

Wie dem auch sei, @alanblack hat dahingehend recht, dass es sinnvoller wäre, die ganzen Themen rund um Readings (und internals? je) in einen eigenen Artikel zu packen. Es darf sich gerne jemand berufen fühlen, das zu übernehmen.

Für den Attribut-Artikel sollte es bei einem Minimal-Inhalt bleiben (ohne Erwähnung irgendwelcher spezieller Module; das mit Dummy war nur als Hinweis zu verstehen, dass an der Stelle der Sachverhalt eigentlich etwas verkürzt wird).

Habe jetzt mal folgendes im Wiki stehen:

Abgrenzung zu Readings
Als Readings werden demgegenüber Daten bezeichnet, die von einem Gerät gelesen und in FHEM in einer (üblicherweise) lesbaren 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.
Auch hier kann der Nutzer über die Kommandozeile (Fußnote: Durch Anpassung der Attribute "setList" und "readingList" können Änderungen auch über FHEMWEB-Elemente ermöglicht werden) direkt Einfluß auf den aktuellen Wert nehmen und Events erzeugen. Es sollte dabei jedoch sichergestellt werden, dass es nicht zu unbeabsichtigten Überschneidungen mit Änderungen der Readingsinhalte kommt, die vom entsprechenden Modulcode geschrieben werden.

Der Vorteil der Nutzung von Readings liegt darin, dass die Änderung der Daten nicht zu Änderungen an der [[Konfiguration]] führen, diese aber dennoch bei einem ordnungsgemäßen Neustart von FHEM direkt wieder verfügbar sind.



Es wäre vermutlich für "Einsteiger mit Programmiererfahrung (?)" sehr hilfreich, wenn jemand eine Art "best-practice-Beispiel" mal im Wiki darstellen könnte.
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 Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3143
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #16 am: 18 September 2018, 13:02:56 »
Zitat
, der sog. statefile
statt dessen z.B. "dem Statefile oder der Konfigurationsdatenbank. Die Speicherung kann automatisch oder manuell erfolgen, siehe [[autosave]], [[save]] oder [[WriteStatefile]]."

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #17 am: 18 September 2018, 13:24:06 »
statt dessen z.B. "dem Statefile oder der Konfigurationsdatenbank. Die Speicherung kann automatisch oder manuell erfolgen, siehe [[autosave]], [[save]] oder [[WriteStatefile]]."
Danke, hab's übernommen; das erzeugt allerdings wieder drei "desired"-Pages, von denen ich mal annehme, dass du die zeitnah anlegen wolltest (oder die Links auf passende bestehende Doku umbiegen) ;) .

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: 67
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #18 am: 18 September 2018, 14:31:37 »
statt dessen z.B. "dem Statefile oder der Konfigurationsdatenbank.[...]"
War das jetzt Pawlow? Jetzt heißt der Satz:
Zitat von: https://wiki.fhem.de/wiki/Attribut
Readings werden nicht in der [[Konfiguration]] gespeichert, sondern in einer eigenen Datei, der sog. statefile oder der Konfigurationsdatenbank.
Damit wird aus dem Unterschied Konfiguration <-> statefile auch ein Unterschied Konfiguration <-> Konfigurationsdatenbank; was aber AFAIK nicht korrekt wäre. Der Satz könnte (und IMHO sollte) inhaltlich korrigiert im Artikel "Reading" verschwinden.
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: 4001
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #19 am: 18 September 2018, 14:46:50 »
Das ist m.E. der (zutreffende) Hinweis auf configDB (in der wird noch deutlich mehr gespeichert, z.B. auch holiday-files usw.). Ob in der configDB dann noch ein eigenes "File" drin ist? K.a., interessiert auch nicht weiter ;) .

Muß aber zugeben, dass ich dahingehend betriebsblind bin und das vermutlich für die Mehrzahl der FHEM-User (zwischenzeitlich kann ich sagen leider) ein völlig unbekanntes Schlagwort ist und zur völligen Verwirrung führen kann. Sollte man vermutlich klarstellen.

(Pers. Anmerkung: Auch wenn es sinnvoll ist, an der Stelle an Worten zu feilen, sollte irgendwann auch mal gut sein. Wie man sieht, tragen manchmal Präzisierungen nicht zur Klärung bei, sondern bewirken das Gegenteil; hier sollte nach meinem Geschmack ein Atom noch eine Kugel sein, für "besseres Wissen" ist an anderer Stelle noch Raum ;) .)

Bin insgesamt geneigt, den Ausgangszustand mehr oder weniger wieder herzustellen ("sog. statefile") und dann nur in eine Fußnote weitere Info zu packen. Für den Normaluser reicht es zu wissen, dass die Readings-Daten in der statefile (bei ordnungsgemäßer Beendigung von FHEM) "neustartsicher" aufgehoben sind.

Just my2ct, und Danke für die Diskussion.
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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #20 am: 18 September 2018, 15:52:02 »
...erledigt wie vorhin angekündigt. Wer jetzt noch was zu bemängeln hat, darf gerne selber Hand anlegen, es ist ein Wiki...

[...]ist das mit dem „in für Menschen verständlicher Form“ schwierig zu vermitteln. [...]
Das war wie dargestellt ein Zitat. Da es nur bedingt zutreffend ist, könnte man evtl. in der Development-API-Intro den Teil auch etwas verbessern, ggf. ergänzt um Hinweise zur Namensgebung "fremdgesteuerter" Readings.

Das sollte aber bitte jemand machen, der da vertieftere Einblicke hat und "auf Stand" ist ::) .
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: 67
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #21 am: 18 September 2018, 17:08:22 »
Wie dem auch sei, @alanblack hat dahingehend recht, dass es sinnvoller wäre, die ganzen Themen rund um Readings (und internals? je) in einen eigenen Artikel zu packen. Es darf sich gerne jemand berufen fühlen, das zu übernehmen.
Ich fühle mich zwar nicht berufen, habe aber mal angefangen. https://wiki.fhem.de/wiki/Reading
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: 4001
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #22 am: 18 September 2018, 23:13:54 »
Ich fühle mich zwar nicht berufen, habe aber mal angefangen. https://wiki.fhem.de/wiki/Reading
...du machst ja ganz schön Druck >:( :( ;D ::) ...

EDIT: ich bin im Ton leider etwas zu hart gewesen, aber m.E. bedarf der Artikel einer Überarbeitung.

DANKE für den Impuls trotzdem ;) .

@alanblack: Vielleicht magst du mal in einen richtigen Modulcode sehen von irgendwas (2-stufigem), das du einsetzt und da mal nachsehen, wann da aus welchem Grund welche Readings angelegt werden und wann die dann ggf. in FHEMWEB zu sehen sind. Dann mach dasselbe nochmal für einen weiteren Modulcode von jemandem anderen. Schließlich: bring' das in eine Form, die "Otto Normaluser" als Addressat derartiger Wikieinträge (?) versteht... (wie definieren wir den?!?).

BAOH............
(Aber eigentlich ist es gaaaanz einfach, oder?)
« Letzte Änderung: 19 September 2018, 12:30:38 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 alanblack

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute
« Antwort #23 am: 19 September 2018, 07:48:42 »
...du machst ja ganz schön Druck >:( :( ;D ::) ...
Wenn Du den Druck wieder herausnehmen willst... irgendwer hat ein paar Postings früher geschrieben: "(Zitat: "Mehr Mut beim Löschen...")"   :P

Zitat
@alanblack: Vielleicht magst du mal in einen richtigen Modulcode sehen von irgendwas (2-stufigem), das du einsetzt und da mal nachsehen, wann da aus welchem Grund welche Readings angelegt werden und wann die dann ggf. in FHEMWEB zu sehen sind. Dann mach dasselbe nochmal für einen weiteren Modulcode von jemandem anderen. Schließlich: bring' das in eine Form, die "Otto Normaluser" als Addressat derartiger Wikieinträge (?) versteht... (wie definieren wir den?!?).
Ich habe es bisher weitgehend vermieden, in die Modulcodes zu schauen, auch wenn es mich ab und zu reizt. Aber das ist eine Sache, die mir einfach zu viel Zeit abverlangen würde, die ich derzeit dafür nicht habe bzw. erübrigen möchte.
Ich werde mal kurz
[OT]
Aber wer ist denn der "Otto Normaluser"? - der Leser dieses Wiki?
Ich denke, dass wir mindestens vier verschiedene Gruppen definieren können, die mit FHEM in Kontakt stehen:
1. Reine Benutzer: schaltet Licht an und aus, reagiert auf Meldungen, nutzt vielleicht noch etwas wie FTUI... wie bspw. meine Frau: was sie nicht nutzt, baue ich wieder aus; unnötige Systemlast und Fehlerquelle
Diese finden hier (*.fhem.de) AFAIK keinerlei Informationen, die ihnen helfen, wenn der "Haus-Administrator" nicht greifbar ist. Sollten wir vielleicht mal ändern?
2. Benutzer mit technischem Verständnis: steckt Komponenten zusammen, kopiert Beispiele und passt diese auf eigene Bedürfnisse an
Diese Gruppe ist hier sicherlich oft mindestens als Leser vertreten, wird aber mit HOWTOs etc. noch IMHO nicht ausreichend versorgt.
3. Benutzer mit Programmierkenntnissen: versteht technische Zusammenhänge, ändert vorhandene und schreibt eigene Routinen
Ich tippe, dass dies die meisten Leser und Schreiber hier sind.
4. Programmierer und Entwickler: sind in der Lage, eigene Module zu schreiben
Diese IMHO relativ wenigen, sind die Gruppe, die den gewichtigsten Beitrag hier liefern, aber auf Grund Ihrer technischen Vorkenntnisse am wenigsten Doku brauchen; da reichen durchaus spärliche Kommentare im Quellcode aus.

Die Frage, die sich jetzt stellt, ist: wer schreibt welchen Artikel für wen?
FHEM 5.8 auf raspi2 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433

 

decade-submarginal