I’ve been doing a bit of work on an idea for simplifying the configuration process for standard applications in emoncms - a device configuration wizard. Paired with the EmonESP wifi developments this is not far off a three step setup process to get home energy monitoring or solar pv monitoring up and running: 1) connect to hotspot and select network 2) register an account with emoncms via EmonESP 3) Select configuration in the Device Wizard
I’ve put together a screen cast here to show the concept:
nice programming for the dummy
will make it more easy for non experts to use the devices though you might end up with more complex support if something goes bad. As the person doesn’t understand what he did … hard to ask to dig behind it to try to figure out what went wrong. Might end with many basic questions that could have been solved if the mechanics behind it were understood.
Thanks Eric, yes will be interesting to see to what degree that might happen, its only going to be useful for configurations that are completely standard, once you add a 3rd CT to the emontx to measure say storage heater power or a temperature sensor the usefulness of this decreases as knowledge of input processing and feeds are needed anyway…
I do see this module more for ‘managed’ hosting such as emoncms.org where there is a server admin that can ensure that the underlying requirements: feed engines, input processes etc are all in place.
Very slick! and ideal for standard systems, especially for new starters.
The video introduction is a nice touch, and worth repeating for future developments. I assume that you’re going to link to it in the repo readme
This looks amassing. I have been looking at the backed to create templates for my standard device. Is it possible to have it create sql feeds?
Thanks
Dafydd
Hi Trystan, have you seen the device module available since January?
It supports device templates to auto create inputs , feeds and can be extended to create dashboards easy. Also supports per device key for better security.
There is no need to create new modules if one already exist that can be extended with new functionalities for a small effort.
Historically this project has had this same mistake in the past, eg: nodes vs input modules, low-write vs normal version, apps vs dashboards modules.
This inconsistencies limits much a shared development effort because the developer has to decide what to support or try to merge inconsistences that are difficult and time consuming.
Hello Nuno, Sorry I had not appreciated exactly what the device module did, I can see now it does much of the same in terms of input and feed setup. Im quite keen to have this basic interface with the setup graphics and a key feature is the ability to select from mulitiple configurations such as home energy monitor, solar pv, different heatpump setups, it this something the device module can/could be extended to do?
On the apps vs dashboards question, I really think there is a large difference here and the ability to code more easily more complex interfaces is a real benefit for me with these prebuilt apps.
