Invalid fan entity state and its parameters about ha-dyson HOT 28 CLOSED

@Drakulix I guess you are right! Sorry I'm a little busy these days. I'll try to fix it in the next few days.

from ha-dyson.

@shenxn Sorry, my knowledge about Home Assistant is limited in this way. Assuming this: https://www.home-assistant.io/integrations/logger/ I just add this to my config and than find the logs in Supervisor/Core logging?

logger:
  logs:
    libdyson: debug

Yes. After adding this to your yaml configuration, restart your ha and you can find logs under Configuration -> Logs. You may need to click on show all logs to see debug log.

from ha-dyson.

@slyoldfox Version 0.13.0 should have fixed this.

from ha-dyson.

@JakubMacoun you might want to try this out as well.

from ha-dyson.

Another related issue: also state is invalid. Whenever I turn my Dyson off, the state remains as 'on'.

from ha-dyson.

@JakubMacoun is your fan in the "Auto" preset mode by chance when you can't turn it off? If so might be related to #18

Logically it makes sense since the fan is technically still supposed to be on when in Auto but it's not intuitive to remove it from the auto mode to fully shut it down.

from ha-dyson.

@geekofweek I can turn if off, just the state remains as 'on'.

from ha-dyson.

Can you find anything related in log?

from ha-dyson.

That's interesting. I've restarted to clear my logs and now state and oscillating are updating correctly. I'll try to do some more tests to find out when does this happen.
I've also done some more tests involving percentage attribute. It is null only if set to auto speed. If I increase speed manually. it correctly shows percentage value. I'm just not sure if displaying null attributes is valid in HA.

Version 0.5.2.

from ha-dyson.

@JakubMacoun That could be some hard to find bug deep in the code and not easy to reproduce. As for the percentage, currently the official dyson integration also set percentage to null in auto speed. Basically, I just copied the code from the official integration with some modifications. So I guess that is fine.

from ha-dyson.

@geekofweek I can turn if off, just the state remains as 'on'.

Right, that is my point. So it does shut the fan off and the state stays on, which I would agree is desired for Auto mode since it technically isn't ever off. But let's say I want to remove it from Auto mode and actually shut it off. The only way to remove it from Auto mode is to set a fan speed first, then turn off. So maybe the issue is better posed as disabling the Auto mode preset is a bit convoluted. I like to keep it in Auto mode but shut it off completely when the house is empty, required an extra step to toggle a fan speed then shut it off. Which I suppose I would also have to do the same if there was say a preset that isn't Auto (None, Off, etc.).

from ha-dyson.

@geekofweek That doesn't sound very logical. Off means off. If I tell my Dyson to turn off, I want it to turn off no matter what mode is set. Dyson app works the same way.

from ha-dyson.

@JakubMacoun I stand corrected. I tested how I believed the fan was functioning, it does turn the fan completely off but the state is still reported as On if in Auto. The fan is not still on and the Dyson App reports it off and it will not attempt to purify the air just monitor air quality if continuous monitor is on. The way I was interpreting it from #12 if the fan itself ramps down completely it would show the state as Off when it was technically still on if the air needed purification. I think that is where the change in behavior came from. If in Auto assume still technically On, but that is not the case. If a fan.turn_off is issued when in Auto mode the fan will turn off but incorrectly report the state as On.

Apologies on the confusion I was causing, I didn't test how I thought it was functioning.

from ha-dyson.

So, it happened again. Unfortunatelly, it just happened after longer time of HA running, so I can't figure out the conditions and my log got spammed by other integration (Darksky closed) :/

from ha-dyson.

@shenxn Could this be caused by the fact, that the on_connect handler of libdyson does not subscribe, like it does on the initial connect?

I have browsed paho's docs and I did not find any information stating, that reconnecting should automatically re-establish any previous subscriptions. Since this issue only happens once the connection was broken once, this would perfectly make sense and cause the exact symptoms.

from ha-dyson.

I've released version 0.9.0. Try if that fixes your problem.

from ha-dyson.

Thanks, I've updated and now I guess only time will show. I'll report back.

from ha-dyson.

@shenxn So far, the state seems fine, but there is one small problem with oscillating attribute. Initially it is set to false even when my purifier is oscillating. When I turn the oscillation off and on manually via service, the attributes value changes correctly. But the initial value is wrong.

from ha-dyson.

@JakubMacoun Can you enable debug log for libdyson and find the initial New state: log? Thanks.

from ha-dyson.

@shenxn Sorry, my knowledge about Home Assistant is limited in this way. Assuming this: https://www.home-assistant.io/integrations/logger/ I just add this to my config and than find the logs in Supervisor/Core logging?

logger:
  logs:
    libdyson: debug

from ha-dyson.

@shenxn This is all I found in log related to libdyson after startup:

2021-04-22 13:21:42 DEBUG (Thread-7) [libdyson.dyson_device] Connected with result code 0
2021-04-22 13:21:42 INFO (SyncWorker_1) [libdyson.dyson_device] Connected to device D8N-PL-XXXXXXXX
2021-04-22 13:21:42 DEBUG (Thread-7) [libdyson.dyson_device] New state: {'msg': 'CURRENT-STATE', 'time': '2021-04-22T11:21:42.000Z', 'mode-reason': 'PUI', 'state-reason': 'MODE', 'rssi': '-54', 'channel': '9', 'fqhp': '70512', 'fghp': '40904', 'product-state': {'fpwr': 'ON', 'auto': 'ON', 'oscs': 'ON', 'oson': 'ON', 'nmod': 'OFF', 'rhtm': 'ON', 'fnst': 'FAN', 'ercd': 'NONE', 'wacd': 'NONE', 'nmdv': '0004', 'fnsp': 'AUTO', 'bril': '0002', 'corf': 'ON', 'cflr': '0042', 'hflr': '0042', 'cflt': 'CARF', 'hflt': 'GHEP', 'sltm': 'OFF', 'osal': '0180', 'osau': '0270', 'ancp': 'CUST', 'fdir': 'ON'}, 'scheduler': {'srsc': '0000000000000000', 'dstv': '0000', 'tzid': '0001'}}
2021-04-22 13:21:42 DEBUG (Thread-7) [libdyson.dyson_device] New environmental state: {'msg': 'ENVIRONMENTAL-CURRENT-SENSOR-DATA', 'time': '2021-04-22T11:21:42.000Z', 'data': {'tact': '2986', 'hact': '0025', 'pm25': '0005', 'pm10': '0003', 'va10': '0004', 'noxl': '0012', 'p25r': '0006', 'p10r': '0006', 'sltm': 'OFF'}}
2021-04-22 13:21:42 DEBUG (Thread-7) [libdyson.dyson_device] New environmental state: {'msg': 'ENVIRONMENTAL-CURRENT-SENSOR-DATA', 'time': '2021-04-22T11:21:42.000Z', 'data': {'tact': '2986', 'hact': '0025', 'pm25': '0005', 'pm10': '0003', 'va10': '0004', 'noxl': '0012', 'p25r': '0006', 'p10r': '0006', 'sltm': 'OFF'}}

from ha-dyson.

@JakubMacoun What is the model of your device?

from ha-dyson.

@shenxn Pure Cool TP04

from ha-dyson.

I am also seeing something weird with the oscillating state which is always false. To reproduce this works for me:

• Have everything turned off
• Turn on the fan via the oscillate button in the Dyson app
• State in developer tools is false. Turning oscillation in the app on/off does not do anything to the state in HA
• call fan.oscillate service with true
• now everything works again (from Dyson app and from switches)

It seems an initial state must somewhere be wrong, this is a Dyson Pure Cool (TP04 as far as I know)

from ha-dyson.

This is the state change that happens when the device is off and I turn it on through the dyson app by pressing the oscillating button

2021-05-09 09:41:00 DEBUG (Thread-5) [libdyson.dyson_device] New state: {'msg': 'STATE-CHANGE', 'time': '2021-05-09T07:41:01.000Z', 'mode-reason': 'NONE', 'state-reason': 'MODE', 'product-state': {'fpwr': ['OFF', 'ON'], 'auto': ['OFF', 'OFF'], 'oscs': ['OFF', 'ON'], 'oson': ['ON', 'ON'], 'nmod': ['OFF', 'OFF'], 'rhtm': ['ON', 'ON'], 'fnst': ['OFF', 'FAN'], 'ercd': ['11E1', '11E1'], 'wacd': ['NONE', 'NONE'], 'nmdv': ['0004', '0004'], 'fnsp': ['0001', '0001'], 'bril': ['0002', '0002'], 'corf': ['ON', 'ON'], 'cflr': ['0085', '0085'], 'hflr': ['0085', '0085'], 'cflt': ['CARF', 'CARF'], 'hflt': ['GHEP', 'GHEP'], 'sltm': ['OFF', 'OFF'], 'osal': ['0080', '0080'], 'osau': ['0260', '0260'], 'ancp': ['CUST', 'CUST'], 'fdir': ['ON', 'ON']}, 'scheduler': {'srsc': '0000000000000000', 'dstv': '0000', 'tzid': '0001'}}

I am unsure what all the variables are for, oscs seems to be correct to me. I am unsued why oson is doing ON ON. Could it be there is an issue with the oscs and oson initial states ?

If you need any more debugging let me know, I am fine by adding extra logging statement in the .py files to debug this further.

from ha-dyson.

@shenxn I modified the values on

https://github.com/shenxn/libdyson/blob/65613dfafdf055c38f5bdb6dc8af9e2b6a5ea98c/libdyson/dyson_pure_cool.py#L123
https://github.com/shenxn/libdyson/blob/65613dfafdf055c38f5bdb6dc8af9e2b6a5ea98c/libdyson/dyson_pure_cool.py#L156
https://github.com/shenxn/libdyson/blob/65613dfafdf055c38f5bdb6dc8af9e2b6a5ea98c/libdyson/dyson_pure_cool.py#L165

from OION to ON and OIOF to OFF and now it seems like this is behaving correctly.

I am not sure if these are leftovers from a copy/paste from another class or if other devices require these values.

This works for me for:

DEVICE_TYPE_PURE_COOL = "438"

however I notice that the dyson_pure_cool is also used by:

        DEVICE_TYPE_PURE_COOL_2021,
        DEVICE_TYPE_PURE_COOL_DESK,

So I am unsure what values these two use.

from ha-dyson.

It seems that some of the device uses OION/OIOF and others uses ON/OFF by default. And seems that your device and the Dyson mobile app can handle both. I'll try to adopt that as well. Hopefully it will work.

from ha-dyson.

@shenxn bumped to 0.13.0 and that seems to fix it as far as I could test it. Tnx!

from ha-dyson.