The battery register reads negative on discharge (raw since day
one), but the tile label promised '+ Entladen / - Laden'. Flip the
three raw battery1_power/current queries with * -1 so positive
means power flowing into the house - the same mental model as the
grid tile (+ Bezug). Full history renders consistently; surplus
panels already use the correctly-signed derived fields.
Verified against simultaneous SolarEdge app readings (PV 40 W,
battery discharge 520 W, house 560 W): battery1_power negative
means discharge, and power_ac on this DC-coupled Energy Hub is
the inverter's TOTAL AC output - it already contains the battery
contribution. The old formula double-counted the battery, so
house_load collapsed (44 W shown vs 560 W real) and the PV tile
showed battery-inflated totals, which looked like PV and house
consumption were swapped.
New derived fields: house_load = power_ac + grid, and
pv_power = power_ac - battery (true PV production). Dashboard PV
tiles and both yield panels now use pv_power / integral(pv_power)
- the energy_total lifetime counter also counts battery
throughput and is not a PV yield.
The assumption meter1_power positive = import was wrong. Evidence
from the recorded data: sustained +2kW meter readings at high PV
with a full battery in maximize-self-consumption mode (exports,
not imports), and a single -2.5kW sample at 17:54 with only 600W
PV - a kettle import, physically impossible as an export under
the old assumption. house_load was inflated by adding export on
top of production, which made PV and consumption look swapped.
All derived flow fields follow the single METER_IMPORT_POSITIVE
constant; tests now describe the observed kettle/export patterns.
Short or garbled gateway responses are rejected on register count
instead of half-decoding (previously: 'unpack requires a buffer',
OverflowError on garbage scale factors). Scale factors outside
+/-10 and non-finite floats are dropped before they reach line
protocol.
offgrid is written as integer offgrid_state: the existing DB
cannot be migrated (mixed inmem/tsi1 shards block all deletes)
and the old boolean field conflicts with integer writes, which
poisoned the spool - HTTP 400 now drops the batch and logs the
InfluxDB error body instead of re-spooling it forever.
grafana_dashboard.json: fully German dashboard (InfluxQL,
InfluxDB 1.x) with off-grid state, SoC (SoE*SoH/100) and
consumption-source panels; status tiles use integers plus value
mappings because Grafana drops string/boolean fields from
InfluxQL time series.
Polls now cover meter 1, battery 1 and storage control blocks,
plus inverter event registers for off-grid detection (vendor
event bit 0). Register layout validated by probing a
SE10K-RWB48BFN4 with fw 0004.0025.0011; battery and storage
floats are word-swapped on this device.
Failed Influx writes spool to disk and replay on the next
success (Influx reached over WAN). Modbus blocks that fail to
read are skipped for that cycle; the flaky gateway must not
kill the daemon. Battery lifetime counters at 0xE176/0xE17A
hang the device and are never read.
BREAKING CHANGE: config.yaml 'mqtt:' section replaced by
'influx:', Home Assistant discovery removed.
When you read the registers one-by-one, which is what the solaredge_mobus
library is doing, you run into the issue where the value and the scale
are sometimes out of sync.
This happens mostly when the values go up or down a lot, like at the
beginning and at the end of the day. At these times the SolarEdge
inverter can change the scale of the values it's returning.
When you read the value register, the scale might be -2, but in the
time between that request, and the request for the scale, the inverter
has changed the scale to -3. So in the next register read, you will get
-3 for the scale, but have a value in the scale of -2. Now when you do
the value calculation, you end up with a factor 10 difference.
So it's better, and also _much_ faster to read out all the registers
at once and then parse the values from this bigger read out.
I'm planning to do a MR back to solaredge_modbus with this change, so
for now i've just included that code into this project.
So it's safer to configure, as we don't need to pass env variables
to a docker run service. Also it's easier to configure without
needing to pass a whole lot of env vars.
dj7nt
Marijn Koesen