Weiterleitung Attribut -> DevelopmentModuleIntro#Attribute

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

Vorheriges Thema - Nächstes Thema

Beta-User

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

Ellert

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]]."

Beta-User

Zitat von: Ellert am 18 September 2018, 13:02:56
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-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: Ellert am 18 September 2018, 13:02:56
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/AttributReadings 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 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

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

...erledigt wie vorhin angekündigt. Wer jetzt noch was zu bemängeln hat, darf gerne selber Hand anlegen, es ist ein Wiki...

Zitat von: JoWiemann am 17 September 2018, 16:54:50
[...]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-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 18 September 2018, 11:16:55
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 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

#22
Zitat von: alanblack am 18 September 2018, 17:08:22
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?)
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 18 September 2018, 23:13:54
...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 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