I’m about to add an EmonESP equipped board to my old EmonTX. I have several years of data in feeds that I want to keep. I’ll post to my MQTT broker using the EmonESP-generated topic names, like ct1,ct2,…,t1, etc. (base topic omitted). Looking at the DB schema, I devised the following simple procedure:
Stop EmonCMS, EmonHUB and mqtt_input services.
Update all rows having nodeid = 'emontx3' of the input table in the emoncms DB similar to this: update input set name = 'ct1', nodeid = 'emonesp' where id = 1;. Process the rest of the rows similarly with a script.
Update all rows having tag = 'Node emontx3' of the feeds table in the emoncms DB to tag = 'Node emonesp'.
Start EmonTX and the attached EmonESP board.
Start all services stopped in the first point.
Would it work? Is there something that needs to be taken care of besides these tables?
That sounds like you are thinking of editing the mysql tables directly, is that right?
Are you aware that you can just edit the input names in the emoncms input page?
Assuming you have the latest v10+ emoncms you just select the inputs by checking the boxes on the left, click edit near the top of the page and change the “1,2,3,4” etc to “ct1,ct2” etc and save.
As for the nodename, I see no reason to change it since the data is still coming from the emonTx3 whether it comes via the emonESP or not.
You are right to take the precautions of stopping and starting the services, and not powering up the emonESP until after you have made the changes. Editing keys on moving data is never a good idea.
How old is the emonTx? You may need to re-flash the emonTx firmware if it is from a pre-emonESP era as the emonTx serial output was not emonESP compatible until v2.4 06/09/2016.
@pb66: thanks. You’re right, but I thought I’d make a distinction and flag the node with a new node ID. That requires fiddling with the DB and at the same time I could change both. Working with a database is not a novelty to me, on the contrary. OTOH, I’ve already prepared the firmware I’ll upload to the EmonTX. It’s too old to support the new format using the list of key:value pairs. Sadly the EmonESP source also needs a few small changes to work on the generic NodeMCU module I’m using but that has also been taken care of.
If you are intending to do it via mysql then i would recommend in addition to stopping the emonhub, mqtt_input(now emoncms_mqtt?0 and feedwriter services, I would also stop the apache2 server service and flush Redis before bringing it back online.
I’m not sure I understand why that would make any difference, it’s simply a “group name” and it’s changing just those last 3 chars of the nodename that is causing significantly more work and more risk.
I wasn’t questioning your skills or knowledge of SQL, It just doesn’t seem right to edit these through an less well-trodden backdoor method when there is a tool specifically for the job in the GUI but that is of course your call.
But yes, you have the concept right in that you must lock everything down before attempting any editing via SQL, I can’t confirm your SQL code offhand as i’m no expert. But I would also recommend making a back-up of the DB just in case things don’t go to plan.
I’m not using Redis and have listed the services in the first point. I always make backups before important changes. It’s not a Pi BTW, it’s running in an LXC container in a Proxmox virtualization host.
But on after some rethinking I might just go with online renaming while the input stream is stopped. It’s indeed a bit simpler and the node naming is just a visual thing. What’s important is feed data.
Answering the question in your deleted post “Can a sketch be calibrated on-line” - Trystan’s new CM sketch that uses emonLibCM also has a degree of on-line calibration included. You could look at that with a view to integrating the principles of that into any sketch - basically, you must either reset the calibration in emonLib, or if it’s only amplitude changes that you require (not phasecal), you can apply your own multiplier in between extracting the value from emonLib and setting into the data structure for radio transmission or, in your case, writing it out serially to the ESP module.
Thanks for the response – I removed my post because I realized it’s a little more than just the question of applying calibration values somewhere. I will eventually move from EmonCMS + phpfina feed storage to an InfluxDB (with MQTT input source) and Grafana setup where I have a lot more freedom in defining what I want to see in my graphs (+ a huge array of other possibilities). The only 2 things remaining will be the EmonTX and the EmonESP. The former possibly with the new emonLibCM library – though it’s in a kind of “beta” stage for my tastes. I’ll be still able to add calibration values to the EmonTX sketch if I want, and at the moment I’m more interested in amplitude correction as I’m using OEM recommended sensors. That can be done in several places in the pipe.
But anyway, now that you mentioned the CM lib – do you think it’s ready for general usage? Are there outstanding issues you care about?
