I've released the changes as a pre-release, on your HA if you go to HACS, find FoxESS Cloud and click on the 3 dots to the right hand side, choose re-download, select 'Need a different version' and choose the v0.44-beta1, when it's downloaded restart HA.
https://github.com/macxq/foxess-ha/rele ... 0.44-beta1
If you can run with this version for a few days to check it's working correctly - the inverter on-line state will continue to show as on-line (as that is what it is reporting) but instead keep an eye on the runningState which would normally be 163 (on-grid) during the day.
When the runningState changes to 161 (waiting) or 162 (checking) the integration will treat the inverter as if it were off-line.
T10-G3 Inverter Status during non-solar hours
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Sounds like a plan.Just downloaded and installed the release now. Will monitor and keep you posted as well.
Currently the inverter is still showing as Online, and continues to do so after the installation of the beta release but the Load Power, Grid Consumption etc. are now unknown which were previously throwing garbage values.Will keep you posted on this week's progress as well.
Some screenshots:
Thank you very much for your continued dedication & support in sorting this out for me!
Currently the inverter is still showing as Online, and continues to do so after the installation of the beta release but the Load Power, Grid Consumption etc. are now unknown which were previously throwing garbage values.Will keep you posted on this week's progress as well.
Some screenshots:
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Hey Dave,
Hope you are doing well.
Just an observation from today, however low in significance. As the PV Power values were at 0, the inverter was transitioning to Checking and then Waiting. At 6:28PM it moved to Waiting and that as a result made Load Power, Grid Consumption etc. values all to Unknown, however, FoxCloud V2 App continued showing Grid Consumption until 6:39PM.
I did notice that the usual refresh time on V2 is between 3-5 minutes (also displays the "last updated at"), but it was showing "Updated 14 minutes ago". While this may have been an incorrect value and not the true Grid Consumption considering the last updated at, I was wondering whether the 10 mins variance in between FoxCloud HA and FoxCloud V2 could have a higher impact in any case.
I hope I was able to give you the details correctly and not confuse you in return.
Short Summary: I saw that HA started reporting Unknown for Load Power and Grid Consumption approximately 10mins earlier than what V2 was reporting.
Here are some screenshots:
Thanks!
Hope you are doing well.
Just an observation from today, however low in significance. As the PV Power values were at 0, the inverter was transitioning to Checking and then Waiting. At 6:28PM it moved to Waiting and that as a result made Load Power, Grid Consumption etc. values all to Unknown, however, FoxCloud V2 App continued showing Grid Consumption until 6:39PM.
I did notice that the usual refresh time on V2 is between 3-5 minutes (also displays the "last updated at"), but it was showing "Updated 14 minutes ago". While this may have been an incorrect value and not the true Grid Consumption considering the last updated at, I was wondering whether the 10 mins variance in between FoxCloud HA and FoxCloud V2 could have a higher impact in any case.
I hope I was able to give you the details correctly and not confuse you in return.
Short Summary: I saw that HA started reporting Unknown for Load Power and Grid Consumption approximately 10mins earlier than what V2 was reporting.
Here are some screenshots:
Thanks!
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Just looking at the logs (apologies time is shown in GMT my timezone)
At 13:21:17 the inverter replied with it's current variables and the runningState has gone to 162 (checking), at this point the data sample appears to be still valid i.e. loads showing 1.637kW - but because it had changed to checking I set the inverter off-line so that last data sample never got through.
On the next sample at 13:26:17 the inverter had gone into runningState 161 (waiting) and the data samples had frozen and were no longer valid.
I think the disparity is that the Fox cloud knows the inverter is no longer responding (hence the last updated 14 minutes ago) but it seems to wait for a few cycles before it switches to off-grid - if the datalogger had gone off-line it would happen straight away but it's obviously waiting for 3 missed samples before it shows it as off-line.
If you take the time on the app when it said 'last update 15 minutes ago' (16:39 - 15 = 16:24) it aligns with my last valid data sample at 13:21 (I guess you are +3 hours GMT?) and as the datalogger only sends data samples every 5 minutes it largely depends where you are in the polling cycle.
The mistake I made is to mark the sample bad when it goes into checking (162), when it fact it is actually still ok and I should have allowed that sample through which would have gotten you an extra data point, it's only when it is state 161 that the inverter has gone to sleep.
The one thing I have seen from the logs is that the inverter doesn't always go to 162 before it settles at 161, it sometimes goes straight to 161 - possibly the just the speed of sunset ?
What I think I need to do is to allow the 162 through (as it was a last good data sample) and then shutdown on the 161 - ironically the status HA provides will be almost real time, whereas the Fox cloud will be up to 15 minutes out (but we'll have the same number of data samples).
At 13:21:17 the inverter replied with it's current variables and the runningState has gone to 162 (checking), at this point the data sample appears to be still valid i.e. loads showing 1.637kW - but because it had changed to checking I set the inverter off-line so that last data sample never got through.
On the next sample at 13:26:17 the inverter had gone into runningState 161 (waiting) and the data samples had frozen and were no longer valid.
I think the disparity is that the Fox cloud knows the inverter is no longer responding (hence the last updated 14 minutes ago) but it seems to wait for a few cycles before it switches to off-grid - if the datalogger had gone off-line it would happen straight away but it's obviously waiting for 3 missed samples before it shows it as off-line.
If you take the time on the app when it said 'last update 15 minutes ago' (16:39 - 15 = 16:24) it aligns with my last valid data sample at 13:21 (I guess you are +3 hours GMT?) and as the datalogger only sends data samples every 5 minutes it largely depends where you are in the polling cycle.
The mistake I made is to mark the sample bad when it goes into checking (162), when it fact it is actually still ok and I should have allowed that sample through which would have gotten you an extra data point, it's only when it is state 161 that the inverter has gone to sleep.
The one thing I have seen from the logs is that the inverter doesn't always go to 162 before it settles at 161, it sometimes goes straight to 161 - possibly the just the speed of sunset ?
What I think I need to do is to allow the 162 through (as it was a last good data sample) and then shutdown on the 161 - ironically the status HA provides will be almost real time, whereas the Fox cloud will be up to 15 minutes out (but we'll have the same number of data samples).
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Absolutely. I believe the math you did explained it clearly to me, and yes aligned on the fact that the last most recent data point if received would be great to have also 
Oh and btw I'm in Pakistan so it is +5 GMT.
Thanks again!
Oh and btw I'm in Pakistan so it is +5 GMT.
Thanks again!
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Ha, sorry yes your clock is 6:38pm (18:38) I got those maths wrongtalal.hassan01 wrote: Tue Feb 11, 2025 4:40 pm Absolutely. I believe the math you did explained it clearly to me, and yes aligned on the fact that the last most recent data point if received would be great to have also
Oh and btw I'm in Pakistan so it is +5 GMT.
Thanks again!
I'll do another beta release shortly to skip state 162
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Ok try v0.44-beta2 - that will only switch off-line if runningState 161 is returned.
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Awesome! doing that now and will keep you posted.
Appreciated as always!
Appreciated as always!
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Hey Dave,
It was one of those blessed days today where the Inverter decided to become "Off-line", but something new happened today.
Inverter and Data logger went Off-line at approx. 7PM but the Running State value did not change and is still stuck on On-Grid.
The Load power etc. values continued to populate data for approx 5 minutes until the inverter went offline at 7:05PM.
Sharing screenshots for better understanding:
It was one of those blessed days today where the Inverter decided to become "Off-line"
, but something new happened today.Inverter and Data logger went Off-line at approx. 7PM but the Running State value did not change and is still stuck on On-Grid.
The Load power etc. values continued to populate data for approx 5 minutes until the inverter went offline at 7:05PM.
Sharing screenshots for better understanding:
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Ok thanks, the running state used to become unavailable when the inverter went off-line, but as part of these changes, I made it so it continues to displays the last known state, but when it goes off-line, it will as you see stick at 163….
I think what I will do is to make the integration trigger ‘164: off-grid’ state when the datalogger goes off-line, you’ll get the ‘161: waiting’ state if it doesn’t so either way you will know it’s not available.
I’ll make the change on my test system first and monitor it for a couple of days before releasing - just in case there are any more gems
I think what I will do is to make the integration trigger ‘164: off-grid’ state when the datalogger goes off-line, you’ll get the ‘161: waiting’ state if it doesn’t so either way you will know it’s not available.
I’ll make the change on my test system first and monitor it for a couple of days before releasing - just in case there are any more gems
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Ahh, understood. Yes sir aligned with your plan!
And just confirming if I added it up correctly:
Scenario 1:
If the inverter goes offline, the Running state would show 164 i.e., "Off-grid" (a masking to the existing "Unknown" value)
Scenario 2:
If the inverter remains online but the datalogger is offline, the Running state would become 161 i.e., "Waiting", triggering Load etc values to become Unknown.
Thank you very much.
And just confirming if I added it up correctly:
Scenario 1:
If the inverter goes offline, the Running state would show 164 i.e., "Off-grid" (a masking to the existing "Unknown" value)
Scenario 2:
If the inverter remains online but the datalogger is offline, the Running state would become 161 i.e., "Waiting", triggering Load etc values to become Unknown.
Thank you very much.
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Yep that’s spot on - with the change made this is my test system now (connected to your inverter via openapi)
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Hi, it has been working well these last few days so I have released the final change (164 - off-grid when datalogger goes off-line).
The latest pre-release is v0.44-beta3, can you install and run with that for a few weeks and if all good i'll do a formal release.
The latest pre-release is v0.44-beta3, can you install and run with that for a few weeks and if all good i'll do a formal release.
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Awesome and great stuff!
Thanks alot Dave, I'll update it today and then keep ypu posted.
Cheers
Thanks alot Dave, I'll update it today and then keep ypu posted.
Cheers
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Hey Dave,
Hope you're doing well.
So the fix you made is working spot on. However, there is one slight observation that I came across today and wanted to share it with you as well:
The running state changed to waiting at 18:23 PM which as a result populated the Load Power etc with "Unknown", but FoxCloud did another last pull from the datalogger at 18:24 and populated the load power value with an updated one.
In theory, our "Last Pull" was still not the last one based on the Running State value, but accordingly to the datalogger, there was one value more that was updated before going into sleep mode.
While I know this may be complex to handle, wanted to share these findings with you. Otherwise, the latest beta build is working as expected.
Thanks!
Hope you're doing well.
So the fix you made is working spot on. However, there is one slight observation that I came across today and wanted to share it with you as well:
The running state changed to waiting at 18:23 PM which as a result populated the Load Power etc with "Unknown", but FoxCloud did another last pull from the datalogger at 18:24 and populated the load power value with an updated one.
Thanks!
- Attachments
-
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Thanks, I have seen that case but as you say it is very complex to catch.
The Fox cloud servers know when it receives a valid data sample but if it doesn’t receive another for 15 minutes it still returns valid variable data until an internal timeout sets it as off-line - and there is nothing in the response to work out whether it is still valid or aged. - I’ll take another quick look just to be sure.
The Fox cloud servers know when it receives a valid data sample but if it doesn’t receive another for 15 minutes it still returns valid variable data until an internal timeout sets it as off-line - and there is nothing in the response to work out whether it is still valid or aged. - I’ll take another quick look just to be sure.
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
I have been testing a change over this past week - I can work out whether the data sample is valid or not (it calculates the age since it was sent) - it's been a lot more trouble than it should have been as python doesn't handle international dates very well and so I have had to calculate the timezones myself and it works in GMT and GMT to PKT etc.. - so the next logical test is for me to create a pre-release which i'll try and do today, i'll mark it as do not use unless you are involved etc.. and then if you could test it on your system please.
I'll post more information once i've done the beta release.
I'll post more information once i've done the beta release.
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
I've released v0.44-beta4 with the check for data sample age:
Can you please download and install that version, make sure full debugging logging is enabled and restart HA.
Whenever the integration checks the OA Device Details for the datalogger on/off line status you'll see in the logs these 2 lines
Immediately following this if on-line (1) it will attempt to get the latest data sample and you'll see the data sample time with it's converted timestamp and finally the line at the bottom which contains the calculate age in minutes (this logs shows 266 which is valid)
The strange results above are because my logs are spanning international timezones so it has worked out the difference, corrected it and compared it to get the age; your logs should look somewhat more straight forward.
Can you please download and install that version, make sure full debugging logging is enabled and restart HA.
Whenever the integration checks the OA Device Details for the datalogger on/off line status you'll see in the logs these 2 lines
The Statetest 1 - indicates on-line, (2 is alarm, 3 off-line)2025-03-01 09:54:06.428 DEBUG (MainThread) [custom_components.foxess.sensor] OA Device Detail System has No Battery: False
2025-03-01 09:54:08.497 DEBUG (MainThread) [custom_components.foxess.sensor] Statetest 1
Immediately following this if on-line (1) it will attempt to get the latest data sample and you'll see the data sample time with it's converted timestamp and finally the line at the bottom which contains the calculate age in minutes (this logs shows 266 which is valid)
Can you post these logs please (but obscure or remove the line with your serial number) and i'll check that it is working correctly.2025-03-01 09:54:10.501 DEBUG (MainThread) [custom_components.foxess.sensor] getRaw OA request: {"sn":"60xTxxxxxxxxxxxx" }
2025-03-01 09:54:10.722 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-01 14:49:45 PKT+0500
2025-03-01 09:54:10.724 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables tsrcv stamp: 1740822585.0, offset: 18000
2025-03-01 09:54:10.724 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-01 14:49:45 PKT+0500 timestamp rcv:1740822585.0
2025-03-01 09:54:10.724 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-01 14:49:45 PKT+0500 vs 2025-03-01 09:54:10.724611 timestamps r:1740822585.0 now:1740822851, age: 266
The strange results above are because my logs are spanning international timezones so it has worked out the difference, corrected it and compared it to get the age; your logs should look somewhat more straight forward.
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Okay understood. I'll update this today and keep you posted on the outcome.
Thanks Dave!
Thanks Dave!
-
talal.hassan01
- Posts: 32
- Joined: Mon Jul 29, 2024 12:39 am
Hey Dave,
The update has been installed, and I can see the StateTest variable showing 1 as well. Currently, it is 2:40PM PK Time. As you requested here are the logs:
The update has been installed, and I can see the StateTest variable showing 1 as well. Currently, it is 2:40PM PK Time. As you requested here are the logs:
The only thing that caught my attention was a message stating invalid age.2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Updating data from https://www.foxesscloud.com/
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Time now: 14, last 14
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Main Poll, interval: 603*********, 5
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Statetest 1
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] getRaw OA request: {"sn":"603*********" }
2025-03-02 14:37:33.356 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables tsrcv stamp: 1740890184.0, offset: 18000
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500 timestamp rcv:1740890184.0
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500 vs 2025-03-02 14:37:33.357716 timestamps r:1740890184.0 now:1740908253, age: 18069
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables invalid age: 2025-03-02 14:36:24 PKT+0500 vs 2025-03-02 14:37:33.357716 timestamps r:1740890184.0 now:1740908253, age: 18069
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
Thanks, that is just what I needed - sadly i've got a mistake as it's applying a double correction - it's worked out your time zone and added the offset to it, but not realised that it was in that same time zone and didn't need to do anything - let me have a think about it and come back to you.talal.hassan01 wrote: Sun Mar 02, 2025 9:41 am Hey Dave,
The update has been installed, and I can see the StateTest variable showing 1 as well. Currently, it is 2:40PM PK Time. As you requested here are the logs:
The only thing that caught my attention was a message stating invalid age.2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Updating data from https://www.foxesscloud.com/
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Time now: 14, last 14
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Main Poll, interval: 603*********, 5
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] Statetest 1
2025-03-02 14:37:32.726 DEBUG (MainThread) [custom_components.foxess.sensor] getRaw OA request: {"sn":"603*********" }
2025-03-02 14:37:33.356 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables tsrcv stamp: 1740890184.0, offset: 18000
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500 timestamp rcv:1740890184.0
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables time: 2025-03-02 14:36:24 PKT+0500 vs 2025-03-02 14:37:33.357716 timestamps r:1740890184.0 now:1740908253, age: 18069
2025-03-02 14:37:33.357 DEBUG (MainThread) [custom_components.foxess.sensor] OA Variables invalid age: 2025-03-02 14:36:24 PKT+0500 vs 2025-03-02 14:37:33.357716 timestamps r:1740890184.0 now:1740908253, age: 18069
Would it be ok if I get you to make a quick change to a single file on your system and then restart to correct the problem and then when I know it's ok I can fix the release.?
-
Dave Foster
- Posts: 1790
- Joined: Thu Oct 13, 2022 7:21 pm
If you are able to could you make this change to the file (let me know if not and i'll update a pre-release)
Open the file /homeassistant/custom_components/foxess/sensor.py
Line 1105 is
change it to be
Save the file and restart home assistant and then copy the same logs when you get chance.
It should work properly this time !
Open the file /homeassistant/custom_components/foxess/sensor.py
Line 1105 is
Code: Select all
tsrcv = tsrcv - tzoffset
Code: Select all
tsrcv = tsrcv # - tzoffset
It should work properly this time !