Why not put a dial widget for that?
1 Like
I tried both methods, but the combined tally doesn’t quite agree with the constituents. Perhaps it is a timing or rounding issue?
For example, if I do Log Input A to Feed (27.00) then + feed Input B (140.00) then + feed Input C (12.00) then Log to Feed and give it a new name, the Feed “result” is 173.00 - ie 6 out.
A similar thing happened in the RTZ attempt, Log to feed Input X (216.00) then RTZ then + feed Input X (216.00) then + feed Input Y (43.00) then + feed Input Z (-1193.00) then Log to Feed & give it a new name, the Feed “result” is -1177.00 - ie 243 out.
In both examples above I obtained the values given from clicking on the spanner icon next to the process list in the Inputs page.
I noticed the same thing. What I saw was the number in the new feed lagged the
correct value by one update interval.
There is a timing issue - but I don’t know the exact details of how or when it comes into play. The essence is, the input processing happens when the input arrives, and the values used are those at that instant. Paul B always suggests using +feed in preference to +input.
Seems to have changed. Now it’s off by 1 to 5 Watts.
Doesn’t seem to matter whether I use + Input or + Feed.
Are these particular values you are trying sum from different devices or a single device Julian?
If they are from 2 devices, try editing the emonhub config (via your local emoncms) to change the emoncms http interfacer send interval to something lower eg 10s (it is 30s by default).
What maybe happening (and this is just one possibility) is that the emonpi data is arriving in 30s batches whilst the emonESP/emonTx data is arriving at 10s intervals so (for example) when each of the batched values is processed it will use the same latest emonTx value for all of the past 30s updates OR when the emonTx updates it maybe using 30s old emonPi data because the batched data hasn’t arrived yet. Setting this to 10s (or less) should allow the updated inputs to process at a more regular “in tune” pace.
I can see that’s gonna stick with me forever!
There used to be a absolute reason for using +feed over +input many, many moons ago. The issue was that it was possible to delete an input without confirmation, even when it was being used in another inputs process list. The result of deleting such an input corrupted the processlist it was cited in to the degree that it couldn’t be fixed and couldn’t be deleted, so all input processing in that now corrupt input after the hole where the deleted input used to reside, no longer worked.
In emoncms v8.5 to v9’ish somewhere the inputs where changed so that you couldn’t delete an input so easily, and the way the input processlists were used was changed so that if a cited input was deleted, the processlist would just show “Error” and be totally accessible to edit and fix (ie remove any ref to deleted inputs). So that particular reason for always insisting on using +feeds has long passed.
BUT as emoncms evolves new quirks and habits form, so there are still instances where one might prevail over the other, but both the +input and +feeds have their pro’s and con’s, it is no longer such a clear choice.
The only real “obvious” time to use a +feed over a +input is when working with results, ie there is no input of the same value as the feed eg working with energy when all the inputs are powers.
The rules for choosing between them get more blurred when you are looking at “cross-device” processing and using the low-write version of emoncms as used on the emonSD (and possibly with phpfina feeds in general?).
Any cross device issues might be more obvious, you are dependent on when the values land (as well as any included timestamps) as to how the input processing order plays out. With the values being passed between emonHub and emoncms via MQTT on the emonSD, the “cross-device” complications extend to include any “per value mqtt topics” as they too can arrive in an order different to which they were sent.
My own preference is still usually to use +feed over +input for the most part, but that generalisation is so heavily undermined by other aspects on a emonSD that whilst I suspect it is important to use the right one, I’m not so able to reliably predict which that would likely be with so many fluid variables.
I use harmonised timestamps, never use low-write mode, never split up batched values, always timestamp as close to source as possible and always send all data via emonHub to retain a chronological timeline so my input-processing is more predictable.
2 Likes
Thanks both; I’ll come back to that issue later, but meanwhile … Would one ordinarily expect a blue 100A CT sensor monitoring a cable that goes only to one 13A plug socket that is not being used to report an Input of zero? I have one that for most of the time is reporting ~30 watts, with a range of perhaps -5 to +40.
Do these CT sensors pick up “interference” from nearby CTs +/or wires? I have four in pretty close proximity to each other.
Is there a way to re-base this number, or even perhaps put in a line of code that says “if reported watts is =< (say) 50, output = 0”?
TIA
Not on emoncms.org, but the local self-hosted emoncms does have extended “logic” input processes designed for this type of use.
Hope? Yes, expect? Not so much!
30w is less than 0.01% of the channels range so it is quite a small error. If you are only using the CT for a max of 13A or less you might want to consider looping the wire through the CT. eg loop it 5x, that reduces the range of that CT channel to 20A , you then add a 0.2 scale (either in emonhub or at emoncms) .
The advantage of this is that the CT will most likely still pick up 30W of interference but when you x0.2 that reduces to just 6W.
The usual warnings and precautions apply when working on mains wiring.
Note @Robert.Wall’s earlier comments about noise when using 5v PSU’s, do you have an alternative source of power you could try?
Is this on your emonTx with the ESP8266? My comments were directed only at an emonTx not using an ESP8266. I’d expect the situation to be even worse if you are using an ESP8266, because it is a digital device using relatively heavy currents to drive the Wi-Fi, and unless the filtering is exemplary, I would expect it to add a certain amount of noise to the power supply, from where it finds its way into the ADC.
Bear in mind the c.t. itself is specified from 10 A - 120 A only.
@pb66, 'fraid your sum is wrong:
The maximum is 24 kW (100 A @ 240 V) so 30 W is 0.125%. But even so, that’s a long way below 10%, the bottom limit for accuracy on the c.t.
Ah! So it is, I think that extra zero must of slipped in whilst I was debating whether the error should be referenced to the CT capacity or the range of the ADC, if it’s interference it might be there regardless of what CT is on the end of the cable. Then there was the line voltage that has been nearer to 250 than 240 on occasions so should it be 25kW not 24kW, at which point I decided I was thinking about it way too much and just rounded it off to what should of been 0.1%. Perhaps I’ll just stick to “less than one percent” in future. 
I now have several “dials” working on a basic Dashboard, and am very pleased with the results. They give a good real time visual indication as to what is happening. All of the Inputs, Feeds & Dashboards are going through emoncms.org for now.
Question: As well as realtime usage data I would like to have some data fields, such as for example
- Power Used - Current Month / Last Month
- Power Generated - ditto
- Power Exported - ditto
Is this easy / possible to do? I can’t find a video tutorial online, nor can I see a widget to use within the Dashboard “toolkit”.
So far I have been working on the “old” Dashboard system, rather than the mobile phone type (with black backgrounds). I have yet to work out which is best for my needs …
TIA
That is actually a good question
I am able to do it on Chart mode, but would like to have it in data text display too
Looking forward for the answer
I am making good progress with regards to hardware, Inputs and Feeds - and will work to get all of this working before I spend time on fancy dashboards. But I have one issue to resolve; If you look at the attached screen grab, you will see there is no temperature input on the emonTx in the garage - but there is in the house.
Both emonTx’s have an RJ45 temp probe plugged in, so how do I get the Input to show in the garage? I have swapped the two wires over, so (presume) I can discount a faulty sensor. Everything is connected via wi-fi to an emonPi / emoncms.org
TIA
Julian
Two questions:
Obvious one: was the temperature probe plugged in when you powered up or restarted the emonTx? If it’s not detected when the sketch starts, it won’t look again and the temperature isn’t sent at all - ever, even if you subsequently plug the probe in.
Not having an ESP8266, are “psent”, “psuccess” and “freeram” coming from the ESP or is it a non-standard sketch, and if so, have you accidentally disabled the temperature measurement - is it still in the data that’s being sent? Can you see it in the data flowing between the emonTx and the ESP?
Thanks Robert; I’ve just turned the power off / waited 30secs / plugged temp probe in / turned it back on again and … Ta daaaa it works. #embarassing 
The attachment below shows the basic inputs from the CT sensors, temperature probes and AC-AC adapters. All I now need to do is wire in two more CTs in the Office, and then I can start playing with more complicated Feeds and dashboards etc.
Thanks so much for everyone’s help so far - it has been invaluable!
Don’t worry - you are a long way from being the first to be caught by that - to the extent that it’s near the top of the FAQ - and it’s an absolute certainly you won’t be the last. 
2 Likes
Within the Inputs page of emoncms.org it shows Node 5 (the emonPi), and 3 other nodes (which refer to the 3 EmonTx’s I have, but with no Node numbers, just names I must have entered at some stage), but it also shows a Node 4, with four “Keys”. All of them were last updated 11 hours ago.
How do I find out what Node 4 is? Is it safe to delete it within the Inputs page?
Within emonpi.local, it shows
- Node 5 - emonpi
- Node 6 - emontxshield
- Node 7 - emontx4
- Node 8 - emontx3
- Node 9 - emontx2
- Node 10 - emontx1
- Node 11 - 3phase
- Node 12 - 3phase2
- Node 13 - 3phase3
- Node 14 - 3phase4
- Nodes 19-26 - emonth1-8
TIA
Off the top of my head, I don’t think there’s a published sketch (at least a modern one) that uses the NodeID 4, so my guess is if you didn’t accidentally have something identified as that, or you didn’t use your browser to send some data to emonCMS using your APIkey (see the on-line help for how you can do that), it was rubbish picked up that happened to get through the checks and that node can be deleted. AFAIK, it won’t cost you storage until the data becomes a feed.
1 Like
This might be entering the world of micro-management & chasing one’s tail, but is there a way to co-ordinate / synchronise the clocks / posting times so that an emonPi and three emonTx/ESP8266 all update their data at the same time? It would make the dashboard data (& apps) slightly easier to interpret.
TIA