Not quite, but close. Mosquitto is just a “broker”. The particular protocol it brokers is called MQTT, which is a light-weight protocol for IoT data.
Mosquitto isn’t even the only one. There is HiveMQ as well, several cloud providers have their own (Amazon, Azure), and other pubsub systems like RabbitMQ has MQTT plugins as well.
The broker is a middle man, it sits there and it relays messages between clients. You connect to a broker (aka MQTT server), and then you tell it what kind of data you are interested in by “subscribing” to the topic you are interested in. It is what you call a pub/sub architecture. When you have data to send, you publish it to the relevant topic, and then people subscribed to those topics are notified.
The component that publishes the data from your GX device to the broker is called dbus-mqtt.
On a Victron system, the topics are structured like this, for example: N/badbeef15b4d/system/0/Serial
The topic is a key, and it has an associated value.
To keep traffic down, it doesn’t publish everything. You need to publish a keepalive to tell it what you want. See here.
The first letter of the topic is either R, W or N. R is a read request. If you publish a read request, you will get a notification (starting with N) for that value shortly afterwards. You can also write values (for paths that are writable) with the W topic.
But to begin, you are probably interested only in the notifications. After the N follows the VRM id of the GX device. This is so you can bridge together several installations into one cloud server, and still be able to identify each.
The third component is the service type. This would be something like settings, system, solarcharger, grid, pvinverter, vebus, etc. Without getting into too much detail, settings is where your configuration settings live, system is a service that summarises details from the others, and the others are the individual services each with their information.
The fourth component is the DeviceInstance. That is a unique number Venus uses to identify a service within its group, ie it helps distinguish between two solarchargers.
What follows after that is the “dbus path”, which is the IPC mechanism used by venus and most other Linux versions. It should usually be mostly self-explanatory. But if in doubt, check the modbus XLS document, or the dbus wiki.
Now, node-red. That’s a client. It connects to the MQTT broker, and then you can use that to connect those topic to actions, using some nice graphical interface. And Node-Red can also publish back to MQTT.
You can also bridge brokers. You can tell it to relay some topics (ie copy back and forth) to another server. So for example, if I am running a HomeAssistant server with its own MQTT server (which incidentally is also mosquitto), then I can bridge certain topics from my Venus broker to my HA broker, so those two can talk to each other, but without copying all the traffic.