How to proceed with this project?

[lanwin]

Hi everyone, I've been thinking about how to proceed with this project over the past few months, and prompted by the discussion at #111, I'd like to ask all of you who have been involved so far for your opinion.

Project Name

I want to rename the project from esphome_samsung_ac to esphome_samsung_hvac to clarify that it is not only about air conditioners but also about heat pumps.

Project Structure

The project has gradually reached a certain level of complexity, and in some cases, it is very difficult to test (especially since I don't have a NonNASA device). Changes sometimes break functions in other areas.

Moreover, the functionality between air conditioners and heat pumps sometimes overlaps and differs.

Both the configuration and the code are becoming increasingly difficult to oversee.

Additionally, there is a desire for the component to become much more flexible and to function more like ESPHome Modbus. No fixed sensors but freely configurable. However, the latter somewhat conflicts with what I want to achieve. While Modbus doesn't have a defined purpose and only represents a protocol, NASA is a generic protocol that represents a defined purpose: controlling air conditioners and heat pumps.

My goal is to keep it as simple as possible, so that even "non-IT people" can integrate it into their smart home.

Furthermore, the AC component should include all standard sensors like (power, pressure, etc.) without having to use custom sensors.

Therefore, I'm considering splitting the whole thing into several components within this project.

Now:

components/samsung_ac

Afterwards:

components/samsung_ac                    # Predefined components for NASA air conditioners
components/samsung_ac_legacy         # Predefined components for NonNASA air conditioners
components/samsung_heatpump       # Predefined components for NASA heat pumps
components/samsung_nasa                # Direct binding to the NASA protocol (custom_sensors, custom_climates)

Each project will get its own example.yaml (which will be much more manageable). The Python stuff will also become much more manageable.

It should then be possible without any problems to use multiple components in one ESPHome project. For example, the basic components for AC and then a few special sensors with the NASA protocol.

The separation will result in some code duplication, but the generic protocol layer and protocol detection can be removed, which simplifies things and prevents a NASA change from breaking NonNASA.

Moreover, it would be conceivable to define maintainers for the individual parts in the future.

Help

I still need your support because I am simply too busy to invest a lot of time into this project.

What is currently missing, however, is something like a vision and defined goals and agreements that someone who wants to get involved can orient themselves to.

In example

Even "non-IT people" can integrate there AC it into their smart home without knowing NASA variables.

The only question is, how could that look like, and what should be included?

I look forward to your feedback!

CC @brazoayeye @Oggy123 @bzumik1 @jbekkema @atanasenko @mbo18 @matthias882 @Foggy2 @dansck @Mongey

[brazoayeye]

Imho samsung_ac and samsung_ac_heatpump could be avoided. A person that can handle an ESPHome installation can probably also read and understand a complete example.yaml and to copy-paste the sensors/climates it needs. Splitting the project in 2 instead of 4 will probably simplify code maintainance.
To keep all sensors usable without specifying addresses (messages), a solution could also be to implement them only in the py file letting the C++ code as agnostic as possible.

I don't know if the same serial port can be used by more components.
Unfortunately my interactions with this project are my first experiences with github and espHome API, I programmed C/py alone for 5 years with a local git where I'm the only user so I lack the experience to manage a project with many users.
However, I can help with refactoring/testing/introducing new functions

[Oggy123]

Hello Steve,

if I can say few words, from my point of view is very surprising how small community is around this project, because I belive there is many users of Samsung ACs or heatpumps and I hope they don't want to rely on cloud integration even if it's so nice'n'easy, because there is no certainity how long it will work. This project gives me hope I can automate it until my device will be functional.

It's necessary to say, I'm not a programmer or hw guy, I just can more or less read code and change small parts of it and put some hw modules together.

I'm not sure if it's necessary to split project to ac and heatpump as it uses same protocol, just maybe create two example.yaml files for each type. Regarding split of nonNASA, I agree as it can interfere to other working code and can clarify the code. But it can be only my point of view, because I don't use HA or ESPHome, my automation is completely written in NodeRed.

I know it's probably not goal of this project, but I can imagine project that will cover all AC/heatpump brands, will work on some kind of plugin libraries and you (as user) just define device functions (windfree etc) and some simple config and everything will work. I'm not sure if you know project IRremoteESP8266, it's one library that have many plugins for ACs, for televisions, for almost everything. Protocol and IR code is described in this plugin, library translate it to/from some standardized output/input. This can be nice. But it will probably need much bigger community around and maybe some support from ESPHome. And off course some brands uses Modbus as its protocol and is easier to integrate them. Samsung also sells Modbus card, but for horrible price.

So to your question, I think if you want to spread widely among people, you should do your config as easy as is installing ESPHome to your ESP board (but have advanced features accessible for geeks), be listed as plugin of ESPHome and then you can cooperate with more programmers, get more help and ...
And off course, I saw on few similar projects they also sell own (or "almost own") hardware preinstalled and preconfigured that can help beginers, because even if ATOM is as simple as can be, this can be added value.

Finally perhaps one answer, maybe you can manage the code to check the bus, enumerate devices and to be plug'n'play, but even non-IT people have to flash ESP module, select right serial interface, set HA and I can't forget, open AC unit and connect the bus and power, maybe more. I think it can't be more easier than now and it will need skilled user everytime.
And to be honest, I'll never recommend any home automation if the user have'nt some skills. It's like fire - good servant, but very bad master.

I hope You'll find the way and I'll be glad, if I can help you somehow

O.

[Foggy2]

Hello @lanwin

I quite like your suggestion of breaking it down into smaller sub-modules that would compartmentalize the code and make it easier to maintain. This seems logical and a smart move but my concern is the availability of others to contribute and maintain those sub-modules.

I would describe myself similar to @Oggy123, I am not a coder but I can understand and make simple adjustments. I use PowerShell frequently at work but C++ is a different beast entirely. This is still a good learning opportunity for me, and I would like to pursue it further however I have been put off from doing so thus far for a number of reasons. Ignoring that I have been integrating over the F3/F4 bus and the complexities that come with that, the main reason I have not contributed anything further is that I struggle to understand how the code works and how it ties into ESPHome/HA.

I am keeping an eye on this project and hope to be able to assist where I can but given the above I am unsure if I would be able to contribute in any significant way.

[omerfaruk-aran]

Hello @lanwin,

First of all, thank you for your project. I have started using ESPHome to integrate Samsung air conditioners with Home Assistant and have had very positive experiences so far. I have been involved in software development and technology for many years, particularly in system integration, database management, and IoT. I am familiar with the NASA protocol used for controlling Samsung air conditioners, and I understand the challenges you are facing while developing this project.

I support your idea of renaming the project and creating a more flexible structure. Renaming the project to "esphome_samsung_hvac" is more descriptive as it also includes heat pumps. Additionally, your suggestion to separate different components makes sense to reduce complexity and provide a clearer structure.

My suggestion would be to make the structure more accessible and user-friendly, especially for "non-IT" users. For this:

Detailed and Simple Documentation: Step-by-step guides can be created to help users integrate their air conditioners quickly and easily. Example YAML files and solutions for common issues can also be included in these guides.

User-Friendly Interfaces: If possible, providing an interface where users can easily set specific parameters could further simplify the integration process.

Support and Feedback Channels: An active support channel where users can report issues and provide feedback could be established. This would be crucial for the project's development and improving user experience.

I would love to contribute and support this project. I can assist particularly in understanding the challenges new users face during the integration process and offering solutions.

Thank you and best regards,

Ömer Faruk Aran

[brazoayeye]

It has been reported that this project uses a good amount of flash but i don't know the real dimension.

Splitting NASA from NON-NASA will surely help to reduce the size.
Also reducing hardcoded messages / logic and moving them to custom sensors/climate will reduce the amount of code hence the size in flash. Py file could be used to give to the final user a simple configuration yaml without hardcoding in C all messages.

Again, idk if the problem is real and if it can be mitigated or not, I only want to report it in this general discussion

[pantherale0]

My view (and something I'm slowly working on in a fork) is to create just a generic NASA protocol handler for esphome (like modbus, ble etc.) where users can define a configuration for any other platforms using the relevant codes that have been documented. Working examples can be provided alongside this, but I think there is quite a lot of functionality in this project (which I understand why) that is not required for all installs (mqtt, hard coded platforms).

By building a separate NASA protocol component, the overall size of installs could be lowered and allow using the microcontrollers for more functionality.

[omerfaruk-aran]

Hi everyone, I've been thinking about how to proceed with this project over the past few months, and prompted by the discussion at #111, I'd like to ask all of you who have been involved so far for your opinion.

Project Name

I want to rename the project from esphome_samsung_ac to esphome_samsung_hvac to clarify that it is not only about air conditioners but also about heat pumps.

Project Structure

The project has gradually reached a certain level of complexity, and in some cases, it is very difficult to test (especially since I don't have a NonNASA device). Changes sometimes break functions in other areas.

Moreover, the functionality between air conditioners and heat pumps sometimes overlaps and differs.

Both the configuration and the code are becoming increasingly difficult to oversee.

Additionally, there is a desire for the component to become much more flexible and to function more like ESPHome Modbus. No fixed sensors but freely configurable. However, the latter somewhat conflicts with what I want to achieve. While Modbus doesn't have a defined purpose and only represents a protocol, NASA is a generic protocol that represents a defined purpose: controlling air conditioners and heat pumps.

My goal is to keep it as simple as possible, so that even "non-IT people" can integrate it into their smart home.

Furthermore, the AC component should include all standard sensors like (power, pressure, etc.) without having to use custom sensors.

Therefore, I'm considering splitting the whole thing into several components within this project.

Now:

components/samsung_ac

Afterwards:

components/samsung_ac                    # Predefined components for NASA air conditioners
components/samsung_ac_legacy         # Predefined components for NonNASA air conditioners
components/samsung_heatpump       # Predefined components for NASA heat pumps
components/samsung_nasa                # Direct binding to the NASA protocol (custom_sensors, custom_climates)

Each project will get its own example.yaml (which will be much more manageable). The Python stuff will also become much more manageable.

It should then be possible without any problems to use multiple components in one ESPHome project. For example, the basic components for AC and then a few special sensors with the NASA protocol.

The separation will result in some code duplication, but the generic protocol layer and protocol detection can be removed, which simplifies things and prevents a NASA change from breaking NonNASA.

Moreover, it would be conceivable to define maintainers for the individual parts in the future.

Help

I still need your support because I am simply too busy to invest a lot of time into this project.

What is currently missing, however, is something like a vision and defined goals and agreements that someone who wants to get involved can orient themselves to.

In example

Even "non-IT people" can integrate there AC it into their smart home without knowing NASA variables.

The only question is, how could that look like, and what should be included?

I look forward to your feedback!

CC @brazoayeye @Oggy123 @bzumik1 @jbekkema @atanasenko @mbo18 @matthias882 @Foggy2 @dansck @Mongey

Hi Lanwin,

I believe it’s the right time to move forward with the plans you outlined for the project. I suggest we start by renaming the project to esphome_samsung_hvac to better reflect its broader scope, including both air conditioners and heat pumps.

We should then proceed with restructuring the project into the following components:

components/samsung_ac - Predefined components for NASA air conditioners
components/samsung_ac_legacy - Predefined components for NonNASA air conditioners
components/samsung_heatpump - Predefined components for NASA heat pumps
components/samsung_nasa - Direct binding to the NASA protocol (custom_sensors, custom_climates)

Initially, we can create identical components for all sections and gradually refine and update them as we progress.

Let me know your thoughts!

[lanwin]

@tfoutfou can you please move your request to a separate discussion and delete it here. This is not related to this topic.

[blka]

Hi , quick presentation , long time Arduino DIYer and home automation DYIer , i have managed to do pretty much whatever i want and more. but have never used ESPHome or Home Assistant

have been using a device to read SAMSUNG AC , made by "INTESIS" , convert NON-NASA to RS485 MODBUS i can read the MODBUS register and get every interresting value and control the HVAC , no problem , expect the box just died and cost too much , 250+$

i am looking for free DYI way , so this repository seem to be OK

so far i have : -> installed ESPHOME , both on linux or windows -> flashed , connected and adopted my first ESP32 -> create new device and copy exemple.yaml , replaced wifi credentials , OTA

tried to install this config and get error about "indentation" , tried to fix for hours and hours , dont know what i am doing wrong [non_nasa_keepalive] is an invalid option for [samsung_ac]. Please check the indentation. [capabilities] is an invalid option for [samsung_ac]. Please check the indentation.

(cant post file it dont show up nicely) but i download the exemple and just modified wifi creds

Please help , it must be a stupid error

Change
source: github://lanwin/esphome_samsung_ac@stable
to
source: github://lanwin/esphome_samsung_ac@main
Branch and recompile.

[tfoutfou]

done , you can delete your request too ;)

[lanwin]

I now changed the project name #196