Newbie looking for guidance

Getting Started
1

Hi all,

I am trying to design my home energy monitoring solution around the open energy Taormina, and I have a few questions I could use help with:

  • I have 4-5 meters that output pulses on S0-like buses: water meter, a three-phase meter in my electric panel: is there a packaged solution that would fit in the panel and could relay multiple pulses to an emonBase? There seems to be one S0 input on some devices but I haven’t seen multiple ones?

  • this is the kind of things I could easily program for an arduino, is anyone making an electric panel friendly, Ethernet enabled enclosure for custom Arduino (e.g. pro mini) projects?

I have the same question about teleinformation coming from my French
Linky meter into the electric panel: is there any solution to forward that to an eMonBase over Ethernet? Again I can program, but I would rather use a ready-made enclosure (no power adapter, DIN rail mounting)

In other terms i guess I am looking for an electric panel ready emonCMS client, which I could configure with my Arduino code to process serial and digital inputs to feed data to the eMonBase… any pointers?
I plan to use IoTaWatt for the power measurements, because of its 12 CT capability and 3-phase support, so I don’t need any other CT sensors.

Thanks!
Franck

2

I am not aware of one. The problem is, the ATMega 328P that we use has only two interrupt inputs that can easily be used for pulse counting, and one of those is needed if you have a radio; therefore, only one is free to use as a pulse input.

If you have (say) 5 separate pulse inputs that you must record, I think it would be possible if you have (say) an Arduino Uno with 5 digital inputs plus an interrupt input, if you added some hardware logic. You would need to feed each pulse source into a digital input, and in parallel into a 5-input ‘OR’ gate that would generate an interrupt input whenever a pulse was present. The interrupt service routine would need to determine which pulse or pulses generated the interrupt, and increment the appropriate counter.

If you have any questions that are only about the operation and use of IoTaWatt, I suggest The IoTaWatt forum is a better place to ask. That is managed by Bob Lemaire, its creator, and he and the other users there are more likely to have the specific knowledge to help you.

3

Thanks Robert,

I am aware of the interrupt limitation, so I would probably dedicate a pro mini to pulse detection using a tight loop. My problem is the enclosing, power supply, and Ethernet connectivity… though I am beginning to think that I may be better off keeping the electronics out of the panel.

Is there an official Ethernet or RFM69 emonCMS client available? A quick search yielded some 3rd-party projects but I couldn’t find anything obvious on the open energy monitor site itself?

Thanks!
Franck

4

Without there being a packaged solution, another option might be to make a hat for the emonBase, and somehow wire the pulse outputs to the RPi GPIO, to be read by a script on interrupt rising-edge. Worked fine for me with the optical sensors, but can’t say say for sure on your devices as I don’t know how how fast the pulses are.

I recently got this type of module working on an Uno. The W5100 are supported officially by Arduino which I found helpful as the library was already available for their shields. The ENC28J60 ethernet module is also an option but will be trickier to get working.

One way I guess would be to have an Arduino reading digital inputs (non-interrupt based if it’s dedicated) then quickly transmit serial data every so often to an ethernet-dedicated Arduino or the emonBase.

5

I have a small RFM69 network already, so if I build this myself I will go with what I know, much easier :slight_smile: And I would prefer to not hack the emonBase which I see as th brain of the system (I will also need to feed it with the utility meter tele-information).

So to speak to emonCMS the best option is to extract the code from the emonTX GitHub? I’ll start looking for protocol docs…

Thanks for the help!
Franck

1 Like
6

These might help:

https://wiki.openenergymonitor.org/index.php/EmonTx_V3.4
and

7

Thanks, this helps! I also find this page:
https://learn.openenergymonitor.org/electricity-monitoring/networking/sending-data-between-nodes-rfm

… however I am still struggling to determine if I can achieve what I want with emoonBase and emonCMS.

Apparently the base (through RFM69Pi) interprets the payload based on the node ID of the sender… so if I create a custom node that sends 3 streams of pulse data (e.g. water, fuel, and one 3-phase meter outputs), then I would need to modify the server code to handle the payload?
Unless I can instantiates 3 RFM69 clients to emulate three virtual nodes?

Also, if I send up pulse counts, can emonBase accumulate them and keep track of the total consumption over time?

I have a similar question about my utility meter’s data: I will receive things such as total consumption in Watts for 2 tarifs (night/day), instantaneous consumption for each phase, production indexes per phase… is that something I can easily store in the emonBase and visualize through emonCMS?

Franck

8

You would need to define (or redefine) the Node in emonHub to correctly interpret the numbers that you send. emonCMS would then accept those numbers and you would then use them as you wish.

Say your new NodeID is 3, and you send each pulse count as an unsigned long integer, you would have

[[3]]
    nodename = Franck
    [[[rx]]]
        names = waterpulsecount, fuelpulsecount, 3-phasepulsecount
        datacodes =L, L, L
        scales = 1,1,1
        units = p,p,p

I believe it can, but we now favour accumulating the pulse count at source. Hence we use an unsigned long integer that is able to hold a very large number.

Yes, if you send that data and store it as Feeds.

9

Thanks Robert for all the help, I had missed the emonHub config piece, that should do it.

I will keep digging :slight_smile:
Franck

10

I have ordered an emonBase, and I am working on the pulse counter node :slight_smile:

Hmmm, that would require persistence at the node level, right? Right now I have a single pro mini with an rfm69 module that can count pulses and forward them to emonBase.
Not sure how I would track a running counter, I would rather not add an SD card - plus if the card fails my counter is back t zero…

I was looking at emonCMS as being my reliable persistent datastore (w/ backups to handle SD failures), I would rather keep the nodes as dumb as possible to keep the custom projects simple.
Hopefully I can use something similar to the kwhinc_to_kwhd2 input processor in emonCMS to create the ever-increasing water index from incoming pulse ticks.

Franck

[Edit]: Just found this in the RFM69Pi docs, looks like the problem has been taken care of:

> To record the total accumulated pulse count in emoncms use the wh_accumulator input process which detects resets continuing the total pulse count accumulation from the last value before the reset.

11

I received the emonBase, and I have a small prototype of what I called an “emonMeter” (pro mini + rfm69 + 6 meter inputs) successfully talking to the base… I have even seen some sensible meter inputs for a while, but not anymore.

A few questions:

  • emonHub is picking up loads of traffic from other rfm69 radios in the house - even though those are not on the “210” “group” (the equivalent of networkId in the Low Power lab library I assume?).
    Is there any way to tune that out? Is the problem that the LowPower lab library encodes packets differently so that the rfm69Pi is unable to filter them out?

  • I started using node 5 for my custom node, then switched to using node 10 out of concern that I would conflict with the emonBase itself… any recommended choice? The node will report water, fuel, and electricity indexes from pulse meters.

  • … and finally even though things worked before I am now stuck with emonHub rejecting most of my paquets… but not all of them. Here is the config:

[[10]]
nodename = emonmeter
[[[rx]]]
names = fuel,foo1,water,foo2,foo3,foo4,foo5,foo6
datacodes = L,L,L,L,L,L,L,L
scales = 1,1,1,1,1,1,1,1
units = ml,W,l,V,C,C,C,C,C,C,p

and here are a few log message:

Discarding RX frame ‘unreliable content’? 10 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 (-30)
7 NEW FRAME : OK 10 0 0 0 0 0 0 0 0 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-30)
Discarding RX frame ‘unreliable content’? 10 0 0 0 0 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 (-29)

The sending code is pretty basic:

unsigned long counters[8] = {0L,0L,0L,0L,0L,0L,0L,0L};

rf12_sendNow(0u, counters, sizeof(counters));
rf12_sendWait(0);

