Help to decode VBUS Payload data

[Jacob Mortensen]

Hi,

I have a Resol SunCtrl. I need to fetch Energy, Power and top temperature.

I get VBUS tgms but have difficulties decoding the data values.

It sends different messages

 

0x0010 <- 0x1120  Cmd: 100 packetCount 0x0A

IT sends many of these packages

I can find 0x0010 <= 0x1120  Cmd: 100 in the documentation but with a smaller length

resol-vbus-docs (danielwippermann.github.io)

I have also tried to look at the received data bytes, but they do not match the model

Does anyone have a packet specification for

-          0x0010 <= 0x1120 Cmd: 100 packetCount: 0x0A

-          0x0010 <= 0x1120 Cmd: 100 packetCount: 0x11

-          0x0010 <= 0x1120 Cmd: 100 packetCount: 0x45

-          0x0015 <= 0x1120 Cmd: 100 packetCount: 0x0A

-          0x0010 <= 0x2220 Cmd: 100 packetCount: 0x11

[Daniel Wippermann]

Hi Jacob,

hmmm. you should not see so much deviation in the packetCount value. Something seems odd.

I assume that you VBus receiver does not work correctly, since a address 0x2220 is not assigned and should not be used. A malfunctioning VBus receiver would also explain why the packetCount differs.

Could please post a sequence of received raw bytes? I’d like to take a look on the checksums etc.

Thanks in advance,

Daniel

--
You received this message because you are subscribed to the Google Groups "Resol Vbus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resol-vbus+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/resol-vbus/2102242b-0a87-40f2-b478-47ce85de2987n%40googlegroups.com.

[Jacob Mortensen]

Hi Daniel

I have some dumps here, start delimiter is not shown 

90% of my received packets is 

 0x0010 <= 0x1120 Cmd: 100 packetCount: 0x0A

10-00-20-11-10-00-01-11-0A-05-01-09-01-00-15-29-00-38-22-05-15-02-01-01-01-00-40-21-89-21-89-15-09-01-01-01-01-01-05-01-01-01-91-01-25-01-04-04-04-04-14-04-04-04-04-04-74-04-14-04-04-04-24-04-00-01-00-00-01-00-00-03-00-00-02-00-00-02-00-00-48-29-29-28-88-28-28-28-09-08-88-00-00-00-00-00-01-00-00-00-00-00-01-00-00-00-00-00-01-00-00

10-00-20-11-10-00-01-11-0A-05-01-09-01-00-15-29-00-08-22-05-15-02-01-01-01-00-50-08-22-08-22-05-42-00-00-00-00-00-01-00-00-00-24-00-09-00-00-00-00-00-01-00-00-00-00-00-03-00-01-00-00-00-02-00-00-00-00-02-00-00-00-00-02-00-06-00-00-48-29-29-28-88-28-28-28-09-04-44-04-04-04-04-04-14-04-04-04-04-04-14-04-04-04-04-04-74-04-04-04-04-04

10-00-20-11-10-00-01-11-0A-04-01-09-01-00-12-10-00-38-22-05-10-01-01-01-01-00-41-08-22-08-22-05-42-00-00-00-00-00-01-00-00-00-24-00-09-00-00-00-00-00-01-00-00-00-00-00-03-00-01-00-00-00-02-00-00-00-00-00-00-00-00-00-00-48-29-28-28-88-28-28-C8-09-04-14-04-04-04-04-04-00-00-00-00-00-00-01-00-00-00-00-00-01-00-00-00-00-00-01-00-00-00

Br. Jacob

[Daniel Wippermann]

Hi Jacob,

thanks for the dumps.

As suspected there seems to be something off with your receiver. Those byte sequences are not valid VBus communication since all of the three samples have a checksum mismatch in the version 1.0 header part. And if you encounter a mismatch there you cannot trust any of the information inside and following the „header“.

