Opower not working for PSE #99674
Comments
|
Hey there @tronikos, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) opower documentation |
|
This is likely the same as tronikos/opower#32 and we need to reduce the |
|
+1 - Can confirm I am experiencing the same issue as detailed above. |
|
What's the startDate and endDate in your URL? |
|
I'm unable to reproduce the errors OP was getting with my own PSE account, using this (redacted) cli: However, I'm also unable to see any info in HA about my PSE account; it was working after initial release, but going in recently and clicking on one of the entities (such as |
|
I'm also having this issue. I tried out some different values of One thing to note, the PSE website also does not allow you to view daily costs. The daily view is only accessible when on the usage tab, not the costs tab. I believe the only possible solution is probably to get a bill history and calculate the cost per unit manually, then apply that to the daily/hourly data as well as the current bill. |
|
Coming here to also mention this integration isn't working for PSE. I've had it set up for at least a month or so, and there is no information in my Energy dashboard about it. I just gave reloading the integration a shot, and looks like it's just pulling Sensors that all show 0: I just turned on debug logging and got this bit of info: I can confirm I am able to view energy use by day/hour and cost per month on the PSE website. If I can help somehow (I have no coding knowledge or knowledge of how to PR or anything like that in Github) I am happy to, looks like this hasn't worked since the Opower integration launched. |
|
I'm using the docker version and I can't PSE to work either. The documentation is rather poor, I'm assuming I use my PSE website credentials with the OPower integration. In my cause it just keeps failing to initialize without any errors. OPower accepts the credentials and starts trying to initialize, it takes a long time. Even with debug it doesn't really show what's going on. UPDATE: Deleted and readded, trying to get more information from Home Assistant. First initialization takes 8 minutes to fail with the I'm using my Puget Sound Energy (PSE) website login information. On PSE's site, I can see my usage data. I changed logger on HA to debug globally and still no useful information, sorry. |
|
Yesterday I added the Opower integration for use with my PSE account and it seems to work okay for me. No errors in the logs and it added my GAS and ELEC accounts. Cost values are all zero, but usage values are correct. I configured my Energy dashboard to include the Opower pse gas and elec consumption entities and I get very nice hourly plots of usage! I checked the HA database and see the hourly data in the statistics table. |
I did, browser dev tools even showed it getting data from pse.opower.com I wonder why the integration doesn't work for me, though. |
|
I noticed I was running the linuxserver/version of the container so I switched to the official one today. Unfortunately, the same problem persists. Core version is 2024.1.2
Are there any logging/debug options I can enable to get more information? If I run the stand alone OPower (https://github.com/tronikos/opower) I get usage data: NOTE: We don't use gas very often anymore so the 0's are normal for us. If I copy demo.py from the OPower project for the Home Assistant container to use and run OPower directly from a bash terminal window, I get usage data. So I think this is a bug in the HA integration. (I have no idea what's with the exception at the end, it doesn't occur in the HA container run.) |
|
Can you try with the latest home assistant release? There was a recent fix that disabled ipv6 for this integration that was causing issues for many |
I can as soon as the official container gets updated. |
|
Disabling ipv6 was included in 2024.1.1 |
Then that hasn't helped. Current Version Info
If I run If I run the integration, it never successfully initializes and even with debug on I don't get any error messages, just that it failed. (Even with debug on). It's frustrating because if I could at least get it to show me any errors, I might have an idea what it's not happy with. If someone can even direct how to get this integration to report actual debug information (specifically the error messages), that would help. |
|
If you search for Opower in http://homeassistant.local:8123/developer-tools/statistics do you see any rows there? Can you try to replicate core/homeassistant/components/opower/coordinator.py Lines 193 to 227 in 3a4c64b |
There seem to be some (all 0), which is odd because I've deleted the integration for now.
PSE doesn't supply costs so probably not.
|
|
Ok, I re-added OPower and turned on debug on everything to try to isolate what may be making this not work. I've discovered a couple minor things:
I have gone through the full debug log file and done a grep to build a (hopefully) OPower specific debug log. I have redacted sensitive information. I still have the raw file. It seems to me that the main issue is that OPower thinks the integration setup is failing (maybe due to lack of cost data). It should probably realize it has usable data. |
|
To delete previous statistics you can follow steps at #107182 (comment)
Lacking cost data shouldn't be causing any issues. |
The odd thing is it's technically working; I can go back through the 'energy' dashboard in HA and it's populated (-2 days and back) but in integrations it still thinks it's failing and initializing. Is it because it doesn't have all the data yet? If that's all it is it should probably not act like it's broken. In summary it looks like this is working but is saying it's not from the HA's integrations (services) screen. |
|
Your logs end with: so it failed getting hourly data between 2020-05-31 and 2020-06-26 |
Yes < If you reload the integration does it make progress backfilling?
I need to learn how to do that first... standby. |
It doe snot backfill, because it has never marked as being successfully setup/initialized, it starts over from the beginning and stops when it gets to the May 31st 2020 - June 26th 2020 failure. Basically when it hits that failure, it stops and marks it all as failed which seems to be a bug or design issue. Subsequent runs start at the current day again and this just keeps repeating. I may need to disable it as I don't want my utility to block my account. It should accept usable data, skip failures, backfill if possible but it shouldn't come to a halt if something unexpected happens. |
The information I've found on this is:
For me the third option is unacceptable, I am only curious about the electricity usage as a 'hey might as well', it is not of much importance to my HA applications. |
|
The integration should probably remember that no cost data is available and stop requesting it in large batches. |
|
Usage and cost data are requested together. You can follow #107182 (comment) to delete all opower statistics. Since yours failed at |
|
Wait I just realized it tried to fetch hourly data for a period way in the past. It should only be fetching hourly data for the past 2 months, daily data for the past 3 years, monthly data for all years. It should be fetching everything in under a couple of minutes. Opower only keeps granular data for a bit over than 3 years (I think 3.5?) which explains why you got 500 for that time period. Was the date ever wrong on your system? Delete all opower statistics following #107182 (comment) to start from scratch. |
|
I think your system date was at some point wrong. It fetched and wrote statistics. If there are existing statistics the integration fetches hourly data since the last statistic. One solution to avoid this is to cap how long back to go at |
|
The system date was never wrong. It's in a docker container and gets time from the host. |
|
Can you:
|
Working on it, no add-on so I'm using a SQLite editor on my Windows machine (I backed up the database of course). UPDATE: Does OPower have any other database entries? NOTE: The costs query tries to go back to 2019-11-20. BTW: The log has "Updating statistic for the first time" so last_stat is not set when This really needs a flag to disable costs entirely. |
|
I'm getting the same issue with Atlantic City Electric. Here is the error message I'm getting: I've tried following the steps in opower atlantic city electric #107182 (comment) After re-adding it, I don't get any rows when I query the |
|
Gave it another try today! it's working! |
I got it working at first, then not working. I'll remove and add it again, hoping it will "stick" to working. It's been working fine now. It has about 24-36 hours delay in getting the data, but it gets it. |
|
Thank you, tried it again for Atlantic City Electric and it's working. Hope it continues to function. |
|
I tried the SQLITE from the ACElectric post, but am still not getting results from pse. Any suggestions on next steps? I'm getting 0s except for typical monthly usage. |
|
... and it wanted me to authenticate (which was successful, so it claims) and now it's broken again. Debug logging is not giving me much information: I'm also not sure why it's trying to get information from near 4 years ago, it worked for around a week just fine and then this starting with it needing to re-authenticate. This code really needs the ability to set a limit for how far "back" to go. UPDATE: Even though it keeps saying it failed setup in services, it is actually populating data each day. I'm not comfortable leaving it enabled, however, since it spams PSE every 40 seconds. So because it can't get data from 2020, it considers setup a failure. That's just bad code. |
|
If you are getting error at |
|
I'm also having an issue with pulling data from PSE but just the gas side. I completed the steps to delete the statistics then re-adding the addon and still same issue. I have all of the past gas consumption through 2023 but as of the start of 2024 it is completely blank. Logs just have the following. I also confirmed the usage is displayed on my online account so far for 2024.
|
|
Deleting statistics was only necessary if you were getting errors at |
|
Continue to fail to get Opower working again with PSE. Deleted the integration, performed the SQLite steps to clean from database and attempt to add again. |
|
I'm back to having to re-enable the service in Home Assistant and then disabling it again so it doesn't spam PSE. Once again, it's actually able to get recent data, but it then tries to get data over 5 years old which the API returns with a 500 server error. I'm not sure opower seems determined to crawl back that far and I realize this Home Assistant package of OPower may not be able to do anything about it but it is annoying. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
This integration with PSE Still doesn't work reliably. I removed the integration some months ago. I just added it again today after getting the above notification from issue-triage-workflows, and there is no current electric bill cost to date, no current bill electric forecasted cost, and no typical monthly eletric cost. The kwh usage exists for current bill forecasted, usage, and typical, but not sure why the costs don't populate. Core |
|
I removed the PSE configuration because it wasn't working, and then added it back, but now have no services or entities. 
|
Can confirm the same for BGE (Baltimore Gas and Electric) Prior to removing/readding I noticed all entities were "Unavailable" and read "The integration is no longer providing this entity." |
|
Not having entities/sensors is expected for many utilities. Do you have statistics? Per documentation you need to use those in the energy dashboard. |
I do not. It is no longer populating in my energy dashboard. |
Same thing with me and PSE. Even tried deleting the database using SQLite and still nada. |
|
Enable debug logging and attach logs |
|
Welp, I went to go reload the integration to capture another log and of course everything is now working as expected after several weeks of issues. Will return should the problem return. |
and others
The problem
Continually recieve internal server error when setting up Opower for PSE. Log message is
Config entry 'Puget Sound Energy (PSE) (sethrait)' for opower integration not ready yet: 500, message='Internal Server Error', url=URL('https://pse.opower.com/ei/edge/apis/DataBrowser-v1/cws/cost/utilityAccount/<ACCOUNT_NUMBER>?aggregateType=day&startDate=2022-07-10T00:00:00-07:00&endDate=2023-07-08T00:00:00-07:00'); Retrying in backgroundWhat version of Home Assistant Core has the issue?
core-2023.8.4
What was the last working version of Home Assistant Core?
NA
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Opower
Link to integration documentation on our website
https://www.home-assistant.io/integrations/opower
Diagnostics information
Logs from running opower's demo.py locally (with certain values redacted):
python : DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetching: https://pse.opower.com/ei/edge/apis/multi-account-v1/cws/pse/customers?offset=0&batchSize=100&addressFilter=
At line:1 char:1
DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetched: {
"customers": [
{
"id": REDACTED_ID,
"uuid": "REDACTED_UUID",
"legacyOpowerId": "43-1-5ff8aa",
"accountNumber": "REDACTED_ACCOUNT_NUMBER",
"accountName": "REDACTED_ADDRESS",
"address": {
"uuid": "",
"streetNumber": "",
"streetName": "****",
"subpremise": null,
"postalCode": "*****",
"city": "SEATTLE",
"country": "US",
"state": "WA"
},
"type": "RESIDENTIAL",
"utilityAccounts": [
{
"id": REDACTED_ID,
"uuid": "REDACTED_UUID",
"utilityAccountId": " REDACTED_ID_2",
"utilityAccountId2": null,
"servicePointId": REDACTED_ID_3,
"meterType": "GAS",
"preferredUtilityAccountId": " REDACTED_ID_2",
"readResolution": "QUARTER_HOUR"
}
]
}
],
"offset": 0,
"batchSize": 100,
"total": 1
}
DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetching: https://pse.opower.com/ei/edge/apis/bill-forecast-cws-v1/cws/pse/customers/REDACTED_UUID/combined-forecast
DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetched: {
"isValidUser": true,
"totalForecast": {
"meterType": "COMBINED",
"startDate": "2023-09-02",
"endDate": "2023-10-01",
"currentDate": "2023-09-05",
"daysInPeriod": 30,
"currentDay": 4,
"daysLeftInBill": 26,
"forecastedUsage": 114,
"forecastedCost": 0,
"typicalUsage": 169,
"typicalCost": 0,
"budgetBilling": false,
"costToDate": 0,
"usageToDate": 8,
"currencySymbol": "$"
},
"totalMetadata": [
"NO_FORECASTED_COST",
"ESTIMATED_PREVIOUS_BILL"
],
"accountForecasts": [
{
"unitOfMeasure": "THERM",
"meterType": "GAS",
"startDate": "2023-09-02",
"endDate": "2023-10-01",
"currentDate": "2023-09-05",
"daysInPeriod": 30,
"currentDay": 4,
"daysLeftInBill": 26,
"forecastedUsage": 9,
"typicalUsage": 14,
"budgetBilling": false,
"usageToDate": 1,
"currencySymbol": "$",
"preferredUtilityAccountId": "REDACTED_ID_2",
"accountUuids": [
"REDACTED_UUID"
],
"isSolar": false
}
]
}
DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetching:
https://pse.opower.com/ei/edge/apis/DataBrowser-v1/cws/cost/utilityAccount/REDACTED_UUID?aggregateType=day&startDate=2023-08-29T00%3A00%3A00-07%3A00&endDate=2023-09-06T00%3A00%3A00-07%3A00
DEBUG:C:\Users\sethr\repos\opower\src\opower\opower.py:Fetched: {
"servicePointId": "6001816530",
"utilityAccountUuid": "REDACTED_UUID",
"unit": "THERM",
"siteTimeZoneId": "America/Los_Angeles",
"reads": [
{
"startTime": "2023-08-29T00:00:00.000-07:00",
"endTime": "2023-08-30T00:00:00.000-07:00",
"value": 0,
"readType": "ESTIMATED",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 0
},
{
"startTime": "2023-08-30T00:00:00.000-07:00",
"endTime": "2023-08-31T00:00:00.000-07:00",
"value": 0.22,
"readType": "ESTIMATED",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 2
},
{
"startTime": "2023-08-31T00:00:00.000-07:00",
"endTime": "2023-09-01T00:00:00.000-07:00",
"value": 0.34,
"readType": "ESTIMATED",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 4
},
{
"startTime": "2023-09-01T00:00:00.000-07:00",
"endTime": "2023-09-02T00:00:00.000-07:00",
"value": 0.48,
"readType": "ESTIMATED",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 6
},
{
"startTime": "2023-09-02T00:00:00.000-07:00",
"endTime": "2023-09-03T00:00:00.000-07:00",
"value": 0.64,
"readType": "ESTIMATED",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 8
},
{
"startTime": "2023-09-03T00:00:00.000-07:00",
"endTime": "2023-09-04T00:00:00.000-07:00",
"value": 0,
"readType": "ACTUAL",
"providedCost": 0,
"readComponents": [],
"isPeakPeriod": false,
"rebateAmount": 0,
"milesDriven": 0
}
],
"seriesComponents": [],
"ratePlans": []
}
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: