Yes, that would work but would potentially be quite a bit of work as you wouldn’t be able to use any of Spans automatic load shedding features. You would have to create scripts and automations completely in home assistant and then have those turn the breakers on and off like a switch.
If you install it you have control over your house as a huge relay box. You could make your own automations based on your Sol-Ark % into “nice to have”, “need to have”, and “non-essential” lists and have them trigger those switches in the Span integration. I wouldn’t use the Span integration labels on these, this would be completely in automations on HA only.
Doable, but something I personally wouldn’t want to manage as I don’t trust myself enough to have that much coding/automation knowledge to run the power to my whole home. Others I know would definitely be comfortable setting this up.
Also, do not think of the Span panel as a replacement for an automatic transfer device if you are going to be grid tied. There is no control over the main breaker.
You didn’t ask but just wanted to throw that in there as it would be a consideration on the install.
I appreciate the feedback. So I’m hearing I probably need to use the batteries supported to really take advantage of span. Ugh. My hardest challenge right now is finding someone that knows about span and a solar installer that has done this successfully previously without being gouged on installation costs.
It’s all really variable on that front. I found a local solar company where I introduced it to them, they liked it and got certified as an installer. I know I also got a sweetheart deal for the install, especially for all the extra work they did for me.
Ask around for people that have it installed in your area. I did solar and Span, but held off on the automatic transfer/battery setup since the investment doesn’t pay off for me yet in Michigan. It may be prudent to split up the install to fit your budget.
Getting the span panel for me cost me about 4k for parts and labor, and I hear that’s about average. It was a bit annoying as the electrician said he’d do it for free if I got solar through him, but he was a sub-contractor to the solar installer and the solar installer said absolutely not and only gave me a discount.
On batteries though, you might want to hold off. I talked to quite a few installers and all of them recommended I wait on batteries stating that right now the cost of the battery is too high based on how long their life span is.
For my use case it made financial sense to skip the batteries as I get a 1-1 buyback from my power company. So for every Kwh I produce I get to draw a Kwh back from the power company for free in the same month (no rollovers for me unfortunately). It ends up with the power company being my battery basically with the downside that if the grid looses power then my solar gets cut off, which is just so dumb to me. I wish I could get a manual transfer switch so I could be 100% with no grid in the event the grid goes down with the sun up, but that’s just not an option for some reason.
For anyone who have 2 Spans with 2 Tesla gateways for a 400amp service. On multi Span install a Network Kit router is installed.
I wanted to retain network access to the panels and gateways through Ethernet. So the 2xSpans and the 2xTesla gateways are all ethernet hard wired directly to my network. Make sure the Tesla gateways have two different passwords set.
While commissioning the Span panels may sure you select eth0 instead of the primary socket.
This way we can have direct access to Tesla Gateways and Span panels. Also had to remove the Span Network Kit router. This router will block all local access to Span panels and the Tesla gateways. This is a very stupid way to set it up!
Does anyone else constantly have to reauth the integration with home assistant? Are there any suggestions to make the auth more durable? It seems to be random, sometimes it will be good for a month, other times it will fail after a day. I’ve tried uninstalling and reinstalling several times, but the problem always reoccurs.
I am using the sargonas repo with the fix for the latest firmware (although I do see that the gdgib repo is now also updated with the patch).
Up until recently yes approx every month but with the sargonas build no. Now I have issues with the door sensor always reporting open
Funny you mentioned more… Durable…
Are you using durable auth? (capture the auth token and install in the integration - look in the git repo for instructions) or are you using the proximity door auth? (three button press)
I’ve tried both, but I’m currently using the proximity auth. Note that the manual token, I think was previously referred to as more durable, but that was due to a misunderstanding as pointed out by mbbush in this PR.
Has anyone looked at a graph of power vs time for a circuit with an air-conditioner load?
Attached is a history chart for 3 entities.
current power (main meter),
5-ton AC circuit, and,
4-ton AC circuit.
The power spikes (to 20kW) are due to the LRA (104A for the 4-ton or 118A for the 5-ton) for starting the compressor. So, ~100A x 220V spikes for short duration (few seconds).
Note that the ‘current power’ includes power usage from all circuits like furnace blower, lights/tv, etc.
I expected to see the power spikes at the start of every cycle and for each AC…but, don’t see it. Also, the spike sometimes shows up in the “current power” (meter feed) but not always and not when the spike shows up for the AC.
Would the Home Assistant default polling time mess up the data capture from SPAN?
Thanks.
Got the solar+batteries energized (finally!) and also got the update done to the SPAN app so it can display the complete view with integration of information from the Tesla Gateway. Both the Gateway and the SPAN are on the same subnet and connected via WiFi. So, working as expected without the need to do a hard-wired ethernet link.
There normally wouldn’t be a spike seen when the condenser kicks on. That LRA is milliseconds long so it wouldn’t even begin to be shown on the graphing. I was looking into this when adding soft starters to my condensers so I could run them without issue during off-grid times without overloading the batteries.
I do not think increasing your polling would even be enough to consistently see the spike when the contactor energizes the motor.
Sorry for the late reply. I got the data set (max per minute) with the help of Span support for the time window as in the graph posted earlier.
The Span data showed
the LRA related very high power spikes for both the specific AC circuit and the ‘common power’ (main feed). This was true for both AC circuits. The Home Assistant data did not show the spikes for both the AC circuit and the common power as well as not every spike that was observed in the Span data.
the spikes did not occur for every AC cycle (on+off = cycle)….maybe this spike does not need to happen in every cycle if the capacitor in the AC has enough juice? Over the 7+ hour time window, peaks were in 20-25% of cycles.
I have also been reading about the soft starter. With my 3 PWs (each able to support 106 A LRA), I have been able to test run both ACs in off-grid mode for a few hours with good (sunny) and weak (cloudy) solar production to assist. Caveats would be - did not test when total battery charge was <70%, and, AC cycles were not synchronised so the peak demand was probably easily met. I will learn more in the super hot summer days.
As far as I’m aware, this information is not exposed to the user via the local api, due to some quirks in our internal data model that leak into the public api.
I can think of a couple of hare-brained ideas you could try, even without the panel exposing it for you.
Tell the user that they should do the setup while the sun is shining
Using the response from the panel endpoint that contains all the circuits by number, filter for the ones that have an instantPowerW attribute which is positive.
There may be more than two of them; the panel supports multiple solar inverters landed on multiple breakers, although I don’t know how common that is.
Ask the user which ones of these have solar on them.
Or I suppose you could do the same with the difference between the list of all 32 circuits, and the named ones exposed by the /api/v1/circuits endpoint. That would include the solar circuits, but also (I think?) batteries, and empty spaces. So you’d still need to ask for user input to confirm.
It’s totally up to you how much work you think this is worth.
Yes there was a bug in the integration that I fixed. It’s not been merged into gdgid yet but you can find the fix in this custom repo for now https://github.com/cayossarian/span
@AngellusMortis, That’s a nice find. It sounds like a useful exercise if we add some more value as well.
One of the missing pieces IMHO is the ability to persistently configure some of the sensors like so:
Whether to produce a sensor for a circuit in the first place (any circuit in the panel with the help of ‘panel/branches’ data which shows even non-user managed circuits)
The unit type (Watt vs kW or Wh vs KwH) Power is obvious but Energy/KwH involves some Riemann Sum integration function (Trapezoidal, Left, etc) that one otherwise has to write some YAML for separately. The Wh currently produced don’t correspond to my utility and I’ve seen other comments along those lines.
These aren’t earth shattering but If we had these features we might be able to configure for a wider range of scenarios. We could change the existing HACs base to accomplish this but since there is some level of work it might be worth porting as well to make things easier with downstream changes, etc.
I made the solar sensors available in my own fork of the repository but the way I had to do it felt a bit like a very specific change that could be better generalized.
With my Powerwalls in self-consumption mode, I did the following Automation to avoid or limit grid import by limiting the use of high usage AC circuits. I don’t have the thermostats under Home Assistant control. So, SPAN circuit control to the rescue!
action: turn OFF SPAN circuits for AC condenser unit(s).
The forecast for solar production is used to check if sufficient excess might be available to use ACs & charge the batteries. This might be for a partly cloudy day vs a very cloud day.
Likewise, turn ON circuit when battery level above (x) % …etc…
Could make these run once per day by using a template condition example to check if triggered today. I saw an example in another community post.
These basic automations worked and I avoided grid import during the cloudy days with low solar production.
I’m close to installing span on our new build, but unfortunately I won’t be going with compatible batteries and I’m hoping I can accomplish load shedding with the combination of my sol ark inverters feeding data to HA and span. I realize this might take some work on my end to achieve, but I’m hopeful I can make it work.
Is anyone aware if Span has plans to do something simple like lumin and just have something upstream to determine if the grid is available or not? Seems like a simple solution for folks that want span, but don’t want to make the investment in the limited battery support. It would allow do some simple load shedding rules just based on is the grid available yes/no.
In general, when integrating power data into energy data, your precision is limited by the resolution of your power data. The more frequent the power measurements that feed into the integral, the more accurate the energy measurement will be.
The best place to do the integration is in the energy measuring hardware, as early in the pipeline as possible. This is precisely what the span panel does to produce the Wh numbers exposed in the local api. I would expect you to get the best results from reading the energy data, not from doing a Riemann sum of the power data, because unlike the power data, the energy data includes information about what happened in between polling intervals.
Especially for the branches, it will not be perfect. Your span panel has more accurate metering of the two main legs than it does of the 32 branches, and the numbers reported on the feedthrough lugs are actually calculated from combining the mains and branch measurements, so they can have even larger errors. But the factors that create those errors apply to both the power and energy data.
You’re welcome to experiment and I’d be curious to know what you find, but in general I would trust the measured energy data more than I’d trust Riemann summed power data.