10-00                        Destination Address 0x0010 (DFA)

      20-11                  Source Address 0x1120

            10               Protocol version 0x10 (1.0)

               00-01         Command 0x0100

                     11      Frame Count (17)

                        0A   Checksum (wrong!)

Even ignoring those checksum errors there are other obvious problems with the byte streams like bytes which have their most significant bit set.

What kind of receiver are you using?

Best regards,

  Daniel

[Jacob Mortensen]

Hi Daniel

Thank you

I did not pay attention to the sum, I only focused on the data, my bad.

My service in fact tells that both header and blocks have sum fault.

I found a bug in my receiver sw, now it restart receiver each time a high bit is set during receiving.

My setup is that I at home for test has a DeltaSol BX.

I have made a VBUS to RS485 converter that is connected to RS485 to Ethernet box that connects to my service. 

This works correct I get correct VBUS tgms without sum faults

It sends this frame and I can test that the 4 temperatures are correct

DFA (0x0010) <= DeltaSol Plus (0x5210), command 0x0100

My faulty setup has the same VBUS->RS485->Ethernet. The Resol controller should be an 8 year old  SKSC3+ 

I have not seen the controller. It is far away and I had another personen to connect the communication box.

Really strange. I wonder how start delimiter, command, and protocol looks VBUS correct, but other data like sum are not correct.

Br. Jacob

[Daniel Wippermann]

Hi Jacob,

one possible explanation for such an effect is if too much energy is drawn from the VBus.

As you might know the VBus is used to transport both power and data. But it only works as long as all attached devices that draw energy from the VBus do not overburden the power supplied by the controller. That’s because the transport of data interrupts the transport of energy and bus-powered devices must accomodate for that by buffering energy on their side which is recharged while the VBus is at idle voltage (around 8-9 volts). That’s one of the reasons why the VBus communication includes large idle periods: it allows those bus-powered devices to properly recharge before the next transmission starts.

I have attached a crude scribble of what I mean by that to this mail.

In the upper part of the scribble you see a VBus signal under ideal circumstances: every time a VBus device sends data, it „short-circuits“ the supplied power. But the diagram shows how the energy level quickly recovers to its full energy potential during idle phases. The yellow line indicates the threshold that needs to be reached for a receiver to work correctly. And in that ideal diagram it surpasses that threshold every time.

The lower part of the scribble describes what happens when the bus is overburdened. After each transmission the energy level is a bit lower than before and it would need a longer idle period to regain its original level. It does not matter in the beginning, because the energy levels are „high enough“ for the receiver to detect it (the yellow line). But once the energy is drained enough, the receiver starts to fail - in unpredictable ways - receiving only garbage or nothing at all.

It needs the long break between transmissions to fully regain its energy.

That data in the beginning can be the SYNC byte delimiter, the addresses, protocol version and command. And after that it might start failing in unpredictable ways.

The caveat here is that different VBus topologies react differently. Controllers provide different amounts of energy, attached modules draw different amount from that. So a DIY receiver that works on your BX topology is not guaranteed to work on other topologies.

As I said: that is only one possible explanation and might not be the case for your situation, but it is the case I have encountered myself before.

Best regards,

Daniel

On Samstag, Apr. 22, 2023 at 9:23 PM, Jacob Mortensen <jacob.so...@gmail.com> wrote:

Hi Daniel

[Jacob Mortensen]

Hi Daniel

Thanks a lot.

I have almost given up on the old resol controller and now my aproch is to use my test DeltaSol BX at the customer installation.

For the DeltaSol BX I had much more progress.

I get header 10-00-52-10-10-00-01-10-6C

10-00                        Destination Address 0x0010 (DFA)

      52-10                  Source Address 0x1052

            10               Protocol version 0x10 (1.0)

               00-01         Command 0x0100

                     10      Frame Count (16)

                        6C   Checksum (OK)

Complete frame

