Since upgrading to the FoxCloud2.0 version, I can no longer set times to force charge the battery either on the new version, the old version or the browser based version.
v2.0 says 'Parameter does not meet expectations'
v1.0 says 'Operation timed out'
Browser says 'Operation timed out'
Pre update, I had 2 timings, one from 11:30 to 05:30 & the other 04:00 to 05:30
I need to be able to toggle the 11:30 to 05:30 setting so that it is on when I charge my car so that the Ohme charger doesn't drain the house battery and uses the Octopus low tariff during the night.
Any ideas?
Thanks in advance.
App Version 2.0
-
Dave Foster
- Posts: 1184
- Joined: Thu Oct 13, 2022 7:21 pm
There have been a number of these reports over the last few weeks, but normally using the website clears it.
It sounds a bit drastic but if it doesn't clear within 24 hours - a shutdown and restart of the inverter appears to correct this problem - there is a video in thw guides section that will help with that, but basically you isolate PV (DC), you isolate Grid (AC), power off the battery and open the battery isolator - wait until the inverter screen goes blank then reverse the process, battery power on, AC power on, PV power on - after 2 minutes of checking it should be back on-line, then 10 minutes later you should be able to set a charge period.
EDIT: For information (i've just checked mine and it times out as well), if that doesn't fix it and you have access to the inverter panel itself, you can change the charge times via Settings, i've attached a system menu screen shot which shows where to find Charge Times. ('Settings', 'Work Mode', 'Charge Time')
And also what the screen looks like to change the times
It sounds a bit drastic but if it doesn't clear within 24 hours - a shutdown and restart of the inverter appears to correct this problem - there is a video in thw guides section that will help with that, but basically you isolate PV (DC), you isolate Grid (AC), power off the battery and open the battery isolator - wait until the inverter screen goes blank then reverse the process, battery power on, AC power on, PV power on - after 2 minutes of checking it should be back on-line, then 10 minutes later you should be able to set a charge period.
EDIT: For information (i've just checked mine and it times out as well), if that doesn't fix it and you have access to the inverter panel itself, you can change the charge times via Settings, i've attached a system menu screen shot which shows where to find Charge Times. ('Settings', 'Work Mode', 'Charge Time')
-
Dave Foster
- Posts: 1184
- Joined: Thu Oct 13, 2022 7:21 pm
Old TV repair man's trick 
If it doesn't work, i've updated the previous post with a link to show how to do it by the inverter panel menu.
If it doesn't work, i've updated the previous post with a link to show how to do it by the inverter panel menu.
The problem with "operation timed out" (41203) is that as far as I can tell in response to the client request for data, their cloud service is failing to send the "read register" commands to the inverter to fetch said data at all, so you might expect rebooting the inverter to do nothing at all since it's clearly not a problem with it.
It's just about possible, I guess, that the cloud service holds some persistent state about the association between your account/site and the current inverter TCP connection which it loses and can no longer send requests for that reason, and resetting the TCP connection restores that. On the other hand the cloud seems perfectly capable of sending a periodic "read multiple 40006+10" every five minutes, which my firmware version responds to with an "ILLEGAL DATA ADDRESS" response. I assume current firmwares actually understand that. Given the protocol includes the firmware and protocol versions, I wonder why the cloud service doesn't know that that request isn't going to work... Occasionally I see other reads, such as a recent read for 41000+1 which appears to coincide with reloading a specific page on https://www.foxesscloud.com/. Still getting the 4 times a day writes to 40000+6 to set the current date/time.
Actually looking at the failures since Friday morning, I see the occasional read (for 41001+6, which is the force charge timing range) does come through to the inverter, maybe between every 3 to 10 attempts, and the inverter replies promptly, but then there should be a subsequent read for 41007+16 (which contains amongst other things min/max SoC limits) which doesn't go through and the cloud service still manages to reply 41203 on the other side. That does kind of suggest that the cloud hasn't lost state and rebooting the inverter is even less likely to do anything useful.
It's just about possible, I guess, that the cloud service holds some persistent state about the association between your account/site and the current inverter TCP connection which it loses and can no longer send requests for that reason, and resetting the TCP connection restores that. On the other hand the cloud seems perfectly capable of sending a periodic "read multiple 40006+10" every five minutes, which my firmware version responds to with an "ILLEGAL DATA ADDRESS" response. I assume current firmwares actually understand that. Given the protocol includes the firmware and protocol versions, I wonder why the cloud service doesn't know that that request isn't going to work... Occasionally I see other reads, such as a recent read for 41000+1 which appears to coincide with reloading a specific page on https://www.foxesscloud.com/. Still getting the 4 times a day writes to 40000+6 to set the current date/time.
Actually looking at the failures since Friday morning, I see the occasional read (for 41001+6, which is the force charge timing range) does come through to the inverter, maybe between every 3 to 10 attempts, and the inverter replies promptly, but then there should be a subsequent read for 41007+16 (which contains amongst other things min/max SoC limits) which doesn't go through and the cloud service still manages to reply 41203 on the other side. That does kind of suggest that the cloud hasn't lost state and rebooting the inverter is even less likely to do anything useful.
-
Dave Foster
- Posts: 1184
- Joined: Thu Oct 13, 2022 7:21 pm
As you say the app needs to ask the Fox cloud to request the battery registers, the complexity is that battery settings are kept in a different dataset to the statistics data, and sometimes this dataset ‘server’ fails to respond which stops the request getting to the inverter - hence the eventual time out, but it can also be the datalogger that has a poor connection or the inverter is off-line which is causing this - however over the past few days there have been a number of reports of the inverter manager effectively locking up and you get this same error which requires the inverter to be restarted.jsfoxe wrote: ↑Mon Jun 03, 2024 3:34 am The problem with "operation timed out" (41203) is that as far as I can tell in response to the client request for data, their cloud service is failing to send the "read register" commands to the inverter to fetch said data at all, so you might expect rebooting the inverter to do nothing at all since it's clearly not a problem with it.
Having checked mine and finding that the battery settings were timing out, it seems likely it’s the former problem i.e. the battery dataset server has a problem and that’s why I posted the addendum to set the periods manually - from what I can see on my debugging the read request to get the cloud stored times is working, but the onwards request to the inverter isn't occurring, or the inverter isn't responding.
The cloud implementation relies heavily on firmware versions (it actually translates this to protocol variant), the protocol variant changes occasionally with a firmware change but not every time - only when something is added. You can see when you request named keys from the Fox cloud, many of the operations are not 'named' but use an indexed list (i.e. 14th in the list is 'Write Yield Total' etc..), whenever this protocol variant changes the assumption about where to find these items is broken, so it's hard coded at both ends that things that are not supported in that protocol version get an invalid response (when using the Fox website you'll see it sometimes being passed in the URL parameters).
@Gillson
Update1 as of 12:01 on 3rd June i'm still getting operation timed out using web or apps - until Foxess correct the issue the only way to set the charge times is via the inverter menu as posted above.
Update2 as of 15:23 on 3rd June now working fine, definitely a cloud infrastructure problem..
Yup, last failure for me was 3 Jun 13:43:29 UTC, next attempt at 13:48:31 UTC succeeded.
However, even after a reload the website https://www.foxesscloud.com/ is still showing empty/broken battery info on the Overview or Sites Detail pages, and no battery at all on the Inverter Detail page. So it looks like the ability to control battery operation via their website is currently broken or missing.
However, even after a reload the website https://www.foxesscloud.com/ is still showing empty/broken battery info on the Overview or Sites Detail pages, and no battery at all on the Inverter Detail page. So it looks like the ability to control battery operation via their website is currently broken or missing.
-
Dave Foster
- Posts: 1184
- Joined: Thu Oct 13, 2022 7:21 pm
I just tried with my agent account and it’s working ok on the foxesscloud website, but it’s possible they are in the middle of re-building the server that holds the battery datasets and it’s only partially complete.. it’s always a work in progressjsfoxe wrote: ↑Mon Jun 03, 2024 3:54 pm Yup, last failure for me was 3 Jun 13:43:29 UTC, next attempt at 13:48:31 UTC succeeded.
However, even after a reload the website https://www.foxesscloud.com/ is still showing empty/broken battery info on the Overview or Sites Detail pages, and no battery at all on the Inverter Detail page. So it looks like the ability to control battery operation via their website is currently broken or missing.
