Vedirect victron node-red

Modifications
,
1

Hello.
I’m using this node to acquire data from a Victron smartshunt.
I find a problem of which I cannot understand the nature, questioning him I obtain alternately in seemingly random way this information:

`{"PID":{"value":"0xA389","product":"SmartShunt 500A/50mV","description":"ProductID","units":""},"V":{"value":54033,"description":"Main or channel 1 (battery) voltage","units":"mV"},"I":{"value":8191,"description":"Main or channel 1 battery current","units":"mA"},"P":{"value":443,"description":"Instantaneous power","units":"W"},"CE":{"value":0,"description":"Consumed Amp Hours","units":"mAh"},"SOC":{"value":1000,"description":"State-of-charge","units":"‰"},"TTG":{"value":-1,"description":"Time-to-go","units":"Minutes"},"Alarm":{"value":"OFF","description":"Alarm condition active","units":""},"AR":{"value":0,"description":"Alarm reason","units":""},"BMV":{"value":"SmartShunt 500A/50mV","description":"Model description (deprecated)","units":""},"FW":{"value":412,"description":"Firmware version (16 bit)","units":""},"MON":{"value":0,"description":"DC monitor mode","units":""}}`
{"H1":{"value":-169877,"description":"Depth of the deepest discharge","units":"mAh"},"H2":{"value":0,"description":"Depth of the last discharge","units":"mAh"},"H3":{"value":-26402,"description":"Depth of the average discharge","units":"mAh"},"H4":{"value":37,"description":"Number of charge cycles","units":""},"H5":{"value":0,"description":"Number of full discharges","units":""},"H6":{"value":-41542003,"description":"Cumulative Amp Hours drawn","units":"mAh"},"H7":{"value":50363,"description":"Minimum main (battery) voltage","units":"mV"},"H8":{"value":59022,"description":"Maximum main (battery) voltage","units":"mV"},"H9":{"value":0,"description":"Number of seconds since last full charge","units":"Seconds"},"H10":{"value":487,"description":"Number of automatic synchronizations","units":""},"H11":{"value":0,"description":"Number of low main voltage alarms","units":""},"H12":{"value":0,"description":"Number of high main voltage alarms","units":""},"H15":{"value":0,"description":"Minimum auxiliary (battery) voltage","units":"mV"},"H16":{"value":0,"description":"Maximum auxiliary (battery) voltage","units":"mV"},"H17":{"value":221642,"description":"Amount of discharged energy (BMV) / Amount of produced energy (DC monitor)","units":"0.01 kWh"},"H18":{"value":231236,"description":"Amount of charged energy (BMV) / Amount of consumed energy (DC monitor)","units":"0.01 kWh"}}

these should be correct and I get the main parameters


`{"H1":{"value":-169877,"description":"Depth of the deepest discharge","units":"mAh"},"H2":{"value":0,"description":"Depth of the last discharge","units":"mAh"},"H3":{"value":-26402,"description":"Depth of the average discharge","units":"mAh"},"H4":{"value":37,"description":"Number of charge cycles","units":""},"H5":{"value":0,"description":"Number of full discharges","units":""},"H6":{"value":-41542003,"description":"Cumulative Amp Hours drawn","units":"mAh"},"H7":{"value":50363,"description":"Minimum main (battery) voltage","units":"mV"},"H8":{"value":59022,"description":"Maximum main (battery) voltage","units":"mV"},"H9":{"value":0,"description":"Number of seconds since last full charge","units":"Seconds"},"H10":{"value":487,"description":"Number of automatic synchronizations","units":""},"H11":{"value":0,"description":"Number of low main voltage alarms","units":""},"H12":{"value":0,"description":"Number of high main voltage alarms","units":""},"H15":{"value":0,"description":"Minimum auxiliary (battery) voltage","units":"mV"},"H16":{"value":0,"description":"Maximum auxiliary (battery) voltage","units":"mV"},"H17":{"value":221642,"description":"Amount of discharged energy (BMV) / Amount of produced energy (DC monitor)","units":"0.01 kWh"},"H18":{"value":231236,"description":"Amount of charged energy (BMV) / Amount of consumed energy (DC monitor)","units":"0.01 kWh"}}`

These contain information but not what I expect.

this happens randomly alternating, a deploy is the only way I’ve experienced to get it back to “normal” but suddenly then change again.
Has anyone had experience with this knot?

2

Nobody used this node, at least to know about it works well?

3

What specific node are you using?
There is a battery monitor node that should provide data from shunts.

4

If I’m using that

Schermata del 2025-01-24 19-57-24

at this time not connected

5

Why are you using that node and not the Victron shunt nodes? What are you trying to do?
And why are you trying it with nothing connected?
The Victron nodes are well documented:

Get your devices connected, use the correct nodes and try again.

6

Thank you for your reply.

so I should install all the nodes even if I only need one node for the smart shunt?

npm install @victronenergy/node-red-contrib-victron

Can’t download and install only what I need?

7

However I tried to install all the nodes where you also includes that vedirect>usb, but it does not change anything randomly changes the output in the way written above, you have some tips to do some verification. don’t know what to do I can not interact with the node only the usb port you can change.
the same hardware on another system works correctly with the same ttl>usb converter ie openhab with its binding

8

