Custom component for interacting with Octopus Energy

Overview

Home Assistant Octopus Energy

** WARNING: This component is currently a work in progress **

Custom component built from the ground up to bring your Octopus Energy details into Home Assistant to help you towards a more energy efficient (and or cheaper) home.

How to install

To install, place the contents of custom_components into the <config directory>/custom_components folder of your Home Assistant installation.

How to setup

Setup is done entirely via the UI.

Your account

When you setup your account, you will get the following sensors:

  • Current Electricity Current Rate (Based on first active tariff)
  • Current Electricity Previous Rate (Based on first active tariff)
  • Latest Electricity Consumption (per electricity meter)
  • Previous Day's Accumulative Electricity Consumption (per electricity meter)
  • Latest Gas Consumption (per gas meter)
  • Previous Day's Accumulative Gas Consumption (per gas meter)

Ideally, you'd be able to use the consumption sensors as part of your energy dashboard. However, while they can be added, Octopus Energy doesn't provide live consumption data.

Target Rates

If you go through the setup process after you've configured your account, you can set up target rate sensors. These sensors calculate the lowest continuous or intermittent points and turn on when these rates are active. These sensors can then be used in automations to turn on/off devices the save you money (and in theory be on when there's the most renewable energy).

Gas Meters

When you sign into your account, if you have gas meters, we'll setup some sensors for you. However, the way these sensors report data isn't consistent between versions of the meters, and Octopus Energy doesn't expose what type of meter you have. Therefore, you have to toggle the checkbox when setting up your initial account within HA. If you've already setup your account, you can update this via the Configure option within the integrations configuration. This is a global setting, and therefore will apply to all gas meters.

Known Issues/Limitations

  • Latest consumption is at the mercy of how often Octopus Energy updates their records. This seems to be a day behind based on local testing.
  • Only the first property associated with an account is exposed.
  • Gas meter SMETS1/SMETS2 setting has to be set globally and manually as Octopus Energy doesn't provide this information.
Comments
  • Odd Target Rates behaviour

    Odd Target Rates behaviour

    I'm now on v4.5.0. I've set up two intermittent Target Rates, one for three hours and the other for six hours. No offset and a 00:00 - 23:59 min/max. Here are the results:

    image image

    Couple of things seem odd:

    1. The three hours are not a sub-set of the six hours, e.g. the three hour sensor came on at 4pm for 90 mins (during a period that definitely wasn't in the top 3 cheapest hours of the day!).
    2. There is much more than 3/6 hours where each sensor is activated in a 24hr period.

    Today's pricing is as follows (incl. a nice plunge in the early morning!):

    00:00 - 00:30 | 22.36
    00:30 - 01:00 | 6.05
    01:00 - 01:30 | 1.05
    01:30 - 02:00 | -0.27
    02:00 - 02:30 | 0.00
    02:30 - 03:00 | -1.64
    03:00 - 03:30 | -3.19
    03:30 - 04:00 | -8.40
    04:00 - 04:30 | -4.20
    04:30 - 05:00 | -8.40
    05:00 - 05:30 | -7.14
    05:30 - 06:00 | 2.10
    06:00 - 06:30 | 6.51
    06:30 - 07:00 | 23.73
    07:00 - 07:30 | 18.06
    07:30 - 08:00 | 31.50
    08:00 - 08:30 | 35.80
    08:30 - 09:00 | 35.80
    09:00 - 09:30 | 33.10
    09:30 - 10:00 | 30.74
    10:00 - 10:30 | 27.89
    10:30 - 11:00 | 23.10
    11:00 - 11:30 | 20.50
    11:30 - 12:00 | 17.26
    12:00 - 12:30 | 17.43
    12:30 - 13:00 | 14.49
    13:00 - 13:30 | 15.58
    13:30 - 14:00 | 6.89
    14:00 - 14:30 | 13.44
    14:30 - 15:00 | 12.01
    15:00 - 15:30 | 12.10
    15:30 - 16:00 | 16.80
    16:00 - 16:30 | 29.40
    16:30 - 17:00 | 35.80
    17:00 - 17:30 | 35.80
    17:30 - 18:00 | 36.75
    18:00 - 18:30 | 35.80
    18:30 - 19:00 | 38.79
    19:00 - 19:30 | 35.80
    19:30 - 20:00 | 35.80
    20:00 - 20:30 | 35.80
    20:30 - 21:00 | 30.60
    21:00 - 21:30 | 35.80
    21:30 - 22:00 | 29.82
    22:00 - 22:30 | 35.80
    22:30 - 23:00 | 25.62
    23:00 - 23:30 | 35.80
    23:30 - 00:00 | 31.08
    

    Finally, I'm still getting the following error when I try to create a new Target Rates sensor without entering min/max times (may also be caused by blank offset?):

    Logger: aiohttp.server
    Source: custom_components/octopus_energy/config_flow.py:215
    Integration: Octopus Energy ([documentation](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/), [issues](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues))
    First occurred: 18:12:16 (3 occurrences)
    Last logged: 18:12:54
    
    Error handling request
    Traceback (most recent call last):
      File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
        resp = await request_handler(request)
      File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
        resp = await handler(request)
      File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 60, in security_filter_middleware
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 222, in forwarded_middleware
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 82, in ban_middleware
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
        return await handler(request)
      File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 136, in handle
        result = await result
      File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 216, in post
        return await super().post(request)
      File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 73, in wrapper
        result = await method(view, request, data, *args, **kwargs)
      File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 71, in post
        result = await self._flow_mgr.async_init(
      File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 225, in async_init
        flow, result = await task
      File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 252, in _async_init
        result = await self._async_handle_step(flow, flow.init_step, data, init_done)
      File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 367, in _async_handle_step
        result: FlowResult = await getattr(flow, method)(user_input)
      File "/config/custom_components/octopus_energy/config_flow.py", line 246, in async_step_init
        return await self.__async_setup_target_rate_schema(config, {})
      File "/config/custom_components/octopus_energy/config_flow.py", line 215, in __async_setup_target_rate_schema
        vol.Optional(CONFIG_TARGET_START_TIME, default=config[CONFIG_TARGET_START_TIME]): str,
    KeyError: 'Start time'
    

    Appreciate any pointers!

    bug stale 
    opened by no1knows 21
  • 3.0.0 & 3.0.1 not gettign data

    3.0.0 & 3.0.1 not gettign data

    Hi love the intergration, I was doing this manually before but so much easier now, thank you.

    2.0.0 worked perfectly and was downloading data each day. Since 3.0.0 no data is ever downloaded and sensors stay at 0

    Rolling back to 2.0.0 gets data again upgrading to 3.0.1 (or 3.0.0) breaks the intergration

    I'm not sure they are relevant but her are the only log entries I can see that are related File "/config/custom_components/octopus_energy/__init__.py", line 89, in async_update_data hass.data[DOMAIN][DATA_RATES] = await client.async_get_rates(tariff_code, period_from, period_to) File "/config/custom_components/octopus_energy/api_client.py", line 107, in async_get_rates return await self.async_get_standard_rates(product_code, tariff_code, period_from, period_to) File "/config/custom_components/octopus_energy/api_client.py", line 49, in async_get_standard_rates data = await response.json(content_type=None) File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 1119, in json return loads(stripped.decode(encoding)) File "/usr/local/lib/python3.9/json/__init__.py", line 346, in loads return _default_decoder.decode(s) File "/usr/local/lib/python3.9/json/decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/local/lib/python3.9/json/decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

    May be relevant that i'm an octopus energy UK customer and don't have a varible tarrif.

    With 3.0.1 (and 3.0.0) the intergration is getting the following; sensor.octopus_energy_electricity_XXXXXXXXX_latest_consumption = Unavailable sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_consumption = 0 sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_consumption_cost = 0.0 sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_cost = 0 sensor.octopus_energy_electricity_current_rate = 0.187845 (always the same) sensor.octopus_energy_electricity_previous_rate = 0.187845 (always the same) sensor.octopus_energy_gas_XXXXXXXXX_latest_consumption = Unavailable sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_consumption = 0 sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_consumption_cost = 0.0 sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_cost = 0

    With 2.0.0 the intergraion get the following: sensor.octopus_energy_electricity_XXXXXXXXX_latest_consumption = 0 sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_consumption = 16.962 sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_consumption_cost = 0.0 sensor.octopus_energy_electricity_XXXXXXXXX_previous_accumulative_cost = Unavailable sensor.octopus_energy_electricity_current_rate = 0.187845 (always the same) sensor.octopus_energy_electricity_previous_rate = 0.187845 (always the same) sensor.octopus_energy_gas_XXXXXXXXX_latest_consumption = 0 sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_consumption = 2.781 sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_consumption_cost = 0.0 sensor.octopus_energy_gas_XXXXXXXXX_previous_accumulative_cost = Unavailable

    Happy to test anything that might help.

    bug 
    opened by Smiley1244 20
  • Device targets don't work

    Device targets don't work

    I've set this up via HACS, the data appears to be there as I can see the prices under the attributes but the device targets don't have any data under them so they never trigger, this is what I see under HA states.

    bug 
    opened by cspiby 19
  • Gas meter not discovered/no sensors generated for gas.

    Gas meter not discovered/no sensors generated for gas.

    Describe the bug Missing gas meter sensors

    To Reproduce Added integration, current and previous electricity meter added, no gas meter

    A gas meter may be seen to be present when running an API curl command https://api.octopus.energy/v1/accounts/A-xxxxxxx/ (the same key and acount added to the integrations. The meter is SMETS1 but is adopted )I tried ticked and unticked).

    Expected behavior Gas meter sensors to be added. Home Assistant Logs I can't find anything useful.

    bug 
    opened by itsfja 16
  • Prices don't include government cap?

    Prices don't include government cap?

    Describe the bug

    I've just switched to Octopus last week, and as a result am on "Flexible Octopus" (for now) which contractually showed as 52p per kWh, but due to the government cap is actually 34.23p per kWh. The Octopus app and website both show as 34.23p per kWh, but obviously the API does not, as this HA integration is showing 0.52074225 GBP/kWh

    rate:  
    value_exc_vat: 49.5945 
    value_inc_vat: 52.074225 
    valid_from: '2022-10-17T16:00:00+00:00' 
    valid_to: '2022-10-17T16:30:00+00:00' 
    tariff_code: E-1R-VAR-22-10-01-H  
    is_export: false 
    is_smart_meter: true
    
    

    To Reproduce

    Have a government capped tariff. Sorry! I assume this is unlikely to be an issue with the integration and an API issue instead, but I thought I'd check and/or wasn't sure if you had a contact at Octopus rather than attempting to explain this to the standard customer support.

    Expected behavior

    The correct price is returned.

    Home Assistant Version 2022.10.4

    Integration Version v4.5.1

    Fresh Install? Fresh install

    Let me know if debug logs would help.

    bug 
    opened by lozzd 15
  • New install - receiving rate, but not previous day consumption?

    New install - receiving rate, but not previous day consumption?

    Hi there,

    Just installed this and seems to all work (great work on this!), correctly returns my rate, however both consumption and cost values are returning 0.

    Any ideas on how I can diagnose this?

    opened by zygote279 15
  • Sensors created for old meters

    Sensors created for old meters

    Describe the bug

    Sensors are created for meters which have been replaced at the same property.

    To Reproduce

    Have a property which returns these kind of API responses 😅

    Get account REST API response
    {
      "number": "A-BCD123EF",
      "properties": [
        {
          "id": 1234567,
          // redacted for brevity
          "electricity_meter_points": [
            {
              "mpan": "0123456789",
              "profile_class": 1,
              "consumption_standard": 5720,
              "meters": [
                {
                  "serial_number": "XXXXXXXXX",
                  "registers": [
                    {
                      "identifier": "00",
                      "rate": "STANDARD",
                      "is_settlement_register": true
                    }
                  ]
                },
                {
                  "serial_number": "YYYYYYYYY",
                  "registers": [
                    {
                      "identifier": "1",
                      "rate": "STANDARD",
                      "is_settlement_register": true
                    }
                  ]
                }
              ],
              "agreements": [
                {
                  "tariff_code": "E-1R-SUPER-GREEN-24M-21-05-29-E",
                  "valid_from": "2021-06-30T00:00:00+01:00",
                  "valid_to": "2023-06-30T00:00:00+01:00"
                }
              ],
              "is_export": false
            }
          ],
          "gas_meter_points": [
            {
              "mprn": "12345678",
              "consumption_standard": 47722,
              "meters": [
                {
                  "serial_number": "AAAAAAAAAAAAAA"
                },
                {
                  "serial_number": "BBBBBBBBBBBBBB"
                }
              ],
              "agreements": [
                {
                  "tariff_code": "G-1R-SUPER-GREEN-24M-21-05-29-E",
                  "valid_from": "2021-06-30T00:00:00+01:00",
                  "valid_to": "2023-06-30T00:00:00+01:00"
                }
              ]
            }
          ]
        }
      ]
    }
    

    YYYYYYYYY is the currently active electricity meter, and AAAAAAAAAAAAAA the gas - it doesn't look like the ordering matters, which is a shame as there's very little extra info for the gas mater in particular.

    Consumption API for the old meters is completely blank:

    {"count":0,"next":null,"previous":null,"results":[]}
    

    Expected behavior

    No sensors are created for the old meters.

    Misc

    Background here: moved into property with old style meters, which where shortly thereafter replaced by smart meters. Sensors are created for the new meters just fine, but also for the meters which were removed, and have no data.

    This might be a bug in the rest API - the old meters don't show in the UI, and don't appear in the graphql API afaict:

    Screenshot 2022-01-03 at 15 04 38

    Using the REST API this might be tricky to handle cleanly because the sensors are created based on the data in the account API, which then go on to have no data in the consumption API but they have already been created at that point. I have disabled the entities for now so it's no big deal to me, but wanted to document the issue here while I had all the info in my head.

    Thanks for creating this - I wanted to get some price sensors and started to look at building a small component based on the GraphQL api, this component saved me the effort 🙂

    bug 
    opened by DazWorrall 15
  • Time period for Octopus data

    Time period for Octopus data

    I have been using this HACS integration for a month or two, and it is great. I did some playing around with the Octopus API in Postman, and noticed that it gives consumption for half hourly time periods, with the group_by parameter allowing reduced granularity. The integration stores the data for the previous day. I understand that Octopus doesn't provide data newer than the previous day.

    Do you have any plans to allow using a shorter time period in the integration? I'd be interested in helping out with this.

    bug 
    opened by dunxd 15
  • Cumulative Gas Cost Calculation

    Cumulative Gas Cost Calculation

    Firstly - thank you so much for developing this integration. Super clean and helpful! Much appreciated.

    Describe the bug I have just set up my integration. But I was not sure if the gas calculation was working. It shows previous day gas consumption of some 6.5m³ but previous day gas cost of £0.49. I suspect the calculation was taking the p/kWh (around 3.6p) multiplied directly to the 6.5m³ and added standing charge of some £0.25. But in reality, the gas cost is much higher in particular in winter...

    To Reproduce Steps to reproduce the behavior: Initiate the integration and read the gas cost against normal bill cycle

    Expected behavior When I was reading the bill, the energy calculation is much more complicated. Your energy usage is calculated from your gas consumption using a standard industry formula: Units Consumed (Cubic Metres) × Volume Correction (for temperature & pressure) × Calorific Value (energy in each m3 of gas) ÷ 3.6 (convert from joules) ≈ Usage (in kWh) So the 6.547m³ need to be converted to some 72kWh (based on the numbers on my bill), then multiplied with the 3.6p, adding standing charge, getting to close to £3 per day, this sounds more like the case in winter...

    The solution that I have is to change the utils.py, make use of your conversion from kWh to m³ but do the opposite way. i.e. I took the m³ reading and multiply Volume Correction, Colorific Value and convert from joules (change the signs in the last bit), then tick the SMET1 box in the integration (so that the conversion kicks in). Let me know your thoughts.

    Home Assistant Logs N/A

    bug 
    opened by sslx123 12
  • Got Electricity data but not Gas

    Got Electricity data but not Gas

    Describe the bug No data for Gas sensors:

    previous_accumulative_consumption
    previous_accumulative_consumption_cost
    previous_accumulative_cost
    

    These sensors have attributes relating to my meter (e.g. serial number, MPRN etc) but always have a 0 value

    gas_current_rate does have a value

    To Reproduce Installed and connected to my account. I have electricity details. The Octopus API does return data when querying my gas metere

    Expected behavior Gas data be present?

    Home Assistant Logs Nothing I can see, tell me how to be useful and I'll provide

    bug 
    opened by trullock 11
  • HACS Install

    HACS Install

    Hiya, great work, looking forward to trying this! Just wondering if you had considered submitting to the Home Assistant Component Store to make installation and updating one click easier?

    https://hacs.xyz/docs/publish/start

    opened by Gadgit83 11
  • Import Targets get

    Import Targets get "Export" entity name

    I have created both import and export targets (I have both meters) but both get named Export (Octopus Energy Target Export 3i_import)

    Can we either name as an import Target or remove the Export text from the name?

    Using version 5.0.0

    Don't see this addressed in the upgrade notes for 5.1.0 but haven't upgraded yet, so sorry if this is already fixed.

    bug 
    opened by usbrit 0
  • Incorrect Tariff using Intelligent Octopus

    Incorrect Tariff using Intelligent Octopus

    Describe the bug

    If using Intellilgent Octopus, and Octopus decide to charge your EV during peak time, the tariff changes to the off-peak tariff. However, the tariff shown in this integration is still the peak tariff.

    To Reproduce

    Signup to Intelligent Octopus and observer sensor behaviour.

    Expected behavior

    The tariff should accurately reflect the current rate.

    Home Assistant Version

    The version of Home Assistant.

    Integration Version

    2022.12.8

    bug help wanted 
    opened by ColinRobbins 2
  • Break out the totals  into peak and off peak costs / kWh

    Break out the totals into peak and off peak costs / kWh

    The entities show the totals for kWh and Costs, would it be possible to add more entities that show the peak and off-peak separately from the totals ie the build up.

    Expected behavior for example :- Peak kWH = 2 , Off-Peak kWH = 4 , Total kWH = 6 Peak Cost = 24p , Off-Peak kWH = 48p , Total kWH = 72p

    This would make it so much easier to understand the total cost build up and usage and how the totals are calculated. Apologise if there is an easy way to already do this, but I'm still learning

    enhancement 
    opened by Annaka007 0
  • Feature request: Service to re-evaluate target on demand

    Feature request: Service to re-evaluate target on demand

    Not sure how straightforward this would be, but I have a use case where I have a target set to run in the early morning, but want to use an Automation earlier in the evening to set charging times on my batteries(mostly so I can either choose to cancel it, or verify the time on the inverter)

    From what I can see, the once a day targets seem to evaluate at midnight. would it be possible to have a service to trigger the evaluation on demand?

    opened by corvus2606 3
  • v 5.0.0 Upgrade Details

    v 5.0.0 Upgrade Details

    As part of https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/79, it was discovered that some of the sensors were configured incorrectly with Home Assistant. Unfortunately, there doesn't seem to be an easy way of fixing this without following one of the following approaches.

    Manual Statistic Removal

    This approach is a little more involved and easiest to launch two browsers/tabs. In the first tab, navigate to your entities (e.g. http://homeassistant.local:8123/config/entities) and search for octopus. In the second tab, you should navigate to your statistics (e.g. http://homeassistant.local:8123/developer-tools/statistics) and search for Octopus.

    Now for each sensor

    1. In the first tab, click on the sensor and navigate to settings
    2. Under Advanced settings click on Disabled and then Update.
    3. Wait a couple of seconds
    4. Click on the sensor and navigate to settings
    5. Under Advanced settings click on Enabled and then Update.
    6. In the second tab, find the corresponding entity
    7. Click Fix issue
    8. In the pop up, click Remove

    Reinstall the integration

    The easiest approach is to remove all references to the integration.

    Once done, you will need to visit your Home Assistant statistics page (e.g. http://homeassistant.local:8123/developer-tools/statistics) and make sure all statistics are removed. If not, you'll neer to remove the statistic associated with each Octopus Energy sensor. This can be done by clicking Fix Issue button and then clicking "remove". If none are here, then

    Once all statistics are removed, you can reinstall the integration.

    Side Effects

    The side effects of this fix unfortunately is that you'll lose all historic statistics for the integration. There doesn't appear to be any way of saving these :(

    If you still have historic data after your removal of statistics, please follow the steps again as you should have no data available.

    opened by BottlecapDave 0
  • On Intermittent mode can the total size in minutes of the upcoming block be reported

    On Intermittent mode can the total size in minutes of the upcoming block be reported

    Feature request.

    I'm trying to use my inverter's force_charge(minutes) feature along side the intermittent mode to make best use of the cheapest overnight 30 minutes blocks. However my problem is as the 30 minutes blocks can follow each other and would therefore only fire one off->on trigger I can't use a default of 30 in the force_charge command. If there was a simple mechanism which reported the current block size then I could use that for the force_charge command and greatly simplify my automation trigger setup, plus reduce the number of commands sent to the inverter.

    enhancement 
    opened by Far2Sleepy 1
Releases(v5.1.0)
  • v5.1.0(Dec 28, 2022)

    5.1.0 (2022-12-28)

    Bug Fixes

    • sensor: Added back m3/kWh calculations for gas sensors (820abde)
    • sensor: Added last_reset attribute to cost/reading sensors (2861796)
    • sensor: Removed SMETS1 configuration as it's no longer used (eb49841)
    • sensor: Updated min consumption data to be in calculation (4f55e8d)

    Features

    • binary-sensor: Updated next saving session to include end date and duration in minutes (4d78a00)
    • sensor: Added sensors for current standing charges for electricity and gas (24641f8)
    • sensor: Updated standing charge to be more specific (521d9fc)
    Source code(tar.gz)
    Source code(zip)
  • v5.0.0(Dec 17, 2022)

    5.0.0 (2022-12-17)

    Bug Fixes

    • sensor: Fixed state class for sensors to "total" (fda8df6)

    BREAKING CHANGES

    • sensor: This fix causes long term statistics for the sensors to break. To rectify this, visit https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/108
    Source code(tar.gz)
    Source code(zip)
  • v4.7.1(Dec 8, 2022)

  • v4.7.0(Dec 4, 2022)

    4.7.0 (2022-12-04)

    Bug Fixes

    • binary-sensor: Fixed issue with rates mismatch and multiple meters (1050fd4)
    • binary-sensor: Updated target rate sensors to work with export based meters (0d4757b)
    • sensor: Fixed issue with rates update (a2fead5)
    • sensor: Updated sensors to support being restored after reboots (1f04b14)

    Features

    • binary-sensor: Added sensor for when joined saving sessions is active (93dbd9e)
    • sensor: Added saving sessions points sensor (94e465c)
    Source code(tar.gz)
    Source code(zip)
  • v4.6.5-beta1(Nov 4, 2022)

  • v4.6.4(Oct 27, 2022)

  • v4.6.3(Oct 26, 2022)

  • v4.6.2(Oct 25, 2022)

  • v4.6.1(Oct 22, 2022)

  • v4.6.0(Oct 16, 2022)

    4.6.0 (2022-10-16)

    Bug Fixes

    • binary-sensor: Fixed issue when sensor is active and calculated on the end date of the last rate (917f9b5)

    Features

    • api-client: Moved conversion of rates to 30 minute increments to separate testable function (412599f)
    Source code(tar.gz)
    Source code(zip)
  • v4.5.1(Oct 2, 2022)

  • v4.5.0(Oct 1, 2022)

    4.5.0 (2022-10-01)

    Bug Fixes

    • binary-sensor: Fixed issue when start/end time isn't set (7ab9b2d)
    • Fixed day/night times for economy 7 tariffs when using a smart meter. Thanks @696GrocuttT (c860a8a)
    • Updated consumption sensors to wait for more than 2 charges to be present (aa97647)

    Features

    • binary-sensor: Added facility to restrict target rates sensors from only reaching the target once a day (67d2993)
    Source code(tar.gz)
    Source code(zip)
  • v4.4.0(Jul 23, 2022)

  • v4.3.0(Jul 4, 2022)

    4.3.0 (2022-07-04)

    Bug Fixes

    • api-client: Updated get_account to use graphql so that inactive meters are ignored (f05dcd9)
    • sensor: Fixed gas sensor (975f4fe)
    • Updated translations to not include title as not needed (43d1a0e)

    Features

    • sensor: Added rate information to current electricity rate sensor (cfb4043)
    • sensor: Updated electricity and gas sensors to be associated with devices (38d8adb)
    Source code(tar.gz)
    Source code(zip)
  • v4.2.1(Jun 18, 2022)

  • v4.2.0(May 7, 2022)

    4.2.0 (2022-05-07)

    Features

    • binary_sensor: Updated target rate sensors to be updatable (a6fbcca)
    • binary-sensor: Added ability to apply offsets to target rate sensors (faafa1b)
    • sensor: Moved targeting sensor update logic to external functions (74908e1)
    • sensor: Updated sensor icons to be gbp instead of usd (66dfc54)
    Source code(tar.gz)
    Source code(zip)
  • v4.1.3(Mar 23, 2022)

  • v4.1.2(Mar 22, 2022)

  • v4.1.1(Mar 22, 2022)

  • v4.1.0(Mar 22, 2022)

  • v4.0.0(Mar 7, 2022)

    4.0.0 (2022-03-07)

    Bug Fixes

    • Fixed support for meters that both import and export electricity (Thanks @696GrocuttT) (1391dc8)

    Features

    • config: Updated selecting target meters for target sensors to be more user friendly (b1dc00f)
    • sensor: Added tariff code to electricity and gas consumption sensors (a728652)
    • sensor: Updated electricity sensors to include is_export attribute (d35967e)
    • sensor: updated gas sensors to include mprn in name (af528ef)
    • sensor: Updated previous gas consumption to display kwh and m3 values in attributes (745c51f)

    BREAKING CHANGES

    • sensor: This has been updated for consistency with the electricity sensor changes
    • Unfortunately in order to support import/exports, electricity sensors now include both the mpan and serial number in their name. This means you will need to update any automations or dashboards that rely on these sensors.
    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Jan 15, 2022)

  • v3.0.4(Jan 1, 2022)

  • v3.0.3(Jan 1, 2022)

  • v3.0.2(Dec 28, 2021)

  • v3.0.1(Dec 23, 2021)

  • v3.0.0(Dec 22, 2021)

    3.0.0 (2021-12-22)

    Bug Fixes

    • sensor: Removed code for falling back on fixed tariffs if no agreement is found (9a5045b)

    Features

    • sensor: Added sensors for accumulative cost of gas for the previous day (42a1408)
    • sensor: Created coordinator for retrieving current reading and created initial electricity consumption cost (4f09269)
    • sensor: removed current consumption sensors due to insufficient data provided by Octopus Energy (0470ff3)
    • sensor: Removed registering of current consumption sensors (d263a68)
    • sensor: Updated previous day consumption to only be valid if enough data points are available (9e71ef2)
    • sensor: Updated previous day cost sensor to include breakdown and standing charges (6618246)
    • updated docs (dff4d16)

    BREAKING CHANGES

    • We no longer fall back to fixed rate agreements if an active agreement can't be found. This was added by mistake when people were not receiving sensors when they had moved home and therefore an inactive house was being picked up. This means that some sensors may disapper, but these should just be inactive meters.
    • sensor: Latest consumption sensors are no longer available, which may cause issues anywhere they are used.
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Nov 10, 2021)

    2.0.0 (2021-11-10)

    Bug Fixes

    • api-client: fixed get_account to find the first property that hasn't been moved out of (970a7a5)

    BREAKING CHANGES

    • api-client: This change could cause the sensors associated with your meters to change, as they may have been associated with a property you had moved out of
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Oct 30, 2021)

  • v1.1.0(Oct 17, 2021)

    Features

    • Support for duel register tariffs (e.g. where you have different day/night rates)

    Bug Fixes

    • Support for account configuration that was setup before the introduction of SMETS1 configuration.
    Source code(tar.gz)
    Source code(zip)
Owner
David Kendall
David Kendall
Pylorawan is a Micropython wrapper for lorawan devices from RAK Wireless.

pylorawan Pylorawan is a Micropython wrapper for lorawan devices from RAK Wireless. Tested on a Raspberry PI Pico with a RAK4200(H) Evaluation Board (

Peter Houghton 3 Nov 04, 2022
Code reimplementation of some papers published in SAIL-Lab

SAIL SAIL-Lab统一代码库 Motivation 创建这个项目的动机最早来源于实验室组内成员相互Debug代码的时候遇到的麻烦。

Jianwen Chen 8 Nov 15, 2022
DongshanPI Seven for STM32MP157DAC.

STM32MP1 Buildroot External Tree

DongshanPI 14 May 06, 2022
HA-Edge-Connector - HA Edge Connector For Python

HA-Edge-Connector 1. Required a. Smartthings Hub & Homeassistant must be in same

chals 21 Dec 29, 2022
Small Robot, with LIDAR and DepthCamera. Using ROS for Maping and Navigation

🤖 RoboCop 🤖 Small Robot, with LIDAR and DepthCamera. Using ROS for Maping and Navigation Made by Clemente Donoso, 📍 Chile 🇨🇱 RoboCop Lateral Fron

Clemente Donoso Krauss 2 Jan 04, 2022
This repository contains all the code and files needed to simulate the notspot quadrupedal robot using Gazebo and ROS.

Notspot robot simulation - Python version This repository contains all the files and code needed to simulate the notspot quadrupedal robot using Gazeb

50 Sep 26, 2022
2021 Real Robot Challenge Phase2 attemp

Real_Robot_Challenge_Phase2_AE_attemp We(team name:thriftysnipe) are the first place winner of Phase1 in 2021 Real Robot Challenge. Please see this pa

Qiang Wang 2 Nov 15, 2021
Philippe 1 Jan 09, 2022
Setup DevTerm to be a cool non-GUI device

DevTerm hobby project I bought this amazing device: DevTerm A-0604. It has a beefy ARM processor, runs a custom version of Armbian, embraces Open Sour

Alex Shteinikov 9 Nov 17, 2022
Home Assistant custom integration for e-distribución

e-Distribución is an energy distribution company that covers most of South Spain area. If you live in this area, you probably are able to register into their website to get some information about you

VMG 17 Sep 07, 2022
View your medication from Medisafe Cloud in Home Assistant

Medisafe View your medication from Medisafe Cloud in Home Assistant. This integration adds sensors for today's upcoming, taken, skipped, and missed do

Sam Steele 12 Dec 27, 2022
The software that powers the sPot: a 4th generation

This code is meant to accompany this project in which a Spotify client is built into an iPod "Classic" from 2004. Everything is meant to run on a Raspberry Pi Zero W.

Guy Dupont 683 Dec 28, 2022
DIY split-flap display

The goal is to make a low-cost display that's easy to fabricate at home in small/single quantities (e.g. custom materials can be ordered from Ponoko or similar, and other hardware is generally availa

Scott Bezek 2.5k Jan 05, 2023
Home Assistant custom integration for Yi cameras: yi-hack-MStar, yi-hack-Allwinner and yi-hack-Allwinner-v2

yi-hack Home Assistant integration Overview yi-hack Home Assistant is a custom integration for Yi cameras (or Sonoff camera) with one of the following

roleo 131 Jan 03, 2023
Adafruit IO connected smart thermostat based on CircuitPython.

Adafruit IO Thermostat Adafruit IO connected smart thermostat based on CircuitPython. Background and Motivation I have a 24 V Heat-only system with a

Shubham Chaudhary 1 Jan 18, 2022
Automatic Watering System using Soil Moisture Sensor and RTC Timer with Arduino

Automatic-Watering-System - Technical Answers to Real-World Problems. Evolution of Watering Manually to Watering Automatically.

Vaishnavi Pothugunta 4 Dec 31, 2021
Modeling and Simulation of Satellite Servicing Manipulators

Modeling and Simulation of Satellite Servicing Manipulators Final Project for the course ENPM662: Introduction to Robot Modeling (Fall 2021). This pro

Adarsh M 1 Jan 24, 2022
ModbusTCP2MQTT - Sungrow & SMA Solar Inverter addon for Home Assistant

ModbusTCP2MQTT Sungrow & SMA Solar Inverter addon for Home Assistant This addon will connect directly to your Inverter using Modbus TCP. Support model

Teny Smart 40 Dec 21, 2022
Iec62056-21-mqtt - Publish DSMR P1 telegrams acquired over IEC62056-21 to MQTT

IEC 62056-21 Publish DSMR P1 telegrams acquired over IEC62056-21 to MQTT. -21 is

Marijn Suijten 1 Jun 05, 2022
Python information display framework aimed at e-ink devices

My display, using a Raspberry Pi Zero W and Waveshare 6" e-paper hat infodisplay Modular information display framework aimed at e-ink devices. Built u

Niek Blankers 3 Apr 08, 2022