Wait, I thought RV-C was a CAN bus protocol?

Yes RV-C is for sure a CAN protocol, but a core component of eRVin listens to RV-C traffic and converts it to MQTT traffic so it can more easily be manipulated.

What is MQTT?

MQTT is a lightweight and efficient publish-subscribe protocol used for IOT (Internet of Things) applications. The nitty gritty details aren’t pertinent to this discussion, so for more info have a look here and here. FYI, eRVin uses the Mosquitto MQTT broker.

How eRVin converts RV-C to MQTT

Before discussing how to use MQTT Explorer it is necessary to understand the basic eRVin architecture and some key RV-C concepts.

While Node-Red is the main tool used to create the eRVin infrastructure (node-red “programs” are know as flows), there are a few core programs that run on the Raspberry Pi OS directly to make everything work, most of these are written in the Perl language.

One of those core programs converts RV-C to MQTT. It runs automatically when eRVin starts up and must always be active for eRVin to function. The program is called rvc2mqtt.pl and is located at this path on the Raspberry Pi: /coachproxy/bin/rvc2mqtt.pl

This program runs continuously, scanning all the RV-C traffic and comparing it to a database of the RV-C specification, then publishing that information to MQTT in human readable formatted text (JSON format).

The RV-C database employed by rvc2mqtt.pl is called rvc-spec.yml and is located at this path: /coachproxy/etc/rvc-spec.yml. This file is in YAML format which is another simple human readable format. Note that if rvc-spec.yml does not have an entry for new or updated RV-C parameters, or proprietary information, it will not be able to process it into a readable format. Also be aware that rvc2mqtt is a one-way program. That is, it can only send RV-C data to eRVin. Sending RV-C commands from eRVin back to the RV-C network is handled a different way, more about that later.

Note: Credit for the rvc2mqtt.pl (Perl version) and rvc-spec.yml goes to coachproxy. eRVin may eventually employ the Python versions as described here and here.

Understanding DGN’s and Instancing:

The RV-C traffic itself is basically a series of what are called Data Group Numbers or DGN’s. Note that RV-C uses the term DGN’s while other CAN protocols use the term PGN’s or Program Group Numbers. For more info about the difference, see here. One thing that sets RV-C apart from other CAN protocols is its ability to do “instancing”. Basically, this means only one DGN is needed to support multiple instances of the same kind of device. For example, a light, of which there are many on an RV, can be supported by one DGN that specifies the instance value for the specific light of interest.

DGN Example:

The RV-C Specification contains a list of all the DGN’s, what they do and how they are configured. For example, the DGN to report the status of lights in eRVin is called DC_DIMMER_STATUS_3. This DGN has a hex value of 1FEDA. Below is a DC_DIMMER_STATUS_3 DGN captured directly off the RV-C by SocketCan (more about that later) and displayed in JSON format. Note the values in this case are in decimal. As per the RV-C Spec, the first byte in the data field is the instance, in this case 33. For my coach that is the same 33 as printed on the front of my Firefly G6 panel and is my Dinette light.