Schermata del 2025-01-25 13-21-00
Schermata del 2025-01-25 13-21-001639×514 86.6 KB

9

Schermata del 2025-01-25 13-26-37
Schermata del 2025-01-25 13-26-371122×558 65.3 KB

randomly changes its output

10 
PID	0xA389
V	53443
I	6747
P	361
CE	0
SOC	1000
TTG	-1
Alarm	OFF
AR	0
BMV	SmartShunt 500A/50mV
FW	0412
MON	0
Checksum	`


H1	-169877
H2	0
H3	-26402
H4	37
H5	0
H6	-41954245
H7	50363
H8	59022
H9	0
H10	493
H11	0
H12	0
H15	0
H16	0
H17	223828
H18	233520
Checksum	Z

Good morning.
in an attempt to figure out how I should use this sensor, I sniffed from a working system the data traffic, which I attach.
It would seem that the data pass alternately in a cyclical manner with a fairly clean cadence.
the system from which I took the data is based on an openhab binding.
I would use this sensor on node-red but get the result of my first post, it is practically returned to me either the first part or the second with unforeseeable exchange. In this situation I can’t have a continuity in the readings and therefore it is unusable.
the node has no possibility of interaction with the sensor except the USB port schelta and the refresh rate.
Can anyone give me some help?
thanks
Joseph

11

The Hx headers for data are not well documented in the VE direct notes for the smart shunt. Some of them relate to historical data, some relate to cumulative data. thing to do is also connect to the same smart shunt with VE configure, and to inspect the data presented there and correlate with the Hx headers.
Typically I use the VE-direct Hex protocol, rather than the broadcast ASCII protocol - but then I don’t used node red.
There is a document BMV700 Series Hex protocol that is available from Victron, which covers some of the information, I haven’t found the equivalent for the shunt.

12

Thank you for your reply, any information is useful.
I did 2 tests, I tried to receive the data with the uart, and it works, but capturing the strings is difficult… seems there are:
< n>< tab>< r> but I haven’t been able to do very well it takes me a lot of resources for processing and I’m limited by rpi4.
I tried to send inject at 0.5 seconds and at least it takes all the data, even if sometimes it jumps but the update is fast and does not create too many problems, but also here I have a lot of resources impegnste on pi.
I would like to do a query test to get me back only what I need, but I have no clear idea of which commands to send if with checksum or not, if you have any other info I’d be grateful if you share them.
hello

Message format
The device transmits blocks of data at 1 second intervals. Each field is sent using the following
format:
<Newline><Field-Label><Tab><Field-Value>
The identifiers are defined as follows:
Identifier Meaning
<Newline> A carriage return followed by a line feed (0x0D, 0x0A).
<Field-Label> An arbitrary length label that identifies the field. Where applicable, this
will be the same as the label that is used on the LCD.
<Tab> A horizontal tab (0x09).
<Field-Value> The ASCII formatted value of this field. The number of characters
transmitted depends on the magnitude and sign of the value.
13

0x0001 : [870,32], #PID
0x8DED : [871,16], #main bat volt
0x7DED : [872,16], #aux bat volt
0x8FED : [873,16], # current
0x8CED : [874,32], # HR current
0x0FFF : [876,16], #SOC
0x8EED : [877,16], #pwr
0x0003 : [878,32], # deep discharge
0x0103 : [880,32], #last discharge
0x0203 : [882,32] # average discharge

msg_get_subat0 = str.encode( “:78DED00D4”+chr(0x0a))
msg_get_subat1 = str.encode( “:77DED00E4”+chr(0x0a))
msg_get_sIbat0 = str.encode( “:78FED00D2”+chr(0x0a))
msg_get_sIbat_hr = str.encode( “:78CED00D5”+chr(0x0a))
msg_get_sSOC = str.encode( “:7FF0F0040”+chr(0x0a))
msg_get_spwr = str.encode( “:78EED00D3”+chr(0x0a))
msg_get_ddd = str.encode( “:70003004B”+chr(0x0a))
msg_get_dld = str.encode( “:70103004A”+chr(0x0a))
msg_get_dad = str.encode( “:702030049”+chr(0x0a))
These are the codes I use to communicate with the shunt. Top section is a python dictionary, with the address indexed to my modbus register map and the data format.
Second section is the hex code requests, which MUST include the crc. request will be ignored if crc is invalid.
see VE-direct-1/VE7_0.py at main · MikeD2-mnb/VE-direct-1 · GitHub
for full program

14

Thanks 1000 for the valuable info.
I speak very little English (school/technical) so I have to use a translator, so as we know the translations leave doubts about terms used. So forgive me if I ask you to confirm things that you have already written clearly.

I seem to understand that the hex codes (at least 0001 x pid) can be sent via serial to the shunt without crc, what is different for the messages shown below that need crc?
I have interpreted well
Thanks again

15

msg_ping = str.encode( ‘:154’+chr(0x0a))
msg_get_pid = str.encode(“:70001004D”+chr(0x0a))

The GET PID message DOES have a CRC, again the rules for CRC calculation are in the Victron documentation for the Hex protocol.
the ping message is a special function code, so does not have a CRC.
no worries about asking questions, I sometimes use translation programs to look at posts in other languages. I have a little French, and can recognise German and Spanish