Got an odd line 404 error that killed the app for some reason, wouldn't start just got an error message. Reinstalled the app and it cleared up. Two possibilities - I changed the £/KWh value and it didn't like it; I made variables without properly specifying a start value. More likely the latter of the two.
Whatever the issue is its something to do with line 404 in the code. Just a heads up.
Seems to be working fine although hubitat is a bit overkill for what I need - that said the peace of mind is worth it in case MuteMute or Shartlife fall over again..
Without the specific error, I won't be able to do much. Could you look at the past logs and screenshot or copy the log entry? Line 404 is around updating the weekly total variable value, so I'd lean towards an issue with the variable itself.
That'd make sense, I'm pretty sure I screwed up the initial value with that one. So when it tried to restart it got confused. Unless it pops up again I think we can consider that one sorted. Thanks.
Just a quick update. I've been finding bug after bug while adjusting the code to account for the rate schedule. They were both frustrating and fun to track down and figure out a fix for. One of the issues stemmed from how I was keeping track of the cost values. I had them being stored as a text value instead of a number (to account for a currency symbol). When changing the calculations, that lead to a number of headaches. The biggest one being that updating from the publish code in HPM to the new code would break the app. I've added a one-time conversion function that will change the values over. The one time conversion method will only run as part of an upgrade of code and will only run for existing installations. The method will not run if the app is a new installation or if the method has already ran once.
A more detailed update list:
set the rate schedules to create a cron expression for scheduling jobs to set the rate cost at the beginning of each window.
modified the code for energy changes to create a new energyChange variable.
modified the cost code to use the new energyChange for cost calculations.
modified the cost code to keep a rolling sum of current day cost + (energyChange * current cost rate)...this allows the cost to accommodate different rates throughout the day.
added a new function to convert the existing cost state.variables from String to BigDecimal using regex.
fixed a bug around tracking the energy reading at the start of the day that could result in the app showing a negative reading.
fixed a bug related to the one above where the cost for energy could end up as a negative number.
renamed the app to "Energy Cost Calculator" to hopefully be more clear about what this app does. This may change again down the road as I have some ideas to add more stats/more tables
One more day of testing and I think I'll be ready to push the update out via HPM.
I got an energy monitor today and was about to embark on a ridiculously complicated rule before stumbling upon this. This looks a lot easier...
Feature Request - In the UK we have a 'Standing Charge' which is an amount which is added daily (mine is currently 48.29p per day). I wonder if there would be a way to add that as an input in the 'Energy Rate Information' so that each day the cost begins at that value rather than 0? I believe you have similar charges but added monthly in the US?
We do. I'm just trying to tiptoe around how much input the app is going to allow. I don't know about you folks, but, here in the US, calculating your full energy bill is super convoluted. To give you an example, here is the "rate schedule" for my account:
A hand calculation says that $147.38 / 1,463 kWh = 10.0738¢..which is 0.6912¢ higher than the schedule. So, that's where the riders come in. I tried pulling each rider up, dumping the value into a spreadsheet and running the math to explain the gap (cause some are adding to the base rate and some are subtracting). Never could get there. I called the power company and spoke with 5 reps, two of whom were supervisors, and no one could walk me through how to hand calculate the rate from my bill. Bonkers if you ask me.
To draw this back to my initial point. My initial intent for this app was to give folks a relatively good idea of how much they are spending based on each available energy meter...not necessarily to replicate a full bill. The other issue is having to code around the requirement. Because it would be calculated differently based on how often the static charges would be added (simple comparison of daily for you but monthly for me). So....maybe.
Not for everyone. A buddy of mine lives in a different part of North Carolina. His provider is still Duke Energy like me, but a separate entity that's was bought out by Duke and who's prices are state regulated...his schedule looks like this:
That's it. All the riders are pre-calculated so it's less convoluted.
Funny enough, and in this vein, I have no personal use-case to have this app. Just thought it would be fun to figure out how to create it and because @Inge_Jones asked nicely.
Enter your rate per kWh information. Note: Numbers only. The input field will clear anything extra automatically. More than one decimal in the input will result in grave peril.
Optionally set the currency symbol for dashboard displays/variables.
Interestingly weird log trace. The app seems to be working fine, but it's getting a little exact in logs..
[trace]New cost for Gecko is 0.05669999999999998652189248105059959925711154937744140625
Items show up for all the plugs, then the normal value readings as before. Doesn't seem to be causing any issues with the table and reporting. Fixed UK tariff here + SC.
The short answer is....probably not. That's a short coming of the driver. I would maybe be a little more inclined if I had a device that used the driver so I could do proper testing. Even still...the driver is using a non-standard attribute which is the root of the problem. That's made even worse by the fact that the dev of the driver you're using is no longer developing for Hubitat that I'm aware of.
Taking a look at the driver, you might be able to modify this method starting around line 91 (since there's three energy meter drivers in the link) and that will allow it to work with this app:
Summary
void parse(List<Map> description) {
description.each {
if (it.name == "energyToday") energy = energyToday
if (it.name in ["current", "apparentPower", "reactivePower", "powerFactor", "energyToday",
"energyYesterday", "energyTotal", "voltageWithUnit", "powerWithUnit",
"voltage", "power", "energy", "switch", "level"]) {
logging(it.descriptionText, 100)
sendEvent(it)
} else {
log.warn "Got '$it.name' attribute data, but doesn't know what to do with it! Did you choose the right device type?"
}
}
}
Understood, but the driver devs should have converted that to the standard "energy" attribute used by Hubitat. That helps to prevent issues just like this one where an app is developed to a standardized capability/attribute but the device is not.
I ordered some Tasmota plugs so I can figure out what needs to change in the driver.
Most just some code cleanup changes for me. Also found a bug where certain variables were not getting a value set after installation until the app was opened the first time. Fixed that.
I think the next add will be to add an option to select a virtual switch that will correlate to rate overrides. This was inspired by this thread discussing critical rate periods that are dynamically set by power companies.
Still brainstorming on how to dynamically set holiday schedules.
