AC2889/10 no longer working

[xxcite]

I was using py-air-control for some months to control my AC2889/10 without problems. Since today it does not work any longer although I have changed absolutely nothing. I can switch on and switch off the air purifier using

airctrl --ipaddr 192.168.0.84 --protocol coap --pwr (0|1)

But when calling airctrl --ipaddr 192.168.0.84 --protocol coap I now get the following almost on every call:

2021-07-05 13:44:32,524 - MainThread - coapthon.layers.messagelayer - DEBUG - send_request - From None, To ('192.168.0.84', 5683), None-None, POST-kR, [Uri-Path: sys, Uri-Path: dev, Uri-Path: sync, ] A0852A76...8 bytes
2021-07-05 13:44:32,525 - MainThread - coapthon.client.coap - DEBUG - send_datagram - From None, To ('192.168.0.84', 5683), CON-49660, POST-kR, [Uri-Path: sys, Uri-Path: dev, Uri-Path: sync, ] A0852A76...8 bytes
2021-07-05 13:44:32,526 - Thread-1   - coapthon.client.coap - DEBUG - Start receiver Thread
2021-07-05 13:44:32,527 - MainThread-Retry-49660 - coapthon.client.coap - DEBUG - retransmit loop ... enter
2021-07-05 13:44:34,837 - MainThread-Retry-49660 - coapthon.client.coap - DEBUG - retransmit loop ... retransmit Request
2021-07-05 13:44:34,837 - MainThread-Retry-49660 - coapthon.client.coap - DEBUG - send_datagram - From None, To ('192.168.0.84', 5683), CON-49660, POST-kR, [Uri-Path: sys, Uri-Path: dev, Uri-Path: sync, ] A0852A76...8 bytes
2021-07-05 13:44:37,532 - MainThread-Retry-49660 - coapthon.client.coap - WARNING - Give up on message From None, To ('192.168.0.84', 5683), CON-49660, POST-kR, [Uri-Path: sys, Uri-Path: dev, Uri-Path: sync, ] A0852A76...8 bytes
2021-07-05 13:44:37,534 - MainThread-Retry-49660 - coapthon.client.coap - DEBUG - retransmit loop ... exit
2021-07-05 13:44:37,535 - Thread-1   - coapthon.client.coap - DEBUG - Exiting receiver Thread due to request
Traceback (most recent call last):
  File "/home/pi/.local/bin/airctrl", line 10, in <module>
    sys.exit(main())
  File "/home/pi/.local/lib/python3.7/site-packages/pyairctrl/airctrl.py", line 448, in main
    c = CoAPCli(device["ip"], debug=args.debug)
  File "/home/pi/.local/lib/python3.7/site-packages/pyairctrl/airctrl.py", line 15, in __init__
    self._client = CoAPAirClient(host, port, debug)
  File "/home/pi/.local/lib/python3.7/site-packages/pyairctrl/coap_client.py", line 80, in __init__
    self._sync()
  File "/home/pi/.local/lib/python3.7/site-packages/pyairctrl/coap_client.py", line 96, in _sync
    raise Exception("sync timeout")
Exception: sync timeout

But this does not happen on every call. A small number of calls (roundabout 1 of 20) succeed and return the correct status:

[name]                        Name: Luftreiniger
[type]                        Type: AC2889
[modelid]                     ModelId: AC2889/10
[swversion]                   Version: 1.0.7
[range]                       range: Comfort
[Runtime]                     Runtime: 0.84 hours
[WifiVersion]                 WifiVersion: AWS_Philips_AIR@64.3
[ProductId]                   ProductId: be10acb2e62411e8a1e3061302926720
[DeviceId]                    DeviceId: 47bf972690a911eb8f480aa926c8d24c
[StatusType]                  StatusType: status
[ConnectType]                 ConnectType: Online
[om]                          Fan speed: 0
[pwr]                         Power: OFF
[cl]                          Child lock: False
[aqil]                        Light brightness: 100
[uil]                         Buttons light: ON
[mode]                        Mode: allergen
[pm25]                        PM25: 4
[iaql]                        Allergen index: 1
[aqit]                        Air quality notification threshold: 7
[ddp]                         Used index: IAI
[fltt1]                       HEPA filter type: NanoProtect Filter Series 3 (FY2422)
[fltt2]                       Active carbon filter type: NanoProtect Filter AC (FY2420)
[fltsts0]                     Pre-filter and Wick: clean in 233 hours
[fltsts1]                     HEPA filter: replace in 4313 hours
[fltsts2]                     Active carbon filter: replace in 1913 hours

Is this a known problem and there is a solution for that?

[Setcover]

I can confirm this issue.

AFAIK: Philips released a new firmware version which installed without user interaction.
My last FW version was 62.1 the new FW version is 64.3
You can check your FW version by selecting your air purifyer in the app -> wrench symbol top right corner -> scroll down and click "diagnostics via e-mail" it will create an e-mail (but not send it) where you can find "Firmware Version".

If anybody could give me any hint how to decode the new interaction. Help would be much appreciated.

My router supports packet capture and exporting to wireshark compatible file type. But i have no idea what to do from there on.

Best regards, Peter

[Setcover]

TL;DR: Proposed hotfix at the end.

Unfortunately i have no aircleaner remaining with FW 62.1, the FW update on the last one started while i was starting troubleshooting hours ago (that's why i know the old FW was 62.1) so i have no way to know how the messages looked like while everything was working. However i can compare airctrl to the smartphone app.

In advance, please note the last ip.addr block of my devices:

• 136 = my smartphone
• 140 = raspberry pi running airctrl
• 151 = Philips aircleaner
• packages sent by the aircleaner (151) are highlighted green
• i assume (without knowing) CoAP messageID's are meant to be in increasing order -- packages are therefore sorted by messageID

Using airctrl to change the mode (/sys/dev/control) does work.
Getting the new status does not work (/sys/dev/status). Airctrl does send /sys/dev/status without token and never gets an answer with corresponding MessageID. Successful control commands marked dark green, unsuccessful status commands marked red.

Comparing the behaviour to the smartphone app, the status request is sent with token but there is again no answer with corresponding MessageID.
I get the feeling the problem is: "the aircleaner simply does not respond to status requests but instead answers to really old status requests" ... notice those "Retransmissions".

To me it looks like Philips screwed up some queue handling... but again i have no aircleaner with old firmware to compare to.

If somebody wants to see the same packet snapshot sorted by time, starting with the first Message with MessageID 638 it looks like this:

I also noticed the aircleaner is no longer listed as "MICO" in my router but instead "mxchip".

I propose to implement a hotfix solution that, regarding /sys/dev/status, ignores the MessageID but instead accepts any message containing /sys/dev/status (and maybe /sys/dev/info).

Best regards, Peter

[Olgidos]

Fortunately, I blocked internet access for the cleaner some weeks ago and I still have the FW 62.1. I have never done such a network analysis, but if you could step me through, I would like to provide the data for the old firmware.

[Setcover]

1. You have to acquire a package capture. If you do not use a fritzbox router you have to google how to capture packages on your router or within linux running your airctrl script. If your router is a fritzbox go to http://fritz.box/support.lua and login, scroll down to "Paketmitschnitte" and click the link, scroll down to "WLAN" and click "Start" in the row containing "2.4 GHz". A download will start, save it to your disk.
2. execute your airctrl command (in my case airctrl --ipaddr 192.168.6.151 --protocol coap )
3. click "Stopp" in your fritzbox browser window, the download will stop
4. if you don't have wireshark: download and install it, you do not need any of those package sniffing drivers wireshark could install
5. open the downloaded file in wireshark
6. apply a suitable filter by specifying the ip address of your aircleaner and your airctrl running machine, (in my case it was ip.addr == 192.168.6.151 && ip.addr == 192.168.6.140 )
7. left click any coap package, left klick (or double click??) to expand "Constrained Application Protocol ...", right click on the Message ID, left klick "Apply as Column" (Als Spalte anwenden) now you can sort by Message ID by clicking on the corresponding column label
8. to color the aircleaner when it is sending: click "view" -> "Coloring Rules..." -> "+" in the bottom left corner, name it however you want to, as filter add "ip.src == 192.168.6.151" (replace the ip address with the ip address of your aircleaner), hit enter, highlight the row containing the new rule, click "Background" in the bottom left corner and choose a color that is not light blue, hit "OK" to close the color selection window, hit "OK" to close the Coloring Rules window.
9. make sure your messages are sorted by message id, look for a /sys/dev/sync with a /sys/dev/sync response from your aircleaner followed by a /sys/dev/status from your airctrl and then ....... the package we are looking for. I highlighted two unsuccessful examples for you
10. post a screenshot of the result

What ever you do, do not post the package capture file itself to the internet, it contains ANYTHING transmitted by WLAN in the regarding timeframe.

Best regards, Peter

P.S.: I really hope you don't hit a roadblock at step 1

[NikDevx]

I have the same error from yesterday.
AC3829/50

airctrl --ipaddr 192.168.0.10 --protocol coap
Unexpected error:'NoneType' object has no attribute 'payload'
Give up on message From None, To ('192.168.0.10', 5683), CON-61742, GET-None, [Uri-Path: sys, Uri-Path: dev, Uri-Path: status, Observe: 0, ] No payload

I think philips updated firmware and something was changed.

[Olgidos]

All right, I did this packet sniffing, thanks for this awsome tutorial! Sorry, that it took some days, i was a little bit busy and needed to reset my linux :/

Here my snapshot of the sync

if you require further information please give me feedback :)