10-00-52-10-10-00-01-10-6C-4A-00-57-00-05-59-38-22-38-22-05-46-38-22-38-22-05-46-38-22-38-22-05-46-0F-27-46-05-00-7E-0F-27-0F-27-00-13-00-00-00-00-00-7F-00-00-00-00-00-7F-00-00-00-00-00-7F-0F-27-0F-27-00-13-64-1E-00-00-00-7D-00-7F-7F-7F-0E-74-1F-6E-58-34-05-61-04-00-00-00-00-7B-00-00-00-00-00-7F-7F-7F-7F-7F-0F-74

When I look in spec I can see the coding of address is that first digit is number of sensors. 

In my stituation it is 5

When I look up the packet speification I find this

DFA (0x0010) <= DeltaSol Plus (0x5210), command 0x0100

resol-vbus-docs (danielwippermann.github.io)

That defines 5 sensors.

My DeltaSol BX has 8 sensors and the frame also contains 8 temperature sensors

 10-00-52-10-10-00-01-10-6C-4A-00-57-00-05-59-38-22-38-22-05-46-38-22-38-22-05-46-38-22-38-22-05-46......

I also identified pump speeds in my frame 100% and 30%

10-00-52-10-10-00-01-10-6C-45-00-49-00-05-6C-38-22-38-22-05-46-38-22-38-22-05-46-38-22-4B-00-05-55-0F-27-46-05-00-7E-0F-27-0F-27-00-13-00-00-00-00-00-7F-00-00-00-00-00-7F-00-00-00-00-00-7F-0F-27-0F-27-00-13-64-1E-00-00-00-7D-00-7F-7F-7F-0E-74-11-00-58-34-07-5B-04-00-00-00-00-7B-00-00-00-00-00-7F-7F-7F-7F-7F-0F-74

My problem is to identify the HeatEnergy. In spec for DFA (0x0010) <= DeltaSol Plus (0x5210), command 0x0100  it says byte 16-21 but that cannotbe correct in my frame

I found this 4 bytes that are incrementing and could be the LSB of the 6 byte HeatEnergy

10-00-52-10-10-00-01-10-6C-23-01-4B-00-04-0C-38-22-38-22-05-46-38-22-38-22-05-46-38-22-52-00-05-4E-0F-27-46-05-00-7E-0F-27-0F-27-00-13-00-00-00-00-00-7F-00-00-00-00-00-7F-00-00-00-00-00-7F-0F-27-0F-27-00-13-1E-00-00-00-00-61-00-7F-7F-7F-0E-74-7A-2B-59-34-04-49-04-00-00-00-00-7B-00-00-00-00-00-7F-7F-7F-7F-7F-0F-74

Can you tell where the HeatEnergy is placed?

Do you have any documentation for Deltasol BX 8 sensor tgm frame?

Br. Jacob

[Daniel Wippermann]

Hi Jacob,

great, those byte sequences actually decode to a valid packet!

I spotted a mismatch in your packet diagnostic: you correctly decoded „52-10“ as „Source Address 0x1052“, but later searched for a VBus specification for 0x5210, which is a completely different device.

The specification for your packet is actually here:

Fields: http://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_1052_10_0100

Bytes: http://danielwippermann.github.io/resol-vbus/#/vsf/bytes/00_0010_1052_10_0100

If I decode the byte stream you provided, it yields the following fields and values:

00_0010_1052_10_0100 -> "Kioto BX Plus V2 [Regler]"

00_0010_1052_10_0100_000_2_0 -> "Temperature sensor 1" -> 20.200000000000003 -> "20.2 °C"

00_0010_1052_10_0100_002_2_0 -> "Temperature sensor 2" -> 21.5 -> "21.5 °C"

00_0010_1052_10_0100_004_2_0 -> "Temperature sensor 3" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_006_2_0 -> "Temperature sensor 4" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_008_2_0 -> "Temperature sensor 5" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_010_2_0 -> "Temperature sensor 6" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_012_2_0 -> "Temperature sensor 7" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_014_2_0 -> "Temperature sensor 8" -> 888.8000000000001 -> "888.8 °C"

00_0010_1052_10_0100_016_2_0 -> "Temperature sensor 9" -> 999.9000000000001 -> "999.9 °C"

00_0010_1052_10_0100_018_2_0 -> "Irradiation sensor 10" -> 1350 -> "1350 W/m²"

00_0010_1052_10_0100_020_2_0 -> "Temperature sensor 11" -> 999.9000000000001 -> "999.9 °C"

00_0010_1052_10_0100_022_2_0 -> "Temperature sensor 12" -> 999.9000000000001 -> "999.9 °C"

00_0010_1052_10_0100_024_4_0 -> "Flow rate Sensor 9" -> 0 -> "0 l/h"

00_0010_1052_10_0100_028_4_0 -> "Flow rate Sensor 11" -> 0 -> "0 l/h"

00_0010_1052_10_0100_032_4_0 -> "Flow rate Sensor 12" -> 0 -> "0 l/h"

00_0010_1052_10_0100_036_2_0 -> "Pressure sensor 11" -> 99.99000000000001 -> "99.99 bar"

00_0010_1052_10_0100_038_2_0 -> "Pressure sensor 12" -> 99.99000000000001 -> "99.99 bar"

00_0010_1052_10_0100_040_1_0 -> "Pump speed relay 1" -> 100 -> "100%"

00_0010_1052_10_0100_041_1_0 -> "Pump speed relay 2" -> 30 -> "30%"

00_0010_1052_10_0100_042_1_0 -> "Pump speed relay 3" -> 0 -> "0%"

00_0010_1052_10_0100_043_1_0 -> "Pump speed relay 4" -> 0 -> "0%"

00_0010_1052_10_0100_044_1_0 -> "Pump speed relay 5" -> 0 -> "0%"

00_0010_1052_10_0100_048_4_0 -> "System date" -> 886599327 -> "02/04/2029 13:35:27"

00_0010_1052_10_0100_052_4_0 -> "Error mask" -> 4 -> „4"

So far, so good…

> When I look in spec I can see the coding of address is that first digit is number of sensors. 

Yeah, that rule does not apply any more… Back in the days where controllers used to have 3 to 6 sensors the numbering scheme was as you described. But modern controllers started to have more than 7 sensors (and due to the „no MSB“ rule 7 is the maximum number in the first place of the address) we broke that rule and started to assign whatever address was available for the pool. So your controller 0x1052 indeed has more than 1 sensor and 0 relais :)

You can find the exact byte positions for your temperatures in the „Bytes“ link above.

> My problem is to identify the HeatEnergy. In spec for DFA (0x0010) <= DeltaSol Plus (0x5210), command 0x0100  it says byte 16-21 but that cannotbe correct in my frame

> I found this 4 bytes that are incrementing and could be the LSB of the 6 byte HeatEnergy

The four bytes you found (including the fifth byte which contains the extracted MSBs, see the „Septett-Bytes“ section of http://danielwippermann.github.io/resol-vbus/#/md/docs/vbus-specification for details) belong to the „System date“. That explains why it is steadily increasing as well.

> Can you tell where the HeatEnergy is placed?

Yes, it should be here:

Fields: http://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_1056_10_0100

Bytes: http://danielwippermann.github.io/resol-vbus/#/vsf/bytes/00_0010_1056_10_0100

As you can see it should be in a separate packet with source address 0x1056. That packet is only transmitted if the heat quantity measurement option is activated. So if you do not find it on the VBus please check your controller’s configuration.

Best regards,

Daniel

--
You received this message because you are subscribed to the Google Groups "RESOL VBus" group.

To unsubscribe from this group and stop receiving emails from it, send an email to resol-vbus+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/resol-vbus/3ea63fa7-01fe-4959-b14e-ee1f68e69aebn%40googlegroups.com.