Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update to the new fan platform #542

Merged
merged 53 commits into from
Jan 3, 2022
Merged

Conversation

tinglis1
Copy link

Updated to the new fan platform using percentages.

I have modified the fan.py and config flow to:

  • Allow for min and max integer speeds.
  • Option to use a named range instead of an integer min/max.
  • Named forward and reverse directions.
  • Removed the deprecated speed_list option.

I have tested with an Arlec Ceiling fan and tried to make the update flexible for as many other devices as possible.
Probably needs some beta testers for more thorough bug finding.

For those using the exiting option in speed lists for small, mid, large these can be done as a comma separated list in named speeds.

@tinglis1
Copy link
Author

Example config page
image

@tinglis1 tinglis1 mentioned this pull request Aug 23, 2021
@vmartinv
Copy link

vmartinv commented Aug 24, 2021

Hi @tinglis1 , wouldn't it be better to follow the same pattern as we have for cover? i.e. for the direction provide several sets, one being "forward/reverse". Same thing for the ordered list, just provide "small/mid/large". Reason being it's easier for the user to setup and I don't think there are that many different options. Take a look at the cover code for inspiration and let me know your thoughts. Also you might need a rebase/merge with upstream to resolve your conflicts.

@tinglis1
Copy link
Author

Hi @tinglis1 , wouldn't it be better to follow the same pattern as we have for cover? i.e. for the direction provide several sets, one being "forward/reverse". Same thing for the ordered list, just provide "small/mid/large". Reason being it's easier for the user to setup and I don't think there are that many different options. Take a look at the cover code for inspiration and let me know your thoughts. Also you might need a rebase/merge with upstream to resolve your conflicts.

I wrote the new platform based on the lack of consistent terms used by the Tuya platform.

  • fan direction. The forward/reverse term is what I have encountered but I remember seeing somewhere that some might be using summer/winter etc.
  • The ordered should be configurable. There will be far to many permutations to consider. With the current named options available in fan.py I can come up with 6 permutations. This only considers a maximum of three speeds. As new terms that are identified this will grow significantly. All the merged pull requests on fan.py this year have been for named speeds.
    I am sure there are more elegant ways to manage this field but I was going for functional as the deprecated fan features end in a few months Fan Entity.

For reference I am not a programmer but needed this component to work for my ceiling fans so gave it go at updating it.

@Francisk0
Copy link

I don´t know How to change Value to 2, and no have same result than exapmle
Captura de pantalla 2021-08-29 a las 21 10 18

@tinglis1
Copy link
Author

tinglis1 commented Aug 29, 2021

I don´t know How to change Value to 2, and no have same result than exapmle

Captura de pantalla 2021-08-29 a las 21 10 18

Based on your post in the issue with your DPS mapping what you have for the speed control should work for your fan.
The DPS of 3 is correct and the value is just showing your current fan speed which is 1.
The forward and reverse terms might need to be changed. Your mapping looks like it uses DPS 101 and the terms True and False.

@tinglis1
Copy link
Author

That field below the oscillation field that doesn't have a title (need to fix that) is the field for selecting the DPS for the fan direction.

@vmartinv
Copy link

vmartinv commented Aug 29, 2021

@tinglis1 You have to be careful of these True/False cases. You might need to add some type conversions because the config are strings and the forward/reverse dp might be a boolean. Look at this:

