Over recent months I’ve developed two Arduino compatible programs. one for any Victron battery monitor, the other any Victron solar controller. These programs bring together all the following knowledge to receive, dissect, decrypt, decode and report the current device status and readings from the ‘advertised data’ that is continually transmitted over Bluetooth Low Energy (BLE) by the Victron device.
There were many challenges along the way and information was patchy and scattered widely. My GitHub submission captures the key points in one place, for others wanting to read their Victron device status, without (or in addition to) using the Victron Connect app (VC) on your mobile.
Even if you’re not using Arduino the information is generally useful for anyone trying to read this data.
This is great and impressively well documented .
It also begs the question whether it’s feasible to make the output ve-direct compatible to enable BT wireless connections to a Cerbo GX. In read only mode and a manual transfer of settings to fill in the blanks not advertised.
guystewart
(Guy Stewart (Victron Community Manager))
3
Very cool @ChrisJ7903 and nicely documented project in GitHub.
This post might find more like minded people in the modifications space, I’ll move it there now.
I’m working on a couple of loose ends for these 2 programs and I need some Victron expertise/help regarding the 0 .. 51A “Load current” field listed near the bottom of the Solar Charger table in your famous “Extra Manufacturer Data” document.
What current is this meant to represent? I went looking for info on VE_REG_DC_OUTPUT_CURRENT but the attached (zipped) Excel list of VE register values etc is all I could find, and it doesn’t realy clarify.
One reason I ask is this always returns the N/A value (0x1FF) on my MPPT 100/30 Solar Charger/Controller (SC)
Another reason is that VictronConnect only reports 5 advertised data items sor my SC on the home screen. One is labelled “Current” but that is the Battery Current further up the table.
The load current is the current on the load output of some MPPT chargers like the 75/15 (12 / 24 Volt | Victron Energy). Your MPPT model does not have a load output, so the value should be 0 or 0x1FF (as there is no load output).
I think I’ll add a switch into the SC code to turn Load Current reporting ON or OFF, then users can decide depending on their model.
However I mispoke in my last post: now that I’m looking closely at my MPPT100/30 output when running the sketch, I see my Load Current toggling randomly between 0x1FF and 0x0FF. This made me wonder if I was decoding it incorrecty, but I can’t test it as I only have an MPPT 100/30.
This is the relevant routine in my SolarController sketch:
float parseLoadAmps(){
uint16_t PVma100 = ((output[11] & 0x01) << 8) + output[10]; // NB little endian: byte[11] <-> byte[10]
if (PVma100 == 0x1FF) na_lodA = true;
return (static_cast<float>(PVma100)/10); // convert integer in 100mA units to Amps as float
}
Do you think this is decoding correctly ? Any chance you can test this?
PS: I’m going to replace that “+” with bitwise OR “|” in all these routines in next release = better coding !
This could be the data you’re after. Herewith a snapshot of the serial output from my development version of the SolarController program, running in VERBOSE mode.
The data: line is the raw manufacturer data [26 bytes].
The output: line is the decrypted data [16 bytes].
Although I only have a MPPT 100/30 it is reporting Load Amps as the last value in the decrypted values: line. This value randomly flips between n/a-A and 25.5A corresponding to 0x1FF and 0x0FF respectively in the output: It shows output[10] is always 0xFF but the least bit of output[11] randomly flips. The 0x0FF value causes the [duds: 1]
I’m planning to add an (optional) way to omit reporting of Load Amps for models that don’t support it. Meanwhile this random bit flipping by my MPPT 100/30 actually helps to demonstrate the issue to you
If you want the raw data see the attached text file, containing the same #045#046 data just embedded in between outputs #022 to #047. SC_F_ouput.txt (3.6 KB)
I must admit that the error is caused by my code that I contributed to your project. I changed the byte wise copy in a for loop to a call to getBytes(). The API is however poorly documented and it seems that when calling getBytes(buffer, len), it does not copy len characters, but it copies len -1 characters and places a 0 byte at position buffer[len - 1], which is not directly obvious from the API / documentation. This means that the last byte always will be 0. And depending on the encryption nonce and key, that will randomly result in the high bit of the load being 0 or 1.
.
