Merge Add-on and Standalone modes

davidusb-geek / emhass

emhass: Energy Management for Home Assistant, is a Python module designed to optimize your home energy interfacing with Home Assistant.

MIT License

260 stars 51 forks source link

Merge Add-on and Standalone modes #269

Open GeoDerp opened 2 months ago

GeoDerp commented 2 months ago

Discussion starting in: https://github.com/davidusb-geek/emhass/issues/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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 standaloneand 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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.