Olen
Some notes about Victron BLE
Hi,
Just want to share my discovery results..
Victron sends Data (and messages) using both ["306b0003-b081-4037-83dc-e59fcc3cdfd0"] and ["306b0004-b081-4037-83dc-e59fcc3cdfd0"]. You'll need to combine notifications to one buffer since sending characteristics can change even middle of the message.
Read request: 05-xx-82-19-VREG Query FW version 05-xx-82-19-01-02 Victron replies 08-xx-19-01-02-44-00-ff-21-03-09-xx-10-01 Reply can divided two messages 08-xx-19-01-02-44-00-ff-21-03 and 09-xx-10-01 Regarding to Victron VE.CAN documentation 00-ff-21-03 -> v3.21
Query Device State 05-xx-82-19-02-01 Reply 08-xx-19-02-01-41-06-09-xx-10-01 -> 0x06: Storage
Write requests: 06-xx-82-19-VREG-CBOR-DATA 06-xx 82-18-COMMAND-CBOR-DATA I haven't tested write requests yet.
Reply messages: 07-xx-yy-zz error messages 08-xx-19-VREG-CBOR-DATA 08-xx-18-(1 byte command)-CBOR-DATA 09-xx-19-VREG-DATA (for 1 data byte messages?) 09-xx-08-01 read request ok 09-xx-10-10 read request ok
xx = 00 (In my BSC IP22 24|16 Charger)
BR, Timo
Hi and thanks for the info. It's been a while since I looked at the code (it seems to work for my use case), but looking at what I have written, it seems like 306b0004-b081-4037-83dc-e59fcc3cdfd0 is used when there are multiple messages that needs to be concatenated, while 306b0003-b081-4037-83dc-e59fcc3cdfd0 is used for single messages
So a "4" will contain multiple "3" messages, and they need to be joined together, and then split into 8 byte chunks.
But this is just how I interpreted the messages at that time, I might be wrong.
Hi,
Change from "4" to "3": I 16:54:42.182 Notification received from 306b0004-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 09-00-19-ED-E6-01-09-00-19-ED-E0-01-08-00-19-02-06-41-00-09 I 16:54:42.190 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 00-19-ED-E8-01 ... I 16:54:42.341 Notification received from 306b0004-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 08-00-19-10-70-58-34-00-00-00-00-00-38-00-00-00-00-00-00-00 I 16:54:42.356 Notification received from 306b0004-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 00-00-00-00-00-00-00-00-00-00-00-00-02-00-00-00-00-00-00-00 I 16:54:42.372 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 00-00-00-00-00-00-00-00-00-00-00-00-95-0A-FF-FF-00-FF-00
Well, it seems that there could be multi-message notifications from "3" also.
I 17:45:56.106 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 08-00-19-ED-DB-42-7E-09-08-00-19-01-20-44-3C-0C-00-00 I 17:45:57.123 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 08-00-19-01-20-44-3D-0C-00-00 I 17:45:58.082 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 08-00-19-ED-DB-42-6A-09-08-00-19-01-20-44-3E-0C-00-00
I created a py parser (quick and dirty) which combine output from both characteristics and parse messages from buffer. With this kind of approach, parser's hit rate is 100%.
Yeah. I believe the "3" messages can contain multiple values, but it seems to me like they are "complete and self contained". E.g.
17:45:56.106 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 08-00-19-ED-DB-42-7E-09-08-00-19-01-20-44-3C-0C-00-00
If I understand it correctly, this is two full measurements:
08-00-19-ED-DB-42-7E-09 08-00-19-01-20-44-3C-0C-00-00
But the "4" to "3":
16:54:42.182 Notification received from 306b0004-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 09-00-19-ED-E6-01-09-00-19-ED-E0-01-08-00-19-02-06-41-00-09 16:54:42.190 Notification received from 306b0003-b081-4037-83dc-e59fcc3cdfd0, value: (0x) 00-19-ED-E8-01
Here the "4" seems to be split in the middle of one of the measurements and the rest is in a "3":
09-00-19-ED-E6-01 09-00-19-ED-E0-01 08-00-19-02-06-41-00 09 the rest of the last measurement is in the following "3": 00-19-ED-E8-01
So if I understand this correctly, if you get a "4", you should keep on filling your buffer until you get a "3" (which you should also add to the buffer) and then you can split the buffer on the prefix (eg. "0x-00-19") and get a number of values.
But if you read a "3" on its own, you can immediately split it on the prefix to get the values.
Does this make sense?
I think a
09-xx-19-VREG-DATA (for 1 data byte messages?)
response means that the VREG is not supported. On the trace I did with a mains charger, the 'DATA' values were 01 with 02 being used when the controller asked for a history record. No other values were returned. If it was actual data, that would be a big coincidence.
For instance, I saw the controller asking for these VREGs, with these responses:
1070 - (08-00-19) 5834
It looked as if the controller was just asking for all the possible history record VREGs, and the charger responded with 09-00-19 for the ones it didn't have/support
Similarly, if the controller asked for the details of the 'relay', the charger (which does not have a relay) responded with 09-00-19-03-4e-01 (034e is the VREG for the 'relay control'), which I think is saying 'that VREG is not supported'
Also, on the 75V/15A Smartsolar charger, VREG 0xEDBD (panel current) returns 09-03-91-ED-BD-01 and the docs say "panel current is not available on the 15A solar chargers"
Maybe the protocol description of victron helps for translating into bluetooth as well? Technical-Information-Data-communication-with-Victron-Energy-products_EN.pdf
Even a bit more information was given by victron in this post.
