Mqtt on cerbo and HA fail

Hello everyone.
I have spent quite a bit of time (and I have been dealing with hardware and software for 40 years) on this and have followed this

and other video and text tutorials, all of which use the same basic procedure to the letter. They all, though, show separate
MQTT on LAN (SSL)
MQTT on LAN (Plaintext)
whilst my Cerbo (up to date) only shows
MQTT Access
I do get Vicron up on MQTT explorer, with
R having one topic (every 30 secs, = “keepalive”)
N one 12 digit hex number ; system; 0.

Of course I should be getting a long list of assorted data.

Has victron blocked access, or do I need to add more to gain access (eg passwords)?

I wrote this the other day, it may help you to resolve your issue:

What have you selected as your ‘Network Security Profile’ on your Cerbo?

Hi,
thank you for your post.
Sadly everything is already as you suggest, so this is not the problem.
MQTT explorer does see the cerbo, displays the VRM portal address, but that’s all.


so I think the cerbo (192.168.68.104) is seen and sees explorer.
It just doesn’t send the data. Keepalive is on in HA.
The problem seems to be to get the cerbo to discharge the data.
Turning off VRM seems to have no effect on explorer.
I haven’t come across a ‘keepalive’ in the cerbo.
Any ideas? I’m running out of plausible things to modify!

Found it. Obscure but important. Set cerbo to “keepalive”.

Whoever would have known but why its not mentioned anywhere I have no idea!
See:

Now have to get same into HA. Sigh.

OK, this is my problem. I was NOT using the VRM number (12 digit hex) in my automation. That is the 12 digit hex that MQTT explorer shows after

victron
N
(12 digit hex number = victron VRM)

This then goes into your keepalive automation


and you are good to go.

The Keepalive is usually used in situations where your network has connectivity issues or one party to the MQTT connection remains idle for extended periods of time (for example a topic with a VERY slow update rate). In a correctly functioning and reliable TCP network, the use of Keepalive should not be required. It can also be used in the new implementation of MQTT on the Cerbo to help reduce the overall network traffic (see below for more details).

I’m assuming that when you setup your MQTT explorer connection you did subscribe to a topic?

It’s a step many people forget and hence nothing is returned, you didn’t request anything.

If your MQTT explorer connected and looked like the below, that is normally because there is no subscribed topic specified in the MQTT connection settings:

Now if we edit our basic connection to subscribe to ALL topics, we see everything registered with the Cerbo and for which it is publishing topics. So how do we subscribe to everything? We can use the ‘wildcard’ topic of #. See here for more info: MQTT Topics and Wildcards: A Beginner's Guide | EMQ

Lets take a closer look at what we can do. In your MQTT explorer connection, at the main connections screen, select your connection and then ‘Advanced’:

Then you’ll see something like thing, if you’ve haven’t set default topics before:

Now lets add a ‘Wildcard’ topic using the ‘#’ symbol. In the text line marked ‘Topic’ (the one with the QoS at the end) type in the ‘#’ symbol and click on ‘+ Add’, then youu’ll see it added to your list of subscribed topics, next click on ‘Back’:

We can now connect using our connection details with our wildcard topic, after a short time ALL Cerbo topics will be displayed:

See the topic count increase:

We could have course chosen to subscribe to a specific topic, e.g the system battery SoC:

Then we would see only a single topic:

We can of course subscribe to multiple distinct topics or use the ‘+ Wildcard’ too:

We can of course mix and match too!:

Not a ‘Keepalive’ in sight. KeepAlive isn’t an absolute requirement, by you can discover why you may want to implement it, or not: GitHub - victronenergy/dbus-flashmq: Plugin for FlashMQ that interfaces between DBUS and MQTT.

However you can implement a simple ‘Keepalive’ via a publish to R/brokerID/Keepalive and with a payload of:
{ "keepalive-options" : ["suppress-republish"] }
or just {}

Hi,
great stuff and has answered some questions I intended to ask when I had more of a working system up and running.
Clearly it makes no sense to download ALL the myriad of information when you only want one. You show how this is done, and its pretty logical. Once I have what I want I will remove keepalives and request just the required data as you suggest using a modified “keepalive automation”. That is call for data every (say) 15 secs.
Currently I can get data items into my dashboard but not into the “energy dashboard” in Home Assistant. Here is the cose fragment I am using and my comment. Others have suggested I am missing an attribute but it doesn;t seem to be easy to find documentation.

Here code fragment from HA MQTT, It delivers a usable entity for the dashboard, but not one for the “energy dashboard”. Of course the main point is to pull data from the cerbo to HA so it displays what I want (etc).

name: “Energy Solar Total”
unique_id: “Energy Solar Total”
device_class: energy
state_topic: “victron/N/c061XXXXX6d7/solarcharger/1/Yield/System”
value_template: ‘{{ value_json.value|float(0)|round(0) }}’
unit_of_measurement: “kWh”
icon: mdi:solar-panel

However, its NOT possible to use this solar output in the “energy” dashboard under solar because it never comes up. This is despite it having “energy” and “solar” in its attributes and is measured in “kWh”.

Long-term Statistics
Home Assistant has support for storing sensors as long-term statistics if the entity has the right properties. To opt-in for statistics, the sensor must have state_class set to one of the valid state classes: SensorStateClass.MEASUREMENT, SensorStateClass.TOTAL or SensorStateClass.TOTAL_INCREASING. For certain device classes, the unit of the statistics is normalized to for example make it possible to plot several sensors in a single graph.

Home Assistant tracks the min, max and mean value during the statistics period. The state_class property must be set to SensorStateClass.MEASUREMENT, and the device_class must not be either of SensorDeviceClass.DATE, SensorDeviceClass.ENUM, SensorDeviceClass.ENERGY, SensorDeviceClass.GAS, SensorDeviceClass.MONETARY, SensorDeviceClass.TIMESTAMP, SensorDeviceClass.VOLUME or SensorDeviceClass.WATER.

I think this may help you in correctly configuring your entity for the energy dashboard.

This is a great way to reduce network traffic to a rate that provides for your use case.