search

Baldhor / Homey-ESPhome-Enhanced

This is an Homey app which adds support for ESPHome devices. ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems. More information on their homepage: https://www.esphome.io/
GNU General Public License v3.0
4 stars 3 forks source link

Request: Support for climate components, Panasonic heat pump #42

Closed Nettopp closed 8 months ago

Nettopp commented 9 months ago

Thank you for a very interesting project on adding ESPhome to Homey, your work is appreciated!

As described on the Homey forum, I will add a file with the log for items not showing up in the app under "native capabilities". Currently, when adding the ESPhome connected to the heat pump, the following options are available: image

Please see the attached file for "newentity" from the log. The following objects are included in the file:

panasonic_ac_outside_temperature panasonic_ac_power_consumption panasonic_ac_econavi_switch panasonic_ac panasonic_ac_horizontal_swing_mode panasonic_ac_vertical_swing_mode

At the bottom of the file I also added an "Unhandled entity type", as it looks like the "panasonic_ac" objectID contains several parameters, as seen in the screenshot below: supportsCurrentTemperature, supportedModesList, supportedCustomFanModesList, supportedCustomPresetsList

image

If you want to see the console.re it is running at the moment: https://console.re/nettoppesp console re newobject.txt

Baldhor commented 9 months ago

@Nettopp Thx for the logs!

So your device has 6 entities, only 3 of them appear in the wizard:

It's missing 3 entities, which we will focus on:

What follow is a todo list ... and it's a long one :) In bold what is required for your usage.

panasonic_ac

{
    "_events": {},
    "_eventsCount": 1,
    "config": {
        "objectId": "panasonic_ac",
        "key": 290099816,
        "name": "Panasonic AC",
        "uniqueId": "panasonic-acclimatepanasonic_ac",
        "supportsCurrentTemperature": true,
        "supportsTwoPointTargetTemperature": false,
        "supportedModesList": [
            0,
            1,
            2,
            3,
            4,
            5
        ],
        "visualMinTemperature": 16,
        "visualMaxTemperature": 30,
        "visualTargetTemperatureStep": 0.5,
        "legacySupportsAway": false,
        "supportsAction": false,
        "supportedFanModesList": [],
        "supportedSwingModesList": [
            0,
            1,
            2,
            3
        ],
        "supportedCustomFanModesList": [
            "1",
            "2",
            "3",
            "4",
            "5",
            "Automatic"
        ],
        "supportedPresetsList": [],
        "supportedCustomPresetsList": [
            "Normal",
            "Powerful",
            "Quiet"
        ],
        "disabledByDefault": false,
        "icon": "",
        "entityCategory": 0,
        "visualCurrentTemperatureStep": 0.5
    },
    "type": "Climate",
    "name": "Panasonic AC",
    "id": 290099816,
}

The entity expose lot of things:

panasonic_ac_horizontal_swing_mode

{
    "_events": {},
    "_eventsCount": 1,
    "config": {
        "objectId": "panasonic_ac_horizontal_swing_mode",
        "key": 3166509394,
        "name": "Panasonic AC Horizontal Swing Mode",
        "uniqueId": "panasonic-acselectpanasonic_ac_horizontal_swing_mode",
        "icon": "",
        "optionsList": [
            "auto",
            "left",
            "left_center",
            "center",
            "right_center",
            "right"
        ],
        "disabledByDefault": false,
        "entityCategory": 0
    },
    "type": "Select",
    "name": "Panasonic AC Horizontal Swing Mode",
    "id": 3166509394,
}

In homey, it should match to an enum capability, which will require a custom capability of type enum with the values set during initialization. Should be getable and setable.

panasonic_ac_vertical_swing_mode

