Success sending ZW "smart" energy data to SEG but kWh issue

[ccclapp]

As stated above we can now send zwave/insteon "smart plug" and other energy reporting device info to the SEG (Smart Energy Groups) excellent energy monitoring/reporting web platform from ISY.  This is 1-year effort is described in this thread...

 

http://forum.universal-devices.com/topic/12682-energy-monitoring-circuits-plugs-interface/?p=167740 

 

The z-wave devices report current power (watts) and energy (kWh).  There is no issue with the power (w) stream.  HOWEVER, I belive the kwh is reported as total to date, meaning total usage to date is send in every update, vs just the small incremental delta that is sent from a GEM/Dash and some other controllers/monitors.

 

My question is: how to deal with this for SEG.  I would think there are two basic approaches:

1) Somehow use SEG settings to deal with the repetitive total kwh being sent (but how and what settings?)

2) Only send current power (W) data and have SEG translate that into kwh data.  This could possibly be via a single stream or by sending a duplicate stream of the W data with an E in the transmission packet.  Again there would likely be SEG configuration settings I don't fully understand.  

I started a thread on the SEG forum on this question and received the following reply from Sam, its founder:

 

 

Hi,

There is no specific setting in SEG for this.  Both kinds of functionality were prototyped a long time ago, and found to have issues, particuarly converting W in to Wh as this is dependent on a time period - for which this is not reliably known between data points and the device can go offline, causing havoc in the calculations!

For subtractive processing, there are other problems as well.

The best advice is to calculate the subtraction on site before sending this data to SEG, that way you are in control of the subtraction processing and getting this right.

Hope this helps!

Sam, @samotage

 

 

Does anyone have guidance on trying to do calculations to the Zwave data prior to sending, or other ideas?

 

Thanks

[Teken]

I would think one of the really smart guys could offer some math to be completed by the 994 Series Controller? Meaning what I see happening is there will be a few variable programs doing the following in no specific order.

 

(I am great for thinking up random sh^t but sometimes don't know how to accomplish the same)

 

This is where the really smart guys that come here and show us how.

 

1. One variable would track the current KWH per hour.

2. The next variable would continue to add those values for a entire days KWH reading.

3. At midnight the next variable would fire off a single value to SEG so the daily total is shown.

 

In my mind this reduces network traffic and tying up the controller plus it would allow you to edit out any unknown issues not found in the existing code.

 

That is how my idea would work now one of the really smart people need to come up with the variable construct to glue all three together.

 

After typing out the 3 points I am thinking some of these elements already exist in my other programs but would need to play around with them to confirm.

 

That's my $0.0000000000000000000

[ccclapp]

At a minimum you should add a .02 in front of all those zeros. Yes i think that is the concept, however doing everything Via variables on the isy gets old fast. In the end i expect this ( and other isy to other i/o solutions) will require intermediaries like isylogger/nodelink or isyhelper etc, basically meaning a RPi with a good "plugin". Alternatively ( as another option but likely mot better) would be the external graphing/import/export via google docs/sheets ( whatever its called) similar to what you recently ( this morning) Related in your "novel"

 

Good thoughts

 

Thanks

[Teken]

At a minimum you should add a .02 in front of all those zeros. Yes i think that is the concept, however doing everything Via variables on the isy gets old fast. In the end i expect this ( and other isy to other i/o solutions) will require intermediaries like isylogger/nodelink or isyhelper etc, basically meaning a RPi with a good "plugin". Alternatively ( as another option but likely mot better) would be the external graphing/import/export via google docs/sheets ( whatever its called) similar to what you recently ( this morning) Related in your "novel"

 

Good thoughts

 

Thanks

 

I was under the impression you wanted to do this internally with the ISY only? If not and you're considering other intermediary's like RPi / wet wear.

 

The world is your oyster  . . .

 

I agree trying to do this via internal variables is quite time consuming and has performance draw backs. I know this first hand so do caution anyone trying to do the same on a very large scale. In my set up there are hundreds of variables running and not surprisingly has impacted my system.

 

But like I said above if the intent is to try to do the above via the ISY in the (interim) that would be a closer solution. As you're probably aware you and I have been very patient in trying to get many elements to mesh and work on various projects.

 

At least using the ISY you have a proven membership who are eager to use what they know with respect to the ISY. With anything outside of that it falls on you or at least having the capability to convince others to help you craft something on a open platform like the RPi.

 

Just my $0.000000000000000000000000002

 

Ha . . . 

[ccclapp]

...Does anyone have guidance on trying to do calculations to the Zwave data prior to sending, or other ideas?

 

The link below is the description of my solution, in concept...

 

http://forum.universal-devices.com/topic/12682-energy-monitoring-circuits-plugs-interface/?p=167885