Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Thorsten Pferdekaemper]

Ich habe je die noch immer eingebauten Sleeps in Verdacht.

Soll ich dir mal eine Firmwareversion schicken wo das Auslesen des Helligkeitssensors abgeschaltet ist, oder kannst du das mal testen?

Das einfachste fuer mich waere natuerlich, wenn Du mir die Firmware-Version schickst. Ich muesste es aber auch hinbekommen, wenn Du mir sagst, wo das entsprechende Coding zu finden ist. Das kann aber ein paar Tage dauern.

Vom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen,  kann aber sein das man den Nächsten nehmen muss.  Eigentlich macht das keinen grossen Unterschied.  Nur wenn der Messagezähler auf 0 ist,  dann ist der aktuelle ja 255 und dann macht es eine Unterschied...

Das klingt ja so, als ob es meistens funktionieren muesste, nur eben alle 256 Messages oder so mal nicht. Das ist aber nicht der Fall. Es funktioniert meistens nicht richtig. Aber ich denke mal, wir sollten auch hier sicher stellen, dass es moeglichst immer klappt. Koennest Du mir dazu auch einen Tipp geben, wo das entsprechende Coding ist?

[Henno]

Hi

Auch auf die Gefahr hin das ich gleich ausgebuht werde,

kann man noch Platinen bestellen?

Ich habe jetzt mal die ersten 6 Seiten überflogen.
Soweit sieht das ganze ja schon mal sehr gut aus!

Wieweit sind die Platinen bestückt?

Ich hätte gerne sofern möglich zwei Sensoren mit Licht und Luftdruck.
Temperatur muss nicht sein.

Was kostet der Spaß?

[frank]

Vom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen,  kann aber sein das man den Nächsten nehmen muss.  Eigentlich macht das keinen grossen Unterschied.  Nur wenn der Messagezähler auf 0 ist,  dann ist der aktuelle ja 255 und dann macht es eine Unterschied...

bei vd/tc, ist ja wohl das gleiche schema, funktioniert es so:

aus der aktuellen msg-nummer wird das nächste meeting berechnet. auch wenn ein meeting nicht erfolgreich war, werden die zähler incrementiert, um das darauf folgende meeting zu berechnen. auch wenn die msg-nummer "nur" um 1 daneben liegt, können durch die berechnung einige sekunden differenz daraus resultieren. ausserdem werden die abstände mit steigender msg-nummer auch manchmal kürzer. also treffen sie sich nur noch durch zufall. darum schläft der vd nach 6 missglückten meetings auch für eine stunde ein. danach wird er aber solange wach, bis wieder ein meeting erfolgreich ist. sollte der tc sich nicht mehr melden, ist die batterie bald leer.
um die trefferquote zu erhöhen vergrössert der vd nach jedem erfolglosen meeting sein wachfenster, und synchronisiert sich bei erneutem meeting. auch bei regelmässig erfolgreichen meetings scheint er sich manchmal neu zu synchronisieren, wenn das meeting wohl gerade noch geklappt hat.

gruss frank

[Dirk]

Das einfachste fuer mich waere natuerlich, wenn Du mir die Firmware-Version schickst.

Ich bau dir die Tage mal was zusammen.

kann man noch Platinen bestellen?

Ja, es wird aber noch etwas dauern.
Es gab bei mir ein paar Verzögerungen.

Wieweit sind die Platinen bestückt?

Von komplett leer bis voll bestückt. Je nach dem was du möchtest.

Ich hätte gerne sofern möglich zwei Sensoren mit Licht und Luftdruck.

Innen oder Außenversion?

Was kostet der Spaß?

Grob überschlagen, je nach Bestückungsvariante / Ausstattung vermutlich um die 20-35€

Gruß
Dirk

[Thorsten Pferdekaemper]

Ich bau dir die Tage mal was zusammen.

Danke. Koenntest Du mir auch einen Tipp geben, wo im Coding Du etwas geaendert hast (bzw. geaendert haben wirst)? Wenn ich sowieso dran rumschraube, dann kann ich's vielleicht gleich reparieren.
Gruss,
    Thorsten

[trilu]

ich mache das in der sensor class

Code Auswählen Erweitern

void MyClassName::poll_transmit(void) {
if (tTiming) nTime = millis() + tTiming; // there is a given timing
else nTime = millis() + (calcSendSlot() * 250) - measureTime; // calculate the next send slot by multiplying with 250ms to get the time in millis

nAction = 'm'; // next time we want to measure again
// transmit code
hm->sendPeerWEATHER(regCnl,tTemp,tHum,tPres); // send out the weather event
}
uint32_t MyClassName::calcSendSlot(void) {
uint32_t result = (((hm->getHMID() << 8) | hm->getMsgCnt()) * 1103515245 + 12345) >> 16;
return (result & 0xFF) + 480;
}

[Dirk]

Hi Trilu,

ich mache das in der sensor class

ich hatte die Firmware ja schon etwas weiter entwickelt. Daher wird das so nicht ganz passen.
Wenn du wieder Zeit hast, könnten wie die Codestände vielleicht mal zusamen mergen.

