Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Gernott]

1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.

Ich war einige Tage unterwegs und hatte nach 600 ms mit vielen Aussetzern dann mal 700 ms gesetzt. Damit ist er 3 Tage nur mit je einem Aussetzer pro Tag gelaufen. Ich werde es nun mal feinfühlig erhöhen und mal sehen, wie es sich entwickelt.

[Gernott]

Gernott hat also den richtigen Hinweis geliefert. Danke!
Komischerweise, kann ich den Sketch lediglich einmal aufspielen, nachdem ich den Bootloader gebrannt habe. Dann klappt es nicht mehr, bis ich wiederrum den Bootloader erneut brenne. Aber damit kann ich leben.

Bitte, gerne. Vielleicht habe ich ja noch einen. Vor etlichen Wochen hatte ich dieses Problem auch. Prüfe mal nach dem Flashen des Bootloaders, ob die Fuses noch stimmen. Aus mir unerfindlichen Gründen haben die sich dabei jedesmal verstellt und der Sketch hat den Bootloader überschrieben. Ging natürlich dann nur ein Mal, wie bei Dir.  Nachdem ich die Fuses wieder korrigiert hatte, konnte ich dann den Sketch hochladen, ohne den Bootloader jedes Mal zu überschreiben (siehe hier).

[papa]

Ich war einige Tage unterwegs und hatte nach 600 ms mit vielen Aussetzern dann mal 700 ms gesetzt. Damit ist er 3 Tage nur mit je einem Aussetzer pro Tag gelaufen. Ich werde es nun mal feinfühlig erhöhen und mal sehen, wie es sich entwickelt.

So gut sieht es bei mir nicht aus. Ich vermute aber auch, das ich auch schlechten Empfang habe, da das Thermostat unterm Dach und der Sensor im Keller ist (2 Etagen dazwischen). Da kann schon mal was verloren gehen.

[Gernott]

Kurzes Update:
Hatte von 700 ms (1 Aussetzer/Tag) auf 750 ms gestellt. Da hatte ich wieder 10 Aussetzer pro Tag. Jetzt läuft es mit 740 ms seit einem Tag synchron und die Temperaturkurven sind auch ziemlich parallel. Das Optimum scheint (bei mir?) dann also in diesem Bereich zu liegen.

[Spezialtrick]

Bitte, gerne. Vielleicht habe ich ja noch einen. Vor etlichen Wochen hatte ich dieses Problem auch. Prüfe mal nach dem Flashen des Bootloaders, ob die Fuses noch stimmen. Aus mir unerfindlichen Gründen haben die sich dabei jedesmal verstellt und der Sketch hat den Bootloader überschrieben. Ging natürlich dann nur ein Mal, wie bei Dir.  Nachdem ich die Fuses wieder korrigiert hatte, konnte ich dann den Sketch hochladen, ohne den Bootloader jedes Mal zu überschreiben (siehe hier).

Sieht gut aus, ich habe keine Idee warum das serielle Flashen dann nur einmal geht.

Ich setze sicherheitshalber immer noch die BLB1 Fuse so (2. Bild):
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz
Dann kann die Application nie den bootldr überschreiben (zumindest in der Theorie  )

Genauso war es bei mir. Nachdem Flashen des Bootloaders wurden die Fuses immer wieder verändert. Insbesondere wurde die Lock Fuse immer mit 0xFF gesetzt.
Nachdem ich diese auf 0xEF geändert habe, kann ich nun immer wieder einen Sketch aus der IDE flashen. 

UV Sensor: mal die customData in Sketch und Perl script anschauen. damit kann man quasi jedes beliebige reading aus den customData für FHEM erzeugen, auch einen UV-Index.

Im Fhem Modul findet sich ja dieser Teil zum CustomData:

Code Auswählen Erweitern

# 16bit customData, ab Firmware 0x13
        $stateMsg .= ' X: ' . $customData;
        push (@events, [$shash, 1, 'customData:' . $customData]);

Und im Sensor Sketch dieser Teil:

Code Auswählen Erweitern

#ifdef SENSOR_VEML6070
        veml6070.measure();
        // Beispiel custom payload, 4bit für UV-Index (integer 0..11)
        uint8_t uvi = veml6070.uvIndex();
        customData &= 0xFFF0;
        customData |= (uvi & 0x0F);

@Tom Major: Könntest du mir hierzu ein paar weiterführende Tipps geben? Ich habe ehrlich gesagt keine Idee wo ich ansetzen soll, weil ich den Code nicht lesen kann. Analog zu den anderen Messwerten die mit dem Weather Event gesendet werden, könnte der Teil im Fhem Modul doch irgendwie so lauten:

Code Auswählen Erweitern

# 16bit customData, ab Firmware 0x13
        my $customData = customData &= 0xFFF0;
        $stateMsg .= ' X: ' . $customData;
        push (@events, [$shash, 1, 'customData:' . $customData]);

Soweit die UV-Messung überhaupt an Fhem übertragen wird.

[Tom Major]

@Tom Major: Könntest du mir hierzu ein paar weiterführende Tipps geben? Ich habe ehrlich gesagt keine Idee wo ich ansetzen soll, weil ich den Code nicht lesen kann. Analog zu den anderen Messwerten die mit dem Weather Event gesendet werden, könnte der Teil im Fhem Modul doch irgendwie so lauten:

