Libre Solar Community Forum

Thingset with CAN

Hi everyone,

I’m working on the implementation of the thingset protocol through Can on a custom hardware these days. I’m using the same BOM than the MPPT2420 board with the TCAN334GDR chip and passives surrounding it.
The MCU used if STM32G474RE so I should be pretty close to the LibreSolar hardware.
I’m attempting to run one of the test, to check basic connectivity between two boards, one is runnign the client, and the second one is running the server.

My noob wonder is the following :
Should I use CONFIG_CAN=y or CONFIG_CAN_STM32=y in my prj.conf file ?
Is there some CONFIG_THINGSET_CAN=y features that I terribly missed in the configuration ?


Hi Jean and welcome to the forum!

The CONFIG_THINGSET_CAN is not configured in the prj.conf by default as not all boards have CAN bus support. That’s why it’s enabled in the board_defconfig if supported, see e.g. here:

CONFIG_CAN_STM32=y should not be required, it’s selected automatically if CONFIG_CAN=y.

At the moment a ThingSet client is not implemented on the charge controllers, they are always the servers of data.

The ESP32 can act as a client, but we are still working on an automatic CAN device ID assignment so that the ESP32 can detect which devices are active on the bus. See here for the ESP32 firmware.

If you have a CAN2USB dongle, you can also use the Linux ISO-TP tools. As an example, requesting all output data from the charge controller in ThingSet binary format works like this:

# Start ISO-TP receiving channel
isotprecv -s 0x1ada1400 -d 0x1ada0014 can0 -l

# Request all output data (in different terminal)
# TX using source (own) ID (ID used for sending)
# RX from destination (remote) ID (ID used for receiving, only needed for flow control here)
echo "01 18 70 A0" | isotpsend -s 0x1ada1400 -d 0x1ada0014 can0

Unfortunately, the ThingSet documentation regarding CAN is a little bit outdated, as I found some issues with filtering for the originally planned 29-bit CAN ID layout. So we are including the function code in the payload and not in the CAN ID. See here for some explanations regarding CAN ID layout:

Control messages (e.g. to align on voltage targets for parallel DC/DC converters) are not really defined yet, but I’ve got some ideas already. Let me know when you are at that point and then we can go ahead with some further planning here :slight_smile:



I have now updated the ThingSet specification aswell.


Thank you for your answer @Martin. We are working on a use case with two STM32G4 boards connected in a daisy chain to the same CAN bus. They should work as follows:

  • One power converter as a server which has data in its local registers

  • One power converter as a client which sends queries to the server and retrieves data

    If I understand you correctly there are no STM32 dedicated CAN client functionalities in ThingSet. I suppose our questions here become:

  • What is missing in the current ThingSet implementation to deploy our use case?

  • Is there a simple workaround we can use to deploy our use case?


The client/server type of communication in the ThingSet protocol is meant to be used more for user interfaces.

For M2M communication, i.e. multiple power converters aligning on common voltage targets, the publish/subscribe method on the bus should be used. As a starting point, all converters could send out their voltage setpoints and at the same time receive the setpoints of other converters. The actual control could then get the minimum of all setpoints as the control target. (just an example to demonstrate the idea)

For development purposes it’s definitely a good idea to have a USB to CAN dongle so that you can talk with the controller using your PC.