To be clear: I’m not certain this is the right way to go about this. It’s mostly based on guesswork and assumption from what I’ve scraped together reading around the discussions about emoncms. For the moment it appears to be working for me and that’s the best I can say. If you try the same and it blows up in your face, sets your hair on fire, eats your firstborn and sells your soul to Santa, I’m afraid there are no refunds. So, here we go…
The way to start once logged into the application is to create devices having selected that section from the menu on the left-hand side of the main page, but that appears to be much more straightforward if there are device templates to work with. After checking over a few of the existing templates, I realised that perhaps the system isn’t going to work as well as I’d like for the RFXcom units that may receive messages from multiple RFXmeters at once, so I decided to treat each sensor connected to an RFXmeter (which may have one, two or three connected) as a separate device. In the end, this is what I came up with:
{
"name": "single-input RFXmeter",
"category": "RFXcom",
"group": "Power",
"description": "1-input RFXmeter",
"inputs": [
{
"name": "count",
"description": "CT Power 1",
"processList": [
{
"process": "log_to_feed",
"arguments": {
"type": "ProcessArg::FEEDID",
"value": "power"
}
}
]
}
],
"feeds": [
{
"name": "power",
"engine": "Engine::PHPTIMESERIES",
"unit": "Wh"
}
]
}
“name” (on the first line) is the entry that will appear in the devices menu for this specific template. “category” is the top-level menu item that it will appear under. In this case I’ve used the name of the company producing the device. “group” appears as a sub-menu of the category, so there might be RFXcom units for measuring gas and water use, say, and they could appear in the same category with different group names. Or a different RFXmeter configuration might appear under the same group as my new device.
As I’m treating each meter input as a separate device there’s only one entry in the “inputs” section. There, I believe “name” is the third element of the topic name to use with MQTT to retrieve data for this sensor, so the full value would be sensors/rfxmeter1/count for example. I’ve used the name “count” because that’s what the RFXcom units call the values they send.
The rest of the entry for this input details how to deal with the data:
"processList": [
{
"process": "log_to_feed",
"arguments": {
"type": "ProcessArg::FEEDID",
"value": "power"
}
}
]
In this case it’s going to be delivered to a “feed” so it can be turned into graphs and suchlike, and the arguments are just indicating that the “log_to_feed” process should be given a feed ID of “power”. That ID is the one that’s used as a name in the “feeds” section of the configuration:
"feeds": [
{
"name": "power",
"engine": "Engine::PHPTIMESERIES",
"unit": "Wh"
}
]
The options for “engine” appear to be Engine::PHPFINA for data that is delivered at regular intervals, or Engine::PHPTIMESERIES where it may be delivered randomly. As the data I’m getting can be a bit variable if the radio signals from the RFXmeter unit aren’t clear, I chose the latter. And in the case of the RFXmeter values, they’re watt-hours rather than kilowatt-hours, so I’ve made that clear in the “unit” field.
This file now needs adding into the Docker image. The existing templates appear to be stored in /var/www/emoncms/Modules/device/data. Looking at the existing image I suspect the directory names may be important, too, so at the top level of my copy of the emoncms Docker project I created a new directory devices/RFXcom. I also suspect the template filenames are important, so in that directory I put the above template file, named rfxcom-rfxmeter-1.json. I believe the first component of the filename (before the “-“) must match the directory name, but be in lower case. It’s possible the end directory name must also match the category name in the template file. I don’t know that for certain, but it looks like that might be the case with the other templates, so I kept to the same form.
Then it’s just a case of copying these files into the Docker image when it is created, which I did by adding the second COPY line in this section of the Dockerfile:
COPY docker.settings.ini /var/www/emoncms/settings.ini
COPY devices/* /var/www/emoncms/Modules/device/data
# Create folders & set permissions for feed-engine data folders (mounted as docker volumes in docker-compose)
After recreating the image and logging in again I was then able to go through the usual device creation process using my own template. I actually went through the process of adding my five power sensors as rfxmeter1, rfxmeter2, rfxmeter3, etc., but in retrospect I think I’ll rename them along the lines of “rfxmeter<meter-number>–<sensor-number>” so it’s clear which sensor input is associated with each RFXmeter unit.
The next stage would appear to be to start pushing data from the sensors into MQTT and see what happens. Life is never simple though, is it?
Presently I am reading data from the RFXcom unit using Perl and a module that can decode the data sent. Unfortunately there doesn’t seem to be a confidence-inspiring MQTT module for Perl. Python might be an alternative as it does have good MQTT integration, but the only RFXcom module I can find doesn’t work with versions of python after 3.6. I have discovered that there’s a set of Node-RED nodes that might possibly do everything for me, but that seems like a massively over-engineered way to read some data from a serial port, decode it and post it to an MQTT topic and I don’t know it would work for certain anyhow. More investigation is required here…
