If you're living in Malta and on Home Assistant, you've probably wanted to see what your energy use is actually costing against Enemalta's banded tariffs. Those bands are cumulative per billing year and the marginal rate climbs as you use more, so a flat "kWh × price" sensor doesn't cut it.
I put together a small package (pure YAML — no custom component) that does it properly:
Supports Residential, Domestic and Non-Residential tariffs.
Prices marginally, band by band, exactly how Enemalta bills.
Uses a yearly utility_meter so the bands reset each billing year.
Includes the residential Eco-Reduction estimate (based on registered residents).
Has an optional Wh→kWh converter for cumulutive energy consumption sensors that report in Wh (rather than kWh).
You point it at your cumulative energy sensor, set a few helpers (tariff type, residents, etc.), and you get a sensor.enemalta_electricity_cost with the running cost plus useful attributes (current band, gross cost, kWh year-to-date).
A few honest caveats up front: it's an estimate — verify against your ARMS bill, and the legislation (S.L.545.41) prevails over any rate I've transcribed.
Rates are current as of the Enemalta pages in early/mid 2026; I've isolated the rate tables at the top of the file and keep a CHANGELOG so updates are easy.
I haven't bothered with the fixed service charge, Maximum Demand, or the Non-Residential day/night & kVAh tables yet — uncommon for a home, but PRs welcome.
Feedback and especially testing across different meter setups very welcome - keen to know if it behaves on sensors other than mine.
Got excited about this & was thinking of installing it, but backtracked when I read the How it works section:
"Enemalta charges on cumulative consumption bands that reset each billing year — the more you use over the year, the higher the marginal rate on the top units."
That's not really how they handle consumption bands though. Bands are calculated pro-rata based on their extremely erratic* billing cycle. This means that, unless you factor these in, the costs will only be correct at the very beginning & at the very end of they year.
If you're paying your own bills, you can verify what I just said yourself. Divide eg. the yearly allowance of the lowest billing cycle (2000 units) by 365, then multiply with the number of days in your billing cycle (let's say 59 days). You'll see that it's proportional & the first 323.288 units will be billed at the lower rate.
If you're not paying (or looking closely at) your own bills & depended on AI to get the answer, it also got it wrong:
*If you want to know how erratic they can be, I just had a look at my last half dozen bills - they varied from 59-70 days!
Uhm, that fixed charge is mandatory & not uncommon at all. It's a service charge which, again, is added pro-rata to your bill based on the number of days in your billing cycle. It varies every bill, but it's always there (like death & taxes) & not uncommon at all.
Please don't get me wrong. I was genuinely interested in installing this and am not here to spit on your efforts. You requested feedback and I'm providing it as honestly as possible. However, unless your package learns to read ARMS' minds or gets them to start billing on a fixed schedule, the costs returned by this integration will be wildly off for most of the year.
Thanks for the honest feedback - and I agree with your observations 100%.
The idea was to get an approximation of how much my electricity consumption is costing me, and my understanding is that the total cost over a year should come close to what ARMS would have billed me throughout the course of the same year.
But you're quite right, the way ARMS work out the bands pro-rata messes up this logic (apart from being quite unfair to boot). I'm thinking I could set up the package so that it takes a user input for the start of the first billing cycle and then assumes that each billing cycle will be 60 days long. Either that or have manual user input to tell HA when a new bill has been issued - which sounds a bit too cumbersome.
Regarding the fixed service charge - I chose to ignore it since I was working off the assumption that I was estimating the total eletricity cost for a whole year, and I just thought working in the meter rental would complicate things unnecessarily. But if I manage to put together a model that works with pro-rated billing runs, it might make more sense to include this charge too.
Anyway - thanks for your feedback and watch this space for an update
