We’ve been hard at work on new features for your BMS in the background of issue fixes, and one of these is the ability to send detailed battery data to your own private MQTT server in an open JSON format. This means the data is now in your hands to do whatever you want with!
Now, on to what we need you for! We’ve tried our best to think of the common use cases and expose the data required, but you will have a much wider pool of ideas we can pull from. Take a look at our specification document and let us know if there is data you’ve always wanted that isn’t included.
Why do you write JSON to MQTT? Why don’t you create a useful tree with MQTT topics and write values directly? Encapsulating monitoring values in JSON makes it hard to write those values to time series databases. You need to extract them from JSON and store each and every value on its own. Otherwise reducing detail level for old data becomes impossible. Furthermore, you can not create an Influx dumper just writing everything from MQTT to InfluxDB. You need again to extract from JSON.
We’ve seen a lot of other IoT devices do it this way, and it seemed like a logical way to pack data that corresponded to how our device works internally. While a tree would work well for small systems with 4-16 cells, but would fall apart for the large systems we see (up to 250 cells), our embedded device wouldn’t be able to keep up with making 2000+ individual writes to the MQTT broker.
This is a valid point, but we have a shareable Node-RED implementation that does this. As for detail, you could modify your bucket and Node-RED implementation to send different data to different buckets with different retention policies. Could you elaborate on the ways you could reduce the detail on older data?
With reducing detail, I was talking about retention policies but was just missing the term
Still I would prefer some data dumper from MQTT to InfluxDB instead to putting this into Node-RED. This is not, what Node-RED is made for. See e.g. the Victron Energy venus-influx-loader. But maybe we can create something similar for Batrium, when then WatchmonUDPListener becomes obsolete.
And I agree with the limited network capabilities of an ESP32 device, which will make it hard to send every value to a single MQTT topic.
after it took nearly a week to get registered here, I have tried to get this running, but although I have the latest Version of Watchmon Tollkit 2.17.54 installed, I don’t have access to this telematics settings in Integration tab. How can I get this seetings activated?
ok, thanks for clarification. I’m waiting on this function a for a long time now.
I’m not so deep into the system, that I understand all the description.
One thing is, it should be possible to use MQTT also without user and PW.
For me most importand would be the state of charge in %, to be able to switch my inverter setting depending on the SOC.
This is exciting stuff. I am really looking forward to you guys getting this implemented into the system. Please hurry! I have also seen some new YouTube videos being published. It is great to see the activity from Batrium on that platform. I am crossing my fingers that once this is deployed, that you guys will publish a video showing the basics on getting the data into the IOTstack that you have laid out. This is a great vision for the future and taking Batrium to the next level.
It looks like you’ve exposed all of the items that I would see a need for. I’m very happy to see the intention to work with Node Red. That integration will make it much easier for a wider audience to take advantage of the capability. The Victron Venus OS Large edition has taken a similar approach and it has been well received. I’m excited for the release!
No news just yet. I’m knee deep in some new hardware for you guys, and our software engineer is still getting TK2/TK3 up to a point that we like. I intend to come back to this after the new hardware is released.
Thanks for your feedback regarding fields that you want! I can see the value of both, and will talk about adding them with our software engineer.
