wlcrs / huawei_solar

Home Assistant integration for Huawei Solar inverters via Modbus
GNU Affero General Public License v3.0
559 stars 89 forks source link

[Bug]: wrong TZ in startup and shutdown Time #46

Closed 2bbe closed 2 years ago

2bbe commented 2 years ago

System Health details

System Health

version core-2022.4.5
installation_type Home Assistant Container
dev false
hassio false
docker true
user root
virtualenv false
python_version 3.9.9
os_name Linux
os_version 5.4.72-microsoft-standard-WSL2
arch x86_64
timezone Europe/Stockholm
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4333 Installed Version | 1.24.5 Stage | running Available Repositories | 1032 Downloaded Repositories | 34
cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
lovelace dashboards | 3 -- | -- resources | 16 views | 36 mode | storage
spotify api_endpoint_reachable | ok -- | --

Huawei Solar Setup

Inverter: SUN2000-6KTL-M1 - V100R001C00SPC14 Sdongle: Yes-V100R001C00SPC126

Describe the issue

Startup time and shutdown time is displayed in wrong time zone. From HA huawei_solar: image From Fusion Solar: image

Modbus register 32091 & 32092: 25180 & 65336 -> 1650261818 Epoch seconds

-> Monday 18 April 2022 06:03:38 in readable format.

Reproduction steps

  1. Check statrtup time in HA vs fusion solar
  2. ...

Relevant debug logs

022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.transaction] Adding transaction 75
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.client.asynchronous.async_io] recv: 0x0 0x4b 0x0 0x0 0x0 0x6b 0x1 0x3 0x68 0x0 0x0 0x13 0x40 0xf 0xbb 0xf 0xb1 0xf 0xac 0x9 0x14 0x9 0x18 0x9 0x6 0x0 0x0 0x1a 0xdc 0x0 0x0 0x1b 0x1 0x0 0x0 0x1b 0x19 0x0 0x0 0x13 0x9a 0x0 0x0 0x12 0xc5 0xff 0xff 0xff 0xe7 0x3 0xe8 0x13 0x8a 0x26 0x17 0x1 0x8b 0xb 0xb8 0x2 0x0 0x0 0x0 0x62 0x5c 0xff 0x3a 0x62 0x5c 0x7a 0xa5 0x0 0x0 0x12 0xe7 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2 0x13 0xb9 0x0 0x2 0x2b 0x0 0x62 0x5d 0x54 0x7a 0x0 0x0 0x0 0x34 0x0 0x0 0x5 0xaf
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.framer.socket_framer] Processing: 0x0 0x4b 0x0 0x0 0x0 0x6b 0x1 0x3 0x68 0x0 0x0 0x13 0x40 0xf 0xbb 0xf 0xb1 0xf 0xac 0x9 0x14 0x9 0x18 0x9 0x6 0x0 0x0 0x1a 0xdc 0x0 0x0 0x1b 0x1 0x0 0x0 0x1b 0x19 0x0 0x0 0x13 0x9a 0x0 0x0 0x12 0xc5 0xff 0xff 0xff 0xe7 0x3 0xe8 0x13 0x8a 0x26 0x17 0x1 0x8b 0xb 0xb8 0x2 0x0 0x0 0x0 0x62 0x5c 0xff 0x3a 0x62 0x5c 0x7a 0xa5 0x0 0x0 0x12 0xe7 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2 0x13 0xb9 0x0 0x2 0x2b 0x0 0x62 0x5d 0x54 0x7a 0x0 0x0 0x0 0x34 0x0 0x0 0x5 0xaf
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.factory] Factory Response[ReadHoldingRegistersResponse: 3]
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.transaction] Getting transaction 75
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [0, 4928, 4027, 4017, 4012, 2324, 2328, 2310, 0, 6876, 0, 6913, 0, 6937, 0, 5018, 0, 4805, 65535, 65511, 1000, 5002, 9751, 395, 3000, 512, 0, 25180, 65338, 25180, 31397, 0, 4839, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 5049, 2, 11008, 25181, 21626, 0, 52, 0, 1455]
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x13@']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x1a\xdc']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x1b\x01']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x1b\x19']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x13\x9a']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x12\xc5']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\xff\xff', b'\xff\xe7']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'b\\', b'\xff:']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'b\\', b'z\xa5']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x02', b'\x13\xb9']
2022-04-18 12:07:25 DEBUG (MainThread) [pymodbus.payload] [b'\x00\x00', b'\x05\xaf']
2bbe commented 2 years ago

I think its related to following:

wlcrs commented 2 years ago

Thanks for diving into the documentation. The "Epoch sec in local time" is an important clue on what is probably implemented wrongly.

I will also need to investigate how the Timezone register influences the time that is reported.

inigoml commented 2 years ago

This bug was already present in the other huawei_solar integration (not yours). So, is probably related with modbus library and not with the integration.

malteger commented 2 years ago

The bug is actually in this integration, as the timezone conversion is done correctly (as seen in the example the datetime shown in HA is in UTC, which is 2 hours behind your local time, which is exactly the difference you see).

The problem is that the entity is missing the proper device class for datetimes and therefore gives you the string representation of the date in UTC. If the device class is changed to timestamp the value is shown correctly.

wlcrs commented 2 years ago

Thank you for your contribution. Greatly appreciated!