Yeah this has to be priority. While I like the fact the door button allows me access. I didn’t like having to venture out in the ice storms to regain control every time we lost grid power this week. (I don’t have solar or battery - yet)
1 Like
Well, I think that any questions for @SPAN-Shoop are probably going to go unanswered. Just checked and found this:
Note the part that states: ex-SPAN
Well, that’s less than ideal…
Hi Everyone. My name is Colin, I’m a Product Manager at SPAN and I’ll be responding in this thread from now on.
Candidly, we are a young company and with many competing priorities we have had challenges finding resources to provide you all the level of support this feature requires (and deserves). I realize this is frustrating so please bear with us - our Local API is not yet officially announced or supported, as such our Tech Support team is not trained to advertise or support it and it may still have some bugs we need to work out.
That said, we know local access is crucially important to you so we are looking for ways to improve your experience in the shorter term… I’ll reply to this thread next week with more.
9 Likes
For anyone who lost breaker control a while back you’re welcome to use my fork of the integration: gdgib/span-hacs (github.com). I can’t promise I’ll always be able to keep up with changes, but at least it’s working right now.
For the hardcore nerds, it was a simple matter of changes in the Span REST API between snake & camel casing of the field names. You’re welcome to see the PR Update keys for new firmware rev - enable circuit control by gdgib · Pull Request #2 · gdgib/span-hacs (github.com)
3 Likes
Oh, and I have all the fixes/improvements I could find from other forks merged in there, so there should be little risk switching to my fork from any other.
2 Likes
Loaded it up in HACS and it came right up with everything activated, works like a charm.
Thanks Greg for the update!
3 Likes
Good job there Greg! Your integration worked for me first try, and I now have breaker control which I had not had before.
1 Like
How hard is it to change the integration. Did you need to uninstall /reinstall?
It’s been a while since I changed HACS repos (back when I forked it). That said, the entity IDs it generates won’t change so it should be no hassle.
At worst you should be able to delete the integration, remove the old repo from HACS, add in mine. Depending on your luck you might have to add the integration again in devices, or it may auto-populate. Total time for all of this ~15min if you’re unlucky or get lost.
The key is that when you’re done, all your old entities will be back with the same IDs working just as always. In short: there should be no downside to switching repos.
2 Likes
Ok, one small problem… While the integration now shows the breakers, flipping one of the switches in Home Assistant does not have an effect on the panel and changes made to the circuit priority do not seem to stick.
Basically, if I click on the blue switch, it will switch to off, but the panel will do nothing. A couple of seconds later, the blue switch turns back on in HA to reflect the unchanged state.
Note that if I go into the SPAN Panel’s local web page the switches work properly. Also, current firmware is spanos2/r202302/03.
On brief observation last night it appeared everything worked, but I am seeing the same actions.
The blue switch will flip for a second, but not turn off the breaker and turn back on when it gets the next handshake update. It does look like the Priority is sticking for me, but I can’t confirm on the app as I don’t have battery backup yet.
It does work the other way however, if I turn off on the Span app it will report to the switch in HA. So reporting works, but action does not.
1 Like
@NathanCu I followed this procedure and worked in < 5 minutes of time.
- Delete Integration from Settings/Integration.
- If using HACS to install previous Galek or Wez version remove repository
2.5 If installed manually deleted Span integration from the /customcomponents folder - On HACS page, go to 3 dots on top right and add custom repository. Add gdgib/span-hacs to the repository and label it Integration.
- Install and enjoy! If Greg can update it will show up in HACS when he does so.
1 Like
I’ve got an update on my own LinkedIn that’s relevant here.
Last month I started a new job at Span. Like many members of the home assistant community, I am passionate about local control. There are many other Span employees who feel similarly. Frankly, I would not have taken the job if the company was committed to a cloud-only, closed ecosystem.
It’s worth clarifying that my role is pretty far removed from development efforts on the local API, but the local experience is something I care about, and something I intend to start using myself as soon as I can get a Span panel installed in my home. It’s also something I’m tinkering with in my spare time. At the moment my “side project” is getting the api documentation into a state we can release publicly. I hope to have more information to share soon.
What I can say for now is that improving the local api experience is something we’re working on. In an ideal world, we’d have a fully-featured, well-documented, secure local api, and official channels for communication between community members and the Span team for issues that come up.
But we live in the real world, not an ideal one, and the reality is that we are also working on many other things at the same time, so sometimes progress can be slower than I’d like.
If you think you’ve found a bug, you can tell me about it and I’ll see what I can do. If you’ve got a suggestion for a simple, effective, lightweight way to support communication between the DIY home automation community and Span, I’d love to hear about it.
4 Likes
Something more than random lockouts is already available on the panel, it’s just not implemented in the HACS integration. The immediate solution to durable authentication is to use the “proof-of-proximity” with the door to temporarily unsecure the endpoints needed to create a new JWT token, and then include that bearer token in subsequent requests. I’m still working on testing this flow and writing up details, but a gist that Shoop linked above contains mostly correct information (once you account for the corrections various users posted in the comments).
I hope to provide more detail soon. I also think it would be fun to work with someone to develop/validate the integration.
2 Likes
This is very cool. I maintain concerns about the company’s support for local control, but it’s good to know that there are going to be advocates inside, and once @SPAN-Colin gets up to speed on our concerns maybe we can even see a solution to the security and connectivity issues.
Additionally, if you need someone to test an integration, I’m willing to give anything a try.
3 Likes
Hi Everyone, let me summarize your concerns as I understand them and give you a little insight into what we’re doing to address them.
- You have to prove proximity repeatedly and at irregular intervals to keep Home Assistant connected to your SPAN panel.
We actually have a solution for this today in token-based authentication. As far as I can tell no one has implemented this yet in a Home Assistant integration. Matt is going to provide instructions on setting this up, and hopefully a developer in the community can implement it soon! We’ll support as needed to get this implemented in an integration so you don’t have to run out in a blizzard to push a button to stay connected.
- You are having issues with your Home Assistant integration for reasons other than staying authenticated with proof-of-proximity.
As I said before, the Local API may still have some bugs and at the moment this is competing with a lot of other priorities for development time. I encourage all of you to keep coming to the community for support on the Home Assistant integration, and to let us know if you suspect any bugs in the API itself.
- You would like some certainty that SPAN is committed to local control for the long term.
I think actions will speak louder than words on this so I’ll leave it at we hear you, local control is important. For now we are looking at providing improved documentation and spending some of our free time polishing the “rough edges”. I’ll provide updates in this thread as I have them - I’m intentionally not giving any timeline as I don’t want to over promise and under deliver. Thanks all for your engagement and really valuable feedback.
3 Likes
Need to provide durable authentication · Issue #11 · galak/span-hacs · GitHub has the details of how to “properly” authenticate. This is information we’re releasing to the community to help you build a better integration.
There will very likely be some future firmware version where this authentication is required, but I don’t have any information about when that will happen.
I hope to have more to share soon!
3 Likes
Thank you @mbbush and @SPAN-Colin, I appreciate the support for both the HA and open source community! I would be happy to beta test this when someone can push this through.
As far as update timelines go, when will the panel update go live? We have noticed that many of our panels are not synced when it comes to official Span updates, and the app does not provide any method of giving firmware/software updates or give the user control to schedule or initiate the update.
Is there a process that is currently used, or are they rolled out on a per-user or group of user basis? For instance, I have been updated to what appears to be the current update (spanos2/r202302/03), but a week ago I was at spanos2/r202249/07, and there seemed to be updates in-between that I did not receive.
To program the auth token in, I would assume a new version would have to be either programed to use a version check or a warning to not update until version xxx with the auth token is updated to our Span panel, correct?