Thank you 
Try restart the fan. Any charges?
If not Try restart HA.
At the end I used the repository from @kongo09
But I can tell you that the warning is present in all the repositories I found linked to this 3d.
At the beginning I wasnât able to get the purifier on HA, so I tried everythingâŚ
Regarding the warning I could think that home assistant generate the warning because it could need a features that the purifier should provide or simply because the add on creates an entity without a device⌠I donât know, I am a programmer but I am new of python and home assistantâŚ
So I cannot help in thisâŚ
EDIT: Just saw that your repository is different⌠maybe I missed it during my tests⌠can it work with coap or it is only for http?
I can see the line in @kongo09 repository that I have fixed. The warning started with HA 2021.4 and now 2021.12 its an error.
In your respository you will have this code in fan.py at line 479:
def device_state_attributes(self) -> Optional[Dict[str, Any]]:
change it to:
def extra_state_attributes(self) -> Optional[Dict[str, Any]]:
No more error, hopefully! =)
I quickly changed this in my repo. Hope this eliminates the warning.
This is a real pain. Mine are unavailable most of the time. The integration is essentially broken since Philips did a firmware update over-the-air. Iâm not the maintainer of the integration and lack the skill to fix it.
The error is gone, but I got othersâŚ
/usr/local/lib/python3.9/site-packages/aiocoap/transports/udp6.py:525
This is the folder where the file is:
pi@domotica:/ $ docker exec -it home-assistant sh
/config # cd /
/ # python --version
Python 3.9.7
/ # ls /usr/local/lib/python3.9/site-packages/aiocoap/
__init__.py credentials.py interfaces.py meta.py optiontypes.py protocol.py resourcedirectory util
__pycache__ defaults.py message.py numbers oscore.py proxy tokenmanager.py
cli error.py messagemanager.py options.py oscore_sitewrapper.py resource.py transports
/ #
I also got these
2022-01-07 18:19:10 ERROR (MainThread) [coap] Connection loss was not expected.
2022-01-07 18:19:10 ERROR (MainThread) [coap] Connection loss was not expected.
As I said, the whole thing is broken and not really maintained.
Not a big problem, the device work to me.
I thought that wasnât an issue to fix that alarm, as already said I am not an expert of python programming
Anyway thank you 
If your purifier model requires the http api and you have some trouble with your device, you can try my fork. I fixed some issues and improved the state consistency for my AC3829/10. Maybe this works for all http models. If not it would be hard for me to fix things, i can not see on my own device.
Important: There are breaking changes included!
I am a little bit off topic but do someone knows if it is possible to disable the sound when the device is powered on or when the mode is changed?
I planned an automation that checks the air quality and start the machine in automatic (during the day) or in sleep (at night) but the sound it make is very noisy especially during the nightâŚ
I donât think thatâs possible. Iâve never seen that and the original apps also donât allow this.
Thank you⌠maybe there is some hidden button combination to press for disable itâŚ
Even if, even in manual I didnât found anything 
Even in sleep mode the chime will play if the timer turns the device off which can be really annoying. I plan on just clipping the beeper after the guarantee has run out.
I havenât seen the board yet so this might be neither feasible nor straight forward.
Please keep in mind that opening and manipulating electric devices is risky and may result in death.
on most buzzers there is a small hole on the top; you can put some chewing gum (or playdoh) to dampen the sound
That is my same idea.
I will wait that the warranty will over, maybe in the meantime Philips will release a new firmware able to disable the sound with a boolean option⌠who knowsâŚ
Maybe try to send them an email and ask about it.
Already did it, sent to tech support of my country (Italy), fingers crossed 
HmmâŚi was reading about the CoAP protocol, and i think the issues were having are related to the nature of CoAP being an udp protocol.
It looks like the 1st message is never received while the second is ignored (or something like that)
# Dealing with Lost Messages
Since UDP is unreliable, the CoAP protocol specifies a way to detect lost messages and then retransmit them. For instance, in any of the CON examples above, if an ACK for the initial CON request was not received, after a timeout period the CON request will be resent with the identical message ID and token (see Figure 6).
Figure 6 â CON request message is lost, and resent.
In the case where the original CON request arrived at client 2, but where the CON ACK was lost instead, client 1 will again timeout and resend the original request, as shown in Figure 7.
Figure 7 â CON request arrives, but ACK is lost.
You probably would have to observe the actual traffic flow to understand whatâs going on. Maybe Philips didnât implement the protocol correctly and doesnât attempt a retransmit after timeout?