Wrong kWh values during HA restart

[BenTaj]

Hi there,

I use the openWB to get access to my SMA Sunny HomeManager 2.0. But I see a strange behavior of the consumption values (in kWh), when I restart HomeAssistent. The current power values (in W) instead seems to work perfectly.

Here you can see, that I have restarted my HA three times today. And in each case the kWh values show a wrong value for a certain time.

But the Watt values does not show any spikes or glitches. And the OpenWB itself also show no strange values.

Does anybody have a clue what is going on there?

[BenTaj]

Addition: Actually I can see also for the Watt value "EVU-Leistung" spikes before each value corruption (see 16:33h)

How can I log the actual values received by the integration?

[ChristophCaina]

Yes, that's probably because the mqtt Broker is sending persistent Messages. I think you are using a second mqtt Broker als Bridge?

[BenTaj]

Yes, my openWB has also a Bridge to provide the data to the web.openwb.de service to access "the box" from external.

[BenTaj]

But what does this means? Is this an expected behaviour?

And is there any documentation which describes the persistent messages? I do not get what is going wrong there.

[ChristophCaina]

I think in one other topic here someone hast explained what he did to solve this. Personaly, I have removed any additional mqtt Broker - and have Home Assistent connected directly to the mqtt Broker of the Open WB ... Since I don't need mqtt für anything else atm

[BenTaj]

This is unfortunately no option, as I use also Zigbee2Mqtt. Do you mean the last message regarding the drops?

[svlsbrg]

Hello,

I have found a solution for myself, where I enable bidirectional synchronization only on the send topics and transfer the rest, only from the openWB to the local Home Assistant mosquitto server. This avoids the corruption of the data on the openWB after restarting Home Assistant:

#
# bridge to openWB Wallbox
#
connection openwb
address openwb.fritz.box:1883
start_type automatic
topic openWB/# in 2
topic openWB/set/ChargeMode both 2
topic openWB/config/set/pv/minCurrentMinPv
topic openWB/set/lp/1/ChargePointEnabled both 2
topic openWB/set/lp/2/ChargePointEnabled both 2
topic openWB/config/set/sofort/lp/1/chargeLimitation both 2
topic openWB/config/set/sofort/lp/2/chargeLimitation both 2
topic openWB/config/set/sofort/lp/1/current both 2
topic openWB/config/set/sofort/lp/2/current both 2
topic openWB/config/set/sofort/lp/1/energyToCharge both 2
topic openWB/config/set/sofort/lp/2/energyToCharge both 2
topic openWB/config/set/sofort/lp/1/socToChargeTo both 2
topic openWB/config/set/sofort/lp/2/socToChargeTo both 2
local_clientid openwb.mosquitto
try_private false
cleansession true

Actually, though, I would like the plugin to use its own paho-mqtt client in the long run, which connects directly to the mosquitto server of the openWB. This would reduce the huge amount of unused topics on the Home Assistant MQTT server.

Greetings Rene

[maltesen]

This is the way! Rene ole ole!

Ive added basically all "/set/" values to be "both 2" as both parties (openwb and homeassistant) want to write those. All "/get/" values should be "in 2" only as you only want to receive them from openwb in order to not mess up your data.

This should go into info.md - a prepared config file ready to be copied into with just the IP and login to be changed or better yet it should be copied by the config script and the config via homeassistant gui should allow to config openwb access data in that file.

[maltesen]

Im working with this atm.:

SSH into HomeAssistant and edit the file ./share/mosquitto/mosquitto.config to contain this.:

#
# bridge to openWB Wallbox
#

connection openwb
address 192.168.0.157:1883
try_private false
cleansession false
start_type automatic
topic openWB/# in 2
topic openWB/config/get/lp/1/stopchargeafterdisc both 2
topic openWB/config/set/lp/1/stopchargeafterdisc both 2
topic openWB/config/get/pv/minCurrentMinPv both 2
topic openWB/config/set/pv/minCurrentMinPv both 2
topic openWB/config/get/pv/lp/1/# both 2
topic openWB/config/set/pv/lp/1/# both 2
topic openWB/config/get/u1p3p/# both 2
topic openWB/config/set/u1p3p/# both 2
topic openWB/config/get/sofort/lp/1/# both 2
topic openWB/config/set/sofort/lp/1/# both 2
topic openWB/get/ChargeMode both 2
topic openWB/set/ChargeMode both 2
topic openWB/get/lp/1/ChargePointEnabled both 2
topic openWB/set/lp/1/ChargePointEnabled both 2
local_clientid openwb.mosquitto

We define all topics as "in" (read only from the wallbox, dont write), so we dont overwrite "data" (as opposed to "settings"). Data should only be read. Afterwards we define a few selected topics as "both" (read and write; those topics which are actually "settings" and not "data"). Im not sure if i missed any important topic to set to "both" to here so far. Add as required. I guess the authors should make this congruent with the HA sensors they added. Every read/write sensor should be "both", everything else should be "in". Be casefull if you first set something to "in" and later try to overwrite the setting with "out" or "both" that will not work. Those settings are cummulative. First setting "in" then "out" on something will make it behave like "both". So "out" doesnt overwrite "in" just because its called later in the config.

First i was only giving "both" to "/set/" topics, but that doesnt seem to work in all cases so i also added "both" to the "/get/" topics now. Its inconsistent somewhere. Not sure if this HA plugins sensors are writing to "/get/" in some cases (and openwb accepts that), or if thats required because its implemented inconsistently on the openwb side (that you actually set some things by writing to the "/get/" topics).

After saving changes, restart the mosquitto app itself (or the whole system, but NOT only HomeAssistant :))

Also the lines

topic openWB/set/ChargeMode both 2
topic openWB/set/lp/1/ChargePointEnabled both 2

are a bit inconsistent with what you get from the box. The values you actually get are at

openWB/global/ChargeMode
openWB/lp/1/ChargePointEnabled

Ive tested that i can set charge mode via that, so i guess thats ok.