New APP version hardly adopted


I recently published (2 days ago already) a new version of my APP:

I precise the version was certified 2 days ago.

Usually, when I publish a new version, the users migrate within one day max “automatically”.

But it seems to be blocked:

Any idea why?
I added the permission “homey:manager:api” in the new version, I’m affraid it is the reason for it!

The user need to validate something?

remark: the screen captures show the date of 5th October for both versions, but 0.7.4 is almost one month old. 1.1.4 is based on 1.0.0 which introduced the new permission, and it’s almost 5 days old already.

Yes, when permissions change users have to explicitly allow them before the app will be updated.

They receive a notification or something?
I was not expecting that, so annoying …

The new version bring a new UI, many fixes (including a big memory leak), and many new possibilities.

Makes sense though that when permissions change, especially when homey:manager:api gets added, updates aren’t automatically installed.

I don’t know if they get a notification or not, but eventually they’ll (hopefully) find the forum and see there’s a new version.

Ok so done is done, but still I need the users to switch to the new version.
Can I pubish a version which doesn’t require the permission to force them to update “automatically”?

I undersntand it is not possible to make this permission “optionnal”, it’s all or nothing.
=> I more and more feel like Ahtom BV is playing the same way as Steve JOBS => decide what the users have right to do or not … I hate Apple because of that

Between the “inconsistentcy of the SDK, local API and web API”, the impossibility to handle dynamic enum values, and this permission constraint, I start to be very very very annoyed …
I spent so many hours to workaround the SDK constraints already, it would be enough to fix the SDK itself … let’s not talk about their documentation …

Why? I mean, what’s the rush?

I don’t understand. I assume your app needs the API permission, so at some point there is user interaction involved if they want to upgrade.

Sorry for the delay, I was thinking about it :slight_smile:

The permission “api” is required because of the inconsistency in the SDK, local API and web API of Homey.

Compared to local API, Web API require the bearer token, but both require the api permission.

  1. You need local API to retrieve all the zones of the home
  2. You need Web API to:
  • Change a device name
  • Change a device zone
  • Delete a device

That’s why I introduced this permission requirement.

So currently, I end up with several issues:

  1. Old users tested and gave up the ESPhome application before I even published anything

It would be nice for them to take a new look :slight_smile: They may like it

  1. Old version had a memory leak (big)

They may have given up, it would be nice to onboard them again

  1. Some users are on the old Driver (either old version or new version of the app)

I want them to switch to the new driver (Wizard), it will enhance their experience

How I’m planning to handle the mess:
1/ Have a notification sent every morning (8am?)
=> You are using an old version, upgrade!
=> You are using old driver, switch!

2/ Put a warning on all concerned devices!
=> Same message

The messages themself will be worked out, and should be translated in all languages.
In a perfect world, it would be nice to include a link (to the user guide) in the messages, but I don’t think it is possible.

How is this even going to work? You’re going to publish a new version of your app with the permissions removed (otherwise it won’t get updated automatically and your users won’t be getting the notifications), and then what? Where will they be able to find the new app version that you want them to upgrade to?

Yes, it seems supported, even I never tested it yet:

Just publish a 0.7.5 based on 0.7.4 (last version before the big upgrade).
Wait for certification.
Then publish a… over it.

The users already on 1.x will not fall back to 0.7.5, at least that’s what the link say :slight_smile:

Not until you can be fairly sure that everybody has updated to it, otherwise you’ll run into the exact same issue. But without publishing 1.x your daily notifications are pointless.

It all seems a bit convoluted to me, to be honest.

Damn it, I think you are right … their updating feature works when you have a live version and a test version. Not when you have 2 live versions …

I will ask on WeeJeWel on Slack … If I use this feature and it doesn’t behave as expected, it could be a big big mess.

There’s no such thing as “2 live versions”: there’s the live app, and the optional test app.

It’s not possible to (get users to) install a specific version, it has to be one of those two.

That’s theory, in practice, that the situation I end up with …
Callthe old one deprecated if you want, but that’s just word game :slight_smile:

No, your situation is that your users are running an older version that doesn’t get automatically updated to the new version because the latter has different permissions.

I’m not saying that it’s impossible for a Homey to be running an older version, I’m saying that you cannot explicitly (get your users to) install a particular version of an app unless that version is either the current live or test version.

Yes, I understand your point.
If the user disabled auto-upgrade, clearly he is out.

The problem here started with the new permission, and I have no idea how Homey handle it.

How the user is invited to accept it?

The consuquence is as it is, I have many users blocked in a deprecated version which I want to onboard on the latest version.

Just out of interest…what’s the use case that an app needs to rename/remove devices? Isn’t that a user decision?

Sure it is anyway, the Wizard of ESPhome just make it easier and faster (if the bearer token is set …).