OpenEnergyMonitor goals February 2018

Organisation
,
#1

Please see OpenEnergyMonitor Development Plan Outline - #3 for the latest development plan (November 2018).

Posted February 2018:

Its been a while since we published a list of our development goals and an overview of what we are working on. I’m aware its a question that a number of people have asked and so we wanted to give a bit more transparency. We have already discussed the following with forum moderators and a number of other core contributors and have made a number of amendments, thankyou to all who have given input so far.

If you would like to give feedback on the following feel free to reply below or send us a PM.

OpenEnergyMonitor goals 2018/2019

OpenEVSE integration: Growing out of our interest in electric vehicles we have developed an integration of the OpenEVSE open-source electric vehicle charging station with our solar pv monitoring system (working with Chris Howell lead developer of the OpenEvse project and Jeremy Poulter), making it possible to divert excess solar to charge an electric vehicle. We are working on a 7kW/22kW single/3-phase compatible type-2 (non-tethered) charger suitable for home & public charging stations with full certification. We have also become an OpenEVSE distributor for UK/EU. It is our intention to improve the emoncms support for the OpenEVSE including a apps module app that records energy use per charge, rather than kwh/d.

IotaWatt: Continue to work with Bob Lemaire to support IotaWatt as part of the OpenEnergyMonitor system: providing WiFi Connected 14 Channel Electricity Monitoring. Add IotaWatt to guide:system overview, update product pages on the shop to reflect CT operating range findings. Ensure historic upload of data to emoncms.org works ok.

EnergyLocal: Develop further ESP8266 based SonOff S20 smartplug and WIFI relay control: for use in demand side response whether solar diversion, time of use tariffs or renewable energy availability on the grid, this is a development that is coming out of our collaboration with EnergyLocal. The project so far has resulted in significant improvements to our ESP8266 firmware called EmonESP, the emoncms device module device-integration developments, wifi access point setup of the emonpi/emonbase, a new emoncms module called demandshaper which can be used to schedule appliances based on a day ahead power availability forecast and a focus on emonbase/emonpi bug testing especially for the phpmqtt_input process. The next steps include completing the release of the EmonESP software development, documenting how to use it, merging the device-integration work in the device module and documenting the use of the device module in conjunction with these control devices and the demandshaper for scheduling. We will be advertising soon for a development position to help us with this project, if your interested please get in touch.

Integrate heatpump monitor into the EmonTx V3: with a separate MBUS reader board and further work on the ESP8266 option for the EmonTx. Allowing lower cost installation where an emonbase or emonpi is not needed. Consider as part of any EmonTx v3 changes that may result from this wider suggestions from the community.

Emoncms billing and scale: emoncms.org has grown significantly over the past few years. Significant investment in server storage, processing and development time will be required in the coming years to continue scaling to meet demand. In the last 12 months the number of active users has grown from 2,400 to 3,500 and the number of active feeds from 28,000 to 38,000. We would like to add further storage servers, optimise the front end and input processing load to enable further scaling. We project emoncms.org costs to rise to £6k for servers and ~£32k for development and administration this year (including the addition of one dedicated full time emoncms.org developer). Our present proposal is to implement a pay-per-feed model with costs in the region of £1-2 per feed per year. For customers of OpenEnergyMonitor hardware, emoncms.org accounts will be automatically credited with credit based on a percentage of total order spend, e.g a full EmonPi costing £153 may result in £31 (20%) of emoncms.org credit providing 3-5 years of free use for 6 feeds. Exact feed cost have not yet been finalised, these figures above are likely to change over the coming months as we assess the impact of different costs. We realise that this is a significant change and that some expectation of service is assumed when buying a hardware product, we are also glad that for those where a payment model will not work, emoncms is open source software that can be self hosted, which is also something we encourage. All emonPi’s will continue to be shipped with Emoncms pre-installed of course, enabling easy local logging if required. Emoncms credit will be applied retrospectively for past OpenEnergyMonitor shop order spend.

emonHub: Work with Paul Burnell to bring emonhub development efforts together. Fix a number of issues in the emonpi variant in particular the emoncms interfacer buffering. Extend the documentation to give example use cases for all the different interfacers e.g recent socket interfacer discussion. Implement option to pass MQTT data from ESP devices through EmonHub and then on to a local emoncms installation so that emonhub can relay the data simultaneously to a remote server such as emoncms.org.

EmonLibCM: Work with Robert Wall to bring continuous monitoring support to the EmonTx, currently in testing.

Groups: Work with Carlos Alonso Gabizón of CarbonCoop on the integration of his groups module developments on to emoncms.org enabling multi-user administration, notifications and alarms.

LoRAWAN: Develop LoRaWAN RF support for our hardware units to enable easy wide area deployment using open The Things Network.

Thankyou for reading, we wish everyone well for the year ahead!

Trystan & Glyn

5 Likes
Emoncms.org billing
OpenEnergyMonitor 9th of March 2018 meeting summary
2018 Development Progress Update
#2

Trystan, Glyn,

Thanks for taking the time to give this update. As a user for some time, it’s always good to get an impression of where your thoughts are re developing the ecosytem.

Personally, I use the servers but don’t have to as I can access my own server when out and about, so I guess I would stop sending data through. For you guys though making the systems commercial is obviously important, so I hope you can find a suitable form of subscription which isn’t onerous on either side and also promotes the use of the services.

I was interested to read the thoughts on EmonESP. I’ve spent a week or two looking at code to replace my breadboard heatbank controller which has an ESP as the controller. I’d already decided to replace the system with a Sonoff 4 Ch but of course these use the integrated ESP chip so haven’t enough memory really to take the emonESP code, so I’m back to rolling my own which is a bit frustrating.

When you do start looking at this space, you should ensure firstly that the emonESP code will work with either the emonTX or emonTH (yes I know it’s meant to be battery powered but it doesn’t have to be and could take the emonESP to give WiFi rather than RF connectivity). Then I’d make sure that the code had a dummy control class with setup and loop calls, in this way it would make the software more adaptable for use as say a thermostat, or in my case a heatbank controller. (Mind you it still wouldn’t fit in a Sonoff 4Ch). There are plenty of applications like this where you would want the system to be able to run stand alone and not rely on control commands from a remote nodered system.

Hope that make sense.

Anyway, good to see you guys planning for the next couple of years, keep up the good work! And thanks for initiating this whole ecosystem way back when it started. I for one have found it very helpful, educational and inspiring.

Simon

2 Likes
#3

Thanks Simon, much appreciated. I will keep your comments in mind as we continue to work on EmonESP.

#4

more importantly, and this might also tie in with Simon’s comments re a smaller esp device. it would be great to see emonESP be able to post to a emonhub socket, this would be simpler for many users that just want to add a wifi emonTx to an existing setup (perhaps not even an emonpi if you can imagine such a thing :slight_smile: ) using mqtt forces us to set up an mqtt server just for that one device, where as posting data to an emonhub socket would still allow emonhub to publish that data to mqtt if the user chooses.

perhaps a lightweight emonesp FW that will run on any emonesp and post to an emonhub socket and a fuller mqtt and http server FW for standalone esp devices with more memory?

1 Like
#5

Thanks Paul, that’s a good idea. Now that I’m up to speed with emonhub sockets I can definitely see that working.

1 Like
#6

I have an idea for you.
It is relatively easy to implement support for receiving ERT/AMR signals. I know that it does not provide good precision for live monitoring of power consumption but on the other hand this is the real data that you actually pay for.

I am currently trying to do it by myself and the major problem for me is to find and buy cheap RF receiver that works with ~900MHz. I ordered several of them and I am still waiting). I know about existing utility rtlamr. I tried it and it works fine but I doubt that RPi would be able to handle the load created by SDR. On the other hand I already have implemented receiving and decoding RF 433MHz signals from temperature sensors (see my project) that involves Manchester code. So I think it will not be a big deal to implement one more protocol.

I can provide you information that I found on Internet about ERT/AMR protocol. I also may help you with testing/debugging it if you need my help.

Alex Konshin

#7

A post was split to a new topic: Feed storage discussion

#8

You are going to develop LoraWAN RF support but did you ever think to look at radio 169 Mhz ? the range is far better than the range of 868 Mhz…
radiocrafts is behind this technology : The Physics Behind 169 MHz Long Range Wireless - Radiocrafts, which is intended for the industrial market…
In France, a reseller is Enless : http://enless-wireless.com/fr/
They sell various TH sensors and analog sensors for remote meter reading…their TH sensors are more expensive than emonTH, but particularly suitable for large industrial buidings, as the ones I use to monitor…The enless technology is based upon mobdus RS485 and is quite easy to use in EmonCMS since EMonCMS has got a modbus adapter (hope it will remain in emonCMS emonhub repository)

Just dreaming: an EmonTx CT sensor with 169 Mhz transmitter would be a must in the industrial context…

By the way, maybe some of you know the new B+B Wzzard sensors ?
http://www.bb-elec.com/About-Us/News-Events/Press-Releases/Wzzard-Intelligent-Sensing-Platform.aspx
I am using advantech 4G M2M routers but I never tested this Wzzard monitoring package…

Regards and keep up developing that excellent EmonCMS software, with such an ambitious roadmap :sunny:

Alex

#9

Is that good? It may lead to much more interference from or to other systems on the same frequency in the vicinity. As an option in your particular installation, where you control all the equipment using that band, it might be a good choice. In an apartment block with maybe 10 or more households within a few tens of metres of each other, interference could become a big problem.

I remember talking about radio microphones with a professional colleague. He worked for the BBC and their solution to interference at their studios was to turn down the power so as to limit the range of the transmitters.

#10

curious is the emonhub a simple translation software or another device… i 've gone the route of now of leaning down my hardware for energy monitoring and in general ( as those open platform routers are extremely powerfully little devices and you can do alot with them and their cheaper then a normal good router ). repurposing pi’s as openwrt routers or flashing existing routers with openwrt in openwrt it has it luci stataisic which is a collectd interface currently you have to self comiple collectd_mqtt and modify luci statistics to view rrd container for mqtt locally - it will be included in the next version since I asked openwrt and wrote the the luci interface for it ). To view live data i use now tft screens connected to esp screen size range 2.4" - 9" which I love . but anyways maybe if not already in development you might consider a simple perl or python translator that can be installed on these open platform firmware for routers that can take local mqtt or http and translate them to your cloudbase emoncms … say something like my rrd method to influxdb does for me or a more direct route that sends them as as soon as it receives them… just a thought would not take long to write i suspect… probably only a few moments for those who know the ins and outs of your current platform ( which i do not otherwise i would write it for you)

the reason I mention to you then you could simple buy these routers here :slight_smile:
Xiamoi wifi router
flash them with openwrt ( if not already) install your software and away you go-- a very attractive emoncmsHub so to speak ( in the next version of openwrt redis is supported you could install emoncms on a usbstick and run it from there if you like . )

#11

I would like to continue the development of our OffGrid DC Battery and Solar monitoring solution in the future to make for a cleaner install, with a single unit similar to an EmonTx. Right now we are using hall effect sensors, a hall effect power/offset/gain adjustment board, an arduino to do ADC, and an RF transmitter to send to an EmonPi. I’d like it to be digital sensors connected to a single enclosure housing a wifi enabled arduino, ready to send data to whatever logging system the user chooses.

-Bert G

1 Like
#12

Great to hear @SolarMill, it would be worth you connecting with @danbates who’s working on similar ideas. I know Dan is looking for people with experience of DC systems to help test and guide development, see his latest post here: DCduo Board Update

2 Likes