Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[santalaus]

Hallo,

Nimm doch einfach Widerstände mit grösserem Werte in gleichem Verhältnis, dann hast Du weniger Verlust im Spannungsteiler.

z.B. 6,8k/10k

Nico

[Dirk]

Die Antwort für Tobias habe ich im Parallel Tread geschrieben:
http://forum.fhem.de/index.php/topic,20956.msg148631.html#msg148631

Gruß
Dirk

Ps. Heute sind die Platinen gekommen. Ich bin aber erst morgen wieder zu Hause. Dann kann ich am Wochenende Basteln und berichten

[trilu]

cool, ich freue mich!
dann können wir ja weiter basteln

[anhtu]

Danke für das interessante Projekt.

Ist die Sammelbestellung noch aufnahmefähig (leider habe ich erst gestern wieder ins Forum reingeschaut) ? Wenn ja, möchte ich auch gern meine Wünsche nennen:

2x indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte,druck, Helligkeit, (+ PIR))
5x indoor-T/H (gehäuse,batteriehalter,platine,atmega,max,T, Helligkeit (+PIR))

2x outdoor (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte, Helligkeit, (+ PIR))

Vielleicht später noch mehr.

Ich habe keine Ahnung von der Elektronik. Aber, das Basteln macht immer Spaß.

Gruß

anh

[Dirk]

Hallo anhtu,

Ist die Sammelbestellung noch aufnahmefähig

Ja, Wir sind erst in der Prototyp-Phase

PIR ist auf dem Bord noch nicht mit drauf.
Wenn es klappt wie geplant sollte das dann aber als Aufsteckplatine möglich sein.

Im Outdoorgehäuse wird der Temperatur/Feuchte Sensor nicht Onboard sein.
Da das Außengehäuse einen Transparenten Deckel hat, und als Helligkeitssensor im Sommer auch jede Menge Wärme einfängt, macht der Sensor hier nicht soo viel Sinn.
Dieser muss dann extern angeschlossen werden. Der I2C-Port ist über eine Steckerleiste aber nach außen geführt.

Gruß
Dirk

[anhtu]

danke. alles klar. ich warte darauf  .

[Dirk]

Hallo,

Ich konnte es gestern Nacht doch nicht lassen und habe einen ersten Sensor zusammengebaut.
Noch ohne SHT10, Also noch keine Feuchte/Temperatur, weil die Sensoren noch nicht da sind. Die sollte aber jeden Tag hier ankommen.

Der Sketch von Trilu funktioniert auch, allerdings ohne valide Daten wegen dem noch fehlenden Sensor.
Verbaut ist aber der Temperatur/Luftdruck- und der Helligkeitssensor.
Beide liefern auch schön Daten, allerdings derzeit "nur" auf dem Terminal. Die Homematic Integration fehlt hier noch.


@Trilu:
Ich baue dir am Wochenende einen Sensor zusammen und schicke ihn dir, wenn du deinen SHT10 hier auf die Platinen transplantieren möchtest.
Ansonsten müsstest du noch ein Paar Tage warten. Willst du eine Version mit Max oder ohne?

Anbei noch ein Paar Bildchen.

Gruß
Dirk

Ps.
Der Max ist bei dieser Version noch nicht bestückt.
Der kommt hier heute erst an.

Update:
Beim ausmessen der Befestigungslöcher für die Platine hatte ich mich wohl etwas vertan.
Daher sind auf der rechten Seite noch 2 neue Löcher dazugekommen. Jetzt kann man die Platine auch wieder ordentlich befestigen.

(http://hfma.de/images/FHEM/CC1101-Sensor_fertig.jpg)

(http://hfma.de/images/FHEM/CC1101-Sensor_geoeffnet.jpg)

(http://hfma.de/images/FHEM/CC1101-Sensor_platine_oben.jpg)

(http://hfma.de/images/FHEM/CC1101-Sensor_Platine_unten.jpg)

[frank]

sieht echt cool aus.

gruss frank

[mmatt]

Klasse 

[trilu]

@Dirk - Profi am Werk! Das Ding sieht klasse aus, echt Professionell!

SHT10 umlöten ist kein Thema.
Max wäre gut, weil dann könnte ich mich auch an die Spannungsmessung setzen, so dass Batterie ok/not ok variabel wird.

Wie wollen wir den Helligkeitswert übergeben?
Martin hat ja die Druckmessung/Anzeige bereits in FHEM integriert. Das passiert hier:

Code Auswählen Erweitern

  if($modules{CUL_HM}{defptr}{$src.$chn}){
    push @entities,CUL_HM_UpdtReadBulk($modules{CUL_HM}{defptr}{$src.$chn}
                                       ,1,$statemsg
                                                 ,"temperature:$t")
  }
      if ($h) {$statemsg .= " H: $h"  ; push @event, "humidity:$h"; }
      if ($ap){$statemsg .= " AP: $ap"; push @event, "airpress:$ap";}
      push @event, $statemsg;
    }


Das ganze wertet einen Weather Event aus - 2 byte temperatur, 1 byte feuchte, 2 byte druck
Hier könnte man noch 2 byte anhängen für Helligkeit. Wie gesagt, das wäre dann aber ein Weatherevent, damit kann man
keine Aktionen über Peer verknüpfen.

Die zweite Möglichkeit wäre den Sensor Event dafür zu nutzen. Das wäre aufwändiger zu implementieren, da wir einen
eigenen Kanal dafür brauchen und diverse Register ausgewertet werden müssen. Zusätzlich können wir nur ein byte als Value übergeben.
Der Vorteil wäre aber, wir könnten dann einen Dimmer ansteuern um die abnehmende Helligkeit auszugleichen...

Code Auswählen Erweitern

  "41"          => { txt => "Sensor_event", params => {
                     BUTTON   => '00,2,$val=(hex($val)&0x3F)',
                     LONG     => '00,2,$val=(hex($val)&0x40)?1:0',
                     LOWBAT   => '00,2,$val=(hex($val)&0x80)?1:0',
                     NBR      => '02,2,$val=(hex($val))',
                     VALUE    => '04,2,$val=(hex($val))',} },


Viele Grüße
Horst

[Dirk]

Max wäre gut, weil dann könnte ich mich auch an die Spannungsmessung setzen, so dass Batterie ok/not ok variabel wird.

Ich baue dir einen Max mit drauf.
Die Spannungsmessung sollte mit und ohne max über den Spannungsteiler R5 und R6 laufen können.
Alternativ könnten wir ohne Max aber die Bestückung weglassen und die Spannungsmessung über die interne Referenz machen.
Ggf. sollte beide Möglichkeiten im Code vorhanden sein.

Wie wollen wir den Helligkeitswert übergeben?

Für die Helligkeitsmessung könnten wir den ks550 nehmen. der Hat schon Frames für Helligkeit.
Allerdings keins für Luftruck.
Luftdruck hat nur die ws550.

Alternativ erstellen wir ein komplett neues Device für den "Komplett-Sensor".
Die XML-Datei, damit das ding auch an der CCU läuft könnte ich dann machen.
Das kann man als Update dann auch selber an einer CCU einspielen.

Als Frames würde ich hier Vorschlagen:
TEMPERATURE, HUMIDITY, BRIGHTNESS (siehe ks550) und AIR_PRESSURE aus ws550.

Der Helligkeitssensor hat 2 Gain-Einstellungen. "low" Faktor 1 und high (Faktor 16)
High könnte man nehmen wenn der Sensor im Innengehäuse steckt. Dann ist der empfindlicher.

Und dann könnte man sich auch überlegen was man mit dem Threshold macht und den Sensor ggf. ewents auslösen lässt, wenn die Helligkeit sich "zu schnell" ändert.
Als zusätzlicher Alarmsensor interessant.

Gruß
Dirk

[trilu]

du willst also beide varianten

Weather und Sensor Event ...

[Dirk]

Weather und Sensor Event ...

War nur eine Idee.
Aber lass uns mit den Weather-Events beginnen.
Wer die Sensor-Events noch braucht kann dann später ja updaten.
Dazu ist dann im einfachsten Fall ja nur ein USB-UART-Kabel erforderlich.

Ich habe mir gestern übrigens den Bootloader ein paar mal Zerschossen.
Man muss auf einem Frischen AVR nachdem man den Bootloader geflasht hat, die Lock Bits für den Bootloader (LPM und SPM) setzen.
Sonst kann es passieren, wenn man ein zu großes Hex-File per Bootloader flasht, dieses in den Botloaderbereich schreibt. Dann ist der Bootloader futsch. und man muss den per ISP wieder neu flashen.
Mit gesetzten Lockbits passiert das dann nicht.

Was meinst du, eigenes Device? Welche Type-ID nehmen wir dann? Vielleicht eine die das erste Byte auch nuzt? dann kommen wir mit den bestehenden nicht ins "gehege". Vielleicht irgendwas mit FExx?
Wie wollen wie das Device dann nennen? Mein Vorschlag:
CC-WDSen-THPL-I und CC-WDSen-THPL-O

Seriennummer und HM-ID würde ich beim ersten Einschalten ggf. Zufällig vergeben und ins Flash schreiben. Wer möchte kann diese Daten dann per Konsole ggf. noch ändern.

Alternativ ging auch noch 2 Virtuelle Devices in einer Hardware. Das ist aber aufwendiger, Weil die Register doppelt vorhanden sein müssten.

[trilu]

wenn wir erst mal nur den Weather Event nehmen würde ich keine Änderungen am Device Type machen.
Das müsste ja alles in FHEM, etc nachgezogen werden.
Ich würde den Helligkeitswert schlichtweg hinten an den Weatherevent anhängen und Martin bitten das mit in
CUL_HM.pm zu übernehmen.

Wenn wir dann die Helligkeit als eigenen Channel machen, dann brauchen wir einen eigenen Gerätetyp.
Dann würde ich aber auch anfangen, Temperatur und Feuchtigkeit als Sensor Wert in jeweils einem eigenen
Kanal zu übergeben.

Sensorevents hätten den Vorteil das man damit Aktoren steuern kann. Z.b. einen Lüfter schalten, wenn die
Luftfeuchtigkeit zu hoch wird. Oder mit einem Steckdosenaktor einen Radiator schalten auf Basis der Temperatur
unseres Geräts.

[Dirk]

Ich würde den Helligkeitswert schlichtweg hinten an den Weatherevent anhängen und Martin bitten das mit in
CUL_HM.pm zu übernehmen.

So hätte ich das auch gemacht. Halt als eigener Devicetyp dann Kann die CCU damit dann auch was anfangen.
Bei der WS550 ist AIR_PRESSURE lediglich ein zusätzlicher Parameter. Plane für AIR_PRESSURE aber 2 Bytes ein. Für Helligkeit würde ich auch 2 Bytes planen.
Dann kann man die vollen 16Bits vom TSL2561 übertragen.
Die Gainumschaltung machen wir dann erstmal per Console. Die muss man pro Sensortyp eigentlich auch nur einmal einstellen.

Wenn wir das so machen, dann kann ist das XML-File ja trotzdem vorbereiten.
Kannst ja Martin mal fragen wie hoch der Aufwand währ ein neues Device dafür zu definieren. Das sollte sich aber in Grenzen halten.

Wenn wir dann die Helligkeit als eigenen Channel machen, dann brauchen wir einen eigenen Gerätetyp.

Das Sowieso
Das sollte beim HM-WDS10-TH-O und den verwandten Sensoren bereits funktionieren. Zumindest haben die Im XML-File eine link_role-source vom Typ WEATHER_TH. Da sind auch Weather-Events definiert. Daher müsste man diese Sensoren auch jetzt schon mit den passenden Empfängern "verheiraten" können.