This was also my finding, and what I did was, I removed all models that I didn’t have from the repository in order to speed up loading.
I guess this made it load a bit faster, and my AC1214 and AC3829 now load (almost) all the time…
(So I still use the original repository, but just shortened the list of supported models)
The devices have now come back (I didn’t change anything), but are as unreliable as before. My interpretation is:
When they’re not so responsive during HA startup, the integration just doesn’t set them up so they’re gone from the system for good.
When they’re responsive, they’re setup, but that doesn’t mean that they stay live after setup.
As your systems seem to be stabler, I wonder if there is anything different with my devices or with my network setup. One difference could be, that I have two devices in the network. What about you guys?
I’ve taken one device off the network for the last twelve hours. It doesn’t help. The remaining device was stable at first, but then started to drop commands. Interestingly, the state continued to be update but I couldn’t control it anymore. I also tried the command line aioairctrl utility, but while this was observing status updates in the beginning, it stopped reporting updates even before HA stopped receiving updates. Weird.
I have one coap device, other 2 are luckily http operated and are much more stable.
I recognize the issue you refer to. If the device is not recognized during ha restart a manual toggle will work and make it appear. No need for me to then also restart HA again.
I also found that service calls typically also revive the device in ha. I use the scheduler custom integration to control my purifiers (on/off, sleep mode, allergen mode etc). Probably, as this relies on the service calls, that helps keep the communication with HA alive on my side.
I do not get rid of the errors in my log though. 1000’s per day. This is the case since the October updates
Logger: coap
Source: /usr/local/lib/python3.9/site-packages/aiocoap/transports/udp6.py:525
First occurred: 09:15:29 (179 occurrences)
Last logged: 11:33:14
Connection loss was not expected.
Since i am using kongo09’s design i wanna share my solution. I changed a few lines to get it running on my 3033/10. I am using your github respository and i have deleted entity.attributes.function. It feels like randomly adding the following code to your configuration.yaml speeds up the start of the purifier. At least for me.
As of a couple of days/week ago the Philips Airpurifier from Kraineff became a READ-ONLY but I intend to try to keep it alive as long as possible.
I have created a repository on Github for you. This repository is updated, 2021-12-23, to work with 2021.12 without errors for my Philips AC3259/10.
My fan dont have a humidifier so I cant guarantee this will work for you.
This looks strange. Are you using my YAML unchanged or did you tweak it? There was a tiny bug that I fixed some time ago and updated my code, so maybe copy-paste will help?
I did a diff with my yaml and noticed quite a few differences appart from the renamed entity.
You’re using your own icons? I’m not sure if that makes a difference, but it could explain why the icons are not shown on your buttons
The templates have been changed for the humidity_button. Might not make a difference? Or maybe it does?
The whole icon part for the toggle_ac_fan_speed was moved
and some other stuff is modified, moved or changed
Overall, that makes it difficult to judge if the changes introduced a problem. I suggest, you try with the original script first and then step by step adapt it to what you want.
Are there other components or steps necessary to add the purifier to HA?
I followed the “Installation” instructions but the air purifier stays unavailable.
Its an AC2889/10, device firmware version 1.0.7, WiFi Firmware version 68.3.
Yes I did. To be sure I removed the component and configuration and added it once more. Unfortunately the problem persists.
Interestingly Studio Code Server gives me this warning:
But checking the configuration and restarting HA does not result in an error or warning.
After fixing the apparent error to: