VictronEnergy MQTT Item - direct Transformation MAP?

Setup, Configuration and Use Items & Sitemaps
1

Hi,
I recently installed a Victron Energy Storage System. An internal MQTT Server provides data of the battery state very simple:

**Number VeBatState "LiFePo4 State [%d]" <error> (VE) {mqtt="<[mivenusgx:N/0c1c57111e38/settings/0/Settings/CGwacs/BatteryLife/State:state:JSONPATH($.value)]"}**

There exists a mapping of the integer values provided (i already created victron.map file):

2=Self Consumption
3=Self,SoC > 85%
4=Self,SoC 100%
5=SoC < limit

Is there any direct way to not add a rule for this mapping, or create another item as a dummy to do the conversion. I hope its possible to somehow combine my mapping file with this item and internally already do the string conversion so i see the text from the mapping file. Thanks a lot Norbert

2

With the MQTT 1.x binding you are using, no, you have to create a rule.

With the MQTT 2.x binding, you can chain transformations so that it first performs the JSONPATH and then the MAP.

3

hm, i knew the day would come where i have to make this decision.
Is there any further advantage moving to 2.x binding?

I know hard to decide for others, but what would you do. I guess it will take me a Friday night to migrate…better i hope.

Cheers

4
  • Some simple transformations like mapping values to ON/OFF or OPEN/CLOSED are built in instead of needing a map file
  • Automatic discovery of MQTT devices that follow the Homie or Home Assistant topic topology standards
  • At least preliminary support for units of measurement
  • Will be supported in OH 3 on-wards (1.x bindings will not be supported in OH 3)
  • Online/offline detection of devices built into the Thing definition (i.e. you can define a Thing and configure the LWT topic and messages and the binding will mark the Thing as offline and set the Items linked to it to UNDEF)
  • The ability to control QOS and retained on a topic by topic basis, with the 1.x binding you could only define those on a broker connection by broker connection basis
  • The ability to control the outgoing format of a message prior to publication without needing a Rule. For example, if the device expects a message like { "id": "1234", "state": "ON" } to turn it on, you can define an outgoing format along the lines of {"id": "1234", "state":"%s"} on the Thing and the proper JSON will be published.
  • Support for Thing Triggers. For example, you can subscribe to a bunch of topics using a wild card subscription and trigger a Rule for each message to any of the those topics. The topic and the message are sent to the Rule for further processing. See Marketplace MQTT Event Bus for an example.
  • If you use PaperUI (recommended) to create the Things all the fields and capabilities are self documented and it’s almost impossible to create a Thing with invalid syntax.
  • Lets you leverage Profiles which further eliminates the need for some Rules.

If you have a lot of similar MQTT Items, you can create one in PaperUI, query for it in the REST API Docs, copy the JSON to notepad or your editor of choice, change the fields for what’s different, then create a new similar Thing by pasting the edited JSON into the REST API Docs. You can rapidly create a number of MQTT Things in this way.

I switched over to the 2.x MQTT binding before it was officially released and have gone out of my way to eliminate all the other 1.x version bindings from my configuration. It’s far more flexible, capable and future proof.