Reading Power and Energy

Thanks Nick

We appreciate your feedback and solutions presented on this topic, as previously stated I am genuinely looking for a good reliable solution for energy monitoring and have looked at using the pulse meter option for cbus before - I was not aware that clipsal was about to release a new product/solution based on the pulse meter concept so I welcome these discussions to clear up my misconceptions.

I am not trying to knock the concept, I just want a solution and couldn't/can't see it as the right solution right now, maybe the latest software releases overcomes some/all of those issues and then again maybe not?

I still have some issues (apart from Power/Energy Accumulation) that you may help confirm and they still relate to response times etc ?
Some of these issues may now be sorted out since you guy's have released new software and have been testing the concept for the last three months as Conformist has also done in his home system?

From my point of view $1000-$1200 is seems a reasonable cost price for a 3-4 circuit energy monitoring system!

Here's another important point about timing?
Ok, say you have four EN40P pulse meters and a bus Coupler in a house with a typical energy demand of say 20kWh per day (my home uses 30kWh/day). This would produce something like 2000 pulses over say a 12 hour day which equates to about 1 pulse every 22 seconds (averaged).
Now the way I see it, this means that there will be a new Cbus transmission every 22 seconds or more depending on the power consumption at the time.
This pulse rate could be higher when you take into account that there are 4 X EN40P's sending their separate pulses to the Cbus Bus Coupler and at certain times, the interval between these separate pulses could be less than the 16mS that Newman was referring to - so we could also miss some of these power pulses (for cbus transmission) and loose metering accuracy/reliability?

I would think that the Cbus network traffic could become heavily loaded under these conditions? and when you add the normal Cbus network traffic that already exists it should get a little worse?

Now if I want to add another 4 X EN40P's and a Bus coupler to this network (for larger systems or another unit/apartment) then I reckon I will be in trouble and I will start to loose more and more of those metering pulses and maybe also my network starts to get really slow and things don't happen like they should anymore?

I must have got this wrong somewhere or maybe the new software overcomes these issues - but things don't quite add up for me here so I would appreciate the advise?
I would be interested in the knowing typical load demand that Conformist was using during his tests and whether he experienced/monitored any excess network traffic when using a single EN40P and Bus Coupler on his home network?

The EN40P pulse width appears to be 120mS - so maybe we have to set the debounce time longer than 16ms ( to say 64mS ) to avoid missing more pulses with multiple channels?

As Ashleigh has said, I know you guys do a lot of testing on these sorts of issues before release so please excuse my pondering.

Thanks

 

The 16ms minimum pulse width limit only applies to the minimum pulse width coming from a single power meter on a single input of a Bus Coupler input unit. The pulses from the EN40 are much wider than that. The timing interval only relates to the time taken to read the inputs of the bus coupler. C-Bus transmission timing is a separate thing and the bus has to be completely clagged with high priority messages for seconds (extremely unlikely) before the bus coupler will give up sending it's message.

 

Thanks Newman,

Assume the Bus Coupler is working in toggle (change of state) mode? and samples the inputs at 16ms intervals (is that how it works?)

So I assume, if input 1 detects a change of state then a Cbus transmission is initiated and the current state of all the inputs at that time are loaded in the transmission message?

Now say 20mS later input 2 changes state (via a different EN40P) but the first transmission hasn't been sent out as yet - does that mean the first transmission message is modified before it is sent (by re-sampling the inputs) or is a second transmission message loaded in some sort of que to be sent straight after the completion of the first transmission message - 20ms later?

 

I am now monitoring using 4 channels on a bus coupler from devices providing 1 pulse per W/Hr and a marker pulse width of 20ms - it does seem fine although just at the moment it is providing different readings to the already installed system so I need to determine why. It reads slightly higher which tends to imply this is not due to missed pulses, and maybe indicates the other system might be the one that is wrong. I'll accurately determine the power consumption and report back.

Some of my other pulse meters provide twice the resolution but still use a 20ms marker pulse. I have seen a meter providing ten times the resolution (one pulse per 0.1W / Hr ) and it is this that used a 10ms marker pulse which it probably had to do to be able to report fast enough. This type of device is not one that you're going to want to use for metering purposes so I think the 16ms pulse width is entirely adequate, and actually much better than I expected . I don't believe anyone should worry about this aspect.