>>> ordered_list_item_to_percentage(["True", "False"], True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "***/homeassistant/core/homeassistant/util/percentage.py", line 25, in ordered_list_item_to_percentage
    raise ValueError(f'The item "{item}"" is not in "{ordered_list}"')
ValueError: The item "True"" is not in "['True', 'False']"
>>> True == "True"
False

Copy link

@PaulioArmani PaulioArmani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thaks for these changes, I have added them to my local tuya and all works perfect except everytime I change fan speed I get the below error but the setting changes just fine.

unsupported operand type(s) for -: 'str' and 'int'

@ThomasADavis
Copy link

This is missing the use of presets... My air purifier uses the low/mid/high/auto settings, and works great as a preset instead of speeds. Several other fan controllers use these also.

auto is a preset, not a fan speed.

My ceiling fan controller doesn't use presets, but does use numerical ranges (4 speeds, 1 to 4)

Need to create a catalog like https://github.com/make-all/tuya-local implemented for his tuya integration and stop hard-coding these into the program.

@ThomasADavis
Copy link

This is the localtuya and the tuya_local catalog entry

#    local_key: *key*
#    friendly_name: Master Bedroom Air Purifier
#    protocol_version: "3.3"
#    entities:
#      - platform: fan
#        friendly_name: Master Bedroom Air Purifier
#        fan_speed_low: "low"
#        fan_speed_medium: "mid"
#        fan_speed_high: "auto"
#        id: 1
#        fan_speed_control: 4
#      - platform: switch
#        friendly_name: Child Lock
#        id: 7
#      - platform: switch
#        friendly_name: Sleep Mode
#        id: 101
#      - platform: sensor
#        id: 22
#        friendly_name: Master Air Quality
#      - platform: sensor
#        friendly_name: MB Prefilter Life
#        id: 102
#      - platform: sensor
#        friendly_name: MB Charcoal Filter Life
#        id: 103
#      - platform: sensor
#        friendly_name: MB Activated Charcoal Life
#        id: 104
#      - platform: sensor
#        friendly_name: MB HEPA Filter Life
#        id: 105
#
name: Renpho RP-AP001S
products:
  - id: oaleouzsq0sk4quk
primary_entity:
  entity: fan
  dps:
    - id: 1
      name: switch
      type: boolean
    - id: 4
      name: preset_mode
      type: string
      mapping:
        - dps_val: "low"
          value: low
        - dps_val: "mid"
          value: mid
        - dps_val: "high"
          value: high
        - dps_val: "auto"
          value: auto
    - id: 7
      name: child_lock
      type: boolean
    - id: 8
      name: aqi_mode
      type: boolean
    - id: 19
      name: timer
      type: string
    - id: 22
      name: air_quality
      type: string
    - id: 101
      name: sleep_mode
      type: boolean
      icon: "hass:sleep"
    - id: 102
      name: prefilter_life
      type: integer
    - id: 103
      name: charcoal_filter_life
      type: integer
    - id: 104
      name: activated_charcoal_filter_life
      type: integer
    - id: 105
      name: hepa_filter_life
      type: integer

secondary_entities:
  - entity: lock
    name: Child Lock
    dps:
      - id: 7
        name: lock
        type: boolean
        mapping:
          - dps_val: true
            icon: "mdi:led-on"
          - dps_val: false
            icon: "mdi:led-off"
  - entity: light
    name: AQI mode
    class: switch
    dps:
      - id: 8
        name: switch
        type: boolean
        mapping:
          - dps_val: true
            icon: "mdi:led-on"
          - dps_val: false
            icon: "mdi:led-off"
  - entity: switch
    name: Sleep Mode
    class: switch
    dps:
      - id: 101
        name: switch
        type: boolean
        icon: "hass:sleep"

@tinglis1
Copy link
Author

@ThomasADavis
Presets could be added to this change but I won't be able to work on it for a while.
If someone wants to give it a go feel free.

In the interim you could just assign your speed and auto to the names list as they are all on the same DPS.
This is pretty much the same way the catalogue tuya implementations are using the deprecated speed options by assigning the auto speed to the high value.

One thing I have noticed is that some presets are on the same DPS as speed and some are on a different one.

Sending the preset will be easy enough but on receiving them there will need to be some checks against preset lists to split out presets from speeds when they share a DPS.

fan presets

@tinglis1
Copy link
Author

@ThomasADavis On a side note i like the catalogue idea but none of those implementations use the new fan platform and I wasn't skilled enough to update those platforms with the added complexity of config yaml.
I also like the easy of someone setting up a new tuya device quickly without needing to know how to create and possibly submit a config file to the integration.

If only tuya would give some standardization on its DPS fields.

@tinglis1
Copy link
Author

Thaks for these changes, I have added them to my local tuya and all works perfect except everytime I change fan speed I get the below error but the setting changes just fine.

unsupported operand type(s) for -: 'str' and 'int'

I have spotted that as well now that I am looking for it. I don't get it every time and I always works.
I don't get anything in my integration debug logs. Maybe I need to turn on the system wide HA debugging and see if it's there.

@antbarney
Copy link

Thaks for these changes, I have added them to my local tuya and all works perfect except everytime I change fan speed I get the below error but the setting changes just fine.
unsupported operand type(s) for -: 'str' and 'int'

I have spotted that as well now that I am looking for it. I don't get it every time and I always works.
I don't get anything in my integration debug logs. Maybe I need to turn on the system wide HA debugging and see if it's there.

yes this was bugging me too, its in line 152, which is just a debug log which is why everything works. (my guess is a copy paste error :))

