GW5000L-DT Platform goodwe not ready yet: Unable to connect to the inverter at host

Still not working for me. GW5000L-DT
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:268
Integration: Sensor (documentation, issues)
First occurred: 2:34:34 PM (1 occurrences)
Last logged: 2:34:34 PM
Platform goodwe not ready yet: Unable to connect to the inverter at host=<IP_ADDRESS> port=8899, or your inverter is not supported yet. Failures=[InverterError("No valid response received to 'aa55c07f0102000241' request"), InverterError("No valid response received to 'f70388b800213ac10000' request"), InverterError("No valid response received to 'f70388b800213ac1' request"), InverterError("No valid response received to '7f03753100280409' request"), InverterError("No valid response received to 'aa55c07f0102000241' request")]; Retrying in background in 30 seconds

Does the problem still persist ?
Did you try to set the inverter_type explicitly ?

Yes i tried that now.. now my logs are saying:
Logger: homeassistant.components.sensor
Source: custom_components/goodwe/goodwe/protocol.py:104
Integration: Sensor (documentation, issues)
First occurred: 10:12:23 AM (1 occurrences)
Last logged: 10:12:23 AM
Error while setting up goodwe platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/goodwe/sensor.py", line 85, in async_setup_platform
inverter = await connect(
File "/config/custom_components/goodwe/goodwe/goodwe.py", line 41, in connect
await inverter.read_device_info()
File "/config/custom_components/goodwe/goodwe/dt.py", line 107, in read_device_info
response = await self._read_from_socket(self._READ_DEVICE_VERSION_INFO)
File "/config/custom_components/goodwe/goodwe/inverter.py", line 80, in _read_from_socket
return await command.execute(self.host, self.port, self.timeout, self.retries)
File "/config/custom_components/goodwe/goodwe/protocol.py", line 104, in execute
await on_response_received
custom_components.goodwe.goodwe.exceptions.MaxRetriesException

Hi,
I have exact same error as matda59.  I upgraded from a working setup (two versions back - not sure what version that was).
All was working well until I upgraded.
Rebooted. - same error
Added specific "NS" model of inverter. - same error
Current Config:

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
inverter_type: NS
sensor_name_prefix: GoodWe

Any ideas appreciated. . . .

Sorry for that, it's really difficult to develop without access to all these specific inverters.
Could you please update to latest version (released just a moment ago).
And then adjust the logging in HA's configuration.yaml - add or adjust logger section:
logger:
  default: warning
  logs:
    custom_components.goodwe: debug

Thanks for the quick response.
Updated and restarted, same error as above
Removed type: NS - restarted - same error above
Let me know if you need more/other details.
Thanks Again

Well, I need the log files, otherwise I'm stuck.
Setup the logger as mentioned above, restart and then check the debug log records.

Yea, sorry. . . .
So that is just the "home-assistant.log" file?
How do I get it to you without everyone seeing it - as I am not sure if it is poor privacy to just attach here . . .
Any guidance appreciated.
Thanks Again

Thanks mletenay:
Posted Home-assistant.log
2021-08-30 20:23:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-08-30 20:23:05 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up goodwe platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/goodwe/sensor.py", line 85, in async_setup_platform
inverter = await connect(
File "/config/custom_components/goodwe/goodwe/goodwe.py", line 41, in connect
await inverter.read_device_info()
File "/config/custom_components/goodwe/goodwe/dt.py", line 107, in read_device_info
response = await self._read_from_socket(self._READ_DEVICE_VERSION_INFO)
File "/config/custom_components/goodwe/goodwe/inverter.py", line 80, in _read_from_socket
return await command.execute(self.host, self.port, self.timeout, self.retries)
File "/config/custom_components/goodwe/goodwe/protocol.py", line 104, in execute
await on_response_received
custom_components.goodwe.goodwe.exceptions.MaxRetriesException
2021-08-30 20:23:06 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in new
port = val.port
File "/usr/local/lib/python3.9/urllib/parse.py", line 180, in port
raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 183, in _async_zeroconf_hass_start
await _async_register_hass_zc_service(hass, aio_zc, uuid)
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 249, in _async_register_hass_zc_service
params["internal_url"] = get_url(hass, allow_external=False)
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 61, in get_url
return _get_internal_url(
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 138, in _get_internal_url
internal_url = yarl.URL(hass.config.internal_url)
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in new
raise ValueError(
ValueError: Invalid URL: port can't be converted to integer
2021-08-30 20:23:06 ERROR (stream_worker) [libav.mp3float] Header missing

I have also the sane error with my Goodwe 6000-DT.
Version 0.8.1 works fine, versions 0.8.2 and 0.8.3 not.

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
sensor_name_prefix: GoodWe
inverter_type: DT           # One of ET, EH, ES, EM, DT, NS, XS or None to detect inverter type automatically
include_unknown_sensors: false

2021-08-30 11:57:31 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to DT family inverter at <IP_ADDRESS>:8899
2021-08-30 11:57:31 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Connection made to address ('<IP_ADDRESS>', 8899)
2021-08-30 11:57:31 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81
2021-08-30 11:57:33 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-08-30 11:57:33 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81
2021-08-30 11:57:35 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-08-30 11:57:35 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81
2021-08-30 11:57:37 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #4 of 3
2021-08-30 11:57:37 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81
2021-08-30 11:57:39 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-08-30 11:57:39 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up goodwe platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/goodwe/sensor.py", line 85, in async_setup_platform
inverter = await connect(
File "/config/custom_components/goodwe/goodwe/goodwe.py", line 41, in connect
await inverter.read_device_info()
File "/config/custom_components/goodwe/goodwe/dt.py", line 107, in read_device_info
response = await self._read_from_socket(self._READ_DEVICE_VERSION_INFO)
File "/config/custom_components/goodwe/goodwe/inverter.py", line 80, in _read_from_socket
return await command.execute(self.host, self.port, self.timeout, self.retries)
File "/config/custom_components/goodwe/goodwe/protocol.py", line 104, in execute
await on_response_received
custom_components.goodwe.goodwe.exceptions.MaxRetriesException

Thanks, I probably see where's the problem, the DT inverters have default address 7F and not F7 and it got messed up during recent code improvements.
The fix will be there today ...

OK, version 0.8.4 with fixed DT/D-NS/XS communication was just released.
Please update and sorry for the inconvenience.

Hi again, still not working...
sensor:

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
inverter_type: DT
sensor_name_prefix: GoodWe
include_unknown_sensors: false

2021-08-30 21:57:01 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-08-30 21:57:01 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up goodwe platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/goodwe/sensor.py", line 85, in async_setup_platform
inverter = await connect(
File "/config/custom_components/goodwe/goodwe/goodwe.py", line 41, in connect
await inverter.read_device_info()
File "/config/custom_components/goodwe/goodwe/dt.py", line 106, in read_device_info
response = await self._read_from_socket(self._READ_DEVICE_VERSION_INFO)
File "/config/custom_components/goodwe/goodwe/inverter.py", line 80, in _read_from_socket
return await command.execute(self.host, self.port, self.timeout, self.retries)
File "/config/custom_components/goodwe/goodwe/protocol.py", line 103, in execute
await on_response_received
custom_components.goodwe.goodwe.exceptions.MaxRetriesException
2021-08-30 21:57:01 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in new
port = val.port
File "/usr/local/lib/python3.9/urllib/parse.py", line 180, in port
raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 183, in _async_zeroconf_hass_start
await _async_register_hass_zc_service(hass, aio_zc, uuid)
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 249, in _async_register_hass_zc_service
params["internal_url"] = get_url(hass, allow_external=False)
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 61, in get_url
return _get_internal_url(
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 138, in _get_internal_url
internal_url = yarl.URL(hass.config.internal_url)
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in new
raise ValueError(
ValueError: Invalid URL: port can't be converted to integer
2021-08-30 21:57:02 ERROR (stream_worker) [libav.mp3float] Header missing

I need the debug log output, especially those
DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81
lines and their logged responses (if any).

OK, version 0.8.4 with fixed DT/D-NS/XS communication was just released.
Please update and sorry for the inconvenience.

It works again.
Thanks voor your fast respons and great work!

Hi Mletenay,
here is the output from home-assistant.log:
2021-08-31 08:44:51 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to DT family inverter at <IP_ADDRESS>:8899
2021-08-31 08:44:51 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Connection made to address ('<IP_ADDRESS>', 8899)
2021-08-31 08:44:51 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409
2021-08-31 08:44:53 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-08-31 08:44:53 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409
2021-08-31 08:44:54 ERROR (MainThread) [homeassistant.components.automation] Blueprint Low battery level detection & notification for all battery sensors generated invalid automation with inputs OrderedDict([('day', 7), ('actions', ["message: 'Low battery warning for: {{sensors}}'"]), ('threshold', 90)]): expected dictionary @ data['action'][0]['default'][0]. Got None
2021-08-31 08:44:55 WARNING (MainThread) [homeassistant.components.webhook] Received message for unregistered webhook 740667d35625c8b1531feba566a42dd071a542606ae47c4890404fd035f65d46 from <IP_ADDRESS>
2021-08-31 08:44:55 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-08-31 08:44:55 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409
2021-08-31 08:44:57 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #4 of 3
2021-08-31 08:44:57 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409
2021-08-31 08:44:59 WARNING (MainThread) [homeassistant.config_entries] Config entry 'broadcom IR receiver' for broadlink integration not ready yet: [Errno -4000] Network timeout; Retrying in background
2021-08-31 08:44:59 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-08-31 08:44:59 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up goodwe platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/goodwe/sensor.py", line 85, in async_setup_platform
inverter = await connect(
File "/config/custom_components/goodwe/goodwe/goodwe.py", line 41, in connect
await inverter.read_device_info()
File "/config/custom_components/goodwe/goodwe/dt.py", line 106, in read_device_info
response = await self._read_from_socket(self._READ_DEVICE_VERSION_INFO)
File "/config/custom_components/goodwe/goodwe/inverter.py", line 80, in _read_from_socket
return await command.execute(self.host, self.port, self.timeout, self.retries)
File "/config/custom_components/goodwe/goodwe/protocol.py", line 103, in execute
await on_response_received
custom_components.goodwe.goodwe.exceptions.MaxRetriesException
2021-08-31 08:45:01 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in new
port = val.port
File "/usr/local/lib/python3.9/urllib/parse.py", line 180, in port
raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 183, in _async_zeroconf_hass_start
await _async_register_hass_zc_service(hass, aio_zc, uuid)
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 249, in _async_register_hass_zc_service
params["internal_url"] = get_url(hass, allow_external=False)
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 61, in get_url
return _get_internal_url(
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 138, in _get_internal_url
internal_url = yarl.URL(hass.config.internal_url)
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in new
raise ValueError(
ValueError: Invalid URL: port can't be converted to integer

It seems you don't receive any response even to initial "_READ_DEVICE_VERSION_INFO" request.
So either L-DT is different from DT or just your inverter is configured differently ?
Are you able to connect to the inverter via the mobile app ?

My GW5000D-NS is still giving the same error.
Which mobile app should we test with, Good we SEMS Portal?
Thanks Again

PvMaster or SolarGo.
(Sems app load data from the cloud and does not connect to inverter directly.)

The best would be if you can sniff the packet traffic.
If not, than somewhere (Advanced settings ?) should be communication address of the inverter, usually someting like 247 or 127.
That's what we need to check/confirm.

I think it is 247. Found it under RS485 Setting.
Thanks Again

So it seems (some) DT inverters use 127 and some D-NS use 247.
Coincidentally I just yesterday adjusted the code to have the address configurable.
When I'll release new version, there will be optional parameter comm_address, you'll need to set that to 247 then.

I've just release v0.8.6 where the comm_address parameter is exposed.
Try to set inverter_type to DT and comm_address to 247 to see if helps.

Thanks mletenay -
Todays error:
sensor:

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
inverter_type: DT
comm_address: 247
sensor_name_prefix: GoodWe
include_unknown_sensors: false

2021-09-03 09:03:02 WARNING (SyncWorker_0) [homeassistant.util.yaml.loader] YAML file /config/configuration.yaml contains duplicate key "logger". Check lines 109 and 118
2021-09-03 09:03:02 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-03 09:03:02 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration sonoff which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-03 09:03:02 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration goodwe which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-03 09:03:03 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to DT family inverter at <IP_ADDRESS>:8899
2021-09-03 09:03:03 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:05 ERROR (MainThread) [homeassistant.components.automation] Blueprint Low battery level detection & notification for all battery sensors generated invalid automation with inputs OrderedDict([('day', 7), ('actions', ["message: 'Low battery warning for: {{sensors}}'"]), ('threshold', 90)]): expected dictionary @ data['action'][0]['default'][0]. Got None
2021-09-03 09:03:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-03 09:03:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:05 WARNING (MainThread) [homeassistant.components.webhook] Received message for unregistered webhook 991501efdb0f407b356f98bb7acb086ce43161ec5bcb3f04eb9da6d44160f127 from <IP_ADDRESS>
2021-09-03 09:03:07 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-03 09:03:07 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:09 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-03 09:03:09 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:09 WARNING (MainThread) [homeassistant.config_entries] Config entry 'broadcom IR receiver' for broadlink integration not ready yet: [Errno -4000] Network timeout; Retrying in background
2021-09-03 09:03:11 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-03 09:03:11 WARNING (MainThread) [homeassistant.components.sensor] Platform goodwe not ready yet; Retrying in background in 30 seconds
2021-09-03 09:03:11 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in new
port = val.port
File "/usr/local/lib/python3.9/urllib/parse.py", line 180, in port
raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 183, in _async_zeroconf_hass_start
await _async_register_hass_zc_service(hass, aio_zc, uuid)
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 249, in _async_register_hass_zc_service
params["internal_url"] = get_url(hass, allow_external=False)
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 61, in get_url
return _get_internal_url(
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 138, in _get_internal_url
internal_url = yarl.URL(hass.config.internal_url)
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in new
raise ValueError(
ValueError: Invalid URL: port can't be converted to integer
2021-09-03 09:03:11 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to DT family inverter at <IP_ADDRESS>:8899
2021-09-03 09:03:11 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:12 ERROR (stream_worker) [libav.mp3float] Header missing
2021-09-03 09:03:12 ERROR (stream_worker) [libav.mp3float] Header missing
2021-09-03 09:03:13 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-03 09:03:13 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:15 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-03 09:03:15 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:17 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-03 09:03:17 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-03 09:03:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-03 09:03:54 ERROR (stream_worker) [homeassistant.components.stream.worker] Error demuxing stream:
2021-09-03 09:04:04 ERROR (stream_worker) [libav.mp3float] Header missing

Hmm, it still does not respond to initial request.
Just to make it clear - @matda59 it was actually never working yet, @RatMondeo you had it working at one point in time and now it stopped, right ?

Yes, that is the case.

@RatMondeo Are you able to checkout the sources and run them in python ?

Sorry, pretty sure that is beyond me .. .. .

That is correct. It has never worked.. I can do whatever UAT you request

@matda59 Can you connect to inverter via the SolarGo or PvMaster mobile app ?

@RatMondeo I'm sorry but I can't figure out why it no longer works for you.
Can you increase the log level of the plugin and test it without setting explicit inverter_type and test it with both 247 and 127 versions of comm_address ?

Sounds like a plan.  I will check tomorrow when the sun is up......
Thanks

@RatMondeo I'm sorry but I can't figure out why it no longer works for you.
Can you increase the log level of the plugin and test it without setting explicit inverter_type and test it with both 247 and 127 versions of comm_address ?

This got it . . . .  It worked as soon as i removed the inverter type setting.   I continued to use the 247 inverter type setting and it works fine.
Thanks for working thought this with me.
Let me know if you need any additional info to assist with debugging this if I can help, I will . . . ..

Can you post the debug log ?
It would be helpful to see what inverter family the discovery method selected and why.

Hi,
Hope this helps,
Debug:
2021-09-06 06:56:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f0375940049d5c2 to ('<IP_ADDRESS>', 8899)
2021-09-06 06:56:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Received: aa557f039215090606380108c400000b660000ffffffffffffffffffffffffffffffffffffffffffff0965ffffffff0000ffffffff1385ffffffff000000000000000000000000ffffffffffffffffffffffffffffffff000effffffff000000002271000003bb00490000ffff0000ffff0000ffff0000ffffffffffffffffffff09600b65ffffffffffff0190ffffffffffff01940054e213
Serial: 55000DSN212W####
ES: test
2021-09-06 07:02:32 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to ES family inverter at <IP_ADDRESS>:8899
2021-09-06 07:02:32 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-06 07:02:34 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-06 07:02:34 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-06 07:02:36 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-06 07:02:36 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-06 07:02:38 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3

Thanks, it helps.

@RatMondeo Just one more more feedback please.
Can you post the logs with and without the explicit NS inverter_type config ?
(You can strip the responses after some 10th character to not expose serial).
I still need to figure out where's the problem.

Let me know if this is what you were after . . . .
Without NS:

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
comm_address: 247
network_timeout: 2
network_retries: 3
scan_interval: 30

inverter_type: ??
sensor_name_prefix: GoodWe

Debug:
2021-09-06 08:33:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f0375940049d5c2 to ('<IP_ADDRESS>', 8899)
2021-09-06 08:33:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Received: aa557f039215090608211c084c003a0ae0000bffffffffffffffffffffffffffffffffffffffffffff0971ffffffff003cffffffff1385ffffffff000005840001000000000000ffffffffffffffffffffffffffffffff0065ffffffff000800002279000003bd00490000ffff0000ffff0000ffff0000ffffffffffffffffffff09600e80ffffffffffff0190ffffffffffff019400540259
With NS:

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
comm_address: 247
network_timeout: 2
network_retries: 3
scan_interval: 30
inverter_type: NS
sensor_name_prefix: GoodWe

2021-09-06 08:38:20 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Connecting to NS family inverter at <IP_ADDRESS>:8899
2021-09-06 08:38:20 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-06 08:38:22 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-06 08:38:22 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-06 08:38:24 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-06 08:38:24 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-06 08:38:26 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-06 08:38:26 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('<IP_ADDRESS>', 8899)
2021-09-06 08:38:28 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket

Isn't there a request f703753100281a81 when NS is explicitly specified ?

Oh, I finally see some difference, when NS is NOT specified as inverter, it ignores the comm_address and goes to 0x7f (which is weirdly correct). When it IS explicitly specified, the comm_address is properly taken into account (and does not work).
So SolarGo is misleading with the 247 address.
Re-test it without the comm_address parameter please, again with both NS scenarios.
(It's a pain to develop this wait without direct access to hw ....)

Hope this helps  . .
Now working in  both NS scenarios
Also, Updated to v0.8.9

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
inverter_type: NS
sensor_name_prefix: GoodWe

2021-09-06 09:08:39 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f0375940049d5c2 to ('<IP_ADDRESS>', 8899)
2021-09-06 09:08:39 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Received: aa557f0392150906090814084600350b430011ffffffffffffffffffffffffffffffffffffffffffff0971ffffffff0040ffffffff1385ffffffff0000070f0001000000000000ffffffffffffffffffffffffffffffff0094ffffffff001000002281000003bd00490000ffff0000ffff0000ffff0000ffffffffffffffffffff09600e80ffffffffffff0190ffffffffffff01940054ef3e

platform: goodwe
ip_address: <IP_ADDRESS>
port: 8899
network_timeout: 2
network_retries: 3
scan_interval: 30
sensor_name_prefix: GoodWe

2021-09-06 09:13:41 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f0375940049d5c2 to ('<IP_ADDRESS>', 8899)
2021-09-06 09:13:41 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Received: aa557f0392150906090d17084500410b070015ffffffffffffffffffffffffffffffffffffffffffff0964ffffffff004effffffff1387ffffffff0000075b0001000000000000ffffffffffffffffffffffffffffffff009fffffffff001100002282000003be00490000ffff0000ffff0000ffff0000ffffffffffffffffffff09600e7cffffffffffff0190ffffffffffff0194005469d5

@matda59 Can you update to latest version, remove all optional parameters (leave only ip_address there) and try again ?
Can you even connect to the inverter via SolarGo or PvMaster mobile app ?

hiya,
log output after only having these lines in the config yaml
sensor:

platform: goodwe
ip_address: <IP_ADDRESS>

2021-09-07 11:03:56 WARNING (SyncWorker_0) [homeassistant.util.yaml.loader] YAML file /config/configuration.yaml contains duplicate key "logger". Check lines 101 and 110
2021-09-07 11:03:56 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration goodwe which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-07 11:03:56 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-07 11:03:56 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration sonoff which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-09-07 11:03:57 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing inverter at <IP_ADDRESS>:8899
2021-09-07 11:03:57 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:03:59 ERROR (MainThread) [homeassistant.components.automation] Blueprint Low battery level detection & notification for all battery sensors generated invalid automation with inputs OrderedDict([('day', 7), ('actions', ["message: 'Low battery warning for: {{sensors}}'"]), ('threshold', 90)]): expected dictionary @ data['action'][0]['default'][0]. Got None
2021-09-07 11:03:59 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:03:59 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:01 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:01 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:03 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:03 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:04 WARNING (MainThread) [homeassistant.config_entries] Config entry 'broadcom IR receiver' for broadlink integration not ready yet: [Errno -4000] Network timeout; Retrying in background
2021-09-07 11:04:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing EH inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:05 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:07 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform goodwe is taking over 10 seconds.
2021-09-07 11:04:07 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:07 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:09 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:09 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:11 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:11 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:13 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:13 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ET inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:13 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:15 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:15 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:17 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:17 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:21 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:21 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing DT inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:21 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:23 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:23 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:25 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:25 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:27 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:27 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:29 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:29 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ES inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:29 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:31 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:31 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:33 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:33 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:35 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:35 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:37 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:37 WARNING (MainThread) [homeassistant.components.sensor] Platform goodwe not ready yet: Unable to connect to the inverter at host=<IP_ADDRESS> port=8899, or your inverter is not supported yet.
Failures=[MaxRetriesException(), MaxRetriesException(), MaxRetriesException(), MaxRetriesException(), MaxRetriesException()]; Retrying in background in 30 seconds
2021-09-07 11:04:40 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in new
port = val.port
File "/usr/local/lib/python3.9/urllib/parse.py", line 180, in port
raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 183, in _async_zeroconf_hass_start
await _async_register_hass_zc_service(hass, aio_zc, uuid)
File "/usr/src/homeassistant/homeassistant/components/zeroconf/init.py", line 249, in _async_register_hass_zc_service
params["internal_url"] = get_url(hass, allow_external=False)
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 61, in get_url
return _get_internal_url(
File "/usr/src/homeassistant/homeassistant/helpers/network.py", line 138, in _get_internal_url
internal_url = yarl.URL(hass.config.internal_url)
File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in new
raise ValueError(
ValueError: Invalid URL: port can't be converted to integer
2021-09-07 11:04:40 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:40 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:40 ERROR (stream_worker) [libav.mp3float] Header missing
2021-09-07 11:04:40 ERROR (stream_worker) [libav.mp3float] Header missing
2021-09-07 11:04:42 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:42 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:44 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:44 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:48 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:48 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing EH inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:48 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:50 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform goodwe is taking over 10 seconds.
2021-09-07 11:04:50 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:50 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:52 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:04:52 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:54 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:04:54 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:56 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:04:56 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ET inverter at <IP_ADDRESS>:8899
2021-09-07 11:04:56 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:04:58 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:04:58 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:00 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:05:00 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:02 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:05:02 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:04 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:05:04 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing DT inverter at <IP_ADDRESS>:8899
2021-09-07 11:05:04 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:06 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:05:06 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:08 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:05:08 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:10 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:05:10 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:12 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:05:12 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ES inverter at <IP_ADDRESS>:8899
2021-09-07 11:05:12 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:14 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:05:14 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:16 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:05:16 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:18 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:05:18 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:05:20 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:06:20 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing inverter at <IP_ADDRESS>:8899
2021-09-07 11:06:20 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:22 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:06:22 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:24 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:06:24 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:26 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:06:26 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:28 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:06:28 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing EH inverter at <IP_ADDRESS>:8899
2021-09-07 11:06:28 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:30 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform goodwe is taking over 10 seconds.
2021-09-07 11:06:30 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:06:30 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:32 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:06:32 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:34 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:06:34 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:36 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:06:36 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ET inverter at <IP_ADDRESS>:8899
2021-09-07 11:06:36 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:38 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:06:38 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:40 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:06:40 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:42 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:06:42 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f70388b800213ac1 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:44 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:06:44 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing DT inverter at <IP_ADDRESS>:8899
2021-09-07 11:06:44 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:06:46 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:48 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-07 11:06:48 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:50 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-07 11:06:50 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: 7f03753100280409 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:52 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
2021-09-07 11:06:52 DEBUG (MainThread) [custom_components.goodwe.goodwe.goodwe] Probing ES inverter at <IP_ADDRESS>:8899
2021-09-07 11:06:52 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)
2021-09-07 11:06:54 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-07 11:06:54 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: aa55c07f0102000241 to ('<IP_ADDRESS>', 8899)

Ok, it does not respond to anything, or it was configured with non-standard communication address.
(And from the logs I see you're not updated to latest version yet, but that shouldn't be a cause).
Can you connect the inverter via SolarGo or PvMaster mobile app ? Can you look at advanced settings there to see to the comm_address ?

Hi,
I have a GW5000D-NS but cannot seem to get it the component working. Firmware on inverter recently updated, not working on previous firmware or new firmware.
I've tried using settings that @RatMondeo has used/tested in this post, but still not working
Inverter responds to broadcast on 48899, but never responds to any other messages
Any ideas?

@dphroon First thing to check is always the mobile app SolarGo or PvMaster.
If that works, than there's hope.

No luck on either, unfortunately. Finds the device, but can't connect

Guys, be aware that if a service is flooding the udp with requests the Inverter will stop communicating with all the the devices.
E.g: when I rise the frequency of home assistant to 2hz I cannot communicate with the inverter via app/ other devices anymore, and the hass data transfer lowers to 1 success read per minute at most.

@dphroon That looks bad for you. I've seen somewhere mentioned the UDP communication is on some inverters only supported since ARM firmware 13 or so. So maybe you have latest firmware but no latest ARM (whatever it means).
Can you raise the debug level and check the log if at least the initial aa55 kind discovery request has some response ?

2021-09-08 17:20:17 DEBUG (MainThread) [custom_components.goodwe.goodwe] Connecting to NS family inverter at 192.168.X.XX:8899
2021-09-08 17:20:17 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('192.168.X.XX', 8899)
2021-09-08 17:20:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #1 of 3
2021-09-08 17:20:19 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('192.168.X.XX', 8899)
2021-09-08 17:20:21 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #2 of 3
2021-09-08 17:20:21 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('192.168.X.XX', 8899)
2021-09-08 17:20:23 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Retry #3 of 3
2021-09-08 17:20:23 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Sent: f703753100281a81 to ('192.168.X.XX', 8899)
2021-09-08 17:20:25 DEBUG (MainThread) [custom_components.goodwe.goodwe.protocol] Max number of retries (3) reached, closing socket
This is from ./inverter_scan.py
2021-09-07 17:16:58,014 init(59) - DEBUG: Using selector: EpollSelector
2021-09-07 17:16:58,014 search_inverters(116) - DEBUG: Searching inverters by broadcast to port 48899
2021-09-07 17:16:58,014 _send_request(36) - DEBUG: Sent: 574946494b49542d3231343032382d52454144 to None
2021-09-07 17:16:58,131 datagram_received(50) - DEBUG: Received: 3XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX2
Located inverter at IP: 192.168.X.XX, mac: XXXXXXXXXXXX, name: Solar-WiFiXXXXXXXX
Trying command: AA55C07F0102000241
No response to AA55C07F0102000241 command
Trying command: 7F03753100280409
No response to 7F03753100280409 command
Trying command: 197d0001000dff045e50303036564657f6e60d
No response to 197d0001000dff045e50303036564657f6e60d command
Trying command: 680241b132303757313234320100ae16
No response to 680241b132303757313234320100ae16 command
Trying command: 680241b132343231573730320100ae16
No response to 680241b132343231573730320100ae16 command
Identifying inverter at IP: 192.168.X.XX
2021-09-07 17:16:58,133 init(59) - DEBUG: Using selector: EpollSelector
2021-09-07 17:16:58,133 discover(67) - DEBUG: Probing inverter at 192.168.X.XX
2021-09-07 17:16:58,134 _send_request(36) - DEBUG: Sent: aa55c07f0102000241 to ('192.168.X.XX', 8899)
^C2021-09-07 17:17:01,992 discover(97) - DEBUG: Probing ET inverter at 192.168.X.XX
2021-09-07 17:17:01,992 _send_request(36) - DEBUG: Sent: f70388b800213ac1 to ('192.168.X.XX', 8899)
^CTraceback (most recent call last):
It appears to hang at this point (or I'm not patient enough).
I tried a couple of different config options today - both produced exactly the same log. I'll run a few tomorrow and list config with log results

@dphroon Keep trying, I'm glad to help as soon you get any kind of answer from inverter.
But to improve your mood in case you will not succeed, look here #65 - there may be a way via the TCP gateway.
(Once we actually implement it ;-)

@dphroon Read this issue https://github.com/jantenhove/GoodWeLogger/issues/28. It is about XS inverters, but should apply also to DT. At the end of the thread they mention arm firmware updates ...

@mletenay thanks!
Sometimes it just takes one person (in that post you linked) to phrase it correctly... ARM-Firmware
Previously, I had already found that download, held my breath and updated the firmware myself, but to no avail. The firmware in that download for the GW5000D-NS is too old.
I had raised a service request with GoodWe to do an OTA inverter firmware update, which they most pleasantly did, but to no avail.
It turns out to be so easy. Raise a service request with GoodWe to do an OTA ARM-firmware update. Just like that. 10 minutes later, and everything works!

Glad to hear that !
I'll adjust the README to add this hint for people with troubles like you ...
@matda59 You should probably do the same - ask for ARM firmware update.

thanks for this, i tried to raise a service request, but the online form refuses to move forward with a "Unable to process your request" error that drops down. That's brilliant can't raise a support ticket. i sent them an email. let's see.

This isn't in the readme yet! I'm having the same issue, have just requested a an ota arm upgrade and firmware from goodwe, will report back


chore(benchmark): fix generation

So we need to provide FORCE_NAPI=true while running generateInFolder?

Yep but it's PRISMA_FORCE_NAPI=true


Fix crash in silver-bun

Closes #678
Marking as draft until I can get some confirmation of the fix.

seems to work now


remove any style links we are processing

With this path I'm removing any style links prevailer-rails is already processing. This addresses #48.

BTW, we've been running with this patch in production for quite a while now...

I'm a bit outdated on the code. Maybe you can help me a bit here :blush: Can you explain to me why this is needed? Is it to prevent a further process of the stylesheet by premailer? Are there other reasons for doing this?

Sure. Without removing the stylesheet from the header, premailer will fetch the stylesheet once more. It seems there is an option to not have premailer load the stylesheet, but that isn't enabled by default. And previously I don't think that option was available. Anyway, removing the header seemed the easiest and cleanest way to just make sure that premailer will just use the styles already loaded by premailer-rails.

thanks! You can close https://github.com/fphilipe/premailer-rails/issues/48 now as well.

@mreinsch Thank you!


Fix exit code on BSD/Mac

Continuing the conversation from 3f5325a613435b9ac478a9bfc4b002537d5e5084...
Currently on master, the exit code for EXECUTE - AND STORE EXIT CODE IN is always 0. I did some digging and it looks like BSD has a different WEXITSTATUS() macro than Linux:

OpenBSD's implementation of WEXITSTATUS uses the address-of operator (unary &) on its argument, effectively requiring that its argument have storage. You are calling it with the return value of a function, which doesn't have storage, so the compiler complains. - https://stackoverflow.com/a/13674801

Here's BSD/Mac's:
https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/sys/wait.h#L144
Which uses the _W_INT macro:
https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/sys/wait.h#L128
And glibc's, which doesn't:
https://github.com/bminor/glibc/blob/7628a1b05adb1e4c6857b87c6f8b71a1d0b1d72c/posix/sys/wait.h#L54
https://github.com/bminor/glibc/blob/7628a1b05adb1e4c6857b87c6f8b71a1d0b1d72c/bits/waitstatus.h#L28
I tried a few things but I suspect the most portable would just be to overwrite _W_INT if it exists to do what we want. Sounds like only really old code expects wait() to return a union on BSDs, anyway.
I also added the explicit (int) cast which my Linux machines needed, for some reason.

It seems that this is failing in Travis (and thus it may fail under some OSs). This is quite the conundrum. Maybe we should implement our own WEXITSTATUS?

I tried a few things but I suspect the most portable would just be to overwrite _W_INT if it exists to do what we want. Sounds like only really old code expects wait() to return a union on BSDs, anyway.

I agree with this.
I've been doing some research and it seems that the value system() returns is very implementation dependant. Maybe we should just save if it is 0 or non-0?

It seems that this is failing in Travis (and thus it may fail under some OSs)

I only promised to fix BSD/Mac in the PR title!
My other idea was to just skip the macro and use its functionality directly, which passes the build and works on my test machines but I don't know how portable it is.

Well, your solution seems quite pragmatic, haha! I hope it works under Windows but anyway I'm merging your PR. Thank you very much for your hard work, dvkt!

My other idea was to just skip the macro and use its functionality directly, which passes the build and works on my test machines but I don't know how portable it is.

We'll see this in due time. If necessary, we can just add some platform-dependent macros (one for windows, one for BSD, one for Linux) and that will be the end of it. Until then, let's just assume it works. Thank you very much for this contribution, again! :smile:

Okay thanks! I agree with that, either adding platform macros or our own system() like how there's an exec(). In there we could do something like:
auto status = system(cmd);
int code = WEXITSTATUS(status);

And that should work everywhere, but doing that inline in ldpl.cpp was a bit tricky so I went this other route tanglin' with the macro.

You can always define a function in ldpl_lib.cpp and get away with it, haha. But anyway your solution is great and if it works that'll be the end of it. :smile:


getting blank page when calling a minified URL in Safari only

Minify version: 2.1.3
PHP version: 5.2.6

What steps will reproduce the problem?
1. Calling a minified URL in a page, ex:
<link type="text/css" rel="stylesheet" href="min/b=css&f=styles.css" />

Expected output:
Page loading correctly with minified assets

Actual output:
Blank page, 9 times out of 10

Did any unit tests FAIL? (Please do not post the full list)
!WARN: environment : Local HTTP request failed. Testing cannot continue.

Things of interest:
• Loading a minified URL directly in Safari always works. Ex. :
http://example.com/min/b=css&f=styles.css&debug=1
• Adding $min_serveOptions['maxAge'] = 0 in config.php solves the problem.
• It's working fine in Chrome.
• I'm using the default config.php
• That problem only occurs in my Mediatemple (gs) environment (I'm currently
trying to reach
them). It's working fine on my local MAMP environment but it's 48 hours since
I'm trying to find out
which PHP or Apache setting to change...

Thanks for your help!

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 16 May 2010 at 5:32

Try the FirePHP error logging
http://code.google.com/p/minify/wiki/Debugging

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 1:30

Changed state: NeedInfo

Hi,

Thx for your reply.
My problem doesn't occur in Firefox therefore I'm not sure it will help. The
only warning I get is when
launching the builder, it's saying "Warning: It appears output is being
automatically compressed, interfering
with Minify's own compression. The option "zlib.output_compression" is disabled
in your PHP configuration so
this behavior is likely due to a server option."

On the mean time, I got an answer from MT support. It seems to be a well-known
Safari (not Webkit) bug
since 4.0 regarding how it handles caching and output compression. Everything
is explained here but that
didn't help me very much.
https://bugs.webkit.org/show_bug.cgi?id=25786

But as I said, everything is working fine in Safari on my local MAMP. Any clue
about which Apache or PHP
setting could fix that?

Thanks!

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 4:52

Great. Fixed in R412

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 11:21

Changed state: Verified
Added labels: Release-2.1.3

If the compression is coming from Apache's DEFLATE filter, you could try
this .htaccess from 2.1.4
http://code.google.com/p/minify/source/browse/branches/2.1.4/min/.htaccess

If it's caused by zlib.output_compression, you can try to turn that Off via
.htaccess
or in a php.ini in the "min" directory.

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 5:26

Thanks a million time!
zlib.output_compression was already turned off but adding "SetEnv no-gzip" did
the trick!

Best,
G

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 5:37


go get github.com/containerd/nydus-snapshotter@latest refers to a non-existent version (v0.11.3)

$ go version
go version go1.21.1 linux/amd64

$ go get github.com/containerd/nydus-snapshotter@latest
go: downloading github.com/containerd/nydus-snapshotter v0.11.3
go: added github.com/containerd/nydus-snapshotter v0.11.3

This revision does not seem to exist.
The actual latest revision in https://github.com/containerd/nydus-snapshotter/tags seems v0.10.0.

cc @changweige PTAL

https://proxy.golang.org/github.com/containerd/nydus-snapshotter/@v/list
It seems to have some broken versions cached in the go module proxy.

The wrongly released versions have already been retracted from go.mod
retract (
	v0.11.3
	v0.11.2
	v0.11.1
	v0.11.0
	v0.3.0 // retagged: cd604c1b597558ea045a79c4f80a8c780909801b -> 85653575c7dafb6b06548478ee1dc61ac5905d00
)```

Wondering if it is because the version that retracts them is older than v0.11.0,
Maybe the best way forward is to tag a v0.12.0 release, so that latest is what can safely be used

I guess I should also mention that v0.11 can no longer be used as version; I see v0.10 was released recently, and v0.11 should be skipped now

@thaJeztah +1, let's do that.

Now we have the latest version https://github.com/containerd/nydus-snapshotter/releases/tag/v0.12.0
$ go get github.com/containerd/nydus-snapshotter@latest
go: downloading github.com/containerd/nydus-snapshotter v0.12.0

Thanks for the bug report cc @AkihiroSuda @thaJeztah

Thanks! I see a v0.12.0  tag was created; https://github.com/containerd/nydus-snapshotter/releases/tag/v0.12.0
🤞 hope that helps with the situation (but I think it does)

Quick check; looks like it does 👍
docker run --rm -w /foo golang:1.20 sh -c 'go mod init foo && go get github.com/containerd/nydus-snapshotter@latest'
go: creating new go.mod: module foo
go: downloading github.com/containerd/nydus-snapshotter v0.12.0
go: added github.com/containerd/nydus-snapshotter v0.12.0


Potential memory leak

The fix is a one liner:
diff --git a/openssl-1.1.1g/crypto/x509/x509_set.c b/openssl-1.1.1g/crypto/x509/x509_set.c
index 164b4e2b..4e57f506 100644
--- a/openssl-1.1.1g/crypto/x509/x509_set.c
+++ b/openssl-1.1.1g/crypto/x509/x509_set.c
@@ -208,7 +208,7 @@ static void x509_sig_info_init(X509_SIG_INFO *siginf, const X509_ALGOR *alg,
     siginf->pknid = pknid;
     if (mdnid == NID_undef) {
         /* If we have one, use a custom handler for this algorithm */
-        const EVP_PKEY_ASN1_METHOD *ameth = EVP_PKEY_asn1_find(NULL, pknid);
+        const EVP_PKEY_ASN1_METHOD *ameth = EVP_PKEY_asn1_get0(pknid);
         if (ameth == NULL || ameth->siginf_set == NULL
                 || ameth->siginf_set(siginf, alg, sig) == 0)
             return;

Let me know if you want me to open a pull request.  This was found on 1.1.1 and well as master.

YIPES!!!  This does not solve the issue I was seeing.


Automatically surround identifiers & attributes with double quotes

Changed DotCompiler to only surround identifiers and labels with double quotes when necessary.
Reasons for this change:

Makes it possible to assign default attributes to nodes, edges, etc:new DotNode("node")
{
    Label = "example"
};

// before: "node"[label="example"];
// after: node[label=example];

Output without unnecessary double quotes is less verbose

I have used the Regex pattern described here: https://graphviz.org/doc/info/lang.html
Issue: #25

This is perfect. Thanks for your contribution :)


Git clone from FAIRiCUBE GitHub to EOX Jupyter server is not working

When I try to git clone the UC2 repository from the FAIRiCUBE GitHub into a running EOX Jupyter server, it does not work because of host key verification failure.
Is there a way to make this possible?

Nevermind, I was trying using it over SSH. It works using HTTPS.

How are you trying to clone the repo? I just successfully cloned it using the terminal and also the GIT UI extentsion

Nevermind, I was trying using it over SSH. It works using HTTPS.

I see. I guess you'd need to provide your ssh key in this case.

Yes, I probably can do that from a terminal. But when in Jupyter there is no such option (at least I could not find it).

Yes, I probably can do that from a terminal. But when in Jupyter there is no such option (at least I could not find it).

You can simply open a terminal in JupyterLab and run any command like a git clone after placing your ssh key in the .ssh directory.


File type

Hi @bluedenim , as in the previous issue you have mentioned "If you set the "s3Compression" property to "true" in the log4j2 config, then the contents will be GZIPed, and the S3 key will end in ".gz" to hint that the content is compressed".
I have tried to set the compression to true, but the file is not ending with the .gz. Can you please provide more context on these , how we can set the file type. is there any release ?
And the another question how to reference the actual file that being uploaded to S3, it is just indicating with the time stamp-hostname-guid. how do we refer the actual file. Can you please provide more information on these.

how to reference the actual file that being uploaded to S3
Can you rephrase the question?

Lastly, this repo is for the example program to test/try the log4j-s3-search library. If you have questions about the library, open an issue over there.
I don't monitor this repo much. Thanks!


[Component Request] {UI-List}

Description - I'd propose a 'UI-list' component... similar to the left side list setup in the screenshot below... the only way i know of to kinda do this currently is by hacking a table or making something custom... but i might be wrong about that! (Anyone know another way to do this?)

Material Design Spec link - Nav+List+Detail, Lists

Use Case(s) - Really quick and dirty Material Design App UI prototyping with html, and probably some sort of sub-navigation or list/detail views.

Left nav is our drawer inside of layout.
We have a subset of lists for 1.1 that just needs some docs.
Not sure about expanding the existing list setup to include this myself... Doesn't seem like something that would prove beneficial to many projects. Leaving open as a feature request for more thought later.

This wouldn't be a drawer... just a navigation/UI-List. Does that make sense? I'm trying to make the hamburger button open a drawer as well...
Currently trying to make two 'left-nav drawers' to hack something like this into happening... the left nav you are referring to is on the 'components' page at getmdl.io, right?

☝🏽like that?
I want a left nav like that, but i want to have the 'hamburger' button work too, to slide out a more 'meta',  site-wide nav.
Right now, I'm having a problem with the fixed drawer always having a higher z-index than the sliding drawer, and my sliding drawer's content always gets hidden. Any Pro tips?

A) Don't copy much of our drawer code. Just write your own fixed drawer structure to keep on page.
B) Just target and makes it's z-index lower? Not sure how that is an issue.
C) Provided we are offering lists in 1.1, I'm inclined to say we don't include the extra bit internally for having a static left-nav area. That is simple enough for developers to handle on their own if needed. Not sure why we should provide it.


Improve Error Output for the profile reconcile command

Describe the bug
Currently the log output is cutted at the profile reconcile command, if the profile xml is not valid.
To Reproduce
Steps to reproduce the behavior:

Make a profile xml invalid by removing one element tag
Rune the following command
sfp profile:reconcile -u dev -f "src-access-management/profile/main/default/profiles/" --loglevel trace

Expected behavior
The error contains the related profile api name or file name and the problem element.
Screenshots
Log output:

Platform Details (please complete the following information):

OS: Mac OS 13.4.1
Version: @dxatscale/sfpowerscripts/22.5.5 darwin-arm64 node-v18.11.0
Salesforce CLI(sfdx cli) Version: sfdx-cli/7.207.5 darwin-arm64 node-v18.11.0
CI Platform: Local

Additional context
Add any other context about the problem here.
Error Message in project: sfpowerscripts/packages/sfprofiles/src/impl/source/reconcileWorker.ts:98

@ethan-sargent  Can you have a look at this one?

PR above should make this look like the following:


Split clippy-reviewdog-filter pipe to mitigate broken pipe

Sometimes (especially during on:push) Broken pipe occurs

ex: https://github.com/arkedge/c2a-tlmcmddb/issues/42 (https://github.com/arkedge/c2a-tlmcmddb/actions/runs/7523751359/job/20485143596)

The root cause of this is that SIGPIPE is ignored in Rust's default behavior

https://github.com/rust-lang/rust/pull/13158
https://github.com/rust-lang/rust/issues/46016
https://github.com/rust-lang/rust/issues/62569

Therefore, temporarily stop pipe directly & passing checkstyle XML to reviewdog via temporary file

PR to clippy-reviewdog-filter: https://github.com/qnighy/clippy-reviewdog-filter/pull/171


ShouldBeUniqueUntilProcessing job with afterCommit get persist lock on failed database transactions and unable to dispatch again

Laravel Version
10.6.2, 10.15.0
PHP Version
8.2.6
Database Driver & Version
MySQL 8.0.30; Redis 7
Description
If queue afterCommit flag is true and database transaction failed (will be rolled back), then all jobs dispatched with ShouldBeUniqueUntilProcessing interface will get a persistent lock, and you can't dispatch them again at all (because there are no any instruments to clear the locks from redis).
This happens because on transaction rollback the Job is not dispatched, but lock is already set and is not released.
So afterwards - you can't dispatch this job again, because the lock is exists.
The only possible workaround right now is to set some $uniqueFor value, so the lock will expire in some time. But this is a bit wrong behavior, when I really need ShouldBeUniqueUntilProcessing without expiration.
Similar issues were reported already without any fix:

https://github.com/laravel/framework/issues/45506 (Laravel 9)
https://github.com/laravel/framework/issues/45488 (Laravel 8)

Steps To Reproduce

Install Laravel
Set queue and cache drivers to redis
Add job like:

<?php

declare(strict_types=1);

namespace App\Tmp;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldBeUniqueUntilProcessing;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Support\Facades\Log;

class UniqueJob implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
    use Dispatchable, Queueable;

    public function handle()
    {
        Log::info('Job executed successfully.');
    }
}

Add command and register it in Kernel or ServiceProvider

<?php

declare(strict_types=1);

namespace App\Tmp;

use App\Models\User;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\DB;

class DispatchJobWithinFailedTransaction extends Command
{
    protected $signature = 'app:dispatch-job-within-failed-transaction
        {--commit : Commit transaction for success case}
        {--rollback : Rollback transaction for failure case}
        ';
    protected $description = 'Replicate bug with dispatching job within failed transaction';

    public function handle()
    {
        $this->line('Start transaction');
        DB::beginTransaction();

        $this->line('Dispatch "after commit" job with lock');
        UniqueJob::dispatch()
            ->afterCommit();

        if ($this->option('commit')) {
            $this->line('Commit transaction');
            DB::commit();
        }

        if ($this->option('rollback')) {
            $this->line('Rollback transaction');
            DB::rollBack();
        }
    }
}

run queue process with php artisan queue:work
run successful case to make sure all working fine with php artisan app:dispatch-job-within-failed-transaction --commit
you should see successful logs in laravel.log and queue job status
run negative case with php artisan app:dispatch-job-within-failed-transaction --rollback > no job has been executed, this is okay
run successful case again php artisan app:dispatch-job-within-failed-transaction --commit
BUG: job is not dispatched and is not handled, because lock is persistent here already

Let's see how your PR goes first 👍

Let's see how your PR goes first +1

As I sad, my PR failed with auto-tests, and I can't find any instruction how to configure them correctly to be the same as it does automatically. I even posted a question in Discussions, but no response on this.
Without this setup I can't complete the PR, because it requires updating existing unit tests (because of main logic of dispatching is different with my update). I fixed all issues and tested manually with my PR, but without fixing unit tests it won't be checked/merged by rules mentioned in Contributing docs

@driesvints , in case you missed the PR, it was already linked to this issue: https://github.com/laravel/framework/pull/47765.

I'm going to close this now because no new PR has been made. Feel free to try again if you want 👍


Create a Bengali (Bangla) translation of the basic web server guide

Based on the English version of the guide (https://github.com/devadvance/terminalcheatsheet/blob/staging/guides/basic-web-server-macos-linux.md), create a Bengali (Bangla) translation in https://github.com/devadvance/terminalcheatsheet/blob/staging/i18n/bn/guides/basic-web-server-macos-linux.md.
You can copy this template to use a starting point: https://github.com/devadvance/terminalcheatsheet/blob/staging/i18n/new_language_templates/guides/basic-web-server-macos-linux.md
It is OK to use the English images/GIFs. Look for TODO in the file for suggested places for translations.
Please comment on this issue before starting work so people are informed that you are working on it.

@devadvance  i can do this . please assign me


Update testing-recipes.md

Move mock restoration in Data Fetching-tests to afterEach to prevent it from polluting test environment if test was unsuccessful.

Signed cla 👍


[SPARK-40397][BUILD] Upgrade org.scalatestplus:selenium to 3.12.13

What changes were proposed in this pull request?
The main change of this pr as follows:

Upgrade org.scalatestplus:selenium from org.scalatestplus:selenium-3-141:<IP_ADDRESS> to org.scalatestplus:selenium-4-2:<IP_ADDRESS> and upgrade selenium-java from 3.141.59 to 4.2.2, htmlunit-driver from 2.62.0 to 3.62.0

okio upgrade from 1.14.0 to 1.15.0 due to both selenium-java and kubernetes-client depends on okio 1.15.0 and maven's nearby choice has also changed from 1.14.0 to 1.15.0

Why are the changes needed?
Use the same version as other org.scalatestplus series dependencies, the release notes as follows:

https://github.com/scalatest/scalatestplus-selenium/releases/tag/release-<IP_ADDRESS>-for-selenium-4.1
https://github.com/scalatest/scalatestplus-selenium/releases/tag/release-<IP_ADDRESS>-for-selenium-4.1
https://github.com/scalatest/scalatestplus-selenium/releases/tag/release-<IP_ADDRESS>-for-selenium-4.1
https://github.com/scalatest/scalatestplus-selenium/releases/tag/release-<IP_ADDRESS>-for-selenium-4.2

Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GitHub Actions

cc @sarutak FYI

thanks @HyukjinKwon

Before this change, ChromeUISeleniumSuite and ChromeUIHistoryServerSuite can run with:
build/sbt -Dguava.version=27.0-jre -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver -Dtest.default.exclude.tags="" -Phive -Phive-thriftserver 'testOnly Chrome*Suite'

After this change, they need newer version of Guava.
build/sbt -Dguava.version=31.1-jre -Dspark.test.webdriver.chrome.driver=/path/to/chromedriver -Dtest.default.exclude.tags="" -Phive -Phive-thriftserver 'testOnly Chrome*Suite'

But I think it's OK. Spark itself still depends on Guava 14.0.1.

Manual test and supplemented with pr description

Merging to master.


[Feature] Implemented Datetime object support

Implemented Datetime object
Resolves: #647
What's Changed:
I didn't removed old contracts yet, means there is no any breaking changes, confirmed with tests. Added instantiation for datetime objects, once we agreed on these contracts, other utility methods for this datetime objects can be implemented on top of it.
Type of Change:

[ ] Bug fix
[x ] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Housekeeping:

[ x] Tests have been updated to reflect the changes done within this PR (if applicable).
[ x] Documentation has been updated to reflect the changes done within this PR (if applicable).

Added methods for datetime object
Constructors

Datetime.new() -> Datetime
Datetime.new(String, String) -> Datetime
Datetime.new(Number) -> Datetime

Methods

datetimeObj.strptime() -> Number
datetimeObj.strftime(String) -> String

Looks like there is some issue in handling gmt, will fix it

Appreciate the work you've done on this so i've stuck the hacktoberfest label on it (if you're participating) until I get some time to thoroughly check it and get it merged in!

I think I'm going to work on this PR (unless you want to continue with it) so that all of the object methods return a Datetime object rather than primitive values and have extra methods on the datetime object to convert to string / numeric values.
Means as we add more methods we can much easier chain things (e.g like addHour or whatever)

Certainly, could you provide some contract ideas that I can attempt to implement ?.
Because current methods such as datetimeObj.strptime,  datetimeObj.strftime could not return Datetime object. Am I right?

Exactly yeah, we'd leave the current ones in and they can return the primitive values. Your new object methods would instead return a Datetime object, so:
Datetime.new(<values>); -> Datetime
Datetime.strptime(<string>, <string>); -> Datetime
Datetime.getTime(); -> Number
Datetime.strftime(<string>); -> String
Datetime.toString(); -> String (thinking do we need this if we have strftime actually? we could have this be strftime with no format specifier passed to it)

// Later down the line
Datetime.addMinutes(<number>); -> Datetime
Datetime.addHours(<number>); -> Datetime
...

Thanks for Suggestions,
I assume that we have two different types of methods/functions, one is on Datetime module, and another is on Datetime object itself.
Methods of Datetime module
Already there
Datetime.new(); -> Datetime(Object) , current time object
Datetime.newUTC(); -> Datetime(Object) , current time object
To implement/modify
Datetime.new(); -> Datetime (Object)
Does values means day,month,year, hour, etc ..?
Datetime.strptime(, ); -> Datetime(Object) , currently it returns string i guess
Methods of Datetime Object
Already there
dateTime(object).strftime()  -> String , returns string
In future
dateTime(object).addMinutes(); -> Datetime(Object)
dateTime(object).addHours(); -> Datetime(Object)
...

Apologies yeah, step time to return a date time object rather than a number, and then getTime to return a number
I had  because at the moment this is overloaded, that’s fine by me and can stay as is

No rush or anything @MannarAmuthan but just checking if you're still working on this?

Hi yes , I am planning to work on this in weekend

Hi @Jason2605 , Please look into it, and provide any suggestions or changes needed.

Will take a look later today, thanks @MannarAmuthan

@briandowns Be good to get your thoughts on this too

I like this.
I'm curious if we could simplify it though.
I was looking at working on a time module myself at one point and was going to model it after the Time package in Go. Essentially, the Time type is just a number and operations are performed on that value(s). There's a Duration type as well which is just an alias for an int64. The package's API is small and clean as well. https://cs.opensource.google/go/go/+/master:src/time/time.go;drc=bc2124dab14fa292e18df2937037d782f7868635;l=135

Hi @briandowns , That one is great reference, Thanks for this !
I assume we are talking about the structure of datetime object , will take look into it.

I like this.
I'm curious if we could simplify it though.
I was looking at working on a time module myself at one point and was going to model it after the Time package in Go. Essentially, the Time type is just a number and operations are performed on that value(s). There's a Duration type as well which is just an alias for an int64. The package's API is small and clean as well. https://cs.opensource.google/go/go/+/master:src/time/time.go;drc=bc2124dab14fa292e18df2937037d782f7868635;l=135

Yeah this is an interesting concept, will need to have a deeper look through the Go source but I think representing the time as a number internally makes a lot of sense to me

Actually I read more on this, and found that classic time_t epoch integer, represents time after 1970. I changed the code, it is working fine,
New structure:
typedef struct {
long time;    /* timestamp integer*/
int is_local;
} Datetime;
But I worry, that we need the capability to create Datetime before 1970 also.
If you have any thoughts on this let me know.

As always, I'll defer to @Jason2605 but I think we can be fine with storing a wall time and mono time in int64_t values in a dateTime object. From there, that single object can be used for timers, time diffs, and we can cast up and down from time_t. In the case of timestamps prior to epoch, they end up being negative numbers.

As always, I'll defer to @Jason2605 but I think we can be fine with storing a wall time and mono time in int64_t values in a dateTime object. From there, that single object can be used for timers, time diffs, and we can cast up and down from time_t. In the case of timestamps prior to epoch, they end up being negative numbers.

Honestly for this one, I'd probably go with whatever the go library is doing (still need to properly look at it sorry). A single numeric value storing the current time sounds perfect to me and going into negative numbers for dates prior to 1970 is fine (and what happens when you want a time before then when using unix time anyways yeah)

A simple and naive assumption of how this might look:
typedef struct {
    int64_t wall;
    int64_t mono;
} DateTime;

DateTime now() {
    struct timespec wall, mono;

    clock_gettime(CLOCK_MONOTONIC, &mono);
    clock_gettime(CLOCK_REALTIME, &wall);

    DateTime dt;
    dt.mono = mono.tv_sec;
    dt.wall = wall.tv_sec;

    return dt;
}

Rooted off of the DateTime class, we can any number of methods that will use the values therein. Timers using mono, time and date operations using wall.

Thanks for all suggestions, I am planning to work on this , will provide updates

Currently, I have created a datetime object to store time as an integer and included a flag for location (local or not). However, this is not quite complete; I need to implement ADD and SUB methods  ( and duration ) to ensure proper functionality. I will investigate this further and continue working on it.

Thanks for still working on this! Will be a really nice addition to get a more fully featured datetime library

Suggestion and Approaches for introducing timedelta (or) duration object:
Naming:  The name timedelta is inspired from python datetime package , meanwhile duration also makes sense
Note: These are just initial thoughts, welcom more suggestions, even hybrid approaches.
To Remember:
In Dictu, there is no named or keyword arguments for function calls, which restrict us to defining clear contract for timedelta object.
Approach 1: Constructing TimeDelta by dictionary
mydatetime = Datetime.new();

toAdd = Timedelta({
'days': 2,
'hours': 1
});  // Can have year , month, etc

mydatetime.add(toAdd); // Returns new datetime object

Pros

Can have more operations such as getting delta difference of two datetime objects, as delta object, etc.
Having clear difference with datetime object

Cons

API might looks slightly complex, especially introducing new object.
Constrcution of timedelta object looks little nasty

Approach 2: Avoid delta object
mydatetime = Datetime.new();
mydatetime.addDays(1);
mydatetime.addMinutes(2);
mydatetime.addYears(1);
//etc

or
mydatetime = Datetime.new().addDays(1).addMinutes(2).subSeconds(1);

Pros

Very simple and minimal in terms of design

Cons

Limited functionality
Might lead to defining lot of methods

Thanks very much for the detailed write up! I personally thing the Timedelta option is the way to go - I feel like when dealing with calculating time differences it will be a lot easier to conditionally create a timedelta object than it will be to apply different methods - it also means we will be able to have an actual value representation of a length of time (we can then apply nice string methods to this for example)!
No kwargs is a valid gripe and would be a really nice addition, but as you say for now, a dictionary would be the next best replacement for instantiation
Be good to hear your thoughts too @briandowns

Yeah when you run .add or .minus (or whatever we decide the public API to be) I would expect a new datetime object yeah!
I'm not too fussed on Duration vs Timedelta either, Luxon a popular JS library seems to use Duration whereas Python's implementation as mentioned uses Timedelta, so open to either on the naming front.
Comparisons of objects will be an interesting one in the sense of would you expect the standard operators to work with these types (< > != ==) or would we have comparison methods (potentially opens up the question of user defined operator overloading too but can save that for another day)

I'm not too concerned around naming Go uses an int64 as type Duration. Meh.
As for object comparison, I'd probably at least expect a couple methods like t2.equals(t1);, and maybe a diff method.

So you'd prefer methods rather than overloading the operators?
Makes sense, yeah I think im siding towards Duration at the moment

Yeah, for sure for methods over operators. Seems like the surface area for that is super small and still achieves the necessary functionality.

If this has stagnated, I'd like to pick it up.

If this has stagnated, I'd like to pick it up.

Have at it mate!

Sorry for dropping this earlier, but I'd love to jump back in and help now. Let me know if there are any updates or changes needed from my side, and I'll get on it as soon as possible.
I guess, I've finished most of the things, but I am not sure about the failures. Need to check

Closing in favour of #750


Update tuv based on uv (1.10.1)

Back to the source structure of uv

Remove uv_platform.h, uv__platform.h, uv__unix_platform.h, uv_extension.h,
uv__unix_extension.h, ...

: Different source structure make us hard to upgrade uv.
: Remove redundant code in above files.

QUEUE does not require initialization before QUEUE_INSERT_HEAD
static integer does not require initialization of zero

Differences between uv 1.10.1 and tuv

Nuttx platform support
Many code (that assumes unix, especially linux) are removed
Resource cleanup on exit is added (as form of _deinit)
CMake scripts support
Tuv test runner
: We cannot use uv's test since it assumes fork. Thus I reuse tuv tests.

Hello, I think below is needed:

Add license which is modified.
Remove codes which are related 'IPv6'

Thanks.

I added license to modified files. And I make check whether ipv6 codes are removed in inet.c.

LGTM

LGTM


Update winapi version from 0.2 to 0.3

Adds only the necessary cargo features to reduce compile time and reduce
the chance of linking errors occurring for unused libraries (e.g.
d3d12.dll fails to link on my win10 VM).
I thought I'd try and land this before before working on the wasapi
backend implementation for #201.
Tested both beep.rs and enumerate.rs and they work fine with the update.

Thanks!


Observations on eyeglasses and textures

Thanks for sharing your ideas and code. It is rather fun to compare it to StyleGAN2. I am wondering about this

Why does your algorithm do poorly with eyeglasses?

There is a certain blockiness to the images (almost like JPEG artifacts) Not sure why it is more common.

I would have expected hair to be better rendered with your architecture, but for some odd reason (especially facial hair) is more iffy. Almost like too much regularity to the wavelet directions.

Thanks if you have any information to share. It is an interesting architecture you propose, so I missing intuition behind it.

@yaseryacoob hey, thanks for you feedback!
Yes, we observed problems with glasses generation—detailed exploration of this problem we have postponed for further work. The main hypothesis about this problem is that this behavior can be related to "undersampling" problem. So, by design, our pipeline generates training data on the fly using a teacher network. If the probability of face with glasses is small, it will be hard to generalization for this class of samples.
What about 2-3, I think this problem related to "underfitting" of the network in common. In the last stages of the training, we observed some symptoms of "overfitting" the discriminator network that leads to stop training. It was partially fixed by using differentiable augmentations, but some artifacts still exist on the generated images.
Yes, we noticed the same problems in our model. But our work just the first step to fast production-ready style-based generative models. We will try to fix the known issues in further works and make the final quality more closure to the original network.

I figured you must have seen these, and I fully understand the complexity of research code and also the challenge. I actually mean to be encouraging of the approach and architecture overall. I will look into it as well (as much as I can within your code to see what else may enable improving the generation. Here is another question, for the example above I used compare.py which inject a 512 latent, can I inject a W+ 18x512 latent instead? (obviously StyleGAN2 has no issue with that, but from the paper I couldn't tell if your architecture is more than W. Can you clarify?
Also, you can send me email directly to<EMAIL_ADDRESS>if you rather not discuss in public.

@yaseryacoob I hope my code is more "engineering" than "research" because I'm an engineer, not a research scientist in general 😂 But if you find it difficult, please feel free to write about it and I'll try to explain it. It will be great if my work helps to further research in GANs!
What about latent space: W+ space isn't equal between StyleGAN2 and MobileStyleGAN because:

MobileStyleGAN has one building block less than StyleGAN2 (the reason is related to using wavelet-domain and had been described in the article).
Building block of MobileStyleGAN has more skip connections to style than in StyleGAN2. You can look at the difference between building blocks for StyleGAN2 and MobileStyleGAN in code.

Actually research and engineering blend when significant architecture changes are made. The changes you made can and should lead to different outcomes from StyleGAN2, but there are a number of issues, like the students/teacher framework. StyleGAN2 is of coarse a good teacher, but when does it stop and a student better than the teacher come to exist is a matter of deeper analysis. I obviously can't tell without further tinkering with the code if the student is better than the teacher given the architecture. The example above shows that given a specific W, you a bit less than StyleGAN2, but it doesn't mean that a W+delta can or can't match or beat StyleGAN2. Delta can be optimized or learned by an encoder.  There are some interesting questions to answer.

@yaseryacoob It's pretty cool idea is to train external networks that will predict the delta between student and teacher! If it works and computational complexity for both networks will be less than a teacher, it will be pretty results. I saw the same ideas about the iterative estimation of the output image in ReStyle paper: https://yuval-alaluf.github.io/restyle-encoder/ 🤔

Yeah I forgot about the restyle approach! I had discussed things with them last week. You can see the thread there. We are missing the last 5-10% in quality, and I am not sure where it will come from, architecture/latent representation/optimization or god knows what. So testing your architecture by pushing it to the 100% is worth trying so we learn where the potential lies.
My gut feeling is that the architecture is got to be the first hurdle that needs improvement to perfectly capture all the frequencies adequately, it has to be just "right". I can't prove it for now... I was hoping your experiment will teach us something.

@yaseryacoob I added an experiment with iterative refinement to my to-do list. I'll try it when I have free time :) It will be great if you research our work deeper and try to improve it too 💪


fix: cross platform path separator with path.sep

What type of PR is this?

[ ] Feature
[x] Bug Fix
[ ] Refactor
[ ] Documentation Update

Description
Fixes the templatePath url match in windows.
Added unit tests?

[ ] No, I want help in writing tests.
[ ] No, I want someone else to write tests.
[x] No, The addition does not need tests.
[ ] Yes

[optional] Random GIF to +1 someone's day

Welcome!


V86 for PC

@copy
Is there a way to create a virtual machine on the actual computer (not just have the virtual machine run in a browser but to have it run on the actual computer) and have the browser act as a interface so when  someone closes the tab the virtual machine isn't destroyed. Is it possible to use node.js to accomplish this task?

I can barely understand what you're trying to say, but about the "Node.js to prevent the VM from being destroyed when the user closes the tab". This MIGHT be possible, but it would be impractical and would take up tons of storage if there are a lot of people using the website.

It's probably possible, but out of scope for this project.


feat(wip): monorepo structure

Summary
This PR moves entire component structure to monorepo
Checklist

[x] core package
[x] swap package
[x] wallet-connectors package
[x] wallet-modal package
[x] SAR package
[x] portfolio package
[x] bridge-swap package
[x] elixir package
[x] pools package
[x] governance package
[x] airdrop package
[x] shared package ( ongoing )
[x] state-hooks package ( ongoing )
[x] set up an example app that uses monorepo packages to make sure everything is working after migration
[x] set up automated changelog generation using changeset
[x] set up CI/CD actions to publish version. This should only go to the Honeycomb npm organisation. No need to duplicate it and publish to the historical Pangolin
[ ] set up size-limit on each PR to make sure all packages are tree-shakable
[x] update readme, contribution guideline, github actions readme to include all essential information
[x] make sure storybook runs properly in each package
[x] add/update ReadMe file in each package
[ ] After everything is done, analyze all package json to make sure we have only necessary dependency
[x] move all packages to @honeycomb-finance org. This should be dealt with above as part of the CI/CD process.
[x] Integrate honeycomb packages to interface - Related PR
[ ] (optional) move common dependency to monorepo root
[ ] (optional) move rollup configuration to common package
[x] Resolve all SonarCloud issues

Carry forward PR from https://github.com/pangolindex/components/pull/404

/snapshot


create json file containing packages per category for easier searching through categories at build time

# TODO: create json file containing packages per category for easier searching through categories at build time

Generate JSON file using a script

This will allow for:

Only showing packages in a category in the browse tab
Searching through packages in a specific category in the search tab