PLEASE NOTE: If you had an account with the previous forum, it has been ported to the new Genetry website!
You will need to reset the password to access the new forum. Click Log In → Forgot Password → enter your username or forum email address → click Email Reset Link.
Another thing to try is if you have access to the router is to change the SSID and connect the inverter to the new SSID this makes it so your inverter is all on its own on that network. I know sounds dumb, but the last two updates I did the inverter got stuck in a reboot cycle trying to connect and download the update and that was the only way to get it out of that loop. I am on on a PJ Genetry LCD upgraded inverter so not apples to apples different code base, but something to try to see if it helps. Worked for me the last two times I updated since it just kept getting in that loop. I am thinking there is something on my network that doesn't play well with connecting to the upgrade server.
52 minutes ago, AquaticsLive said:Another thing to try is if you have access to the router is to change the SSID and connect the inverter to the new SSID this makes it so your inverter is all on its own on that network. I know sounds dumb, but the last two updates I did the inverter got stuck in a reboot cycle trying to connect and download the update and that was the only way to get it out of that loop. I am on on a PJ Genetry LCD upgraded inverter so not apples to apples different code base, but something to try to see if it helps. Worked for me the last two times I updated since it just kept getting in that loop. I am thinking there is something on my network that doesn't play well with connecting to the upgrade server.
I need to get revised code down to your codebase as well. Pretty sure the crash-looping was a fault with the WiFi baseline firmware--which has since been fixed.
The issue that I'm guessing is happening with <a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/147-steve-trumann/?do=hovercard" data-mentionid="147" href="/profile/147-steve-trumann/" rel="">@Steve Trumann is an ISP-related data corruption. <a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/133-notmario/?do=hovercard" data-mentionid="133" href="/profile/133-notmario/" rel="">@NotMario was able to replicate it by duplicating the inverter's HTTP GET request with a CURL command on his laptop--and the ISP provided corrupted data. It appears that if I change the HTTP request headers, the ISP won't corrupt the data--but I'm very hesitant to change the stock default request headers to solve this issue...because I have no idea whether it would pop up problematic elsewhere.
And FWIW the ISP that <a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/133-notmario/?do=hovercard" data-mentionid="133" href="/profile/133-notmario/" rel="">@NotMario was experiencing file corruption on? AT&T.
If you don't mind answering <a contenteditable="false" data-ipshover="" data-ipshover-target="/profile/147-steve-trumann/?do=hovercard" data-mentionid="147" href="/profile/147-steve-trumann/" rel="">@Steve Trumann what state are you in?
One solution included in the 1.2r0 update is...firmware uploads. This would bypass the ISP data corruption issues--you would download the update file to your phone/laptop, and then directly upload it from said phone/laptop to the inverter. Problem is, it's a catch-22: you have to get 1.2r0 before you can use that feature!
I need to get revised code down to your codebase as well. Pretty sure the crash-looping was a fault with the WiFi baseline firmware--which has since been fixed.
The ISP in question is FirstNet. AT&T was contracted to build/maintain it and share antennae, but are otherwise separate networks.
FWIW, as long as the inverter will be happy with different headers (ie. there isn't some technical limitation preventing "identity" encoding from being usable), i would completely remove the Accept-Encoding header altogether, or set it to "identity". These days it's pretty unusual to use chunked encoding of any kind - especially for static files.
A quick and dirty solution for the layman would be to connect your inverter to your phone's hotspot. (assuming you don't have firstnet on your phone...)
I need to get revised code down to your codebase as well.
That will be awesome, I am sure others that purchased the upgrades from Sean will enjoy getting an update as well.
Thanks e everyone for the input. By the way I am in North Carolina. The internet and cell service has been very bad today. I do have a mini with a different carrier for emergency use. But I would have to get the inverter to talk to it. Then change it back to AT&T afterwards. That sounds like a lot of trouble to.
I have tried numerous times tonight. The one suspected thing I see is GS_Inverter Connected without internet, this is after scanning the code.
Thanks e everyone for the input. By the way I am in North Carolina. The internet and cell service has been very bad today. I do have a mini with a different carrier for emergency use. But I would have to get the inverter to talk to it. Then change it back to AT&T afterwards. That sounds like a lot of trouble to.
I understand, but if the inverter can't get an uncorrupted update file...there's not much we can do about it remotely. Am looking into this issue with @notmario, and we'll do some testing to see if we can "ruggedize" the inverter's HTTP connectivity a bit--which might solve the issue. (But again, you'd need the update to get the solution!)
On 8/10/2022 at 12:27 PM, Sid Genetry Solar said:Seamless ATS transitions from grid -> battery. (Currently the battery -> grid transition is seamless, but not the return.)
*note that "power loss" transitions never will be seamless. It's not feasibly possible.
This note is referring to power-loss situations only, right? Manual and Automatic [elective] transfers can be seamless?
This note is referring to power-loss situations only, right? Manual and Automatic [elective] transfers can be seamless?
Yes. If power is lost, the inverter can't prepare for it. But if it's purposely switching (without AC input loss), it can technically do so seamlessly.
@notmario: worth noting, I can definitely "tighten up" the glitch on power-loss transfers. Currently, the transfer delay is software extended...while the CPU waits to ensure that the AC output voltage is basically zero BEFORE it fires up the FETs (this to protect against direct AC backfeed into the inverter's output). The problem is that all the feedback registers in the firmware are on a running 2-step average. This means that even though power may go from 240v to 0v in one cycle, the average will run 240v -> 120v -> 60v -> 30v -> ah, 3 cycles after power actually disappeared, THEN it can enable the inverter mode. That's what I'd like to tighten up for you to test.
Sure thing. I don't consider it a "glitch" so much as an unfortunate timing.
For a lot of people this probably wouldn't bother them. I have a lot of PSUs that go into a power-fault protection state, and refuse to turn on until a bigger outage is noticed.
That ends up affecting routers, which affects security cameras and etc. It's a mess.
Let me know when you have something to test, i'm happy to see if we can get this one working. In the absolute worst case, an off-on timer would suffice. So at least it doesn't mess up the PSUs.