Feature Request: Send MQTT SUM Data to OpenWB

[dersch81]

I love OpenDTU! I'm using OpenWB as a Wallbox and more and need all the actual data in it.

At the moment i'm sending the data like this:

OpenDTU => MQTT to HomeAssistant => NodeRed SUM all inverter data => MQTT to OpenWB

I don't like to have all the Middleware in the data flow.

Therefore it would be so great to have:

OpenDTU => MQTT to OpenWB

OpenWB just need two topics:

Per MQTT zu schreiben:
openWB/set/pv/2/W PV-Erzeugungsleistung in Watt, int, positiv
openWB/set/pv/2/WhCounter Erzeugte Energie in Wh, float, nur positiv

OpenDTU need a topic where all inverter Watt and YieldDaily will be summarized and then send it to configurable topics. Besides the HomeAssistant MQTT (or other MQTT server) should be usable, too. So we need two MQTT targets as an option. The OpenWB target could be specific and with less options as needed like above.

That would be awesome and usefull for a lot of users with OpenWB and Hoymiles.

[ff4-solar]

I'm also in this situation.
So it would be great to have a solution for direct MQTT-connection to the openWB-Wallbox.

openWB is also an open source project with an great commmunity
https://github.com/snaptec/openWB

[tbnobody]

Why does openWB a separated MQTT broker? On small devices like the ESP this is a waste of resources. Also the complete handling of reconnect etc. needs to be implemented twice. It will need duplicate RAM as also the configuration has to be kept twice.

[dersch81]

The OpenWB is the broker. On the OpenDTU ESP just another client connection to another broker is needed. tbnobody ***@***.***> schrieb am Di., 18. Okt. 2022, 11:53:

…

Why does openWB a separated MQTT broker? On small devices like the ESP this is a waste of resources. Also the complete handling of reconnect etc. needs to be implemented twice. It will need duplicate RAM as also the configuration has to be kept twice. — Reply to this email directly, view it on GitHub <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADI6ECZH5DSYB4QRWFO5WETWDZXR3ANCNFSM6AAAAAARH2VAD4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tbnobody]

Yes, thats clear. Sorry that sentence above from me doesn't make sense. My question was, why is it not possible for openWB to use an existing MQTT Broker? Why does it need it's own?

On the OpenDTU ESP just another client connection to another broker is needed.

It's not JUST. That's a rewrite of the existing connection handling and web UI etc. It also will take a amount of RAM because of the different connection parameters and the connection object itself. Just publishing values is one thing, but writing them to a different broker complete different one.
In this case it's even easier to configure mosquitto or another broker as a bridge (e.g. http://www.steves-internet-guide.com/mosquitto-bridge-configuration/)

[dersch81]

OpenWB is running on a Pi3B+ inside the Wallbox. I don't know why it has it's own broker but there are enough ressources for it. OpenWB users are already using a MQTT bridge to talk to the Wallbox via HomeAssistant for instance. So that's clear and a common way.

The idea was to let OpenDTU directly talk to the OpenWB without any middleware.

Here you can see the different Options how to talk to inverter systems:

Also JSON requests are possible. Do you think this would be a better way?

[tbnobody]

I just found this screenshot: https://openwb.de/forum/download/file.php?id=4563&sid=ca9c32f10acc2b8d39ccc471373a90c4&mode=view

Can you really enter a jq query string? Because if this is the case, the API endpoint /api/livedata/status would give all the required values. As I saw it it would be also possible to sum up the different inverters.

A jq query to sum the power of all inverters could look like this: [.[]."0".Power.v] | add

[dersch81]

It seems so. Here is the setting for the inverter JSON query.