Flush output when observing

[Setcover]

Status-observe will work on console but not when the output is piped to something else. Flushing forces the output out of buffer so piping will work as expected.

see rgerganov/py-air-control#93
and #4

[hundehausen]

I support this :D

[GSzabados]

@betaboon, can we give this a go as a beta or something? As it mentioned in the OP, in the other reference, Philips has pushed out a firmware update which breaks the connection with the device, it does respond to commands, but the status update is not working after a while.

I have the new firmware since a few days, and I hate that they broke the normal way how the device sent updates.

The latest firmware version is 64.3 which does this issue.

[Setcover]

If you want to use / try my fix, you can install it with:
pip3 install -U git+https://github.com/Peter-J/aioairctrl

[GSzabados]

If you want to use / try my fix, you can install it with: pip3 install -U git+https://github.com/Peter-J/aioairctrl

Thanks, I might going to give it a try. But I am not sure anymore that this is the fix for my issue.
I am using @betaboon's integration in Home Assistant which uses aioairctrl to communicate with the device. And it was working well since the last release update of aioairctrl. It received all the messages with the device and handled them well in Home Assistant.
Since the firmware update on the device, it stopped working as expected. It receives all the messages until some point, probably the point where the messages starts to repeat because of the not changing values, I guess, and from that point it does not update anymore. It doesn't matter that commands sent, what received and acted on, or just any status updates. The details of the device are not updated anymore in Home Assistant.

Would it solve this issue?

[GSzabados]

The other worrying thing in this firmware update, that comments from different people that they are unable to add the device back to the Wifi network and to the Home Care/Air Matters app.

[ronaldt80]

Thanks @peter-j! I changed the manifest file of the air purifier referencing to your update. After a hard reboot of Hass OS my purifier (ac2889) now runs without issues for nearly 3 days. Also the "handshake issue" appears to have disappeared!

[GSzabados]

now runs without issues for nearly 3 days.

I can confirm as well that it solved the firmware 64.3 issue, and it survived a wifi restart as well. Just to reiterate, I have restarted my WiFi network and it survived. For power outages the integration has to be patched to be able to reload.

@betaboon can this PR be merged?

[ronaldt80]

@GSzabados - when my purifier is off and HA restarts it does not show up in HA. If however during a reboot of HA the purifier is turned on an entity is created in HA. Do you have a similar experience? If not, how did you solve?

[GSzabados]

Do you have a similar experience?

Actually no, because my purifier is always on. But that should be fixed by an some extra code in the integration to have a unique id for the device and be able to reload the integration. There is another "fix" for that as well, let me search for that conversation and get back to you.

[GSzabados]

@ronaldt80, I see that you were discussing the issue there as well.

betaboon/philips-airpurifier-coap#57

This forced reconnect would be a solution for the issue what you have mentioned. But the cleanest would be the reload integration with unique id.

[ronaldt80]

@GSzabados - I will try that solution. Mistook this to be a different issue (eg. power outage of the purifier whilst HA is running).

On the point of a unique id, the entity is setup to get a unique id right?

    async def init(self) -> None:
        self._client = await CoAPClient.create(self._host)
        self._observer_task = None
        try:
            status = await self._client.get_status()
            device_id = status[PHILIPS_DEVICE_ID]
            self._unique_id = f"{self._model}-{device_id}"
            self._device_status = status
        except Exception as e:
            _LOGGER.error("Failed retrieving unique_id: %s", e)
            raise PlatformNotReady

[GSzabados]

@ronaldt80

betaboon/philips-airpurifier-coap#28 (comment)

And I was a bit mislead, it needs a config entity to be able to reload.

[GSzabados]

I am so disappointed that this issue sits here for 5 months and the fix works for everyone who implemented it, but the codeowner still hasn't bothered to reply to the topic or to merge the PR, meanwhile actively developing other projects....

At least would give write access to other people to carry on with the development.

[Setcover]

As much as i understand your disappointment, this is open source, there is no obligation to serve us, there is no money made in serving us and in the end everybody has only a finite amount of time each day and still has to make a living to pay bills.

Just have a look at the forks
https://github.com/betaboon/aioairctrl/network/members
and hope one of those works for you, or fork it yourself and fix it if you can.

[GSzabados]

As much as i understand your disappointment, this is open source, there is no obligation to serve us, there is no money made in serving us and in the end everybody has only a finite amount of time each day and still has to make a living to pay bills.

This is not about the service, but at least look at it and say a word if someone would like to add a fix to your code.

Staggered forks are not really a solution, and really that is the main problem with any custom_component. If it is merged to Core, then there are more people able to work on it together and someone oversees the work as well. Of course it has downsides as well, as it has to fit to he development path as well...

Anyhow, just my 2 cents...