Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Cannot create inputs

Tags: #<Tag:0x00007fe7a1dc8c38>

Hi all - I am extremely frustrated that I can’t seem to create inputs.

Background on my setup: I bought the emonbase and the emontx when it was first released several years ago. I set it up by adding the inputs corresponding to the CT sensors (all 4) and it was running for several years, logging to emoncms.org, no problem.

A couple of months ago, I bought an additional emontx unit so that I could log data for more circuits. I edited the device in emoncms.org but it was giving me bogus values for the inputs. So I figured my emonbase was out of date, and I updated it to the latest, so now I have the emoncms running on it.

There appears to be no way to create inputs for all of the CT sensors. The new device template setup doesn’t seem to have a device that has all 4 CT sensors. That would be OK if there were a way to manually create them but there isn’t as far as I can tell. There also doesn’t seem to be a way to add an additional emontx. Is this stuff supposed to be auto-discovered or something? Do I need newer emonbase hardware?

Frustrating because it was working for years without needing to touch it, and now with an expansion of the system it is completely down.

Inputs just appear if you are sending data to the server that it can understand - you can’t ‘create’ them manually.

Did you change the NodeID of the second EmonTX?

Are they both talking via RFM?

Welcome to the community.

To add a couple of points of explanation to what Brian has written, things have changed and progressed over time, so the new emonBase software probably isn’t consistent with your old emonTx software.

It’s easily fixed, but what sort of emonBase do you have - is it a Raspberry Pi with a RFM12Pi piggy-back radio module, or is it the older Open Kontrol Gateway or the even older NanodeRF?

What’s changed is the NodeIDs, and the number of variables and their types that are sent by the emonTx. That means if your Base is RPi-based, it will need just one configuration file (emonhub.conf) editing to bring it back into line with your emonTx’s.

If you know the version of software in your emonTx’s, that will help. Otherwise, and again if you have the RPi emonBase, the error message from the emonhub log will hopefully have enough for me to deduce what data is being sent from your emonTx.

Do you have a programmer and the Arduino IDE set up on your computer?

Thank you both for the responses. The emonBase is a Raspberry Pi with the RFM12PI radio module.

One emonTx is node 10 and the other is either 15 or 16. I changed the node id after I wasn’t able to get it working, same result.

Very good to know that the inputs should appear automatically.

One emonTx is quite old, I have not upgraded it since install, and the other was purchased in December.

I do have the Arduino IDE - I do not have an ATmega programmer but I could get one.

I just restarted the emonBase and here is the log - I see there is a communication error:

2021-02-09 04:11:21,834 INFO MainThread EmonHub emonHub (emon-pi variant) v2.1.5
2021-02-09 04:11:21,869 INFO MainThread Opening hub…
2021-02-09 04:11:21,872 INFO MainThread Logging level set to DEBUG
2021-02-09 04:11:21,906 INFO MainThread Creating EmonHubJeeInterfacer ‘RFM2Pi’
2021-02-09 04:11:21,913 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2021-02-09 04:11:23,960 WARNING MainThread Device communication error - check settings
2021-02-09 04:11:23,964 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2021-02-09 04:11:24,979 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2021-02-09 04:11:25,983 INFO MainThread Setting RFM2Pi group: 210 (210g)
2021-02-09 04:11:26,988 INFO MainThread Setting RFM2Pi quiet: 1 (1q)
2021-02-09 04:11:27,992 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2021-02-09 04:11:28,996 DEBUG MainThread Setting RFM2Pi pubchannels: [‘ToEmonCMS’]
2021-02-09 04:11:28,999 DEBUG MainThread Setting RFM2Pi subchannels: [‘ToRFM12’]
2021-02-09 04:11:29,009 INFO MainThread Creating EmonHubMqttInterfacer ‘MQTT’
2021-02-09 04:11:29,080 DEBUG MainThread Setting MQTT pubchannels: [‘ToRFM12’]
2021-02-09 04:11:29,083 DEBUG MainThread Setting MQTT subchannels: [‘ToEmonCMS’]
2021-02-09 04:11:29,127 INFO MainThread Setting MQTT node_format_enable: 1
2021-02-09 04:11:29,129 INFO MainThread Setting MQTT nodevar_format_enable: 1
2021-02-09 04:11:29,132 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2021-02-09 04:11:29,177 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer ‘emoncmsorg’
2021-02-09 04:11:29,183 DEBUG MainThread Setting emoncmsorg pubchannels: [‘ToRFM12’]
2021-02-09 04:11:29,227 DEBUG MainThread Setting emoncmsorg subchannels: [‘ToEmonCMS’]
2021-02-09 04:11:29,230 WARNING MainThread Setting emoncmsorg apikey: obscured
2021-02-09 04:11:29,232 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2021-02-09 04:11:29,235 INFO MainThread Setting emoncmsorg senddata: 1
2021-02-09 04:11:29,249 INFO MainThread Setting emoncmsorg sendstatus: 1

