Comments (8)
When was this first time that you tried? There has been a lot of improvements for these types of issues thanks to the work of @GeoDerp earlier this year. There is now a treatment for setting default values when they are not specified by the user.
The configuration file in the add-on was also updated and rearranged for better treatment of optional and non-optional params. But there is probably more room for improvement. Although this is foe the add-on installation method and not the docker standalone, so that may not be completely irrelevant
from emhass.
When was this first time that you tried? There has been a lot of improvements for these types of issues thanks to the work of @GeoDerp earlier this year. There is now a treatment for setting default values when they are not specified by the user.
The configuration file in the add-on was also updated and rearranged for better treatment of optional and non-optional params. But there is probably more room for improvement. Although this is foe the add-on installation method and not the docker standalone, so that may not be completely irrelevant
Hey @werdnum, you probably have some good ideas, as @davidusb-geek already mentioned we have done some parameter defaulting in the add-on version of EMHASS.
Standalone
so far we just assumed people left the defaults in. (not saying we can't change this)
If you like, try running the add-on
version of EMHASS and see what you think. You will need to convert your parameters (including their respective parameters name changes) from the config.yaml to the options.json. (note you should be able to remove all the options.json parameters and it should still function). You will need to revert the config.yaml to it defaults in order for the add-on mode to work.
I'll update this comment Tomorrow with more details on this (currently writing this on bed with 1% battery life). But for now have a look at https://emhass.readthedocs.io/en/latest/develop.html#docker-run-add-on-via-with-local-files for docker run command difference, and https://emhass.readthedocs.io/en/latest/differences.html for the parameter name differences between standalone
and add-on
.
Hope that helped. 😁
Sorry in advance for all the spelling errors.
from emhass.
If you with to grab the image via a container registry: (not build the image locally)
- EMHASS amd64 add-on: https://hub.docker.com/r/davidusb/image-amd64-emhass
- Docker run example:
This assumes secrets are passed via options.json. Alternately, you can mount the secrets file also and EMHASS should reference it.
docker run -it -p 5000:5000 --name emhass-container -v $(pwd)/options.json:/app/options.json davidusb/image-amd64-emhass:latest
docker run -it -p 5000:5000 --name emhass-container -v $(pwd)/options.json:/app/options.json -v $(pwd)/secrets_emhass.yaml:/app/secrets_emhass.yaml davidusb/image-amd64-emhass:latest
from emhass.
I'm not sure I understand the difference between the 'addon' and the regular version of EMHASS. I thought addons were just for HAOS, and I'm not using HAOS, so I am just using the normal version. Is the addon version better supported or something?
from emhass.
I'm not sure I understand the difference between the 'addon' and the regular version of EMHASS. I thought addons were just for HAOS, and I'm not using HAOS, so I am just using the normal version. Is the addon version better supported or something?
Thats correct, add-on
was designed with HAOS in mind, It has better support for validating parameters. Standalone
and Add-on
mode aren't that mutch different in the way they operate besides the parameters.
In saying this this is the first time trying out the container via DockerHub and I seem to be running into some issues (I know why , i'm just not sure whats the best outcome ). Having a look at it now.
from emhass.
As a meta question, what's the point in having a separate standalone type if the add-on version doesn't actually require running under HAOS? Would it make sense to maintain only the add-on version, or at least to strongly encourage preferring it over the standalone one?
from emhass.
I think the best way to use add-on mode is via passing in the arguments via the standalone mode Image
docker run -it -p 5000:5000 --name emhass-container -v $(pwd)/options.json:/app/options.json davidusb/emhass-docker-standalone --addon true --no_response True
from emhass.
As a meta question, what's the point in having a separate standalone type if the add-on version doesn't actually require running under HAOS? Would it make sense to maintain only the add-on version, or at least to strongly encourage preferring it over the standalone one?
Good question. The one main difference is that add-on mode calls HA via its local API to gain location and timezone information.
In reality, it wouldn't be impossible to create an alternative method to check if its running in HAOS (to use the local API or not). Then standalone
and add-on
could be merged.
You could ask it to check via If the Local API supervisor key exists.
Since everyone is already using one or the other. This may be a good change to implement on a large version release. And it may be good to make sure legacy users are not impacted.
PS. Up to recently, there has been more differences between the two. We have been slowly merging them together.
from emhass.
Related Issues (20)
- Data posted via home assistant is different to what appears in the EMHASS logs HOT 6
- Infeasible result with 0.10.1, optimal with 0.9.1 HOT 4
- Feature request: Provide p_hybrid_inverter as a sensor HOT 2
- Sensor unit: Unit is missing for 'Total cost function value' HOT 1
- load_cast_forecast nordpool fails, HOT 7
- pv_forecast is not aligning with JSON input for naive-mpc-optim command HOT 4
- Unable to connect to home assistant HOT 2
- Warning: deprecated lags_grid argument HOT 1
- Feature Request: Pd_max/Pc_max as runtime parameters HOT 3
- 400 error on call HOT 1
- Feature Request: Support solcast/Forecast.Solar
- Feature Request: Support dynamic electricity prices HOT 4
- Custom machine learning forecast model predict HOT 1
- Solcast shows values at night HOT 4
- Optimisation at times exceeds p_nom for deferrable loads HOT 1
- Cannot install add-on HOT 4
- Feature request: minimum continous runtime for each deferrable load HOT 1
- Same as 328 - missing image update to0.10.6 HOT 12
- sometimes error since 0.10.6 MPC HOT 1
- Feature Request: Cost/profit comparison
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from emhass.