Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[justme1968]

für die panstamp devices mache ich es so das pro device model ein eigenes fhem modul geben kann das automatisch nachgeladen wird sobald sich so ein device das erste mal meldet und per define/autocreate angelegt wird. zwischen dem generischen swap modul und den spezialisierten gibt es eine art mini api mit dem das spezielle modul initialize und define des generischen verwenden und teilweise überschreiben kann sowie sich in die set, get und parse funktionen eingängen und diese erweitern kann.

ich weiß nicht wie viel davon auf hm passt (da die swap register definition eh zur laufzeit aus einem XML file gelesen wird) aber vor allem das automatische nachladen sobald das device auftaucht würde ich für wichtig erachten. ein neustart fände ich unschön.

gruss
  andre

[Dirk]

- User können sich eigenen Devices bauen (siehe Panstamp Projekte) und müssen diese einlagern

Ich habe bisher keinen gangbaren Weg gefunden incl. dem Erweitern der Modellist und Subtypelist.
Daher dieser Vorschlag.

? Ist die Filestruktur so ok? Ein File für ein neues Device?
? Soll das File eingecheckt werden oder wird es dem User "geliefert", falls er sein eigenes Device baut/kopiert?
? Sollte dies in ein Unterverzeichnis abgelegt werden?

Das könnte man noch mal besprechen.
Prinzipiell ist die Idee weitreichend.
Man kann allgemeine Devices-Devinitionen mit FHEM ausliefern. Ggf. im Contrib-Verzeichniss oder auch selber erstellen und manuell verteilen sofern es nur um eine Handvoll Devices geht

? welche Daten werden im File enthalten sein?
  - registerdefinition
  - register usage
  - Kommando usage
  - Kommando - definition (noch nicht implementiert)
  - parser-routinen

Auch das könnten wir noch definieren und ggf. später ausbauen.

Im Prinzip müsste sich auch alles in 99_myUtil einbauen lassen.

Die Modellist und die Subtypelist konnte ich hier nicht erweitern, so dass sie auch zur Verfügung steht wenn CUL_HM initialisiert wird.

für die panstamp devices mache ich es so das pro device model ein eigenes fhem modul geben kann das automatisch nachgeladen wird sobald sich so ein device das erste mal meldet und per define/autocreate angelegt wird.

Das währ für HM auch eine Idee. Allerdings wohl mit recht viel Umbau verbunden.

Gruß
Dirk

[betateilchen]

Ein extra Neustart ist nicht notwendig.

Da die Erweiterungen per Update kommen und nach einem Update ohnehin ein Neustart notwendig wird, stehen danach auch die Erweiterungen zur Verfügung. Und seien wir mal realistisch: es werden nicht jeden Tag zehn neue Devices hinzukommen.

Und es ist eine Lösung, die auch ohne autocreate funktioniert.

[justme1968]

ein neustart ist nur notwendig wenn ein bereits existierendes modul ein update bekommt. wenn ein neues modul per update kommt ist eigentlich kein neustadt nötig.

selbst wenn nicht jeden tag zehn neue devices dazu kommen kann ich dir versichern der entwickler der auch nur ein einziges neues device baut wird sehr sehr dankbar sein wenn es mit so wenig neustarts wie nur möglich geht. da ist ein einfaches neu laden mit der erweiterungen und der device definition wirklich ist da wirklich sehr hilfreich.

autocreate ist keine pflicht und da hm autocreate sowieso nicht bzw. nur zum teil verwendet hier auch nicht so wichtig.

[betateilchen]

nochmal: es ist überhaupt nie ein Neustart notwendig.

[martinp876]

ein neustart/restart ist notwendig, wenn man Konfigdaten ändet (HMConfig). Die werden zumindest in Teilen nur einmal beim Booten bearbeitet - aus Performancegründen.

Für Funktionen trifft dies nicht zu, die (meisten) werden bei den Aktionen ausgeführt.
Im Prinzip ist Panstamp nichts anders - daher wäre ein einheitliches Vorgehen schön.

Der User kann in diesen Datenstrukturen alles zerschießen, genau wie ihr, da das Nachladen alles Überschreiben darf (so ist FHEM eben). Bei Panstamp werden die Daten geladen, wenn ein entsprechendes Device erstellt wird - das ist nicht so schlecht. In eurem Fall bekommt jeder die Erweiterungen zu dem Eigenbau mit. Und wenn es weitere Devices gibt, auch die.
Falls ihr bei diesem Konzept bleiben wollt solltet ihr strikt auf die Regeln achten. Es betrifft alle HM User (im Gegensatz zu Panstamp).

Wenn ihr ein File je eigenbau-HM-device machen wollt schlage ich vor, dass es all-inclusiv ist, also alles beinhaltet, was dieses Device benötigt.

[betateilchen]

ein neustart/restart ist notwendig, wenn man Konfigdaten ändet (HMConfig).

Bitte definiere "neustart/restart" aus Deiner Sicht, bevor wir wieder tagelang aneinander vorbeireden.

[Dirk]

Falls ihr bei diesem Konzept bleiben wollt solltet ihr strikt auf die Regeln achten. Es betrifft alle HM User (im Gegensatz zu Panstamp).

Nicht wenn die entsprechenden Files über Contrib ausgeliefert werden.
Dann muss jeder der es nutzen will erst altiv werden.

Dennoch finde ich die Methode die Panstamp verwendet interessant.
Allerdings währ es ganz gut wenn wir kurzfristig eine Lösung finden.
Man kann es ja später ggf. Umbauen.

[hexenmeister]

Contrib wäre insoweit unschön, dass keine
automatischen updates stattfinden.

[betateilchen]

Ich erkenne gerade das Problem nicht, um das es hier überhaupt geht.

[martinp876]

hm - seltsame Frage. Restart ist, wenn alle Init Prozeduren ausgeführt werden und alle internen Daten gelöscht werden. FHEM macht das bei boot, shutdown restart und auch bei rereadCfg.

HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.

Ein Problem sehe ich, wenn zum einbinden eines selbstbau-device ein File in .FHEM eingecheckt werden muss. Der aktuell gebaute Sensor sit sicher ein besonderer... dennoch ein Selbstbau. Ggf - im Falle von Konflikten  - muss sich der Selbstbau dem HM-Konzept unterordnen.
Ich sehe somit zu wenig Flexibilität für User.

Mit einem Schnellschuss der jetzt gerade passt baut man sich Historie auf, die bei einem breit verteilten System auf Dauer Probleme macht. Die meisten scheinen das hier zu verstehen und zu beachten. Die (wenigen) anderen sehen nie Probleme.

Ich habe es erst einmal eingebaut.

[Prof. Dr. Peter Henning]

Betreffend die Kalibrierung der Heligkeitssensoren:

Das Problem liegt etwas tiefer, als hier vermutet - haben wir schon mal an anderer Stelle diskutiert. Denn die Sensoren sind typischerweise auch im Infraroten empfindlich, ein Blatt Papier hingegen hat im Infrarotbereich ein ganz andere Transmission, als im sichtbaren Bereich.

Die Frage ist also: Was soll gemessen werden ?

- Die solare Einstrahlung auf Flächen bestimmter Neigung ? Das ist sinnvoll für PV-Anlagen, mache ich bei mir auch.
- Die Globalstrahlung ?
- Die empfundene Helligkeit ? Die wird aber z.B. nicht in Lux gemessen, sondern in Lumen

LG

pah

[Dirk]

Denn die Sensoren sind typischerweise auch im Infraroten empfindlich, ein Blatt Papier hingegen hat im Infrarotbereich ein ganz andere Transmission, als im sichtbaren Bereich.

Der Sensor hat sowohl einen Kanal für IR+Visible und einen Kanal für IR.
Mit einer Formel laut Datenblatt werden die gemessenen Werte direkt in Lux umgewandelt.
Da muss auch nix mehr kalibriert werden.

Bei direkter Sonneneinstrahlung übersteuert der Sensor aber.
Daher muss für diesen Anwendungsfall dann ein Filter davor.

Gruß
Dirk

[Prof. Dr. Peter Henning]

Einspruch.

Lux sind Lumen pro Quadratmeter, und das Lumen ist eindeutig auf das menschliche Auge bezogen.

Eine Infrarothelligkeit in Lux anzugeben ist also prinzipiell unsinnig - es sei denn, man legt ein ganz bestimmtes Spektrum zu Grunde und benutzt den IR-Einfall, um die sichtbare Helligkeit abzuschätzen.

Das geht zwar bei direktem Sonnenlicht, das ein thermisches Spektrum bei ca. 5.500 K aufweist. Aber spätestens bei bedecktem Himmel ist das nur noch sehr vage gegeben.

LG

pah

[Dirk]

Lux sind Lumen pro Quadratmeter, und das Lumen ist eindeutig auf das menschliche Auge bezogen.

Hat doch auch keiner was anderes behauptet.

Eine Infrarothelligkeit in Lux anzugeben ist also prinzipiell unsinnig

Der Sensor benutzt seine IR-Photodiode lediglich um die Helligkeit entsprechend dem menschlichen Sehvermögen zu berechnen.

Magst du mal in das Datenblatt schauen?
http://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/TSL256x.pdf

Gruß
Dirk

Update:
Mein gekauftes Helligkeitsmessgerät welches die Helligkeit übrigens auch in Lux angibt misst so ziemlich die selben Werte wie der Sensor.
Daher gehe ich davon aus, dass die Messung stimmt.