Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Frini]

Hallo,
kann man mit diesem Außensensor auch erkennen, ob die Sonne tatsächlich scheint? Ich benötige einen Sensor zur Rolladensteuerung.
Und besteht die Möglichkeit einen Sensor komplett montiert zu bekommen?

Grüße
Matthias

[pc1246]

Moin Matthias
Also anbringen musst Du ihn schon selbst! Ansonsten ist der Sensor von Dirk komplett fertig!
Da die Werte schon recht hochaufloesend sind, kannst du selbst entscheiden, bei welchem Wert Deine rollaeden runterfahren sollen. Ich benutze zusaetzlich noch den Sonnenstand, so dass ich wieder hochfahre, wenn die Sonne nicht mehr auf diese Fenster scheint. Zudem wird das auch nur dann gemacht, wenn die Temperaturen hoch genug sind, so dass ich im Winter die Sonnenenergie zum "heizen" nutze!
Gruss Christoph

[plombe]

Hallo,
vor einigen Monaten entdeckte ich den Thread mit den Selbstbau Sensoren von Dirk und baute mir auf dieser Basis 6 Sensoren auf.
Dabei merkte ich bald, dass es beim Timing Probleme gibt.
  Wenn man die ursprünglich Software von Dirk benutzt, werden bei jeder Sendung
alle im Umkreis befindlichen HM-Geräte, die auf ein Burstsignal reagieren, geweckt. Das kostet Energie.
  Beim Umstellen der Software auf das Timing, wie es auch von den originalen HM-Sensoren benutzt wird, stösst man auf das Problem der Ungenauigkeit des
Watchdog Timers, der abhängig von Spannung und Temperatur seine Werte ändert.

Auch die von Linef eingefügte Kalibrierung löst dass Problem nicht wirklich.

Nach wochenlangen Versuchen daher meine Frage: Ist das für euch überhaupt ein Problem und wenn ja, wie habt ihr das gelöst?

[Frini]

Anbringen bekomme ich gerade noch hin 
Meine Frage zielte darauf ab, ob ich da noch was löten müsste oder so. Das krieg ich nämlich überhaupt nicht hin.

Aktuell mach ich das fast genauso wie Du. Ich hole mir über Twillight den Sonnenstand und über meinWetter (wegen fehlender Sensoren) die Temperatur. Wen die Temp. über 20 °C ist und die Sonne vor den Wohnzimmerfenstern steht, fahren die Rollos in den Beschattungsmodus. Jedoch unabhängig ob die Sonne scheint oder ob es gerade bewölkt ist. Das bringt mich halt immer in Erklärungsnot bei meiner Holden.

Die Frage war vielleicht etwas falsch formuliert. Sind die Sensoren so hochauflösend, dass ich den Unterschied zwischen bewölktem und nicht bewölktem Himmel mitbekomme?
Wenn ja, hätte ich wirklich interesse den Sensoren.
Grüße
Matthias

[Linef]

Hi,

das mit dem Timing sehe ich so:
Für ein Peering mit einem RT-DN reicht es derzeit (für mich) aus (Temperaturbereich 20-28 °C). Ich habe ein Register mit reinprogrammiert, mit dem ich die Frequenz des internen RC-Oszillators justieren kann (in ca. 0,3%-Schritten). D.h. bei einem Sendeabstand der Telegramme von z.B. 180 Sek. kann der Abstand auf 0,5 Sek. genau eingestellt werden. Da der RT-DN ein Empfangszeitfenster von 10 Sek. hat, kommt man also genügend genau in dieses Fenster rein.

Problem ist eher, daß der RT-DN die Telegramme ab und zu komplett ignoriert, obwohl sie im Zeitfenster liegen.

Somit kommt es bei mir nur alle paar Tage vor, daß der RT-DN auf seinen internen Temperatursensor zurückschaltet. Das ist natürlich trotzdem ärgerlich.
Hier würden mich mal Erfahrungsberichte von Usern interessieren, die den RT-DN mit einem original EQ3-Raumthermostat versorgen - gibts hier auch immer wieder Rückschaltungen auf den internen Temperatursensor des RT-DN ??

Ich hatte auch schon drüber nachgedacht, den 32KHz Quarzoszillator zu benutzen - funktioniert aber leider auch nicht, da im niedrigsten Energiesparmodus des Atmega 328P ausschließlich noch der (RC-gesteuerte) Watchdog Oszillator läuft
Hier könnte man allenfalls noch drüber nachdenken, mithilfe des Quarzoszillators den Watchdog immer mal wieder nachzukalibrieren.

Wenn der Sensor lediglich mit einer Zentrale gepairt ist, dann sehe ich überhaupt keine Probleme, was das Timing angeht.
Der Zentrale ist es egal, wann die Telegramme ankommen.

Wie es mit dem Peering mit anderen Aktoren aussieht, kann ich mangels Material nicht beurteilen.

