Conversation
Adds a local onboarding option to the config flow that talks directly to ZenSDK capable devices over their local HTTP API, with no Zendure account or token required for setting this up. It does however require knowledge of the device IP and the devices should be assigned static IP addresses. This local setup can be used to work-around the 'no device found' issue as reported in issue Zendure#1502. Devices onboarded via the local flow are handled no differently from those added via the cloud onboarding, they behave the same. - config_flow.py: added a cloud-vs-local option menu, plus a wizard to add local devices, that validates each device via its /properties/report and auto-detects the model from the reported product string. Reconfigure allows adding or removing devices later. - api.py: in local mode Connect() synthesises the device list from config and skips the cloud based MQTT setup (obviously), localDeviceList() returns one entry per configured device, and testLocalDevice() validates and returns (sn, product). It also registers the solarFlow4000MixAC+ alias -> SolarFlow4000AC_Plus. - device.py: local devices default to the ZenSDK connection and poll the local report every cycle. - Api.devices is cleared on unload and on device removal so a removed device does not reappear.
jahierwan
reviewed
Jul 22, 2026
This was referenced Jul 27, 2026
Contributor
Author
|
@FireSon is this something support can be added for? Its now closed as stale, but nobody really looked at it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a local (cloud-free) onboarding option to the config flow that talks directly to ZenSDK-capable devices over their on-device HTTP API, no Zendure account token needed. Requires knowing the device's IP and assigning it a static address.
This works around the "no device found" issue reported in #1502 (e.g. affects the SolarFlow 4000 Mix, which the cloud API doesn't seem to return). But can also be used by those that want a true local setup, that does not require a cloud based MQTT connection.
Devices onboarded locally behave identically to cloud-onboarded ones, same entities, same manager logic.
Detailed changes
config_flow.py: new cloud/local pick menu, plus an add device wizard for local devices. Each device is validated via its/properties/reportendpoint, with the model auto-detected from the reported product string. Reconfigure supports adding/removing devices later.api.py: in local mode,Connect()synthesizes the device list from config instead of hitting the cloud API and skips cloud MQTT setup;localDeviceList()builds one entry per configured device;testLocalDevice()validates a device and returns(sn, product). Also registers thesolarFlow4000MixAC+product alias toSolarFlow4000AC_Plus.device.py: local devices default to (and are locked to) the ZenSDK connection, and poll the local report every cycle since there's no MQTT push.Api.devices: is now cleared on unload and on device removal, so a removed device doesn't reappear.Localization
I manually worked on Dutch and English, however an LLM was used to translate to other languages. Would be appreciated if someone could check those.
Test plan
Unfortunately I cannot easily test if cloud-onboarded devices/setup still works as expected, as I don't have any devices that work via that method. Perhaps someone else could validate, but the code path is basically unaffected so I don't expect any issues.
Please let me know what you think of this PR, I'm happy to work on details where required.