Yeah I get it, just wanted to see if they had a US reseller, tindie site, or another website so I could buy it more easily from that company. I’m sure there are other people in the US who want to buy this product and support them too!
The only thing what I can suggest is to send them a message. They might can do something to make it a better option for you. I don’t work for them. I know their product only from one of the posts above.
1 Like
Today I was at IKEA and (of course) couldn’t resist picking one up myself as it was on sale now.
I connected it to a USB-cable and it seemed to work fine, but i noticed it stayed orange and never turned green.
No matter where i put it, it is either orange or red. Even outside where the PM2.5 is currently 14 µg/m³ according to official reports, where the sensor should definitely show green. It shows date code 2135 on the sensor.
I couldn’t resist opening the PM1006 to see if there was something obvious that caused this. Luckily the PM1006 is easily opened by removing the 3 screws and lifting the metal plate. The circuit board is press fit and lifts out of the case. All parts are secured in place, no pieces wil go flying. On the bottom of the circuit board are the two diodes with a lens in front of each of them. I found one of the lenses had some smudge/grease on it. I cleaned both lenses and diodes with a cotton swab drenched in 96% alcohol, and dried them off making sure no dust is left behind.
Next I reassembled the sensor, to find it now actually turns green! Testing with a vape pen it now reacts quickly to the particles going red, and after a while it goed from red to orange to green. That seemed to have fixed it.
If it is reading too high or you see other abnormal readings, try cleaning the lenses and diodes on the inside of the PM1006 and see if it improves. Unfortunately I am still waiting on my Wemos D1 mini’s otherwise I could have done a before and after comparison reading the sensor’s output.
4 Likes
With the latest upgrades of the Bluetooth integration and the Bluetooth proxy, I hope you have ordered an ESP32 D1 Mini to utilise it as a proxy as well. 
Interesting thread and looks pretty easy to implement as well!
But, I’m now stuck in the very beginning. When ESPHome (from latest version of Home Assistant) tries to install the software to Wemos D1 Mini, I get following error.
INFO Reading configuration /config/esphome/vindriktning-8266.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing vindrikning-air-quality-sensor (board: d1_mini; framework: arduino; platform: platformio/espressif8266 @ 3.2.0)
--------------------------------------------------------------------------------
Platform Manager: Installing platformio/espressif8266 @ 3.2.0
Error: Please upgrade to the PlatformIO Core 6
How to solve this?
What version of ESPHome are you running? Platformio should be already version 6.
Oh, it looks like I had not made the move from ESPHome Community plugin to ESPHome’s add-on store one, and thus have an old version running. Will do the change. Thanks!
Ps. Maybe the ‘old’ version could have nagged about the situation? Or maybe it did and I did not see?
It is not nagging about it. I realised a half year after the change happened, that I am on the wrong repo.
Hi I followed fabiosofts guide GitHub - fabiosoft/esp8266_ikea_vindriktning: Ikea Hack: Making the air quality sensor VINDRIKTNING smart sensor with ESP8266 ESPHome and Home Assistant
I cant get the orange light to work. Ive cut between the resistors.
Do i need the level shift in the circuit? Or can i just connect directly like in vcc grounds tutorial?
Thanks
2 Likes
My vindriktning from time to time reading value over 100ppm and staying around that value forever. I have to unplug and plug my usb C cable to make it read normally again. Restarting the Tasmota won’t solve the problem. Anyone experienced such problem?
2 Likes
Just upgraded to HA Core 2022.11.1 and getting the following warning in HA log:
Logger: homeassistant.components.homeassistant.triggers.numeric_state
Source: components/homeassistant/triggers/numeric_state.py:134
Integration: Home Assistant Core Integration (documentation, issues)
First occurred: 15:03:00 (1 occurrences)
Last logged: 15:03:00
Error initializing ‘websocket_api’ trigger: In ‘numeric_state’ condition: unknown entity sensor.ikea_vindriktning_pm25
Everything seems to be working but how to get rid of it?
Update: Did not change anything but error had disappeared.
Got a lot of these on many esphome since last update (ha ans esphome are up to date) too. Not sure it’s related to Ikea’s one.
Every few hours my automations which control my ventilation are seems to be getting weird values from my Ikea/esp combo which trigger them to run.
I have 4 automations, 2 of them are for lowering the speed and 2 of them to up the speed.
the trigger is a numeric value (from the Vindriktning).
The weird glitch always trigger the automations in 2 pairs, or the both “up” speed automations are triggered or the both “down” speed automations are triggered.
Just a few minutes ago I had two automations trigger the “down” pair again at the same time:
alias: Afzuiging bar oranje naar groen
description: >-
Afzuiging bar gaat naar 8% of 29% wanneer de luchtkwaliteit goed is (<36
groen) en de cinema <1000 ppm
trigger:
- platform: numeric_state
entity_id: sensor.ikea_vindriktning_pm25
for:
hours: 0
minutes: 1
seconds: 0
below: 36
condition:
- condition: numeric_state
entity_id: sensor.espsensor_co2
below: 1000
action:
- if:
- condition: numeric_state
entity_id: sensor.espsensor_co2
below: 800
then:
- delay:
hours: 0
minutes: 0
seconds: 3
milliseconds: 0
enabled: true
- service: script.turn_on
data: {}
target:
entity_id: script.blower_off
else:
- delay:
hours: 0
minutes: 0
seconds: 3
milliseconds: 0
enabled: true
- service: script.turn_on
data: {}
target:
entity_id: script.ventilation_29
mode: single
and
alias: Afzuiging bar rood naar oranje
description: "Afzuiging bar gaat naar 47% of 74% wanneer de luchtkwaliteit oranje je wordt "
trigger:
- platform: numeric_state
entity_id: sensor.ikea_vindriktning_pm25
for:
hours: 0
minutes: 1
seconds: 0
below: 86
condition:
- condition: numeric_state
entity_id: sensor.espsensor_co2
below: 1400
action:
- if:
- condition: numeric_state
entity_id: sensor.espsensor_co2
below: 1200
then:
- delay:
hours: 0
minutes: 0
seconds: 2
milliseconds: 0
- service: script.turn_on
data: {}
target:
entity_id: script.blower_on_medium
else:
- delay:
hours: 0
minutes: 0
seconds: 2
milliseconds: 0
- service: script.turn_on
data: {}
target:
entity_id: script.ventilation_74
mode: single
They run exactly at the same time (18:31:39), if I check the history graph from the sensor:
There is always a gap during this “trigger moment”.
Changed the state time in the trigger to “2 minutes” but that didn’t help.
Also changed the following in the sensor setting:
From:
sensor:
- platform: pm1006
pm_2_5:
name: "Ikea Vindriktning PM25"
filters:
- sliding_window_moving_average:
window_size: 10
send_every: 10
to:
sensor:
- platform: pm1006
pm_2_5:
name: "Ikea Vindriktning PM25"
filters:
- sliding_window_moving_average:
window_size: 50
send_every: 10
send_first_at: 10
But that didn’t help.
Anybody got some hint how to fix this? Want to get rid of these ghosts triggers.
Your conditions and triggers are overlapping in the two automations.
Look at the timeline of the automation to see why they triggered and you will understand it.
For the second automation you should add at least and above somewhere.
You mean the <36 trigger is also part of the <86 value? So I always have to have an above and below value?
It should trigger only once when goes below 86 (crossing) or goes below 36 (crossing), but my guess the for statement for 1 minute changes something in the trigger which causes it to work like a condition.
Check the traces of the automations! And you will see why it triggers.
Ok, I see what is the actual problem. It triggers, because it detects a crossing and both triggers, because both crossing happens.
Do you see that non continuous line of your data, where you have that hole, you receive something else, but not a value, maybe it goes unavailable or something and as it comes back, it declares it as a change below 36 and below 86 obviously and both triggers.
1 Like
Thanks a lot, changed the middle “orange” automation with an above and below value:
alias: Afzuiging bar oranje
description: >-
Afzuiging bar gaat naar 47% of 74% wanneer de luchtkwaliteit (36-85 oranje) en
cinema co2 lager 1400
trigger:
- platform: numeric_state
entity_id: sensor.ikea_vindriktning_pm25
for:
hours: 0
minutes: 0
seconds: 30
above: 35
below: 86
condition:
- condition: numeric_state
entity_id: sensor.espsensor_co2
below: 1400
action:
- if:
- condition: numeric_state
entity_id: sensor.espsensor_co2
above: 1200
below: 1400
then:
- service: script.turn_on
data: {}
target:
entity_id: script.ventilation_74
else:
- service: script.turn_on
data: {}
target:
entity_id: script.blower_on_medium
mode: single
And I think you are right, it was probably receiving a value which triggered both those automations.
I’m now curious if the “bogus value” will not trigger the “orange” automation and keep the ventilation running to high when not needed (green condition).
You should use above 36. It still overlaps between 35.1 and 35.9 (including those).
And it will just trigger the one which trigger is valid, so probably the below 36. Make sure that it doesn’t receive bogus values. Are you using MQTT or how it reports the values? You should look at the device level what state it was in for that period of time.
I’m using zero decimals in the ESP config, so i always get round numbers. So I think i need
<36 green
>35 <86 orange
>85 red
Using the ESPHome integration for these sensors, not MQTT.