Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Linef]

Hallo Martin,

geht das auch mit FHEM oder nur mit ner CCU ? Ich kriege keine HAVE_DATA Message

CCU hab ich jetzt nicht, aber ich denke, wenn dort lazy-Config mit anderen Devices funktioniert, dann kann das das nur über die HAVE_DATA Messages gehen.

Wahrscheinlich müssen beide Seiten zusammenspielen: die CCU muß wissen, daß das Device lazy-Config kann, und das Device muß in den Messages das WKMEUP-Flag setzen. Dann sollte von der Zentrale die HAVE_DATA Message kommen und das Device muß mit einem ACK darauf reagieren.

Martin

[papa]

CCU hab ich jetzt nicht, aber ich denke, wenn dort lazy-Config mit anderen Devices funktioniert, dann kann das das nur über die HAVE_DATA Messages gehen.

Wahrscheinlich müssen beide Seiten zusammenspielen: die CCU muß wissen, daß das Device lazy-Config kann, und das Device muß in den Messages das WKMEUP-Flag setzen. Dann sollte von der Zentrale die HAVE_DATA Message kommen und das Device muß mit einem ACK darauf reagieren.

Ich versuche das gerade mit nem HM-SEC-MDIR Nachbau und FHEM. Wenn ich in der Motion-Message das WKMEUP-Flag setzte, kriege ich CONFIG_START Message - aber keine HAVE_DATA. Darauf geht nen Ack raus - aber FHEM zeigt nach nach einiger Zeit ein MISSING ACK als Status an.

Code Auswählen Erweitern


Motion
<- 0D 04 A2 41 56 78 90 63 90 87 01 04 C8 40
waitAck: 01
-> 10 05 A0 01 63 90 87 56 78 90 01 05 00 00 00 00 01
<- 0A 05 80 02 56 78 90 63 90 87 00


[Linef]

Ich versuche das gerade mit nem HM-SEC-MDIR Nachbau und FHEM. Wenn ich in der Motion-Message das WKMEUP-Flag setzte, kriege ich CONFIG_START Message - aber keine HAVE_DATA. Darauf geht nen Ack raus - aber FHEM zeigt nach nach einiger Zeit ein MISSING ACK als Status an.

Ich glaube, das läßt sich nur durch Trial und Error lösen oder mitsniffen eines offiziellen eq3-Devices.

Ich habe derzeit nur Sensoren im Einsatz - auch da mußte ich etwas rumprobieren. Trilu hatte mal vorübergehend einen ACK zuviel drin (im Umfeld des Pairings) und schon lief das HAVE_DATA nicht mehr richtig.
Oder: WKMEUP-Flag im ACK der HAVE_DATA Message... gaaanz schlecht - endlose HAVE_DATA und ACKs...

Am besten den Kommunikationsverlauf beobachten, und dort, wo ein Ende der Kommunikation eintritt, obwohl noch weitere Messages in der Queue sind, dort beim letzten ACK das WKMEUP einbauen. Damit bin ich recht weit gekommen.

Martin

[Dirk]

Allerdings werden die Versionen immer leicht unterschiedlich sein, da ich andere Sensoren drauf habe und ich optional bei mir noch den 32KHz Quartz nutze.

Das ist klar. Schon auf Grund der verschiedenen Sensorbestückung.
Die Platine vom Innensensor die Pads für den Quarz sogar schon vorbereitet. Der könnte da also nachträglich och bestückt werden.

Die AES-Erweiterung ist nicht von mir (ich glaube, kam von Dirk?)

Ja. Hab ich eingabaut. Ich hab im Sensor-Fall hier aber noch keinen zusatznutzen für AES im Kopf. Ok, evtl. einen remote-Aktivierung für den Bootloader. Oder vielleicht falls man signierte Sensordaten haben möchte.

Der BME280 würde sich anbieten da er alle 3 Werte liefern könnte.

Ja, auf alle Fälle.

Leider hab ich bis jetzt noch keinen erhalten der die Temperatur richtig misst. Man erhält zwar das Geld zurück, aber nach ewigem Warten wieder Ärger ... Die Chinesen löten die zu heiß dann ist die Kalibrierung weg.

Ok, schauen wir mal ob ich das besser hinbekomme. Die Teile bekommt man ja mittlerweile auch bei den üblichen Distributoren.
Ich habe hier noch einen liegen den mir PeMue geschickt hatte. Bin da aber leider noch nicht dazu gekommen den auszubrobieren.

Vielleicht gibt auch der Linearregler Wärme ab die den Wert verfälscht ... keine Ahnung.

Bei Sensoren in Dauerbetrieb könnte ich mir das auch vorstellen. Aber bei Sensoen die nur hin und wieder mal kurz aufwachen ist das eher nicht zu befürchten. Ich habe mal ein IR-Bild vom Innensensor aufgenommen. Der SHT10 ist hier höchstens 0,1 °C wärmer. Wobei ich mir nicht sicher bin, ob das in diesem Fall eher von der Umgebung kommt. AVR und Spannungsregler sind unauffällig.

Hab für Temp. einen DS18B20 drauf was ich eigentlich nicht wollte.

Für eine Temp/Feuchte-Only-Version Würde ich alternativ vermutlich dann auf einen SHT21 zurück greifen.

[papa]

Ich glaube, das läßt sich nur durch Trial und Error lösen oder mitsniffen eines offiziellen eq3-Devices.

Oh man - ich habe das Funkmodule nach dem Ack von CONFIG_START sofort in den Idle-Modus geschickt. So kann man natürlich keine weiteren Nachrichten empfangen. Jetzt lasse ich das Funkmodule noch 10 Sekunden nach den CONFIG_START wach und schon funktioniert es.

[Linef]

Jetzt lasse ich das Funkmodule noch 10 Sekunden nach den CONFIG_START wach und schon funktioniert es.

Halbe Sekunde reicht - spart Batterie, falls drauf ankommt...

Martin

[papa]

Halbe Sekunde reicht - spart Batterie, falls drauf ankommt...

Ich denke hier kann man ruhig großzügig sein, so oft kommt das Ändern der Register ja nicht vor.
Jetzt scheint es wirklich zuverlässig zu funktionieren.

Danke

[gerassimo]

Hallo Dirk,

ich habe Interesse an Innen-/Aussensensoren. Könntest Du mir bitte eine PM schicken?

Danke, Gruß

Gerhard

[Dirk]

Hallo Gernott,

anbei mal eine experimentelle Firmware wo ein ADC-Eingang (Arduino-Pin A2) ausgelesen wird.
Die Messung bezieht sich auf die interne Referenzspannung von 1,1 V An dem Eingang brauchst du zum Messen von 12 V also mindestens einen 1/10 Spannungsteiler.
Den kann man recht einfach z.B. mit einem 10 kOhm und einem 100 kOhm aufbauen.

A2 ist auf der oberen Pinleiste der Sensorplatine der 5. Pin von Links
Gnd ist der 2. Pin von Links

Code Auswählen Erweitern


Sensor-Platine
                 +-----------o Eingang (0-12 V)
                |¯|
                | | 100 kOhm
                |_|
                 |
A2 (5)  o-------+
                |¯|
                | | 10 kOhm
                |_|
                 |                 
GND (2) o-------+-----------o GND



Hier noch das Passende User-Reading:

ExtSpannung { sprintf("%.1f", (ReadingsVal("$name", "luminosity", 0) * 12 / 9.96)) }

Da die Widerstände in der Regel eine mehr oder weniger große Tolerenz haben, kann man die gemessene Spannung im Userreading abgleichen.
Dafür den Sensor an eine bekannte Spannung anschließen ggf. ausmessen. Diesen Wert ist bei mir im Beispiel oben 12 V.
Dann den luminosity-Wert in FHEM ablesen. In meinem Beispiel oben 9.96.

Der Wert des ADC wird hier wieder im Helligkeitswert Übertragen. Der Sensor misst mit dieser Firmware also nur Temperatur / Feuchte / Luftdruck und Spannung
Die Messung und Übertragung der Spannung erfolgt in dieser experimentellen Firmware im 15 Sek.-Raster. Zum Testen ist das ganz ok, für den Dauereinsatz eher nicht.
Wenn du nicht selber Kompilieren kannst, dann baue ich dir auch noch eine Version mit einem anderen Sende-Intervall.

Und noch einen wichtigen Hinweis:
Die Spannung die hinter dem Spannungsteiler am AVR raus kommt, darf nicht größer sein als die Betriebsspannung des Sensors. Bei den meisten, bei denen der Max 1724 bestückt ist, sind das 3,3 V. Der AVR misst hier aber ohnehin nur bis 1,1 V (interne Referenz) Also werden alle Spannungen größer 1,1 V die hinter dem Spannungsteiler ankommen mit 10.23 im luminosity-Reading angezeigt. Daher den Spannungsteiler evtl. etwas größer Dimmensionieren.

Edit:
Der Code liegt im Repo in der Branch US100-ADC
https://github.com/kc-GitHub/Wettersensor/tree/US100-ADC

Die wichtigen Änderungen sind dort im Subrepo der AskSin-Lib (Firmware-Src/Libraries/AskSin)
https://github.com/kc-GitHub/AskSin/tree/US100-ADC



@gerassimo,
Du hast Post

Viele Grüße
Dirk

[frank]

hi dirk,

sollte die schaltung nicht besser so aussehen?

Code Auswählen Erweitern

