Interesting.
If you plot them both on the same chart they will be easier to compare, but you still get the idea like that.
Sometimes I use Grafana, and then you can tinker with offsets (say add 10) and linear scaling (say multiply by 0.9) on the fly until they line up …
Nice work comparing these! Semi-related question: How did you get the SPS30 to work with esphome? I only get extremely high values, like this:
Did you encounter anything like this?
I haven’t experienced any issues with the SPS30 sensor. Just use the SPS30 component. SPS30 Particulate Matter Sensor — ESPHome
Used this, GitHub - paulvha/sps30: Sensirion SPS30 driver for ESP32, SODAQ, MEGA2560, UNO, ESP8266, Particle-phot , as standalone before, and it worked just fine as well.
Apparently I had connected it to 3V instead of 5… Up and running now.
Pleeeeeenty of room for more stuff inside!!! I manage to install a mhz19 (temp and CO2) and a MQ-9 (CO)
After a few days working very well I´ve decided to open a wee hole for the MQ-9 because of the heat it generates, not much tho but it affects the MHZ19 temperature sensor.
This is my esphome code
esphome:
name: sensor-aire-ikea
platform: ESP8266
board: d1_mini
api:
ota:
password: "xxxxxx"
wifi:
ssid: "xxxxxx"
password: "xxxxxxxl"
ap:
ssid: "Sensor-Aire-Ikea"
password: "xxxxxxxx"
captive_portal:
uart:
- id: uart_1
rx_pin: D2
baud_rate: 9600
- id: uart_2
rx_pin: D3
tx_pin: D4
baud_rate: 9600
sensor:
- platform: pm1006
pm_2_5:
name: Ikea_PM25
uart_id: uart_1
- platform: mhz19
co2:
name: "Dioxido de Carbono"
temperature:
name: "Temperatura"
update_interval: 120s
automatic_baseline_calibration: false
uart_id: uart_2
- platform: adc
pin: A0
name: "Monoxido de Carbono"
update_interval: 60s
filters:
- lambda: return (x * 1024/5);
unit_of_measurement: "ppm"
icon: 'mdi:fire'
Was thinking of doing something similar, but then I would like to control the LEDs myself, so that they become orange/red when the CO2 level rises as well, but since those are not controllable I have not begun that project yet.
That should be possible, you just need to cut the leads running up to them with a sharp screwdriver and wire them up to your board. 
Hehe. True that! Will actually try that out.
Thanks for share the way!
It’s really easy connect to ESPhome & HA
I also put DHT22 in it, here’s my setup & code:
esphome:
name: ikea-pm25
platform: ESP8266
board: d1_mini
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
wifi:
ssid: !secret my_ap_ssid
password: !secret my_ap_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Ikea-Pm25"
password: !secret the_ap_password
captive_portal:
uart:
rx_pin: D2
baud_rate: 9600
sensor:
- platform: pm1006
pm_2_5:
name: "PM2.5 sensor"
- platform: dht
pin: D5
temperature:
name: "Temperature"
humidity:
name: "Humidity"
update_interval: 30s
Hi guys!
Have you noticed that your reading will either stay the same for very long time or will change to unknown after home assistant reboots?
I’m, running esp32 with esphome, with config same as everyone else’s above 
Thanks for any input!
Great solution!
I would be very grateful if you could share your yaml configuration
Tasmota now supports Vindriktning. Currently it is required to compile your own firmware with
#define USE_VINDRIKTNING
Result
!
How are the 3 different values? Full RX/TX UART support?
@Habbie, you might want to have a peek on this…
Full RX/TX is in pm1006: add support for sending a measurement request by Habbie · Pull Request #2214 · esphome/esphome · GitHub
I also saw the two other numbers in the data frame from the pm1006, but the datasheet does not say what they are, so I did not make a separate sensor output for them. If somebody has good information on what they are, we can add them, of course.
(reading calculation appears to be wrong · Issue #3 · Hypfer/esp8266-vindriktning-particle-sensor · GitHub has some earlier discussion on the other numbers in the frame)
The PM1006K is not the PM1006
The Tasmota code is at Tasmota/xsns_91_vindriktning.ino at 03b26adf07b6ee5f42a9511eaae6fece3948cb0d · arendst/Tasmota · GitHub - it indeed appears to be based on mixing the PM1006 and PM1006K datasheets
Judging from the code, the Tasmota implementation is RX-only, like the one currently in ESPHome (but see my PR above for adding TX to the one in ESPHome).
I was assuming RX/TX, as I’ve never seen the other two values before, and though the PM2.5 was only due because the TX from the device queries only that. But now I understand the whole thing.
It is interesting that there are PM1006 and PM1006K sensors, with identical look and far too similar specs and behaviour. I have a feeling that the PM1006 is a sensor which fails on the higher specs PM1006K’s QC process or missing some calibration. (The PM1 on the previous picture looks extreme for me, that’s why I think the above.) Someone should ask Cubic what is the difference if any.
I emailed Cubic 20 minutes ago to ask about the other values in the PM1006 response 
I did not ask about the difference between the two products.
Also interesting: Cubic’s Chinese site only lists the pm1006; the English site only lists the pm1006k. They are both ‘article 105’.
As for the extreme ‘PM1’ value (which we are assuming is because of how the responses from the pm1006k look), you can also see that at reading calculation appears to be wrong · Issue #3 · Hypfer/esp8266-vindriktning-particle-sensor · GitHub - it’s the 06 9f column.