Code Auswählen Erweitern

# 16bit customData, ab Firmware 0x13
        my $customData = customData &= 0xFFF0;
        $stateMsg .= ' X: ' . $customData;
        push (@events, [$shash, 1, 'customData:' . $customData]);

Soweit die UV-Messung überhaupt an Fhem übertragen wird.

Ab Firmware 1.3 ist die customData immer in der Message dabei.
So müsste es ungefähr gehen (ungetestet)

Code Auswählen Erweitern


        # UV-Index VEML6070
        my $uvindex =  $customData & 0x000F;
        $stateMsg .= ' U: ' . $uvindex;
        push (@events, [$shash, 1, 'UV-Index:' . $uvindex]);


Falls das geht ? kann ich das als Beispiel in dem Skript einkommentiert mit aufnehmen.

Du musst nach Änderung mindestens ein reload des Skripts machen oder FHEM Neustart.

[Spezialtrick]

Ab Firmware 1.3 ist die customData immer in der Message dabei.
So müsste es ungefähr gehen (ungetestet)

Code Auswählen Erweitern


        # UV-Index VEML6070
        my $uvindex =  $customData & 0x000F;
        $stateMsg .= ' U: ' . $uvindex;
        push (@events, [$shash, 1, 'UV-Index:' . $uvindex]);


Falls das geht ? kann ich das als Beispiel in dem Skript einkommentiert mit aufnehmen.

Das scheint zu funktionieren. 

Zumindest wird das Reading im Sensor angezeigt. Derzeit logischerweise ohne UV Strahlung.  Ich melde mich morgen, wenn die Sonne wieder scheint.

Herzlichen Dank schon mal!

[Tom Major]

ok, sehr gut.
Ich denke bei Sonne sollte jetzt einem UVI > 0 in FHEM nichts im Wege stehen. 

[Gernott]

Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.

[Tom Major]

Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.

Gut zu wissen.
Kannst du mal deinen aktuellen sketch posten? Dann nehme ich die Änderungen ev. als Kommentar mit in den UniSensor, in einem halben Jahr kommt sicher der nächste mit diesem Problem. 

[Gernott]

Gut zu wissen.
Kannst du mal deinen aktuellen sketch posten? Dann nehme ich die Änderungen ev. als Kommentar mit in den UniSensor, in einem halben Jahr kommt sicher der nächste mit diesem Problem. 

Hier ist er. Ich hatte noch den SHT31 dazugenommen, aus einem von papa's Beispielen.

[papa]

Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.

Das klingt ja super. Dann muss ich das mal in den Master mergen. Der async-Branch ist eigentlich für was anderes.

[Spezialtrick]

Ich wollte einfach mal DANKE sagen! 

Mein neuer Universalsensor läuft seit nunmehr fast vier Wochen einwandfrei und meldet zuverlässig alle paar Minuten die Sensorwerte.
Ich messe mit dem Sensor die Temperatur, die Luftfeuchtigkeit, den Luftdruck, die Helligkeit und die UV-Einstrahlung.

Danke an Dirk für die Initiierung des Projekts! 
Danke an Papa für das tolle Gehäuse und die Umsetzung der AsksinPP! 
Danke an Tom Major für den "idiotensicheren" Sketch! 
Danke an alle anderen die dieses Projekt möglich gemacht haben! 

Ein paar Fotos von meiner Umsetzung des Sensors füge ich als Anhang bei.

(https://uploads.tapatalk-cdn.com/20190923/c75f64c34dc5570333681df64cd5393d.jpg)

(https://uploads.tapatalk-cdn.com/20190923/0a8428596aca86bb84af73bf78e97148.jpg)

(https://uploads.tapatalk-cdn.com/20190923/9e44841df77083641e6685ed4a6bbdbe.jpg)

(https://uploads.tapatalk-cdn.com/20190923/cc8e43cbb8ec0be379b7dbeb77744109.jpg)

(https://uploads.tapatalk-cdn.com/20190923/a9f7914a0ba05a31860a6322d452eec1.jpg)

[gloob]

Ich wollte einfach mal DANKE sagen! 

Mein neuer Universalsensor läuft seit nunmehr fast vier Wochen einwandfrei und meldet zuverlässig alle paar Minuten die Sensorwerte.
Ich messe mit dem Sensor die Temperatur, die Luftfeuchtigkeit, den Luftdruck, die Helligkeit und die UV-Einstrahlung.

Danke an Dirk für die Initiierung des Projekts! 
Danke an Papa für das tolle Gehäuse und die Umsetzung der AsksinPP! 
Danke an Tom Major für den "idiotensicheren" Sketch! 
Danke an alle anderen die dieses Projekt möglich gemacht haben! 

Ein paar Fotos von meiner Umsetzung des Sensors füge ich als Anhang bei.

Kleiner Tipp, wenn die Kabel nach unten raus gehen, kann oben kein Wasser rein laufen.

[Spezialtrick]

Kleiner Tipp, wenn die Kabel nach unten raus gehen, kann oben kein Wasser rein laufen.

Der Sensor steht auf einem überdachten Balkon. Wasser stellt also kein Problem dar.