Complete now returning 200 (1.43.3)

[estebanpapp]

As of 1.43.3, complete is returning 200 for me. Mode takes a bit longer to change, but still changes within the minute. Complete is also returning the same as "status": {"start_time":"2019-12-13 10:16:11 +0800","up_time_seconds":"82h12m42.803575945s","is_new":false,"version":"1.43.3","git_hash":"7aa2baba2508c04599e1c4609865c6b61e106888"}

Someone can validate? and we can update the doc

[piersdd]

Same here, although I do not recall if the return response was any different (ie, not identical to /api/status) before. That said, I am experiencing errant behaviour; When switching to self_consumption, my Powerwall actually appears to enter backup mode, and vis-a-versa. This started on about the 12th December. Unfortunately I'm not logging software updates. Shall followup as I learn more

Testing, just now @17:00AEST, with surplus PV load, I have; A) manually enabled self_consumption with the /api/operation (using https://paw.cloud, not my python scripts) `HTTP/1.1 200 OK Cache-Control: no-store Date: Fri, 20 Dec 2019 06:02:39 GMT Content-Length: 60 Content-Type: text/plain; charset=utf-8 Connection: close

{"real_mode":"self_consumption","backup_reserve_percent":15}`

B) manually enabled /api/config/completed `HTTP/1.1 200 OK Date: Fri, 20 Dec 2019 06:06:16 GMT Content-Length: 172 Content-Type: text/plain; charset=utf-8 Connection: close

{"start_time":"2019-12-13 10:16:23 +0800","up_time_seconds":"155h49m52.849944888s","is_new":false,"version":"1.43.3","git_hash":"7aa2baba2508c04599e1c4609865c6b61e106888"} `

C) Manually confirmed configuration with /api/operation `HTTP/1.1 200 OK Cache-Control: no-store Date: Fri, 20 Dec 2019 06:07:37 GMT Content-Length: 60 Content-Type: text/plain; charset=utf-8 Connection: close

{"real_mode":"self_consumption","backup_reserve_percent":15}`

[BJReplay]

I'm seeing the same erratic behavior as Piers. Switches to backup seem to work, but switches to self consumption are erratic.

First noticed with 1.43.3.

On Fri, 20 Dec 2019 at 17:18, Piers notifications@github.com wrote:

Same here, although I do not recall if the return response was any different (ie, not identical to /api/status) before. That said, I am experiencing errant behaviour; When switching to self_consumption, my Powerwall actually appears to enter backup mode, and vis-a-versa. This started on about the 12th December. Unfortunately I'm not logging software updates. Shall followup as I learn more

Testing, just now @17 https://github.com/17:00AEST, with surplus PV load, I have; A) manually enabled self_consumption with the /api/operation (using https://paw.cloud, not my python scripts) `HTTP/1.1 200 OK Cache-Control: no-store Date: Fri, 20 Dec 2019 06:02:39 GMT Content-Length: 60 Content-Type: text/plain; charset=utf-8 Connection: close

{"real_mode":"self_consumption","backup_reserve_percent":15}`

B) manually enabled /api/config/completed `HTTP/1.1 200 OK Date: Fri, 20 Dec 2019 06:06:16 GMT Content-Length: 172 Content-Type: text/plain; charset=utf-8 Connection: close

{"start_time":"2019-12-13 10:16:23 +0800","up_time_seconds":"155h49m52.849944888s","is_new":false,"version":"1.43.3","git_hash":"7aa2baba2508c04599e1c4609865c6b61e106888"} `

C) Manually confirmed configuration with /api/operation `HTTP/1.1 200 OK Cache-Control: no-store Date: Fri, 20 Dec 2019 06:07:37 GMT Content-Length: 60 Content-Type: text/plain; charset=utf-8 Connection: close

{"real_mode":"self_consumption","backup_reserve_percent":15}`

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vloschiavo/powerwall2/issues/26?email_source=notifications&email_token=AJB3YI5JQJI53QJNWPKY3Q3QZRPUVA5CNFSM4J3VUKLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHMAF3Q#issuecomment-567804654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJB3YI3HDFLT237A6BJFNWLQZRPUVANCNFSM4J3VUKLA .

[spoonwzd]

Same here - 1.43.3 pushed out last night and now just repeatedly get an error status code 200 when setting a reserve.

Setting Powerwall reserve to 5% Confirming changes with Powerwall Failed to complete with error code 200 {"real_mode":"self_consumption","backup_reserve_percent":5}

[estebanpapp]

I was observing some weird behavior. In self consumption, all solar was going to the batteries and the house was being powered by the grid. I reset the powerwalls and the next change seemed to work fine. However, now is doing that again. Changing to backup is working fine. Is self consumption the problem for me. Switching it through the app works fine.

[BJReplay]

It gets stranger - last night my battery was empty - the result of running AC into 44° heat. Through the night, it progressively charged to 44% in fits and bursts; all the time the set mode was self_consumption, 5% reserve. See https://pvoutput.org/intraday.jsp?id=8562&sid=6943&dt=20191221 and click on the right hand square under the date below the legend of the graph to show charge status.

[BJReplay]

I've been testing with https://www.getpostman.com/ and it appears pretty solid:

1. Set mode / reserve (post to https://powerwall/api/operation)
2. Set complete (get https://powerwall/api/config/completed)
3. Set running (get https://powerwall/api/sitemaster/run)

I can throw in calls to get current status (get https://powerwall/api/operation) (at any point after number 1 above) and it always returns what was set in the call to set mode at 1 above.

If I go into my app on my (android) mobile, provided I exited the app, if I go into customise, it reflects the setting set through the api (taking into account the correction of the reserve_percentage), after about 5 seconds.

While monitoring the local GUI, when I call Set Complete, the local gui pauses for about 5 seconds.

So, at least as far as I can see, calls from postman that take about one second between each call to allow me to move from one tab to the next and make the API call always work.

I'm going to throw a 2 second delay between calls to set the mode and set complete into my service to see if that makes it more reliable.

[estebanpapp]

@BJReplay when setting "self consumption", I see it in the app in self consumption (iOS). However, I see it consuming from the grid. If from the app (iOS) I switch to backup and then back to self consumption, after some seconds it does not consume from the grid (which is what I would expect if I have some % battery). Do you see that behavior after 2 and not after 3? Thanks

[BJReplay]

@estebanpapp

In answer to your question, I was testing when PV > load, so the house was always feeding into the grid. I was just changing modes or backup_reserve_percent and checking if they were reflected in the app (and assuming, that if the conditions were correct, that the powerwall would then obey the settings).

However, I'm going to do some testing again, because I've just seen what @piersdd described: Apparently switching into the opposite mode.

API

1. Switched to backup at 12:05am
2. Powerwall accepted command and reported in backup mode
3. Powerwall continued to supply load overnight
4. Switched to self_consumption at 7:45am
5. Powerwall accepted command and reported in self_consumption mode
6. Powerwall began to charge from grid

App:

1. Checked mode at 8:45 (I had a post-xmas sleep in)
2. App reported self consumption mode, and backup reserve 0%
3. Powerwall was charging from grid
4. Turned off Storm Watch just in case that was causing charging
5. Changed backup reserve from 0% to 5% and back to 0%
6. Powerwall stopped charging and went into self consumption mode.

This is the behaviour that @estebanpapp @piersdd described.

I plan to test whether this is a bug where the PW needs another API call to actually change mode, but then goes into the settings from the previous API call.

If it is, the workaround response for programs or scripts may be to call the mode setting API twice; once to set the desired mode, and again to get the PW to actually go into that mode!

[estebanpapp]

I played today with it... you may be right that the "set running" is the key... previously I was doing:

1. Set mode / reserve (post to https://powerwall/api/operation)
2. Set complete (get https://powerwall/api/config/completed) Noticed that in the https://powerwall/ interface the PW shows as "stopped"

Added the 3rd step:

3. Set running (get https://powerwall/api/sitemaster/run)

Now I see the https://powerwall/ interface in the right "started" state. I also switched back-forward between backup and self-consumption through the API and I see it changing "as expected", during night time (no PV production):

• in self consumption all the load consumption is being provided by the battery
• in backup mode, all the load consumption is being provided by the grid

I will keep monitoring the behavior and will also test during PV production.

[vloschiavo]

Thanks for all the testing guys! This is great.

[spoonwzd]

I've tried adding a 5 sec delay in-between commands but that didn't seem to help.

Based on what @BJReplay said I've also tried using POST on config/completed and called sitemaster/run after both operation & config/completed but even after all of these changes, it still takes two attempts before the Powerwall actually does as commanded.

I see @BJReplay has updated his own code with 1.43.3 fixes - maybe he'll respond here with his findings in due course.

[BJReplay]

@spoonwzd I'm hoping to report back tomorrow, with my refactored code having run though several modes over the weekend, and into a normal peak workday. For the moment, what seems to be working is setting the mode twice. I've chosen to make the second attempt after five minutes - simply because I had a five minute timer in my service, and one minute looked like it might be too soon, given the delays between setting a mode and the powerwall switching too it.

This seems to be working.

I haven't yet experimented with changing the mode through the app to see whether the same bug (doesn't accept first instruction, accepts second instruction exists there), but I suspect it might.

I will respond back with further findings as and when I have them.

[spoonwzd]

Thanks @BJReplay. FYI I can successfully issue the commands for the 2nd time 5-10 seconds after sitemaster/run brings the system back online.

So, if:

1: Set mode / reserve (post to https://powerwall/api/operation) 2: Set complete (get https://powerwall/api/config/completed) 3: Set running (get https://powerwall/api/sitemaster/run)

Are you saying that simply running 1,2,3,1,2,3 is the solution, or is there another combination?

Thanks as always.

[BJReplay]

@spoonwzd, yes, I think 1,2,3 ... 1,2,3 is the answer. That said, I haven't tried 1,2,2,3 or 1,1,2,3. I've bundled 1,2,3 into a routine so I call that routine again.

[BJReplay]

Summarising:

Firstly, setting complete is returning 200 as per the title of this issue. Secondly, apparently introduced at the same time is a behaviour where mode changes do not stick the first time, but do the second time.

re-running the sequence 1: Set mode / reserve (post to https://powerwall/api/operation) 2: Set complete (get https://powerwall/api/config/completed) 3: Set running (get https://powerwall/api/sitemaster/run)

60 seconds after the first attempt to change the mode seems to result in the powerwall accepting the new mode and changing modes into the new mode.

[spoonwzd]

Yup I've done the same - call the sequence twice with a 20 second gap in-between. Seems to work ok.

I've also found that using the same POST method for /completed as you do for /operation and it successfully returns code 200. hasn't made any difference to having to run it twice.

$set_pw_reserve = Invoke-WebRequest -Method POST -ContentType 'application/json' -Body $post_json -Uri https://$powerwall_ip/api/operation -headers $header
$pw_complete = Invoke-WebRequest -Method POST -ContentType 'application/json' -Body $post_json -Uri https://$powerwall_ip/config/completed -headers $header

[estebanpapp]

Updated my script automation to do 1,2,3,1,2,3 and has been stable for a couple of days. I have no time gaps between the first 1,2,3 and the second.

It wasn't... it changed sometimes and sometimes it didn't... I was able to reproduce it in the iOS application: changing operation quickly seem to not change the operation at all. Could be related to some "bad state" that the gateway is left in with the internal API. In both cases (iOS and through internal API) the iOS app reported a mode that the gateway seemed to not be in. This IMO looks like a bug (likely introduced in the last firmware 1.43.3)

Is anyone able to sniff the communication between the app and the gateway?

[estebanpapp]

Changed to:

1: Login (/api/login/Basic) 2: Sitemaster stop (/api/sitemaster/stop) 3: Set mode (/api/operation) 4: Set complete (/api/config/completed) 5: Sitemaster running (/api/sitemaster/run)

self_consumption -> backup changes immediately backup -> self_consumtion takes around 30s, similar to when I change it with the iOS app

Will leave that for a couple of days to validate stability, currently changing self_consumption -> backup at 12pm and backup -> self_consumtion at 6am.

[estebanpapp]

Gave up with the local API... I couldn't get to something "stable". Ended up going with the "owner-api.teslamotors.com" API. The only reason I was using the local one was because it would switch immediately (vs every half hour or so). The one from "owner-api.teslamotors.com" now switches immediately (takes maybe 30s when activating the batteries).

[vloschiavo]

So, what's the consensus? Do we have a solution that works now that we're on 1.45.2?

[piersdd]

Now I have a little more time on my hands I plan on revisiting the local API. Am also quite keen to integrate the excellent solcast.com API.

Very disappointing Tesla are not posting change logs for their gateway software.

[BJReplay]

The call twice approach described in this thread by me has been working since I described it.

The powerwall entered the wrong mode after updating to 1.45.2, but mode changes work as now expected.

On Sun, 12 Apr 2020, 7:52 am Piers, notifications@github.com wrote:

Now I have a little more time on my hands I plan on revisiting the local API. Am also quite keen to integrate the excellent solcast.com API.

Very disappointing Tesla are not posting change logs for their gateway software.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vloschiavo/powerwall2/issues/26#issuecomment-612520852, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJB3YI55TMTJRWZMH5HYCLDRMDRB5ANCNFSM4J3VUKLA .

[estebanpapp]

I have been using the public API to change mode with almost no problems. The only issues I get is when the gateway "hangs", sometimes after an update and is not accessible even from the phone app. I just reset it in those scenarios and I am good.

[spoonwzd]

Now I have a little more time on my hands I plan on revisiting the local API. Am also quite keen to integrate the excellent solcast.com API.

Now Solcast have limited the free API to 10 calls per day, I have a Powershell script that runs on a limited schedule in the early hours of the morning to get the most recent prediction so I can precharge using the cheaper overnight energy.

Happy to share my scripting if it's any use.

[vloschiavo]

@spoonwzd - Yes, please add your powershell script as a file in the examples directory as a pull request, or paste here and I can add on your behalf.