Anbei übrigens der Temperaturverlauf über 1,5 Wochen - oben jeweils die gemessenen Werte des Eigenbau-Sensors, unten die des RT-DN. An insgesamt 5 Stellen (in den 3 markierten Bereichen) sieht man, daß er auf den eigenen, internen Sensor umgeschaltet hat. Davon waren aber 2 selbst verursacht (Neustarts des Sensors durch Neuprogrammierungen).

Viele Grüße,
Martin

[PeMue]

Anbringen bekomme ich gerade noch hin 
Meine Frage zielte darauf ab, ob ich da noch was löten müsste oder so. Das krieg ich nämlich überhaupt nicht hin.

Dirk's Sensoren sind komplett bestückt. Ggf. musst Du ihn noch in ein Gehäuse einbauen, aber ich meine, das hat er bei einem meiner Sensoren auch mitgeliefert.

Das bringt mich halt immer in Erklärungsnot bei meiner Holden.

Hm, dann solltest Du an ein einer Lösung arbeiten 
Vielleicht gibt Sie Dir dann das Budget dafür frei 

Sind die Sensoren so hochauflösend, dass ich den Unterschied zwischen bewölktem und nicht bewölktem Himmel mitbekomme?

Ja, das geht. Ich hänge mal einen Plot von heute dran, da sieht man (hoffentlich) den Unterschied zwischen bewölkt und nicht bewölkt. Allerdings könnte ich mir vorstellen, dass man sowohl eine Hysterese braucht als auch ggf. den Schwellwert im Winter (Sonnenstand) ändern können müsste ...

Gruß PeMue

[plombe]

Hallo,

habe zum Überprüfen der Synchronität zwischen Temperatursensor und Heizkörperthermostat den tempOffset auf -3.5K
eingestellt. Besonders in der heizungsfreien Zeit kann ich dadurch jede Abweichung erkennen.

Bei dem zweiten Bild sind die Kurven deckungsgleich - also keine Abweichung.

Erreicht habe ich das unter anderem durch Einbau der Bibliothek narcoleptic von http://playground.arduino.cc/Main/LibraryList.

[MadMax-FHEM]

Hallo Martin (Linef),

hab zwar eigentlich wegen was anderem vorbei geschaut

Aber weil ich über deine Frage "gestolpert" bin:

Somit kommt es bei mir nur alle paar Tage vor, daß der RT-DN auf seinen internen Temperatursensor zurückschaltet. Das ist natürlich trotzdem ärgerlich.
Hier würden mich mal Erfahrungsberichte von Usern interessieren, die den RT-DN mit einem original EQ3-Raumthermostat versorgen - gibts hier auch immer wieder Rückschaltungen auf den internen Temperatursensor des RT-DN ??

Ich habe einige HM-CC-RT-DN direkt mit einigen HM-TC-IT-WM-W-EU gepeert.

Ab und an habe ich mich über "eigenartiges" Verhalten der Heizkörper gewundert (macht auf, obwohl eigentlich warm genug / bzw. zu obwohl noch nicht warm)...
...und dann beschlossen, die desired-temp und measured-temp von beiden zu loggen (obwohl ja der HM-TC-IT-WM-W-EU "führend" ist und der HM-CC-RT-DN ja eigentlich seine eigenen Werte "ignorieren" soll, diese also identisch sein sollten) und mir nen Graphen gemacht.

Und ja ganz sporadisch laufen die mal ganz kurz "durcheinander", also der HM-CC-RT-DN springt auf sein eigenes Wochenprogramm etc.
Sieht so aus als würde er mal ein Telegramm des HM-TC-IT-WM-W-EU nicht bekommen (ist zumindest mal meine Vermutung).

Habe jetzt sorge ich immer dafür, dass die Wochenprogramme identisch sind dann fällt wenigstens das "komische Verhalten" der Heizkörper weg...

Aber ich denke nicht, dass das das eigentliche Problem (verlorenes Telegramm) löst, sondern nur die Auswirkung nicht mehr für mich sichtbar ist

Gruß, Joachim

[Linef]

Hallo,

habe zum Überprüfen der Synchronität zwischen Temperatursensor und Heizkörperthermostat den tempOffset auf -3.5K
eingestellt.

Den Offset habe ich bei mir zwecks Erkennung des Problems ebenfalls recht hoch eingestellt...

Bei dem zweiten Bild sind die Kurven deckungsgleich - also keine Abweichung.

War bei dem ersten Bild die Lib noch nicht eingebaut?
Wie lange läuft bei Dir der Synchronitätstest mit der Lib schon? Nur die paar Tage jetzt?

Ich muß mir mal ansehen, wie die Lib das Timingproblem löst - hat ja auch keine andere Hardware zur Verfügung...

@MadMax-FHEM:
D.h., auch bei den Originalsensoren von EQ3 scheint das Problem also aufzutreten - beruhigt mich etwas, daß es also doch möglicherweise am RT-DN selbst liegt.

Martin

[plombe]

Hallo,

@Linef:
die narcoleptic Library benutzt den Timer1 zum Messen der Watchdogzeit(16ms) und misst die Abweichung in Microsekunden bei jedem Aufruf.
Die Wirkung der Korrektur ist bei kurzen Zeiten nicht so gravierend (Auflösung).

