Summing multiple inputs


I just recently purchased and installed this amazing system. I have solar generation plus power from the utility. I have installed an emontx with four CTs. Two go to the solar connections and two go to the utility supply. BTW I am in the USA so US rules apply here. I have been trying to combine power1 and power2 to get the sum of the two for my PGE supply. I also want to combine power3 and power4 for solar generation. Yet no matter what I try I always end up with a total that is not the sum of the two values but actually only ends up being the value of one of the data points. For instance if I try to add Power1 and Power2 and log it to use, the reported value for use usually equals Power1. IE 480 + 600 = 480 and not 1080 as expected. What is the trick to getting these to sum properly into the feed called use?

Thanks in advance for any help.

What are you actually doing and where? You haven’t said so I’m reduced to guessing.
On the Inputs page, you need to do “+ input” before you “Log to feed”. Are you doing that? Is scaling correct for both inputs? (i.e. You’re not multiplying just one by 0.01, then both by 0.01 so that one effectively disappears?)

Alternatively, if you are able to edit and reload the sketch in your emonTx, you can do the maths in there, and send the combined value to emonCMS.

Thank you for the fast reply… I actually had tried something like that… I have a +input of power2 in the 1st position which I assumed would add the value to power1 and then I have a few log feeds but they all show the power1 value only. I plan to clean all of this up once I figure out what I am doing wrong here. If need be I can edit the sketch but I would prefer to manipulate the data here and leave the raw per branch numbers alone if possible.

the trick is to use the functions in the correct order (from top to bottom) and at the end save the result in a new log to feed with another name.
Here is part of a feed I made to exclude false power generation by my solar panel system (below 10W isn’t production in my case)

as you can see I say to reset the value to zero as long it is below in my case 10 and exclude negative values and FINALLY log to feed solar_corrected

hope this is what you need to solve your problem

I thought that was the problem, but try as I might with all the similar names that I can think of, I cannot reproduce your problem. In every case, ‘the system’ has beaten me and produced the correct result.


Node:	Key Name	Process list	last updated	value			
0       power1		+ inp log	3 mins ago	220			
0       power2		+ inp log	3 mins ago	310			

Input Power 1 processing:

Order	Process	        Arg		        Actions
1	+ input	        Node 0: power2	        (inputvalue:310.00)	
2	Log to feed	Node:0: Node 0:power1	(feedvalue:530.00)	

However, I advise you NOT to have the same name for both Input and Feed.
It says “Input processes are executed sequentially with the result being passed back for further processing by the next processor in the input processing list.” but there are exceptions to that. I think there’s a post in the old forum listing those.
“passed back” means passed downwards to the next process below in the list.

When adding a +input to combine with power1 you only need to do a +input of power2 and it adds it to the infered value of power1 correct?

Eric was illustrating the process for a slightly more complicated problem.

You start off with the feed input value (in concept) above the first process in the list. The first process accepts that as the default input, does what it must to it, and passes the result down to the second process in the list, and so on. In the example I did to replicate what you’re attempting, that initial value was 220. “+ input” fetched and added “Node 0: power2” to it, the result (530) was passed down to process 2 “Log to feed”. This sent it to the feed that I originally called “sumP” (but above it’s confusingly called “Node:0: Node 0:power1”) and passes it down to the next, but here non-existent, process.

This is what I originally had:

Node0: power1 config

Input processes are executed sequentially with the result being passed back for further processing by the next processor in the input processing list.

Order	Process	        Arg		Actions
1	+ input	        Node 0: power2	(inputvalue:310.00)	
2	Log to feed	sumP	        (feedvalue:530.00)

Are you looking at the Feeds page to see what is actually arriving there?

Not to throw a rag in the gears, (or spanner/wrench if you will. The rag is an old mechanics trick) but here’s a post where PB66 recommends using +feed over +input and his reasoning for doing so: Logging import/export separately (from one input) | Archived Forum

There are a number of things it could be, there is quite a lot of info missing to determine what it is exactly.

But I’m guessing the data is coming via an emonPi or an emonBase running the emonPi image as the nodes and inputs are named not numbered, is that correct? or are you posting to emonCMS via a homebrew script?

If you are using the emonSD the issue is most probably the use of mqtt, you have no control over which inputs update in what order, each input is independent and therefore the inputs could even be updating simultaneously.

Also we cannot see what feed types you have there, if they are fixed interval then it really doesn’t matter what updates when in between intervals as the feed will only record a snapshot at the interval.

Can you post a screen dump of your feed list?

The advice @bidouilleur has shared is good advice but a bit off topic for the basic issue here, the reason he’s using a “different name” is because he has a “log to feed” at the start and another at the end, therefore yes they must be different for the purpose of identifying them, but in actual fact it’s only doesn’t support reusing the same names, in a self hosted emoncms you could in theory name every single feed “feed”, I cannot imaging why anyone would and it would be a nightmare if they did but emoncme will allow it and function perfectly well.

I’m not aware of any reason to not name feeds the same as inputs, but maybe @Robert.Wall has experienced something I haven’t. I actually make a point of always using a “log to feed” at the start of a processlist to record the raw values and I usually name them the same as the input they mirror.

IMO better advice is to not use spaces or special characters, I use only alphanumeric chars, underscores and dashes. I have seen some bizarre things happen with other characters and emoncms often removes spaces too.

Robert’s example is exactly how easy it should be [quote=“Robert.Wall, post:5, topic:1373”]

Node: Key Name Process list last updated value
0 power1 + inp log 3 mins ago 220
0 power2 + inp log 3 mins ago 310

Input Power 1 processing:

Order Process Arg Actions
1 + input Node 0: power2 (inputvalue:310.00)
2 Log to feed Node:0: Node 0:power1 (feedvalue:530.00)

However if you are posting the data as a packet of value in a fixed order (eg csv), the inputs are processed in order starting with 1 then 2 etc, as long as you put you “input1+input2” in the processlist of input 2 not 1 it cannot go wrong (famous last words), if it’s in input1 processlist input2 will not have been updated yet so you will use the old value.

With any other method JSON named inputs or individual MQTT topics you have no guarantees and you probably will not easily spot this type of issue as the screen you are watching is not always upto date info, eg the inputs page refreshes every 10 secs and the processlist screen (I believe) only displays fixed value of when opened.

This is the reason the emonPi has a “power1pluspower2” input because it has to be done in the sketch to be reliable unless you revert to posting orderly packets of data.

The use of feeds over inputs was good advice but the main reason for doing that was if you delete inputs when they are referenced in another inputs processing you would lose that other inputs processlist and have to delete it, it is not as easy to accidentally delete an input now so it’s less of an issue but still good advice IF you are not referencing a fixed interval feed as it will always use the feeds last value which could be stale, as it is not updated in between intervals, so it isn’t good “blanket advice” and whilst it is still my preferred method I have learn’t fixed interval feeds do not work as expected.

Do you have a account? try also sending the date there at the same time, you may spot the difference.

Thank you all for the input. After a bit of experimentation I figured out the error of my ways and understanding. One issue was for some reason I was expecting the value on the inputs page to be effected. But after a bit more study I discovered it won’t be and will always be the root value of the input and I needed to use the feeds page to verify the proper values. Also I needed to adjust the orders of the steps. Once I figured out what I was doing wrong I got it to work. I have two days of accurate data now. Now I need to figure out how to add the eagle data to it.