_LOGGER.debug("Fan async_set_percentage: %s > %s", percentage, percentage_to_ranged_value(self._ordered_list, percentage))

Just need to update it to use the correct tuple value of the speed range which is what percentage_to_ranged_value expects.

_LOGGER.debug("Fan async_set_percentage: %s > %s", percentage, percentage_to_ranged_value(self._speed_range, percentage))

@bughaver
Copy link

bughaver commented Dec 19, 2021

I can't understand what that "statuses" message means but I believe that's the reason.

Thats just simply saying the ci needs to run before the pr can be merged.

@tinglis1 not sure if this is the issue but its something to check, when creating a pr myself it ask if you wanted to give the maintainers (@rospogrigio) write permission.. did you tick that box?
image

@psbankar
Copy link

Can closing and reopening the PR trigger the checks?

@rospogrigio
Copy link
Owner

OK I managed to re-run the checks, but the python 3.8 check failed:

custom_components/localtuya/fan.py:115 in public method `async_turn_on`:
        D201: No blank lines allowed before function docstring (found 1)
tox: lint

=================================== log end ====================================
✖ FAIL lint in 1 minute, 16.789 seconds
✔ OK typing in 31.793 seconds
___________________________________ summary ____________________________________
  py38: commands succeeded
ERROR:   lint: parallel child exit code 1
  typing: commands succeeded
Error: Process completed with exit code 1.

Please commit the fix...

@bughaver
Copy link

@rospogrigio just need tests to run again

@bughaver
Copy link

@tinglis1 would it be possible to update the yaml for the new fan configuration in the readme please: https://github.com/tinglis1/localtuya/blob/master/README.md?plain=1#L64-L66

Copy link

@bughaver bughaver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested and working

@tinglis1
Copy link
Author

It should pass the checks now but in my last testing my fan is showing as always on. I am not sure if there is an issue with my HA instance. I can do everything like change speed etc. but it shows as on when it is off.

I will do some further checks. Please hold off on merging until I have confirmed if it is a local issue to me or something i broke.

@tinglis1
Copy link
Author

Confirmed that the issue I had around the fan showing as always on was related to the hardware. Turning it off and on fixed that issue.
So not an issue with the code and once the tests pass we can merge.

@joe-sydney
Copy link

I manually merged this with v3.3.0 that was just released as I needed both the update DPS capability for power consumption as well as this fan one. Worked as expected. Would be good if this fan PR can be merged into master soon :)

@rospogrigio rospogrigio merged commit 204b36b into rospogrigio:master Jan 3, 2022
@tinglis1
Copy link
Author

tinglis1 commented Jan 3, 2022

Thank you very much everyone who was involved in getting this merged.

@stanvx
Copy link

stanvx commented Jan 6, 2022

Documentation needs to be updated to mention fan_direction_forward and fan_direction_reverse rather than fan_direction_fwd and fan_direction_rev.

https://github.com/tinglis1/localtuya/blob/master/README.md?plain=1#L70-L71

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.