EmonTx v3.2 and UK 3 phase supply

ian · 2017-05-21T14:35:27.603Z

Hi

I have an EmonTx v3.2 that I purchased a while back. I now wish to set up monitoring. Our building is mixed industrial and domestic and for historical reasons was built with a 3 phase supply. We now only have one machine powered by 3 phase and that is rarely used. At this stage I have not established how the three phases are distributed in the single phase parts of the building which has a single distribution board for all electrical circuits.

I found the wiki:-

https://wiki.openenergymonitor.org/index.php/EmonTx_V3#emonTx_V3.2

All links pointing to github seem to 404.

I assume at this stage I will need emonTxV3_3Phase_Voltage sketch. Where can I find it?

Regards

Ian

Robert.Wall · 2017-05-21T14:47:23.285Z

On Github!
The 3-phase sketch is common to all emonTx versions (you configure it before you load it) and it has its own section on the second page of [OpenEnergyMonitor · GitHub] (OpenEnergyMonitor · GitHub).

ian:

All links pointing to github seem to 404.

No, only 5 out of 6 (that I counted)! @gwil or @glyn.hudson please note.

Bill.Thomson · 2017-05-21T18:44:37.879Z

ian:

At this stage I have not established how the three phases are distributed in the single phase parts of the building which has a single distribution board for all electrical circuits.

Sounds like he’s going to be monitoring a single phase, unless he’s speaking of the 3-phase machine he says is rarely used. Maybe some clarification is needed?

Robert.Wall · 2017-05-21T19:35:53.569Z

Sounds like he wants to monitor the incoming supply to me. It’s quite normal here to use one phase per section of a building, or per floor. If it was principally industrial use, then it’s quite likely that the original “domestic” part - offices and suchlike, were all on just one phase, as the energy use would be small compared to the big machines. Reading between the lines, it sounds as if part of the building has been converted for domestic use, so that section might well all be on one (different) phase.

ian · 2017-05-22T11:59:38.912Z

Many thanks Robert

I have downloaded the 3 phase sketch. I have one puzzle. I had to define RFM12B as that is the radio module I have. I also changed the node number.

The sketch compiles and appears to be working fine.

This is part of the serial log:-

                                          emonTx V3.2 & V3.4 CT1234 Voltage 3 Phase example

Using RFM12B Radio
OpenEnergyMonitor.org
Node: 21 Freq: 433MHz Network: 210
No temperature sensor
Voltage: 244.05
Phase 1: 0.26 A, -2.28 W, 63.61 VA, PF=-0.036
Phase 2: 0.06 A, 0.54 W, 14.00 VA, PF=0.039
Phase 3: 0.21 A, 1.48 W, 51.91 VA, PF=0.029
Input 4: 0.00 A, 0.00 W, 0.00 VA, PF=nan

Pulses=0

The puzzle is that I am not seeing inputs posting on my local emoncms. Have I missed a setting?

If I install my original standard sketch on the emonTx, same node and group I see inputs posting.

With regard to the building it was built new as multi use. There are also several external buildings also with 1 phase spurs from the main building. I want to monitor incoming supply initially to see which phases are consuming power. We are hoping to fit a single phase PV system and powerwall type unit (if this is even possible) to the phase supplying the domestic part.

If the 3 phase sketch is not the best way to go I would appreciate any thoughts.

Regards

Ian

Robert.Wall · 2017-05-22T12:45:47.024Z

Have you got the node definition for Node 21 correct in emonhub.conf ? It must match exactly the data sent by your sketch, otherwise it will be ignored. The correct definition appears to be in the comment at the top of the sketch - unless somebody has changed it.

You must have only one definition of Node 21 in the file. As Node 21 is pre-defined in emonhub.conf as an emonTH, I think I can guarantee why it isn’t working. Delete that Node 21 and replace it with the one in the comments, and it should work.

The specifiation for emonhub.conf is in emonhub/configuration.md at emon-pi · openenergymonitor/emonhub · GitHub

ian · 2017-05-22T13:24:54.463Z

I don’t use emonhub. All my other emonTx transmit to NanodeRF base stations which in turn publish via the internet to my local Pi based emoncms server. Does that mean the 3 phase sketch as written will not work in my setup?

Robert.Wall · 2017-05-22T16:02:30.624Z

Which sketch are you running on your NanodeRF?
Are you certain you’re not using emonhub on your Pi?

ian · 2017-05-22T16:51:09.489Z

Sketch on Nanode is NanodeRF_multinode.ino

I am certain I am not using emonhub. Only entries in emonhub.log show:-
INFO MQTT Connecting to MQTT Server

I am sure in the past I discussed using emonhub with @pb66 but if I remember correctly it would not handle the fact that I have 2 Nanodes posting data. Private messages were on old forum so I cannot confirm.

What I find really puzzling is If I use emonTxV3_RFM12B_DiscreteSampling.ino the inputs are showing as I expected.

pb66 · 2017-05-22T17:40:25.454Z

Sorry Ian, although I vividly recall you were using NanodeRF’s and not emonHub, I cannot recall the exact detailed reason without some back reading on the old forum which is no easy task now.

I am not familiar with the way NanodeRF works so I’m not much help to you with the issue you have. But since you are sending data over the RFM network to the NanodeRF I see no reason why the 2 sketches get different results, unless you are using a custom group ID and not changed it in the new 3ph sketch.

Robert.Wall · 2017-05-22T21:49:19.962Z

That Nanode sketch assumes the data is integers (16-bit words), so it will split the pulse count into two values. But other than that, it ought to handle it correctly. If you’re not going to use the pulse count, you could remove it from the data structure (and the assignment to emontx.pulseCount obviously).

Paul - it reads the receive buffer as bytes, converts adjacent pairs of bytes to signed integers and sends them as json/csv :

str.print(basedir); str.print("/api/post.json?");
str.print("apikey="); str.print(apikey);
str.print("&node=");  str.print(node_id);
str.print("&csv=");
for (byte i=0; i<n; i+=2)
{
  int num = ((unsigned char)rf12_data[i+1] << 8 | (unsigned char)rf12_data[i]);
  if (i) str.print(",");
  str.print(num);
}

str.print("\0");  //  End of json string

(The “Discrete Sampling” sketch sends the pulse count as a signed integer.)

You have picked up all the '#define … ’ settings? The last one you need to look at is
#define PHASE3 18

pb66 · 2017-05-22T23:51:49.524Z

Robert.Wall:

Paul - it reads the receive buffer as bytes, converts adjacent pairs of bytes to signed integers and sends them as json/csv :

That’s all pretty standard, nothing stands out as being handled differently for the 2 sketches.

Robert.Wall:

(The “Discrete Sampling” sketch sends the pulse count as a signed integer.)

That shouldn’t create an issue (especially if not used) you can use the signed to unsigned process and just use the 2 LSB’s, it will roll over just the same. Or use the signed to unsigned process then multiply the 2 MSB’s by 65536 and add to the 2 LSB’s to reconstitute the unsigned long fully.

Is there any led to flash on the NanodeRF? or can it be hooked up to get some debug serial output?

@ian - have you changed line 133 #define RFMSELPIN 10 to #define RFMSELPIN 4 and line 185 #define RFMIRQPIN 2 to #define RFMIRQPIN 3 ?

You should also change line 135 from #define PULSEPIN 3 to #define PULSEPIN 2 and therefore line 134 from #define PULSEINT 1 to #define PULSEINT 0. Even if you are not using pulsecount it would be wise to change these to avoid pin conflicts when using the “RFu” spi pins.

ian · 2017-05-23T10:07:43.034Z

Hi

Many thanks @pb66 !
I had not changed the RFM defines. Missed that when I went through the sketch.
Just changed them and inputs showing, 13 of them!

Regards

Ian

Robert.Wall · 2017-05-23T10:47:58.988Z

Robert.Wall:

(you configure it before you load it)

I did warn you it was the same sketch for all versions, and needed to be configured.

ian · 2017-05-25T09:40:20.789Z

Thanks to all the help in this thread I have now got this set up, connected and running. Not yet calibrated which I should do over the weekend.

I have had one small issue. I was powering from the AC adaptor. After it had been running for about an hour I noticed the update time on the inputs started getting longer and longer and eventually it stopped updating completely. This morning I switched to a separate 5 volt DC supply and the longest update time I have seen is 30 seconds. Only having a RFM12B I don’t see the radio signal strength. Sometimes it seems to update every 12 seconds. I am guessing I might be on the limits of the radio. The Nanode is in a different building and there is a stone wall, a wooden wall, a Caravan and a Van between them line of sight.

One thing that surprised me is the power used by the fluorescent lights in the workshop and also the fact that they are on different phases. As the tubes need replacing any way I shall have a look at LED fittings.

I have one question on the CTs which are the shop supplied SCT-013. Up to now I have been unclipping them from the cables before unplugging them from the EmonTx. In the Learn section it states these have Zener diodes. Does this mean it is safe to plug and unplug them from the EmonTx while they are clipped on the supply cable?

Robert.Wall · 2017-05-25T11:51:42.825Z

ian:

The Nanode is in a different building and there is a stone wall, a wooden wall, a Caravan and a Van between them line of sight.

Ouch! The wooden wall isn’t much of a worry, but the stone wall, and two metal ( ? ) vehicles must be a pretty effective barrier to radio. So you’re probably right. It’s struggling to get a usable signal. Is it possible to move one or both vehicles just to test? That would be my approach.

ian:

Does this mean it is safe to plug and unplug them from the EmonTx while they are clipped on the supply cable?

No, it means it should be safe, but however slight the risk, is it worth it?

Bill.Thomson · 2017-05-25T15:07:26.177Z

ian:

a Caravan and a Van between them line of sight.

The vehicles may be causing a multipath problem. I say may, because it’s somewhat doubtful that multipath is to blame. The easiest way to eliminate that as an issue would be to move either radio (emonTx or Nanode) to see if it changes anything. It may not require much change in position to make a difference if multipath is indeed, the problem.