Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[betateilchen]

Gibts denn eigentlich schon eine Planung, ob/wann die vorgeschlagene Änderung zum Nachladen der Typ-Dateien in die HMConfig.pm eingebaut wird?

[Dirk]

Bisher hat Martin auch die Vorschläge hier nicht regiert bzw. hat der die wohl übersehen.
Ich werde ihn mal direkt anschreiben.

Gruß
Dirk

[Thorsten Pferdekaemper]

Hi,
vielleicht kannst Du ihn auch auf den AskSin-Thread hinweisen. Ich glaube, da sucht jemand nach einer ähnlichen Lösung.
Gruß,
    Thorsten

[PeMue]

Bei der Helligkeit kann ich nicht sagen, ob das hinkommt. Ich habe das Gehäuse geschlossen und keinen Lichtleiter oder ähnliches eingebaut.

Hallo Thorsten,

d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...

Gruß Peter

[Dirk]

d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...

Die Zahl vor Lux stimmt ohne Umrechnung nur, wenn der Sensor direkt beleuchtet wird. Also ohne Gehäuse.

[Thorsten Pferdekaemper]

d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...

Ja, das Gehäuse ist ziemlich geschlossen, da kommt ziemlich wenig Licht rein. Ich mag's auch eher hell...

[PeMue]

Hallo Dirk,

wie würde sich dann das Gehäuse des Außensensors auswirken? Ist ja transparent, aber die optische "Dämpfung" kennt man ja auch nicht? Bezüglich Kalibrierung in W/m^2 würde ich an einem strahlenden Sommertag einfach die Kurve mit den Karlsruher Messungen vergleichen und kalibrieren.
Irgendwelche berechnete Kurven habe ich (noch?) nicht gefunden.

Gruß Peter

[Dirk]

Hi PeMue,

wie würde sich dann das Gehäuse des Außensensors auswirken? Ist ja transparent, aber die optische "Dämpfung"

Um das genau zu beantworten müsste man eine Messreihe mit 2 Sensoren, mit und ohne Abdeckung machen.
Dazu bin ich noch nicht gekommen. dazu hätte ich gerne mal von morgen bis abends keine Wolken.

Bezüglich Kalibrierung in W/m^2 würde ich an einem strahlenden Sommertag einfach die Kurve mit den Karlsruher Messungen vergleichen und kalibrieren.

Oder so. dann reicht auch 1 Sensor.
Da bei voller Sonneneinstrahlung der Sensor übersteuert, muss aber ein Filter davor.
Da bin ich auch noch am experimentieren.
Gut hat sich bisher ein einfaches Blatt 80g Papier gezeigt. Ich will aber nochmal ein paar Tests mit anderen "Filtern" machen.

Gruß
Dirk

[Dirk]

Hallo,

Der Sensor läuft nun auch an der CCU mit allen Werten.
Dafür wird dann wieder ein Firmwareupdate nötig sein, da es in der 0.7er Firmware Probleme mit dem Pairing gibt.

Wenn ich es schaffe, stell ich das heute Abend rein.

Gruß
Dirk

[betateilchen]

Die Darstellung der Temperatur sieht aber "komisch" aus. Ich kann dann ja mal gegen die CCU2 testen

[Dirk]

Die Darstellung der Temperatur sieht aber "komisch" aus. Ich kann dann ja mal gegen die CCU2 testen

Ich vermute das Liegt am Raspberry der da drunter läuft.
Zum Testen auf meiner CCU1 bin ich noch nicht gekommen.

[betateilchen]

Hat sich martin eigentlich inzwischen schon geäußert? Es kommt von ihm ein Update der HMConfig nach dem anderen, aber vom Nachlademechanismus keine Spur - ich muss das jedesmal manuell nachziehen.

[Dirk]

Mist, vergessen.
Hab aber grade ne PM an Martin gesendet.

[martinp876]

Hi,

Den Vorschlag hatte ich nicht gelesen ... sorry.
Prinzipiell sicher ok - kann ich einbauen.
Vor solchen grundsätzlichen Dingen denke ich gerne noch einmal nach...
- User können sich eigenen Devices bauen (siehe Panstamp Projekte) und müssen diese einlagern
- der TH-sensor Eigenbau ist sicher etwas gewichtiger, fällt aber unter diese Kategorie

? 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?
? welche Daten werden im File enthalten sein?
  - registerdefinition
  - register usage
  - Kommando usage
  - Kommando - definition (noch nicht implementiert)
  - parser-routinen

Im Prinzip müsste sich auch alles in 99_myUtil einbauen lassen. Die Änderungen der Strukturen sollten vor dem Lesen der Attribute abgearbeitet sein - und somit rechtzeitig (habe es nicht getestet, aber sollte so sein, hoffe ich).

Also wenn ihr meint, dass es so passt und sicher seit, dass es ein Weg für alle User ist - und ihr meint dass es so stabil ist, dass man es einchecken kann/soll baue ich es ein.
Wird es code-varianten geben, die weitere Anpassungen zur Folge haben werden - und hinten nach ist alles eh User-spezifisch? Dann wäre einchecken nicht der Weg. Dann sollte man das File einfach mit dem Device ausliefern.

Ist eure Entscheidung.

Gruss Martin

[betateilchen]

Die Lösung wie wir sie hier vorgeschlagen haben, ist zumindest eine der wenigen Lösungen, die tatsächlich fhem-konform wäre. Auch was die Verzeichnis- und Datenstruktur angeht.

Ein Einbau in die 99_myUtils dürfte vermutlich viel zu spät greifen. Und das Risiko, dass die User dort etwas zerschießen, was die Funktionalität von Homematic Komponenten blockiert, ist sehr viel höher, als wenn ein Developer, dem ich durchaus das Wissen zuspreche, zu wissen was er tut, eine entsprechende HMConfig für seine Hardware eincheckt, die er mit Sicherheit auch getestet haben wird. Die Verantwortlichkeiten sehe ich dabei sehr viel klarer definiert, als wenn man die User auf die 99_myUtils losläßt.

Und die Lösung ist einfach soweit offen, dass zusätzliche Hardwaredefinitionen, deren Implementierung sich an Deine HMConfig-Konventionen hält, ohne weiteres Zutun automatisch mitgeladen werden. Ich denke schon, dass eine Verteilung auf dem regulären Update-Weg die beste Lösung sein wird.