This repository has been archived by the owner on Dec 14, 2022. It is now read-only.
AC2729: initial support #4
Comments
|
Thanks! I will test it tomorrow and give feedback :) |
|
Doesn't really work for me. There is no "on/off" switch and the developer tools say: state unavailable. I've set the log to DEBUG but there is nothing special to be seen. HA reports my other fan in regular intervals. The AC2729 is reported only once at the beginning: |
|
@kongo09 could you try enabling the debug-logging for logger:
logs:
custom_components.philips_airpurifier: debug
coap: debug |
|
@kongo09 i just added a so could you please post the output of: source aioairctrl-shell.sh
aioairctrl --host $DEVICE_IP --debug status-observe --json |
|
Here is the complete log showing both fans. The problematic one is |
|
I'll take a look at it tomorrow ;) |
|
Here comes the output of aioairctrl: it then goes on and keeps repeating itself. |
|
this is interesting. the device seems to have a buggy CoAP-implementation: you see how the request that is being sent contains right now I'm unsure how to overcome this. |
|
@kongo09 i just pushed a commit that help with this issue. |
|
Hm, I have actually no idea about the CoAP protocol. The fact that the AirMatters remot app works can only mean that this is either specific to the local interface or the app ignores the ACK - if that is possible in the protocol. I once had a problem with a firmware update and through mailing the support in the end got hold of one of the guys from AirMatters who was very helpful. I could try to reach out to him again and maybe connect you two? |
HACS doesn't show any update? |
|
@kongo09 should be available by now |
|
Hm, still problematic. The speed settings seem to work but not the on/off switch. When I switch it off, HA puts the toggle back on as it doesn't realize that it went off. Consequently, I cannot switch it back anymore as HA believes it is already on. When I set the speed to something different, it actually goes back on with the right speed setting. So communication is somehow working but not for the on/off setting. |
|
Just tried it with my airpurifier:
but hey, anyway a great step forward! thanks a lot for your work @betaboon :) |
regarding the on/off:
|
|
@nicx i just pushed reading of filter-values |
|
Tricky beast. Right now, I can change all fan-speed settings in HA and they're reflected correctly on the device. So I cannot confirm the observation of @nicx concerning the auto mode. What remains weird is the on/off switch. Clicking the toggle switches the devices off, but the toggle comes back on. The fan-speed setting remains on auto and doesn't go to off, what I would expect. However, when I switch the device just with the fan-speed selector ignoring the on/off switch, it functions as a workaround. So setting fan-speed to off switches the devices off. Setting it back to, e.g., auto switches the device back on and to auto. The toggle stays unaffected the whole time. Do you in your code actually treat the toggle switch different from setting fan-speed to off? |
|
i just pushed services for:
it would be great if you could test it :) |
yes there is a minor difference: it considers the state of the device. but as mentioned in #6 a debug-log of that situation would help the most. |
here is the output: device on and running: device turn "off" via HA (and yes, its really off, but the HA switch remains "on"): |
|
Thanks for your fast development @betaboon, that's really lightning-fast :)
|
|
@nicx i just pushed the water-level reading. thanks for bringing that up. totally overlooked it |
|
on the auto-mode: you could set the auto-mode using the app or on the device and then read the status. the code currently uses |
|
on the on-off issue: could you repeat the same procedure but provide a debug-log of HA additionally ? |
hm unfortunately this commands are not working for me: |
|
@nicx oh sorry. the |
|
ah I just need to cur off the parameter "--json". so here ist the output: aioairctrl --host $DEVICE_IP --debug set mode=P aioairctrl --host $DEVICE_IP --debug set pwr=1 mode=P |
|
did both commands successfully enable auto-mode ? |
|
just in addition, maybe it helps finding the problem: when the purifier is off an I use any of these two commands I only get 1 "bing" (the same "bing" when its already running and I will only do a mode change. But I don't get the 3 "bing bang bong" when using the command so for me it seems that it only powers on correctly when not using any mode parameter in addition. Is that possible? |
yes they apparently did. |
|
Another question regarding the remaining time for all filters: Currently you convert them to a non standard format which is hard to handle in HA automations. The original remaining time is just hours, which is very handy regarding HA scripting. Is there any reason why you convert them to "166 days, 14:00:00"? |
i chose a representation that is human-readable. |
I understand this, but it is not machine readable which should be in my opinion the priority for a HA integration for a sensor. For the UI (and the human readability) it could be converted via templating. But anyway, this are just my two cents ;) |
here is the debug output of aioairctrl: and here the debug output of HA: as already said: the purifier powers off correctly, the switch in HA is turning "off" and jumps back to "on" immediately. |
|
@nicx in the HA-log: how long does it take for a new observation-status to arrive after that ? |
|
@betaboon I waited now for 30 minutes but there is never any new log entry regarding your custom compinent. The HA switch remains "ON" forever ;) |
|
i have a hunch:
can you restart in server-controls and try again. |
|
@betaboon I think we are getting closer: after a reboot it works exactly 1 time, after that it does not work again until the next reboot. Your hunch could be right :) |
|
hm i just tested. |
|
@nicx could you enable debug-logs for |
|
I just generated a fresh log after restart. Now, the AC2729 is not found anymore. The AC2889 is still found. I can ping the AC2729 and the AirMatters app shows it well, so it is connected. the device with 192.168.179.12 is the AC2729 |
sure, here we go: |
|
Now this is crazy. Out of frustration I unplugged the device yesterday and left it off for the whole night. Upon plugging it back in this morning everything started to work. All modes are correct, the on/off switch works as expected. HA catches when I set the device manually or via the AirMatters app - in short: all is good. I've now played with it for some time and it is still good. @nicx can you try the same and see whether there is a pattern? Maybe the thing just confuses itself internally and a power cycle brings it back to its senses. Here is the full log (again including the other device, which is also good): |
Closed
|
@kongo09 I will tray that and unplug it right now :) |
|
I'm going nuts. I left it for itself for the day and just gave it another try right now. And it fails again. On/off switch doesn't reflect the state. I can only switch it back on by using a speed setting. Auto setting stopped working as well. I suspect it died sometime during the day as HA says the last data is from 10 hours ago, while the other device says it is from 15mins ago:
At some point after 12:00 the last message from the AC2729 arrived. After that all quiet, also no errors. The other device keeps sending messages every few minutes. I'll now take the AC2889 out of HA to keep logs cleaner and observe the AC2729 only. |
|
For me the unplug-workaround unfortunately didn't work. Same behavior today after plugging it again: Switching on/off does not work in HA, neither setting mode to Auto. |
|
This morning I thought the device had died - stupid me, it was in a switchable socket. Which means, it was again without power for the night. Switching it back on it works in HA - at least for now. I'll keep observing it. |
|
I have setup an automation that switches the devices on and off every 15mins. It's been running for the last few hours without problems. Not sure what to make of it. Maybe it is just an instable implementation on the device side that dies from time to time. |
|
Some update from my side: the code has been working well now for over a week. Now it starts making problems again and one fan in the log keeps reporting duplication. The state attributes in HA don't reflect the state of the device anymore: I'm not sure what the code logic is here. Are all coap messages checked for uniqueness to prevent double processing? Maybe you could introduce an override flag where duplicate messages are processed nevertheless. Maybe that increases stability at the expense of redundancy? |
|
this is working great. one minor thing: water_level is incorrect. it always shows me: It seems |
|
@arthurgeek for me the water level works. But then again, my device sometimes overall works and sometimes not. The interface is very instable. I think @betaboon did his/her best and it might be down to a buggy Philips implementation. |
|
I'm currently unable to work on this due to personal reasons. regarding the water-level: it seems like the @kongo09 regarding the duplicate-messages: that is taken care of by |
|
Good to hear back from you and thanks for bringing us that far! If there is anything we can do in the meantime to help you out, please let us know. On a totally different side-note, I've developed a nice card interface to take advantage of your work: |
Oh, I see. For me it always displays And thanks again for your work on this! |
|
I also would like to add to @nicx point on remaining time for filter: making it human readable means it's harder to assign any automations to it (for example: be notified when filter needs change). if you're ok with it, I can try to add new attributes with remaining time in hours instead of human readable. |
This was referenced Mar 17, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
this issue is the place to discuss the initial AC2729 support.
references
raw-data (provided by @kongo09): #3 (comment)
cc: @kongo09, @nicx
The text was updated successfully, but these errors were encountered: