The server at api.givenergy.cloud has been returning no data and a 401 code since 6pm tonight.
Overnight solar forecasting (SmartTarget, etc) is based on historical data from this server and may be affected.
Anyone from GE able to give the server a nudge please!
+1
Hey there,
We usually take these claims very seriously but I've just tried a number of endpoints and I'm not getting the same response. Would appreciate if you know how this was replicated
401 is not authorised.
Any security updates as I know changes were coming with the app.
Does the version of palm that is part of the GivTCP home assistant addon use the API, or does it use the data in home assistant to work out the load?
I can’t see any errors in the GivTCP logs.
It worked out the previous usage and set a target SOC successfully. 😀👍🏽
Mickey (GivEnergy) This is what I'm seeing. I have a version of the code that's been running since this time yesterday and was fine into 18:05, so API keys, etc unchanged at this end. Running a new instance of the code gives this error:
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.givenergy.cloud:443
DEBUG:urllib3.connectionpool:https://api.givenergy.cloud:443 "POST /v1/inverter/CE2146G203/settings/77/read HTTP/1.1" 401 None
ERROR: PALM:Invalid response: 401
TX200 It also uses the API. However, there is a set of default consumption data preloaded. Running standalone palm here, it goes through the motions but yields the wrong answer. The issue was more obvious to me as I pull the GE data and upload it to pvoutput.org and it has been flatlining.
kram @Mickey (GivEnergy) I have regenerated my API key and the issue is now resolved. Looks like either a security change on the GE server or someone deleted my key there accidentally (it certainly wasn't me!).
Curiously the new key is 1 character longer than the previous one...
Interesting your error shows you trying to connect to https but post is http.
I’d suggest the extra character is an s in the preamble.
I assume API access is now mandatory https?
Shouldn't really be using non secured comms, especially with API keys - somewhat lessens their effectiveness!
Late to the party but been on hols. It appears my API key was also killed off last week in my absence (401's both getting data out but also trying to push power data back into the portal as well)
A bit annoying - will regen the keys and go through and update all my scripts when I get a spare min.
At least im consistent, National Grid decided to change all theirs which broke most of TerraVolt's Gas tracking too (why is it always when I'm away!)
looks like my API key has been killed as well.
2023-08-01 19:00:04,980 - battery.configBatteryCharge - ERROR - HTTP request to charge battery failed: 401 Unauthorized attempt 1
2023-08-01 19:00:04,981 - battery.configBatteryCharge - INFO - HTTP response {"message":"Unauthenticated."}
Will create a new key and try again
locked @TheDragon (GivEnergy) any idea what's happening with API keys? Were/are they being issued with a set validity and expiring or is something else going on?
Hi all,
There was an oversight on our part - the library we use for our API authentication generates tokens that expire after 1 year by default which we haven't been aware of until today.
We have raised an issue internally to modernise the API token creation process which will include the ability to set token scopes (abilities), modify the lifetime and more.
We will be issuing a mass email to customers that have generated an API token that expires within the next month to notify them of this.
Thanks Sam, good to see that I wasn't getting special treatment 😁
Sam D (GivEnergy) expires within the next month to notify them of this.
Sam, maybe it'd be helpful to have a system where the customer gets an email a couple of weeks before the current key expires? I had an email from you last July because there was a wholesale change that required everyone to regenerate their API keys. It looks like mine is good until 13th August, but it would be good to get that reminder automatically triggered beforehand.
stevelewis yep, some people have email OCD so I just searched for the last time I generated an API key; that’s how I also found the email from Sam which I had forgotten about (hence obsessive email filing).
Different scopes sounds good though. Opens the doors to more apps/partners where your not handing absolute control over to a mystery entity whose security of that key may or may not be upto scratch.
I guess along the lines of you can give your car charger / ASHP / whatever manufacturer access to "pause" but not allow it to screw with your timers or plugs or get your identifying information/email etc from the accounts pages and so on.