Added CustomClimate, set a couple of custom sensors, added debug_number to easily scrap packets #111
Conversation
It allow to print debug messages only when they match a source and a value settable using number component in HA
Added power_consumption
brazoayeye
changed the title
|
@brazoayeye thank you for that pullrequest! |
|
hey what is the status? I really would like to see the energy consumption added to main. Thanks |
|
Same here - looking forward for the power consumption sensor. Thank you!! |
I haven't followed developments in this branch in the last months, but using my branch for me works well (except like 20% of writing fails) and i have the climate option for heating/cooling and dwh. The configuration is not handy for presets and working modes, but that's the only option i found to give flexibility in the config file. Test and suggestione are well accepted |
|
I'll try flashing it in the next couple of days and have some feedback once I do. I am not using presets so that's a non-issue for me. Thanks. |
I have a power consumption sensor via a custom sensor. Here is my config for the heat pump (addr 10:00:00) Note, the model for my unit is |
|
@brazoayeye thank you for your pullrequest and all of your work! I am a little bit torn about this. On one hand it adds a lot flexibility. On the other hand I can not see more "climates" controls then the ones you already figured it. What else should come there? And making all configurable adds a lot of complexity witch needs to be supported in the future. I already have problems digging thru your changes. And also, more flexibility means that new users need to understand it, look for the message ids and need to understand what they are doing. So maybe it would be better to just add specific controls dedicated to the configuration that you already figured out so new users just need to add them and given them a name. Dedicated controls add more code, but usually they tend to be simpler and easier to understand and fix. |
|
Maybe an easy fix could be a shortcut in the py file to easen the setup of the yaml. But it desn't remove the underground complexity i wasn't able to avoid to allow users to select custom addresses and behavior. I admit i'm not an expert regarding espHome and that i don't have any experience with heat pumps except from mine, so i can't assume other setups are similar to mine. For example:
Refactoring and simplifications could (and should) be done, but I would like to have a feedback regarding other heat pumps or code suggestions. Otherwise I'll reach a very similar result. This is my first time using github and I made some mistakes trying to amend a commit, but I tried to publish step by step while adding features so you can check modifications easier. If I can help, please tell me how |
|
[brazoayeye] , lanwin |
|
@Krzysiek1976 Have you seen 0x4299 and 0x8061 in the communication? You can implement them adding a custom sensor for example @lanwin I think that the project started with the wrong idea of mixing code and parameterizations, and that caused many enums and avoidable rows of code. Imho a refactoring should be done to remove all hardcoded messages and to expand the example to include all working configurations as the list of custom sensors (as provided by pantherale0) and custom climates. This is not intended as a criticism of the work done, that's very good, but only as a point of reflection and a discussion to simplify future work. I also skipped to analyze the non-nasa protocol, that seems much more fixed and less flexible and for wich could be right to keep values fixed. In my code I decided to call Presets and Mode by number (ex ClimatePreset0Value, ClimateMode3Value) to keep it as transparent as possible to future EspHome changes, but it's probably a fail because the parameterization is counterintuitive. It's probably better to link them directly with espHome enums. |
|
I am just randomly passing by through this PR as a user, so I don't know the details, but I think what @brazoayeye makes sense to me and is close to what I know from some other integrations (such as ESPHome Modbus integration, e.g. here). |
|
@brazoayeye I am still not sure what is the best option to go here. Moving everything to custom_sensor and custom_climates is not as bad as an idea. But the problem is that this does not includes the non nasa stuff with (as you correctly discovered) it is static and dont use the flexible message. It might be possible to change the non nasa stuff and create an adapter witch converts the non nasa messages to nasa messages and back. But this adds also another layer of indirection. Especially the a message in nasa can be one variable. NonNasa messages often have multiple values and you need to send all of them to make it work. Maybe its a good split nasa and non nasa into separate components. But then also all features need to get added twice. I also fear the complexity a bit. I have 23 years of experience in development and as I was younger I often also preferred ultra generic solutions cause they ware cool. But the last years I mostly moved to use specific code for specific problems and most of the time this turned out to be more reliable and easier to support and change. Regarding the custom_sensors. My plan is still to add dedicated sensors for most of the basic stuff like power, pressue etc. So you simple need to give them a name. @hnykda you can not directly compare integrations like Modbus to this one. This is not an NasaProtocol component witch let you adapt to any device that users the NASA protocol. It was designed in the first place to easily add my AC to home assist. Modbus is also a good example what I mean by being too generic. You have to know how modbus works. Know exactly witch coils and addresses to use and witch modifiers to apply. That is pretty complex for someone how dont is an IT person. Meybe that is exactly the point. Maybe its better provide a generic "components\samsung_nasa" components along with "components\samsung_ac_nasa" and "components\samsung_ac_nonnasa", witch then works like modbus and the components share the nasa protocol and utility classes underneath. This would allow to create examples for each and reduces complexity. (Component means sub folder not github repository). Also there is the problem that this project startet mainly for AC devices and now there are also heatpump users. Maybe there also should be "components\samsung_headpump". So I struggle with where to go now. I also would like to invite more people to directly change the codebase and make it easier for me (since I am pretty bound to other stuff). But before that happens I need to ensure that we all agree on some basics pricipals and a plan where to go. Splitting things up also would have the benefit that I could assign maintainers to specific parts like the non nasa stuff where I always will have the problem that I can not test that stuff. Maybe I should start a discussion and invite the other contributors to this discussion. |
|
You are entirely right; I like your thinking about this and really appreciate your careful reasoning around UX as well as developer experience here (also that you think about long-term maintenance, including other contributors ❤️ ). The proposal for the split looks like a great idea. Seems like that would make it very extensible on all fronts (both generic NASA, making non-nasa stuff separate so not poluting the new stuff, being able to add additional devices next to ACs, such as heatpumps and other stuff, ...)? Btw. you might consider renaming the repository before it gets too popular (removing the Btw. I would consider asking directly the HA/ESPHome maintainers/developers for an opinion, I suspect this will be a very common issue/consideration, and they might be willing to help. And if not them, maybe someone from similar projects might? |
|
@brazoayeye I think this is great work, although I have to agree with @lanwin. My personal opinion is this project should be kept as the interface with the AC/Heatpump for controls and sensors as needed. I actually wouldn't even have the climate that @lanwin put in the project already. Exposing the controls needed allows for all users to build their own climate control in HA the way they see fit. I use weather compensation and have a complex set up that controls the needed compensation curve. Other will have all sorts of different set up. So why complicate this project? I also wouldn't put all the sensors hard coded in there @lanwin - you have created the ability to add custom sensor, to @brazoayeye's point people may not know about them, and certainly not all the options available of them. So I suggest we add more examples, maybe not in the examples.yaml, maybe we create some sensor example yaml's to help users. I'll raise a pr to add some examples We could also do with expanding the custom sensor, or adding more custom sensor types So then we just have the controls implemented and sensors can be added using the custom sensor approach, keeping the code as simple as possible but the flexibility everyone needs. I'll pick up more on your how to proceed with project discussion @lanwin |
|
I made this modification to allow my HASS to control the heating/ DWH temperature to follow photovoltaic production. Not knowing all code stuffs already presents, and not finding anything related or fitting my needs in the examples, I supposed there weren't any other way to change the setpoint except from coding a new one. I've chosen the climate instead of a simple control because it (nearly) perfectly fits the samsung concept with Set - read - presets - modes so It seemed the most logic option even for HASS views. |
|
So now I added the PRs for sensors and other stuff I have done, I have implemented a climate control using the esphome climate and the sensors for the Samsung heatpump. So I think it makes sense to share yaml examples for people to implement their own instead of adding a custom climate to the code. I may be missing something, what are you not able to do using an esphome climate control? |
|
I don't know what you mean with espHome climate control, because this is my first project with esp home and i didn't reach my goal without programming. I have two setpoint, one for dwh and another for heating/cooling. Both have their status temperature. One have a climate mode, the other have a preset. I use esphome terms but i don't know how they are called by samsung. Presets are like eco - standard - power for dwh Could I implement them without my code? Thanks |
|
@brazoayeye yeah this is my first go of using esphome, so I am far from an expert. I am just learning, but you can configure whatever you want in it. Take a look in their docs at the climate thermostat and there is all the other components you can setup. So I have set up DHW with the samsung heatpump, I need to do a proper example.yaml etc but for now, here is my config.. you need the indoor device controls I added water_heater_power:
name: "DHW Power"
id: dhw_power
water_temperature:
id: hot_water_current_temp
water_heater_mode:
id: hotwater_mode
water_target_temperature:
id: hot_water_target_tempNB Using id only and no name makes it internal (wont be exposed to home assistant) Then to create my domestic hot water climate I add this to my esphome yaml: climate:
- platform: thermostat
name: "Hot Water"
id: climate_hot_water
sensor: hot_water_current_temp
min_heating_off_time: 300s
min_heating_run_time: 300s
min_idle_time: 30s
on_state:
- number.set:
id: hot_water_target_temp
value: !lambda return { x.target_temperature };
- if:
condition:
switch.is_on: dhw_power
then:
- select.set:
id: hotwater_mode
option: !lambda |-
if (id(climate_hot_water).target_temperature > id(hp_dhw_max_temp).state) {
return { "Standard" };
} else {
return { "Eco" };
}
preset_change:
- if:
condition:
lambda: return id(climate_hot_water).preset == CLIMATE_PRESET_BOOST;
then:
- component.suspend: dhw_preset_mode
- delay: 45min
- component.resume: dhw_preset_mode
heat_action:
- switch.turn_on: dhw_power
- select.set:
id: hotwater_mode
option: !lambda |-
if (id(climate_hot_water).target_temperature > id(hp_dhw_max_temp).state) {
return { "Standard" };
} else {
return { "Eco" };
}
idle_action:
- switch.turn_off: dhw_power
heat_deadband: 5
heat_overrun: 0
default_preset: ECO
preset:
- name: ECO
default_target_temperature_low: 40 °C
- name: HOME
default_target_temperature_low: 45 °C
- name: AWAY
default_target_temperature_low: 20 °C
- name: BOOST
default_target_temperature_low: 55 °C
- name: SLEEP
default_target_temperature_low: 70 °C
visual:
min_temperature: 20
max_temperature: 70
temperature_step:
target_temperature: 1
current_temperature: 0.1I've left the automations within the climate config so you can see them, but you can prob take those out. I set up a sensor with id hp_dhw_max_temp, this is the temp at which the heat pump is set to use the compressor to heat hot water, so when I request water hotter than that (which I do overnight on cheap rate) it flicks it out of eco and into standard. We should be able to get that from 0x427C but it doesnt work for me so I hard coded it for now. |
Nothing more than title, nothing less.
Described on example.yaml