Proposal: The removal of target rate sensors from the integration

[BottlecapDave]

Target rate sensors are one of the key features of the Octopus Energy integration. It was so powerful, that a variation of it was included in another one of my integrations, Carbon Intensity, where carbon emissions was used instead of price.

However by having a variation of this available in two of my integrations, this posed issues with keeping them in sync with feature parity. There are also more energy providers popping up with OE like dynamic prices that can't take advantage of this feature. There are also other areas of automation that could benefit from this feature, for example picking a time when solar generation is at it's highest.

I therefore created a new integration, Target Timeframes, which takes this feature and abstracts the data source so it can be used with whatever data source a user can think of. This means this is one feature you don't have to worry about losing if you every move away from OE for whatever reason. I'm also thinking about doing the same with cost trackers

However, maintaining all of these variations of this feature and keeping feature parity takes a lot of work. Therefore I'm proposing the removal of target rate sensors from this integration in favour of using my other integration. I've already included a blueprint for using OE data. If I go ahead, this will be removed in 6 months time, around the end of november. A repair notice will be added in the next minor release to notify users of this change.

I've already removed the feature from my Carbon Intensity integration in favour of the new integration, as it had low known user count. However due to the high user count of this integration, I wanted to propose this removal instead of just doing it. I want to hear what scenario might be missing from the new integration.

EDIT:

An initial migration guide for this can be found at https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/migrations/target_timeframes/

[slippyr4]

Well I think it makes sense. The target rate sensor is a really powerful idea and it really helps you do clever stuff with tariffs like agile. Obviously it would be a breaking change but the group of users who are actually using it are likely going to be smart enough to handle the migration.

I;m not using the new integration yet but I will look to switch to it soon. I notice the target_timeframes.update_target_timeframe_config action. Looks powerful, but it would be great to have an optional parameter as an adjunct to target_look_ahead_hours that is something like target_find_hours_before_datetime as it were. I want to be able to have a UI where I choose how many hours I want to charge and what time I want it done by - that can be done with this service call but I'd need to do some datetime math.

as an aside, did you happen to see my post about my rates graph Lovelace card?

[BottlecapDave]

I notice the target_timeframes.update_target_timeframe_config action. Looks powerful, but it would be great to have an optional parameter as an adjunct to target_look_ahead_hours that is something like target_find_hours_before_datetime as it were. I want to be able to have a UI where I choose how many hours I want to charge and what time I want it done by - that can be done with this service call but I'd need to do some datetime math.

The services have been straight copied from this integration. The service you are suggesting goes a little against the purpose of the sensors (reoccuring sensors instead of one off with date/times), but feel free to raise a feature request in the new repo.

as an aside, did you happen to see my post about my rates graph Lovelace card?

I did, but forgot to respond. I've responded now.

[elyobelyob]

I have a similar usage. I want to charge my e-bike battery depending on whatever mileage I've done. From that mileage I can gauge my number of hours it needs to charge. Having something like this functionality would make finding the best hours much more precise. At the moment I have to put in 6 hours, even when I only need a 1 hour window.
This would be really useful for many battery related. I could also use the same with my home battery.

[BottlecapDave]

The service that is available allows you to change the amount of hours you need on the fly. So you can say find the best time for the day and turn on for x hours. Its just not really built for I need x hours by 17:00 on Monday and 13:56 on Tuesday, etc.

[hingston]

Thanks for the detailed explanation. This move seems entirely logical from a maintenance and flexibility standpoint. Consolidating the feature into the dedicated "Target Timeframes" integration makes perfect sense.

I don't foresee any major issues migrating my setup when the time comes. Appreciate the clear communication and the 6-month notice period!

[dowbulldog]

Thanks for the proposed update information. I understand the logic behind this however in my instance it took me a very long time to get this working. I would class myself as a novice user, I am a pensioner so not a quick as some of the young guns. My worry is I would struggle with the new format. I will however investigate and see how I get on. Thanks for the work you do, much appreciated.

[BottlecapDave]

As others have suggested, I plan to write a migration guide from going from this integration to the new integration. I'll also see how easy it would be to use a repair action to migrate ones setup from this integration into the new integration closer to the time of removal.

[qgazq]

As a software engineer, I completely agree with the reasoning and need to do it.
As an end user with 7 targets, and a(n overly) complicated set of automatons to select which to follow, I looked at the initial migration guide and figured it will take a few hours to update (mostly copy paste and finding references). And I don't especially want to have to do. :)
Therefore if you could do a repair action as you suggest which does as much of the migration as possible (even if there are a few steps I need to do after) that would be great.

[alexhk90]

@qgazq I migrated my (only 2 rather than 7) target rate sensors yesterday and it probably took under half an hour in total. As I deleted the existing OE target rate sensors and renamed the new Target Timeframes ones to the same entity IDs, I didn't need to change any of my associated automations that were based on the target rate sensor entities (and I checked today that they all are continuing to work as expected). So while I don't know the details of your configuration, I think if I had 5 more sensors it would have only taken another 5 minutes or so for each one (create the new sensor in Target Timeframes, copy entity ID from existing OE sensor, delete existing OE sensor, rename new Target Timeframes sensor to the old OE sensor entity ID).

Essentially this is what I did (by following the migration guide):

1. Install Target Timeframes integration from HACS.
2. Use the OE blueprint to provide the relevant entities from the OE integration.
3. Configure equivalent Target Timeframes sensors for each of my existing OE target rate sensors (to make sure I configured them the same, I opened the existing configuration from the OE integration and had it side-by-side on a computer screen with the new one I was configuring). (Reload the data source in the Target Timeframes integration for the new entities to be shown.)
4. Copy the existing entity IDs from the OE target rate sensors, and delete these OE target rate sensors.
5. Rename the entity IDs of the new Target Timeframe sensors to match the (now-deleted) equivalent OE target rate sensors. (Reload the data source in the Target Timeframes integration for the entities to be shown with the new IDs.)

Of course, some kind of auto-migration would be nice (as I mentioned in my own post earlier), but it was surprisingly straightforward (for me at least) to manually migrate, and didn't break any of my automations based on OE target rate sensors (now on the new Target Timeframes sensors).

[elyobelyob]

I totally agree, I migrated three and all were done in 30 minutes, from reading the migration guide to finishing. The amount of time for BCD to write a migration when it really only takes a short while to manually migrate isn't efficient. I was of the same mindset, but jumped in and created one. I'd recommend doing one and seeing how easy it is. You'll probably jump straight into the second ...

[dowbulldog]

As a software engineer, I completely agree with the reasoning and need to do it. As an end user with 7 targets, and a(n overly) complicated set of automatons to select which to follow, I looked at the initial migration guide and figured it will take a few hours to update (mostly copy paste and finding references). And I don't especially want to have to do. :) Therefore if you could do a repair action as you suggest which does as much of the migration as possible (even if there are a few steps I need to do after) that would be great.

Hi Dave, As stated I thought I might have issues and I have. I will hold off trying again until I NEED to do it by which time the process might be a little easier for those of a less technical ability. Unfortunately I cant relate the migration process to my setup, no problem though Im sure i.ll sort it when needed with help from this community. Thanks again for the outstanding work you do for us.

[alfwro13]

It all makes sense however as an end user this will break a lot of automations for me. I would vote against it but as you are the one putting your free time to maintain this great integration it is your call. I am sure I can handle the change. Please keep in mind that there is a lot of copy/paste examples out there and more users using them.

[apollojones]

Your proposal makes sense. It will break some of my working automations but six months is enough warning to manage a transition. Thanks for the work you have done.

[ragg987]

You hinted at this new development about a month ago, so sort of expected. I've used targets since mid 2023 and they are central to my cost optimisation automations, initially with Agile and now IOG.

Understand your logic and appreciate the heads-up. From my view maintaining two integrations is inefficient use of the time you give up to benefit others, so I am OK with the proposal. Something else to learn and updating many score automations is the small downside.

I'll try to migrate one of my sensors to this and see how it goes. When do you think you will make a final decision on this? I'd prefer to wait until we know for sure prior to committing to the full transition.

[BottlecapDave]

I plan to make a decision by the end of the week. I'm 95% sure I'll do it for the reasons mentioned above, but wanted to see if anyone raised any real concerns.

[alexhk90]

Thank you for the heads-up via the "Repair" notice for your Octopus Energy integration in HA and the detailed explanation. That all makes sense to me though as already noted is a bit inconvenient for current users. I wonder if there is a way to automate the migration from a user perspective? So by installing the Target Timeframes integration the user could choose to migrate the existing OE target rate sensors somehow? Maybe not possible due to the way HA does entity objects though. If not, then a step-by-step guide on "how to migrate target rate sensors from OE to Target Timeframes" would be great (and this could be linked from a future Repair notice).

[gedl]

👍 on the "how to" for the migration

[BottlecapDave]

I'lo provide a migration guide at a minimum. I'll also see if I can provide some auto migration via the repair notice functionality, but that one might be more restrictive.

[BottlecapDave]

An initial migration guide can be found at https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/migrations/target_timeframes/

[alexhk90]

Thanks, @BottlecapDave!
I followed the migration guide and it was straightforward to migrate my existing target rate sensors in the Octopus Energy integration to Target Timeframes. As I also followed the final step to delete the sensors from the OE integration and rename Entity ID of the new binary sensors in Target Timeframes to match those previous used by the target rate sensors from the OE integration, I didn't even need to update any of my automations that rely on them.

[dowbulldog]

Great suggestion, a step by step would certainly help.👍🤞

[BottlecapDave]

An initial migration guide can be found at https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/migrations/target_timeframes/

[lamboid]

bit of a lame techie here - what is the datasource we need to setup? Tried with the MPAN id but thinking it needs to be something else???

[dowbulldog]

Yep same issue, if you find out can you post here please?

[BottlecapDave]

The data source in the new integration is whatever you want it to be. It's a unique key. Tbh, I don't think it's needed as is probably hangover from when I was going in a different direction with the integration. You can just use the term 'octopus_energy' as the blueprint will handle the data.

[BottlecapDave]

An initial migration guide can be found at https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/migrations/target_timeframes/

[elyobelyob]

Hi, think this is great. When I click on the blueprints, I get an error "Invalid parameters given." ..

[dowbulldog]

Same here !

[BottlecapDave]

This should be resolved, but just noticed there's a spelling mistake which I'll fix later on tonight.

[elyobelyob]

Did you fix this one? description: Configures a targe timeframe data source from Carbon Intensity

Do blueprints update? It's new territory.

[maksyms]

I can see the logic in extracting this functionality in a separate integration. At the same time, I have a lot of automations driven by the binary sensor, including some bespoke dashboards, etc. I'm sure the migration is possible, but what would make this change a no-brainer for me is if there was automated migration of binary sensors from one automation to the other, if that is possible at all - i.e., for Target Timeframes automation to find all binary sensors from Octopus Energy one and migrate them such that even the name stays the same. I know that the binary sensors in Octopus Energy are in Octopus Energy namespace, but I'm wondering whether it is possible to keep them as aliases for the "new" migrated binary sensors.

In other words, if there is a painless migration path - it all makes sense. If not - I'll be honest, I'm happy with the binary sensor feature in Octopus Energy to be "frozen" in its current state, as today it does all I want it to do. And those who need the cutting edge features could use your other automaton.

[BottlecapDave]

Keeping the feature frozen won't be an option as it will be confusing for new users and if bugs are discovered I'm trying to avoid fixing them in multiple places.

In terms of auto migration, I'll look to see if this is possible with repairs. I believe I'll be able to migrate the config, but I'm not sure I'll be able to migrate the names. However once the migration is complete, you're free to rename the created entities how you see fit.

[Slee2112]

I think its a good idea, it will let you spend more of your time on useful things that you enjoy.

[Slee2112]

I only had 3 target sensors, which i have now moved, and documentation seems good enough to migrate stuff manually.
I did have to reload the integration to get it to start showing entities, and had to run the automation manually to get the data into the target timeframes entity. but now its all setup it looks exactly the same.

[BottlecapDave]

The automation will run whenever one of the underlying event entities updates, which means it can take a little while for the automation to run when setup depending on your tariff. I'll point this out in the docs.

The reloading of the integration I believe is a bug. I'm using a new HA feature of sub config entries but something feels amiss with them. I've raised a bug with HA.

[slippyr4]

@BottlecapDave would you consider turning on discussions in the target time frame repo?

[BottlecapDave]

Thought I had - done!

[ProphetOfDoom]

So I've installed the Target Timeframes integration via HACS, but not the OE Blueprint, and still have my single existing target rate sensor as part of my Octopus Energy integration installed and working.

I added an entry, Name: Octopus Energy Target, Id: octopus_energy_target, and then added a Target Timeframe, completing the entries (Required Hours etc) the same as my existing Octopus Energy Target.

So far, despite a couple of HA restarts, the resulting sensor only has Data Source Id as an attribute, and if I try to reconfigure it I get an error dialog "Config Flow could not be loaded. 500 Internal Server Error Server got itself in trouble"

I haven't so far been prompted for any info about my OE account/MPAN etc so can't quite see how the Target Timeframes sensor I created will do it's magic. It's quite likely I've screwed up, but if I haven't, can I fix it, or do I simply wait for your migration guide to come out?

Hold the cavalry!
I've just read the OE Blueprint code, and figured out what it does, then managed to create my own automation to populate my Target Timeframe sensor based on the previous/current/next rates from the OE Electricity Meter integration. If I've set it up correctly, it should mirror my existing OE Target Rate sensor over the next few days. That being the case, I'll change over to using it for my inverter charging, and delete the existing one. The Config Flow error is still there though.

Great work, BTW

[BottlecapDave]

I've just read the OE Blueprint code, and figured out what it does, then managed to create my own automation to populate my Target Timeframe sensor based on the previous/current/next rates from the OE Electricity Meter integration. If I've set it up correctly, it should mirror my existing OE Target Rate sensor over the next few days.

Correct, the blueprints are used for converting any data source into target timeframe compatible data sources. This means your data sources can be whatever you want them to be. I plan on introducing a blueprint that combines the carbon intensity and OE data to show how this would be possible. It is advised to use the blueprint as the base of your automation so it can be easily updated if new features are introduced.

Config Flow could not be loaded. 500 Internal Server Error Server got itself in trouble

Please raise an issue in the other repo along with any errors you might have in your HA logs.

[ProphetOfDoom]

Target Timeframe issue created (#6), along with screenshots and HA log entries.

I wanted to go down the stand alone automation route initially to help me understand what was going on. Now that I do, I'll take on board your advice to install the OE Blueprint and create an automation from it instead of rolling my own. As you say, it insulates me going forward if you ever make any significant changes to the Target Timeframes integration as you could also release a corresponding update to the Blueprint at the same time.

[sshaikh]

I think I understand the need of a blueprint as a "bridge" to export OE data as a compatible datasource (is that right?), but it still feels a little dissonant to me. Is it possible to either:

a. Have OE create compatible datasources
b. Have Target TimeFrames accept data in the OE format (converting internally)

?

I'll try to run these in parallel for a while.

[BottlecapDave]

Have OE create compatible datasources

I wanted to avoid this for a couple of reasons.

1. I'm not a fan of integrations knowing about other integrations as it creates a dependency between them, causing complexities in keeping both integrations up-to-date.
2. I wanted the data provided like any other source so that I can easy spot shortcomings in the integration API. If I start creating backdoors, then I can easily be blinded to those shortcomings as I would code around it.

Have Target TimeFrames accept data in the OE format (converting internally)

This is basically what the blueprint does, but the other way around.

[bazcurtis]

I have installed the new Integration and the Carbon Intensity and OE Blueprint, but I get this error.

Message malformed: Missing input carbon_intensity_current_day_rates, carbon_intensity_next_day_rates, octopus_energy_free_electricity

Those fields are blanks to fill in so I assume that is the error, but why are they blank? I have no free electricity option either. I am Cosy Octopus. I appreciate any help.

[bazcurtis]

I assume it was because I didn't have the carbon integration installed. I have now installed the Blueprint with no free electricity and it look good. I assume I should pick the no free electricity blueprint?

[BottlecapDave]

This fields should be required. I'll update the blueprint. The free electricity sensor is linked in the docs. It's only available if you have octopus and is disabled by default.

[dmslangford]

I understand the logic, my wallet is benefitting from your freely given time - I'm not going to argue!

Thanks for the notice. I'll be sure to migrate when everything breaks in 6 months. 😂

[jon-hedgerows]

I get why you're doing this, but I think target rate sensors needs to be a software library that's pulled into the integration, maybe something like a python library, so end users get something that Just Works(TM).

From an end user point of view, moving target rates into a separate integration just makes things more complicated for no apparent benefit - so is not an improvement.

So I vote "no" to the proposal.

(I've installed the target rate integration, but I can't make sense of how on earth I'm supposed to configure it. Trying to follow the instructions hasn't worked - there are too many differences between reality and the docs. Right now it's failing the not-too-difficult test; before unleashing it on users it needs to pass the higher bar of easy-to-use.)

[Daverover66]

Jon, I initially had issues setting up my target times too. I created them as per the docs, but they weren't showing any entities - until I reloaded the integration and my entities popped up. Hope that helps.

[pantherale0]

Agree with this proposal, less duplication across integrations with something that can be made even better in its own integration. Nice work done here.

[f1wade]

I like the target sensors in this integration, and s i already have them setup, I dont want to have to change them all.

But can see your reasoning.

Could the other integration be pulled into this as a library to save you having to maintain it in 2 places?

[gcoan]

I follow the logic of doing this. From a 'clean HA' perspective I'd prefer to have less integrations, and of course I'd vote for not having to migrate my target rate sensors, but having firstly started on Octoblock within AppDaemon and then migrated to Target rate sensors, I'm sure I can migrate to the new solution. That you've written a migration guide makes it even easier.

Do appreciate the advance notice and putting up the repair notice to prompt to come to this proposal discussion.

[owenashurst]

As with any change, it doesn't feel the greatest when you have to move to something new. However, I've just managed to migrate my dishwasher target rate sensor over to the Target Timeframes integration. The only thing that puzzled me for a moment was in the Blueprint (to fetch data from Octopus Energy), I had to enable the previous, current and next day rate sensors, as these were disabled by default for me. After a minute (takes 30 seconds for those sensors to pick up data), I was able to select the sensors within the Blueprint.

As per the documentation, I had to reload the data source within the Target Timeframes integration, and I had to manually "run" the automation the blueprint had created so the target rate sensor had data. If you check the attributes, you can see it begins to pull in and use the data. That allowed me to verify it was indeed selecting the correct time.

As a software engineer, I know what it's like when something begins to get too big. Splitting it out makes a lot of sense. People will adapt. Both are brilliant integrations, and I wouldn't have the automations I have now without it - so thank you.

[garyjohnwalker]

Done without too many issues. And I do think breaking this out makes sense, not just for code upkeep but also for expansion to other companies and their sensors.

Thanks BCD!

[StephenMilner]

When I get some time I'll do this migration. However, at least for the moment, holidays are calling.

An automated migration tool would be great, but that's just me being lazy.

[d1964b]

If you only use target rate sensors then is this new integration to be used 'instead of' the current integration or 'in addition to' it ?

[ChrisMarriott38]

I know it's probablly better to split out for multiple suppliers support. Are there many suppliers that even offer the access API octopus do?

I do really like that it's included as part of the octopus integration though, it's one less thing to have to add and it's such a neat solution with it pulling in information it needs automatically. You only need to add a couple of fields and you can make more items. I keep thinking of uses and adding more so personally i really like it integrated.

[ChrisMarriott38]

@BottlecapDave "As mentioned in the original post, the feature won't be removed until the end of November 2025."

I assume that the existing code section, can't be left in as it is? but with a warning that part is no longer updated. If issues arise then the recommendation is that the user will need to port over?

Just thinking, if it continues to work and not need fixes as such and luck happens to be there. Sure no updates and features adn bugs will be worked on but if that little part can be left, it may be useful?

[BottlecapDave]

Keeping unsupported features is not a good long term solution for new people joining or existing people adding more sensors and then realising they've hit a bug. It's confusing for everyone involved. Even if the approach was "if you hit issues you have to migrate", I'll still get issues raised which is extra admin on my part.

[ChrisMarriott38]

Keeping unsupported features is not a good long term solution for new people joining or existing people adding more sensors and then realising they've hit a bug. It's confusing for everyone involved. Even if the approach was "if you hit issues you have to migrate", I'll still get issues raised which is extra admin on my part.

Yea I totally get that. I'm wondering if many other users than Octopus are using the sensors in mention? I completely understand it but it's nice to have over all "fewer" integrations that's why i've liked it being built in mostly. :)

[BottlecapDave]

People not on Octopus can't use the sensors if they're not made available :) As previously mentioned, and a driving force for this, a variation of these sensors were available for my other integration around carbon intensity. Theres also other energy companies that are starting to do similar tariffs to OE, or non UK variations of OE that this integration doesn't support. By having it separate, it means these other integrations can take advantage of the functionality. It also gives you the flexibility to alter the underlying data to also include other data points (see the blueprint which mixes OE tariffs and carbon intensity).

[rozza-m]

As a user of the octopus integration, I use the target rate sensors quite a lot and I'd find it pretty annoying to have to migrate for no additional benefit (for me - accept there's benefit to others).

However, your justification makes sense and is well explained. You're also giving loads of warning. People can also just not upgrade. Ultimately you're doing this for free and giving it away, and so you can do what you like with it so long as you're not hurting anyone

[d1964b]

I've recreated the target rate sensors , but I don't have the option to rename them - any advice ?

[pantherale0]

Rename the entity themselves, not the configuration entry which you are looking at.

[ando2040]

Just some feedback for Dave - I migrated across, a bit of a pain to do but it makes sense. A lot of work in these integrations (especially the much-appreciated documentation!) and the least we can do is adopt the new way to make maintenance a little simpler.

I had to change value_inc_vat to just value in a couple of places, but apart from that it was seamless. The new more powerful integration using blueprints was a new concept for me, I can't say I understand yet but I did go poking around in the YAML - is it expected that this address path gives a 404?

use_blueprint:
  path: >-
    bottlecapdave.github.io/target_timeframes_octopus_energy_with_free_electricity.yaml

[BottlecapDave]

I'm not sure where that path came from in your blueprint. It should be pointing at https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/blueprints/target_timeframes_octopus_energy_with_free_electricity.yaml as per https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/blueprints/#free-electricity-available.

a bit of a pain to do but it makes sense

It would be interesting if you could elaborate on this further. Was it just the updating of existing automations? HA UI is not really built for mass migrations (I usually work in the yaml directly but understand this isn't ideal for everyone)

As @gcoan mentioned, he's improved on the docs (HA has changed a little since they were first written up), which should go live in the next release.

The beauty of the blueprints in the new integration is you can get creative with the data source and bring in additional data points that you want to consider. The carbon intensity x octopus energy blueprint is an example of this where price is favoured and then carbon intensity is taken into consideration where the price is the same between timeframes.

[gcoan]

I'm not sure where that path came from in your blueprint. It should be pointing at https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/blueprints/target_timeframes_octopus_energy_with_free_electricity.yaml as per https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/blueprints/#free-electricity-available.

I get the same path embedded in my blueprint as @ando2040, it's not the full path and returns a 404 error if you click it from the YAML view of the blueprint.

But the blueprint works fine, must be some weird HA redirection going on??

[BottlecapDave]

Ah sorry yeah it's the internal path location within the HA config if where the blueprint is downloaded to.

[ando2040]

a bit of a pain to do but it makes sense

It would be interesting if you could elaborate on this further.

Sure - it's true that I had a several automations, and more plotly graphs, plus a flex-table-card, where the sensor name and value_inc_vat attribute needed to be updated. I did that in the GUI and missed a few on first pass - I don't trust myself enough with YAML to not mess up some unrelated section if I did the global find and replace I think you're suggesting.

I use a wildcard to keep track of all the defined sensors in a flex-table-card

entities:
  include: binary_sensor.target_timeframes_*

Further, the documentation is excellent but following anything for the first time is a bit of a challenge - I initially tried without the docs but it was sufficiently different, and I set up the target rate sensors in the octopus integration long enough ago, that I had to simultaneously follow the documentation and refer back to the settings of existing target rate sensors - I messed up the Agile start and end times without looking back, didn't remember that I needed to specify 16:00 to 16:00 (on sensors where I didn't care about start and end time otherwise).

In addition, it's a multi-stage installation including the blueprint automation I've never used before as mentioned. So, a learning exercise and a small amount of pain that I put off for a few weeks. Hope that makes the comment clearer.

[BottlecapDave]

Thank you for clarifying. I was wondering if there was anything I could do to improve the process, but sounds like potentially improving the docs (which some community members have done)

[ragg987]

Just finished migrating from Octopus to Target Timeframes. Slow process as I have a bunch of automations built on top of the target sensors, however I think I'm there now. A couple of gotchas in case anyone else is doing this:

• you need to replace the Action that updates the target to the new one action: target_timeframes.update_target_timeframe_config
• the old Action accepted target_hours as a string. The new one requires a number.
• a couple of my automations would reload the config using homeassistant.reload_config_entry. I had to update these as well

I also decided to keep the new naming convention in the sensors rather than rename them to the old, this means that as I add new ones there is a naming convention that I can use to easily find these.

And for anyone using the octopus-energy-rates-card, don't forget to update this with the new sensors.