SmartSolar MPPT internal temperature available on SmartSolar Control Display, but MQTT value is null

Node-RED
, , ,
1

Hi,

I have a SmartSolar MPPT VE.Can 250/100 connected to a Cerbo GX running Venus OS Large. The MPPT is connected through VE.Can and I am reading the values through MQTT / Node-RED. I recently installed a Smart Solar Control Display for my MPPT.

The MPPT is publishing normal data correctly, for example:

N/<portalId>/solarcharger/0/ProductName
{ value: "SmartSolar MPPT VE.Can 250/100…" }

N/<portalId>/solarcharger/0/Mgmt/Connection
{ value: "VE.Can" }

N/<portalId>/solarcharger/0/Dc/0/Voltage
{ value: 53.13 }

N/<portalId>/solarcharger/0/Yield/Power
{ value: 0 }

N/<portalId>/solarcharger/0/ErrorCode
{ value: 0 }

However, the temperature path is present but always returns null:

N/<portalId>/solarcharger/0/Dc/0/Temperature
{ value: null }

I understand that battery temperature is available separately and that part works fine in my system.

My question is specifically about the solar charger internal temperature. The SmartSolar Control Display manual shows two temperature menu items: battery temperature and solar charger temperature. Because of that, I was wondering whether the solar charger internal temperature is available somewhere in Venus OS / D-Bus / MQTT, or if it is only available locally on the SmartSolar Control Display.

Is it expected that /Dc/0/Temperature is null for a SmartSolar MPPT VE.Can 250/100?

If the internal MPPT temperature is not currently exposed in Venus OS, would it be possible to expose it in a future update? It would be very useful for monitoring against ambient temperature, battery temperature, avoid thermal stress etc.

Thanks.

2

I googled a kind of answer in community archive - Is there a way to query the internal temperature of an MPPT controller? - VictronEnergy
It seems, that the internal temperature can be read out on CAN units via direct reading of can registers…
I wish Victron would include this information within standard dbus, as it is really important. Same for Multiplus!

3

+1

Would be great to have temperature readings for MPPT’s and inverters, in VRM, NodeRed and Overview pane.

4

I fully agree - those informations are on the Bus, just to present them on dbus would make them visible in nodered and even cerbo…
dear Victron - please consider this!

5

chatting with AI i got pointed to a not that popular github dbus project - GitHub - chriswg3/victron-dbus-tempcontrol: Read the internal temperature sensor of Victron Smartsolar MPPT. Control the internal MPPT Relay based on temperature · GitHub

It is just briliant - not only does all that polling, but is also able to use the relay built into MPPTs to drive a fan when temperature exceeds configured thresholds.

One just need to adjust config file (do not change section names!), choose own (free) VRM Id’s, paste dbus path for mppt from dbus-spy output and eventually provide thresholds for the relay. NAtive dbus stuff, no NodeRed needed anymore for this!

Because it is native DBus stuff - it also shows as temperature gauge in VRM/GX Console!

6

This worked amazing! I have it now on the dashboard and you can also use it now in cooling applications with the relay. Amazing find!

7

Yes, it’s a great add-on, but does the VRM display the custom name of the MTTP?

8

Yes, you need to go to Devices in VRM, then Device and there you can specify your own names! Just the section names in config file have to follow the specific rule with just number increasing otherwise it will break. Once the device is in VRM you can freelyt rename it and it will keep that name.

9

I’m a little bit confused. In VRM > Devices, should I use VictronConnect to rename it? I already set a custom name for MTTP in there earlier (but its not displayed). Or do you mean I should somehow rename the temperature sensor?

10

Sorry, i was a bit non precise. In VRM i used “Remote Console”, and there in Settings → Devices → [temperature device] → Device → Name you can set your own name and it will be displayed so in VRM and in Console under Levels. Hope you can find it.

11

Now its clear :+1:
It should be renamed in the Cerbo GUI. Rename the temperature sensor (it does not inherit the custom name of the existing MTTP device).

12

Does this persist across firmware updates? Also, there is a version for mppt controllers that don’t have a relay and communication over ve.direct, here