[NikDevx]

My snapshot of the sync

[ThumbGen]

I have the same error from yesterday.
AC3829/50

airctrl --ipaddr 192.168.0.10 --protocol coap
Unexpected error:'NoneType' object has no attribute 'payload'
Give up on message From None, To ('192.168.0.10', 5683), CON-61742, GET-None, [Uri-Path: sys, Uri-Path: dev, Uri-Path: status, Observe: 0, ] No payload

I think philips updated firmware and something was changed.

Yes, indeed, my AC1214/10 started to show the same error, right after performing the firmware update (WiFi WPA3).

[roscarraig]

I've been in the same situation, on the new firmware and I lost local control most of the time (it would occasionally work), so I took a closer look. It seems the requests are timing out so increasing the hard-coded timeouts to 10s in coap_client (and adding a timeout argument on line 177) restores operation for me.

[NikDevx]

I've been in the same situation, on the new firmware and I lost local control most of the time (it would occasionally work), so I took a closer look. It seems the requests are timing out so increasing the hard-coded timeouts to 10s in coap_client (and adding a timeout argument on line 177) restores operation for me.

Can you show what did you added?

[roscarraig]

The first couple of lines were just some trailing whitespace which was triggering syntastic, but the remainder is the relevant part:

index 9d5b142..d2f76eb 100644
--- a/pyairctrl/coap_client.py
+++ b/pyairctrl/coap_client.py
@@ -83,15 +83,15 @@ class CoAPAirClient(HTTPAirClientBase):
     def __del__(self):
         # TODO call a close method explicitly instead
         if self.response:
-            self.client.cancel_observing(self.response, True)        
-        self.client.stop()        
+            self.client.cancel_observing(self.response, True)
+        self.client.stop()
 
     def _create_coap_client(self, host, port):
         return HelperClient(server=(host, port))
 
     def _sync(self):
         self.syncrequest = binascii.hexlify(os.urandom(4)).decode("utf8").upper()
