Hi,
Does PnPSCADA support 'Events' for water meters? e.g. can we send a message to the system when there is a continuous flow for a preset length of time. Can the system then send an SMS or email message to a designated person who should investigate this further? This is important for our clients, as in many cases we are monitoring bulk meter supplies, where timeous notification can prevent excessive water loss and flooding. On residential lines, tenants may be away overseas, and this type of notification can flag someone to investigate before they run up a massive water bill!
Thanks,
Chris | Applied Metering Innovation

The events supported are different for different meters. For example, the Wavenis WaveFlow modules support a number of events, e.g. pipe burst, trickle, wire cut and battery low.
Yes, we support email and SMS on events. The way it is setup is as follows:

1. Set up these events under 'Edit->Meter Event Setup' to generate notifications, or not, on a per event, per meter basis.
   
2. Under Role Notifications or Login Notifications, the appropriate notifications needs to be enabled for a Role/User, in order for that user to receive the notifications. This is also where you set up whether you want email/sms notification. Here (under Role Notifications) you can also set up your deadbands, and maximum number of messages per day, and the time of day during which you are available, so that you are not spammed. Events are aggregated into one email/sms whenever possible.
   
3. If you want to enable SMS, you need to create an account under CommunitySMS (www.CommunitySMS.com); and specify your account login details under Role Notifications.
   

So must I first go and check these tick-boxes for each WaveFlow device, using WavenetExplorer, and upload the edited .prp file to the system?
When one of the specified events occurs, is this notification 'pushed' to PnPSCADA, regardless of when the next read of Totals and Events is scheduled to take place?

What needs to be done in WavenetExplorer, is for the alarms to be set up, per meter, including the route back to the WavePort on the modem/etherpad (you need the radio address of the WavePort for this to work). You don't need to upload the .prp for that: the settings are stored in the MIUs, that is what is important.
When one of the specified Wavenis events occurs, it is pushed to the WavePort. For PnPSCADA to pick it up, you must edit the WavePort entity on PnPSCADA and enable it to check for alarms every 'x' period, e.g. every 5 minutes. This will then 'poll' the waveport at the set interval, without causing any RF emitting from the WavePort, which means it should not affect your batteries on the MIUs.
The latest alarm is kept in the WavePort for some time, until you acknowledge it. If the WavePort should lose power, it will forget the alarm that was sent. If the alarm is not acknowledged, it will retry sending it from the MIU at increasing intervals about for about 4 or 5 times, if I remember correctly.

When I look at my WavePort entity on PnPSCADA, there doesn't seem to be an option or link (under Edit ) where I can edit the settings and enable it to check for alarms. How do I go about setting this up?

Ok, please ignore my last question. I see the option to edit the WavePort is under the Tools menu - not the Edit menu. Thanks, I'll be able to proceed from here.

When I look at the 'Role Notifications' or 'Login Notifications' screen, I don't see any tick-boxes that seem to relate to Wavenis events - see image below. Which tick-boxes should I select to get the alarms e.g. trickle-flow, burst, wire-cut, etc. sent to me?

When I look at the 'Role Notifications' or 'Login Notifications' screen, I don't see any tick-boxes that seem to relate to enabling for Wavenis events / alarms - see image below. What should I select to get these sent to me? e.g. trickle-flow, burst, wire-cut, etc.

That is correct. This issue has now been fixed.
We've also made changes to how automatic events are sensed: it is necessary to connect your waveport to pnpscada using an Always Connected Etherpad or Always Connected GPRS modem.
The way the leak events are set up, are through 3 parameters:
The first parameter is set up the same for all the meters connected to the MIU. It is the check period, in minutes. (it counts from midnight)
The second and third parameters are set up per meter:
The second parameter is the threshold. This is the number of pulses ABOVE which the MIU must measure on that input channel to trigger the alarm. This will be counted up over the period set up above (the MIU has a real time clock, so if it is set up per hour, you can expect your event evaluations to happen exactly at the hour).
The third parameter is the one that allows for a sliding window: it is the number of period, as set up in the first parameter, that must be ABOVE the threshold as set up in the second parameter, before an alarm is triggered.
So, if you want to test your alarms, and your period is set to 60 or some other large number, it will take a really long time to see if it works. And if you set it to 1 minute, for example, but your threshold is set to e.g. 1, then it will typically also not happen easily, since you'd probably not get more than 1 pulse per minute, unless the meter is going fast. You CAN set the threshold to 0, which will then mean that an alarm will be generated for every minute that you get at least one pulse, which is quite often true. Just remember to set it back to something reasonable again, so that your battery doesn't get flat too quickly.
Residual leak and burst pipe are both calculated in the same way, although it is two different alarms you can set up per meter. Usually the threshold on burst pipe will be larger and the third parameter smaller.
Some things worth mentioning is that you should only enable the alarming once your parameters has been set up correctly, otherwise the MIU might ignore your settings. It basically loads/starts/resets the algorithm when you set the alarm bit on.
Another thing worth mentioning is that the route to your waveport could get automatically set when the alarm bit is set, to point to the waveport through which you set it, so you should not do this from your mobile waveport connected to your laptop if you can help it, but from the waveport that connects back to Plug and Play Scada. Or if you do use your laptop to set this, you must go and set the route up again afterwards to point to the correct waveport.

http://sdg.pnpscada.com/wiki/waveflow/waveflow%20alarms.html

A few questions:
1. When setting up the MIU in WavenetExplorer, must we first read in the meter pulse constants before setting up the sample periods and thresholds?
2. Is it still necessary to edit the Waveport first, to check for alarms every 'x' minutes?
3. In 'Edit->Advanced Meter Settingings' must we select the Events tick-box (Sets to be read) for alarming to work?
4. I see it is possible to do an 'Edit->Meter Event Setup' on either the MIU or the Meter itself. Must the tickboxes be specifically checked for the MIU, and not for the Meter? Or must it be done for both?
Thanks.

Yes for one.
No for two. The new requirement is that it must be connected through an 'Always Connected' communications entity.
No for three. One could argue for the belt and braces approach, in which case the answer would be yes, but then one might not realize when your real time alarm update alarms are not working, so I'd go for no on this one.
It should be for the Meter itself on number 4.

One of the Wavenis events we can check for is 'Battery Failure'. Using WavenetExplorer, I see we can enable to check for this condition for MIUs, but not for Repeaters - we can tick the check-box, but the 'write to meter' option is greyed out. With the workload they handle, it's conceivable that the battery on a Repeater may go flat before those on any of the MIUs linked to it, so it would be useful to be able to check for this alarm condition. Is it possible to enable this option?

I'm not at all sure that it is physically possible to have alarms that send updates dynamically from the Repeaters, since the alarm functionality is in documentation specific to the WaveFlow unit.
However, it is possible to read the battery level from Repeaters. This can also form part of an instrumentation profile. So it makes sense to read this from every repeater mayble once a month, so you can see how the battery diminishes over time.
Another feature of the WaveFlow is also to act as a repeater. So, unless you need special long range repeaters, you can actually use WaveFlows as your repeaters. I believe the price is comparable? In that case, of course, you should be able to set battery failure events on the unit that you use as a 'repeater'. (I'm not sure that the WavenetExplorer will allow this in software, but it should be possible on the physical hardware & firmware)
What Elster in England does, is they install 2 repeaters every time they install a repeater station, so that when the one gets flat, they switch over to the other one manually but remotely, giving them time to go and replace the flat repeater when they get a chance.

One of the Wavenis events we can check for is 'Battery Failure'. Using WavenetExplorer, I see we can enable to check for this condition for MIUs, but not for Repeaters - we can tick the check-box, but the 'write to meter' option is greyed out. With the workload they handle, it's conceivable that the battery on a Repeater may go flat before those on any of the MIUs linked to it, so it would be useful to be able to check for this alarm condition. Is it possible to enable this option?