30m readings are offset

I noticed a problem, but Hildebrand have told me they are declining to investigate, saying I'm the only person seeing it ( BTW I don't agree with this approach to CS!) 

So I thought I'd ask here: is anyone else seeing this? 

As described in the FAQ, the 1m and 30m readings are constructed in 3 stages as follows:

1. The CAD gets readings every 10s from the meter, and sends these on to Hildebrand servers. These are aggregated to 1m and preliminary 30m readings

2. The meter sends 30m readings after the HH end, these will overwrite the preliminary readings 

3. Usually about 9 or 10am, the DCC figures overwrite the 30m ones for the previous day.

I believe things are going wrong at step 2, and these readings are put in the wrong slot - the one prior to the correct one. 

I have a tariff that goes to off-peak at 11pm, so I have automations that mean house load jumps from near zero at 11pm, but Bright and the api report this jump at 22:30 - until the DCC update the next morning; when that happens, the numbers are shifted forwards into the correct slot. 

If I overlay the 1m and 30m readings on a graph, there is an obvious mismatch, until corrected by step 3. And for most of the day, the first HH reading for the day (00:00Z) is missing, but is reinstated after the DCC update the next morning.  

I have the wired CAD, so no way to view readings locally other than mqtt, which doesn't include the 30m readings. 

I've checked the time on the meter (it's accurate), and also my Secure IHD shows the readings correctly (with no offset).

I took a packet trace of the CAD traffic - it shows two streams to Hildebrand, one is UDP (I think that data looks OK), the other is encrypted (TLS) and I suspect this is where the HH readings are sent, but I don't know the key so can't decrypt these. 

This was not happening with my old Glowstick, so may be specific to my CAD, or perhaps just the wired CAD more generally, but I'm very interested to find out...