This message was trancribed from an email.
Does PUSH protocol on the IP Telemetry (IPT) work, on the SyM2 meters, with PNPSCADA, and if so, how do I get it going on PNPSCADA?

Yes, SyM? meters do work with PNPSCADA. IP Telemetry also does work on PNPSCADA. And SyM? Push over IPT does also work on PNPSCADA.
SyM? meters can also work over CSD (the underlaying protocol is called SML); but the PUSH functionality only functions over IPT as far as we are aware, currently. It was the only option on the meter configurator tool for push.
We currently read 4 modems with IPT, two of them being the Landis & Gyr SyM? related communication modules - one of them GPRS (ZDUE-GPRS-SyM?) and the other one TCP (LAN CM-E1E01) - the third module being the Itron (previously Actaris) Sparklet modem that is based on the Siemens (now Cinterion) TC65 module with a special embedded Java program, and the last one being a new Landis & Gyr modem that fits as a communication module into ZMD meters (not sure what its model number is yet, and it seems the current version still has some buffer overflow problems).
One of the special feature of the SyM? meters is that they can 'push' data through IPT. To do this, they open one or more new 'push channels' on the underlying IPT, and send the data through there. (IPT is an 'always connected' active protocol, where the client connects to the server, with watchdogs being sent through at intervals. It stays connected, similar to the various types of Active GPRS modems supported on PNPSCADA. IPT is very popular in Germany)
It is possible to mess up your configuration to such an extent that the amount of data it tries to push through exceeds the physical limitations of the connection, so you have to be careful. The SML protocol as implemented on the SyM? meter has another great feature that involves the digital signing of regular profile period readings (the profile readings are energy totals, not consumptive figures); but that does make the protocol BIG. So it is not as difficult as you might imagine to overload the push with a wrong setting. Our advice: Make sure you get your settings working properly with PNPSCADA on a meter in the lab before you roll out a new configuration to site.
Over here we'll give you some examples of what works for us, and what doesn't work for us.
Some preliminary findings, was that the Push interval should not be something small like 1 second. Something more realistic is 300 seconds. The Push-Delay we set to 60 seconds, that worked for us, for 'Addressed Registers', which sends through phasor values.
For 'Auto Load Profil', which sends the profile through, we generally specify a Push-Interval of 15 minutes (900 seconds); which is the profile period, and that seemed to come through very nicely.
One note: make sure that your physical pipe is big enough to handle the push traffic if all your meters send at the same time.
You should be able to stagger the push times with setting different Push-Delay settings, but we haven't had the opportunity to test that yet on really large amounts of meters, so do your own tests and share with us here.
Nevertheless, even if you stagger it, it is very important that you monitor your link saturation levels, so that you can anticipate when you should get a bigger pipe to e.g. your cell phone company/-ies.
Another note, is that you must make sure the NTP is working properly on your meters, otherwise your profile wouldn't work properly, since the meter starts counting seconds from when it is switched on the first time, and in that sense doesn't keep any other internal clock. The internal clock used for profile offset is part of a different functionality or module in SyM?, and that is time stamped with the seconds after switch-on for every profile period, but it needs to sync with NTP to work properly, so your quarter hour offsets are accurate. So your NTP setting is very important. For a clearer understanding of this issue, please refer to your meter documentation.

After some experimentation it seems to bring voltages and currents and angles through if I select to push 'Addressed Registers', and specifically one called 'Actual operation values'

Here is a sample of how to set up the near-instantaneous profile update (every 15 minutes)

It sometimes happen when a meter has not called in for a long time or when you have played with the push settings and possibly messed it up for a bit, that the meter attempts to send back this huge buffer under normal communication circumstances (when trying to read in the meter). And then in subsequent communication sessions, the channel is all clogged up and you can't communicate effectively. To restart the meter sorts this out, otherwise I think there is a timeout for that, but of course I can't check that very quickly.
So if that happens, the reply doesn't finish: to see if the reply is well ordered, it has to be an SML file, and the SML file has 1B 1B 1B 1B 01 01 01 01 at the front, and something like 1B 1B 1B 1B 1A 03 BE 4C at the back (note the second last 4 bytes are all 1B - the last 4 bytes are a checksum and would be different)
So what happens is that the big packet gets stuck in the throat, and next time when we open the channel, this stuff comes pouring out, but for some reason it stops, so when we time out after 35 seconds we ask for new data anyway (and that sometimes work) and then more often than not we get another bit of the large packet coming back and it stops again.
(sometimes the messages flies thick and fast and the display on the comms monitor does not stop exactly at the 1B 1B 1B 1B XX XX XX XX, because the reply to the next message has already arrived before the comms monitor could switch between rx and tx, but you shouldn't have this problem on GPRS)
I'm not 100% sure whether that behavior is related to wrong push settings or not. However, if you have such a problem, the quick way I found to sort this out, is to read the meter up to date, or manually edit the read in up to time to lets say midnight morning of the current day, and to restart the meter (switch off, switch on). I realize both of those conditions are not ideal under real conditions - you should be able to do it under lab conditions. So my advice would be, once you have found the ideal meter setup under lab conditions, then program your meters like that before you send them out.

Packets should be small. That is why we always ask for only half a day of profile at a time. Nevertheless, I'll cast the net a little wider to find out if there is a way to reset the channel or to get the large chunk of data out of the comms channel throat in some other way. In the mean time, if you encounter that problem, set your maxdate recent and restart your meter!

Another note: If the push arrives and there is a gap in the profile, it ignores the push and schedule a normal read for the meter to get it up to date. So to really check if it is working by watching the profile like a hawk (I can see you!); you have to be reasonable, seriously, and therefore first check that your meter has been called in to date to the last 15 minute interval (before you complain and say that it doesn't work)

There has been some problems when I moved to the GPRS module.
Basically, the push arrives in the form of an incomplete packet that is sent in numerous push packets, of which the first 5 arrives, and then it seizes up: it stops sending. And the link light on the meter goes off.
So, what I did to fix that, is to disable push completely om the meter, to get a reliable link re-established.
Then, after reading in in reliably for about 2 hours, I read it in up to date, and then set the push back on, as per the above settings (900 seconds); and it worked.
I now have a SyM2 meter here, with push happening every 15 minutes over GPRS!!
It seems therefore that one way to 'reset' the push is to first of all switch it off, then let the meter connect, and the Link light should be on, and read it in up to date, and then reprogram it with Push, stating 900 seconds from the start. Do NOT program it on 60 seconds and then change it later to 900 seconds. Program it with 900 seconds from the very first.
That seems to work.
What happened previously is that the meter tries to 'push' a large packet, and then it would send 5 packets (which is not all the packets) and seize up.
The Link light would also love going off - now it is on all the time, and the push is happening reliably.

Another problem that currently happens on Public GPRS, is that the watchdog from the meter only happens every 5 minutes, which is too long for the IP Masquerading firewall. The IP Masquerading firewall return path closes after about 1 minute. Therefore, for 4 minutes out of the 5, you would not be able to read the meter, even though it is connected over TCP/IP. You should not have this problem over an APN, I think!