Open braindeadmalc opened 1 month ago
Cheers- sheer coincidence that I only started to try and control discharge after the sun had gone in for the year in Lancashire, so didn't see the link!
I'll wait for the merge- I'm not a PYTHON fan...
Thanks again for all your effort on this.
Peter
From: Joshua Leaper Sent: Monday, November 4, 2024 9:40 AM To: CharlesGillanders/homeassistant-alphaESS Cc: pjhum ; Mention Subject: Re: [CharlesGillanders/homeassistant-alphaESS] "Alpha ESS: Set Battery Charge" not setting (Issue #138)
you can use the visual studio code add-on, but i would not recommend it if you are not sure, rather wait for the PR to be merged
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I made the change, however it did not seem to resolve the issue
assuming you have restarted home assistant after making the change, and waiting 10 mins (since the last press as there is a cooldown implemented by alphaess)
Does anything show in the app? the fix worked for me, and i can show a video verifying if you'd like?
i would just recommend waiting for the patch and then giving it a go
so when i click 30min discharge - after making the changes - it just starts charging.
Interesting. i would wait for the .1 release, and update. if this still occurs you can make another issue. it could be case of you have changed the wrong variable.
I am a little unclear here about the scope of this fix. Does this fix the new force charge/discharge feature only, or does it also fix the wider issue of the failure to set charge/discharge parameters via automations?
Does this fix the new force charge/discharge feature only
It only fixes the features offered by this integration, so if there is any automations tied to it (that uses this) it will be fixed.
Not sure what external providers like Amber use tho, so it wont fix that
I'll check what happens when my automations run (trigger the actions to make the set charge / discharge) this evening
The charge should work, the discharge wont until the latest PR is merged
I’ve had a response from Alpha UK- they suggest trying using a different URL for the API-https://apiservice-eu.alphaess.com/v1/Open/XXXXX
I don’t know which URL the integration uses. If it isn’t this I need to find some tools to interrogate the API manually, I guess…
Peter
I got this response from UK support:
"Could you please update the URL and API address to below and try again? European Center URL: https://apicloud-eu.alphaess.com/ European Center API address: https://apiservice-eu.alphaess.com/v1/Open/XXXXX "
Not sure what i need to do with it though. I get user "user does not exist" if i try the URL.
You need an API test tool- Postman or whatever.
I've downloaded SoapUI which is free but I'm struggling to frame a request (any request) to test it. The API documentation is just that, not a tutorial... plus I've never used the software before.
I'm on some other training tomorrow but will have a dig later in the week if I get time- though for it to help in HA the source code for the integration would have to be updated anyway. Thinking about it, that might be the easiest test path.
The update has been pushed, so you can force the fetch the new update by going onto the integration (on the HACS page), click on the three dots (⋮) on the integration’s card and then update information
"Could you please update the URL and API address to below and try again? European Center URL: https://apicloud-eu.alphaess.com/ European Center API address: https://apiservice-eu.alphaess.com/v1/Open/XXXXX "
Interesting, we dont keep the baseURL (aka the URL to the API) anywhere in this repo, its kept in the openAPI repo here
Changing that as the end user is not easy, and i would recommend if you want to test it, you use something like postman (there is a example collection in that openAPI repo)
Maybe try the .1 release that just got put out and see if that fixes it. otherwise might need to re-work where the base URL is deprived from.
Explains why I couldn't find the base URL in the repository files. I'll have a go at trying to query the 'new' API if the update brings no joy. Peter Sent from Android deviceOn 4 Nov 2024 23:12, Joshua Leaper @.***> wrote:
"Could you please update the URL and API address to below and try again? European Center URL: https://apicloud-eu.alphaess.com/ European Center API address: https://apiservice-eu.alphaess.com/v1/Open/XXXXX "
Interesting, we dont keep the baseURL (aka the URL to the API) anywhere in this repo, its kept in the openAPI repo here Changing that as the end user is not easy, and i would recommend if you want to test it, you use something like postman (there is a example collection in that openAPI repo) Maybe try the .1 release that just got put out and see if that fixes it. otherwise might need to re-work where the base URL is deprived from.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
The update has been pushed, so you can force the fetch the new update by going onto the integration (on the HACS page), click on the three dots (⋮) on the integration’s card and then update information
Hi, I've tried the update on my B3 and no joy I'm afraid.
Also, for info, I've had no update on my case from Alpha recently.
Still no good for me setting 1 hour discharge just sets a 1hour window the battery can be drawn from the load … it not dispatching
Sent from Outlook for iOShttps://aka.ms/o0ukef
From: braindeadmalc @.> Sent: Tuesday, November 5, 2024 6:50:30 PM To: CharlesGillanders/homeassistant-alphaESS @.> Cc: renamedthewild @.>; Comment @.> Subject: Re: [CharlesGillanders/homeassistant-alphaESS] "Alpha ESS: Set Battery Charge" not setting (Issue #138)
The update has been pushed, so you can force the fetch the new update by going onto the integration (on the HACS page), click on the three dots (⋮) on the integration’s card and then update information
Hi, I've tried the update on my B3 and no joy I'm afraid.
Also, for info, I've had no update on my case from Alpha recently.
— Reply to this email directly, view it on GitHubhttps://github.com/CharlesGillanders/homeassistant-alphaESS/issues/138#issuecomment-2456515670, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL3QDYNXCCRBWGDX5YIQMBDZ7B5U5AVCNFSM6AAAAABQHTBGF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGUYTKNRXGA. You are receiving this because you commented.Message ID: @.***>
Same with me; Storion Smile B3 is not working on charge or discharge setting even with the .1 update. Peter
Just curious, if you click it, then open the app (fresh open the app) then have a look at the dis-charge settings, does it show there?
No, the app settings reflect whatever I last set in the Alpha app. I suspect it is an Alpha issue. I need to get my head round framing a suitable HTTP request to test the alternative URL, but I'm sitting through seven hours of CPC training today
Peter
so what is the expected outcome when i push discharge 60mins now ?
This is all I get when I press the button, however this is not dispatching this is just discharge timed control..
Can this API dispatch ?
That is the expected outcome for your inverter it seems, per the API:
According to SN Set discharge information,Setting frequency 24 hours, set once a day
I read that it had previously been lifted to once in 10 minutes?
From: Joshua Leaper Sent: Tuesday, November 5, 2024 10:36 AM To: CharlesGillanders/homeassistant-alphaESS Cc: pjhum ; Mention Subject: Re: [CharlesGillanders/homeassistant-alphaESS] "Alpha ESS: Set Battery Charge" not setting (Issue #138)
That is the expected outcome for your inverter it seems, per the API:
According to SN Set discharge information,Setting frequency 24 hours, set once a day
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
That is the expected outcome for your inverter it seems, per the API:
According to SN Set discharge information,Setting frequency 24 hours, set once a day
It was definitely once every 10 minutes. There was a huge backlash at the one every 24hrs rule so it was allowed more frequently
Oh ok - sorry assumed open API could configure battery dispatching - so you could discharge your battery to the grid during high prices Sent from my iPhoneOn 5 Nov 2024, at 21:06, Joshua Leaper @.***> wrote: That is the expected outcome for your inverter it seems, per the API:
According to SN Set discharge information,Setting frequency 24 hours, set once a day
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Yeah, it was reduced for being able to set it every 10 mins, clearly the API docs weren't updated 🙄
Oh ok - sorry assumed open API could configure battery dispatching - so you could discharge your battery to the grid during high prices
Honestly that's what I thought, but different batteries may behave differently
oh well back to modbus it is
@renamedthewild what model are you connecting via modbus? I can't get my B3 to respond on RS485 (it doesn't support modbus over TCP) whatever I try...
SMILE5-INV EMS 2.01
No issues with Modbus using the RS485 port (ethernet adaptor)
just trying to save having to mess around with all that stuff just so they can sell a few kWh between 6-9pm lol
I also use my self a SMILE-T10-HV-INV - that has modbus over TCP and that works amazing
The original B3 seems a bit of an outlier. did you have to mess about to get the converter working? mine is set up as a simple TCP server with the serial side on 9600 no parity as per the docs I can find. HA has RTU over TCP set, but getting nothing.
My freebie modbus tester connects to the bridge just gets time outs.
Now thinking the B3 doesn't do modbus at all...
From: renamedthewild Sent: Tuesday, November 5, 2024 11:59 AM To: CharlesGillanders/homeassistant-alphaESS Cc: pjhum ; Mention Subject: Re: [CharlesGillanders/homeassistant-alphaESS] "Alpha ESS: Set Battery Charge" not setting (Issue #138)
I also use my self a SMILE-T10-HV-INV - that has modbus over TCP and that works amazing
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I have now downloaded the new 5.6.1 release and will see whether changing the charge/discharge settings via automation (service call) works this evening with my SMILE B3.
I just got another response to my support ticket from Alpha. I'm not quite sure where this leaves us,
"Sorry for our late reply. According to the Web API team, there are no reported issues with the OpenAPI command integration at this time. Could you please try again? For questions related to OpenAPI, we recommend reaching out on the GitHub forum, where additional support is available. Thank you for your understanding"
Looking on the German users' forum, it seems European data is now stored on the (new) European server. I suspect this is also hosting the new API that UK customer support gave me. (https://apiservice-eu.alphaess.com/v1/Open/XXXXX)
I'd been holding out for a reply from Alpha regarding this same issue on my one year old B3-plus. I got exactly the same response from them this morning as braindeadmalc.
Like others , I'd been able to set charge and discharge periods and desired SOC using the OpenAPI via Home Assistant a couple of times a day so as to make best use of Octopus Agile and prevailing weather conditions. Since the global update I can read SOC but cannot set it or charge periods via HA. I pulled the latest version of the OpenAPI yesterday. I believe I am on 0.5.6.1 version.
Interesting, seems like i'll have to make the API dynamic, and what will happen is you guys will have to manually edit your files and place the API URL in the files (will require an update to the integration + API)
Interesting, seems like i'll have to make the API dynamic, and what will happen is you guys will have to manually edit your files and place the API URL in the files (will require an update to the integration + API)
The optimum solution would be to have the API library be aware of both API endpoints and to accept a parameter that would select a specific endpoint for each time data is requested.
We would then be able to configure the Home Assistant integration with an extended setup dialogue that asked for a radio button type question "EU or worldwide API endpoint"
I can make the appropriate change to the library later this week.
Wonderful, ill see if i can get a full list of region specific list of URL's (if there is any more)
I'm in the UK and despite downloading 5.6.1 yesterday my automations still failed to effect any changes to the charge / discharge settings on of my SMILE B3 last night. It does however sound like you have a handle on this - thanks as always for the excellent work on this integration.
I've just been experimenting with the new EU URL https://apiservice-eu.alphaess.com/v1/Open/getLastPowerData . It seems to almost work, but every call fails with the error {'code': 103, 'info': 'Timestamp is Wrong!'}
Switching back to the old URL, it works again. Not sure if Alpha has updated the API in other ways too? I havent seen any doc updates.
The old api wanted the time stamp in the china time zone, with a 5 minute latitude. Which time zone did you timestamp it for? I can’t find any documentation either, though I’m still getting to grips with trying to interrogate the api.
Sent from my iPad
On 6 Nov 2024, at 22:50, Tony Butterfield @.***> wrote:
I've just been experimenting with the new EU URL https://apiservice-eu.alphaess.com/v1/Open/getLastPowerData . It seems to almost work, but every call fails with the error {'code': 103, 'info': 'Timestamp is Wrong!'} Switching back to the old URL, it works again. Not sure if Alpha has updated the API in other ways too? I havent seen any doc updates.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Im unfortunately not in the EU, so i wont be much help, but is there any documentation on this website: https://apicloud-eu.alphaess.com/#/?
I wish Alpha made this information easier to find! Does anyone know how to get login credentials for https://apicloud-eu.alphaess.com/#/ ? If I use the ones created on https://open.alphaess.com/login it says "no such user".
@pjhum on the original API the timestamp was in seconds since 1970 Epoch which should be timezone independent AFAIK
I've been wrong before...😉I was using the timestamp generator linked from the open API documentation, and it appeared to return a value in Beijing local time when I decoded it.May simply be the decoding that was corrected to their local time- Google wasn't making such a good job of translating the page from Chinese.I couldn't log in to the German server's API either, though I'm not confident my request was properly formed.PeterSent from Android deviceOn 7 Nov 2024 10:06, Tony Butterfield @.***> wrote: I wish Alpha made this information easier to find! Does anyone know how to get login credentials for https://apicloud-eu.alphaess.com/#/ ? If I use the ones created on https://open.alphaess.com/login it says "no such user". @pjhum on the original API the timestamp was in seconds since 1970 Epoch which should be timezone independent AFAIK
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
I am beginning to think that there is confusion within AlphaESS between the OpenAPI and their older commercial API services.
According to this page https://urlscan.io/domain/alphaess.com the apiservice.alphaess.com URL has been around since 2021, whereas the URL for openapi.alphaess.com is only from 2023.
In the absence of any comment on the OpenAPI developer portal I wonder if there's a chance that people are being given mistaken information by the EU support team?
I may be wrong but something got fixed! My automations seem to be working again. I've tried a few tests and I seem to be able to set the charging period via HA again.
I'm seeing the same thing as braindeadmalc. It does seem to be working.
I did, initially, find that my two automations were no longer valid. I pulled the latest GitHub version and it made no difference. So I investigated further and discovered that the SOC condition definition has changed from (whatever it was before, as I didn't write it down) to "current <serial number"_State of battery level . I made changes to my automations and I've run both automations a number of times and it appears to be setting the battery charge/discharge settings properly and quickly.
Fingers crossed !
Who ever has changed things to make it work .... thank you!
My original automations run overnight- I'll see if they've restarted working.If so, I'll then see if the new force charge/discharge features work on the B3.PeterSent from Android deviceOn 8 Nov 2024 18:08, purrcat33a @.***> wrote: I'm seeing the same thing as braindeadmalc. It does seem to be working. I did, initially, find that my two automations were no longer valid. I pulled the latest GitHub version and it made no difference. So I investigated further and discovered that the SOC condition definition has changed from (whatever it was before, as I didn't write it down) to "current <serial number"_State of battery level . I've run both automations a number of times and it appears to be setting the battery charge/discharge settings properly and quickly. Fingers crossed ! Who ever has changed things to make it work .... thank you!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Same here. Set battery charge finally worked today again. I'm in UK.
And had a message yesterday from UK support saying we should still be using the original open API address not the EU one.
On Fri, 8 Nov 2024, 7:48 pm pjhum, @.***> wrote:
My original automations run overnight- I'll see if they've restarted working.If so, I'll then see if the new force charge/discharge features work on the B3.PeterSent from Android deviceOn 8 Nov 2024 18:08, purrcat33a @.> wrote:
I'm seeing the same thing as braindeadmalc. It does seem to be working.
I did, initially, find that my two automations were no longer valid. I pulled the latest GitHub version and it made no difference. So I investigated further and discovered that the SOC condition definition has changed from (whatever it was before, as I didn't write it down) to "current <serial number"_State of battery level .
I've run both automations a number of times and it appears to be setting the battery charge/discharge settings properly and quickly.
Fingers crossed !
Who ever has changed things to make it work .... thank you!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.>— Reply to this email directly, view it on GitHub https://github.com/CharlesGillanders/homeassistant-alphaESS/issues/138#issuecomment-2465634556, or unsubscribe https://github.com/notifications/unsubscribe-auth/BIALCZHNAYVC4GJVJXR2GULZ7UIPXAVCNFSM6AAAAABQHTBGF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGYZTINJVGY . You are receiving this because you were mentioned.Message ID: @.*** com>
Automations using "Alpha ESS: Set Battery Charge" don't set the battery charge period on my Smile B3. No errors, just not setting the times
These automations worked prior to the latest Alpha upgrade.
Looking at the Alpha API site, they appear to be stating that setting once per day is allowed which is what caused problems for a lot of us. It got changed to once every 10 mins but I'm wondering if they've put it back to once per day?