Work in progress: new sensors and components about sensors-software HOT 28 OPEN

first sensor modules of BME 680 is now commercial available for example:
https://www.sparkfun.com/products/14570
https://de.aliexpress.com/item/BME680-temperature-and-humidity-temperature-pressure-high-altitude-sensor/32847670390.html

from sensors-software.

Thanks for testing. So we can use the 1003 decoding with the 7003.
Funny fact: bytes 3 and 4 should show the length of the 'frame'. For the 7003 this is 0x28 or 40 bytes. And just another Plantronics sensor with a wrong protocol documentation ...

from sensors-software.

The value seems to be 0x28 in every frame.
So we have now the following frame lengths:
PMS1003: given 0x20 - is 0x20
PMS3003: given 0x20 - is 0x18
PMS7003: given 0x28 - is 0x20
May be thats interesting for other people too.

from sensors-software.

Great!
Thank you!

from sensors-software.

@ricki-z MQ-2 and MQ-135 sensors have no value in this kind of project. Because they need to be calibrated. It's impossible to compare one sensor to another.
They drift after a while, have limited lifetime and consume a lot of power.

from sensors-software.

What about this sensor ?
CCS811
https://www.sparkfun.com/products/14193

Can it be useful for project ?

from sensors-software.

We are waiting for the Bosch BME680. This sensor will measure temperature, humidity, pressure and VOC. Price should be in the same range.
The BME integration should be easy as we have most of the other BMP and BME included already.

from sensors-software.

Wo kann man den kaufen?

from sensors-software.

Just tried BME280 sensor connected to nodeMCU at pins D3 and D4 and it doesn't work. Thats because first initialization is done with Wire.begin(D4,D3) but later the BME280 function bme.begin() is called. Inside this function Wire.begin() with standard pins is called and overwrites the first correct init. If I Change Wire.begin() to Wire.begin(D4,D3) in file Adafruit_BME280.cpp then it works. Needs some code change in main ino file.

from sensors-software.

Which version did you use? The version under 'airrohr-firmware' is the actual version. Our bulgarian colleagues use this version with SDS011 and BME280 only. And this without problems.

from sensors-software.

I use the version here from github. The problem is the 2nd Wire.begin() in function bme280.begin() from the library itself. If i change Wire.begin() in the library to Wire.begin(D4,D3) then it works.
I'm using a nodeMCU 1.0.

from sensors-software.

Please give me the path her on github to the version you use. As I've mentioned we have over 100 sensors with working BME280. The Wire lib is using the TwoWire lib. This lib is initiated with the first call of Wire.begin. The first call in our firmware is in the function setup() with given parameters D3,D4.

from sensors-software.

The DS18B20 Sensor is also available in a "waterproof" case, so it would be possible to measure the temperature outside the housing. I will try to implement it in a few weeks, which should'nt be to hard since there are the "OneWire" and "DallasTemperature" library available.

from sensors-software.

I would really like to contribute in order to integrate PMS7003
#103
But since i am totally new to these IoT devices (yes, that's a shame, i am usally more on OpenWRT and other stuff running linux kernel); Is there a quick start you can recommend?
is there some kind of "minimal version" of the code which just initializes the sensors and reads them, without all the website&database stuff, so making it easier to debug. Or is there a "special" mode you can ativate, in order to run stuff separately?

from sensors-software.

I'm about to integrate the PMS x003 series. But there are some differences between documentations and real sensor readings. I.e. for the 3003 the documentation says a frame is 32 bytes long, the frame size header field says 32 bytes, but the sensor is sending only 24.
So we need a sample of every sensor to check this.
I've added some perl scripts to our repo (https://github.com/opendata-stuttgart/sensors-software/tree/master/perl-scripts). These scripts will try to decode the data sent by a sensor connected via usb-to-serial converter.
If you have a PMS7003 you could try the two pms scripts and send me the output.

from sensors-software.

o.k. my fault... PMS7003 seems to work perfect with the PMS1003 script.
And it looks like the sensor is repeating the same datagram 3 times in a row. So in case you want to save engery and are sure about your readings: just skip 2... (of course, this is softserial... so no big economy to gain)

https://paste.debian.net/977576/

Checksum is: 467 - Checksum_should: 467
Checksum is: 550 - Checksum_should: 550
Checksum is: 550 - Checksum_should: 550
Checksum is: 550 - Checksum_should: 550
Checksum is: 534 - Checksum_should: 534
Checksum is: 534 - Checksum_should: 534
Checksum is: 534 - Checksum_should: 534
Checksum is: 536 - Checksum_should: 536
Checksum is: 536 - Checksum_should: 536
Checksum is: 536 - Checksum_should: 536
Checksum is: 524 - Checksum_should: 524
Checksum is: 524 - Checksum_should: 524
Checksum is: 524 - Checksum_should: 524
Checksum is: 590 - Checksum_should: 590
Checksum is: 590 - Checksum_should: 590
Checksum is: 590 - Checksum_should: 590
Checksum is: 635 - Checksum_should: 635
Checksum is: 635 - Checksum_should: 635
Checksum is: 635 - Checksum_should: 635
Checksum is: 685 - Checksum_should: 685
Checksum is: 685 - Checksum_should: 685
Checksum is: 685 - Checksum_should: 685
Checksum is: 665 - Checksum_should: 665
Checksum is: 665 - Checksum_should: 665
Checksum is: 665 - Checksum_should: 665
Checksum is: 723 - Checksum_should: 723
Checksum is: 723 - Checksum_should: 723
Checksum is: 723 - Checksum_should: 723
Checksum is: 763 - Checksum_should: 763
Checksum is: 763 - Checksum_should: 763
Checksum is: 763 - Checksum_should: 763
Checksum is: 629 - Checksum_should: 629
Checksum is: 629 - Checksum_should: 629
Checksum is: 629 - Checksum_should: 629
Checksum is: 687 - Checksum_should: 687
Checksum is: 687 - Checksum_should: 687
Checksum is: 687 - Checksum_should: 687
Checksum is: 716 - Checksum_should: 716
Checksum is: 716 - Checksum_should: 716
Checksum is: 716 - Checksum_should: 716
Checksum is: 788 - Checksum_should: 788
Checksum is: 788 - Checksum_should: 788
Checksum is: 788 - Checksum_should: 788
Checksum is: 772 - Checksum_should: 772
Checksum is: 772 - Checksum_should: 772
Checksum is: 772 - Checksum_should: 772
Checksum is: 842 - Checksum_should: 842
Checksum is: 842 - Checksum_should: 842
Checksum is: 842 - Checksum_should: 842

from sensors-software.

And just another Plantronics sensor with a wrong protocol documentation ...

Bizarre... "never implement according to the spec". i wonder if the value is calculated wrong for each frame or just a wrong const. (no, completly out of scope here)

from sensors-software.

despite the fact that the information of datagram length is somewhat redundant if you already know what sensor is connected (otherwise you don't know how to interpret the data):
if there would be at least a field telling which sensor is actually connected an perhaps it's firmware or even some wear counter.
In that case the drivers could do autodetect (including to say if it's 1003 or 7003) and even apply of necessary according to FW and/age some correction tables.

from sensors-software.

but to come back to topic, it would be great to have for PMS s additional IO that us just powered up 30(?) seconds before measurements, in order to save some power.

from sensors-software.

Ich hätte gern den INA219 (I2C Spannung/Strom, letzteres "massenfrei meßbar"), am besten gleich für 2 Stück.
Das wäre für eine Solar-Version wichtig, um den Akkustand (Zell-Spannung, Entladung) und die Solarzelle (Panel-Spannung, Ladestrom) zu monitoren. (Spannung vom ESP: Hoffentlich kontant... und Leistungsaufnahme hoffentlich auf den Spannungen und der Differenz zu berechnen... sofern die Wandler-Verluste halbwegs konstant/linear sind.)

from sensors-software.

Anything i could do here to get the stuff for PMS7003 moving?
Should i try something and make a PR? (my code will probably not very good...)

from sensors-software.

I'm testing the latest beta version on some sensors. If everything seems okay, this version will go online on monday. This version includes support for the HTU21D, BMP280, PMS1003, PMS3003, PMS7003.
With so many sensors online we have to test the software thoroughly.

from sensors-software.

LCD 1602 or 1604
What about 2004?
To display all information, the 1602 will be a limitation.
What is with a LCD 2004? Is there a 1604?

from sensors-software.

BTW: for PMS7003: I see it transmitting and on the local sensor, but it's not getting on the graphs
https://www.madavi.de/sensor/graph.php yet.
Or there something i have to set up on the sensor itself?
Since it works well for the temp/hydrometric sensors on the same device i would assume that the PMS should show up too.

from sensors-software.

PMS should show up now.

from sensors-software.

We are redesigning the display functions. The data should be split in frames.

from sensors-software.

In the start post the 1604 is mentioned. As I see, there is no 1604 LCD with I2C support available at the friendly asien seller but a 2004 LCD with I2C support.
Which display will be supported in future?
Is there a discussion thread for the future display function?

from sensors-software.

Support for the BME680 would be really appreciated. How can I support development?

from sensors-software.