As mentioned previously in the OpenEnergyMonitor goals post we are working towards adding a pay-per-feed model to emoncms.org to fund server costs, maintanence and development.
Billing section on Account page
We have now added a Billing section to the user accounts page of emoncms.org, which gives projected costs and a graph of account balance:
Multiple accounts
If you administer other emoncms.org accounts and wish to handle billing as part of a single account, you can add users by username and password to a chosen account. Feeds from added accounts will be subtracted from the balance of your chosen admin account.
Billing starts 1st of July 2018
To give plenty of warning and to give us time to complete the OpenEnergyMonitor Shop integration we are aiming for a start date of 1st of July 2018. Any account balances accumulated between now and then will be reset on the 1st of July 2018. Once billing starts there will be an option to link your OpenEnergyMonitor Shop account to your emoncms.org account. If you have bought hardware from us previously you will automatically gain emoncms.org credit based on a percentage of the order amount as mentioned above.
Iām self-hosted, so these changes will not affect me, but thanks guys for keeping emoncms.org a free service for so long
A couple of questions do spring to mind though;
What will be the consequences for users with zero credit after July 1st? will users be able to access data that was already stored in emoncms.org prior to 1st July to view or download, will their accounts/data be locked - or even deleted? If users continue to try and post data - will it result in a 401 http error?
Not all users are regularly in the forum, and may not see this post, and if accessing emoncms.org via weblinks may not see the message that youāve posted in āMy Accountā page either. As this is a significant change which will affect continuity of service, should informative emails be sent to the registered email addresses of emoncms.org users?
Do you have any plans to delete accounts that have been inactive for āxā period of time? Iām sure that there must be loads! (I think Iāve got 2 - sorry!)
A similar model is used extensively by other businesses, to reduce storage & maintenance demands.
Usually preceded by a warning email to the registered address.
Accounts will be able to run into negative balance and there will be an automated email notifying of the need for a topup. If the account remains in negative balance for:
One month: posting will be disabled
Three months: account will be archived (the account can be recovered at this stage)
6/12 months (to be confirmed): account will be permanently deleted.
There will be an automated email prior to each point.
Yes, we will be sending out an email notifying of these changes over the next couple of days and referencing this forum post.
Thanks I got the email yesterday evening. I was a little surprised but then see the logic behind it, no such thing as a free lunch as they say I do have a couple of questions:
How can payment be made - credit card/paypal etc?
Does the credit for previous purchases run from 1st July 2018 or from the date of purchase? (my purchases were some years ago and Iāve not made any purchases/changes since - if it aināt broke etc!) So the indicator in my account suggests Iāve used up any credit I may have accumulated already
I donāt have a big issue with paying per feed as such, I note I have a few āpointlessā feeds which donāt change that much and could be deleted, I guess this is part of the reason the scale of feeds has become so large. I did try to set up the cms on Windows (ergh I know) and came to a dead end and didnāt have time to persevere. I honestly donāt have time to fiddle more between now and July either so will have to bite the bullet and pay up I guess I have zero Linux experience sadly and the Pi would eat up any savings made from having the system in the first place!
Couple of thoughts:
Similar to my situation of āpointlessā feeds in an attempt to get folks to scale down taking up server space - could you offer a āfreeā + āsubscribedā model of say āxā feeds for free and then you pay for any extras on top? It might soften the blow
Is there a notion of personal use versus commercial use?
Thanks and appreciate that this has been a free service for many years now and been very useful!
At least to start with there will be an OpenEnergyMonitor shop item called āemoncms.org creditā. It will work a bit like a mobile phone topup. The shop can accept credit/debit card, bank transfer and paypal. In future we may look at adding automated recurring payments.
Credit will run from the 1st of July 2018 not the date of purchase (if it was earlier than the 1st of July 2018). You will have all of your credit Which gives the chance to think about number of feeds etc and a good period of continued free use.
Yes, thatās been I think part of the problem with a free service there is no incentive to manage use and we want to ensure we can sustain the server costs, maintenance and development time required to ensure it is a stable, secure, well backed-up and scalable system into the future.
Emoncms.org is also used by many users who are not OpenEnergyMonitor hardware customers, which we welcome, but its difficult to subsidise the whole service from hardware sales only.
We did think about this, but decided that the emoncms.org credit based on past order spend gives a similar benefit as the free for āxā feeds while keeping things as simple as possible and making payment fully proportional to usage and shop purchases. The feed cost and percentage rate is something we will review over time as we assess the impacts of these changes.
Thanks for your email regarding pay-per-feed. As a long time user of emoncms I am surprised and grateful you have managed to keep the service free for so long.
Recently I put max and min feeds on many of the temperatures on the emon accounts I look after. I assumed they are reset every 24 hours so take no significant server space.
They will however triple the cost of the service, from Ā£9 to Ā£27 on one of my accounts.
Pragmatically I will remove them but it does raise a question about storage/cpu hungry feeds vs minimal feeds and perhaps something to consider in your business model as, I guess, others are likely to do the same.
I would be interested to know why you rejected pay-per-input rather than pay-per-feed?
That is a point I also wanted to make: At the moment I store current, voltage, power and power factor all in a separate feed. However, some of these values could actually be calculated from each other. If it would be possible to calculate these values directly in emoncms.org (virtual feeds?), no storage space has to be wasted.
But I also want to mention that I consider the model with 1 pound / feed / year as very fair.
Hello @David_Eager, @Simsala , yes its a good point about feeds with longer intervals and features like min/max. There is a processing overhead associated with all input processing and a significant part of the scaling demands on emoncms.org are also due to input processing. Feeds such as mix/max or kwh/d are still called at the input post rate which may be every 10s even through in terms of disk space there is only a new datapoint every day. So in this way the Ā£1/feed/year both captures disk use and input processing overhead. It gets quite complicated to assess all the different options in terms of their resource use, impacts of using different input APIās, post rates, processor types, feed intervals etc which is why we settled on number of feeds as a relatively simple measure that captures both the disk space element and a good part of the processing.
I think what follows is on-topic in that it might provide a chargeable information stream. It might also be a daft idea but I thought Iād mention it anyway.
There must be a fair amount of solar power data appearing in the emoncms data structure. If you asked people to include their postcode in their profile it would be feasible to produce a real time solar power intensity map for the UK. The solar data would be self normalising and probably pretty straight forward to identify and pull from all the feed data. It would open up a new area of real time logging and short term solar prediction (in pragmatic terms avoiding the sun going in the second you want to use power (kettle, washing machine etc)
I send an monthly solar kWh figure to Sheffield University each month and this in turn is used in the Templar UK power mix figures. Itās nowhere near real time.
The big question is I guess whether anyone is prepared to pay for near real time data and what sort of coverage existing emoncms users would provide.
Iāve always thought it would be neat to sell solar postcards - a mini flexible panel with integrated esp8266 like comms that could just be put in a south facing window. Iāve not done the sums as to how big the panel would need to be to provide a reasonable update interval if it also powered the comms circuitry.
Hello @David_Eager, sorry for slow reply. Its a great idea and one Iāve been wanting to pursue for sometime but time has not allowed. I would however be keen to approach it as an open data project, perhaps we could even give away free feeds for participation in a specific project like this that would curate high quality datasets around topics that are of interest to the wider research community as well as OpenEnergyMonitor users?
Iām not sure if this is the best way, i see at it as a perpetuous rent, of a unknown value, since it is feed based. It removes all the fun into exploring the software. It will not matter if it is fair price or not. Itās unpredictable.
I know you guys are suffering from the expenses of this great ecosystem and also suffer from non-OE customers using and abusing emoncms.
I should make a alternative suggestion now but it is actually very hard! Big SW companies give us cool bits of software and then sell our soul without us knowing. this makes honest sw development very hard to monetize.
I have lots of friends that use emoncms online and iām not sure how they will behave. Some of them are considering rpiās even though they know nothing about it. They will spend 40ā¬ or more in a piece of hardware maybe you guys could capture that money and give emoncms for free for a long time. I donāt knowā¦
Hello @cab123, thankyou for the input, Itās a difficult one, Im not sure what you mean by unpredictable? is that in terms of potential price change over time? or to do with system setup, knowing how many feeds you need?
Unpredictable because every time you think of changing the system you have to calculate if itās worth it in terms of pound per feed. I remember creating a great amount of feeds to separate the different charging periods. You kind of penalize the most creative folk. And cap others that want to expand their systems.
Personally i would appreciate more something like a free plan for everyone that wants to try out the software with just 1 monitoring point (feeds maybe too technical?) and maybe without any advanced emoncms engine processing. And eventually with limited monitor history? And then a Premium account with unlimited monitoring points for whatever price you think is reasonable, with 1-year subscription and another with lifetime subscription?
If you opt out of a free plan i believe many will simply ignore and never give it a shot and see how great emoncms is.
Thanks for the clarification @cab123, Im not sure if I was clear in the above that when you add a new feed for testing you dont have to pay for a year upfront. If you want to test a new feed for one hour you only have to pay for that feed for one hour which would cost about Ā£1 / 8760 = Ā£0.000114. It works like pay as you go mobile plans or cloud services like amazon EC2. You can always test a new configuration for a short time and remove if you dont find it useful.
ā¦but if you added ādaily maximum temperatureā & ādaily minimum temperatureā to the temperature input process, you would have 3 temperature feeds, which would be the same as your example for energy.
I do have a couple of questions:
Which gives the chance to think about number of feeds etc and a good period of continued free use.