New emoncms settings format - help testing needed

I agree that file names are important but documentation also and generally there is a lack of documentation specially in the codes of the modules (API doc)…

Does the error repeat if you keep restarting demandshaper?

@TrystanLea, Just went onto github and switched to the settings branch in demandshaper and there is apparently no run.php file.

1 Like

Yes, I’ve just changed the service name to demandshaper_run.php. I’ve also updated the service file which will need recopying to /lib/systemd/system/demandshaper.service and then a systemctl reload-daemon. Once this merges to master I will add a notice to the demandshaper thread.

1 Like

@alexandrecuer - you will need to re-pull the repo and do the above changes.

If there is still a problem, add the variables to the error message and see if they are pulling through correctly.

1 Like

Can we change the install to do a link please? I raised an Issue.

1 Like

Sorry I forgot, theres an install script in the demandshaper module that handles the service install, including the correct path location:
demandshaper/install.sh at master · emoncms/demandshaper · GitHub

running:

./install.sh

inside the demandshaper folder sorts out the service file install.

and I realise now why its copied. Its because of the path change… so we need to use a override if we are to symlink. Will look into that alongside what we where discussing for setting the user for the other services.

Um, but the other services work fine…

Their run paths are all fixed to /var/www/emoncms/scripts… though. While the script path for demandshaper is system dependent .

Oh yes, I was thinking of the modules that get installed as links. You could pass the path as a variable to the demandshaper install script but default to the existing path - that might help transition.

I’ve create stable and master branches for all the emoncms modules and modified the emonSD update process to switch modules that did not have stable branches over to stable (if emoncms core is on stable).

So the testing process for the above is now to ensure all modules are on the master branch.

The only repository that needs to be on the settings_object branch at the moment is the emonpi repository. On an emonSD system:

cd
cd emonpi
git checkout settings_object

OK fine for demandshaper - no more error message on the admin page

for dashboards, I have the following warnings :

EmonCMS Error
-------------
Message: ReferenceError: Vue is not defined
Route: Modules/graph/graph.js?v=2
Line: 1294
Column: 21 

and

EmonCMS Error
-------------
Message: ReferenceError: _lang is not defined
Route: Modules/graph/graph.js?v=2
Line: 635
Column: 21

Anyway, no malfunction : you can edit and view dashboards…

As far as postprocess module is concerned, when creating a powertokwh process, it is correctly injected in the data field of the mysql postprocess table, the process begins to treat the datas, but the process is then removed from the list…the processed feed is anyway correctly created…I think it is not linked to the new settings, but do you have such a behaviour ? if yes I will raise an issue…
for other process, I dont have the problem

@alexandrecuer, can you try an update please, specifically the database update. I don’t think the database update has been changed to use the new settings object.

Thanks database is up to date

1 Like

@TrystanLea - might I suggest something in the admin page that informs which settings files are in use? Might be useful for debugging as the migration happens.

I’ve now merged the master branches into stable, which means this is all now live and available via emonSD update. I will do a forum post detailing this release next.

@borpin good idea, will look into that.

1 Like

I’m not sure the backup Module has been modified. I raised an issue.

My bad - wrong redis prefix so service-runner did not pick it up.

All fine except it is not currently backing up the settings.ini. I’m sure Trystan will fix that shortly :slight_smile:

1 Like

It seems to me, that this is the other way round in that, emoncms will first try and process a settings.php file (so backwards compatible) and if not found, will process a settings.ini.

1 Like

I’m running a custom Docker image. I’ve cloned stable branch and tried settings with env vars. Didn’t get it to work.
Below example gives error that user {{MYSQL_USER}} has no access. Placeholders doe not seem to be replaced with env vars. Setting the real values instead works nicely.
Example of my settings.ini

[sql]
server = 192.168.1.6
username = {{MYSQL_USER}}
password = {{MYSQL_PWD}}

[redis]
enabled = true

[mqtt]
enabled = false

[log]
level = 1