@TrystanLea would it be possible to create an ‘Input Alias’ feature to Emoncms?
One of the hassles is when you have a set of processing set up, works nicely and for one reason or another, you have to change the Input. You then need to build the whole processing again.
Could there be a mechanism that allowed you to assign a different Input to the Processing or a process that allows you to simply pass one input to a different (the original) Input?
Effectively split the processing out from being fixed to one input, and allow the input to a set of processes to be changed? The processing is then almost a Virtual Input.
In that there is also the thought about copying processing ‘templates’ between Inputs (with the Feed it’s logged to changing).
Looking at the API, there is a both a GET and SET process for the process lists, so perhaps a simple UI to select the new Input that does a GET UNSET SET from old to new?
Just a thought especially if folk are upgrading to EmonTX4s
Sounds good to me. Even being able to do a straight copy of the process list from one input to another, then edit it to tweak the values (and maybe choose a different feed or two) would be very useful, considering the number of requests/complaints we see when a contributor finds for whatever reason they need to replicate a process.
if the process list is free-standing (i.e. the first step is to assign an input to it), what event initiates processing? It looks to me as if the Input needs the capability of having a Process List assigned to it (and only one), and thereafter everything is almost the same as we have now.
It will add a layer of confusion to those who don’t yet understand the system, but power comes at a price.
But surely, automatically changing a Feed is more dangerous, not less? How does it know the right one to choose? Most people have fallen into the Ctrl-C Ctrl-V trap more than once, and know to look out for things that need changing.
I disagree, it’s not at all crazy. I think with the 3-phase emonTx being imminent, the European market is likely to expand and there will suddenly become a need to copy a chunk of process from Phase 1 to Phases 2 & 3. And especially if 3-phase becomes the norm for UK domestic users, as has been suggested (though when is a moot point).
Yes, I think as part of the copying, there would need to be a UI intervention to change the Feed to be logged to (could be multiple feeds). In your 3 phase example, you don’t want all 3 inputs to be logged on the same Feed (which a straight copy would do).
Perhaps the answer would be to default to (when copying rather than switching inputs) a new feed being created. If an existing one was required, it is a relatively simple job to select the existing feed.
There simply isn’t a one-size-fits-all answer. I feel a straight copy, which most people do all the time, fits expectations. A copy and automatic change won’t. I can see your point about offering the selection, but what if you need to refer back to another place - you need to make a choice that might be wrong, go away, come back and possibly change it. Code complication for little or no gain is how I see it.
