Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[TheUnicornXXL]

@kadettilac89

Um die CMDs in einer vernünftigen Zeit abzuarbeiten (hatte keine Muße zum Warten ) muss ich trotzdem auf die Taste des Sensors drücken.

[kadettilac89]

@kadettilac89
Laut Eintrag im Github wurde Lacy-Config anscheinend bei der aktuellen Version der pm Datei nachgerüstet.

funktioniert nicht. In Version history nicht enthalten, nur Test am 5. März 15.

Darum wie beschrieben Config Button nutzen ... "https://forum.fhem.de/index.php/topic,20620.msg423759.html#msg423759

[Linef]

Eine Ergänzung in der pm-Datei reicht nicht - die Firmware muss das auch unterstützen - tut sie aber derzeit nicht.
Musste ich selber ergänzen (Handling von HAVE_DATA Messages und WKMEUP-Flags in der AskSin Lib) - dann geht's.

Martin

[Dirk]

Hi Martin,

(Handling von HAVE_DATA Messages und WKMEUP-Flags in der AskSin Lib)

Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.

Gruß
Dirk

[papa]

Hi Martin,
Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.

Gruß
Dirk

Mir bitte auch ... Danke

[Dirk]

Hi Gernot,

Ließe sich mit dem Universalsensor eine Spannungsmessung z.B. an einem 12 V Akku realisieren.

Hardwareseitig ist das das kleinere Problem. Im einfachsten Fall ein Spannungsteiler mit ein paar Widerständen an einen der freien AD-Eingänge des Sensors.
In der Firmware muss mann den Eingang dann "nur noch" abfragen und im einfachsten Fall den RAW-Wert Senden und in FEHM umrechnen.
Provisorisch gebaut, sollte das kein so großer "Akt" sein. Wenn es noch ein paar Tage Zeit hat, könnte ich dir da eine experimentelle FW für bauen.

Gruß
Dirk

[Dirk]

Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.

Ok, ich kann natürlich auch in dein Repo schauen

[Linef]

Hallo Dirk,

die Anpassungen hatte ich auf Basis der NewAskSin gemacht, da ich mit der "alten" Version bei meinem Sensor-Projekt nicht mehr starten wollte.
Die Version v1.3 in meinem Git-Repo läuft derzeit am stabilsten.

Am besten, Du hältst nach dem String WKMEUP Ausschau - das Flag habe ich an verschiedenen Stellen eingebaut, um der Zentrale zu signalisieren, daß das Device für Config-Daten empfangsbereit ist. Im Gegenzug muß aber auch die AS_MESSAGE_HAVE_DATA Message bearbeitet werden, um zu bestätigen, daß man empfangsbereit ist.

Grundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten. Dann sendet die Zentrale die in der Queue liegenden Datenpakete.
D.h. aber auch, daß nach jedem Senden von Daten das Device mind. 1/2 Sek. auf eine eventuelle HAVE_DATA-Message der Zentrale warten muß.

Martin

[Gernott]

Wenn es noch ein paar Tage Zeit hat, könnte ich dir da eine experimentelle FW für bauen.

Hallo Dirk

Da würde ich mich sehr darüber freuen. Es ist nicht eilig. - Ich habe die Hardware auf dem Steckbrett zusammen, mir die IDE mal installiert, aber bisher null Erfahrung mit der Firmwareerstellung. Will es aber trotzdem mal lernen. Dann hätte ich schon mal etwas lauffähiges als Backup.

Gruß
G.

[kadettilac89]

Hi Dirk und Martin,

was spricht dagegen wenn ihr beide Projekte in eines vereint? Ich habe einen Sensor auf Basis der ... ich nenne es mal ... linef-Implementierung und später habe ich basierend auf der Dirk-Version einen gebaut weil ich zu faul war den Luftdruck-Part in den von linef einzubauen  (für den BME280).

Im Prinzip laufen alle Sensoren bei mir stabil mit geringem Stromverbrauch. Dirk, deiner hat das Include "Sensor_THP*" welches in der "measure"-Methode von Linef einfach gerufen werden könnte oder halt direkt im loop selbst. Zusätzlich noch den Bootloaderteil übernommen und es sollte fast schon laufen. Martin, du verwendest halt Atmel Studio, das könnte für manche Nachahmer eine Hürde darstellen. Ich habe es aber auch geschaff ... Anleitung ist ja in deinem GitHub-Projekt enthalten.

Ich würde das begrüßen weil ich dann meine quick-n-dirty Firmware gegen die von euch tauschen könnte ... Spass beiseite aber ich werde demnächst noch weitere Sensoren bauen, dann könnte ich es ggf. auch mit anderen Sensoren testen. Will SHT31 und nochmal BME280 bauen.

Martin, du hast eine Abwandlung der newAsksin, vielleicht noch mit trilu sprechen und eine neue newAsksin bauen dann wäre auch deine AES-Erweiterung im "Standard".

[Dirk]

Hallo Martin,

Am besten, Du hältst nach dem String WKMEUP Ausschau - das Flag habe ich an verschiedenen Stellen eingebaut, um der Zentrale zu signalisieren, daß das Device für Config-Daten empfangsbereit ist. Im Gegenzug muß aber auch die AS_MESSAGE_HAVE_DATA Message bearbeitet werden, um zu bestätigen, daß man empfangsbereit ist.

