I am thinking about the possibly of using the TX and Wi-Fi combination to monitor the generation and use of solar/grid power. If I understand the config menu correctly for the TX, it looks like you can point it to either emoncms.org, or to a local version hosted on your PC.
Is there a way to feed the data to both emoncms.org and our PC (Linux Mint 17.1 Cinnamon 64-bit in my case) at the same time? The reason I need to query this is because loss of internet connection is not an uncommon event. So to be able to save data locally could help negate this issue. However, this obviously then raises the big question of how to synchronise the data later when both records become available again.
To compound things further, power outages are not unknown. So would the Tx loose its data if power is lost? If not, for how long does the Tx save its data?
Any feedback will be appreciated, but please bear in mind that I am mechanical engineer of senior years with a limited/basic understanding of both computers and electronics. Finally, I apologise if my searching has missed any references that deal with the above, so a pointer in the right direction would be satisfactory.
yes you can send data to several servers, locally and/or remotely.
Just edit the emonhub config
look for the code that is standard in there to send to emoncms.org, copy/paste it and adapt.
In my case I did as follows to send it to my server and to emoncms.org
The emonTx does not have any local storage for data. So when power dies, data isn’t generated, or when the network connection is broken further upstream, the data is lost in transit.
I think Eric is assuming that you’ll either have an emonPi, or an emonBase, as well as your emonESP (which is what we call the emonTx with the Wi-Fi module attached).
EmonBase and emonPi are of the same lineage: based on a Raspberry Pi, both run emonCMS (the software) and emonhub; and both can send data forwards to emoncms.org (the web-based version of emonCMS) as well as store it locally. Where they differ is the emonPi has one voltage and two current inputs (so it’s got a cut-down emonTx inside the case).
So as you’re in the UK, and presumably have a single-phase supply, you might want the emonPi instead of the emonESP + emonBase combination.
We don’t have any software that will allow you to merge the two databases, unfortunately.
Thank you both for replying to my list of queries. Yes, we are on a single-phase supply and have a 4kW PV system installed.
I was considering the emonESP because it does not have the two current sensor input restriction of the emonPi. As our solar system can divert power to heat water, I was hoping to monitor the Immersun unit as well. I would then be able to find out how much of the daily consumed solar energy goes into heating water. The 4.5kW input channel on the emonESP also appeared to be ideal for this task.
From your responses, without some independent power supply backup, any intermittent internet and power outage situations would disrupt the monitoring process on the openenergy range of products.
And so to my next question. Is there an intention to provide a continuous power feature along with data storage on an openenergy product in the future?
Having looked again at my last reply it would appear that I did not explain myself very well, so please let me try again.
I initially considered the emonPi to monitor our solar production and usage. Because of the two CT input limit it was not possible to collect information regarding the Immersun unit.
I therefore had a look at the alternative Sensor Nodes to find one with more CT inputs and thought the emonTx might be suitable. Because I do not understanding the internal workings of these units I started asking questions. I now understand that the emonTx is also not suitable, but for different reasons.
So perhaps my last question should have been along the lines of – Is there or is there likely to be a unit that will have the characteristics of the emonPi and also have three or more inputs for CTs?
Hopefully, if I have now explained things a bit better.
Indeed they are, thanks. It’s a recurring problem here - people often forget that there are many things we can assume or infer, but unfortunately not all bases can be covered by that. Hence occasionally we have to rejuvenate the ‘I’m not a mindreader’ cartoon.
That I can’t answer. There’s a unit being developed by someone that I understand might be sold through the shop, but I’m unaware of the details. Whether it has any storage or significant processing power on board, I haven’t a clue.
Staying with the OEM/Megni products, your solution would be to pair an emonTx with a Raspberry Pi, connected serially (i.e. not even an emonBase unless you require the radio link). The downside is you’d have several boxes or you’d need to engineer a housing. The emonTx would give you 4 current, 1 voltage and one pulse input, the Pi would give you local emonCMS and WiFi access via your router to your computer and to emoncms.org.
The remaining downside is, I’m not aware of a way to merge the databases (local and remote) following a network drop-out, unless you write your own software to do that. It would be tedious, but as the database format was invented by Trystan and it’s documented, it shouldn’t be impossible.
Unfortunately, space is a problem for using the emonPi + emonTx combination. So I will wait to see what happens regarding the possible future development you hinted at. Thanks for your help and patience.
Working with OEM to make IotaWatt available. Iotawatt provides 14 monitoring channels, maintains all of the data on a local SDcard, will upload the data backlog after a wifi outage, and has a local LAN web server that can provide current status as well as serve a version of the OEM graph application to look view the locally stored data. It doesn’t have battery backup except for the real time clock but restarts after a power failure in a couple of seconds. There’s an extensive thread on this forum if you search for iotawatt.
Timeframe for general availability is several months.
Thanks for the correction – I’ve had closer look at this possible alterative. Although I understand the meaning of serial connection, how would ‘connected serially’ be carried out between the RaspberryPi and emonTx pcbs if not using a radio link?
They both have a UART, you simply connect Gnd to Gnd, Tx to Tx and Rx to Rx… voila, instant serial connection.
From the emonTx wiki article: Note: on the PCB and schematic, the Tx and Rx pins are labelled according to the connections on the Programmer, meaning that data is received by the emonTx on the Tx pin, and transmitted by the emonTx from the Rx pin.
Or, to put it another way, exactly as it is done inside the emonPi.
(Caution, the emonTx serial data lines are not labelled conventionally, so as @Greebo says, you connect Tx to Tx and Rx to Rx.)
I’ve recently managed to read up some of the background information regarding this option. Your comment on GitHub - boblemaire/IoTaWatt: IoTaWatt Open WiFi Electric Energy Monitor of ‘There is also ongoing development to adapt the ESP32’ is noted. So does this mean that the ESP32 will be in the final solution of the iotaWatt?
