Samsung AC

Hey @SebuZet,
I tried the dev setup as per your instructions from a few posts earlier, and it has worked fine for me too! The only mod was to change the path to the cert because my HA setup doesn’t seem to work with the ‘config’ reference.

Thankyou so much, I have been waiting/trying to get this on HA for years!

@SebuZet I am finding my HA is hanging after a few minutes. Manually interacting with the AC with OpenSSL is also unresponsive after receiving an initial
CONNECTED(00000003)
Is the connection opened and closed every time it is polled?
Can the connection be reused? I know when I leave the connection open with OpenSSL, the AC reports any settings changes and I can post a request at anytime, too.

@Jman. Yes, connection is opened everytime when component is asking about state or executing command. I’ll try to reuse existing connection this evening.
Path with config reference folder is valid only for HA in Docker

Sorry for the late reply, I just grepped for where the file was referenced, then changed the paths from /config/* to /home/homeassistant/.homeassistant/

I believe the files I changed were :slight_smile:
climate.py
samsung_2878.yaml
samsungrac.yaml

Is there a better way to implement it to work across all types of install perhaps ?

Also I don’t think I’ve seen you in Discord @SebuZet, please feel free to join us there for more active discussions :slight_smile:

@atxbye I’ll try to make it easier to use. I’ve installed Discord but I’m sure how to use it :slight_smile: Are there some kind of channel or anything similar?

@Jman Can you try latest version? Now, component is working on already created connection.

@SebuZet First of all Many Thanks for your hard work!

I’m trying to get your code to work with Samsung’s MIM-H03 Wi-Fi kit that’s connected to a Samsung heat pump and it appears that the JSON returned is somewhat different from what ACs return, as a start it returns an array of temperatures - indoor, DHW and outdoor temperature.

I’m interested in integrating these code changes into your component rather than creating forks with minor differences. Furthermore I think this API can work with other Samsung SmartHome devices, given that in the example Samsung mentions “Smart coffee pot”. How should we colaborate on this?

Hi @kirichkov, thanks for good words :slight_smile:
I believe we can integrate your AC without any code modifications.
I was trying to make this component as much flexible as possible.
I’m planning to change the name of this component to Climate_IP because I believe it can be used to work with any AC units driven by REST API very easily.

I think that creating dedicated YAML configuration file will be enough. If you take a look at YAML configuration file then you will see many templates (status, connection). This component uses jinija templates so different json can be handled by dedicated templates.

We can start with such approach and then we will add this configuration to repo.
First of all, please let me know if your device is working with REST API or using sockets connection? We have to know which configuration file use to start work with.
Next, you can add debug: true line to configuration.yaml. After that device_state attribute will be added to device in HA.

Unless you already done an integration then please share your code. I can create new branch for you to make it easier.

YAML+jinja config sounds great! I didn’t see a YAML in the github repo, hence the suggestion. Indeed the format is largely the same just the place in the json differs. I’ve already turned on debug.
Where can I see this YAML example? There’s nothing like that in the github repo.

Please take a look at dev branch. The component was rewritten by me :wink:

Silly me! Indeed it’s there. I’ll be switching to the dev branch then! I’ll tweak the configuration and submit the yaml when it’s working properly.

Do you have any plans to make this official HASS component?

If your device is working with REST API then samsungrac.yaml is for you

What’s that mean. What do I need to do to make this component official. Keep in mind that it is still in dev mode.

Yes, it’s REST, and I’ve managed to start off from samsungrac and get it to set temperature properly. I’ll be testing later powering on/off and switching modes.

The only issue I have is that I can’t read the external temperature. Does the new component support adding custom attributes? I tried the following:

current_outside_temperature:
  type: number
  stastus_template: '{{ device_state.Temperatures.2.current | int }}'

but I always get -1000

on the other hand:

current_temperature:
  type: number
  status_template: '{{ device_state.Temperatures.0.current }}'

works properly. The module returns an array with Temperatures and the first one (index 0) is the water temperature, while the third element is the outside unit’s temperature.

Regarding the official component - I see it’s still under heavy development, but once it’s ready do you intend to add it to the main home assistant repository?

@kirichkov To be honest, in this component every attribute is custom and configured in yaml file :wink:
If you add debug: true in configuration section then you can go to dev-state panel and see device_state json. You can copy it and test your template in dev-template section.

One more thing: take a look at state_template in status section. In this place component can modify json returned by device and this modified json will be passed as device_state.

Can you provide json from your device?

And last warning, I’ve pushed last version and there are changes in configuration section. More info in this post:

All the controls are working :partying_face:

Save for getting the outside unit’s temperature. I also tried to get the data from the device_state attribute but I think the templating engine interprets it as a string, rather than a json/dict.

Here’s my configuration (excerpt):

device:
  status:
    status_template: '{{ device_state.Devices.1 }}'

  attributes:
    current_outside_temperature:
      type: number
      stastus_template: '{{ device_state.Temperatures.2.current }}'

Here’s the (abbreviated) response to GET /devices:

{
  "Devices": [
    {

    },
    {
      "Mode": {
        "modes": [
          "Opmode_Auto",
          "Dhw_Opmode_Not_Supported",
          "Away_Off"
        ],
        "options": [
          "Volume_100"
        ],
        "supportedModes": [
          "Opmode_Auto",
          "Opmode_Cool",
          "Opmode_Heat",
          "Dhw_Opmode_Not_Supported",
          "Away_On",
          "Away_Off"
        ]
      },
      "Operation": {
        "dhwPower": "Not_Supported",
        "power": "Off"
      },
      "Temperatures": [
        {
          "current": 23.6,
          "desired": -1000,
          "id": "0",
          "increment": 1,
          "maximum": -1000,
          "minimum": -1000,
          "name": "INDOOR",
          "unit": "Celsius"
        },
        {
          "current": -1000,
          "desired": -500,
          "id": "1",
          "increment": 1,
          "maximum": -500,
          "minimum": -500,
          "name": "DHW",
          "unit": "Celsius"
        },
        {
          "current": 27.5,
          "desired": -500,
          "id": "2",
          "increment": 1,
          "maximum": -500,
          "minimum": -500,
          "name": "OUTDOOR",
          "unit": "Celsius"
        }
      ],
      "Wind": {
        "direction": "Off",
        "speedLevel": 48,
        "supportedWindModes": [
          "48",
          "Off"
        ]
      },
      "description": "EHS",
      "id": "032000000",
      "name": "32:00:00",
      "resources": [
        "Operation",
        "Wind",
        "Mode",
        "Temperatures",
        "Information",
        "Configuration",
        "Alarms"
      ],
      "type": "Air_Conditioner",
      "uuid": ""
    },
    {

    }
  ]
}

One more question - What’s the use of target_temp_high and target_temp_low? I looked at other hass components but there doesn’t seem to be a clear answer, what it can be used for.

This template was introduced to increase performance but it is not obligatory.
You can set it as: ‘{{ device_state.Devices }}’ and modify all status templates to work with it.
You can also remove this line and then json returned by device will be passed as device_state for template rendering. Other status_templates will require update. Chose whatever you want but every part of device json is accessible in component :wink:

As far as I know some devices try to keep desired temp in range <target_temp_low…target_temp_high> in some modes (E.g. my ET SPIRIT ZWAVE thermostat in heat_eco mode). It’s device specific and my AC unit has such attributes.

That’s what I thought, I don’t think it’s applicable in my case.

The weird part is that the whole “Temperatures” array is available at index 1, so I don’t think that’s the issue. I’ll dig into it to resolve it or get template sensor working.

Thanks again! :bowing_man:

Try remove state_template from status section. Replace ‘device_state.’ with ‘device_state.Devices.0.’ in other status_templates. then add your attribute with ‘device_state.Devices.1.REST_OF_TEMPLATE’.
Should work.

@kirichkov Last version was broken. I’ve updated to better one :slight_smile: . You can take a look at samsungrac.yaml - I’ve removed status_template from status section and modified rest of templates to make it working. You can do the same and add your temperatue attributes.
If you add option debug: true in dev-panel you should have something like this (device_state attribute):


It is json file taken from device. You can see how your JSON looks and adjust templates for it.

Looks like typo: stastus_template instead of status_template :wink:

:man_facepalming:

Problem solved! :slight_smile: