Still haven’t been able to resolve this issue. I can access my SPAN panel from my computer using http://[IP Address]/api/v1/circuits and clearly see the data, but every version of SPAN-HACS that I use gives me the same result when entering the IP address of my panel during the process of adding the SPAN integration to Home Assistant. “Unknown error occurred”
Last effort was using GitHub - wez/span-hacs and firmware version “spanos2/r202223/06d09”.
This is also working for me.
I got the same thing at first. Installed the integration from HACS and immediately tried to input my hostname but it failed just like yours. I tried name, IP, full web address - nothing worked. Then I just left it alone and all of a sudden it popped up as a suggestion in HA for me to configure. Weird.
Agreed, with this update from wez everything is working as it should. When I uploaded it to HA it came up as a notification to add almost instantly. This version of the integration has been rock solid for me, even exposing some datapoints I can’t see in the Span app. At least it does for me with the latest Firmware: spanos2/r202223/06d09
Whoa, first time seeing this.
I noticed I’d lost connection to the panel today from HA and went to access via plain webpage and was presented with this. Took me a couple tries but eventually the door switch presses worked. Let me in via the webpage and then HA could see everything again.
Hey All,
My name is David Shoop - although colleagues and friends call me Shoop, and you can too. I am a new product manager at SPAN and one of the areas I am responsible for is local API access to SPAN’s physical products.
I can almost hear the Oooo’s, Aaaaah’s, and Yeeeeeses from some of you now.
If I’m correct about the ooos and aaaahs, I’m sure there may be a number of questions and requests… and that’s part of the reason I popped in here. I enjoy connecting with customers to understand what drew you to our product(s), how they are are being used, what you like, what you don’t, and what is missing. Let’s take things in order, shall we?
1. Thank you - No really, thank you! First, thanks for being a SPAN customer, and an early SPAN customer to boot. Thank you for your curiosity about integration with SPAN, the collaboration in this forum, and the discovery of some easter eggs. Thank you for future collaborations here and possibly with SPAN on future products .
2. Easter Eggs (Web Dashboard and Local APIs) - As mentioned above, your curiosity has led you to the discovery of a web based dashboard and local APIs that provide access to SPAN Panel functions and data - I see you @hyun007! While SPAN does not officially support these easter egg features, we do our best to keep an eye on discussions around easter egg discovery and usage, feature requests, and interest in these becoming an official product.
3. Software Updates - Warning - when using easter egg features, software updates could cause problems. Customer support, public documentation, or official release notes may not help you if you run into easter egg issues. I get it - it can be frustrating when you have come to rely on those easter eggs. To that end, I want to be as helpful as I can. We are rolling out a software update to our SPAN Panel fleet which will be a cause for anomalies noticed by anyone using either the web dashboard or the local APIs. Given these are still easter egg features, I will skip the details of what was changed or why, but focus on how to roll with the changes so that you may continue to use them.
4. Web Dashboard Change - As some have discovered there is a Web Dashboard that can be accessed from a browser by entering the IP addressed assigned to the SPAN Panel. With the latest software update, the web dashboard presents a login page. To access the web dash board we have implemented a proof of proximity check which is satisfied by opening and closing the panel door 3x. A count down can be found in the lower left corner of the page. Once the count reaches 0, simply click the button to gain access.
5. Local API Change - As some have discovered there are REST based APIs that provide information from the panel. With the latest software update, calls to the panel may result in errored responses. In order to retrieve information previously obtained you must complete a proof of proximity challenge which is satisfied by opening and closing the panel door 3x. Once this is complete API calls previously used should provide their responses. Access may be blocked if the internal computer in the panel reboots. If a reboot occurs, you will need to complete the proof of proximity challenge once again before the data begins to flow.
6. Official Support of Local APIs - I’m sure you’re thinking, “come on Shoop, why can’t you give us the APIs? It seems like you have em’. Heck your product should already be using them.” We are not trying to hold out on you… but… Like any company, perhaps more so as an early stage start up, we continually review our product offering and prioritize products/features/services that provide the greatest value to our customers or spur innovation. We continue to access when (not if) we will provide local APIs to the SPAN Panel. Before rolling out an official product we will run a Beta program to capture customer feedback and fine tune a product customers will love.
7. Beta Program(s) - I don’t have a specific date to announce, but when I do, I would love the opportunity to have some\all of you participate in a Local API Beta program. I believe that your contributions to this forum, your interest in SPAN, and your technical know-how will not only help us create a great API offering, but help us spin the innovation flywheel. When we are ready, be on the look out for the Bat SPAN Signal!
For now, I wish you a great weekend. I hope this information has been helpful and encourage you to tag me or send a direct message if you have any comments, questions, or feature request. I don’t lurk here often, but will do my best to respond in a timely manner.
Thanks
SPAN-Shoop
Nice!
I’m super keen to see you guys working with Sunrun/Ford so the Ford Home Integration System can tell the span panel there’s a power cut!
Right now (both getting installed next week) I think we’ll have to either enable use groups manually, or sort something out with HA.
I’d definitely be interested in the local api beta access
Ok, here’s the error log I get when I get when I try to add the integration…
This error originated from a custom integration.
Logger: aiohttp.server
Source: custom_components/span_panel/config_flow.py:136
Integration: Span Panel (documentation, issues)
First occurred: 8:40:14 PM (1 occurrences)
Last logged: 8:40:14 PM
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 60, in security_filter_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 222, in forwarded_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 82, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 136, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 178, in post
return await super().post(request, flow_id)
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 73, in wrapper
result = await method(view, request, data, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post
result = await self._flow_mgr.async_configure(flow_id, data)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 280, in async_configure
result = await self._async_handle_step(
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 367, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
File "/config/custom_components/span_panel/config_flow.py", line 136, in async_step_user
return self.async_create_entry(title=info["title"], data=user_input)
TypeError: 'SpanPanel' object is not subscriptable
Does any of this point to what I might be doing wrong?
Hello everyone,
I’m in the early architectural stages of a new home build that will start in 2024. I was researching about home automation and found out both about the Span and the HomeAssistant.
I am fairly new to this but I would like to know what is the potencial of an integration between Span and HomeAssistant. If I lay out the wiring in the house in the right way, could I achieve a home automation system with low EMF’s while using only Span, HomeAssistant and different kinds of sensors? I suspect I would need to plug into Span independently everything that I want automated, even if it were just a specific light switch. This would probably demand more than one Span panel, and could cost a lot of money right now, but maybe not so much in the future decades.
I just want to lay out the wiring the best I can for this house to be compatible with future upgrades without the use of wifi in every corner…
Thank you for keeping this community active
There’s a pretty common story here, but with a very uncommon ending.
Here’s the twist. Usually what happens next is
But based on what @SPAN-Shoop said, it sounds like what happened here was a thoughtful design decision to include an easy-to-implement compromise that, while not ideal, still allows the end user to keep doing advanced things. “proof of proximity” is a great idea, because it allows you to secure against who you actually should be securing against–remote attackers–while letting the actual user keep using it.
Well done. This is a feather in SPAN’s cap for sure. And then the icing on the cake is the direct communication from the company to the community.
I wouldn’t read it as the Intent of the SPAN hardware - this is more infrastructure-level circuit protection switching and monitoring. For control of individual loads you’ll need something else.
I recently entered into contract for my own SPAN panels (that SPECIFIC interaction was the final decision point for me @SPAN-Shoop, sold - sir.) If they were willing to find an intelligent compromise between security and client local access - I’m all for it. I’ll encourage that with my pocketbook. David - You know how much I will spend on a two-panel install. I’m hoping you can point to this as proof this is what your end-users want and keep that API up and developed for us. Thanks…
Echoing this sentiment – I’m literally in the decision making stages of adding SPAN into a project – (notably, at the cost of delaying the timeline of my overall solar project) and a decisive factor was the ability to integrate SPAN data into my local home network for a variety of use cases. It’s worth noting that I recognize that current state is obviously scrappy, nascent, community driven & far from fully baked.
However, if the signal here had been “shit – they locked down the API with the latest update, and sent some patronizing reason as to why with no alternatives or visibility into roadmap or prioritization” I would have absolutely backed out this week from commitment, and probably never looked back. Instead, I’m moving forward in part specifically because of the official comment & engagement here. Nice!
Good form to engage with the community transparently & proactively, clearly there is a vocal interest here. It pays.
While the “proof of proximity” is great for “power home-owners” its not great for a fully automated home automation system that was created for “hands off” home owner. The integrator cannot ask a homeowner to open and close their breaker box everytime there was a power outage.
My feeling is though, that SPAN is considering a token based login - the question is how an integration software can securely get and refresh the token.
The Alexa Media Player integration currently renews a dynamic token with 2FA. It’s entirely possible.
That is a cloud based service. If you want to stay strickly local API only 2FA will not work
I used that example strictly because it’s currently the most complex auth in any integration I currently know of… It initiates a token renewal on a regular basis which triggers a 2fa request that the integration handles on its own. Yet… it still works well. My point is whatever they put in I’m sure the community can adapt to it. Any auth that uses current standards, supports local control, resettable, etc.) should not be a problem for HA to consume. Any auth that doesnt fit the bill I will join in with flames to thier engineering team
On proximity access there’s some things I want to not be easy to access like onboarding a new ZWave door lock or accessing my entire electrical infrastructure. I LIKE that proximity access is part of it and if they sound like they’re moving away from that I will definitely put in a counter argument to at least keep it as an enforceable option. If you dont want physical access part of your auth solution that’s fine - personally I DO. Be it button on panel or a FIDO key or whatever. (yes im also a weirdo switching many of my important public IDs to FIDO keys for 2FA)
Im any case, Its up to us as users to keep pressure on SPAN to ensure whatever they do maintains local auth and local API access. If they don’t think it’s important to thier customers they won’t put effort behind it. If they do think it’s important to clients it suddenly becomes a Product Manager’s problem… I intend to keep putting it in any SPAN employees desk. Yes this is important. If not one of the most important features.
My panels look due to be installed next week. Im pretty sure my sales team and engineering team are already getting tired of me repeating that local access local control mantra and asking them to make sure that the message is passed up the chain. I keep reminding them that I am spending enough money to have earned the right for them to at least listen to my opinion and that thier core demographic are folks who REALLY care about these issues. Someone who doesn’t care about local access and control of an electric monitoring system isn’t spending 1.5x the cost of a typical panel installation and isn’t who they’re trying to sell to. They can try to monetize the advanced AI features all they want. Cut off basic access to the panel and we’ll have a SIGNIFICANT problem. 
Else, they can simply not have my money and not install the panels. So far I’m not unhappy with the responses.
Thanks @SPAN-Shoop for the details about SPAN’s plans. I’ve been in discussions with my local solar installer about adding a SPAN panel to my system, but I would need a commitment from you guys you’ll support local API access. So, the project is off for now.
Proximity makes sense, but it HAS to be persistent. I paired my Hue bridge to Home Assistant by physically pressing a button on my Hue hub, and it’s just worked for years without a problem.
Thanks @SPAN-Shoop, this first confirmation has really encouraged my purchasing decision this summer. The “easter eggs” you have in the local REST API have so much more detail than the current SPAN app, and together with the SolarEdge Modbus both ethernet wired in creates very detailed data information collecting. Bravo for letting us continue down this path with both Span and HA! I am sure the Venn diagram between Home Assistant users and those considering Span is pretty inclusive, and I am sure a decent marketing potential could be had by getting officially integrated into Home Assistant by working with Nabu Casa.
I do like the local verification idea (after I figured out what was going on after my power was restored from the wind storm last weekend), but @stbenjam has a point - this should also be persistent. A setup similar in protocol to Hue, where a physical location trigger is entered when enrolling into a system and on the same local network - but then it should be persistent. After all, it is an electrical panel and designed to react to power failures!
Thanks again for the support Span.