The first problem is the communication error. Your RFM2Pi is likely to want to talk at 9600 baud, your emonHub is talking at 38400. Change that in emonhub.conf. If it still doesn’t work, the easiest is to try every baud rate available between 9600 and 115200 (it’s never been slower or faster than those, but as far as I know, only 9600, 38400, 57600 or 115200 have been used:

[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400         # 9600 for old RFM12Pi

With a bit of luck, Node 15/16 should appear, and with a bit more luck, so should Node 10. If it doesn’t, I’ll need a bit more of the log showing the actual length of the data from Node 10, then I’ll look back through the old sketches and see what fits.

Nice, I am seeing inputs and values from node 16 now and I know a bit more about where to look.

Here’s the relevant bit of the log, I’m guessing the emonTx just needs an update because the frame length is too short:

2021-02-10 02:35:31,582 DEBUG    RFM2Pi     5567 NEW FRAME : 10 9 0 8 0 254 255 2 0 101 48 0 0
2021-02-10 02:35:31,593 WARNING  RFM2Pi     5567 RX data length: 12 is not valid for datacodes ['h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'L']
2021-02-10 02:35:33,281 DEBUG    RFM2Pi     5568 NEW FRAME : 16 135 8 84 85 179 126 84 85 185 170 85 85 105 85 229 81 85 85 123 154 170 170 38 186 170 170 9 126 85 85 101 32 101 32 101 32 84 85 85 85
2021-02-10 02:35:33,292 DEBUG    RFM2Pi     5568 Timestamp : 1612924533.280427
2021-02-10 02:35:33,294 DEBUG    RFM2Pi     5568 From Node : 16
2021-02-10 02:35:33,298 DEBUG    RFM2Pi     5568    Values : [89554, 112.38, 1, -20, 0, 60, 1200, -12498, -4237, 11100, 300, 300, 300, 1]
2021-02-10 02:35:33,301 DEBUG    RFM2Pi     5568 Sent to channel(start)' : ToEmonCMS
2021-02-10 02:35:33,305 DEBUG    RFM2Pi     5568 Sent to channel(end)' : ToEmonCMS

Reformatted text, BT - Moderator

I have a feeling this has been caused by the emonhub.conf being ‘updated’.

No, not necessarily. As Robert posted

and

I’ll let Robert confirm the payload format as they have recently changed and I would need to go exploring to find the info, but it will be a simple edit in emonhub.conf, done via the config page of emoncms, so just a minor task. :crossed_fingers:

1 Like

That’s exactly what has happened.

That’s the part we need to look at. Taking it one or two bytes at a time, L-R:
“10” is the node ID
“9 0” is likely to be a power, not much 9 + 256 × 0 = 9 W
“8 0” likewise.
“254 255” again likewise, but as I know all powers are signed, a small negative power
“2 0” again a small power
“101 48” 101 + 256 × 48 = 12389 = 123.98 V probably. This is where putting your country in your profile is useful, because that’s a stupid voltage for me, but you might live where 124 V is a sensible value.
“0 0” My guess is, that’s a temperature or pulse count, more likely the first.
So, I’m looking for an emonTx sketch that sends 4 powers, a voltage and something else. That rules out most of the emonTx V3.4, the 4 powers rules out all of the emonTx V2, so it looks like an emonTx V3.2.
Here’s one that fits: emonTxV3_RFM12B_DiscreteSampling.ino
The payload for this is

typedef struct { int power1, power2, power3, power4, Vrms, temp; } PayloadTX;

so now I can construct the Node definition to go into emonhub.conf. At present, you will have

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

The easy way is to edit the bits of that that are different to read

       names = power1, power2, power3, power4, vrms, temp
       datacodes = h,h,h,h,h,h
       scales = 1,1,1,1,0.01,0.01
       units = W,W,W,W,V,C
1 Like

Thanks to your help, I am now back up and running, nicely logging data. Thank you very much. This system is critical for monitoring my well pump - I’m in Colorado and we’re in a drought… this allows me to detect if my well is starting to run dry. I also have PV so keeping track of that and my consumption is also quite nice.

1 Like