Incorrect kVA readings pulled through to SAP

sdg.marinusvz
2024-08-01 10:24
Last Edited 2024-08-01 11:49

This post has been transcribed from a support call

Hi MvZ:Please investigate. How the incorrect kVA readings pulled through as the IEC readout reflects as follows:

kVA- Meter:57XXX154

IEC readout:1-1:9.6.2(0.042*kVA)(24-06-27 16:00)= 8,4kVA

MDUS:0.000kVA

kVA- Meter:57XXX153

IEC readout:1-1:9.6.2(0.040*kVA)(24-06-04 15:00)= 8kVA MDUS: NULL

sdg.marinusvz
2024-08-01 10:25

Hi X, we always get kVA from profile. So probably there was a spike of some kind?

sdg.marinusvz
2024-08-01 10:25

How do I resolve it?

sdg.marinusvz
2024-08-01 10:27
Last Edited 2024-08-01 11:49

wow, such a big gap in the profile?

was the meter off?

multiplier of 200000? is that accurate?

> How do I resolve it?

once the profile is correct, like any other reading: rollback link on the MDUS meter reading report

is it an implausible on SAP?

sdg.marinusvz
2024-08-01 10:28

> was the meter off?

yes

> multiplier of 200000? is that accurate?

yes. 132 kV supply

sdg.marinusvz
2024-08-01 10:28

so mdus returned 0 kVA to SAP?

8409.518 in provisional bill. divided by 200000, 0.04204759

sdg.marinusvz
2024-08-01 10:29
Last Edited 2024-08-01 11:50

Yes

Agree, but MDUS didn't report kVA to SAP. That is the concern

sdg.marinusvz
2024-08-01 10:30
Last Edited 2024-08-01 11:51

ok, so I see that 57XXX154 and 57XXX153 are in a summated account

That means that the MD must be vectorially summated. So technically, we cannot get the accurate kVA until both meters are called in.

so the MD is calculated over both, and then it splits according to the kWh, in the specific half hour, supposedly..

So, if you summate the kVA over both meters, for the same date, do you get the correct amount?

sdg.marinusvz
2024-08-01 10:30

Will check and get back to you.

sdg.marinusvz
2024-08-01 10:32
Last Edited 2024-08-01 11:51

it is a bit strange to split the kVA between 2 summated meters, especially in a case like this, where the feeders are basically a backup for each other

in a way, the kVA of that meter at the kVA moment is really zero.

DEMAND (in kVA) 0.995pf 2024-06-11 12:00 8438.009kVA

2024-06-11, 57XXX154 was pulling no power

So the kVA for 57XXX153 is not sent because 57XXX154 has not been called in yet?

java.lang.Exception: 57XXX153 Meter not read in sufficiently yet co-incident being 57XXX154

sdg.marinusvz
2024-08-01 10:32

Meter supply off, due to feeder being off

sdg.marinusvz
2024-08-01 10:33
Last Edited 2024-08-01 11:53

so, it is still a bit strange to me, what was sent to SAP? It seems to me there is room for improvement here, in terms of how things work. I mean, for a summation account, how do you say it is 'acceptable' to send a kVA reading if both meters are not read in...

sdg.marinusvz
2024-08-01 10:33
Last Edited 2024-08-01 11:55

I would have expected 57XXX153 to update and 57XXX154 not to update, since 57XXX153 is called in beyond 2024-06-30 and 57XXX154 is not. However, now 57XXX154 has sent a zero reading, and 57XXX153 has not sent a reading, because it is a summation account, and 57XXX154 did not read in yet.

in fact, both should not have updated

because it is a summation account

so according to how I read the code, the weird thing is that 57XXX154 sent 0...

aha! I see you made its connect status on 27 Julie 'disconnected'?

sdg.marinusvz
2024-08-01 10:35

I did so as the meter supply was off.

What is the correct process?

sdg.marinusvz
2024-08-01 10:39
Last Edited 2024-08-01 11:56

that would explain to an extent why 57XXX154 passed the first check. (readings for 'Disconnected' meters are returned even if not called in up to date)

Let me read a bit further... because:

Why shall it take that one, if the other one is not also called in? BUT the other one is also read in? So that is why. BUT I see jou changed the disconnect status back to 'normal' 6 minutes later. So the other meter did not have a chance to send an update to SAP yet, and now it doesn't want to update because 57XXX154 is not on 'disconnected' any more, so it must therefore be up to date before 57XXX153 would send its reading to SAP.

> What is the correct process?
then why did you switch it back to normal 6 minutes later on 2024-07-23? That is why 57606153 is not updating. How is this part of your process? oic, this is what you do for summation meters, where one of the feeder's meters switch off when the feeder is off.

sdg.marinusvz
2024-08-01 10:39
Last Edited 2024-08-01 11:57

The readings for meter 57XXX153 still did not update even though meter 57XXX154 was disconnected.

Then I did not understand the disconnect function. Meters for summated accounts should remain disconnected should they be off in the field for the remaining meters that are on to report readings?

sdg.marinusvz
2024-08-01 10:40
Last Edited 2024-08-01 11:57

57XXX153 didn't 'change' when you updated the connection status of 57XXX154, so MDUS didn't receive a notify update for it to see if I should send the reading to SAP.

('disconnected' tells the system to send the last reading from the meter even if it is not read in up to date)

sdg.marinusvz
2024-08-01 10:50

> What is the correct process?
I suppose, you should send a change notification for the other meters in the summation account as part of the procedure. That would then cause both meters's kVA readings to update to SAP.

You can use Tools->Send Meter Entity Change Notifications

sdg.marinusvz
2024-08-01 11:00

You know what, let me change the code, so that when you edit a meter from the advanced meter settings screen, that it will also send a change update to the other meters in the same summation account.

Then you should next time get both readings updated to SAP within that 6 minutes, after the first edit.

Please log in to post a comment