{
"payload": {
"timestamp": 1737320735407,
"ext": true,
"canid": 436132495,
"dlc": 8,
"rtr": false,
"data": [
    33,
    124,
    100,
    252,
    255,
    4,
    4,
    255
    ],

Now, your homework is to go to the RV-C spec and figure out what the rest of the data values represent and how to decipher them.

Oh what, too much work? Well that’s where eRVin can help. Below is the output for the same DGN after it’s been processed by rvc2mqtt.pl / rvc-spec.yml and sent to MQTT. All of the info incorporated in the data field have been converted to human readable parameter names and their values. Note that “instance” is called out with a decimal value of 33. Another value of interest is “operating status (brightness)” with a value of 50 – this means my dinette light is dimmed to 50%. This is a relatively complex DGN with a lot of data parameters. The RV-C info is primarily contained in the “payload”  subset shown below. The “topic” and other parameters are part of the MQTT framework.

{
"topic": "RVC/DC_DIMMER_STATUS_3/33",
"payload": {
    "data": "217C64FCFF0404FF",
    "delay/duration": 255,
    "dgn": "1FEDA",
    "enable status": "11",
    "enable status definition": "enable status is unavailable or not supported",
    "group": "01111100",
    "instance": 33,
    "interlock status": "00",
    "interlock status definition": "interlock command is not active",
    "last command": 4,
    "last command definition": "stop",
    "load status": "01",
    "load status definition": "operating status is non-zero or flashing",
    "lock status": "00",
    "lock status definition": "load is unlocked",
    "name": "DC_DIMMER_STATUS_3",
    "operating status (brightness)": 50,
    "overcurrent status": "11",
    "overcurrent status definition": "overcurrent status is unavailable or not supported",
    "override status": "11",
    "override status definition": "override status is unavailable or not supported",
    "src_addr": "8F",
    "timestamp": "1737317899.434036"
    },
"qos": 0,
"retain": false,
"_topic": "RVC/DC_DIMMER_STATUS_3/33",
"_msgid": "d26c5147f52b9797"
}

How to view DGN’s using MQTT Explorer

OK, now that you know the basics of the eRVin architecture and RV-C, let’s go ahead and view what is happening on the RV-C in real-time. Download MQTT (free) to your PC or Mac and install it. Open the program and enter your eRVin IP address as shown below, then click the Connect button.

Assuming eRVin is running, and is on the same network as your PC or Mac, you should see something like the following:

The main category of interest is RVC (highlighted in yellow) and contains the actual RV-C data. The CP category (highlighted in green), contains data that is processed by eRVin and then re-published to MQTT to be used by other programs.

Next, click the black arrow to the left of the RVC category to expand the data. You will see something similar to the screenshot below. The bolded all capitalized items are the RV-C DGN’s. Note that in MQTT parlance, these are known as “topics”. You may see more or fewer DGN’s/topics depending on the extent of your RV-C installation. From the factory, my 2017 coach only had DGN’s for lighting and generator status, but since then I have added additional equipment, hence the additional DGN’s for the Inverter./Charger, Tank Levels, etc. Newer RV’s will likely have many more DGN’s than are shown below.

Now, lets dig a little deeper. Click the black arrow to the left of DC_DIMMER_STATUS_3. The items listed are the active instances, basically all the lights that are currently on or dimmed. I have highlighted instance 33 and it’s data parameters show in the scrollable Value box to the right. You will of course have noticed by now that the data is updated constantly and the values are rapidly changing. To pause the action and make things a little easier to read, click the pause icon to the right of the search box at the top of the window. Note in my screenshots that I have the display paused, clicking the play arrow will start things up again.

Note that in my screenshots, every DGN is a status DGN. That’s because I have not sent any COMMANDS, such as turning on a light, since I started MQTT Explorer. In the screenshot below, I changed the dim level of my dinette light, instance 33.

Note there is now a DGN for DC_DIMMER_COMMAND_2. In the Value box to the right, the two most recent commands are shown because MQTT Explorer highlights the parameters that have most recently changed. In green is the most recent command which is a “stop”. Prior to that was a “ramp up/down”. This is because changing the dim level sends multiple commands to accomplish that. The two shown above are not necessarily all the commands sent, only the two most recent. If you click the arrow next to History, below the Value box you will see more of the command history. At this point if I were to go back to instance 33 under DC_DIMMER_STATUS_3, I would see the new dim level value.

In Conclusion

So with this tool, at a minimum, you will be able to study what kind of RV-C data is present on your network. In addition, you will be able to learn what makes RV-C tick and do basic network troubleshooting. But as a reminder, MQTT Explorer can only display what is defined in the rvc-spec.yml database, so it does have a limitation.

Be aware, besides rvc2mqtt, there are other ways to view the data on the RV-C network. As mentioned earlier, SocketCan is one of those options and comes pre-installed in eRVin v0.62 and higher. I have written a few flows (Node-Red programs) to help filter the data coming in from SocketCan-Out nodes. Whereas rvc2mqtt.pl/rv-spec.yml can only report data that is known and specifically contained in the YAML database, SocketCan has no such limitation. However, it will require more time, skill with bit manipulation, and working within node-red directly. Also, SocketCan can not only receive data from the RV-C, it can send it too. This potentially eliminates the need to write Perl or Python programs to send commands to the RV-C as is done now in eRVin. For example, I have been successful posting chassis battery voltage read by a Shelly Plus Uni, back to the RV-C as an actual RV-C DGN using the SocketCan-In node. I also have examples of how to turn lights on/off/dim and a few other capabilities. It is entirely possible that rvc2mqtt could be replaced by using SocketCan in the future.