evcc-io / evcc

Sonne tanken ☀️🚘
https://evcc.io
MIT License
3.58k stars 660 forks source link

EM24 Ethernet false gridEnergy in InfluxDB #11513

Closed diavolopineapplepizza closed 10 months ago

diavolopineapplepizza commented 10 months ago

Describe the bug

Hi,

I use the EM24 Ethernet (fw: PFB-1.0 (Eth:1.8)) as grid energymeter. Now I have implemented evcc in my InfluxDB (v2.7.4). The energy value „_measurement gridEnergy“ in InfluxDB is only the phase L2 energy of the EM24.

It was nice when you can implement the grid energyFeedIn and maybe gridVoltages, gridPowerFactor and gridFrequence to EVCC->Influx

Thanks

Steps to reproduce

  1. open influx Data Explorer -> bucket EVCC -> gridEnergy -> value
  2. open Carlo Gavazzi UCS7 software (or lock on EM24 display) -> compare values
  3. influx gridEnergy = energy L2 on EM24

Configuration details

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: debug
levels:
  cache: error

# unique installation id
plant: XXXX

interval: 10s # control cycle interval

sponsortoken: XXXX

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false

meters:
- type: template
  template: cg-em24
  id: 1
  host: 192.168.XX.XX
  port: 502
  usage: grid
  modbus: tcpip
  name: grid1

chargers:
- type: template
  template: phoenix-ev-eth
  id: 255
  host: 192.168.XX.XX
  port: 502
  modbus: tcpip
  name: wallbox1
- type: template
  template: go-e-v3
  host: 192.168.XX.XX
  name: wallbox2
- type: template
  template: go-e-v3
  host: 192.168.XX.XX
  name: wallbox3

loadpoints:
- title: Garage
  charger: wallbox1
  mode: minpv
  phases: 3
  mincurrent: 6
  maxcurrent: 32
  priority: 1
- title: Carport
  charger: wallbox2
  mode: minpv
  phases: 0
  mincurrent: 6
  maxcurrent: 16
  priority: 0
- title: Stellplatz
  charger: wallbox3
  mode: minpv    
  phases: 0     
  mincurrent: 6           
  maxcurrent: 16   
  priority: 2

site:      
  title: XXXX
  meters:
    grid: grid1

tariffs:
  currency: EUR # (default EUR)
  grid:
    # static grid price
    type: fixed
    price: 0.2839 # [currency]/kWh

  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.0673 # [currency]/kWh    

influx:
  url: http://192.168.XX.XX:8086
  database: evcc # InfluxDB v2.x uses term `bucket` but for compatibility still named `database` here
  token: XXXXXXXX
  org: home

Log details

.

What type of operating system are you running?

Docker container

Version

0.123.5

premultiply commented 10 months ago

Ouput from evcc meter --log trace is missing here.

diavolopineapplepizza commented 9 months ago

@andig Hi, too bad you have already closed the issuereport. In the meantime, I have finally been able to find the time to investigate the matter myself. This is a difference in the communication protocols of the Ethernet variants to RS485.

Protocol for the Ethernet version: https://www.gavazziautomation.com/fileadmin/images/PIM/OTHERSTUFF/COMPRO/EM24_E1_CP.pdf

Is condition: https://github.com/volkszaehler/mbmd/blob/master/meters/rs485/carlogavazzi-em24.go

Translation: VoltageL1: 0x00, ok VoltageL2: 0x02, ok VoltageL3: 0x04, ok CurrentL1: 0x0C, ok CurrentL2: 0x0E, ok CurrentL3: 0x10, ok PowerL1: 0x12, ok PowerL2: 0x14, ok PowerL3: 0x16, ok Power: 0x28, ok CosphiL1: 0x32, -> 0x2E CosphiL2: 0x33, -> 0x2F CosphiL3: 0x34, -> 0x30 Cosphi: 0x35, -> 0x31 Frequency: 0x37, -> 0x33 Import: 0x42, -> 0x3C -> 0x112 its better to use TOTAL, export is TOTAL to ImportL1: 0x46, -> 0x40 ImportL2: 0x48, -> 0x42 ImportL3: 0x4A, -> 0x44 Export: 0x5C, -> 0x4E

In addition, it would be really great if you would pass the following values to Influx: Voltage L1-L3, Cosphi (Sum), Import (corrected), Export

Thanks

andig commented 9 months ago

Hi, too bad you have already closed the issuereport.

We're closing any resolved reports or ones with missing feedback.

@premultiply looks like CG is actually 2 models- ModbusTCP and RS485. Seems we should switch to direct implementations.

@diavolopineapplepizza do you want to propose a PR for splitting the models? This is not a priority for us.