https://github.com/openenergymonitor/emontx-3phase

What's the license for this repo?

Is it AGPL-3.0-or-later as per https://github.com/emoncms/emoncms ?

To make the templates easier to read I have tried using the function name in place of the processlist index number eg "process":"log_to_feed" rather than "process":"1" but that doesn't seem to work.

I have also tried "process":"process__log_to_feed" to try and match the "process":"additionalp__andfunction" which does work in the events module, so it appears to be that the original processes are only available via the numeric index that has apparently only been kept for backwards compatability, is that correct?

if so how difficult would it be to make them available via the function names?

I had some devices posting to emoncms before making up the device template files, since devices are now created for all new inputs, there were new devices already listed on the device page so rather than deleting, I "edited" the device(s) and selected my new template and "reinitialized" the device.

The first time I did this it duplicated the inputs and I put that down to it not recognizing each existing input by it's index+1 temporary name given to it.

However when I fixed a typo to a feed name and added another input to the template and then reinitialized the same device a second time, it created a third set of inputs, see below.

It should have only created a single addition input as input "8" aka "frequency" was omitted in the draft template.

This creation of a third set of inputs is definitely a bug, but the second set although it could be the same error, I sort of expected it to happen as it couldn't map the old temp names to the new names, but now we have indexedinputs there should be no problem with mapping.

After updating a device template redis redis must be updated reload the templates to make the changes visable:

redis seems to be duplicated, and potentially missing some punctuation?

After updating a device template, redis must be updated. Reload the templates to make the changes visable:

This has been discovered, debugged and fixed previously on the forum (https://community.openenergymonitor.org/t/development-devices-inputs-and-feeds-in-emoncms/4281?u=pb66).

I am currently running emoncms 9.8.31 indexedinputs branch fully up to date at 15/10/18 with the "device-integration beta" switched off. The device module is also fully up to date and I've tried both the master and the indexedinputs branches.

It is currently not possible to introduce any new templates. I have tried adding new templates to both existing and new groups and new folders and every combination of those fails. At each change I have cleared the browser cache.

I have also tried creating a unwanted device to try and pull in the changes (this was previously found to work before this same issue was fixed last time), but the listed device templates doesn't change.

The only way I'm able to get the new template picked up is to delete all keys from Redis via the command line, then the list repopulates with the new templates included.

Device template cache needs reloading somehow so that users can see new devices, calling:

https://emoncms.org/device/template/reload.json

works, perhaps this could be called once when the device interface is loaded?

What do you think @adminde

I've just updated the OpenEVSE device, but no one will be able to see it, in its new location on emoncms.org without calling https://emoncms.org/device/template/reload.json

See: https://community.openenergymonitor.org/t/what-is-the-feed-template-for-a-device-with-a-virtual-feed/13297

Errors in emoncms.log related to device module from Dave's test emonPi:

Currently, if a user doesn't select any device template which is easy to miss since there are no clear instructions or prompt to do so and the device template list is hidden on a mobile device, the user is still able to click save without selecting any template.

How about an error message if a user tried to click 'save' without selecting a template, or 'save' could be greyed out until a suitable template has been selected?

Why does every template seem to have 2 superfluous key:value pairs?

Whilst trying to navigate the Redis entries for device templates (related to #24) I noticed that every template has the following

1) "module"
2) "device"

. . . 

11) "control"
12) ""

fields 2 thru 10 seem valid enough, but these don't seem to serve an obvious purpose (that I can see)

pb66@test2:$ redis-cli HGETALL emoncms:device:template:emonpi-SPV1
 1) "module"
 2) "device"
 3) "name"
 4) "Solar PV Type 1"
 5) "category"
 6) "OpenEnergyMonitor"
 7) "group"
 8) "EmonPi"
 9) "description"
10) "EmonPi Solar PV Type 1 template"
11) "control"
12) ""

When editing a device and clicking on New to generate a new device key it gives this error:

Fatal error: Uncaught Error: Call to a member function hSet() on boolean in /home/gtdev/sites/emondev.gtronica.com/Modules/device/device_model.php:563Stack trace:#0 /home/gtdev/sites/emondev.gtronica.com/Modules/device/device_controller.php(98): Device->set_new_devicekey(32)#1 /home/gtdev/sites/emondev.gtronica.com/core.php(63): device_controller()#2 /home/gtdev/sites/emondev.gtronica.com/index.php(240): controller('device')#3 {main} thrown in /home/gtdev/sites/emondev.gtronica.com/Modules/device/device_model.php on line 563

It's quite un-intuitive to click the little 'x' to collapse the burger menu. This is made worse by the config menu not aligning left correctly:

When re-naming a node (screenshot); the node's inputs are not adjusted to use the new node name. The old node is then re-created when the next input data is received.

Node field above is the device.nodeid field in MySQL
Name field above is the device.name field in MySQL

MySQL data structure: device.nodeid == input.nodeid

Would be good to add the check for node inputs and editing their input.nodeid property in the following lines: https://github.com/emoncms/device/blob/master/device_model.php#L435

As inputs is a Module in https://github.com/emoncms/emoncms it would be better to use the input controller to achieve this without having to change the input Module directly.

A stable branch of this module should be created for consistency.

https://community.openenergymonitor.org/t/thoughts-on-the-new-input-and-feed-page-layouts/8583/20

Could we consider having the data directory structure sub-divided rather than all the templates in one folder?

That way users/we can better manage custom sets of templates that meet our own needs and standard templates can be grouped and maintained in their own repo's, eg OEM stuff in one repo, the existing "amig.json" and "amrm.json" etc in another so that we can install the templates we want and more importantly, maintain our own repo of custom templates without them having to share a folder with the included templates.

A similar sort of set up to the emoncms Modules folder where a minimum of just an "example" folder is included in the emoncms/device repo and a .gitignore file to prevent installed template folders from being committed when contributing.

The folder names could also double up as grouping names so that as the number of templates increases they are still easily found.

This might encourage other device/software developers to maintain their own device templates to make using their products even easier to use with emoncms.

I would be happy to look at this if it's an acceptable idea, I'm not specifically asking for someone to do it, just asking if anyone has any opinion at this stage

What is this module for? Could it have a readme?

I'm intrigued! .... :-)

When setup of a new device you will need a devicekey ahead of the first post.
The create new device button is missing from the UI.
It was available on the old version.

While the image at https://guide.openenergymonitor.org/images/applications/solar-pv/solar-pv-install.webp on https://guide.openenergymonitor.org/applications/solar-pv/ explains what Type 1 vs Type 2, it's not immediately obvious what those mean from the "Configure Device" window

I've no idea if HTML link parsing will work from the JSON files (not tested yet)... But having some sort of reference link there to https://guide.openenergymonitor.org/applications/solar-pv/#sensor-installation would potentially be useful for those browsing around the interface who may wonder what Type 1 vs Type 2 are

@adminde you've added the support for sharing MQTT auth to a device using the API.

Shouldn't there be a complementary UI functionality for listing devices pending authorization and approving ?

Should be possible to configure the input: name, location and even devicekey without having a device template.

Currently it gives the error: "Device need to be configured first"

You may add an option like: "Configure Manually" when there is no template available so that processors and feeds need to be configured manually.

It's like the old way of emoncms working, inputs get created automatically when a device posts.

see https://community.openenergymonitor.org/t/error-on-inputs-page-in-10-1-2/11295/6

related to emoncms/emoncms#1360

For devices with short names the help text is hidden

https://community.openenergymonitor.org/t/device-category-setup/9634