Totally agree. I tested the integration-branch now in both stable and master.
I guess versioning makes only sense in a potentially new stable branch?
The changes with the set_processlist() were merged yesterday with #0b3d009 in stable and in #af3e77 in master… so prior to yesterday, everything should’ve worked for my understanding?
Although I cannot be sure, I expect it was before then.
I have just pulled in both the main master emoncms branch and the “device-integration” branch of the device module, still no processlists created.
Switched to the “master” branch of the device module, as I cannot re-run initialise, I created a second emonTH and that too has been created with no processlists.
I suspect the device module has not been compatible with the master branch of emoncms for sometime and it just hasn’t been noticed because I haven’t updated the device module and you guys are not running master or stable emoncms.
Do you know off hand how to roll back to a specific commit? I will try rolling the device module back to before those changes
Ok I think I have an interim solution, I’ve created a patch for the master banch available in a branch called set_processlist_patch:
https://github.com/emoncms/device/tree/set_processlist_patch
if you just do ‘git checkout set_processlist_patch’ that should get device initialisation back up and running on the master branch. Im not going to merge it as it will cause merge conflicts later on, if I try to merge the device-integration branch into it.
This patch works with the latest emoncms master branch 9.8.11.
Depending on whats your definition of “quite a while” 
The device-support branch actually gets almost weekly merges to be up-to-date with master.
All problems regarding set_processlist() and hence the template processList creation was due to the merge from yesterday.
Maybe this is a cache-problem with your browser, as the module stores some template meta-data in the browser cache? Did you try ctrl-F5 reloading the page?
I tried reproducing your problems with the latest fix and everything works fine for me 
Sorry Trystan, but that doesn’t help me much, a patched “master” still cannot add the processlists to existing inputs and and the previously created feeds blocks it from re-initialising.
We need to fix the “device-integration” module to be compatible with emoncms pre-9.8.11 and so that the types are saved. For now patching the “device-integration” branch would make more sense, that would get me out of this hole and allow the “device-integration” branch to be merged into master without breaking systems that already use the device module.
Well possibly 7.5 months in this case.
At every step and I just retested now, just in case.
@pb66 the device types are definitly getting saved correctly for all emoncms branches for me.
When you create new devices, they still get saved with a type NULL?
We are discussing the lack of processlists, not the device type, I now have many devices all with a type (i’m having to switch back and forth between branches)but none with a processlist.
I have now pulled in the latest device commits too, I have cleared the cache, I have tried to re-initialise an existing device and it didnot add a process list. I have tried creating another fresh device and it has created 2 inputs each with one item on the processlist, but the “internal battery” input has now disappeared, so it’s still not right.
I was referring to the “so that the types are saved” but ok.
But the emonth template I have in front of me does not have a Battery input?
Did something change here @TrystanLea ? I think the templates were a little overhauled, as e.g. the EmonPi templates use “log_to_feed” instead of “1” now?
Maybe hopefully it could work if you use the old templates from the master branch together with the new Code @pb66 ?
If the templates have changed too, I hadn’t noticed. In that case it seems to have created a new fresh device ok, but still won’y add the missing processlists to the previous attempts.
If that part is not yet functional either then I am clearly not going to be able to fix this using the device module.
I have no particular interest in the emonth templates I am just using a stock template to test, my templates are way too big to use for tests. The missing input looked like an error, the 3 devices you see are all from the same template (name) but since the new branch wouldn’t save the type originally, they have been created by the master branch.
Ok but this seems to be a fundamental problem, as everything you describe definitly works for me with the master,stable and device-support branches of emoncms without any problem what so ever. Both on a windows machine as well as on a Raspberry Pi with Redis enabled.
Help me reproduce your system, as this is definitly nothing trivial code-wise…
I have identified one issue when upgrading from device:master to device:device-integration. In the way the device information is cached in redis. Essentially the userid was not previously cached in redis and now it is and this causes both the get function and init function to fail.
To reproduce I first do git checkout set_processlist_task (as Im using the latest master). Then I create & initialise an EmonTH using the old template which creates 3 inputs and feeds which are MYSQL. I then do git checkout device-integration and try to delete the device but it fails. If I delete the input processes to try and replicate @pb66’s state I still cant initialise.
If I clear redis it works fine.
But in general I try not to do redis flushall on a production server, as it can affect input and feed last values, so it might be best to do a selective device cache clear
You’re completely right, I cache the userid now to be able to avoid querying the database everytime I call a ->get() function, but this should work flawlessly for newly created devices then?
But yes, for the already existing devices of @pb66 a redis flush-all could do the trick
Did you also see my note on the github pull request regarding the get function @Adminde Improve caching and fix set_processlist by adminde · Pull Request #9 · emoncms/device · GitHub
Can you specify the keys that need deleting do I can manually check them and delete them?
My test server is on the same physical server as my live instance and FLUSHALL indiscriminately flushes all, something I’ve been wondering about if we can use seperate redis db’s for each emoncms instance and then use flushdb instead.
If we KNOW we’ve fixed it, I will do a flushall, but til then I would prefer to not keep flushing my live instance.
Can you find the device id of the device in question?
The key should be of the form:
emoncms:device:77
emoncms:user:device:2
where:
emoncms:device:deviceid
emoncms:user:device:userid
