Support for T series #77
Replies: 17 comments 9 replies
-
|
The same problem. Kepp getting 40257 data formatting error which in course stops dsiplaying any data in the panel. 2024-06-07 05:04:05.096 DEBUG (MainThread) [custom_components.foxess.sensor] getReport OA request:{"sn":"60AT123T2CCF008","year":2024,"month":06,"dimension":"month","variables":["feedin","generation","gridConsumption","chargeEnergyToTal","dischargeEnergyToTal","loads"]} |
Beta Was this translation helpful? Give feedback.
-
|
Ok, that’s a strange one, rhe report data is formatted ok, except that month is being entered with a leading zero “06” whereas it should be “6”, - the strftime() call i’m using to format it is supposed to strip the leading zero but the function is ‘platform dependent’ and that’s the first time I have ever seen it do that - what platform are you running on ? |
Beta Was this translation helpful? Give feedback.
-
|
Thank You kindly for responding. I’m running it using Windows 11 Python container. There is a ready-to-run executable available for Home Assistant:
https://github.com/AlexxIT/HassWP/releases
All the rest – HACS and FoxESS sensor are configurable in this environment without any problems, after adjusting for time string format differences: %_Y ==> %Y, etc. Time string formats are as explained here: <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170&redirectedfrom=MSDN> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170&redirectedfrom=MSDN
After many trials, I noticed that this FoxESS sensor wrongly reports the inverter being off-line when it was actually on-line. So I stupefied the on-line status recognition in the sensor.py – by making on-line state permanent and run it all again. Although the 40257 error is still reported, the HA started displaying the most inverter controls from the FoxESS G3-T12 and G3-T15 in the HA front panel. But not all of them. E.g. all energy related controls (e.g. energy generated, solar) are not recognized or reported as zeroes. My suspicion is that this is due to differences in naming energy controls in the series T and other (hybrid) inverters. May be for the FoxESS G3 T series, a completely differently structured sensor.py is required, despite platform dependent string formatting differences. May be energy controls are differently named than in other series and this causes the errors – 40257 and wrong on-line status recognition.
After your response, I found this:
https://stackoverflow.com/questions/904928/python-strftime-date-without-leading-0
and reformatted the sensor.py to remove leading zero in the month number: %m ==> %#m, but it didn’t stop the 40257 error. I also removed leading zero from year format for tests – it still did not prevent the 40257 error. Its cause must be a different one.
Another painful thing is lack of historic data in this HA application – a full history import from the FoxESS cloud would be nice, also data export for further analysis in EXCEL, TXT or CSV format.
I’m attaching the manipulated sensor.py (time format adjustment to remove the month’s leading zero + making the on-line status permanent, in order to enforce any reporting to the HA front panel at all, and this was good for some tests only, with energy still wrongly displayed).
I’d be very grateful for having a look at these problems, may be you will find some solutions.
From: Dave Foster ***@***.***>
Sent: Friday, June 7, 2024 9:36 AM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Ok, that’s a strange one, rhe report data is formatted ok, except that month is being entered with a leading zero “06” whereas it should be “6”, - the strftime() call i’m using to format it is supposed to strip the leading zero but the function is ‘platform dependent’ and that’s the first time I have ever seen it do that - what platform are you running on ?
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMVBJKUGECCZ65KYECDZGFPGJAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMOJYGUYDO> .
You are receiving this because you commented. <https://github.com/notifications/beacon/BBCRGMUJ5JW2HB6H4HUP6WTZGFPGJA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQASP6MW.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
As it is getting an error from the openapi, it sets the status off-line - the openapi is a bit flaky at the moment, Fox are supposed to be working on it, but any error from the api results in an off-line status. You shouldn't be getting the error, let me modify the code to use a platform agnostic version, the error will stop and it will stay on-line - i'll come back to you once i've got something for you to test. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you kindly, thank you very much.
I’d like to have a reliable tool – also capable of exporting data for further analysis, also having full data export of historic data from FoxESS Cloud. The FoxESS Cloud web app produces pictures, no data export available. So the HA is probably the best choice, provided that Open API will allow such wide range data exports. Also for further integrations. I’d like to integrate it with remote WiFi switches – to control electric heating system – switch it on when the energy is cheap as coming from the sun.
From: Dave Foster ***@***.***>
Sent: Friday, June 7, 2024 1:27 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
As it is getting an error from the openapi, it sets the status off-line - the openapi is a bit flaky at the moment, Fox are supposed to be working on it, but any error from the api results in an off-line status.
You shouldn't be getting the error, let me modify the code to use a platform agnostic version, the error will stop and it will stay on-line - i'll come back to you once i've got something for you to test.
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMWLEE6DFERB4ZYSG3DZGGKHJAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMBRGAYDC> .
You are receiving this because you commented. <https://github.com/notifications/beacon/BBCRGMWRDWBOXXDKHRRU45DZGGKHJA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQASQDIS.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
I have released a beta version that should correct this for you, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b2 This integration will give you access to the 'real time data' i.e. the 5 minute time samples and it will start to build energy data going forward and Home Assistant will allow you to control devices based on the state of the various sensors. This integration doesn't give you access to your historical data in the cloud, but have a look at these scripts which will may do what you want in pulling your historical data from the cloud and save it. https://github.com/TonyM1958/FoxESS-Cloud?tab=readme-ov-file#history-data |
Beta Was this translation helpful? Give feedback.
-
|
Thank you kindly very much.
I installed your new version of sensor.py and run the HA with this integration’s update, in parallel with the original FoxESS Cloud web app.
Your new version of FoxESS HA integration still produced a series of errors – in the Python environment, they occurred once only, at the start of the integration in the HA – see the part of log attached below, containing these errors:
2024-06-08 10:59:32.894 ERROR (MainThread) [homeassistant.components.sensor] Error adding entity sensor.nadrzeczna_25_szyszko_stefan_solar_power for domain sensor with platform foxess
Traceback (most recent call last):
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity_platform.py", line 580, in _async_add_entities
await coro
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity_platform.py", line 890, in _async_add_entity
await entity.add_to_platform_finish()
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity.py", line 1334, in add_to_platform_finish
self.async_write_ha_state()
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity.py", line 998, in async_write_ha_state
self._async_write_ha_state()
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity.py", line 1119, in _async_write_ha_state
state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity.py", line 1056, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\helpers\entity.py", line 1004, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\python-3.12.3.amd64\Lib\site-packages\homeassistant\components\sensor\__init__.py", line 548, in state
value = self.native_value
^^^^^^^^^^^^^^^^^
File "E:\Urzadzenia_Domowe\Instrukcje_Obslugi\FOTOWOLTAIKA\FoxESS\HAs_FoxESS-Cloud_Integration\config\custom_components\foxess\sensor.py", line 1258, in native_value
total = (loads + charge + feedIn - gridConsumption - discharge)
^^^^^^
UnboundLocalError: cannot access local variable 'feedIn' where it is not associated with a value
Despite of these errors listed above, most of the controls are displayed correctly in the HA front panel right after ~5 minutes after the start. All energy related: firstly they are still unknown or zeroed, then also presented in the front panel, after ~10-15 minutes.
There is also one significant issue – if compared to the original FoxESS Cloud web app, all the values drown by FoxESS Open API in Your HA integration are dramatically delayed – I estimated this delay as ~10-15 minutes minimum. This may be result of the FoxESS policy – a purposes disadvantage if compared to original FoxESS Cloud web app, or there is some way to set some parameters in the Open API access to get rid of this delay, I don’t know. In the HA’s energy panel, displaying the energy from solar is delayed ~1 hour or more, I don’t know actually why.
I will also test downloading to HA integration all the historical data from FoxESS cloud, as you suggested.
Thank you kindly one again, You did a really great job.
From: Dave Foster ***@***.***>
Sent: Saturday, June 8, 2024 10:29 AM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
I have released a beta version that should correct this for you, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b2
This integration will give you access to the 'real time data' i.e. the 5 minute time samples and it will start to build energy data going forward and Home Assistant will allow you to control devices based on the state of the various sensors.
This integration doesn't give you access to your historical data in the cloud, but have a look at these scripts which will may do what you want in pulling your historical data from the cloud and save it. https://github.com/TonyM1958/FoxESS-Cloud
—
Reply to this email directly, view it on GitHub <#77 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMQ3YBVLFJUVNNOBXJTZGK6DPAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJRG42TK> .
You are receiving this because you commented. <https://github.com/notifications/beacon/BBCRGMSB6RLUME4TRAACNT3ZGK6DPA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQASQYIW.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
Aaah ok, thanks for that, yes i've found that error - it is just a startup problem but i'll get that fixed now. On the timing, it samples the data every 5 minutes so it may be up to 4:59 minutes behind what you see on the cloud - but what is making it a lot worse at the moment is the OpenAPI problems I mentioned before. The OpenAPI usually replies in less than 400mS, but at times during the day it is taking up to a minute and that can cause the bigger delays that you are seeing. FoxESS are aware of the problem and know they need to commit more resources to it, but i'm being told it's not a quick fix and this may drag on for a bit longer yet. When the OpenAPI is responding correctly you will never be any more than 5 minutes behind the cloud, and usually a lot less. |
Beta Was this translation helpful? Give feedback.
-
|
In case You fixed this startup problem, please let me know where could I get the updated code.
While having this running stable, I want to test a simple automation with SonOFF WiFi switch – I want to use their simplest WiFi relay switch to start air condition, heater, freezer, dehumidizer, etc. when my solar kW output is above certain level, to run all of them on cheap energy. This is the simplest case for any such automation.
Another problem is a HA server itself:
* Currently I’m running it on a Windows PC gadget but this is energy consuming. What would be the best energy efficient solution – may be an Android tablet?
* When I switch off this PC, I loose the historical data for that period – is there any simple method to draw data from the cloud, covering such a time gap?
From: Dave Foster ***@***.***>
Sent: Saturday, June 8, 2024 1:17 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Aaah ok, thanks for that, yes i've found that error - it is just a startup problem but i'll get that fixed now.
On the timing, it samples the data every 5 minutes so it may be up to 4:59 minutes behind what you see on the cloud - but what is making it a lot worse at the moment is the OpenAPI problems I mentioned before.
The OpenAPI usually replies in less than 400mS, but at times during the day it is taking up to a minute and that can cause the bigger delays that you are seeing. FoxESS are aware of the problem and know they need to commit more resources to it, but i'm being told it's not a quick fix and this may drag on for a bit longer yet.
When the OpenAPI is responding correctly you will never be any more than 5 minutes behind the cloud, and usually a lot less.
—
Reply to this email directly, view it on GitHub <#77 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMSGKAX7E7I6FZLFEYTZGLRZRAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJSG43TG> .
You are receiving this because you commented. <https://github.com/notifications/beacon/BBCRGMRF4KTB5KBKOLATZWDZGLRZRA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQASQ2IK.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
Yes that's possible, the Sonoff devices when installed and configured in HA can be turned in an automation using the service 'Switch: Turn On' with the entity name of the sonoff device set (usually something like 'switch.mysonoff_device' The sensor for combined PV power will be named something like On the hardware, there are quite a few options for this - I use a Raspberry Pi with SSD attached which is low cost, low power and will run 24/7 without interaction, others use ultra low form factor pc's i've linked you to my colleagues page as he has documented what he uses here (url) I have released 'beta3' which fixes that startup issue - if you follow the same instructions, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b3 Please note the OpenAPI is at it's slowest during the afternoon and early eveneing, so you may find when you restart it takes a few minutes before your sensors get populated. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you kindly, for the updated code (I installed it and I’ll be testing it for some time, I let you know my oservations) and for Your advice concerning HA platforms. I will probably go for the low form PC version.
From: Dave Foster ***@***.***>
Sent: Saturday, June 8, 2024 2:32 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Yes that's possible, the Sonoff devices when installed and configured in HA can be turned in an automation using the service 'Switch: Turn On' with the entity name of the sonoff device set (usually something like 'switch.mysonoff_device'
The sensor for combined PV power will be named something like sensor.foxess_pv_power - in an automation you can add a test for an entity being above or below a certain value.
On the hardware, there are quite a few options for this - I use a Raspberry Pi with SSD attached which is low cost, low power and will run 24/7 without interaction, others use ultra low form factor pc's i've linked you to my colleagues page as he has documented what he uses here (url) <https://github.com/TonyM1958/HA-FoxESS-Modbus/wiki/Installing-Home-Assistant-on-a-USFF-PC>
Which option you choose largely depends on your familiarity with the type of equipment and your IT skills, home assistant is a very addictive 'rabbit hole'
I have released 'beta3' which fixes that startup issue - if you follow the same instructions, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b3
Please note the OpenAPI is at it's slowest during the afternoon and early eveneing, so you may find when you restart it takes a few minutes before your sensors get populated.
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMWIHL5YBZLW5EHSUCLZGL2VVAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJTGI4DK> .
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Your last HA FoxESS Cloud integration runs quite stable for a couple of days. So, may be You decide to advance its current status from early beta to something higher.
I decided to stick with my current environment for running Home Assistant server: properly expanded (8GB RAM, 1TB SSD) 17 years old Lenovo Intel notebook without UEFI, MS Windows 11 64bit. Energy cost with number of applications reduced to minimum and screen switched off – not specially larger than Rasberry Pi. This is a pragmatic way to avoid standard HA demand for UEFI PC which eliminates most of old PC stuff for running HA system directly. And in such a configuration I have all the analytical Windows software for my disposal - to process the data exported from Home Assistant. I will simply dedicate a separate old notebook for Home Assistant, to make this HA environment as stable as possible.
Another question, please. In Your opinion, which integration – Tuya or Sonoff – is better for such purposes like switching on various home appliances when the energy from PV is enough to supply them?
After I configure my HA FoxESS integration with Sonoff Wifi od Tuya switches and keep running it for some time, I let you know how stable all this construct actually is.
Thank you kindly for all your help till now.
From: STEFANEK STEFANEK ***@***.***>
Sent: Saturday, June 8, 2024 8:37 PM
To: 'macxq/foxess-ha' ***@***.***>; 'macxq/foxess-ha' ***@***.***>
Cc: 'Comment' ***@***.***>
Subject: RE: [macxq/foxess-ha] Support for T series (Discussion #77)
Importance: High
Thank you kindly, for the updated code (I installed it and I’ll be testing it for some time, I let you know my oservations) and for Your advice concerning HA platforms. I will probably go for the low form PC version.
From: Dave Foster ***@***.***>
Sent: Saturday, June 8, 2024 2:32 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Yes that's possible, the Sonoff devices when installed and configured in HA can be turned in an automation using the service 'Switch: Turn On' with the entity name of the sonoff device set (usually something like 'switch.mysonoff_device'
The sensor for combined PV power will be named something like sensor.foxess_pv_power - in an automation you can add a test for an entity being above or below a certain value.
On the hardware, there are quite a few options for this - I use a Raspberry Pi with SSD attached which is low cost, low power and will run 24/7 without interaction, others use ultra low form factor pc's i've linked you to my colleagues page as he has documented what he uses here (url) <https://github.com/TonyM1958/HA-FoxESS-Modbus/wiki/Installing-Home-Assistant-on-a-USFF-PC>
Which option you choose largely depends on your familiarity with the type of equipment and your IT skills, home assistant is a very addictive 'rabbit hole'
I have released 'beta3' which fixes that startup issue - if you follow the same instructions, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b3
Please note the OpenAPI is at it's slowest during the afternoon and early eveneing, so you may find when you restart it takes a few minutes before your sensors get populated.
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMWIHL5YBZLW5EHSUCLZGL2VVAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJTGI4DK> .
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
ok thanks, will do. On the integrations, i've used Tuya and Sonoff - If your device isn't supported getting Tuya to work is really difficult, whereas the Sonoff just works so I that is now my choice for heavier load switching (heaters, water etc..) For lighter loads i.e. switching house sockets I have a mix of TP-Link Kasa devices or Meross smart plugs - both of these work well with home assistant, integrate easily and are very reliable. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for bothering you one again. I’m stuck on some stupid error I cannot overcome. I connected LOCAL TUYA with 5 TUYA WiFi Switches (4 sockets and 1 mini DIY first to TUYA and then to HA, manually all works perfectly – from HA, TUYA Smart App on Android phone and also from TUYA CLOUD DEVELOPER. I’m trying to create a working HA automation: when FoxESS generated power exceed X, the all the TUYA devices have to be switched on, when power generated drops below Y, ale they shall be switched off. I used all the proper device instances of FoxESS and Tuya, automation created, but it cannot work properly – switches are not activated except manual option. Where is my error? I’m attaching 2 print screens documenting trials on to activate 2 Tuya WiFi switches when generated power is above zero. For simplicity, I haven’t defined any area nor time limits for this activation
From: STEFANEK STEFANEK ***@***.***>
Sent: Saturday, June 8, 2024 8:37 PM
To: 'macxq/foxess-ha' ***@***.***>; 'macxq/foxess-ha' ***@***.***>
Cc: 'Comment' ***@***.***>
Subject: RE: [macxq/foxess-ha] Support for T series (Discussion #77)
Importance: High
Thank you kindly, for the updated code (I installed it and I’ll be testing it for some time, I let you know my oservations) and for Your advice concerning HA platforms. I will probably go for the low form PC version.
From: Dave Foster ***@***.***>
Sent: Saturday, June 8, 2024 2:32 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Comment ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Yes that's possible, the Sonoff devices when installed and configured in HA can be turned in an automation using the service 'Switch: Turn On' with the entity name of the sonoff device set (usually something like 'switch.mysonoff_device'
The sensor for combined PV power will be named something like sensor.foxess_pv_power - in an automation you can add a test for an entity being above or below a certain value.
On the hardware, there are quite a few options for this - I use a Raspberry Pi with SSD attached which is low cost, low power and will run 24/7 without interaction, others use ultra low form factor pc's i've linked you to my colleagues page as he has documented what he uses here (url) <https://github.com/TonyM1958/HA-FoxESS-Modbus/wiki/Installing-Home-Assistant-on-a-USFF-PC>
Which option you choose largely depends on your familiarity with the type of equipment and your IT skills, home assistant is a very addictive 'rabbit hole'
I have released 'beta3' which fixes that startup issue - if you follow the same instructions, go to HACS, click on Integrations and then the FoxESS Cloud, click the 3 dots in the top right corner and select 're-download', make sure the 'Show beta versions' is checked and download v0.40b2 https://github.com/macxq/foxess-ha/releases/tag/v0.40b3
Please note the OpenAPI is at it's slowest during the afternoon and early eveneing, so you may find when you restart it takes a few minutes before your sensors get populated.
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMWIHL5YBZLW5EHSUCLZGL2VVAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJTGI4DK> .
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Can't see any pictures in your post and can you post the YAMLcode of your automation? |
Beta Was this translation helpful? Give feedback.
-
|
@SSSSSStefanek yes nothing to see within your message, you will need to come github and attach any images directly, or post the yaml - when you reply to an email, github just messes it up |
Beta Was this translation helpful? Give feedback.
-
|
I have managed to configure TUYA (4 WiFi sockets + 1 WiFi DIY switch) automation in my LOCAL TUYA integration in HA. The principle for WiFi switches’ activation by solar power level was very simple:
* Switch ON all devices when GENERATION POWER > X
* Switch ON all devices when GENERATION POWER < Y (Y<X)
And this didn’t work, actually it worked sporadically, mostly not worked, this was the reason I contacted you asking for some clues, as I thought the reason was some TUYA integration’s malfunction.
Then I noticed something strange on the FoxESS Cloud integration’s side in HA, and this malfunction was demonstrated mostly in peak hours:
* FoxESS Cloud API:
* If compared to the FoxESS web page diagnostics of my PV installation, updating values in HA via API was always significantly delayed, minimum 5 minutes, sometimes probably more
* Sometimes this updating in HA stopped completely and I had to restart HA trying to make it alive again
* Sometimes updating of the data pool was partial only !!! Only some data was updated, the rest of the data existing in my installation and to be reported as instructed by API had been kept for long time as unknown.
* And this was the reason my automation in LOCAL TUYA integration failed to work properly, as the GENERATION POWER reporting kept failing.
* So, I started observing again the FoxESS HA integration errors and I found a solution for my particular integration, where trigger was based on PV production:
* Although GENERATION POWER for long periods failed to be transmitted by API to my HA integration properly, another entity: SOLAR POWER was transmitted very reliably
* To my astonishment it was properly reported even when other entities were reported as unknown and installation reported as being off-line (some time before being properly reported again as being on-line).
o So, I simply changed GENERATION POWER for SOLAR POWER in my automation in the LOCAL TUYA integration as the ON/OFF trigger and since then it keeps working properly second day already. When I’m writing this to you, again the most returned values in my FoxESS Cloud integration via API are reported as unknown, inverter is reported as being on-line, but SOLAR POWER is still alive and keeps being reported properly, so my WiFi switches automation via LOCAL TUYA integration works properly.
You wrote me last time that FoxESS API is flaky, my experience with TUYA integration looks like a confirmation.
May be, despite these unfriendly traits of FoxESS API, you will find some temporary cure for it in your HA FoxESS Cloud integration code, simply to make reporting to HA more reliable, provided that in these circumstances such a cure is possible at all. May be the only solution is simply to wait for the FoxESS Cloud API stabilisation. Or go for MODBUS integration.
May be my findings will be useful for others, even as a temporary cure.
Thank you kindly again for your help till now.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks, glad that you have got it working. Yes you are correct, because of the problems with the OpenAPI, the cloud is not responding quite often at certain times of the day and when that happens the real time sensors will become 'unknown' state. I made a change recently to keep the report totals available (generation, gridconsumption, feedin, charge, discharge, loads) even when the cloud stops responding so that will be why solar power is still working as it is made up from a sum of these sensors solar power = (loads + charge + feedIn - gridConsumption - discharge) Once Fox correct the OpenAPI performance all of these problems should stop :) |
Beta Was this translation helpful? Give feedback.
-
|
Is there available any version of your code newer than kindly advised me to test last time?
Thank you also kindly for a very clever move to make the SOLAR POWER available as alive when its source data hangs in this Open API limbo. It would be a very good idea do stress it in the documentation of your code as this trait significantly better its real applications scope – probably very many of them will be similar to mine – lets go for solar when it is available above certain level.
As I’m now limited in my testing activities by the warranty given by my PV installers, I did no start testing MODBUS instead of FoxESS Cloud for such automation. My PV installers told me that any hardware messing at the inverter (like attaching MODBUS interface) will result in loosing warranty, as such attachment (even in the case of G3 inverters in which the only working mode is read-only without any possibility to execute any configuration changes) always produces traces in the inverter control logs.
Additionally, I’m not sure whether 2 interfaces (Anatel Smart WiFi for FoxESS Cloud and MODBUS for local WiFi management) can safely run in parallel at the same time.
From: Dave Foster ***@***.***>
Sent: Sunday, June 23, 2024 5:20 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Mention ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Ok, thanks, glad that you have got it working.
Yes you are correct, because of the problems with the OpenAPI, the cloud is not responding quite often at certain times of the day and when that happens the real time sensors will become 'unknown' state.
I made a change recently to keep the report totals available (generation, gridconsumption, feedin, charge, discharge, loads) even when the cloud stops responding so that will be why solar power is still working as it is made up from a sum of these sensors solar power = (loads + charge + feedIn - gridConsumption - discharge)
Once Fox correct the OpenAPI performance all of these problems should stop :)
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMXSIRGVOO6WW6ZDKS3ZI3RQFAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNJSGQ4DS> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/BBCRGMSNSUT7JEZSHQRK4FLZI3RQFA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQASZLES.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry for bothering you once again.
After experimenting with Hass Core, I set up Hass OS contained in Virtual Box under Windows 11 on my old Lenovo T430. Despite reporting some errors (which I don’t know how to correct them, see the list attached, may be you will have some clues how to fix them), my Hass OS installation is up and running. I tried to install FoxESS integration and I failed. The problems with FoxESS I encountered are as follows:
1. The list of proposed integrations is very limited if compared to Hass Core:
a. No instructions, how to set up FoxESS integration and other missing if compared to Hass Core:
i. Manual installation of this integration is excluded, as there is no direct files access to the Virtual Box’s container hosting the Hass OS and all its data
* In Virtual Box I get 2 widnows; HOST FILE SYSTEM and GUEST FILE SYSTEM
* But both these windows are empty and all associated controls greyed out
ii. So, there is now way to import external partial backups from files, except 1 single chance when the system Is installed:
* I didn’t do this as messing up with foreign backups at the Hass OS’s start and its system’s configuration is probably not a good idea
a. There is TUYA, but not LOCAL TUYA
b. No SONOF nor EWELINK integration
1. Add-ons cannot be installed:
a. I get the error message: “AddonManager.Installl” blocked from execution, no host internet connection
b. Actually, internet connection is alive, despite this message
List of install errors:
3. Install errors:
4. Timed out waiting for device /dev/virtio-ports/org.qemu.quest-agent
5. Dependency failed for QEMU Guest Agent
6. Failed to start Wait Until Kernel Time Synchronised
May be you would be able to help me to start with FoxESS integration on Hass OS.
|
Beta Was this translation helpful? Give feedback.
-
|
I keep testing it in HA Core environment. It is pretty stable. Except situations when WiFi internet connection is temporarily down for some time. Then it fails to connect to integrations again. The only way is to close terminal and internet browser windows and restart the hass application from disk, then all the connections to integrations start correctly, my Tuya and EweLink plugs and switches are seen again. Is there any way to reconnect integrations automatically, when internet connection is back? Without such an automatic restart / reconnect of integrations, it is practically impossible to rely in any serious application on automations based on these integrations (like switching various home appliances given certain status of PV).
May be you would be able to find some cure.
From: Dave Foster ***@***.***>
Sent: Sunday, June 23, 2024 5:20 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Mention ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
Ok, thanks, glad that you have got it working.
Yes you are correct, because of the problems with the OpenAPI, the cloud is not responding quite often at certain times of the day and when that happens the real time sensors will become 'unknown' state.
I made a change recently to keep the report totals available (generation, gridconsumption, feedin, charge, discharge, loads) even when the cloud stops responding so that will be why solar power is still working as it is made up from a sum of these sensors solar power = (loads + charge + feedIn - gridConsumption - discharge)
Once Fox correct the OpenAPI performance all of these problems should stop :)
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMXSIRGVOO6WW6ZDKS3ZI3RQFAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNJSGQ4DS> .
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
In a normal HA session you can reboot or restart HA in an automation, so it's possible to have a condition that checks for the Tuya being unavailable for x minutes and then call a supervisor reboot, or request a core restart. The yaml code looks like this, but if you add an action and enter start to type 'host' you'll see the 'reboot' option. If instead you start to type 'restart' you'll see the option for an HA core restart. HA Core restart HA Supervisor restart |
Beta Was this translation helpful? Give feedback.
-
|
I followed your kind advice, using HA Core, a made and automation restarting HA Core when Tuya Smart Plug changes state from ANY to NONAVAILABLE. Results are as follows:
1. When Tuya integrations are active and I disable the internet connection:
a. This automation restarts HA
b. When I reconnect the internet quickly enogh, Tuya is active again, visible
c. When I wait long enough, a couple of minutes, and then I reconnect the internet:
i. Tuya is non-active again, its controls in the integration are greyed out.
ii. The only way to make them active again I to close the terminal and web windows and restart HA from command line again.
2. I cannot find any useful automation to overcome this issue.
From: Dave Foster ***@***.***>
Sent: Saturday, July 20, 2024 12:34 PM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Mention ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
In a normal HA session you can reboot or restart HA in an automation, so it's possible to have a condition that checks for the Tuya being unavailable for x minutes and then call a supervisor reboot, or request a core restart.
The yaml code looks like this, but if you add an action and enter start to type 'host' you'll see the 'reboot' option. If instead you start to type 'restart' you'll see the option for an HA core restart.
HA Core restart
service: homeassistant.restart
data: {}
HA Supervisor restart
service: hassio.host_reboot
data: {}
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMXTVZTVBMNH2LAB5NLZNI4ILAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJQGE3TOMI> .
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
If it's just Tuya that is failing to re-connect, you could try adding an action |
Beta Was this translation helpful? Give feedback.
-
|
OK, but the major problem for longer internet connection interrupts is the trigger, as HA restart produces Tuya devices still UNVAILABLE, even when I restart manually from developer / programmer menu. When the Tuya device becomes once UNVAILABLE, there is no available trigger to reload any config or restart HA except doing it manually. I tried the trigger: from UNVAILABLE to UNVAILABLE wait for 2 minutes, but it did not work.
From: Dave Foster ***@***.***>
Sent: Sunday, July 21, 2024 10:02 AM
To: macxq/foxess-ha ***@***.***>
Cc: SSSSSStefanek ***@***.***>; Mention ***@***.***>
Subject: Re: [macxq/foxess-ha] Support for T series (Discussion #77)
If it's just Tuya that is failing to re-connect, you could try adding an action homeassistant.reload_config_entry and add the devices you have for Tuya - that is the equivalent of doing an integration 'reload'
—
Reply to this email directly, view it on GitHub <#77 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBCRGMQDGZGBD5VEH7RCMRDZNNTIPAVCNFSM6AAAAABI53BTJOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJQGU3DOMA> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/BBCRGMSVX4KZXYUVWO235QTZNNTIPA5CNFSM6AAAAABI53BTJOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQATIZUM.gif> Message ID: ***@***.*** ***@***.***> >
|
Beta Was this translation helpful? Give feedback.
-
|
Ok there is a way to do this - In the automation for the 'when' clause use the 'Time Pattern' and set the Minutes to /10 That will fire the automation every 10 minutes and then check the conditions. In the Condition section add a condition for your Tuya entity state being 'Unavailable' for 5 Minutes If that passes it will then move down to action, add an action to reload the config etc.. |
Beta Was this translation helpful? Give feedback.
-
Does is support T series ? I plugged it in but most main entities like Grid Consumption, FeedIn or Solar doesn't return any value.
I see these errors
Beta Was this translation helpful? Give feedback.
All reactions