-
Describe the bugI'm new to EVCC and I've tried the configuration in this community post. #6617 With the example from the community I don't get an error message but the addon under HomeAssistant doesn't start correctly with this configuration, eg. the EVCC page stays in the startup phase "The add-on is starting, this can take some time...". With the demo wallbox everything seems to be ok: Steps to reproduce
Configuration detailsnetwork:
# schema is the HTTP schema
# setting to `https` does not enable https, it only changes the way URLs are generated
schema: http
# host is the hostname or IP address
# if the host name contains a `.local` suffix, the name will be announced on MDNS
# docker: MDNS announcements don't work. host must be set to the docker host's name.
host: evcc.local
# port is the listening port for UI and api
# evcc will listen on all available interfaces
port: 7070
interval: 30s # control cycle interval. Interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
# database configuration for persisting charge sessions and settings
# database:
# type: sqlite
# dsn: <path-to-db-file>
# sponsor token enables optional features (request at https://sponsor.evcc.io)
# sponsortoken:
# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true
# log settings
log: info
levels:
site: debug
lp-1: debug
lp-2: debug
cache: error
db: error
# modbus proxy for allowing external programs to reuse the evcc modbus connection
# each entry will start a proxy instance at the given port speaking Modbus TCP and
# relaying to the given modbus downstream device (either TCP or RTU, RS485 or TCP)
modbusproxy:
# - port: 5200
# uri: solar-edge:502
# # rtu: true
# # readonly: true # use `deny` to raise modbus errors
# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:
- name: grid
type: template
template: victron-energy
usage: grid
host: 192.168.1.7 # IP-Adresse oder Hostname
port: 502 # Port (optional)
meterid: 30 # Grid-Energiezähler VRM instance- kann im VRM Portal oder im RemoteUI ausgelesen werden. (optional)
minsoc: 20 # Ladung mit maximaler Geschwindigkeit bis zu dem angegeben Ladestand unabhängig PV-Erzeugung, wenn der Lademodus nicht auf 'Aus' steht (optional)
maxsoc: # optional
- name: pv
type: template
template: victron-energy
usage: pv
host: 192.168.1.7 # IP-Adresse oder Hostname
port: 502 # Port (optional)
- name: battery
type: template
template: victron-energy
usage: battery
host: 192.168.1.7 # IP-Adresse oder Hostname
port: 502 # Port (optional)
capacity: 9.8 # Akkukapazität in kWh (optional)
- name: charge
type: template
template: shelly-1pm
usage: charge
host: 192.168.1.60 # IP address or hostname
channel: 0
# charger definitions for generic charger via MQTT
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for documentation see https://docs.evcc.io/docs/devices/chargers
chargers:
- name: Carport
type: custom # or default
status: # charger status A..F
source: mqtt
topic: carport/lp/1/ChargeStatus
timeout: 10m
enabled: # charger enabled state (true/false or 0/1)
source: mqtt
topic: carport/lp/1/ChargePointEnabled
timeout: 10m
enable: # set charger enabled state (true/false or 0/1)
source: mqtt
topic: carport/set/lp/1/ChargePointEnabled
payload: ${enable:%d}
timeout: 10m
maxcurrent: # set charger max current (A)
source: mqtt
topic: carport/set/lp/1/AConfigured
timeout: 10m
# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for documentation see https://docs.evcc.io/docs/devices/vehicles
vehicles:
- name: car1
type: renault
title: Zoe
capacity: 52 # kWh
user: luxxxxxx@xxxxxx # user
password: xxxxxxxxxxxxxxxxxxx
vin: # .WREN.Car ID..
onIdentify: # set defaults when vehicle is identified
# mode: pv # enable PV-charging when vehicle is identified
phases: 1
icon: car
cache: 15m
# minCurrent: 8
# maxCurrent: 16
# site describes the EVU connection, PV and home battery
site:
title: Home # display name for UI
meters:
grid: grid # grid meter
pv:
- pv # list of pv inverters/ meters
battery:
- battery # list of battery meters
# aux:
# - aux # list of auxiliary meters for adjusting grid operating point
residualPower: 200 # additional household usage margin in W
maxGridSupplyWhileBatteryCharging: 1 # ignore battery charging if AC consumption is above this value
# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
- title: Carport Charger # display name for UI
charger: Carport # charger
meter: charge # charge meter
mode: "off" # default charge mode to apply when vehicle is disconnected; use "off" to disable by default if charger is publicly available
# remaining settings are experts-only and best left at default values
priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
soc:
# polling defines usage of the vehicle APIs
# Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
# or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
poll:
# poll mode defines under which condition the vehicle API is called:
# charging: update vehicle ONLY when charging (this is the recommended default)
# connected: update vehicle when connected (not only charging), interval defines how often
# always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
mode: charging
# poll interval defines how often the vehicle API may be polled if NOT charging
interval: 60m
estimate: true # set false to disable interpolating between api updates (not recommended)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
disable: # pv mode disable behavior
delay: 3m # threshold must be exceeded for this long
threshold: 0 # maximum import power (W)
# tariffs are the fixed or variable tariffs
tariffs:
currency: EUR # three letter ISO-4217 currency code (default EUR)
grid:
# either static grid price (or price zones)
type: fixed
price: 0.294 # EUR/kWh
zones:
- days: Mon-Sun
hours: 7-21
price: 0.19 # EUR/kWh
- days: Mon-Sun
hours: 21-0
price: 0.12 # EUR/kWh
- days: Mon-Sun
hours: 0-7
price: 0.12 # EUR/kWh
# mqtt message broker
mqtt:
broker: 192.168.1.39:1883
topic: evcc # root topic for publishing, set empty to disable
user: mosquitto
password: xxxxxxxxxxxxxxxxxxxx
# influx database
influx:
# url: http://localhost:8086
# database: evcc
# user:
# password:
# eebus credentials
eebus:
# uri: # :4712
# interfaces: # limit eebus to specific network interfaces
# - en0
# certificate: # local signed certificate, required, can be generated via `evcc eebus-cert`
# public: # public key
# private: # private key
# push messages
messaging:
events:
start: # charge start event
title: Charge started
msg: Started charging in "${mode}" mode
stop: # charge stop event
title: Charge finished
msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
connect: # vehicle connect event
title: Car connected
msg: "Car connected at ${pvPower:%.1fk}kW PV"
disconnect: # vehicle connected event
title: Car disconnected
msg: Car disconnected after ${connectedDuration}
soc: # vehicle soc update event
title: Soc updated
msg: Battery charged to ${vehicleSoc:%.0f}%
guest: # vehicle could not be identified
title: Unknown vehicle
msg: Unknown vehicle, guest connected?
services:
# - type: pushover
# app: # app id
# recipients:
# - # list of recipient ids
# - type: telegram
# token: # bot id
# chats:
# - # list of chat ids
# - type: email
# uri: smtp://<user>:<password>@<host>:<port>/?fromAddress=<from>&toAddresses=<to>
# - type: ntfy
# uri: https://<host>/<topics>
# priority: <priority>
# tags: <tags>Log detailsWhat type of operating system are you running?HomeAssistant Add-on Version0.130.7 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 18 replies
-
Will do exactly that- wait for 10m for a value... |
Beta Was this translation helpful? Give feedback.
-
I think, It's not a problem for the shelly-wallbox-template. |
Beta Was this translation helpful? Give feedback.
-
I tried it and it shows the power of the charger. But that's it as long evcc doesn't expose any charger output data to the API or MQTT nothing works. Even with a custom MQTT charger, I can't imagine how this should work as there isn't something as a "starting request" from evcc. How should I control my HA automation to initiate and stop the charging process? But ev I'm wrong here, because my MQTT charger doesn't work at all. |
Beta Was this translation helpful? Give feedback.
-
|
sorry my fault.. not possible with Shelly EM |
Beta Was this translation helpful? Give feedback.
-
evcc doesn´t create these topics, it is waiting for data at these topics. So your automation must fill these topics with data.
you can use the ShellyEM as charger. If there is enough surplus, evcc will switch it on. You can get this |
Beta Was this translation helpful? Give feedback.
-
I dont think so, because the ShellyEM output can only switch 2A.. the device is primary a meter. |
Beta Was this translation helpful? Give feedback.
-
|
The ShellyEM doesn't have switches it is only a clamp meter. The Shelly Plus 1PM is rated up to 16A and will probably work as Shelly Charger. |
Beta Was this translation helpful? Give feedback.
-
|
yes, there is nothing connected to the switch. It is only to get the But, maybe I misunderstood the use case. |
Beta Was this translation helpful? Give feedback.
-
sure? I have a ShellyEM (Gen1) as charger in use. |
Beta Was this translation helpful? Give feedback.
evcc doesn´t create these topics, it is waiting for data at these topics. So your automation must fill these topics with data.
you can use the ShellyEM as charger. If there is enough surplus, evcc will switch it on. You can get this
enabledinformation in MQTT with in the loadpoint section