Sensor-Platine
                 +-----------o Eingang (0-12 V)
                 |
                |¯|
                | | 100 kOhm
                |_|
                 |
A2 (5)  o-------+
                 |
                |¯|
                | | 10 kOhm
                |_|
                 |                 
GND (2) o-------+-----------o GND



gruss frank

[Dirk]

Verdamt, du hast recht. Danke.
Ich habs geändert.

[Gernott]

anbei mal eine experimentelle Firmware wo ein ADC-Eingang (Arduino-Pin A2) ausgelesen wird.

Hallo Dirk

Ich habe mich mal durchgekämpft und zum Schluß Deine Firmware über hmusb-OTA installiert. Leider startet der Sensor damit nicht. Am Ende des Flashvorganges fehlt das

Code Auswählen Erweitern

Device rebooted
Die LED hat weiterhin einmal lang und 2x kurz geblinkt.

Ich habe dann mal die normale Firmware v0.15 geflasht. Heureka! Da hat sich mein Arduino Nano brav als Innenraumsensor gemeldet. Also, prinzipiell geht es, nur die Spezialfirmware hängt beim Flashen.

Ergänzung:
Da ich ja keinen Universalsensor habe, habe ich einfach den Teilerausgang an A1 gehängt. Damit bekomme ich die Spannung dann schon mit der Originalfirmware gemessen. Die Stufen sind nur etwas grob aufgelöst (0.1 V roh, ~0.3 V nach Korrektur). Das wurde wohl damals zur Beruhigung der Anzeige so eingerichtet. Werde also mich mal in die Firmware hineinvertiefen und mir eine geänderte Version kompilieren. Der Nano zieht im Betrieb etwa 6 mA, kommt vermutlich von der hellen roten Betriebs-LED. Bin froh, überhaupt soweit gekommen zu sein. Vielen Dank noch einmal!

Gruß
G.

[Chris8888]

Hallo,

ich bin von meinem Pi1 auf einen Pi3 umgezogen und bin in diesem Zuge von einem CUL auf einen HM-MOD-RPI-PCB umgestiegen (plus einen HM-LAN).
Jetzt ist mir folgendes aufgefallen: Mein HB-UW-Sen-THPL-O wird zwar noch erkannt, aber die Readings werden nicht mehr ausgelesen (Timeout).
erst nachdem ich das IO-Device auf mein HM-Lan umgestellt habe werden auch die Readings wieder ausgelesen.

Kann das jemand bestätigen? Gibt es da eine Lösung zu?

VG
Christian

[hastrobe]

Hallo Dirk,

ich habe Interesse an Innen- und Aussensensoren.
Kannst Du mir bitte eine PM schicken?
Besten Dank.

Heiko

[Gernott]

Edit:
Der Code liegt im Repo in der Branch US100-ADC
https://github.com/kc-GitHub/Wettersensor/tree/US100-ADC

Hallo Dirk
Habe Deinen Code nach einigen Versuchen zum Laufen bekommen. Mir war aber aufgefallen, daß die Spannungswerte doch ziemlich streuen. Der Teilerausgang war stabil. Also habe ich mal den Aref oszillografiert. Da gibt es nach dem Einschalten eine ziemliche Spitze und es dauert bei meinem Nano etwa 1 bis 1.2 ms bis die Referenz stabil ist. Also habe ich den Start der Messung um 2 ms verzögert. Mit dieser Variante scheint mir nun das Resultat deutlich stabiler. Soweit ich gesehen habe, besteht das Problem mit Deiner Batteriemessung gegen die interne Referenz auch. Hier mal der geänderte Code aus der Sensor_SHT10_BMP085_TSL2561.cpp:

Code Auswählen Erweitern

uint32_t SHT10_BMP085_TSL2561::adcMeasuer() {
uint16_t adcValue = 0;
ADMUX = ((1 << REFS1) | (1 << REFS0) | ADC_PIN); // Voltage Reference = Internal 1.1V Voltage Reference
ADCSRA = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0); // Set ADC prescaler
ADCSRA |= (1 << ADEN); // Enable ADC
_delay_ms(2); //**Wait until internal reference voltage is stable
ADCSRA |= (1<<ADSC);                  //**Dummy measurement
while (ADCSRA & (1<<ADSC) ) {          //**Wait for completion
}

(void) ADC; //**Read once

for(int i = 0; i < ADC_NUM_MESS; i++) {
ADCSRA |= (1 << ADSC); // start conversion
while (ADCSRA & (1 << ADSC)) {} // wait for conversion complete
adcValue += ADC; //**ADC is the same as ADCW
}

ADCSRA &= ~(1 << ADEN); // ADC disable
adcValue = adcValue / ADC_NUM_MESS;

return adcValue;

}

Viele Grüße
G.