I think is somehow related to the pm25 definition as I commented the unit measurement and replace it with blank not null " " to have information in graphs. Otherwise on the picture element it will display also the ug/m3 and don’t know is possible to get rid of this. Try replacing pm25 on trigger with fan.mi_air_purifier_3h and add aqi at attributes instead of defined sensor pm25.
Many,Many thanks for the great work. It works perfectly for me.
I have a small challenge because of the missing unit of measurement for the AQI 2.5. I have several other Dust Particle sensors and I can not graph them in the same history graph and show them in consistent way in the entity cards . It will be good if possible to hide the unit of measurement only for the visualization on the picture element card, but still have unit of measurement. As a workaround I will probably define one more variable with the same value with desired unit of measurement “µg/m3”.
Thank you for the nice work !
Hi @zerg. I had the same challenge but didn’t figure out how to solve it other than remove it. This is how the state label is implemented in Picture elements - value and unit of measurement. You don’t have any possibility to hide or to alter the style of unit. Moreover, if you skip it the history will be represented as bar with colored distinct values so in order to have chart you need to specify the unit of measurement. One dilemmas: how to hide unit of measurement but still to have history of sensor as chart not distinct values, so in the end I have decided to have it blank " ".
For me works to create new template sensor with different name , with exactly the same value, but with unit of measurement. I use the first sensor(without unit of measurement) only for visualization on the card as in your example. The second sensor i use for everything else - for history, graphs, etc…
mi_air_purifier_air_quality_pm25:
friendly_name: "Mi 3H Air quality PM2.5"
value_template: >-
{% if state_attr('fan.mi_air_purifier_3h', 'aqi') == None %}
{{ 0 }}
{% else %}
{{ state_attr('fan.mi_air_purifier_3h', 'aqi') }}
{% endif %}
unit_of_measurement: " "
icon_template: mdi:blur
mi_air_purifier_air_quality_pm25_unit:
friendly_name: "Mi 3H Air quality PM2.5"
value_template: >-
{% if state_attr('fan.mi_air_purifier_3h', 'aqi') == None %}
{{ 0 }}
{% else %}
{{ state_attr('fan.mi_air_purifier_3h', 'aqi') }}
{% endif %}
unit_of_measurement: 'µg/m3'
icon_template: mdi:blur
I think there is a bug in the automation.yaml . It looks like that the Favorite Level should be adjusted every minute by AQI Level in “AP02 - Air Purifier set favorite level based on PM2.5”.
- id: '1234567891012'
alias: AP02 - Air Purifier set favorite level based on PM2.5
description: ''
trigger:
- minutes: '1'
platform: time_pattern
condition:
- condition: state
entity_id: fan.mi_air_purifier_3h
state: 'on'
action:
- data:
speed: Favorite
entity_id: fan.mi_air_purifier_3h
service: fan.set_speed
In this case you have to change the parameter to ‘/1’. Otherwhise the automation is only started when the minute is ‘1’.
Strange syntax at this point 
.
Indeed 
but every minute is too fast, updated to every 5 minute.
BTW - my purifier is reporting PM2.5 every 30 minutes, so maybe also 5 min is to early, 10 or 15 min are more appropriate.
I’m testing a new trigger event. With this code the automation is only started when the purifier sends a new valid AQI.
- id: '1234567891012'
alias: AP02 - Air Purifier set favorite level based on PM2.5
description: ''
trigger:
- platform: state
entity_id: sensor.mi_air_purifier_air_quality_pm25
condition:
- condition: state
entity_id: fan.mi_air_purifier_3h
state: 'on'
- condition: numeric_state
entity_id: sensor.mi_air_purifier_air_quality_pm25
above: '0'
Hi @derwolff. I have also added last night a condition in my automation but didn’t have the chance to test it as the triggering conditions were not met. Your idea seems simpler but let us know once tested.
@schilea and @majkers I had same issue with changing favorite level swithcing to Fan. I solved it by adding a condition to the fan level change update automation, so it will only trigger if the mode is actually currently set to Fan:
- id: '20000000006'
alias: Bedroom Air Purifier fan level update
description: ''
trigger:
- entity_id: fan.bedroom_air_purifier
platform: state
condition:
- condition: state
entity_id: input_select.bedroom_air_purifier_mode
state: Fan
action:
- service: input_number.set_value
entity_id: input_number.bedroom_air_purifier_fan_level
data_template:
value: '{{ state_attr(''fan.bedroom_air_purifier'', ''fan_level'') | int }}'
mode: single
@check could you elaborate on the issues you saw related to your comment:
Due to issues with Mi Air Purifier 2S and 3H sending “None” status when turned off
I have noticed in HA log files many errors connected to something like “Cannot read status: None” when the device (automatically) broadcasted it’s status about fan_speed when it was turned off (purifiers are connected to WiFi and broadcasting even when you turn off the device). The error showed because of automations, of course. As “xiaomi_miio” platform only accepts predefined values (this might change in the future) and “None” was not one of them, the only solution was to make a check about “None” before proceeding with automation execution.
1 Like
Thanks a lot for the details. I also see the automations getting trigged every few tens of seconds even if there is no change in mode. I will try to add your mods of checking if difference to current stats and see if this triggering of the automations stops as well.
With latest implementation from above, I think post 69, there is no need anymore for automations related to fan/favorite level. All the inputs select/number/text are not needed anymore also.
Thanks @schilea, i did not look too much into that as I mistook it for more of a graphical update only, but will look into the details. Thanks for all the great work you have put into this, much appreciated.
Hello everyone. I integrated my air purifier h3 on hassio nice well it works but with delays and disconnections …
I state that I have blocked the connections to their cloud with the firewall I use.
he tries to connect to the cloud for 2 minutes after which he gives up and stays connected to hassio but every now and then he goes offline, I assume he tries the real connection again.
do you have any ideas?
1 Like
I have the exact same problem. I would love to find a solution. Let me know if you know how to solve this.
I believe that if there is no Tasmota-style software we do nothing.
I’ll try another thing tonight about DNS
Its not DNS. ESP or whatever they use there is probably overloaded or they have really messed up the design.
Just try to ping it and you will see. Its not something we can fix externally.
Well i didn’t had this connection issue on the Update June 10th 2020 version
I did a full HA reset after moving from a Synology to a raspberry pi and loaded the Updated December 4th 2020 version.
And now i have the connection issues that i din’t had before.
Is it maybe a raspberry Pi issue?
No, I have a dedicated NUC for HA.
If you ping 3H, you will see those crazy high unstable pings and packet loss.