Daher sind die gemessenen Zeiten bei Schlafzeiten von 250ms trotz Korrektur durch die Library 
ca. 249ms//255ms//256ms//255ms//252ms//250ms.(meine 6 Sensoren)

Leider muß man also jeden ATmega823P messen. Gerne hätte ich dafür ein Verfahren gefunden, das ohne individuelle Messung auskommt.
Aber da scheitere ich.
Zum Messen benutze ich einen Logikanalysator.

Bei einer eingestellten Schlafzeit von 100 000ms - zum Testen - ist die gemessene Zeit bei allen gleich bei 99 620ms.
Das bedeutet, daß eine Tiefschlafphase von z.B. 144 750ms hmid=EBD6C8 cnt=0 genau eingehalten werden kann.
Deshalb habe ich es so gelöst, daß die ersten 10 Minuten nach Reset der Sensor 250ms Pausen macht, der Sensor also gepairt und mit
den Heizungsthermostaten gepeert werden kann und danach in die lange Tiefschlafphase wechselt. Da reagiert er dann nicht mehr auf Tastendruck.
Der Stromverbrauch liegt dann bei ca. 4,5 Mikroampere.

Das Ergebnis ist, nach all dem langen Probieren und Suchen, begeisternd. Seit ca. 1 Monat laufen die ersten Sensoren, ohne ein einziges Mal
die Verbindung zu den gepeerten HM-CC-RT-DN zu verlieren. Das funktioniert auch, wenn ich den Sensor in den Kühlschrank lege.

Meine Versuche ergaben, daß der HM-CC-RT-DN seine interne Messung erst nach 5 erfolglosen Empfangsversuchen übernimmt.

Die Arduino Pro Mini mit internem RC-Oszillator waren mir so ungenau, daß ich 8MHz Keramik Quarze eingebaut habe.

Christian.

[Dirk]

Hallo Zusammen,

nach der "Sommerpause" melde ich mich wieder zurück
Aus beruflichen und privaten Gründen habe ich mich die letzen Woche ein bisschen zurück gezogen.
Darum, und auch auch wegen fehlender Teile war die Sensorproduktion auch liegen geblieben.
Da die letzten Teile diese Woche nun endlich eingetrudelt sind, hab ich die Produktion wieder aufgenommen.

Alle die noch auf der Warteliste standen haben daher gestern eine Nachricht bekommen.
Falls ich jemanden vergessen oder übersehen haben sollte, bitte nicht böse sein. Einfach noch mal eine kurze Nachricht an mich senden.

... werden bei jeder Sendung alle im Umkreis befindlichen HM-Geräte, die auf ein Burstsignal reagieren, geweckt.

Das sollte eigentlich nicht sein. Danke für den Hinweis. Das ist in meinem Umfeld noch gar nicht aufgefallen. Und dabei habe ich einige Sensoren im Einsatz.
Allerdings nur wenige Geräte die Auf Burst reagieren. Dabei hab ich aktuell keine erhöhten Energieverbrauch dort festgestellt. Ich werde mir das aber mal ansehen.


Viele Grüße
Dirk

[morph]

So, meine Geräte sind soeben eingetroffen und angelernt.

Vielen Dank an Dirk!!!!

Dann fangen wir mal an


Die Geräte sollen primär dazu dienen, die Rollos selbstständig hoch und runter zu fahren.


WO baue ich die Teile am Besten hin?

Direkt neben das Fenster?
In die "Sonne" oder den "Schatten"?

Habt ihr ein paar Bilder am "Einsatzort"?

Ein bisschen Code, wie ihr die Teile "auslest", bzw. "benutzt"?

VIelen dank schon mal.

[HMSteve]

Hallo,

habe mich mal hier angemeldet, da der Universalsensor die aesthetischen Probleme eines auf dem Schreibtisch herum blinkenden Arduino mit BMP280 an einen dicken USB-Kabel zur Stromversorgung, der den Luftdruck ueber ein dickes Cat6-Kabel per HTTP an die CCU2 postet, elegant loesen koennte. Zeit zum kompletten Selbstbau ist allerdings Mangelware. Darum die Frage:

Dirk,

ist noch eine Innensensor-Platine zu haben, bestueckt / unbestueckt?

Vielen Dank,
Stephan

[rvideobaer]

Hallo,

ich habe den Sensor von Dirk bei mir auf dem Balkon(Südseite) angebracht. Leider war ich mit den Temp. Werten nicht so zufrieden aber leider habe ich keinen anderen Platz.
Nach langer Suche habe ich im Internet endlich ein Gehäuse gefunden.
http://www.elv.de/tfa-schutzhuelle-fuer-aussensensor.html
Die Temp. Werte sind deutlich besser da der Sensor vor Direkter Sonneneinstrahlung geschützt ist und durch die Rippen des Strahlungsschutzes sich auch nicht so aufheizt.

Gruß Rolf

[morph]

Danke!