The IKEA MCU requests six or seven (I forget) readings every 30 seconds. Indeed this then looks very frequent in HA.
Do you mean Wh?
over 4 hours, I’d then expect roughly 2Wh. 0.5178 W average looks right to me.
I use a median of three values according to this Sensor Component — ESPHome, with a delta of 1.0. Doesn’t spam HA and still updates fast when the value change.
No. It’s the average consumed power, not consumed energy for a 4 hour time frame.
Using the median doesn’t increase your resolution, but will just use a random value of those recorded.
The reason you do a sliding average is, that the sensor can only pickup small amounts of air. So it’s fluctuating a lot if there’s some wind in the room, as it gets more and less air through the sensor.
To get an accurate reading you want to smooth out those short time effects and get the particular matter for a larger quantity of air.
Using 50 values and sending the update every 10 seconds will have it still react very quickly to changes but keeps it stable if there’s no change.
Here’s my graph for today, as you can see even extemely large changes are no issue:
For me the issue with my three sensors were sudden spikes, which obviously wasn’t caused by worse air quality but some faulty measurements, so I wanted to get rid of the outliers, not just smoothing them out.
Okay, but that’s not what you wrote initially - you wrote that you use median to not spam HA but get fast value changes.
Median isn’t the right tool to achieve that.
It’s kind of strange that you get spikes like that, haven’t seen anything similar with my unit and would still assume that the values are correct, maybe the fan just kicks up some dust from time to time or the fan collected some dirt on the fan blades which falls back into the sensor when it turns off?
Anyway, yes median is able to filter out outliners. But I would stack a sliding average over the output anyway, to avoid that you send flickering values in short succession to HA, but instead combine those values to get more precision.
I use the median in combination with a delta of 1.0, Sensor Component — ESPHome so the difference between last sent value and the new value being sent to HA need to be at least 1.0 to avoid the flickering.
Has anyone got a mod to quieten down the fan? I can hear mine from about a meter away spinning up. Don’t think it’ll be usable in a bedroom as I’m sure the fan spinning up will keep me awake.
Had the same issue. It was an annoying sound in our living room. I connected the + (red wire) from the fan to the 3.3v from the Wemos. The GND (black wire) is still connected to the original connector.
In this way the fan is still controlled by the IKEA PCB, but at a lower voltage (and speed).
Don’t know if this will impact measurement…
Can you please explain your logic here?
I wanted to connect the fan to 3.3v, to reduce noise; as described by Hypher.
I only reconnected the + / red wire to 3.3V.
Later on I discovered that the fan was still turning on/off (which was not my objective ). It appears that the fan is controlled via it’s GND connection
I can imagine that a lower fan speed will result in a lower air flow. Might result in the sensor seeing less particles per unit of time; measured values might be lower than 5V fan.
But because the measurements seems to be optimistic (see post 72 in this thread), I don’t think the lower fan speed should be an issue.
Thanks! That drawing explains a lot. Interesting solution with the transistor. Everyone would think the opposite way, I guess.
@sermayoral, have a look at this:
https://mobile.twitter.com/horcicaa/status/1415298890950119426/photo/1
Sad. Would be cool to get PM10 and PM1 measurements, too. Can we plot them to confirm that these don’t contain useful informations?
Can we plot them to confirm that these don’t contain useful informations?
Adding an export for them, clearly marked as ‘unknown value’, would be a small change to the driver. I’ll think about it (of course, anybody else is free to PR such a change as well!)
Thanks Habbie.
Anyway, here’s my config which also exports the power consumption and enables the Vindriktning to be shown properly in the Energy Monitoring:
uart:
rx_pin: D2
baud_rate: 9600
sensor:
- platform: pm1006
pm_2_5:
name: "$friendly_name"
accuracy_decimals: 2
filters:
- sliding_window_moving_average:
window_size: 50
send_every: 10
send_first_at: 10
- platform: template
name: "$friendly_name - Power Usage"
id: power_consumption
device_class: power
state_class: measurement
unit_of_measurement: W
accuracy_decimals: 4
filters:
- heartbeat: 60s
- platform: integration
name: "$friendly_name - Consumed Energy"
sensor: power_consumption
time_unit: 'h'
device_class: energy
state_class: total_increasing
unit_of_measurement: 'Wh'
restore: false
integration_method: left
interval:
- interval: 1min
then:
- sensor.template.publish:
id: power_consumption
state: 0.5696
The power consumption is what I measured earlier plus 10% inefficiencies for the power supply.
You managed to figure out how to control the LED’s from ESP ?
No, sadly not.
You managed to figure out how to control the LED’s from ESP ?
Have a look at the post above. It has a link to Twitter where you can find a sketch of the PCB and you will find the LEDs as well on that.
I wanted to connect the fan to 3.3v, to reduce noise; as described by Hypher. I only reconnected the + / red wire to 3.3V. Later on I discovered that the fan was still turning on/off (which was not my objective ). It appears that the fan is controlled via it’s GND connection I can imagine that a lower fan speed will result in a lower air flow. Might result in the sensor seeing less particles per unit of time; measured values might be lower than 5V fan. But because the measurements s…
Other option, you can disconnect the PCB from the sensor and you can feed the “appropriate” UART messages to the PCB from the ESP to control the LEDs. For color changes refere to the manual. You just need to send UART messages according the color what you want to display.