-        resp = self.client.post("/sys/dev/sync", self.syncrequest, timeout=5)
+        resp = self.client.post("/sys/dev/sync", self.syncrequest, timeout=10)
         if resp:
             self.client_key = resp.payload
         else:
@@ -145,7 +145,7 @@ class CoAPAirClient(HTTPAirClientBase):
         try:
             request = self.client.mk_request(defines.Codes.GET, path)
             request.observe = 0
-            self.response = self.client.send_request(request, None, 2)
+            self.response = self.client.send_request(request, None, 10)
             encrypted_payload = self.response.payload
             decrypted_payload = self._decrypt_payload(encrypted_payload)
         except WrongDigestException:
@@ -174,7 +174,7 @@ class CoAPAirClient(HTTPAirClientBase):
                 }
             }
             encrypted_payload = self._encrypt_payload(json.dumps(payload))
-            response = self.client.post(path, encrypted_payload)
+            response = self.client.post(path, encrypted_payload, timeout=10)
             if self.debug:
                 print(response)
             return response.payload == '{"status":"success"}'

Ideally, I'd suggest using a defined constant but I thought I'd see what people thought before proposing something more concrete.

[NikDevx]

The first couple of lines were just some trailing whitespace which was triggering syntastic, but the remainder is the relevant part:

index 9d5b142..d2f76eb 100644
--- a/pyairctrl/coap_client.py
+++ b/pyairctrl/coap_client.py
@@ -83,15 +83,15 @@ class CoAPAirClient(HTTPAirClientBase):
     def __del__(self):
         # TODO call a close method explicitly instead
         if self.response:
-            self.client.cancel_observing(self.response, True)        
-        self.client.stop()        
+            self.client.cancel_observing(self.response, True)
+        self.client.stop()
 
     def _create_coap_client(self, host, port):
         return HelperClient(server=(host, port))
 
     def _sync(self):
         self.syncrequest = binascii.hexlify(os.urandom(4)).decode("utf8").upper()
-        resp = self.client.post("/sys/dev/sync", self.syncrequest, timeout=5)
+        resp = self.client.post("/sys/dev/sync", self.syncrequest, timeout=10)
         if resp:
             self.client_key = resp.payload
         else:
@@ -145,7 +145,7 @@ class CoAPAirClient(HTTPAirClientBase):
         try:
             request = self.client.mk_request(defines.Codes.GET, path)
             request.observe = 0
-            self.response = self.client.send_request(request, None, 2)
+            self.response = self.client.send_request(request, None, 10)
             encrypted_payload = self.response.payload
             decrypted_payload = self._decrypt_payload(encrypted_payload)
         except WrongDigestException:
@@ -174,7 +174,7 @@ class CoAPAirClient(HTTPAirClientBase):
                 }
             }
             encrypted_payload = self._encrypt_payload(json.dumps(payload))
-            response = self.client.post(path, encrypted_payload)
+            response = self.client.post(path, encrypted_payload, timeout=10)
             if self.debug:
                 print(response)
             return response.payload == '{"status":"success"}'

Ideally, I'd suggest using a defined constant but I thought I'd see what people thought before proposing something more concrete.

I ping airtctl 10 times and 2 times I got Unexpected error:'NoneType' object has no attribute 'payload'
I changed to 15 sec timeout and 10 times ping airtctl and got 0 error.

Thanks.

[michaelschefczyk]

Both changes seem to go into the right direction (thanks!!). Nevertheless, I found more timeouts than before. I use the connection to (a) change the level based on time of day and (b) track air quality via FHEM. As I send the change command three times in a row, that seems to be more stable. Tracking misses many data points, unfortunately.

[TravisWilder]

FYI .. timeout with 60 does not help on my new Model: AC2889/10 (AC2889/10)
Device Version: 1.0.7

[mbirnbacher]

Same problem here with the AC2939/10 and Firmware 64.3.