Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Dirk]

Nee, gab es noch nicht.

Das ist merkwürdig.
Eigentlich hatte das Martin schon vor ein paar Wochen eingebaut. Somit sollte es ausreichen nur die Datei "HMConfig_SenTHPL.pm" zu kopieren.

EDIT:
Beim Starten sagt er übrigens:

Code Auswählen Erweitern

Subroutine CUL_HM_ParseTHPLSensor redefined at ./FHEM/HMConfig_SenTHPL.pm line 18, <> line 96.

Hast du die Datei 2 Mal ggf. mit anderem Namen im Verzeichniss?

Ich wollte eigentlich gerade ein paar Sachen, die ich bisher herausgefunden habe, im Wiki verewigen.

Was hast du noch herausgefunden?

[Dirk]

Was mir noch aufgefallen ist: Wie sieht es denn mit einem OTA-Bootloader aus? Jan aus dem Nachbarprojekt hat da einen gebaut.

Ja, das Projekt ist mir bekannt.

Würden für den die 32k vom Atmega aus noch ausreichen oder wäre ein 64k erforderlich?

Es ist weniger der Gesamtspeicher, eher der Speicher der für den Bootloaderbereich übrig bleibt. Das ist beim Atmega328 nur 2kb und da wird es mit dem OTA-Bootloader eng.

Wenn das für dich in Frage kommt, wären das mMn 2 gut investierte Euro, um sich zukünftiges herumbasteln bei jedem Flashen zu ersparen

Keine Frage OTA ist prima. Ich denke bei nächsten Projekten werde ich das bestimmt berücksichtigen.

Viele Grüße
Dirk

[vbs]

Das ist merkwürdig.
Eigentlich hatte das Martin schon vor ein paar Wochen eingebaut. Somit sollte es ausreichen nur die Datei "HMConfig_SenTHPL.pm" zu kopieren.

Hast du die Datei 2 Mal ggf. mit anderem Namen im Verzeichniss?

Also scheinbar ist der Code, der diese Config-Files nachlädt von martin nicht in HMConfig, sondern in 10_CUL_HM eingebaut worden. Da hab ich zumindest etwas sehr ähnliches gefunden.
Da ich jetzt den Code nochmal in HMConfig eingebaut habe, hat er bei mir die Config zweimal geladen und daher die Fehlermeldung.

Was hast du noch herausgefunden?

Naja, nix was für euch nicht völlig klar ist Also wo man den Firmware-Quellcode findet. Dass es ein Arduino-Projekt ist und wie man es mit Arduino-IDE zum Kompilieren bekommt. Naja und jetzt eben, wie man den Sensor mit einem Stock-FHEM zum Laufen bekommt. Der nächste Schritt wird für mich sein, die Firmware selbst auf den AVR zu flashen und nach Möglichkeit debuggen zu können. Die Basics halt

[kaihs]

wie man es mit Arduino-IDE zum Kompilieren bekommt.

Da ich mich mit der Arduino IDE noch etwas schwer tue und ich auch nach einigem Suchen noch keine Lösung gefunden habe:

Kannst du bitte kurz zusammenfassen, was man machen muss, um den Code von https://github.com/trilu2000/AskSin mit der Arduino IDE compilieren zu können?

Nur den Sketch zu öffnen reicht nicht, weil dann die Include Files nicht gefunden werden. Noch irgendwas mit den Arduino Libraries?

Vielen Dank schon mal,

Kai

[Dirk]

Ansonsten bin ich schon sehr auf deine Testergebnisse von diesem Wochenende gespannt.

Die Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991

Somit kann ich die Tage auch wieder ein paar Sensoren Zusammenbauen.

Viele Grüße
Dirk

[Mr. P]

Die Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991

Großartig! *thumbsUp*
DAU-Frage: Spricht etwas dagegen, bei dem Board den größeren Atmega zu verbauen und sich dem OTA-Bootloader zu bedienen? Gerade bei der Häufigkeit, wie es zZ Updates zu testen gibt, will man die Sensoren schließlich nicht ständig abmontieren müssen. Und das ist jetzt noch viel interessanter geworden, da diese jetzt auch noch 1-wire können.
Ansonsten bräuchte ich letztendlich wohl 4+1 Stück (da wäre flashen OTA nicht verkehrt). Wobei natürlich die Frage ist, was die Boards letztendlich mit den einzelnen Sensoren kosten werden.

Tausend Dank an alle Beteiligten!

[vbs]

Kannst du bitte kurz zusammenfassen, was man machen muss, um den Code von https://github.com/trilu2000/AskSin mit der Arduino IDE compilieren zu können?

Nur den Sketch zu öffnen reicht nicht, weil dann die Include Files nicht gefunden werden. Noch irgendwas mit den Arduino Libraries?

Die AskSin-Library hat gar kein Sketch, oder? Zumindest sehe ich keine ino-Datei. Als ich die Firmware hier kompiliert habe, habe ich die AskSin-Lib und die anderen Abhängigkeiten von hier (https://github.com/kc-GitHub/Wettersensor/tree/master/Libraries) als Libs hinzugefügt. Kompilieren ging dann, aber es gab dann Linker-Fehler, da Asksin ihrerseits diese anderen Libs benutzen wollte, was die IDE so nicht erkannt hat (also Lib benutzt andere Libs).

Ich hab dann ganz oben in der cpp der Firmware nochmal die Header der anderen Libs eingefügt und dann hat die IDE diese Sachen auch korrekt mitkompiliert und gelinkt:

Code Auswählen Erweitern

#include <Sensirion.h>
#include <Wire.h>
#include <BMP085.h>
Von alleine kapiert das die IDE scheinbar nicht, wenn Libs ihrerseits auf andere Libs angewiesen sind. Erklärung zum Beispiel hier: http://provideyourown.com/2011/advanced-arduino-including-multiple-libraries/
Speziell der Part "Getting Your Library to Link to another Library".

[vbs]

Es gibt ja im Firmware-Ordner zwei verschiedene Firmwares für Indoor und Outdoor. Wenn ich die Firmware normal mit Arduino kompilieren, habe ich dann die Indoor oder die Outdoor? Bzw. wie kann ich einstellen, welche ich kompilieren möchte. Ich habe kein Define oder ähnliches finden können :/

[Thorsten Pferdekaemper]

Es gibt ja im Firmware-Ordner zwei verschiedene Firmwares für Indoor und Outdoor. Wenn ich die Firmware normal mit Arduino kompilieren, habe ich dann die Indoor oder die Outdoor? Bzw. wie kann ich einstellen, welche ich kompilieren möchte. Ich habe kein Define oder ähnliches finden können :/

Hi,
in der Datei Register.h steht das hier:

Code Auswählen Erweitern


const uint8_t devParam[] PROGMEM = {
0x08,                                    // The firmware version, 1 byte
0xF1, 0x01,                              // The model-ID    0xF1 0x01 = DIY (HB-UW-Sen-THPL-I)
// 0xF1, 0x02,                              // The model-ID    0xF1 0x01 = DIY (HB-UW-Sen-THPL-O)

Ich denke also normalerweise den für Indoor. Ich weiß aber nicht, ob das tatsächlich irgendwo einen Unterschied macht.

Gruß,
   Thorsten 

[Dirk]

Ich denke also normalerweise den für Indoor. Ich weiß aber nicht, ob das tatsächlich irgendwo einen Unterschied macht.

Technisch gesehen macht HB-UW-Sen-THPL-I (Indor) und HB-UW-Sen-THPL-O (Outdoor) das Selbe.
Ich habe nur 2 unterschiedliche Devicetypes vergeben, um im FHEM unterschiedliche Models zu Implementieren und für die CCU zwei unterschiedliche Devices mit auch unterschiedlichen Icons zu bekommen.

Ich hab dann ganz oben in der cpp der Firmware nochmal die Header der anderen Libs eingefügt und dann hat die IDE diese Sachen auch korrekt mitkompiliert und gelinkt

Das sollte eigentlich gar nicht nötig sein.
Ich schau mir das aber noch mal an. Ggf. gibt es da noch einen Bug

Gruß
Dirk

[vbs]

Das sollte eigentlich gar nicht nötig sein.
Ich schau mir das aber noch mal an. Ggf. gibt es da noch einen Bug

Inhaltlich ist das wirklich nicht nötig. Das scheint einfach ein "Hack" zu sein, um die Arduino-IDE dazu zu bewegen, Libraries zu linken, die nur von anderen Libraries verwendet werden (nicht aber von dem Sketch selbst). Ist vielleicht einfach eine Eigenart der Arduino-IDE?
Ohne die Zusatz-Includes hatte ich "undefined Reference"-Fehler.

Danke übrigens, konnte jetzt die Indoor-FW kompilieren, flashen und läuft sogar Jetzt will ich nur noch das ISP-Flashen bzw. DebugWire-Debuggen in Gang bekommen...

[Dirk]

Jetzt will ich nur noch das ISP-Flashen bzw. DebugWire-Debuggen in Gang bekommen...

Wenn du willst kannst du den Bootloader benutzen der in den Sourcen mit dabei ist.
Das ist der Arduino-Bootloader mit einer kleinen Modifikation dass die LED beim Flashen und beim Starten blinkt.

[vbs]

Hatte fast was vergessen: Inbetriebnahme des SHT10

Aber leider auch hier: Klappt alles auf Anhieb! Laaaaangweilig

Beschaltung rausgesucht, drangelötet, läuft! Glückwunsch & Danke an alle Beteiligten

Ich hab den Sensor zum Testen erstmal nur provisorisch angelötet. Wie habt ihr den verbunden? Per Stiftleiste? Direkt aufs Board gesteckt?
Muss da ein Loch ins Gehäuse? Ist ja wahrscheinlich sonst schwierig mit der Messung der Luftfeuchte.

PS. Bitte keine Witze über meine Lötkünste

(https://dl.dropboxusercontent.com/u/24641738/sht10.JPG)

[Dirk]

Hallo,

Aber leider auch hier: Klappt alles auf Anhieb! Laaaaangweilig

Ich werde als Option noch eine "Abenteuer-Version" mit Fehlersuche anbieten

Muss da ein Loch ins Gehäuse? Ist ja wahrscheinlich sonst schwierig mit der Messung der Luftfeuchte.

Ja, der Sensor war zum nach außen Führen geplant. Ggf. auch weiter abgesetzt vom Gehäuse.

Viele Grüße
Dirk

[vbs]

Ich werde als Option noch eine "Abenteuer-Version" mit Fehlersuche anbieten

Ja, der Sensor war zum nach außen Führen geplant. Ggf. auch weiter abgesetzt vom Gehäuse.

Warum abgesetzt? Einfach um eine bessere Messposition haben zu können oder hat das noch technisch Gründe?


Mein Ansatz wäre es erstmal, den SHT10 im normalen Gehäuse zu belassen, jedoch irgendwie eine Möglichkeit zum Luftaustausch zu schaffen. Wie wäre es mit einem Loch im Gehäuse und das dann verschließen mit zB sowas: http://www.extremtextil.de/catalog/Nylon-PU-beschichtet-atmungsaktiv-100den-80g-qm::1764.html?XTCsid=9b6595d7929f33c82ea51d6a84fdc802
Also wasserdicht, aber atmungsaktiv. Was haltet ihr davon? Schon andere Ideen?