{
    "_events": {},
    "_eventsCount": 1,
    "config": {
        "objectId": "panasonic_ac_vertical_swing_mode",
        "key": 3804174560,
        "name": "Panasonic AC Vertical Swing Mode",
        "uniqueId": "panasonic-acselectpanasonic_ac_vertical_swing_mode",
        "icon": "",
        "optionsList": [
            "swing",
            "auto",
            "up",
            "up_center",
            "center",
            "down_center",
            "down"
        ],
        "disabledByDefault": false,
        "entityCategory": 0
    },
    "type": "Select",
    "name": "Panasonic AC Vertical Swing Mode",
    "id": 3804174560,
}

In homey, it should match to an enum capability, which will require a custom capability of type enum with the values set during initialization. Should be getable and setable.

Baldhor commented 9 months ago

For reference your yaml file:

esphome:
  name: panasonic-ac
  platform: ESP32
  board: nodemcu-32s

wifi:
  ssid: "xx"
  password: "xx"

logger:
  level: DEBUG
#  baud_rate: 0 # ESP8266 only

api:

ota:

# mqtt:
#  broker: 192.168.1.102

web_server:
  port: 80

# Requires ESPHome 1.15.0+ for the even parity option
uart:
  tx_pin: GPIO17
  rx_pin: GPIO16
  baud_rate: 9600
  parity: EVEN

external_components:
  source: github://DomiStyle/esphome-panasonic-ac
  components: [panasonic_ac]

climate:
  - platform: panasonic_ac
    # For CZ-TACG1
    type: cnt

    # For DNSK-P11
    # type: wlan

    name: Panasonic AC
    horizontal_swing_select:
      name: Panasonic AC Horizontal Swing Mode
    vertical_swing_select:
      name: Panasonic AC Vertical Swing Mode
    outside_temperature:
      name: Panasonic AC Outside Temperature

    # Enable as needed
    # eco_switch:
    #   name: Panasonic AC Eco Switch
    econavi_switch:
      name: Panasonic AC Econavi Switch
    # nanoex_switch:
    #   name: Panasonic AC NanoeX Switch
    # mild_dry_switch:
    #   name: Panasonic AC Mild Dry Switch
    current_power_consumption:
      name: Panasonic AC Power Consumption

    # Useful when the ac does not report a current temperature (CZ-TACG1 only)
    # current_temperature_sensor: temperature_sensor_id
Baldhor commented 9 months ago

@Nettopp Possible to retrieve the console.re logs for the 3 entities missing ?

It looks like: image

edit: I mean the "Received state for entity" logs

Nettopp commented 9 months ago

Hi @Baldhor, sorry for taking so long to get back with this. I was confused about the log, especially about entity wih key 3336637474. It has a lot of states, documented in the txt file. But I dont think we really need to worry about this entity, my theory is that it reports the state of the heat pump (if it is actually heating, cooling, etc.), and we really only need to worry about the settings.

In the file I listed the different settings that will be used in practice, I dont think my heat pump uses "LegacyAway", "Action", "fanMode", "preset". That might be dependent on the model of heat pump.

LogESP.txt

Baldhor commented 9 months ago

@Nettopp yes, for me, only the bold ones are required for your use case. But I cannot declare Climate is fully supported if I don't implement others :) I want to finish #30 improved ui before working on Climate support. Too much code changed, I would need to implement it twice :)

Sorry, but you will need to wait about a week or so. It's way more work than I first expected (ie. 1h ... lol)

Baldhor commented 9 months ago

@Nettopp So I looked at your txt file, thanks for trying to analyze :) The 2 select entity is not a big deal, and I know how to implement it.

the main issue is the big "climate" entity. From your logs, it report only a "state" with very strange values ... I would expect many attributs, something like:

{
    "key": 3336637474,
    "state": <current_tremparature>,
    "fan_mode": ...,
    "target_temperature": ...,
    ....
    ....
    "missingState": false
}

Anything you missed in the logs???

Nettopp commented 9 months ago

@Baldhor sorry for being unclear, every log report from panasonic_ac contains all those states I listed in the first part of the txt file. So basically the first log posted in the file, and I only posted the different parameters that were available.

