Merge Add-on and Standalone modes

[GeoDerp]

Discussion starting in: #262
EMHASS is probably in a sate where we could choose to use the local or external HA API automatically based on API key (SUPERVISOR_TOKEN). Removing the need of passing it via arguments.
Allowing for both Standalone and Add-on modes to merged into one.

This may be something I'll look into when I have some time. I am sure all help will be appreciated.

[GeoDerp]

@davidusb-geek , I see the biggest decision being what we should do with the configuration files. If everyone should move over to the options.json or still have the two.

[davidusb-geek]

Yes if this merge is done the best idea would be to just keep one type of conf file. The options.json would make more sense as it is widely the most used along with the add-on.
As for this merge, what would be the consequences for people just using the add-on mode?

[GeoDerp]

Yes if this merge is done the best idea would be to just keep one type of conf file. The options.json would make more sense as it is widely the most used along with the add-on.
As for this merge, what would be the consequences for people just using the add-on mode?

I think there will be any noticeable difference for add-on. It would be more the standalone users adjusting to using options.json... Atleast I believe.

[GeoDerp]

My thoughts on the steps that would be carried out:

• Integrate auto select local API, based on passed API key and if SUPERVISOR_TOKEN is present.
  • Add redundancy. (E.g. if passed API fails, try local)
• Migrate all parameters naming conventions to options.json's?
• Adjust Dockerfiles
• Remove standalone and add-on naming convention on CI/CD
• Adjust Documentation
  • Remove all documentation explaining differences between new modes
  • Adjust Readme
  • Adjust Development pipeline tests
    • Add documentation for both EMHASS & EMHASS-Add-on git repos
• Remove config.json all together and hard code defaults?

This is supper quick/ruff. I'll come back to this checklist after some more thought. Please feel free to comment.

[davidusb-geek]

It seems like a very complete planning.
We will still need two Dockerfiles right? One in the main emhass git repo and the other one in the add-on repo? At the end they will be fairly similar? Or even the same Dockerfile?

[GeoDerp]

It seems like a very complete planning.
We will still need two Dockerfiles right? One in the main emhass git repo and the other one in the add-on repo? At the end they will be fairly similar? Or even the same Dockerfile?

Good question, I have been thinking about the idea of merging both repos together. (I know it's a long shot)

At the moment the EMHASS-Add-on Dockerfile is pulling EMHASS via pip before it creates the image.
If we don't mind building EMHASS locally for EMHASS-Add-on, I don't believe there will be many reasons why we can't merge the Dockerfiles.

I would need to check if the FROM tag could work in both situations.

[davidusb-geek]

I have been thinking about the idea of merging both repos together.

I don't like the idea of merging the repos. The add-on repo has the structure of a HA add-on repo, while this one has the structure of a Python package. I would like to keep that as I like the option that EMHASS can be used completely independent of HA, you just provide the correct data and it will crunch it and perform the optimization, it doesn't matter if this data comes from HA, a CSV file or a list passed by a REST command.

[davidusb-geek]

Closing this as completed with #334