Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

jjf

Zitat von: justme1968 am 01 März 2014, 14:11:33
allerdings kann man darüber streiten ob ein temperatur und fechte sensor der alle paar sekunden sendet wirklich zuverlässiger wird wenn das ganze bidirektional ist oder nur unnötig der funk raum mit acks gefüllt wird.
gruss
  andre

Meine Erfahrung: drahtgebundene Sensoren sind sehr zuverlässig.
Deshalb gefällt mir ja die Platine gut:
Rx und Tx sind noch frei: -> RS485 oder 1W wäre möglich,
falls man die Verkabelung realisieren kann.

Gruss,
Joachim

justme1968

wenn kabel liegen würde ich nichts anderes verwenden.

wobei mich bei 1wire das pollen stört und ich das nicht  mehr über das haupt fhem system mache würde wenn die anzahl der sensoren zweistellig wird.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

jjf

Zitat von: justme1968 am 01 März 2014, 14:56:50
wenn kabel liegen würde ich nichts anderes verwenden.

wobei mich bei 1wire das pollen stört und ich das nicht  mehr über das haupt fhem system mache würde wenn die anzahl der sensoren zweistellig wird.

Ich habe 15 Temperatursensoren DS18B20 am Avr-Net-IO. Mehr sind geplant.
Zur Info: hier die aktuelle Messungen von heute.
https://dl.dropboxusercontent.com/u/18713924/SVG_BoilerTemperatur.svg
https://dl.dropboxusercontent.com/u/18713924/SVG_BoilerAnschluesseTemperatur.svg
Als Perl-Übung habe ich gerade die im Warmwasserspeicher befindliche Wärmemenge
berechnet und in eine dummy-Variable geschrieben.

An die fleissigen: weitermachen, das Interface kann man später auch noch anders gestalten.

Joachim

hexenmeister

TME hat mich mit der Schnelligkeit überrascht. Gestern bestellt, heute hat Post die Gehäusen gebracht. Sind IMHO echt brauchbar  :)

hexenmeister


Dirk

Zitat von: trilu am 01 März 2014, 13:18:41
Du hast die Pins vom SHT mit auf den I2C Bus gepackt, das hatte ich in meinem Prototyp nicht,
sollte aber theoretisch gehen.
Wie hattest du den SHT10 aktuell angeschlossen?

Zitat von: jjf am 01 März 2014, 14:36:10
Wir in Hessen haben bald (oder schon) Rauchmelderpflicht.
Luftgüte, Wasseralarm fällt mir spontan ein.
Luftgüte finde ich auch interessant.
Hast du hier einen bestimten Sensor im Sinn?
Über die Steckleisten kann man die geplante Platine recht gut erweitern. Da sollte auch ein Wassersensor machbar sein.

Zitat von: jjf am 01 März 2014, 14:40:15
Rx und Tx sind noch frei: -> RS485 oder 1W wäre möglich,
falls man die Verkabelung realisieren kann.
Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Der Vorteil zu 1Wire, HM-Wired muss man nicht pollen.

Gruß
Dirk

jjf

Zitat von: hexenmeister am 01 März 2014, 20:47:18
Zum Thema MAX1724:
Kennt jemand noch bessere Quelle?

Nein. Eine Alternative wäre TPS61097.
Aber auch nicht preiswerter.

Joachim

trilu

@Dirk
laut Datenblatt ist der SHT10 kein wirkliches I2C Device. Das Protokoll ist ähnlich, aber das Ding hat keine Adresse.
Ich wollte möglichst Fehler ausschliessen und bin ja auch etwas faul, deshalb hatte ich ihn an  Pin A0 (data) und Pin A1 (clock)
angeschlossen...
Falls du weiterhin freie Pins hast, wäre das die bevorzugte Alternative. Ansonsten bin ich mir aber fast sicher, das wir
den Sensor auch über A4 und A5 ans laufen bekommen.

Viele Grüße
Horst

Dirk

Zitat von: trilu am 01 März 2014, 21:25:30
laut Datenblatt ist der SHT10 kein wirkliches I2C Device. Das Protokoll ist ähnlich, aber das Ding hat keine Adresse.
Achso, ja das hatte ich fast vergessen, weil ich mich hierauf verlassen hatte:
Zitat"however, the sensor can be connected to an I2C bus without interference with other devices connected to the bus. The controller must switch between the protocols."

ZitatFalls du weiterhin freie Pins hast, wäre das die bevorzugte Alternative.
Ok, dann schaue ich mal ob ich da was machen kann. Die Ports sind kein Problem. Langsam wird es aber voll auf der Platine :)

trilu

Genau das war der Satz den ich auch gelesen hatte.  Wir könnens ja testen  ;D

frank

danke für die einschätzungen.

ZitatMomentan ist der 328 schon ziemlich voll mit den Temperatur/Luftfeuchte/Luftdruck Modul. 86% Flash sind dicht.
Ich versuche das ganze Zeug auch noch ein wenig zu optimieren, aber unter 70% werden wir nicht kommen.
ZitatAllerdings ist einen Thermostat zu basteln eine ganz andere Nummer als ein paar Sensorwerte zu übertragen.
In einem Thermostat müssen Regelfunktionen und solche Sachen, da wird kaufen vermutlich einfacher :-)
ZitatFalls du mit deinem "Thermostat" aber nur eine Solltemperatur setzen möchtest, z.B. per Incrementalgeber, FHEM dann aber die Regelung vornimmt, könnte das noch rein passen.

da ich die regler in den "echten" thermostaten nicht verwenden kann, um mein heizungssystem umzusetzen, benötige ich eigentlich nur einen sollwertgeber und eine temperaturmessstelle. der regler wird in fhem durch pid20 realisiert, der dann über ein virtuelles hm-cc-tc das ventil hm-cc-vd steuert. ausserdem sind meine hm-cc-tc thermostate nicht einmal in der lage "nur" den sollwert verlässlich bereit zu stellen.

aus euren antworten entnehme ich: wenn ich ein reduziertes sensormodul (firmware -> T/H) verwenden würde, sollte ich auf alle fälle den sollwertgeber und eventuell noch ein display integrieren können. dann werde ich mich demnächst wohl mal mit der asksin library beschäftigen und versuchen ein io-modul zu integrieren. eventuell dieses: http://www.aliexpress.com/item/Free-Shipping-1602-LCD-Keypad-Shield-Duemilanove-UNO-MEGA2560-MEGA1280-in-stock/701995021.html

daher sieht meine wunschvorbestellung wie folgt aus (oder vergleichbare ausführungen):

1x indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T/H,druck,licht)
5x indoor-T/H (gehäuse,batteriehalter,platine,atmega,max,T/H)

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Dirk

Hi Horst,

Ich hab mir das noch mal angesehen.
Ich könnte dem SHT10 für den Sensor1 eigene Pins spendieren.
Beim zweiten Layout habe ich aber nur den I2C-Bus zusätzlich nach außen geführt. Da sollte ein optional angeschlossener SHT10 über die I2C-Pins laufen. Daher, lass uns den SHT10 am I2C-Bus lassen. Dann kann man die Sensoren alle einheitlich verbauen.
Die Änderungen an deiner Lib sollten doch nicht so umfangreich ausfallen?

Kannst du deinen Prototypen dahin entsprechend umbauen und testen ob das so einfach funktioniert bevor ich die Platinen in Auftrag gebe?

Gruß
Dirk

hexenmeister

@Dirk
Ich habe mir das Schema bezüglich Spannungsmessung mit MAX1724 angesehen. Mit den angegebenen Widerständen beträgt die Stromstärke maximal 1,5V/570k=2,63µA=0,00263mA. Wenn die Batterie ca. 1000mAh hat, dann reicht sie bei diesem Verbrauch für ca. 380000 Stunden. Das sind zwar nur etwa 43 Jahre ;) Aber lohnt es sich dabei überhaupt einen Pin zum Abschalten dieser Schaltung zu spendieren? Wenn ja, warum dann nicht auch einige Sensoren zwischendurch abzutrennen?
Oder habe ich mir verrechnet?

Dirk

Hi hexenmeister,

Deine Rechnung stimmt so etwa. Ich hab mit 3,3V gerechnet und komme da auf ~5,8µA.
In Zusammenhang mit dem MAX ist das recht wenig, da die Batterie ziemlich gut ausgenutzt wird.
Ein Paar µA für die Sensoren, AVR, CC1101 kommen auch noch dazu. Und periodisch aufwachen muss der AVR auch noch. Somit bekommen wir hier bestimmt keine 44 Jahre hin. Über 2-4 Jahre sollten das aber dennoch werden.

Für die Version ohne MAX sieht es etwas anders aus, da der Lichtsensor Laut Datenblatt min. 2,7 V möchte.
Bei der Reihenschaltung von 2 Zellen a 1,5V liegt die Spannung hier schon recht früh unter den 2,7V. Laut Entladekurve, die ich ein paar Beiträge weiter vorne gepostet hatte, kann man den AA-Zellen bis dahin ca. 500 mAh entnehmen. Knapp 1/5tel der Nennkapazität.
Daher wollte ich so viel es geht an Energie sparen. Aber auch hier sollte man eine Betriebszeit von 1-2 Jahren erreichen können.

Zitatwarum dann nicht auch einige Sensoren zwischendurch abzutrennen?
Den Helligkeitssensor könnte man abklemmen, dann muss man diesen aber auch pollen. Ansonsten kann der, entsprechend mit Schwellwerten programmiert, eigenständig Events an den AVR senden.

Hier mal eine Liste der Standbyverbräuche bei 3,3V
SHT10: ca. 0,6 µA.
TLS2561: ca. 3,2 µA
BMP180: ca. 0,1 µA
CC1101: ca. 0,5 µA
Atmega32: ca 0,1 µA

In Summe sind das nur etwa 4,5 µA für alles zusammen.
Mit dem abgeschalteten Spannungsteiler sparen wir also über 50% Energie in der Standby-Zeit.

Ich wollte den Pin für das Enablen des Spannungsteilers aber noch verlegen.
Eine andere Idee währ noch, dass sich Spannungsteiler und Config-Taster einen Pin teilen.
Während der Spannungsmessung muss der Pin für ein paar ms auf Output-Low konfiguriert werden. Ansonsten ist er auf Input-High konfiguriert.
Was haltet ihr davon? Spart einen Pin und trotzdem Energie.

Gruß
Dirk

marc2

Moin !

Zitat von: Dirk am 01 März 2014, 21:08:55
Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Der Vorteil zu 1Wire, HM-Wired muss man nicht pollen.

Na dann freue ich mich jetzt schon auf RS485 Version  :)

Gruß, Marc