questions on push v2

[paul99]

Hi fellow Santa Cruzan

Your system seems ideal for my monitoring needs, but I do have a couple questions about the push system.

I have some rural rentals, that use a local wireless ISP (Surfnet) that has monthly bandwidth caps. So I am very concerned about total bandwidth usage, and if there is a way to throttle it, knowing that updates would not then be real-time, but maybe updated each 8 or 12 hours. Also might be nice to block certain hours, like evenings when Netflix is popular with my tenants and the neighbors who effectively share the same total bandwidth over that wireless link. I would not want to interfere with streaming, which is probably pretty delicate on these bandwidth limited links already.

Possibly a bigger issue is that Surfnet does not allow incoming TCP connections (e.g. no servers at the rental location). By the name, the "push" system would seem to establish its own outgoing data connections to your servers, and would not be polled by your cloud system. Is that correct?

Of course, I fail to see how the OmniMeter relay outputs would be remotely controlled in this case, but I can live without that feature.

Looking forward to learning more....

thanks,

paul

[Jameson]

A local!! We have a surprisingly large Santa Cruz EKM Meter user contingent these days (surprising in that we sell meters all over the world). We should start some sort of a club

We have designed the EKM Push system to be extremely data efficient. Each read is about 200 bytes (0.2 kB) to transfer the meter data. You could read your meters slower if you want to transfer less of this type of data

Then there is a 300 bytes per minute transfer that is just the EKM Push gateway checking in with the database. This is currently fixed at once a minute.

For a once a minute meter this comes to about 0.72 MB per day. This is a very small amount of data. It would take 4 or 5 days to move the equivalent data to downloading one song. A Netflix movie burns through .72 MB in a matter of seconds. So I cant imagine you would even notice it.

We use UDP to send data to the database, this is much more efficient than using TCP to transfer data.

The EKM Push will work quite well on your Surfnet service, you are correct that it Pushes data out to our servers, so you dont have to mess with any of your incoming ports.

Of course, I fail to see how the OmniMeter relay outputs would be remotely controlled in this case, but I can live without that feature.

We do not offer the ability to make meter settings via the Push system yet anyway. But if we did (someday), this would also work.

Thanks,

[paul99]

Hi Jameson -

I'd be glad to join your club! I'm ready to order the first system, for testing.

I need to monitor two 220v circuits, and at least one water meter, via the pulse input. So it seems that I want one EKM Omnimeter Pulse v.4, and then one EKM-OmniMeter I v.3 for the 2nd 220v circuit. Can they be mixed on the same system OK?

Of course, also one EKM Push Pro, and the 4 Current Transformers.

Can I do will call, and drop by to pick these up later in the week? (I'm < 1/2 mile from your office location)

I have a 2nd site where I need to measure two water meters only, no power, do I still need EKM Omnimeter Pulse v.4, or is there a pulse-counter only device that will work with the Push?

[Jameson]

Sounds like you have what you need pretty well sorted out. I would consider how you are going to mount the v.4 meters (either DIN rail in your own enclosure, or our water-tight or indoor enclosure kits) and I would go for the 1 amp fuse holders.

Yes, you can have both a v.4 meter and a v.3 meter connected to the same Push system. With what you have proposed you would get the data from 2 electrical systems and 1 water meter. For the second site you would need to get 1 Omnimeter Pulse v.4, 2 water meters, and 1 EKM Push. We will set it up so that the data from the 2 Push systems goes to your same Push account.

And yes, come on by, we are here during business hours at:

EKM Metering Inc.
122 Benito Ave
Santa Cruz, CA
95062

Thanks and see you soon.

[paul99]

The system is installed, and is working great! I really appreciate all your open API's and excellent documentation.

However, I'm having an issue getting the "Pulse Input State" value over the API.

I have the two meters, and I have an input on Pulse Counter 1 of the v4 meter, which is not a pulse in my case, just a level I need to check (actually it's the control signal to start the well I am monitoring). I see this value clearly in the EKM Dash software data, it transitions when expected.

However, I cannot read the value at all in the API, I set up using the API Maker tool on your site (or from just reading the docs).

So here are 3 URLs for your example meter that the API Maker tool defaults to:
http://io.ekmpush.com/readMeter/v4/mete ... te_Inputs/
http://io.ekmpush.com/readMeter/v4/mete ... te_Inputs/
http://io.ekmpush.com/readMeter/v4/mete ... te_Inputs/

The first two work on your example meter, and return a sensible value, json for example: "State_Inputs":"4"

But the CSV (3rd URL) does NOT return the state inputs, you can see it is not in header or the data.:
Meter,Date,Time,Time_Stamp_UTC_ms,RMS_Volts_Ln_1,Amps_Ln_1,RMS_Watts_Ln_1
300000369,04/09/2015,22:43:28,1428619408618,122.8,5.0,612

Now VERY weirdly, if I substitute my API key, and my meter number, then NONE of the 3 URLS will get the input state.

I will send the 3 edited URL's by private mail for your convenience. Thanks in advance for your help on this!

paul

[Jameson]

Oooh nasty! Thanks for sending us this. It certainly looks like a bug. "Pulse Input States" are not reported in .csv files.

We will get right on it and let you know when it is cleared up.

It looks like html, xml, and json are all working fine. It is a bit of a pain but I can show you how to convert .xml files to .csv if you are interested.

Thanks again for the heads up!

[paul99]

Hi Jameson - thanks for quick reply! As mentioned above, when I read my own meter, I don't get Input States in _any_ of the formats, html, json, xml, etc. I sent you links with my meter urls by private email.

[Jameson]

It is possible to have an Input State that is reported as "0". In our API, if the data is not there, you can assume the value that is returned is "0"

Here is the map of the possible "Pulse Input State" values for the 3 inputs:

Pulse Input State High/Low
High/High/High = 0
High/High/Low = 1
High/Low/High = 2
High Low/Low = 3
Low/High/High = 4
Low/High/Low = 5
Low/Low/High = 6
Low/Low/Low = 7

[paul99]

Right, so the one input I am using is open circuit most of the time, when not-active, and shorted to ground via relay contact when active. So all inputs are internally pulled-up by meter, and that is a 0 state for you, and no data comes back. I'll verify that I get valid Input_State when the well goes active. I can certainly work with this if it is deterministic.

I was thrown off by the CSV, where even the headers are not there. Actually for the CSV data, that's a problem if you do not have a consistent number of columns. I will just use json or xml for now.