The requirement is monitor the electricity demand in a three phase supply and save data at 1 minute intervals to a database. The reason for doing this is to be able to show whether or not demand ever exceeds the 300 amp supply.
From other posts in this forum I presume I could use an emontx5 with 3 sensors, one on each phase, in the suppply cabinet, which would communicate with an emonBase located inside the building next to an ethernet port on the internal network. These could then be configured to read and save the demand in amps.
The question is how could I then save the data to an existing mysql database on a UNIX server located on the same network?
Once the data were saved to the external mysql database, I could then write a program to generate a report and send it out as an email. This would be run on the UNIX server as a cron job scheduled to run at monthly intervals.
As far as I can see, I have no obvious requirement to use the emoncms app unless it is essential to implement what I want to do.
Any help would be most appreciated.
Where is the supply cabinet located in relation to your Ethernet port - is it within range for a USB cable, or RS485? And what material is the cabinet?
My thinking is if the cabinet is steel, the ability for a 433 MHz signal to get out is limited, so you might need an external aerial with all the attendant problems.
What is your criterion for not exceeding the 300 A - is it thermal, maximum demand or what? In other words, what is the averaging time you want for the measurement? It need not be the same as the reporting interval.
Your emonTx5 can be set up to record the 1 minute average current (per phase of course) and report it in whatever format you require - assuming you or somebody at your place has a basic knowledge of C programming, and with a USB / RS485 to Ethernet adapter at your Ethernet port, the data would go straight into your database via a service which you’d need to write and then there’s no need for an emonBase. With a bit more programming in the emonTx5, you could customise it to record (say) the maximum 1 second average over the last minute and report that. It will handle 0.5 s averaging but no faster, if whatever is receiving the data can handle it.
The c.t’s are standard 0.333 V devices so 300 A or 500 A versions are readily available.
Hopefully it’s a silly question - what’s the voltage in the supply cabinet, and is a normal domestic 120 - 240 V available to power the emonTx5 and its emonVs (if you have that, it’s not necessary if you don’t need active power measurement, but having a voltage will allow you to use the later emonLibDB software. It can be powered at 5 V via the USB serial data connector.
Thanks Robert.
I propose to record 1 minute average demand on each phase. From your comments this may be computed from the 1 second averages recorded by emonTx5
From your comments it appears the principal disadvantage of having separate emonTx5 and emonBase devices is the possibility of having difficulties with the 433 MHz comms. In my case I find this unlikely as the electricity supply cabinet is plastic and the distance to the ethernet socket only 3 meters. This layout would be convenient as I would then not need to run any sort of comms cable to the external supply cabinet. The 230 volt power supply for the emonTx5 can be taken from the distribution board in an adjoining external cabinet.
I understand now that I should be able to write a program to run on the emonBase to compute 1 minute average demand per phase in amps and save the data to an external database. Is there any documentation which might help me get started with this task? I am familiar with C and UNIX programming which as I understand is what Raspberry Pi OS is based on. So what I need to know is what specific libraries and/or data structures should I access to get at the data recorded by the emon devices.
Of course, I had absolutely no idea that this would be the case.
If you only want 1 minute averages, there’s no need for that, you can have the 1 minute average directly. By default, the emonTx5 (and the library that does the work) reports every 10 s approx (actually a bit less, 9.8 s, because of the way emonCMS works), but it’s a simple configuration change to report every minute exactly (timed off the 50 Hz mains). With a bit of programming - uncommenting a line or two - the current can also (or instead) be reported. We package the data in a fixed, binary format - but as you’re not going to be using emonHub and emonCMS, you can choose whatever format you like. There a limit on the buffer size, but it’s unlikely to worry you with only 3 currents to send.
You’ll find all the information you need for this in the source code for the sketch and in the documentation for emonLibDB, which is part of the zip file download for the library.
I’m unsure what you need for the emonBase - the RFM69CW handles the reception and decoding of the data (and the Hope data sheet is your source for that), all you have to do is poll the module to see if a data packet has been received, then retrieve the data from the buffer and parse the values out. And to see how to do this, look at the sketch that runs in the emonPiCM. What happens then inside the emonPi - and by inference in the service you’ll need to write to replace emonCMS, I’m totally ignorant of because it’s not documented in detail anywhere and I’ve never had the need to find out. But the important thing is, it will be driven primarily by the arrival of the data, but a major influence must be the way you structure and use the database.
EmonCMS uses two types of database: Fixed Interval Time Series - where the metadata stores the start time and data interval, then data is written into fixed records depending on the time elapsed; and Variable Interval Time Series, where the time and the data form part of and are written into the same record. We almost invariably use Fixed Interval for power and energy data, but the snag is, mains time can drift in relation to Internet time, hence the data is sent slightly faster (9.8 s) than the database (10 s) so that null records are avoided, at the cost of an overwritten record occasionally.
It’s done this way because the original emonTx was battery powered. At some point in the future for mains-powered sensors, we might move to the sensor sending data on demand - which is OK if mains power is available because the sensor must listen all the time for its command to send the data, that’s not practical with dry cells as the power source. Then the timing problem disappears.
And don’t forget the Docs section here. There’s an awful lot of information there, so if you need a steer to where to look, ask.