{ "key": 290099816, "mode": 0, "currentTemperature": 25, "targetTemperature": 21, "targetTemperatureLow": 0, "targetTemperatureHigh": 0, "legacyAway": false, "action": 0, "fanMode": 0, "swingMode": 0, "customFanMode": "Automatic", "preset": 0, "customPreset": "Normal" }

So when I changed the CustomPreset, it reported the log above, just with a different "customPreset" value, everything else was the same. The only thing that prompted another log key was the mode change, those responses I added to the bottom of the txt file. Maybe you could look in the https://console.re/nettoppesp and see if I missed something, it should be running now. Or just page me to restart it.

Please finish #30 first tho, no rush for me! Just happy to see the app being worked on and improved, looking forward to the new functionality.

Baldhor commented 8 months ago

@Nettopp Implemented and published as TEST version: https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/

Please understand I do not have this kind of devices, so I just cannot test it! However, I'm confident ... kind of :)

Report any issue here! Or let me know if it works perfectly :)

Baldhor commented 8 months ago

@RoadXY Any idea how to make a mock entity for an entity of type 'Select'? :)

Baldhor commented 8 months ago

Testing this:

select:
  - platform: template
    name: "Random select"
    id: random_select
    optimistic: true
    options:
      - one
      - two
      - three
    initial_option: two
    lambda: |-
      switch (rand() % 3){
            case 0:
              return one;
            case 1:
              return two;
            case 2:
              return three;
      }
    update_interval: 10s
RoadXY commented 8 months ago

@RoadXY Any idea how to make a mock entity for an entity of type 'Select'? :)

I'll try and find something

Baldhor commented 8 months ago

Tried this too, just doesn't compile:

select:
  - platform: template
    name: "Random select"
    id: random_select
    set_action:
      - lambda: |-
          auto call = id(random_select).make_call();
          call.set_option(x);
          call.perform();
    options:
      - "one"
      - "two"
      - "three"
    lambda: |-
      switch (rand() % 3){
            case 0:
              return "one";
            case 1:
              return "two";
            case 2:
              return "three";
      }
    update_interval: 10s
Baldhor commented 8 months ago

Found a working configuration:

select:
  - platform: template
    name: "Random select"
    id: random_select
    set_action:
      - lambda: |-
          id(random_select).publish_state(x);
    options:
      - "one"
      - "two"
      - "three"
    lambda: |-
      return id(random_select).at(rand() % 3);
    update_interval: 10s

Testing ... there are several bugs :)

Baldhor commented 8 months ago

Ok so, basically, the select component is working, but ... Once again Athom BV is playing with my mind: the available values of an "enum" capability cannot be dynamic ...

They have to be hard coded in the app.json (or compose file) ...

Baldhor commented 8 months ago

The only workaround I can think of is to use the media ui component: image

speaker_playing: current value speaker_next and speaker_prev: cycle through the possible values

Bu t it means that when the user add "custom enum" capability, acutally the app need to add 3 more:

Baldhor commented 8 months ago

Another idea, make use of the Ternary ui component: image

Good side:

Bad side:

RoadXY commented 8 months ago

Don't know for sure if it's related but: _The enum device class was removed from ESPHome to keep in sync with Home Assistant. The class was already not able to be used by any of the built in components and only potentially used by externalcomponents. https://esphome.io/changelog/2023.9.0.html#enum-device-class

Baldhor commented 8 months ago

Don't know for sure if it's related but: _The enum device class was removed from ESPHome to keep in sync with Home Assistant. The class was already not able to be used by any of the built in components and only potentially used by externalcomponents. https://esphome.io/changelog/2023.9.0.html#enum-device-class

No, it's not related, ESPhome moved to Select component to replace Enum component a long time ago

The limitations here are on Homey side ... So I tried my best to implement the second idea (using ternary uiComponent). It's globally working: image

But .... With Athom BV, there are always "but" seems: 1/ When one of the two capability change title (to include the selected value), it automatically reselect the first capability in the list 2/ If only one capability the dropdown (check screenshot) doesn't appear at all ... so no way to see the current value 3/ Homey app (on your phone) just break when the title change ...

Baldhor commented 8 months ago

screen capture with only one capability: image

But at least the Homey app (on your phone) doesn't break lol

Solution "ternary" is dead ... The only idea I have is using media, the selected option will appear as the current "playing title". The random and repeat buttons will not appear. The picture will not appear either.

In the long term, I suppose we could "generate the picture" so the user can see the list of possible values ...

Baldhor commented 8 months ago

image

No picture (at least until someone provide a took to generate one :) ) Song title will be replaced with current value Singer could be replace with something like :[[...] <previous value> ]<current value>[ <next value> [...]]

The brackets indicates the optionnal part based on the context

Random and repeat should not appear (related to dedicated capabilities, if we don't set them up, the button should be hidden) The play button will do nothing The "media" icon will be replace by a custom icon.

Baldhor commented 8 months ago

So it's 5 capabilities I need to hide behind a "dynamic_enum" custom capability ... image

I will need to think a few days lol

Baldhor commented 8 months ago

Additionally, it shows the album art as set using [Device#setAlbumArt()](https://apps-sdk-v3.developer.homey.app/Device.html#setAlbumArt).

image

The function doesn't take the capabilityId as input, I'm affraid there are a hard limit of one of each of the media capability ... But for sure the "generated image" I was talking about is dead ...

RoadXY commented 8 months ago

I've asked on Slack.

RoadXY commented 8 months ago

Ronny Winkler responded to my slack question (here: https://athomcommunity.slack.com/archives/C04SUGZ9E/p1696599722211809) He is the developer of the Home Assistant app for Homey. He has mainly the same challenges as we do with ESPhome.

RoadXY commented 8 months ago

I have Home Assistant running and I test-added the airconditioner via home assistant and there are capabilities in homey my airconditioner does not support (I use Tado). What Tado has: image

What Home Assistant device added to Homey says it has: image

RoadXY commented 8 months ago

It could be possible to add another device, pre defined in JSON, which is for airconditioners. Like this, in example: image

RoadXY commented 8 months ago

Another real life example: https://community.homey.app/t/app-pro-home-assistant-community-app/71477/802

Baldhor commented 8 months ago

@RoadXY

Ronny Winkler responded to my slack question (here: I cannot access slack, no idea why.

The main issue is that Homey expect the enum capabilities to have their possible values defined in the app configuration before you compile... Just cannot be dynamic.

So either I add a generic enum capability with 10 values (1, 2, 3, ...) so you can use it. But the values will be meaningless for the user (just cannot change their label dynamically either), and it will be 10 values, whatever the original number of values. I could also, make 10 generic enum, one with 2 values, one with 3, one with 4, ... but you still end up with the meaningless issue.

I tried to use the media ui component, actually I could make it work out as I explained above, but it is limited to "one" media component per virtual device. It's the best I could propose here. Meaning that for the original user asking to support panasonic climate, need to setup 4 virtual devices to handle the 4 enum (vertical swing, horizontal swing, ...).

I suppose it is acceptable, but sorry it's far from convenient!

Also, for each of the enum, using media ui compoinent, the user will need to setup 5 capabilities: prev, next, title (label of the enum), singer (current value), and track (prev / next values).

The only way to solve this would be for me to implement a kind of helper that will create those 5 capabilities in one step ... => Probably around 20h of development

Nettopp commented 8 months ago

@Baldhor I have been away for a few days, but back home now and ready to test! I asume 1.1.4 is the latest version, as I could not find anything on the "/test"-url.

Edit: Looks like when I add a new physical device there are no devices discovered, not even the sensors that were there on the original post (of this topic). I tried to add a couple of the devices, like current temperature. I will experiment a bit more and report back.

image

Baldhor commented 8 months ago

@Nettopp

@Baldhor I have been away for a few days, but back home now and ready to test! I asume 1.1.4 is the latest version, as I could not find anything on the "/test"-url.

Yes, I published in the meantime, so lastest version is the way to go

Edit: Looks like when I add a new physical device there are no devices discovered, not even the sensors that were there on the original post (of this topic). I tried to add a couple of the devices, like current temperature. I will experiment a bit more and report back.

This is, let's say, by design, you need to go into "New virtual device", to create a virtual device, then you will be able to add capabilities "one by one" You can check out the user guide: https://github.com/Baldhor/Homey-ESPhome-Enhanced/wiki/User-Guide

Now, there are a big issue in regards to Climate component. A climate component includes a lot of attributs which are "list of values": swing mode, fan mode, preset, and so on. In Homey, it is impossible to have those values dynamic, they mmust be know at programming time, which is just not possible when we consider ESPhome devices ... => It's the whole discussion we had with @RoadXY above ...

Currently, you just cannot configure those, it will not work, so you are limited to the temperature, or simple things like it. I will try to implement today the possibility to manipulate them through flows. And I will create another enhancement thread to continue the discussion about a possible "workaround". But to be honest, I'm in very bad mood because of this limitation, and I'm thinking about giving up and switch to Home Assistant ...

Nettopp commented 8 months ago

@Baldhor Thank you for the explanation, I think I understand some of the challenges. Do you recommend adding one viritual device for each capability, or add them all on one device? Maybe add all the temperature and power capabilities in one device of class "heater", and make one viritual device per list (mode) capability of the "media" class?

Baldhor commented 8 months ago

@Baldhor Thank you for the explanation, I think I understand some of the challenges. Do you recommend adding one viritual device for each capability, or add them all on one device? Maybe add all the temperature and power capabilities in one device of class "heater", and make one viritual device per list (mode) capability of the "media" class?

Using media class as a workaround is not implemented yet, that's the purpose of #53

I will make both esphome_text and esphome_select capabilities available as a "cheap" solution. They will have triggers, conditions, and actions cards.

But I'm still trying to figure out how to make them work :) Homey design is not really "easy" on this kind of subject ...

Baldhor commented 8 months ago

Actually, I just made my first trigger card works!

Baldhor commented 8 months ago

@Nettopp

New version: https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/

Published for certification (certification will be tomorrow) the new custom capabilities, and I wrote a wiki ... https://github.com/Baldhor/Homey-ESPhome-Enhanced/wiki/Custom-capabilities

It's missing the action card to modify the value of a select capability from a flow. I don't think I have time to do it tonight, probably more like tomorrow or even the day after ...

Let's be honest, we all were expecting such capability (list of value) to appear like: image

But Ahtom BV decided that it MUST NOT be possible for dynamic values ... Go complain to them ... no complain, no change ...

Baldhor commented 8 months ago

Actually, it's not so complicated to make action card, so I just published in test version (1.1.6), certification will be tomorrow

Nettopp commented 8 months ago

I'm currenly testing, managed to change the horisontal swing mode with an action card! There seem to be some weird behavior/bugs when I map the custom capabilities, I will report back when I get some more time for testing.

Baldhor commented 8 months ago

@Nettopp keep me aware, I tested it all (I think), but you may find some edge cases which require some fix

Baldhor commented 8 months ago

@Nettopp If you could update the app with lastest and certified version, I would like you test the new "collect debug info" on your panasonic device :) It's supposed to be much easier to use than last time lol

https://github.com/Baldhor/Homey-ESPhome-Enhanced/wiki/User-Guide#manage-your-physical-devices-page

Nettopp commented 8 months ago

@Baldhor, you are effective, this debug function will be useful :)

I added all the 13 capabilities of my heat pump to one virtual device as class heater. When I finished this, there was an error on the device in homey, no device capability linked or something similar, but after a restart of the ESPhome app the error went away.

The debug log of the physical device is here: debug.txt

On the Homey device, I had some trouble getting the right temperature to the thermostat device. The outside temperature is shown on the current temperature setting, I assume I can use Index to fix this?

The Econavi switch has taken the spot on the "on/off" function on the heating device. This is a bit of a problem, as the Homey device is shown as "greyed out" (off) when the Econavi function is off. Econavi is a function that adds sunshine and movement sensors to the temperature control of the heat pump, I always leave this off.

On the device list, there are a few of the capabilities that are missing values: 2 All the temperature and power seems to be working fine.

Then I tried the action cards: EconaviSwitch: Counted as on/off function for heater Setting the set point temperature seemed to work well.

When i tried "set the selected value of capability to value", these are the results: CustomFanMode: OK HorizontalSwingModeState: OK VerticalSwingModeState: OK

CustomPreset, Preset, SwingMode all give the following error: "e.name.toLoweCase is not a function". 3

For FanMode, there is no error, but the value field is empty (nothing to chose from).

Baldhor commented 8 months ago

@Nettopp I confirm, debug.txt is very very usefull lol

You should always set title, but I seen you did it. I think I will make it mandatory, and maybe compute a default title in the futur.



On the Homey device, I had some trouble getting the right temperature to the thermostat device. The outside temperature is shown on the current temperature setting, I assume I can use Index to fix this?

You have 3 temperatures:

      {
        "nativeCapabilityId": "290099816:currentTemperature",
        "entityId": "290099816",
        "attribut": "currentTemperature",
        "entityName": "Panasonic AC Econavi Switch",

=> match with measure_temperature with index inside

     {
        "nativeCapabilityId": "290099816:targetTemperature",
        "entityId": "290099816",
        "attribut": "targetTemperature",
        "entityName": "Panasonic AC",

=> match with target_temperature with index inside

      {
        "nativeCapabilityId": "1168153563:state",
        "entityId": "1168153563",
        "attribut": "state",
        "entityName": "Panasonic AC Outside Temperature",

=> match with measure_temperature with index outside

As a result, you should obtain a thermostat ui component for inside (show current temp + allow modification of target). And a measure for outside.



The Econavi switch has taken the spot on the "on/off" function on the heating device. This is a bit of a problem, as the Homey device is shown as "greyed out" (off) when the Econavi function is off. Econavi is a function that adds sunshine and movement sensors to the temperature control of the heat pump, I always leave this off.

Set the index of econavi to 2, and the other one to 1. Hopefully it will solve your issue. If it doesn't fix it, try remove the econavi and set it again.

In homey, we cannot control the order of appearence ... There are some logic to it, but it's not very clear: standard capabilities first, onoff before them all, order of creation, order of definition in the app.json file... this kind



CustomPreset, Preset, SwingMode all give the following error: "e.name.toLoweCase is not a function".

That's the 3 of them that have numeric values ...

      {
        "nativeCapabilityId": "290099816:swingMode",
        "entityId": "290099816",
        "attribut": "swingMode",
        "entityName": "Panasonic AC",
        "type": "Climate",
        "used": 1,
        "value": 0,
        "configs": {},
        "constraints": {
          "values": [
            0,
            1,
            2,
            3
          ],
          "type": "string"
        },
        "specialCase": null
      },

In comparaison, customFanMode has a list of string values:

      {
        "nativeCapabilityId": "290099816:customFanMode",
        "entityId": "290099816",
        "attribut": "customFanMode",
        "entityName": "Panasonic AC",
        "type": "Climate",
        "used": 1,
        "value": "Automatic",
        "configs": {},
        "constraints": {
          "values": [
            "1",
            "2",
            "3",
            "4",
            "5",
            "Automatic"
          ],
          "type": "string"
        },
        "specialCase": null
      },

I need to convert it to string, but then I'm unsure how it will react when pushing the new value to the device itself ... (when you moidify it through a flow). You will have to test the fix and let me know :)



For FanMode, there is no error, but the value field is empty (nothing to chose from).

      {
        "nativeCapabilityId": "290099816:fanMode",
        "entityId": "290099816",
        "attribut": "fanMode",
        "entityName": "Panasonic AC",
        "type": "Climate",
        "used": 1,
        "value": 0,
        "configs": {},
        "constraints": {
          "values": [],
          "type": "string"
        },
        "specialCase": null
      },

I confirm, no values ... I need to fix the code this native capability should not even be proposed to you :) Or maybe it's not an enum type ... I need to double check.



I will let you know when I published the 2 fix. Let me know for the others

Baldhor commented 8 months ago

For fanMode, I confirm the problem come from your device, the rawData (ie. data published by your device) indicate: "supportedFanModesList": [],

So the fix will be to ignore an enum native capability if the list of values proposed is empty.

Baldhor commented 8 months ago

As about CustomPreset, Preset, SwingMode. They are supposed to be working? I tried to make a select component with numeric values, it doesn't even compile ... it's apparently not supposed to be possible

Baldhor commented 8 months ago

@Nettopp see above comments please

I have been checking your screen capture from few weeks ago: image

fanMode, CustomPreset, Preset and SwingMode are not there! So ESPhome itself do not support them!

The fix for all of them will be to filter them out.

Baldhor commented 8 months ago

Fixed and live. Actually, I had a bug in preset and customPreset => custom preset should be available, and I have no idea why ESPhome doesn't show it.

          "supportedCustomPresetsList": [
            "Normal",
            "Powerful",
            "Quiet"
          ],
Nettopp commented 8 months ago

fanMode, CustomPreset, Preset and SwingMode are not there! So ESPhome itself do not support them!

The fix for all of them will be to filter them out.

Yeah its weird, but the functions are supported by API/HA and MQTT: https://github.com/DomiStyle/esphome-panasonic-ac/blob/e0719bf790f157ae0d5a6946d446bff726ad1327/components/panasonic_ac/esppac_cnt.cpp#L301

Nettopp commented 8 months ago

Fixed and live. Actually, I had a bug in preset and customPreset => custom preset should be available, and I have no idea why ESPhome doesn't show it.

          "supportedCustomPresetsList": [
            "Normal",
            "Powerful",
            "Quiet"
          ],

@Baldhor Custom preset and custom fan mode is not visible in the native capabilities list, did you filter them out?

image

Swing mode and mode can be added, but there are no values shown. To be honest I'm not sure if swing mode will do anything om my heat pump, could be that this function is only for heat pumps that does not have both vertical and horizontal swing modes.

image

When trying to control swing mode and mode by an action card, the following error message is shown:

image

Baldhor commented 8 months ago

@Nettopp It should be the opposite :) mode and switchMode should not appear, and the others should appear :)

It's live, upgrade please :)

NB: the problem is that I just cannot test Climate, I cannot simulate it

Nettopp commented 8 months ago

@Baldhor Perfect, both fan mode and preset works now! Really nice, thank you for all your work! The only thing that is missing now is Mode, this is where you select heating, cooling, turn the heat pump off, etc. Hopefully you can get this to work as well :)

Baldhor commented 8 months ago

@Nettopp Ok so I added a custom enum for horizontal swing mode. It's awaiting certification: https://homey.app/a/nl.inversion.esphome/test/


In the Wizard, you can select the ESPhome Custom Enum capability. It will only be proposed if it exists a custom enum with exactly the same values! image

In the device, it will appear like this (here is just my test enum): image

You can use it in the "esphome_select" cards (trigger, condition and action): image


If you confirm it works well, I will add the custom enum missing for your needs, and only for you because you are the "first" that need it. Others will need to pay ... --greedy mode--

Baldhor commented 8 months ago

fanMode, CustomPreset, Preset and SwingMode are not there! So ESPhome itself do not support them! The fix for all of them will be to filter them out.

Yeah its weird, but the functions are supported by API/HA and MQTT: https://github.com/DomiStyle/esphome-panasonic-ac/blob/e0719bf790f157ae0d5a6946d446bff726ad1327/components/panasonic_ac/esppac_cnt.cpp#L301

@Nettopp Yeah, I can see in the code, but it returns numerical values, meaning I actually need to convert it to string, and not just exclude it. But I have no way to test it at all, I cannot setup a test enity that returns numerical (it's not supposed to be possible).

I need to think about it a little