Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the minimum supported gen1 firmware to 1.9.0 #474

Merged
merged 4 commits into from
Jan 8, 2024
Merged

Conversation

bieniu
Copy link
Collaborator

@bieniu bieniu commented Jan 6, 2024

The last firmware for SHPLG-1 is 1.9.4, and some SHUNI-1 are stuck with firmware 20210105-095645/release-1.9@8517d431+, so I suggest using 1.9.0 as a minimum, except for bulbs that support light transition, in case these bulbs, the minimum firmware remains at version 1.11.0.

Related to: home-assistant/core#107352

@bieniu
Copy link
Collaborator Author

bieniu commented Jan 6, 2024

I'm still not convinced that we should use 1.8.5 as the minimum fw ver home-assistant/core#107235

What do you think?

@thecode
Copy link
Contributor

thecode commented Jan 6, 2024

What is the minimum we need for the bulbs? if I remember they had a changes in the API

@bieniu
Copy link
Collaborator Author

bieniu commented Jan 6, 2024

transition for lights was introduced in 1.11.0, so anyway we will have to restore the logic that checks the firmware version for light bulbs.
Previously in 1.9.0 there was a change for RGBW2 related to transition.
appliance_type for relays was also added in 1.9.0, it is not something that affects our code but it is a significant change in the API.

It's a pity that we don't know how many people are using firmware 1.8.5 due to WiFi problems.

@chemelli74
Copy link
Collaborator

I would start making an exception for Plug and accept 1.9.4 and leave other devices as they are in current 2024.1.x and eventually add more exceptions if needed in future

@thecode
Copy link
Contributor

thecode commented Jan 6, 2024

I would start making an exception for Plug and accept 1.9.4 and leave other devices as they are in current 2024.1.x and eventually add more exceptions if needed in future

I don't agree with this, as per @bieniu above with 1.9.4 we can support everything except for transition for bulbs.
If we make an exception would be easier to make an exception that force 1.11.0 for bulbs and all others 1.9.4, this will reduce the amount of effected users, otherwise we may end up with multiple cycles which require new aioshelly
Note that we don't really know the whole picture as many users update HA only after few releases.

@chemelli74
Copy link
Collaborator

Anyway, for all users that are on 1.8.5 nothing changes with this PR.
This is why I suggested not to change current behaviour for all devices, but for the one excluded.

@lgehring
Copy link

lgehring commented Jan 6, 2024

Also stuck at 20210105-095645/release-1.9@8517d431+ on Shelly Uni with no clear option to upgrade. Getting aioshelly.exceptions.FirmwareUnsupported. Please also include the Uni if making specific exceptions.

@thecode
Copy link
Contributor

thecode commented Jan 6, 2024

I would start making an exception for Plug and accept 1.9.4 and leave other devices as they are in current 2024.1.x and eventually add more exceptions if needed in future

We didn't need to wait to much to get another example, see home-assistant/core#107275 (comment)

{'type': 'SHHT-1', 'mac': '44179321DC27', 'auth': False, 'fw': '20210710-130145/v1.11.0-g12a9327-master', 'sleep_mode': True}

Date of the FW (1.10) is 2021-07-10 while our limit for 1.10 is 2021-07-15 only 5 days later. This is a Shelly HT, now we force this user to manually wakeup the device and update it just to get the same FW with few days later. Looking at #460 (comment) we already had discussion about devices with this FW with older timestamps.

@chemelli74 I understand you like to have things on latest versions, however our main reason to enforce a minimum version should be based on the following:

  1. If a version bellow has incompatible API or missing features which forces us to maintain different code to handle it.
  2. If there is a known critical bug fixed by the manufacture which we need users to update to reduce our issues.

Looking at the release notes for Gen1, the discussion here and in the original PR: #460

For the points above:

  1. For all devices excepts specific bulbs any version above 1.9.0 doesn't bring any new feature or API changes we need to handle, for bulbs of course we do need to handle it differently but an exception will exist anyhow doesn't matter if it will be for the SHPLG-1 or another devices, however as I wrote before we don't know the whole install base and what it may bring in the next few weeks/months when more people update their core.
  2. Looking at the issues in the last year (for Gen1) we didn't have any issue which is FW related.

For now we should focus on reducing users frustration to the minimum firmware which doesn't require major code changes or handling multiple incompatible APIs and my understanding is that excluding bulbs any 1.9 version should work.

About 1.8.5 mentioned at home-assistant/core#107235 I had a discussion with the issue owner and since he is one of the QA members, aware of this issue, seen no other complains he also suggested setting 1.9.0 as the minimum version.

"But, keeping compatible back to 1.9.0 would still be a positive direction, even if my particular need isn't met."

As for the bulbs, my suggestion would be to do the following:

  1. Set minimum version for all devices for 1.9.0 or 1.9.4 (per my understanding for us it doesn't make any difference so 1.9.0 would be preferred in my opinion, also give some spare in case there are different FW timestamps).
  2. Set a minimum version for the relevant bulbs to 1.11, the exception will exist in aioshelly so from HA core side we won't need the logic which was removed at Bump aioshelly to version 7.0.0 home-assistant/core#105384 and will keep the code clean.
  3. Note that we still have unhandled exceptions (see Shelly - Task exception was never retrieved when firmware is not supported home-assistant/core#107394) when firmware is not supported, this was found with my SHPLG-1 with 1.9.4, however even if I complexly disable/remove the device from HA the error will still happen on every discovery (which Shelly does in a high rate), I had 1100 occurrences of this error after disabling the device in HA which means even if users decide to keep a device on a lower version or device is not even connected to HA, they will still be overwhelmed by errors. I understand this is a different issue and should be fixed, but until we fix it, reducing the firmware version requirements will reduce the number of affected users.

If you have any good reasons to enforce 1.11 for all (or most devices) please explain them.

@bieniu bieniu changed the title Change the minimum supported gen1 firmware to 1.9.4 Change the minimum supported gen1 firmware to 1.9.0 Jan 7, 2024
@bieniu
Copy link
Collaborator Author

bieniu commented Jan 7, 2024

I agree with your opinion @thecode. PR updated.

@bieniu bieniu marked this pull request as ready for review January 7, 2024 10:15
@thecode
Copy link
Contributor

thecode commented Jan 7, 2024

@chemelli74 can we go with this change?

@chemelli74
Copy link
Collaborator

@chemelli74 can we go with this change?

Honestly I don't agree but I'm used to accept what the majority approve.

@thecode
Copy link
Contributor

thecode commented Jan 8, 2024

@chemelli74 can we go with this change?

Honestly I don't agree but I'm used to accept what the majority approve.

Ok, we can change it in the future if we discover problems for now would be good not to hold a new release. Thanks for accepting this although you are not fully convinced.

@thecode thecode merged commit 461bf37 into main Jan 8, 2024
3 checks passed
@thecode thecode deleted the min-fw-1.9.4 branch January 8, 2024 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants