Feinstaubsensor - alternative Firmware (luftdaten.info)

Begonnen von JoWiemann, 03 Juli 2017, 16:09:14

Vorheriges Thema - Nächstes Thema

igami

Habe noch ein paar Änderungen eingebaut, unter anderem werden die master Readings gelöscht, wenn ein slave definiert wird.
Weiterhin wurden pressure_nn und pressure nicht unterschieden, das habe ich dann auch noch einbaut. Was soll ich als Beschreibung für das Reading eintragen? Wird der irgendwie berechnet?

Bei dir scheint aber auch was nicht zu stimmen: Temperatur und Luftdruck sind vertauscht?

... {"value_type":"BMP_pressure","value":"22.60"},{"value_type":"BMP_temperature","value":"101522.00"} ...
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

JoWiemann

Hallo igami,

danke für den Hinweis und habe ich korrigiert. Im Moment teste ich noch ein paar Sachen mit der Firmware.

Der Rest sieht gut aus.

pressure_nn, also Luftdruck auf Normal Null wird berechnet, wenn die aktuelle Höhe des Sensors größer 0 Meter über Normal ist. Somit erhält man den Vergleichswert für Wettereinschätzungen.

Berechnet wird so:

/**
* http://rn-wissen.de/wiki/index.php/RP6_Multi_IO_Projekt_-_Software#Library_Source_5
* Reduces the absolute airpressure [Pa] value
* and returns the airpressure at sea level
* value [Pa]. The airpressure at sea level is
* also stored in the global long variable p0.
*
* Input:  p   -> Airpressure [Pa]
*         alt -> Altitude [m]
*         t   -> Temperature [/ 10 °C]
*
* Output: Airpressure at sea level [Pa]
*
*/
int32_t ReducePressure(int32_t p, uint16_t alt, int32_t t)
{
  double dp0;
  double dt = t / 10;
  int32_t p0;
  dp0 = (double) p * (pow ((TEMP_ZERO + dt) / (TEMP_ZERO + dt + 0.0065 * alt), -5.255));
  p0 = (int32_t) dp0;
  return p0;                  // Result in [Pa]
}

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

igami

Zitat von: JoWiemann am 27 September 2017, 15:25:13
pressure_nn, also Luftdruck auf Normal Null wird berechnet, wenn die aktuelle Höhe des Sensors größer 0 Meter über Normal ist. Somit erhält man den Vergleichswert für Wettereinschätzungen.
Trifft die folgende Aussage dann zu?
Zitat

        <li>
          <code>pressureNN</code><br>
          Calculated pressure at sea level in hPa<br>
          Requires an altitude sensore or configured height.
        </li>

      <li>
        <code>pressureNN</code><br>
        Berechneter Luftdruck auf Meereshöhe in hPa<br>
        Benötig einen Höhen-Sensor oder eine konfigurierte Höhe.
      </li>
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

JoWiemann

Eher:

Berechneter Luftdruck für Normal Null bei aktivem Höhen- und Temperatursensor, sofern sich der Sensor nicht auf Normal Null befindet. Hierzu ist die Höhe, kann über Kartendienste oder SmartPhone ermittelt werden, auf der Konfigurationsseite anzugeben.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

igami

Zitat von: JoWiemann am 27 September 2017, 15:55:42
... bei aktivem Höhen- und Temperatursensor ...
Muss das nicht "Luftdruck- und Temperatursensor" heißen?
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

JoWiemann

Zitat von: igami am 27 September 2017, 16:04:52
Muss das nicht "Luftdruck- und Temperatursensor" heißen?

Stimmt. Heute ist noch nicht mein Tag.
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Burny4600

Zitat von: JoWiemann am 27 September 2017, 13:49:47
Welche Einheit hat den UV - Licht?
Ist eigentlich nur ein Index Definition.

Info nachzulesen unter https://de.wikipedia.org/wiki/UV-Index

Danke für die anderen Infos.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

JoWiemann

Zitat von: Burny4600 am 27 September 2017, 18:43:20
Ist eigentlich nur ein Index Definition.

Info nachzulesen unter https://de.wikipedia.org/wiki/UV-Index

Danke für die anderen Infos.

Ja, aber das ist der Index, der sich aus der Intensität errechnen lässt. "The VEML6070 does have a real light sensor in the UV spectrum." Somit sind wir dann doch wieder bei Lux.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

sash.sc

#158
Ich habe auch einen veml Sensor in meinem Außensensor am laufen.
Normalerweise bringt der veml Werte über 30000. Das muss auf den UV Index runter gerechnet werden.


https://forum.fhem.de/index.php?topic=63931.msg668264.msg#668264


Gesendet von meinem SM-T560 mit Tapatalk
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Burny4600

#159
Nach dem Wiki sind es beim UV Sensor die direkt ausgegeben werden µW/cm² und nicht Lux.
Dieser Wert kann dann umgerechnet werden 1 µW/cm² entspricht dabei 0,004 UV Index.

Barometrischer Luftdruck:
Dies wäre auch nicht schlecht wenn der Luftdruck auf die passende Komastelle reduziert wäre.
Wenn ein Display angeschlossen ist, sollte die Möglichkeit gegeben sein das diese Werte zumindest für das direkt angeschlossene Display passt.
Derzeitige Displayanzeige
Pres: 102924.0

Auch bei der Anzeige der des Feinstaubes wäre für die lokale Displayanzeige eine andere Definition besser zur Ansicht:
Vielleicht wäre es sinnvoller nicht SDS011- zu verwenden sonder für die Feinstaubsensoren grundsätzlich zb.
FSS Pm 2.5:
FSS Pm10.0:
Die derzeitige lokale Displayanzeige sagt nicht wirklich etwas aus. Hier wird derzeit zb. SDS01186.0
Siehe Anhang.
Bei der original Luftdaten Firmware war es noch ein wenig besser gelöst.

Was beim Display auch noch nicht passt ist das sich oben eine Leerzeile befindet, und dadurch im unteren Bereich ein Versatz der Zeile entsteht.

Vielleicht wäre noch eine Anpassung betreffend dieser Punkte möglich.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Christian Uhlmann

Hi,

sorry für die späte Rückmeldung.

Zitat von: igami am 27 September 2017, 13:54:03
@Christian: Hat das eigentlich funktioniert?

Ja, das hat geklappt, im Master Device wird nun die Temp vom DHT22 angezeigt. Im Slave Device die des BME, wie erwartet.

Nach dem testen der neueren Version aus diesem Post:
Zitat von: igami am 27 September 2017, 15:10:31
Habe noch ein paar Änderungen eingebaut, unter anderem werden die master Readings gelöscht, wenn ein slave definiert wird.
Weiterhin wurden pressure_nn und pressure nicht unterschieden, das habe ich dann auch noch einbaut. Was soll ich als Beschreibung für das Reading eintragen? Wird der irgendwie berechnet?

Hat es aber nicht mehr geklappt, die Temp vom DHT bekomme ich damit nicht in FHEM rein.

Ggf. muss die obere Änderung dort noch vorgesehen werden?


Danke und Grüße

Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

JoWiemann

Danke für die Rückmeldung. Ich werde mich dann übernächste Woche an die Überarbeitung machen. Nächste Woche geht es erst einmal ins Elb Sandsteingebirge.

Grüße Jörg


Gesendet von iPad mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

igami

Zitat von: Christian Uhlmann am 28 September 2017, 13:44:14
Ggf. muss die obere Änderung dort noch vorgesehen werden?
Da hab ich das doch tatsächlich wieder vergessen -.-

neue Version im Anhang
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Christian Uhlmann

Hi,

Zitat von: igami am 28 September 2017, 13:47:25
Da hab ich das doch tatsächlich wieder vergessen -.-

neue Version im Anhang

Perfekt :) so passt es tatsächlich wieder.


Grüße

Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

Burny4600

Ich habe mit der aktullen Version noch einige Probleme.
Sensor 1 besteht aus TSL2561 und VEML6070: Die Werte des TSL2561 werden in FHEM übernommen. Die des VEML6070 nicht obwohl bei get sensors dieser in der Auflistung der Sensoren erscheint.
Was mir nicht ganz klar ist warum aber bei dieser Konstellation ein max-micro und min_micro ausgegeben wird.

Sensor 2 besteht aus BME280, SDS011, einem GPS Neo6 und einem Mehrzeilen Display.
Von dieser Sensoreinheit wird nichts von FHEM übernommen.
sate ist permanent auf Error.
Via Browser ist der Sensor aber zu erreichen und gibt Werte aus.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess