Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[PeMue]

Hallo Kai,

sollte für die Schaltung v1.4 so sein:

Code Auswählen Erweitern

#define BAT_SENSOR BatterySensorUni<15, 7, 3300>    // mit StepUp, sense pin A1, activation pin D7, Vcc StepUp 3,3V

das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.

Gruß Peter

[Kai-Alfonso]

Hallo Kai,
das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.

Gruß Peter

Ach stimm, hattest du ja geschrieben - habe ich ganz übersehen Sorry

[Kai-Alfonso]

Es scheint aber irgendein ein Problem noch bei mir zu geben.

Ich hab folgende Sensoren aktiviert

Code Auswählen Erweitern

//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT


Nach dem Booten des Bootloaders (7 mal blinken) leuchtet die LED dauerhaft

[PeMue]

Hallo zusammen,

wenn ich einen Sensor mit zwei Lichtsensoren bauen will (TSL2561 und MAX44001) müsste ich in

Code Auswählen Erweitern

public:
    WeatherChannel()
        : Channel()
        , Alarm(seconds2ticks(60))
        , temperature10(0)
        , airPressure10(0)
        , humidity(0)
        , brightness(0)
        , digInputState(0)
        , batteryVoltage(0)

Code Auswählen Erweitern

    WeatherEventMsg msg;

    int16_t  temperature10;
    uint16_t airPressure10;
    uint8_t  humidity;
    uint32_t brightness;
    uint8_t  digInputState;
    uint16_t batteryVoltage;

den zweiten Kanal in temperature10 und airpressure10 "verstecken", um denselben Wertebereich zu bekommen und dann per userReading die beiden Werte in FHEM wieder zu einem zusammenzubauen. Oder gibt es noch eine bessere Lösung?
Eine Temperatur (ohne Faktor 10) würde dann in humidity kommen, falls noch etwas übrig sein sollte, oder? 

Danke + Gruß

Peter

[papa]

Hallo Peter,

vielleicht ist ja der Universelle-Sensor-Sketch etwas für Dich. Da kannst DU selbst bestimmen, was gesendet wird. Auf FHEM Seite muss dazu nur ein Attribute angelegt werden, wleches das gesendete Format bestimmt.

https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110

[Tom Major]

Hallo Kai,
das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.

Gruß Peter

Ich habe MAX1724 mit 3,0V Ausgangsspannung im Einsatz, deswegen die 3000, aber klar bei 3,3V Ausgangsspannung natürlich dann 3300.

[Tom Major]

Es scheint aber irgendein ein Problem noch bei mir zu geben.

Ich hab folgende Sensoren aktiviert

Code Auswählen Erweitern

//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT


Nach dem Booten des Bootloaders (7 mal blinken) leuchtet die LED dauerhaft

Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?

[Tom Major]

den zweiten Kanal in temperature10 und airpressure10 "verstecken", um denselben Wertebereich zu bekommen und dann per userReading die beiden Werte in FHEM wieder zu einem zusammenzubauen. Oder gibt es noch eine bessere Lösung?
Eine Temperatur (ohne Faktor 10) würde dann in humidity kommen, falls noch etwas übrig sein sollte, oder? 
Danke + Gruß
Peter

ich verstehe die Frage mit dem "verstecken" nicht wirklich. In gewissen Grenzen bist du ja frei die payload selber zu bestimmen solange du auf der anderen Seite (FHEM, CCU) für die korrekte Dekodierung sorgst.
Du könntest z.B. den zweiten Helligkeitswert in der Payload anfügen und die Messagelänge entsprechend vergrößern. Oder nicht benutzte Messwerte entfernen. Und dann das Perl Script anpassen dass die Dekodierung zu deinen Änderungen passt.

[Kai-Alfonso]

Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?

Muss ich dafür NDEBUG aktivieren?

Und noch eine kleine Frage: ist es jetzt Typ F102 oder F103, wenn man den alten Unisensor mit der neuen Software flashed?

[PeMue]

Hallo papa,

vielleicht ist ja der Universelle-Sensor-Sketch etwas für Dich. Da kannst DU selbst bestimmen, was gesendet wird. Auf FHEM Seite muss dazu nur ein Attribute angelegt werden, wleches das gesendete Format bestimmt.

https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110

danke für die Info, werde ich mir mal anschauen.

Hallo Tom,

Ich verstehe die Frage mit dem "verstecken" nicht wirklich. In gewissen Grenzen bist du ja frei die payload selber zu bestimmen solange du auf der anderen Seite (FHEM, CCU) für die korrekte Dekodierung sorgst.

das war mir in dieser Form nicht klar. Ich dachte, für den Universalsensor ist die PayLoad festgelegt.

Du könntest z.B. den zweiten Helligkeitswert in der Payload anfügen und die Messagelänge entsprechend vergrößern. Oder nicht benutzte Messwerte entfernen. Und dann das Perl Script anpassen dass die Dekodierung zu deinen Änderungen passt.

Im Sketch würde ich das bestimmt hinbekommen, auf FHEM Seite wird das (mangels Perl Kenntnissen) deutlich schwieriger ...

Gruß Peter

[Tom Major]

Muss ich dafür NDEBUG aktivieren?

Und noch eine kleine Frage: ist es jetzt Typ F102 oder F103, wenn man den alten Unisensor mit der neuen Software flashed?

NDEBUG muss dafür kommentiert bleiben.

Code Auswählen Erweitern

//#define NDEBUG

Mein Sketch verwendet F103 (Zeile 105)

[Tom Major]

Hallo Tom,
das war mir in dieser Form nicht klar. Ich dachte, für den Universalsensor ist die PayLoad festgelegt.
Im Sketch würde ich das bestimmt hinbekommen, auf FHEM Seite wird das (mangels Perl Kenntnissen) deutlich schwieriger ...
Gruß Peter

Wenn du mir schreibst welche Messwerte du genau in deiner Spezialversion brauchst mache ich ich dir einen Vorschlag für die Payload und für das Decode in FHEM.

[gregor]

Erst mal vielen Dank für die vielen Infos hier. Ich habe HB-UNI-Sensor1 zusammengebaut und funktioniert auf Anhieb. FHEM bekommt regelmäßig plausible Werte - außer von MAX44009 (GY-49). Der funktioniert prima, solange der Sensor  auf meinem Schreibtisch liegt. Sobald ich ihn nach draußen stelle, kommen erst ein paar höhere Werte im 2000er Bereich, dann nur noch 0-Werte. Hole ich ihn wieder rein, sofort wieder Werte im 300er Bereich. Das habe ich ein paar mal wiederholt und ist reproduzierbar. Die Außentemperatur kann es eigentlich nicht sein (ca. 3° ), weil 1. die Nullwerte kommen, bevor der richtig ausgekühlt ist und 2. plausible Helligkeitswerte sofort kommen sobald er wieder drin ist. Hat jemand eine Idee ? Wie kann ich das Problem am Besten finden/isolieren?

Habe mir mal das Datenblatt und das GY-49 angeschaut - Der Eingang für die Auswahl der Adresse (A0) war offen. Ich habe ihn mal mit GND verlötet und warte nun dass es draußen wieder hell wird.

Danke
Gregor

[Tom Major]

Erst mal vielen Dank für die vielen Infos hier. Ich habe HB-UNI-Sensor1 zusammengebaut und funktioniert auf Anhieb. FHEM bekommt regelmäßig plausible Werte - außer von MAX44009 (GY-49). Der funktioniert prima, solange der Sensor  auf meinem Schreibtisch liegt. Sobald ich ihn nach draußen stelle, kommen erst ein paar höhere Werte im 2000er Bereich, dann nur noch 0-Werte. Hole ich ihn wieder rein, sofort wieder Werte im 300er Bereich. Das habe ich ein paar mal wiederholt und ist reproduzierbar. Die Außentemperatur kann es eigentlich nicht sein (ca. 3° ), weil 1. die Nullwerte kommen, bevor der richtig ausgekühlt ist und 2. plausible Helligkeitswerte sofort kommen sobald er wieder drin ist. Hat jemand eine Idee ? Wie kann ich das Problem am Besten finden/isolieren?

Habe mir mal das Datenblatt und das GY-49 angeschaut - Der Eingang für die Auswahl der Adresse (A0) war offen. Ich habe ihn mal mit GND verlötet und warte nun dass es draußen wieder hell wird.

Danke
Gregor

Klingt seltsam mit dem MAX44009. Ich würde in solchen Fällen mit Notebook und FTDI Adapter rausgehen und mir die Debugwerte der MAX44009 Messungen anschauen ob man da was sieht was draußen anders ist. Und notfalls weitere Debug Ausgaben in der  MAX44009 Klasse anlegen um das Problem einzugrenzen.

[gregor]

Gelöst: Ursache für die 0-Werte von MAX44009 war der offene A0 Anschluss. Wenn der Anschluss zu high wechselt (vmtl. durch hohe Luftfeuchtigkeit), können die Werte nicht mehr ausgelesen werden. Ich habe ein Bild mit entsprechendem Hinweis angehängt.

Gruß
Gregor