Am I doing something obviously wrong? Is the emonHub log format documented somewhere?

Thanks!
Franck

12

Some initial timings btw, using a pro mini 3.3V at 8mHz I can take 6 pulse readings in under 0.1ms.
The radio send however takes about 9ms, which should still work for a 20ms pulse but may well miss 10ms pulses.

I have ordered a couple 3.3V 16mHz boards, hopefully that will help. I also seem to remember 3-4ms send times with the LowPower Lab library, so I may need to look into that.

The goal was to keep everything on a single board…

Franck

13

Switching to packets of 4 unsigned longs makes the problem go away, so the problem has to do with packet size / timing.

Otherwise changing the send code to call sendWait (probably not even needed since the last packet will be long gone) before sendNow yields 3ms per send, which should be safe for 10ms pulses :slight_smile:

Franck

14

I have no knowledge of the workings of the low power library, so I cannot comment on that. However, I do know that it does not use the same protocol as JeeLib.
“Group” is a software selection of messages after they have been received. All transmissions take place on a common channel, so it is not possible to “tune” for a specific group.

I recommend you stay with our default node IDs. The only reason for this is, if you update your emonBase, the RFM69 firmware will be updated automatically also. You will save a lot of confusion when asking for help if you do use our default Node IDs.

You have too many units specified. There should be 8, to correspond with the numbers of names, datacodes and scales. At some point, that will confuse someone.

Formally? not that I’m aware of. “unreliable content” normally means a checksum error, which might be due to another transmitter on the same frequency scrambling the data.

I in effect had the same problem with the 3-phase sketch, in that the processor was too busy to pass one character at a time as JeeLib requires. I solved it by rewriting the transmit part of JeeLib to use the internal buffer of the RFM69 (which the earlier RFM12B, for which JeeLib was written, does not have). So the likely reason for the corrupted message was, the processor went away to do other things, and the data stream to the RFM69 paused, and the break meant it could not be decoded.

15

Got it, I was expecting the JeeLib to filter the messages from other groups though, since the group ID is part of the preamble and decoded by JeeLib. I guess the rfm69Pi is not configured that way.

I definitely don’t want that, but which “default” node ID do you recommend since I am creating a custom node? Should I pick something in the 11-14 “Unassigned” range? I tried 5-10 since those are described as “energy monitoring nodes” in this document:
https://learn.openenergymonitor.org/electricity-monitoring/networking/sending-data-between-nodes-rfm

Good catch, thanks!

Makes sense, looks like I’ll have to look into some low-level RFM69 programming if I want to go beyond 4 meters then…

Thanks!
Franck

16

15 - 18 and 27 - 30 are, as far as I know, not presently specified. Node 5 is the emonPi, and that conflicts with the list in ‘Learn’ that you linked to, which I believe hasn’t been updated to reflect current practice.

We (the moderators) don’t necessarily get told when changes like that are made, the version of emonhub.conf that I have specifies these:

5 – emonpi
6 – emontxshield
7 - 10 – emontx4 - emontx1
11 - 14 – emonTx 3-phase1 - emonTx 3-phase4
19 - 26 – emonth1 - emonth8

You can lift it out of the 3-phase sketch. You can have 56 bytes of payload. (If I remember correctly - look at the documentation / comments.)

17

My “emonMeter” is up and running, thanks for your help with my questions!

If there is interest I can provide the details, the pro mini can read up to 6 time or pulse inputs and forwards them to emonHub by radio.
“Time input” can be used to monitor how long any appliance has been ON, the node converts elapsed time to pulses:

// Fuel at 2.27125 L/h, 1 pulse / ml
TimeMeter fuelMeter = TimeMeter(0, 2271, 3600);

image

Franck

1 Like
18

In case someone ends up here after a search, my RFM69 problems came from a bad version of the JeeLib library, see this thread:

https://community.openenergymonitor.org/t/unreliable-content-with-rfm69c-and-emonbase/9805

Franck