@Thorsten
in Sensor_SHT10_BMP085_TSL2561.cpp wird die Helligkeit so eingelesen:

Code Auswählen Erweitern

tLux = tsl2561->readBrightness(data0, data1) * 100;
Diese Zeile einfach auskommentieren.

Die Funktion readBrightness ist in TSL2561.cpp
Dort findes du auch die Delay's.

Ich werde das die Tage mal umbauen, so dass hier keine vor allem langen Delay's mehr gebraucht werden.

Anbei auch das Kompilierte Hex-File.

Gruß
Dirk

[Thorsten Pferdekaemper]

ich hatte die Firmware ja schon etwas weiter entwickelt. Daher wird das so nicht ganz passen.

Hast Du auch den AskSin-Teil geändert? Ich hatte mir das vom AskSin-Thread geholt und es schien zu passen. Falls Du auch was an den AskSin-Sourcen geändert hast, könntest Du mir die schicken?
Gruß,
Thorsten

[Dirk]

Ich hatte mir das vom AskSin-Thread geholt und es schien zu passen.

Das würde mich wundern.
Ich hatte an der Lib einige Optimierungen vorgenommen und das Wichtigste, die Timerbehandlung geändert, so das dadurch der Bug mit dem Zyklischen hängenbleiben des Sensors gefixt wurde.

Daher hatte ich die Lib geforkt und im Wettersensor-Repo als Subrepo eingebunden:
https://github.com/kc-GitHub/AskSin

Gruß
Dirk

[Thorsten Pferdekaemper]

Das würde mich wundern.
Ich hatte an der Lib einige Optimierungen vorgenommen und das Wichtigste, die Timerbehandlung geändert, so das dadurch der Bug mit dem Zyklischen hängenbleiben des Sensors gefixt wurde.

Ich habe auch ehrlich gesagt nicht ausprobiert, ob es wirklich laeuft. Das Kompilieren hat geklappt und das Ergebnis hatte exact dieselbe Groesse.
Na, dann werde ich das vielleicht mal mit Deinem Fork ausprobieren.

[xequtor]

ich hab hier paar Arduino mini pro 3.3V 8Mhz, CC1101 868Mhz Module (die die auch Dirk verwendet) und DHT22 Sensoren.

Ich habe bis jetzt nur mit Uno und selbst gebauten Arduinos und DHT22 ein T/H sensor gebaut aber mit Display und auch mit EtherShield aber will das ganze mit den Arduino Mini Pro und CC1101 bauen da ich schon fast ales mit HM steure.

Da ich schon alle Komponente habe muss ich nur alle verbinden und programmieren, meine Frage wäre gibts eine einfache Programmierung Beschreibung fuer nur T/H mit DHT22 ohne sonstigen Sensoren? (später mach ich vielleicht mit Lichtsensor)
Ich hab hier im Thread gesucht aber konnte keine Antwort finden.

Meine ToDo Liste:
- Arduino Mini Pro 3.3V Programmieren
- CC1101 868 mit Arduino Verbinden
- DHT22 mit  Arduino Verbinden
- Daten an FHEM schicken und freuen

[Bennemannc]

Hallo,

wenn es nur der DHT 22 sein soll - panstamp Battery Board, entsprechenden Sketch drauf, fertig.
Ich habe das als S0 Counter im Einsatz (binimp und temphumpress zusammen kopiert). Das Battery Board gibt es mit DHT22.

Gruß Christoph
PS. der Panstamp sendet SWAP, aber das ist schon in Fhem integriert.

[xequtor]

Danke Christoph, werde mir es anschauen aber ich will keine neue hardware kaufen da ich schon material fuer ca 5 Sensoren habe Arduino Mini Pro, DHT22 und CC1101 868Mhz. Bin auch interessiert an selbstbau von HM kompatiblen Sensoren (mit AskSin ?)
Eigentlich muss ich nur den existierenden Sketch umbauen (uns das ist z.Z. das Problem) und an DHT22 anpassen oder hat es schon jemand gemacht?

[Bennemannc]

Hallo,

ich habe mal gegoogelt - http://www.ebay.de/itm/DHT22-AM2302-digital-Sensor-Feuchtigkeit-Temperatur-Feuchte-Temperatur-Sensor-/290738840660
dort steht, das die Sensoren kompatibel wären, also würde ich das einfach mal probieren - oder die Datenblätter vergleichen.

Gruß Christoph

-- beim Battery-Board vom Panstamp ist ein DHT22 drauf - für den Panstamp gibt es da einen fertigen Sketch, vielleich kanst Du ja Teile davon nutzen (sensor.h und sensor.ino)

[xequtor]

Danke Christoph,

ich werde mich heute die nächste paar Tage damit auseinander setzen spricht den Arduino Mini Pro mit dem Code von Dirk und DHT22 zu laufen zu kriegen.
Nur das Problem ist reverse Engineering von dem Code von Dirk da ich es HM Protokoll kompatibel machen möchte.