500 error during circuit priority change

[gdgib]

As mentioned on #4 both @etmelvin and myself get 500 errors when attempting to change the priority of a circuit. However, since neither of us have a battery, our theory is that circuit priority only works when there's a battery installed. Given that the span UI and this integration BOTH get 500 errors this seems reasonable.

If anyway has a battery and 2min, could you:

1. Attempt to change circuit priority using this HACS integration? If it works, I'll be very happy.
2. Attempt to change circuit priority using the SPAN local UI. I'd be curious to see if that works, too.

[gdgib]

@jeffkibuule if you have a battery connected to your span would you be so kind as to try the two things in this issue?

You seem skilled & dedicated, and I could really use a test partner on this one.

[etmelvin]

I just got batteries installed a couple days ago and the API is still throwing 500 errors even when I can see my batteries and the re-prioritization options in the Span app.

From Span Panel's local web server, when attempting to change the circuit priority through its circuit page yields the same issue. Once you made a change via the drop down, refreshing the back will reset it to its previously set value.

This looks like a broken API on Span's side. Hopefully we'll get more information on the fix.

[gdgib]

Good to know! Thanks for reporting. That's a bit unexpected that their local web app is broken, though. Dang.

[mbbush]

Unfortunately this is a regression/bug in the on-device code which implements the local API. There's nothing the home assistant integration can do about it. We've got a ticket documenting it internally, but I can't promise any timelines for a fix, other than to say that I am personally embarrassed that what was once working is now broken.

[nathan-curtis]

@mbbush - any update on that ticket? See next.
@gdgib - finally have time to work on the logs you asked for - but waiting on Matthew's response to see if firmware re this has pushed if so, what ver. is required. Let me know if you need anything collected.

[nathan-curtis]

@mbbush Do you know if spanos2/r202342/04 fixes this?

[gdgib]

This error is still happening for me as of 30seconds ago even when I use the SPAN UI, so this isn't something I can fix in the integration.

If anyone with a battery would care to check whether they get a 500 when setting priority through the SPAN UI (navigate to the IP address of your panel, click Circuits and try changing something with the browser dev console open that would be lovely.

[gdgib]

Can confirm this is still an issue. Even weirder: when I use the app to change what's a must have vs non-essential circuit, I could mark a circuit must have and the website reflected that, but when I changed it back, the web site still said "must have" even though it now allowed to control the breaker.

Something ain't right. Leaving this open. I rather suspect we'll have to wait for firmware changes, or I may have to get clever about intercepting app traffic (which I really don't wanna do)

[AngellusMortis]

I do not have my batteries or solar hooked up yet, but definitely getting a 500 from the Span Gateway when trying to change the circuits.

[gdgib]

Thanks @AngellusMortis ! Please let us know when you get both batteries and solar hooked up. If you still see 500s after that, it would be a sign that this is a firmware bug.

[AngellusMortis]

Got the batteries hooked up. Still gives the 500 errors in the Web UI. Works on the app though.

[cayossarian]

Back to the OP's original issue, we may want to remove this option to set circuit priority in this integration as these changes can be made in the SPAN app and the API does not allow us to change the priority. The rationale for the API not allowing it is a bit fuzzy since the "Power Up -> Always On Circuits" setting in the SPAN app I presume effectively uses the settings for "Must Have."

At any rate changing the priority, other than through the SPAN app, is not allowed and I don't see 'Nice to Have' in the app so maybe that setting is deprecated.

[cayossarian]

BTW, one of the things I do is have a template that notifies me when the power even gets close to what I want to see in my "Power Up" settings and I can take action. The intent then was to notify the user and allow the user to shut down circuits proactively and potentially via an automation that trips some SPAN breakers to off once the user has time to gracefully shut down stuff. This scenario is useful for services that don't have 200 amp service at a panel.

[gdgib]

Yeah, @cayossarian if you haven't seen a circumstance in which we could change priority through the API, then I think the right thing to do is remove the functionality from the integration. In short, I think we make the "always on" vs whatever into sensors, but not selects, since we can read those values but not change them.

I say that because we've never seen anything but 500 errors when trying to make these changes, and since we see that both in the REST API, and through the actual span web app served by the panel. I'm left concluding this isn't something we can work around, there's no mistake in our logic, and there appears to be no circumstance in which the API accepts updates to that.

The only other step I can think of is setting up a proxy on a phone and sniffing the app traffic, since there's clearly SOME API to change this, but I think that's a bit more reverse engineering than I'm comfortable with supporting in the long term.

[gdgib]

Not bad advice on the automations, though. Maybe something we should write up for the readme? I could imagine others being interested.

[cayossarian]

We can make the selects read-only at least to avoid the exceptions. Or...make the priorities useful within the integration.

Based on the data we have at our disposal we know which circuits are user manageable which would allow us to create our own management dashboard for setting thresholds and picking circuits with priorities, get notifications, etc. That is essentially what SPAN "Power Up" does without the notifications AFAIK. One could also do something similar at a circuit level to warn in case a circuit is > 80% for 3 hours or > 100% for any period (NEC compliant). Maybe I'll put a prototype together 🥇