Subscribe to device data for Zendure products. To receive information from the device, Developers can obtain the same device information as the official App by subscribing to Zendure MQTT Broker
I noticed that the MQTT integration in Home Assistant spams the logs with high-frequent warnings relating to missing JSON attributes in Zendure SolarFlow messages like these:
2023-08-13 16:40:10.960 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'inputLimit' when rendering '{{ value_json.inputLimit}}'
2023-08-13 16:40:10.963 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'electricLevel' when rendering '{{ value_json.electricLevel}}'
2023-08-13 16:40:11.962 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputPackPower' when rendering '{{ value_json.outputPackPower}}'
2023-08-13 16:40:11.967 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputHomePower' when rendering '{{ value_json.outputHomePower}}'
2023-08-13 16:40:11.972 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputLimit' when rendering '{{ value_json.outputLimit}}'
...
I suspect, it happens if the MQTT messages received updates some attributes but not all. But it is difficult to be sure. These messages massively spams the logs, given the high frequency of arriving MQTT messages consisting of 1-few attributes. Generally, it would be preferable to broadcast complete, aggregated messages, with lower frequency if needed. Currently, the update frequency seems rather high with multiple messages in one seconds, each consisting of a single or few attributes. This might also reduce the seemingly high load on the Zendure servers.
I noticed that the MQTT integration in Home Assistant spams the logs with high-frequent warnings relating to missing JSON attributes in Zendure SolarFlow messages like these:
2023-08-13 16:40:10.960 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'inputLimit' when rendering '{{ value_json.inputLimit}}' 2023-08-13 16:40:10.963 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'electricLevel' when rendering '{{ value_json.electricLevel}}' 2023-08-13 16:40:11.962 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputPackPower' when rendering '{{ value_json.outputPackPower}}' 2023-08-13 16:40:11.967 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputHomePower' when rendering '{{ value_json.outputHomePower}}' 2023-08-13 16:40:11.972 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'outputLimit' when rendering '{{ value_json.outputLimit}}' ...
It seems to relate to the MQTT discovery process of Home Assistant trying to populate the auto-generated sensors with the JSON data. Similar issues are known for other devices like here: https://github.com/Koenkk/zigbee2mqtt/issues/6987 https://github.com/home-assistant/core/issues/48851 and several others.
I suspect, it happens if the MQTT messages received updates some attributes but not all. But it is difficult to be sure. These messages massively spams the logs, given the high frequency of arriving MQTT messages consisting of 1-few attributes. Generally, it would be preferable to broadcast complete, aggregated messages, with lower frequency if needed. Currently, the update frequency seems rather high with multiple messages in one seconds, each consisting of a single or few attributes. This might also reduce the seemingly high load on the Zendure servers.
This is also been described by others: (German language): https://github.com/z-master42/solarflow/blob/main/solarflow.md#user-content-fn-1-b21a976d0a55dc53f993ab04ea9b6a05
A workaround may be to disable the discovery process in the MQTT integration, but this is cumbersome. At least I think it should be documented here.