I’m writing a library that converts and stores data from Victon products via the VE Direct cable.
The text protocol is fairly straightforward. The HEX on the other hand…
I’m receiving the following ASYNC messages from an ORION XS
valid HEX [11] [A0102000642]
valid HEX [11] [A0002000148]
valid HEX [17] [ABCED00050000009D]
valid HEX [17] [A00E0002300000048]
valid HEX [17] [A00E0000300000068]
valid HEX [17] [ABCED00030000009F]
valid HEX [17] [ABCED00030000009F]
valid HEX [17] [A00E0002300000048]
valid HEX [17] [A00E0000300000068]
valid HEX [17] [ABCED00030000009F]
valid HEX [17] [ABCED00050000009D]
valid HEX [17] [A00E0002300000048]
valid HEX [11] [A0102000642]
valid HEX [17] [A00E0000300000068]
valid HEX [11] [A0002000148]
valid HEX [17] [ABCED00050000009D]
valid HEX [113] [A701000007B000000040000002F1C000000000000000000006D630500000000000000000000000000000000000B000000B2048E05FFF100E8]
valid HEX [59] [A431000001B8005000B000000010000000100000001000000000000004A]
valid HEX [59] [A421000001B8005000B000000010000000100000001000000000000004B]
valid HEX [17] [ABCED00040000009E]
valid HEX [17] [A00E0002300000048]
valid HEX [17] [A00E0000300000068]
valid HEX [17] [ABCED00050000009D]
valid HEX [17] [ABCED00050000009D]
As you can see there are some fairly long HEX messages there… 113bytes being the longest… from register 0x1070. This looks like it might be a history value as the registers 0x10?? in the MPPT are historical values.
Can anyone shed some light…
I’m wondering what size of buffer I’m needing to allocate for HEX vars… as 113 bytes is fairly large.
Yes, 10xx are history values and are using the longest message defined, 52 bytes for history data.
As you can see here, on my second post.
With 2 chars per byte in hex protocol and another 9 for control stuff, use at least 9+52*2 = 113 bytes.
Just like you’ve already observed… 
Thanks for the reply. ok that makes sense…
HEX [0xE000] [FLAG:0] [LEN:8] [23000000]
HEX [0x0201] [FLAG:0] [LEN:2] [06]
HEX [0xE000] [FLAG:0] [LEN:8] [03000000]
HEX [0x0200] [FLAG:0] [LEN:2] [01]
HEX [0xEDBC] [FLAG:0] [LEN:8] [03000000]
HEX [0xEDBC] [FLAG:0] [LEN:8] [05000000]
HEX [0xE000] [FLAG:0] [LEN:8] [23000000]
HEX [0xE000] [FLAG:0] [LEN:8] [03000000]
HEX [0xEDBC] [FLAG:0] [LEN:8] [06000000]
HEX [0xEDBC] [FLAG:0] [LEN:8] [05000000]
HEX [0xE000] [FLAG:0] [LEN:8] [23000000]
So these are the regular ASYNC messages. I’ve not written the GET side of things yet…
I can’t find reference to these in your documentation…
0xE000. Seems to change value very frequently…
0xEDBC = input power…
I will keep digging… Still got a fair amount of the interface to write…
0xE000: VE_REG_BPC_LED_STATE
Additional info:
Blue Power Charger LED “State” e. g. for VictronConnect to mimic LED behaviour (un32 read-only).
3 bits reserved per LED; from lsb to msb: “test” “bulk” “abs” “float” “storage” “normal” “high” “recon” li-ion.
Definition: “0:off” “1:on” “2:blink” 3:blink “inverted” 3-6: “reserved” 7:invalid.
0xEDBC: VE_REG_DC_INPUT_POWER
Additional info:
Charger input specific parameters - actual input power (un32 = power “[0. 01W]” read-only)
Thank you.
What was your source for this?
VictronConnect application. 
1 Like
Is there a good register to test writing a value to… that is not important…
It depends on what’s writable (as register) on your device.
I don’t have such device to say for sure, but being a charger, you can try to read the 0xEDDC (VE_REG_CHR_USER_YIELD) which is Charger user yield.
If you obtain a valid value (different than 0xFFFFFFFF), then that register is also writable and if you put 0 on it, will reset the yield.
Or try 0x1030 (VE_REG_CLEAR_HISTORY) where writing a 0 will clear the history.