Feature Request: Add price per kilowatt conversion factor and toggle to see usage in dollars and cents.

[dev464]

So I keep looking at my kilowatt readouts and doing the conversion on my phone or in my head to see how much I'm actually spending for certain appliances. It'd be cool if this was integrated. To be able to enter my price per kilowatt on the app and then just touch the total usage box and see it in dollars. Then when I drop down the breakers see totals in dollars and then the livestream value could be configurable between cents/dollars, and then per time unit minute/hour/day/week/month/year. Maybe even on the graph too. Not a vital feature by any stretch but I think it'd be useful.

[MarkBryanMilligan]

I've been meaning to add this for a while and here are a few things to consider, would love to have your input.

I'm thinking of setting this value per meter. 99% of people only have one meter and in that case I can just hide the complexity of it and you only set one value. But in my house, we have two meters, one for heat and one for everything else and both meters charge at different rates. To further complicate it, our power company charges tiered rates, first 400kWh are one rate, then the next 600kWh at another rate, and then everything over 1000kWh are a final rate. Then, the rate changes twice per year for the transition from heating to cooling.

That's why I've been procrastinating on this feature. My power company is insane and the rules are obscenely complicated. Trying to create a data model that can accommodate the billing systems of every electricity provider on earth has me a little bit scared.

For the short term, should I just put in an "average rate" value to keep it simple and provide a ballpark estimate, or should I tackle the more complicated scenarios up-front?

[dcsar1]

I think you could start with an average rate as that would be immensely easier to code and be generally useful to everyone. Getting into the complicated mess of variable rates will likely be a significant effort and you will always be behind as the insane folks at the various power companies keep coming up with even crazier ways to get more of your money and make you grateful to give it to them... We are flat rate currently but that will soon change to rates based on time-of-day.

[dev464]

So I'd say its totally up to you what you want to do first. I've got thoughts on how to accomplish the complex task though so I'm just gonna go ahead at this moment and do a brain dump... Let me know what you think.

https://imgur.com/a/ItNCxQn

So first off, regardless of how complex or simple these rules get, I know you mention that some companies change their rates year by year or season by season, so if we don't want these seasonal or annual changes to affect previous totals or readings we will need to bake something in that allows us to freeze or lock in dollar values for certain readings or time periods. I'm assuming you're storing all values in some kind of database and that there's maybe 2 data sets side by side, one that stores Watts at the point of the reading and then another that totals the assumed total usage between two point values. I'm also assuming it makes more sense to store one value for this dollar value and if the user ever wants to see it in cents per second or dollars per hour or however they want to see it, to have their phone just run the conversion and trade slightly higher user processing for more efficient storage. But from there we only need 2 db fields then, total in cents, and value freeze/lock. So as you set up your rules on the app they're only ever looking at existing kWatt totals and applying rules to unfrozen values writing into one field according to those rules. Also rules would be applied to entries in these fields (when being applied retroactively to unfrozen values) that are in specified date/time ranges as defined in the rules. Any time you go to change rules maybe the app asks the user if they'd like to freeze all values in the past to avoid changing good data. Here is a quick screen I shopped up to show something that might capture some necessary functions. This is by no means comprehensive, so take it with a grain of salt. My boss just happened to be out sick today and there was nothing to do at work lmao. Some of the features I was building in my head kind of got away from me a bit as I was photoshopping the screen. Not exaaaactly sure how some of these features would jive together exactly but figured it might help to get the juices flowing. Looking back at it probably don't have a need for those radio buttons with single vs multi rule and rate modes since you can always just have multi enabled and only input a single rule or rate. Thinking maybe the complicated part will be whether the rules will pivot off of date ranges or time ranges if companies actually change rates based on time of day. Maybe this deserves a radio button option that changes the scheduler mode. Not sure. Also these buttons on the bottom kinda clash with the scheduler concept a bit. Maybe there should just be a separate screen that allows you to lock or freeze specific date ranges so no matter what you do with any new rules, older proven values cannot be affected. Eh I dunno. Sorry for the rambling stream of consciousness here lol.

[MarkBryanMilligan]

Making the UI simple enough to be usable while complex enough to accommodate all of the billing scenarios is definitely the most difficult part. I appreciate the mockup, I'll use that input when I get around to arranging the config UI in the app.

The data model for the billing rates isn't too terrible, right now the most difficult aspect will be applying it to the raw power readings. Because solar production into the grid can pay at a different rate than grid consumption, I need to apply that billing rate per second, which is the smallest interval that gets sent to the server. Aggregation into summaries is done server side as data is posted, and the summaries that are sent to the phone only contain data per minute. This is for performance reasons as I can build the data summaries in a few milliseconds server side, but to send the raw per second data to the app, the data can be quite large. (86400 seconds per day, 4 bytes per sample, maybe 50 breakers ≈ 17MB.)

Since it can be cloudy for the first half of a minute and you may turn on your AC in the second half, the per minute data that gets sent to the app won't be detailed enough to apply accurate billing on the client side. That's really a shame too because, for scalability reasons, it would be ideal to apply that on the phone side. But I can't really have the phones downloading 17MB of data every time the app loads.

For solar, I'm already calculating the "from grid", "to grid" data and I do it at the second level when I'm building the summary aggregations. So, I just need to enhance that a little bit and do it at a per breaker level and apply the billing rate at the same time and store it all separately in the summary model. Not insurmountable, but a little more complicated than you would expect at first glance.

[MarkBryanMilligan]

I went ahead and handled all the super-complicated cases. You can define time of use, kwh thresholds, and production vs consumption rates. All the rates can be defined per meter. The data model for the config is here The server calculates the rate in real-time as power gets pushed to the server so you can see it in the app each minute as it reloads.

Here's a screenshot of what it looks like in app that I just released to google play. The graph is still just the kwh, but I'd like to eventually make that a cumulative graph of the charges.

I haven't added the UI to the app for building the config yet. If you want to let me know the details of your rates (via e-mail/subreddit/here) then I can throw it in the database so you can use the app immediately and I'll get around to doing the UI for the config a little later. I'll leave this issue open until I get the app totally done.

[MarkBryanMilligan]

I released a new version of the app that allows billing rate configuration. It will be available on google play after it gets through the review process (probably later today).

When you change your billing rates, all affected totals are recalculated and will be available in the app after the server finishes recalculating (might take a couple minutes).

Closing issue.

[zyphlar]

I've just done my setup and am getting graphs, but I entered a price into the app and it says it's recalculating and yet no pricing information appears. It's as if the pricing feature doesn't exist outside of the billing rate configuration form, and doesn't match the screenshots. Maybe I have to wait for a few days to collect more data?

[MarkBryanMilligan]

You might double check the "from" date on your billing rates. I think it defaults to the current time, so if you're looking back at past data, the rate wouldn't apply. You can go back in and move the from date earlier to have it apply to old data.

If that doesn't help, e-mail your username to me at mark.milligan@lanternsoftware.com and I'll take a look in the database and see what's going on.

Also, originally, you could only set billing rates, but I added an enhancement to allow multiple billing plans (which are just a grouping of rates), so you can compare all of the different plans that your power company offers. Since I made that enhancement, I haven't gone back and updated the screenshots on the website. I'll get to that eventually.

[MarkBryanMilligan]

Ok, turns out this was a bug in the android app. After I migrated from billing rates to billing plans, the app was still using the existence of the old billing rates to show the currency button on the main page. Since my account had some old vestigial rates in my config, the button was displaying, but wouldn't for anyone else who added plans from the start.

Thanks for finding this bug! I'm sure it's been affecting pretty much everyone. I released a new version of the app, 1.0.23. It's in review now and should be available within the hour.

[zyphlar]

Thanks so much! Love this project and have been daydreaming enhancements to contribute since I installed it