13

They should yes. I checked, and the script is in /data which is presistent and survives a firmware update. After each reboot/or firmware update which also does a reboot, the script runs and recreates the symlink in /service (which gets wiped).

14

Thank you, I’ll give the ve.direct non relay version a go.

15

I can confirm the ve.direct, no relay, version works too. But if you install it the author changed the name of the .py file but didn’t update the install.sh and uninstall.sh files with the new name so you’ll need to do that yourself. Also, the .ini file is a little different, you just need to provide the id of the temperature sensor for the first mppt controller, any subsequent controllers are generated sequentially. For me, my existing temp sensor inputs were 20-23, so my ini file started at 24 and that’s all I had to change. I tested it with a SmartSolar 100/50 and a 100/30 connected to the same Cerbo gx and both internal temperatures are available in the Cerbo gx and VRM

HTH anyone else.

16

Thats great to hear. I had the relay version so I used that. I got inspired by this and made temperature cards for all my devices in my rig. Wall of text incoming.

image
image346×805 13.5 KB

I ended up adding a few custom D-Bus temperature/status services on my Cerbo GX / Venus OS Large setup, mainly to improve thermal visibility in VRM/GX GUI.

1. MPPT internal temperature (The subject of this topic)

Service:

com.victronenergy.temperature.can_00

This one reads the internal temperature exposed by my Victron SmartSolar MPPT VE.Can charger. In my case it is a SmartSolar VE.Can 250/100 rev2.

Displayed value:

MPPT01 Temperature
actual MPPT internal charger temperature in °C

Notes:

This is a real internal temperature coming from the solar charger data. Relay control is disabled; the script is used only for monitoring.

2. Fronius powerstage temperature

Service:

com.victronenergy.temperature.fronius_powerstage

This one reads the Fronius inverter powerstage temperature using the Fronius Solar API archive endpoint:

GetArchiveData.cgi with channel Temperature_Powerstage

Displayed value:

Fronius Powerstage Temp: OK
actual Fronius powerstage temperature in °C

The script also queries realtime inverter data from:

GetInverterRealtimeData.cgi?DataCollection=CommonInverterData

and uses:

PAC

DeviceStatus.StatusCode
DeviceStatus.ErrorCode

The displayed card title changes depending on status:

Fronius Powerstage Temp: OK
Fronius Powerstage Temp: Offline
Fronius Powerstage Temp: Warning
Fronius Powerstage Temp: Critical

Logic used:

  • temperature missing = Offline
  • temperature 0°C and PAC 0 W = Offline
  • known thermal/temperature-related Fronius error codes = Critical
  • fallback warning/critical thresholds are used as a safety layer
  • otherwise = OK

The temperature is real, but it comes from Fronius archive data, so the update interval is roughly the archive interval, about 5 minutes in my case.

3. Cerbo GX internal SoC/CPU temperature

Service:

com.victronenergy.temperature.cerbo_internal

This one reads the Linux thermal framework directly:

/sys/class/thermal/thermal_zone0/temp

Displayed value:

Cerbo Internal Temp: OK
actual Cerbo internal SoC/CPU temperature in °C

It also reads:

/sys/class/thermal/thermal_zone0/trip_point_*
/sys/class/thermal/cooling_device*/cur_state
/sys/class/thermal/cooling_device*/max_state

On my Cerbo GX, the exposed thermal data currently shows:

  • passive trip point: 75°C
  • critical trip point: 100°C
  • cooling device: cpufreq-cpu0
  • cooling state: 0/6 when not throttling

The displayed card title changes depending on state:

Cerbo Internal Temp: OK
Cerbo Internal Temp: Warning
Cerbo Internal Temp: Throttling
Cerbo Internal Temp: Hot
Cerbo Internal Temp: Critical

Logic used:

  • below passive trip and cooling state 0 = OK
  • above passive trip = Warning
  • cooling state > 0 = Throttling
  • above hot/critical trip points = Hot/Critical

This is not ambient room temperature. It is the internal Cerbo SoC/CPU temperature.

4. MultiPlus-II L1/L2/L3 thermal status

