The following are some ideas I had for new Emoncms features:
Ability to put data on dashboard without Log to Feed It would be nice if we could put an "input" on a dashboard, for data that doesn't need to be logged or saved. The only purpose would be for visualization. It could work in a couple of different ways:
1. Have something like a special virtual feed, mapped to an input (not a feed) only for the only purpose of putting the data on a dashboard.
2. Give the option for feeds that do not insert data after the first, and only row, in the table. The data is simply overwritten. That would fulfill the desire to put input data on a dashboard, without building up a big table of data that I don't care to save. Wouldn't that just be a change from insert to update?
Improve Button Widget Improve on the button widget, such that a press could send a MQTT message, or modify it as demonstrated by joyrider3774 in this post: http://openenergymonitor.org/emon/node/11728
Improve LED Widget Provide for setting the LED color, and improve the LED graphic (it looks too much like the button widget). Maybe just make it smaller?
Provide a Reports Module Provide a way to generate simple custom reports. For example, a report of kWh used from December 7, 2015 until January 9, 2016. The report could have daily kWh and a grand total, as well as daily and total cost. Allow for entering date ranges, feeds, what to total and what to multiply. A built-in reporting module would be very useful.
Thanks for consideration and comments. Tom
Re: Emoncms Feature Requests
I agree something like a "log to variable" process would be a great addition. no distinction between inputs or feeds, just a holding place for a current value, updated each time the input processes.
I have many unwanted feeds that are just holding the result of a process calculation so I can use +-x/ feed later somewhere else or to just display the current value, no persistence is needed.
There are currently 2 ways to perform complex processing, either do each smaller part of the sum once and save as a feed so it can e reused or you sometimes you can repeat the processing multiple times for slightly different results. The first taks up diskspace and the second add a significant amount of wok for the user to set up and ongoing processor time each time the input is updated.
There was a big discussion on this subject sometime ago and the use of "virtual feeds" that were basically the same as normal feeds but not persisted, this transformed into the current "virtual feeds" that may work for your purpose, they only "process the feed data" when the dashoard is loaded so unfortunatly they do not work for process calculations nor could you get the current value via a api.
Paul