The level of pulses applied to group level changes on C-Bus is obviously related to the max wattage that the pulse meter has to handle and its reporting resolution. At 1W/Hr and 1 pulse per second this equates to 3.6KW. For a 10W/Hr resolution this would be 36KW or 1 pulse every 10 secs at 3.6KW. If the C-Bus coupler is set up in toggle mode (if I've interpreted this correctly) then this would halve again C-Bus traffic. The key here I think is to select an appropriate resolution device for the anticipated load to avoid excessive C-Bus traffic. Mine are rated at 32A/240V (which matches our ring main capacity fusing here in the UK) so could max at just over 2 pulses per sec if fully loaded, but they're nowhere near that.

One thing re the Wiser dial display... You setup your pulse meters in PICED with a max value - and it would be nice if that figure was carried though onto the meter displays .. at the moment I believe they just always display a 0-10 value and as mine vary 0-1.5 typically the movement is very small and not visually very helpful.

Having a C-Bus coupler or Aux input unit with 4 inbuilt 32 bit counters would be really nice ;-)

K

Although the coupler samples at this rate it will only send a C-Bus message if the input has changed state - which mostly it hasn't. The important thing is the number of pulses from the pulse meter not the sampling rate. The sampling rate only has to be faster than the marker pulse width so with a 20mS marker pulse then a 16mS sampling is ideal. If the sampling rate is slower than the marker pulse then there is a slight possibility that between samples a pulse came and went but was not seen (sampled). When 16ms is quoted I assume that is per channel so each of the four channels is sampled every 16ms so a state change on one can't create a missed pulse on another. I assume any required outgoing C-Bus activity doesn't impact this sampling rate.

 

Spot on, KevinH.

 

Using a bus coupler to react to 20ms pulses should be safe enough; the 16ms limitation Newman mentions is the rate at which the inputs are tested for changes. If debounce time is set to 16ms (minimum), then the first time the input changes, a command can be issued on the bus. C-Bus communication rate allows for approximately one complete message of this type every 22ms, but on a busy network, the messages must be queued until the network is free. There is no hard and fast limit here, but I would think two pulses per second would be about the highest pulse rate that I would be comfortable with on a moderately loaded C-Bus network.

A toggle function is a good choice as it results in only a single short message (alternating on / off) for each pulse. An alternative would be a recall function, which would also always be just one message for each pulse, and might be easier to handle on whatever is processing the commands.

If a second bus coupler were added with a similar pulse rate, the bus loading would increase in proportion, but if multiple channels were fed into the same bus coupler, every time the bus coupler saw pulses from multiple channels at the same time, it would format the messages to make better use of the bandwidth by concatenating group commands into the same message.

 

OK - I've been playing a while now with energy monitoring on both a Wiser and Colour Touch. My two pulse meters , attached to two inputs of a coupler, provide pulses about every 5 seconds but at peak could I think generate about 4 pulses per second. Output is 1Whr pulses and pulse width is 50ms. The new inbuilt realtime energy consumption algorithms I believe are working fairly well. What I wanted however was to be able to display accumulated usage and cost, and also an electronic meter reading with a next bill estimate.

So I added a code module that incremented a couple of counters, one for each of the two groups involved and I synchronised the counter values with that displayed on the KWhr meters. However over a period of time they seem to lose count and as the pulse width is well within spec I'm suspecting the code module. As the code has to loop and test rather than being event driven , I'm thinking at peak KWhr consumption the loop processing isn't fast enough. This is likely exacerbated by the realtime KWHr usage processing the Colour touch has to undertake.

So I was thinking ...

Rather than having to create anpther code module to poll and count group changes wouldn't it be far more efficient if the existing inbuilt smarts of the realtime KWHr algorithm also maintained an internal pulse count as a system I/O variable ? Then after setting/resetting this varaiable all you have to do is read it periodically as desired to build your consumption figures.

Additionally , although less beneficial here , the Wiser is also calculating realtime consumption - wouldn't it be nicer if only one piece of hardware had to do this and the value, and pulse count, was presented on the C-Bus measurement app rather than being independently calculated by each unit ? This would preserve touch screen processing resources. I haven't played with the measurement app much but I think it can operate in a request , rather than broadcast mode which would avoid excess C-Bus traffic.

I know I could add some prescaling to the output of the KWHr meters to reduce the pulse frequency but I already have a lot of these meters wired in on each fused circuit and would like to utilise them if possible, plus trying to avoid home build I haven't found any neat hardware to do this.

K

 

The processing for energy monitoring is very minor.

We are already considering this.

This would increase the amount of C-Bus traffic, but hardly save any processing.