Hi,
Yesterday I was handed a Pi, an SD Card and an RPICT3T1
(RPICT3T1 - lechacal)
I’ve connected the RPICT3T1 to the Pi, imaged the SD with EmonPI and got it all started up and connected to the web interface.
I just need a few pointers as to how to get EmonPI to see the inputs for the CT Clamps on the RPICT3T1.
Thanks
Mark.
Welcome, Mark, to the OEM forum.
Does this imply it’s work? 
Most of us here use the emonPi - which isn’t what you have. The emonPi is hardware - a Raspberry Pi with our own analogue “emon” front end, effectively a 2-channel emonTx, and a display all in an aluminium case. The custom software, written in PHP, is in two parts: emonHub handles the serial data input and emonCMS does the data processing, databases and web page generation. Both those plus the operating system comes as a download image to write to the SD card with (say) Balena Etcher, or you can buy the SD card ready flashed.
This page http://lechacal.com/wiki/index.php?title=Raspberrypi_Current_and_Temperature_Sensor_Adaptor says that the Hat you have sends its data via the serial port of the RPi, which is exactly the same as the true emonPi. Therefore, if your RPICT3T1 is doing as it should, the data will automatically appear on the Inputs page of emonCMS.
I know nothing about your RPICT3T1, but my guess is, it either isn’t sending anything at all, or it’s sending it at the wrong baud rate, or you haven’t copied the configuration for your RPICT3T1 into the emonhub.conf file. This is immediately beneath the heading “Emoncms Config (Emonhub)” [It’s not Emoncms Config.] If there is already a Node 11 (Identified by **[[11]]**0, delete it. You can edit emonhub.conf directly in emonCMS using your web browser (Setup →Emonhub →Edit config).
Is the anything in the emonhub log indicating that data is being received? (Setup →Emonhub →View log). You should see new data appear every 10 s or so - depending of course on the software inside your RPICT3T1.
Note that with the RPICT3T1 you are not measuring the voltage, so you are only getting an estimate of apparent power, which could be markedly different to the real power that your supplier’s meter reads.
If LeChacal wishes to send me a RPICT3T1 and a RPICT3V1, I might be able to help you a little more.
@CSUK if you have solar PV, that unit won’t be worth the PCB it’s printed on, as @Robert.Wall says, it has no voltage measuring. The “240V mains voltage” can vary a lot. Mine regularly wanders from 232V to 252V, with that swing your power readings are going to be all over the place.
Over the last 7 days, mine isn’t quite so bad, 230.6 V to 245.5 V, and I don’t have PV. Add to that what happens when the power factor of the load wanders away from unity…
(Which is why I used “markedly”.)
Yes, the PV causes good rises in the voltage, and 9:30pm when Octopus’s Go Faster tariff off-peak kicks in, and the car charger starts, the washing machine and dishwasher start, the voltage plummets.
Have you calculated the fault level of your supply? From what you write, it sounds as if it’s quite low.
From memory, mine is around 350 - 400 kVA.
No, how would I do that?
Measure the volt drop, given a known load. It’s Ohm’s Law, just in a different guise.
Hi Robert,
You are quite right it is work
This was all put together by a colleague who has since left, it is sans any kind of documentation - and the SD Card died - so I’m trying to get to grips with it.
I did use Balena Etcher to put the current version of EmonCMS on a brand new 16GB SDCard.
I do see inputs, and readings - I did have a dig around in the emonhub.conf, but I suspect my mistake was not removing the old [[11]] entry (I simply renamed it [[99]]
I do see the inputs in the inputs list , but I am also seeing a lot of rogue entries in the list - should I remove everything from the emonhub.conf other than the [[11]] ?
I’ll pass on the notes abount the voltage measurement to the boss.
Thanks again for the information - I’ll keep ‘fiddling’ and come back if I get stuck again 
Mark.
Yes, you can remove the other entries in emonhub.conf - the data coming in will still appear in the emonhub log (renaming it to 99 should have been fine, as should be leaving all the other entries you don’t need), and you can delete unwanted inputs - in fact all inputs on the Inputs page if you wish, the active ones will reappear as soon as data arrives (you don’t - can’t “create” an input on the Inputs page).
A quick run-down:
The Inputs page is where you scale, add, accumulate the data. There are many input “processes” accessed via the spanner icon for each input and the data flows down the list top to bottom, sometimes changed, sometimes not. “Log to feed” is where the data enters the database. If it isn’t logged to a feed, it evaporates.
Once in a Feed, you can access and graph the data, or show it on a dashboard that you assemble yourself by dropping dials, graphs or text onto the screen and then setting up the data source (the feed), scale etc for each.
Where are you seeing the rogue data? If it’s in the emonhub log, it can only be that your analogue hat is sending “helpful” data via the serial port - it should not do this, it should only send measurements in the published format.
If it’s on the Inputs page, it is likely to have been your predecessor 
and all those can safely be deleted. The other way is if another device on your LAN is sending to the RPi’s address - but then the data again has to be sent to the right place in a format that’s recognisable.
In my opinion, that’s the best way to learn. Don’t hesitate to come back and ask. I’m not an expert on the finer points of emonCMS, but there are plenty here ready to help.
I take it you’ve found the Guide here? (Yes, I know it can be hard to find what you need - even I struggle from time to time.)
I’m an inveterate fiddler 
Despite clearing out the inputs page - I keep getting other inputs showing up - the RPICT3T1 has only 4 inputs (3 power and 1 temp).
I remove them and they eventually come back again.
I have this under interfacers in the EmonHub Config
[[SerialDirect]]
Type = EmonHubSerialInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0 # or /dev/ttyAMA0 or/dev/ttyACM0 etc
com_baud = 38400 # to match the baud of the connected device
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
is that likely to be causing some duplication or ‘interference’?
I did see the guide and did have a look - I’m happier I’ve got something of a handle on whats happening (initial ‘it’s Linux!!’ panic is subsiding now so I’ll have a thorough read.
Thanks
“1611” I would think is either some data that’s been mis-interpreted, or spurious output from the hat.
I’d need to know exactly what the hat is sending to be able to know exactly what’s going on, but when I look at at the web page for your device, it wasn’t exactly very specific.
Take the config file entry:
[[11]]
nodename = RPICT1T1
firmware = RPICT3T1_V1_1.ino
hardware = RPICT3T1
[[[rx]]]
names = Power1,Power2,Power3,Temperature
datacode = 0
scales = 1,1,1,1
units = W,W,W,C
The format of the data received by the Python demo script indicates that you do indeed need the Serial Interfacer.
datacode = 0 means “no decoding - expect plain human-readable text” and it leaves the door wide open to any data coming in. That’s probably where inputs 5, 6, 7… are coming from, and that indicates to me that it’s sending rather more than it says it does.
I’m not sure whether the JeeInterfacer will try to interact - I think it won’t - but you could comment that out. If it sees a byte stream that happens to fit one of its definitions, then it might create extra inputs, although I’ve never seen it happen. (This is where my detailed knowledge of emonHub is lacking.)
But whatever, you can just ignore the extra inputs. If there’s no “Log to feed”, they evaporate.
It would be quite useful if you could supply details of the serial output from the hat.
Can we see the data in the Emonhub.log?