Options for Sunpower solar integration?

Third party integrations
#1

I’m looking to integrate my Sunpower solar power panel reporting into HA. I’ve found two Github repos which appear to solve this problem, but this leaves me with more questions.

Repos:


Questions:

  1. Are either of these options available as an integration, perhaps through HACS? I see an HACS file in the repo but I don’t find anything within HACS. Wondering how exactly to install.
  2. Has anyone compared the two approaches? I’m not sure which one I should use, although the concepts are similar.
  3. Can anyone suggest what the routing approach should look like? I know the requirement is an indirect connection to the management interface within the Sunpower hardware. I’ve got a little GL.iNet router which I think will work, but I’m not sure of the actual router configuration. I’m guessing I need to somehow bridge the LAN port to the Wifi connection, which would then connect to my network.

Looking for suggestions from anyone who may have gone down this route, or possibly from @Keith_Baker.

4 Likes
#2

I’ve written up what I did on my blog: https://blog.gruby.com/2020/04/28/monitoring-a-sunpower-solar-system/

I used a Raspberry Pi W with an Ethernet header to act as a bridge and then use Node-RED to bring the data into HA and display it on Grafana.

There are tons of comments on the entry, so happy reading!

1 Like
#3

Hi Todd,
There are a number of ways to integrate with HASS obviously. All of these methods rely on having access to the management (installer) port which requires some networking gymnastics because it can’t just plug into a household flat network due to it running a dhcp server. The other folks have written this up in more detail. If you know networks they are probably all equally as easy if not mine might be a bit hard without more detail.

  • Mine is available via HACS. That’s how I install it on my system. Put the github url in HACS as a custom repo and you should be good to go.
  • I hadn’t seen the second one until you pointed it out (cool!). A five minute glance at the differences:. My code is a full ‘integration’ with HASS. You use the UI to configure it and get 3 devices (PVS, production clamp, consumption clamp) plus a device per panel. The other one is a cgi script that converts the data from the pvs to a format that is fairly easy to integrate using json templates in HASS (I think you get entities this way). Mine requires less external software but does require that the code is kept up to date and compatible with hass as it evolves. One word of warning the code is only compatible with some systems (I think PVS 5. A person who had a PVS 6 said some data changed making it incompatible, bit it could be some other difference). It is a small change to make it more robust but I need to get permission from my new employer to resume contribution to that code (given interest here I’ll open that topic).
    Good news is that one of my Sunpower micro-inverters kicked the bucket. Thanks to this setup I noticed within a week (insert lots of cursing about sunpower’s dumbed down interface and lack of automated alerting here)! Apparently I had a known bad batch of inverters and they were all replaced under warranty including and upgrade to a PVS 6. Long story short I too want this upgrade.
  • For my Integration networking:
  1. you need to get hass a network route to the sunpower management network. You don’t want to put the sunpower management port on your home network because it will conflict with any dhcp server you have and steal the default route to be itself! You need to NAT to the sunpower so that it only needs to send to the local network (it’s routing table is also default routed improperly for this use). I’ll see if I can get a moment to diagram this out and add more info on my actual setup and alternate solutions in the next day or two.

Best of luck with either!

Side note: please write Sunpower to give us a simple, clean, stable, public API. Their monitoring has been nothing but dumbed down garbage for me (including their data loss for about a year and lack of per panel monitoring). This hack works and I highly recommend any of them but It could be a lot better with a little friendly help from the people you and I spent a large sum of money with!

3 Likes
#4

Thanks, Keith! I just installed your integration and it appears to be working pretty well on a PVS6. The only field that isn’t filled in on the inverter is the MPTT KW. Moving to your integration will let me eliminate a lot of Node-RED stuff that I used to create sensors. This is a very welcome change!

#5

Wow, thanks Keith and Scott! I had no idea I’d get so much help so quickly. Thanks to you, and after working though some configuration struggles, I’ve already got it working! 27 new devices on my dashboard (now I just need to figure out an effective way to present that data).

I’d seen Scott’s blog but did not think to read through the comments. Definitely some good discussions there.

As for Keith’s detailed info:

  • Thanks! I was forgetting about HACS custom repos. Got it installed now. Appreciate the full integration, and knowing the differences between these repos!
  • Looks like I have a PVS 5, and one of my panels is reporting almost zero output. That could be a problem but it’s too early for me to say that, need to watch the data and check for shade/etc.
  • Agree 100% that this is an expensive system and should include a usable internal API. I think they focus all their energy on the average consumers that call them every day, and don’t often consider us “prosumers” who want extra access and probably don’t contact them often. Since they’re typically connecting to customer networks anyway, the config could be really easy for a local API (or of course they could do a cloud based API).

A few followup questions:

  • Does the PVS 6 have some desirable improvements over the PVS 5?
  • It looks like we have sensors for every panel (or micro-inverter I guess). Is there any aggregate reporting? If not, would it be reasonable to add sensors to the integration that are just there for summary totals? I don’t know much about how integrations are typically written.
  • All of my 27 sensors show the same short names (just Power / Temperature / Voltage / etc). Should there maybe be a prefix in the name that’s basically a panel number? Something like “SunPower 1 Voltage” for example. Again I don’t know if this is typical but it seems like the individual sensors for other integrations show up with different names on the dashboard.
#6

And in case it is helpful to others, here are some notes on how I got the networking side of things working:

Basically I’m using a small travel router to make a bridge between my home Wi-Fi network and the travel router’s LAN port, which connects to the SunPower installer port, with port forwarding for the API requests.

  1. I used a GL-iNet travel router; in my case it’s model GL-MT300N-V2, only around $20 and very compact (it’s also quite useful as a portable VPN solution for travel but that’s another matter).
  2. For initial configuration, I connected my PC to the LAN port of the router and configure as follows. This router has a simplified GUI which allowed me to do all the steps except one (which required the alternate “advanced” LuCI screens).
  3. Connect the Wi-Fi repeater to my internal network (in my case I used a separate SID on my main network with no Internet access and limited access to the rest of my network… this part is optional).
  4. [Update: Step 4 should no longer be necessary as of the GL-iNet firmware version 3.203, should be possible to disable inbound Wi-Fi now] Define an inbound Wi-Fi name/password - technically this WISP/repeater piece shouldn’t be necessary, but with this device I found that it wouldn’t automatically connect the “uplink” Wi-Fi without also having an active downlink. Otherwise I would have disabled inbound Wi-Fi.
  5. Change the LAN IP to 172.27.153.10 (the .10 part can be anything, but not .1 as the SunPower is expected to be at 172.27.153.1)
  6. Firewall: Create a port forwarding rule from WAN port 8080 to 172.27.153.1 port 80. I used port 8080 so that I’d still have access to the router’s admin pages using the default port 80.
  7. Firewall: Enable inbound port 80 (allows router admin from internal network)
  8. Firewall: Enable inbound port 8080 (which was forwarded above to SunPower’s port 80)
  9. Go into Advanced settings (the LuCI screens): Under Network/Firewall, change the zone settings for zone “wan”: Add lan to the “covered networks” list and change “Input” to “Accept”. I don’t understand all of the details here, but my port forwarding didn’t seem to work until I did this.
  10. Mount the router in the SunPower box, plug the power connector to the USB port and the LAN connector to the installer port.
  11. Back on my main router configuration, assign an IP to this travel router (which should be connected via Wi-Fi now).
  12. Configure the SunPower integration (the krbaker/hass-sunpower integration added via HACS) to use my assigned local IP at port 8080 (in my case: 10.10.40.10:8080).
  13. Profit!

Home router (10.x) —Wi-Fi—> Travel Router (10.x:8080) —LAN port—> SunPower (172.27.153.1:80)

Now I can configure the travel router using its 10.x address (if needed), or talk to SunPower using port 8080 on that same address.

2 Likes
#7

I think you will find that the data doesn’t update! It looked like it was working but didn’t. The fix is easy I just need to make sure I can contribute it without the change belong to my employer (they seem good about this I just haven’t gotten to it). I like it and I’m psyched if it ends up working for others!

1 Like
#8

Thanks for letting me know! I won’t migrate from my system quite yet.

#9

Awesome to hear. I just got a Raspberry Pi installed in my PVS6, and I’m exited to try your integration as soon as it’s updated :slight_smile:

#10

Not sure if they’ve updated stuff on the PSV6, but I’ve loaded the integration and get values that update. I’m still working on implementing all the values on my dashboard, but so far I can at least see production and consumption, which is a good start.

#11

I take it back. I’m not actually seeing consumption. I’m seeing solar power and grid power. I don’t see a consumption value.
Side note question, when I go to the 172.27.53.1 landing page, should it give me the option to claim everything from scratch? To me, it looks like nothing was ever claimed, but maybe the landing page just always gives you that option?

1 Like
#12

Hi Keith,

I see you updated your component to 0.07. Does this include changes to update? My basic test shows data updating. Am I imagining things?

Thanks!

#13

:tada: this should finally be fixed. Sorry for the delay here I had to get permissions to contribute with my new employer and that took longer than expected but I finally have it. Should now support PVS5 and PVS6.

#14

Thank you so much!

1 Like
#15

Just setup Keith’s setup which works great! I leveraged Scott’s Pi setup using HA-proxy and pointed the integration to the Pi’s IP.

Currently running both setups now but hoping to sunset the nodeRed version soon.

How frequently does the SunPower dump command break? I noticed it happening every 4-5 days on the old method

#16

Anyone having a guide to getting this to work with the PVS6? I have Scott Grubys HA-proxy setup running with node-RED, and I have installed the " tesla-style-solar-power-card" in HACS.

What/how do I need to configure it to present the data on the dashboard?

#17

I’m noticing that in HAProxy logs I start with 200 requests then start getting 503 requests for ~2 days unless I manually reboot the Pi. Is there anything else I can check to see why this is happening?

#18

Is anyone willing to share their Lovelace config?

#19

@Keith_Baker On your integration, is the intent to get entity ids such as

sensor.power1, sensor.power2, ...

Is there any way to provide a bit more context here to disambiguate them from other Power sensors?

#20

Anyone else see this message…? Does it affect integrations?

To support our legacy devices, we have extended our SunPower Console sunset date for residential installations to August 20th, 2021.

For the best mobile commissioning experience please use our new app, SunPower Pro Connect, for any installations with PVS6.

SunPower Pro Connect is a commissioning app available only to authorized SunPower installers. A SunPower Pro account is required to log in to the application.

If you are a SunPower authorized installer and need an account, please contact [email protected] and request an account for access.

If you already have an account and are unable to log in, please contact [email protected] for account assistance.