Danke schaue ich mir an.

Grundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten.

Das hatte ich eigentlich gemacht. Hin und wieder funktionierte das auch. Aber nicht stabil.

was spricht dagegen wenn ihr beide Projekte in eines vereint? Ich habe einen Sensor auf Basis der ... ich nenne es mal ... linef-Implementierung und später habe ich basierend auf der Dirk-Version einen gebaut weil ich zu faul war den Luftdruck-Part in den von linef einzubauen  (für den BME280).

Dieses Projekt werde ich mal angehen. Den Upgrade auf die neue Asksin-Version hatte ich ja schon länger geplant. Leider hat es an der nötigen Freizeit gefehlt. Martin war da schneller.
Freut mich aber. So werde ich mit Martin seiner Version mal den Upgrade starten.

Martin, du verwendest halt Atmel Studio, das könnte für manche Nachahmer eine Hürde darstellen. Ich habe es aber auch geschaff ... Anleitung ist ja in deinem GitHub-Projekt enthalten.

Ich versuche mal das Ganze sio zu modifizieren, dass das auch in der Arduino-IDE Kompiliert.
Ich selber nutze aktuell Eclipse mit dem Arduino-Plugin.

Will SHT31 und nochmal BME280 bauen.

Den BME280 und SHT21 oder ähnlich hatte ich schon mal im Auge für eine neue Platine (Vielleicht ein Universalsensor V2 oder so. Mal sehen.)

vielleicht noch mit trilu sprechen und eine neue newAsksin bauen dann wäre auch deine AES-Erweiterung im "Standard".

AES hatte ich "damals" im DEV-AES-Branch gepusht. Und ich meine das ist auch aktuell die Hauptentwicklungsbranch an der Trilu, Martin, und ich demnächst hoffentlich auch wieder weiter entwickeln. Daher kannst du die schon benutzen.
Es funktionieren dort ggf. noch nicht alle Beispiele.

Gruß
Dirk

[Linef]

Von mir aus gerne - Allerdings werden die Versionen immer leicht unterschiedlich sein, da ich andere Sensoren drauf habe und ich optional bei mir noch den 32KHz Quartz nutze.
Dirk hat schon angefragt, da er ja schon lange auf die NewAskSin-Lib gehen wollte. Und bei mir fehlt noch der Teil für die Bootloader-Unterstützung...

Mit trilu bin ich ständig in Kontakt - er entwickelt derzeit die NewAskSin-Lib komplett um, so daß das Zeug mit distillRegs nicht mehr notwendig ist.  Mein Sensor läuft bereits mit dieser neuen NewAskSin, allerdings funktioniert Peering noch nicht (Pairing schon).

Vielleicht kann Dirk auf meiner Variante aufsetzen und seine Sensoren dazu bauen?
Änderungen können wir ja dann gegenseitig dank Git übernehmen. Ich werde weiterhin am Code von trilu dran bleiben, so daß dann sogar die ganz neue Lib mit einfließen könnte... ??

Die AES-Erweiterung ist nicht von mir (ich glaube, kam von Dirk?) - im Git ist derzeit der DevAES-Branch der aktuelle Entwicklungszweig - hat halt noch nicht in den Master-Branch zurückgefunden... Trilu hat aber AES jetzt in der neuen Lib mit drin und auch schon getestet.

Martin

[kadettilac89]

Den BME280 und SHT21 oder ähnlich hatte ich schon mal im Auge für eine neue Platine (Vielleicht ein Universalsensor V2 oder so. Mal sehen.)

Der BME280 würde sich anbieten da er alle 3 Werte liefern könnte. 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. Zumindest liest man das so in Foren. Vielleicht gibt auch der Linearregler Wärme ab die den Wert verfälscht ... keine Ahnung. Hab für Temp. einen DS18B20 drauf was ich eigentlich nicht wollte.

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

Schon das Gerüst ist hilfreich, wenn jemand andere Sensoren verwendet musss man nur die Lib tauschen und etwas anpassen.

Die Frequenz kann per #ifdef elegant ein- bzw. ausgeschaltet werden. Oder hast du sowieso schon drin. Ich nutze 8mhz (mini pro) und der läuft nun seit mehr als einem halben Jahr.

[papa]

Hallo Martin,

Grundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten. Dann sendet die Zentrale die in der Queue liegenden Datenpakete.
D.h. aber auch, daß nach jedem Senden von Daten das Device mind. 1/2 Sek. auf eine eventuelle HAVE_DATA-Message der Zentrale warten muß.

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

[Linef]

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

So was ist nicht zu unterschätzen!
Nicht umsonst sind die Sensoren oftmals thermisch auf der Platine entkoppelt (komplette Fräsung um den Sensor herum - bis auf die Leitungszuführung).
Ich hab's bei meinen Sensoren gemerkt - da ist der DS18B20 ca. 2 cm vom Atmel entfernt.
Wenn der Atmel im vollen Power-Modus läuft, dann misst der Sensor 1,5-2 Grad mehr, als wenn der Atmel die überwiegende Zeit im Powersave ist...

Martin