Yes of course that’s already a thing.
I’ve just made it public: https://github.com/users/davidusb-geek/projects/1
3 Likes
Hi,
I apologize if that was already answered, but how you achieve that a deferrable (e.g. EV) is charged before x time next morning and charging duration is known in the previous evening.
Obviously, EV charging optimization objective is pick hours when grid electricity is at lowest price and should not consume battery too. Thanks
I am not so familiar with curl yet. So I am pressing the button on the EMHASS web interface. Can I fetch somewhere what curl this button is generating?
This is a very new features just released in the last version of EMHASS so there aren’t too many examples in use out there so you may have to do some experimenting:
https://emhass.readthedocs.io/en/latest/lpems.html#timewindows-for-deferrable-loads
Basically if you would like to constraint the optimisation so your car will finishing charging in 12 hours and you are using 30 minute time steps you would set the value of def_end_timestep to 24 (12*30).
To have the car ready at a certain time (say 10:00) you need to create a template to set def_end_timestep to the amount of time steps between now() and 10:00.
Which is what I did below:
1 Like
https://emhass.readthedocs.io/en/latest/mlforecaster.html#a-basic-model-fit
This covers the subject in the documentation.
Yes correct, that could be a workaround.
From the EMHASS side we don’t know when data is available.
It seems over complicated to design an algorithm that automatically check since when data is available right?
Yes I guess that this seems like the best option, along with a big warning sign in the logs because the optimization won’t be that realistic
Those button are just calling the basic curl commands without any runtime passed params.
The curl commands looks like this in your Home Assistant configuration.yaml using the shell_command integration
shell_command:
dayahead_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/dayahead-optim"
publish_data: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/publish-data"
Just as an addition to what @markpurcell said.
The template sensor could look like this:
{{ (((states("input_datetime.emhass_p_deferable_1_end_time")|as_timestamp)-now()|as_timestamp)/1800)|int }}
In this example I leverage a input_datetime helper which then can be set by a hand or an automation (e.g. to force a run in the next x hours).
This is just to get an idea. I think there is further finetuning necessary, depending on the setup. E.g. negative value handling, shorter timeframes then expected hours to run…
3 Likes
To complement this: that’s exactly how I implemented my input_datetime helper as well.
Regarding exception handling:
I’ve built the timewindow feature in EMHASS in such a way that it gracefully deals with exceptions:
- if your datetime helper has a value in the past, the end_timestep value it provides to EMHASS is negative. EMHASS then just ignores your end constraint and extends the deferrable load timewindow till the end of the prediction horizon.
- if the time between now and the proposed end timestep is too short, because it conflicts with the specified number of hours the deferrable load needs to run, EMHASS will issue a warning, warning that the optimization lead to an unfeasible outcome. (I’ve considered to let EMHASS even automatically extend the specified deferrable load timewindow, but there’s multiple degrees of freedom, so not implemented at this moment)
1 Like
IndexError: list index out of range → after the latest Update
If anyone else is feeling desperate, just like I was after the latest update: I figured out what the problem was.
I kept getting an „IndexError: list index out of range“ error and didn’t know what was causing it, and I was really starting to despair.
Solution: since the update, there are two new variables for the deferrable_loads, I have three deferrables in the configuration.
But my third consumer was not automatically included in the new variables in the configuration after the update (list_start_timesteps_of_each_deferrable_load and list_start_timesteps_of_each_deferrable_load), and there was no error message in the config either.
This could perhaps be easily resolved in the configuration by asking a question, for example, if there are three consumers but only two are entered for the variable time out, a short note or an error message could appear when saving the configuration.
… and yet again a huge thank you for this addon and to all those who help with it
1 Like
Thanks for clarifying this.
Yes there is room for improvement.
There is work to do on automatic configuration and management and at least some improvement on logging configuration inconsistencies
2 Likes
Just added a number a whole bunch of actions to the todo list in github projects to continuosly improve the code. see: https://github.com/users/davidusb-geek/projects/1/views/1
Anyone feel free to contribute to these improvements. 
Something har changed with emhass 0.6.2. I get "IndexError: list index out of range“ error with emhass 0.6.2, but not with emhass 0.6.1 when I run day-ahead optimization using the same emhass config.
I have already updated the variabel “list_start_timesteps_of_each_deferrable_load” and “list_stop_timesteps_of_each_deferrable_load” as @prinzkafka mention, when emhass 0.6.1 was released.
I have made a issue about this here: emhass 0.6.2 IndexError: list index out of range · Issue #74 · davidusb-geek/emhass-add-on · GitHub
I only ever make suggestions for newbie onboarding, without actually developing anything, sorry 
Has anyone considered making a publishable / supportable Blueprint? That might be a good way to gather and standardise some of the obvious use cases…
- using Solcast
- scheduling a single load
etc.
I work in University IT Services, so I worry more about supporting masses of users and avoiding them all asking the same questions, than about developing
We can see the warning in the container/addon log
and the sensor changes to “Infeasible”
Would be nice if we could have the warning added as an additional attribute to this sensor. So we can access it to use it in alerts / notifications etc. Furthermore it should be added to the Web UI as well.
Solved with the latest quick fix release.
Sorry about this.
2 Likes
Hi @davidusb ,
I saw in github that you asked for my contribution to a next feature.
Happy to help, however I’m currently struggling with the setup of my development environment.
I developed the previous feature purely by editing files directly in Github, which is not very sustainable. So I wanted to spin up the devcontainer in my VScode.
This is not successful, I’m running into an error:
[294 ms] Dev Containers 0.338.1 in VS Code 1.86.0 (05047486b6df5eb8d44b2ecd70ea3bdf775fd937).
[294 ms] Start: Resolving Remote
[305 ms] Setting up container for folder or workspace: c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass
[307 ms] Start: Run: wsl -l -v
[371 ms] Start: Run: wsl -d docker-desktop-data -e /bin/sh -c echo ~
[520 ms] Could not connect to WSL.
[520 ms] Command failed: wsl -d docker-desktop-data -e /bin/sh -c echo ~
[520 ms]
[520 ms]
[522 ms] Start: Check Docker is running
[522 ms] Start: Run: docker version
[732 ms] Client:
Cloud integration: v1.0.31
Version: 23.0.5
API version: 1.42
Go version: go1.19.8
Git commit: bc4487a
Built: Wed Apr 26 16:20:14 2023
OS/Arch: windows/amd64
Context: default
Server: Docker Desktop 4.19.0 (106363)
Engine:
Version: 23.0.5
API version: 1.42 (minimum version 1.12)
Go version: go1.19.8
Git commit: 94d3ad6
Built: Wed Apr 26 16:17:45 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.20
GitCommit: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
runc:
Version: 1.1.5
GitCommit: v1.1.5-0-gf19387a
docker-init:
Version: 0.19.0
GitCommit: de40ad0
[743 ms] Start: Run: docker volume ls -q
[927 ms] Start: Run: docker ps -q -a --filter label=vsch.local.folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --filter label=vsch.quality=stable
[1110 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --filter label=devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json
[1278 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass
[1454 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass
[1633 ms] Start: Run: C:\Users\me\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js read-configuration --workspace-folder c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --id-label devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --id-label devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --log-level debug --log-format json --config c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --mount-workspace-git-root
[2127 ms] @devcontainers/cli 0.56.0. Node.js v18.17.1. win32 10.0.22631 x64.
[2127 ms] Start: Run: git rev-parse --show-cdup
[2216 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --filter label=devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json
[2446 ms] Start: Run: C:\Users\me\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js up --user-data-folder c:\Users\me\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --container-session-data-folder /tmp/devcontainers-3aa7c6a6-629a-4277-bd29-c1ebaaaa2b771707121559412 --workspace-folder c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --workspace-mount-consistency cached --id-label devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --id-label devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --log-level debug --log-format json --config c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root --terminal-columns 195 --terminal-rows 28
[2985 ms] @devcontainers/cli 0.56.0. Node.js v18.17.1. win32 10.0.22631 x64.
[2985 ms] Start: Run: docker buildx version
[3392 ms] github.com/docker/buildx v0.10.4 c513d34049e499c53468deac6c4267ee72948f02
[3392 ms]
[3392 ms] Start: Resolving Remote
[3396 ms] Start: Run: git rev-parse --show-cdup
[3472 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --filter label=devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json
[3670 ms] Start: Run: docker inspect --type image mcr.microsoft.com/devcontainers/python:0-3.11
[3884 ms] Resolving Feature dependencies for 'ghcr.io/devcontainers/features/docker-outside-of-docker:1'...
[3884 ms] * Processing feature: ghcr.io/devcontainers/features/docker-outside-of-docker:1
[4117 ms] Start: Run: docker-credential-desktop get
[4759 ms] * Processing feature: ghcr.io/devcontainers/features/common-utils
[5164 ms] Soft-dependency 'ghcr.io/devcontainers/features/common-utils' is not required. Removing from installation order...
[5165 ms] * Fetching feature: docker-outside-of-docker_0_oci
[5525 ms] * Fetched feature: docker-outside-of-docker_0_oci version 1.3.2
[5533 ms] Start: Run: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f C:\Users\me\AppData\Local\Temp\devcontainercli\container-features\0.56.0-1707121563990\Dockerfile-with-features -t vsc-emhass-81305847820dad65efa558562efe33e9aceefd65700622d86b533bfa63a61225 --target dev_containers_target_stage --build-context dev_containers_feature_content_source=C:\Users\me\AppData\Local\Temp\devcontainercli\container-features\0.56.0-1707121563990 --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label --build-arg _DEV_CONTAINERS_IMAGE_USER=root --build-arg _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass
[+] Building 2.4s (11/17)
=> [internal] load build definition from Dockerfile-with-features 0.1s
=> => transferring dockerfile: 3.30kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:1.4 1.2s
=> CACHED docker-image://docker.io/docker/dockerfile:1.4@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc 0.0s
=> [context dev_containers_feature_content_source] load .dockerignore 0.0s
=> => transferring dev_containers_feature_content_source: 2B 0.0s
=> [internal] load metadata for mcr.microsoft.com/devcontainers/python:0-3.11 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 1.02kB 0.0s
=> [dev_container_auto_added_stage_label 1/3] FROM mcr.microsoft.com/devcontainers/python:0-3.11 0.0s
=> [context dev_containers_feature_content_source] load from client 0.0s
=> => transferring dev_containers_feature_content_source: 33.94kB 0.0s
=> CACHED [dev_container_auto_added_stage_label 2/3] COPY .devcontainer/setup.sh requirements.txt requirements_webserver.txt ./ 0.0s
=> ERROR [dev_container_auto_added_stage_label 3/3] RUN ./setup.sh 0.8s
------
> [dev_container_auto_added_stage_label 3/3] RUN ./setup.sh:
#0 0.791 /usr/bin/env: ‘bash\r’: No such file or directory
------
Dockerfile-with-features:6
--------------------
4 |
5 | COPY .devcontainer/setup.sh requirements.txt requirements_webserver.txt ./
6 | >>> RUN ./setup.sh
7 |
8 |
--------------------
ERROR: failed to solve: process "/bin/sh -c ./setup.sh" did not complete successfully: exit code: 127
[8706 ms] Error: Command failed: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f C:\Users\me\AppData\Local\Temp\devcontainercli\container-features\0.56.0-1707121563990\Dockerfile-with-features -t vsc-emhass-81305847820dad65efa558562efe33e9aceefd65700622d86b533bfa63a61225 --target dev_containers_target_stage --build-context dev_containers_feature_content_source=C:\Users\me\AppData\Local\Temp\devcontainercli\container-features\0.56.0-1707121563990 --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label --build-arg _DEV_CONTAINERS_IMAGE_USER=root --build-arg _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass
[8706 ms] at Y$ (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:465:1933)
[8706 ms] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[8706 ms] at async Fw (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:464:1831)
[8706 ms] at async $J (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:464:608)
[8707 ms] at async tAA (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:481:3660)
[8707 ms] at async CC (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:481:4775)
[8707 ms] at async NeA (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:614:11107)
[8707 ms] at async MeA (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js:614:10848)
[8733 ms] Exit code 1
[8738 ms] Command failed: C:\Users\me\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-containers-0.338.1\dist\spec-node\devContainersSpecCLI.js up --user-data-folder c:\Users\me\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --container-session-data-folder /tmp/devcontainers-3aa7c6a6-629a-4277-bd29-c1ebaaaa2b771707121559412 --workspace-folder c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --workspace-mount-consistency cached --id-label devcontainer.local_folder=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass --id-label devcontainer.config_file=c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --log-level debug --log-format json --config c:\Users\me\SynologyDrive\sandbox\2024-02-05_Onion_EMHASS\emhass\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root --terminal-columns 195 --terminal-rows 28
[8738 ms] Exit code 1
Anyone has got an idea on what’s going wrong?
Seems like an error in the setup.sh script, but I’m not sure what’s wrong.
In general, I’m struggling a lot in setting up a decent Python dev environment in VScode. Steep learning curve. Any useful tutorial recommendations are very much welcome as well. 
Was this solved in the latest release? What makes it a boundary condition and what can I change/tweak so that it doesn’t do that anymore?