Services:

com.victronenergy.temperature.multi_l1
com.victronenergy.temperature.multi_l2
com.victronenergy.temperature.multi_l3

I have a three-phase Victron system with three MultiPlus-II units, so I created one virtual card per phase/unit.

Important note:

I could not find any actual internal MultiPlus temperature in °C exposed on D-Bus. The following paths are empty on my system:

/BatterySense/Temperature
/Dc/0/Temperature

So these cards do not currently show a real internal MultiPlus temperature. Instead, they show a thermal status derived from VE.Bus flags.

Current displayed value:

Multi L1 Thermal: OK
Multi L2 Thermal: OK
Multi L3 Thermal: OK

At the moment /Temperature is used as a numeric status value:

  • 0 = OK
  • 1 = Warning
  • 2 = Critical

The important part is the card title, which changes based on flags.

Variables used:

/Alarms/L1/HighTemperature
/Alarms/L2/HighTemperature
/Alarms/L3/HighTemperature
/Alarms/HighTemperature
/Hub4/L1/CurrentLimitedDueToHighTemp
/Hub4/L2/CurrentLimitedDueToHighTemp
/Hub4/L3/CurrentLimitedDueToHighTemp
/Devices/0/ExtendStatus/TemperatureHighForceBypass
/Devices/1/ExtendStatus/TemperatureHighForceBypass
/Devices/2/ExtendStatus/TemperatureHighForceBypass
/Devices/0/ExtendStatus/PowerPackPreOverload
/Devices/1/ExtendStatus/PowerPackPreOverload
/Devices/2/ExtendStatus/PowerPackPreOverload
/Leds/Temperature

Logic used:

  • no flags active = OK
  • current limited due to high temperature = Warning
  • temperature high force bypass = Warning
  • powerpack pre-overload = Warning
  • temperature LED active = Warning
  • high temperature alarm = Critical

Future plan:

I will probably add three Victron temperature sensors at the exhaust of the three MultiPlus-II units. Once those are installed, I plan to modify the virtual Multi thermal cards so that:

/Temperature = real exhaust temperature from the physical sensor
/CustomName = thermal status based on VE.Bus flags

So the final result would look like:

Multi L1 Thermal: OK
42.3 °C

or:

Multi L2 Thermal: Warning
58.1 °C

This would combine real measured exhaust temperature with the internal VE.Bus thermal/derating flags.

All scripts are stored under /data and are started as runit services via /service, with /data/rc.local recreating the service symlinks after reboot or firmware update.

17

What temperature are you all setting your fan(s) to come one/off? Up until now I’ve been using a temperature sensor mounted to the heat sink (earth connection) calibrated in my Cerbo gx by using a temperature sensor supplied with my multimeter. The internal temperature sensor reports a temperature consistently at 12 deg higher, even when it’s all effectively cold after sitting idle until 4am. Ambient temperature last night was about 13 deg.

image
image2214×1189 152 KB

I’m not really sure why that is, except perhaps the algorithm for decoding the temperature from the dbus data might not be correct but I’ve no way of knowing that. So I was wondering what ‘cold’ internal temperature you are all seeing and based on that what fan trigger temperatures you are using?

18

My device is a SmartSolar MPPT VE.Can 250/70 rev2. Today I installed the script and was happy to see the measurement working fine.
But when passing the threshhold (in my case 40 C) nothing happened, the relay remained open.

After that I tried to trigger a state change of the relay in NodeRed, using a relay control node. The function itsself seems to be ok, NodeRed shows the relay state changes when temperature is raising or falling, but nothing is happening with the physical relay on the MPPT.

Does anybody have a clue what’s wrong ?

I found the fault. Relay was not set to “manual”. Now it’s working as estimated.

19

Hi Derek,

I measuered and compared the MPPT temperature with an infrared sensor. The difference betwenn MPPT and the sensor is smaller than 0.5 degrees, so I would assume the MPPT measurement is correct.

I set the switch-on temperature to 40 degrees and switch-off to 35. This is working quite good.

grafik
grafik331×431 10.4 KB

20

Thank you for that. Much appreciated.