What do you mean? HTTP requests?
You mean the API’s?
WebSocket “requests” (WebSocket-over-TLS, if he actually means “wss”).
2 Likes
Yeah i know what he wants, but i wonder what he means with HTTP requests?
I haven’t added anything that i think he means.
1 Like
What would you want with it btw? Updates when variables are changed (and updating them ofc)?
Or for use with the BLL Coding and other of that stuff?
1 Like
Hmmmm… Why would they add that timeout to the whiteball Pro, after 8 years? Do you know in which firmware that timeout was applied?
1 Like
Only on version 10 = HP2023 currently!.
These messages confuse me. What is an old HP? The Homey Pro 2019?
What version of BLL will keep working if not updated? I use v2.3.10. Is that “safe”?
1 Like
You are, very.
This change in the SDK was discussed on Slack about two weeks ago already, it was explained on Slack by @Jero and he offered a few tips on how to work around it.
HomeKitty also needs to wait when it starts within 10 minutes after a reboot (to wait for other apps to start) and it was trivial to fix.
The init timeout was already there it’s part of the new Docker app runner which was already in use on cloud. The only thing he changed was the message you see.
1 Like
Indeed, it might have been used on the cloud, it was not on the HP2023.
I have been working on this for months, and the error (not just the message) has just been accuring the last days.
As in, my apps do not start up anymore.
If this would be the case for two weeks, i would not have been developing this two weeks.
But he, believe it or not, i would be very very happy if i indeed was mistaken, because this really feels like a hard and cold knive in my back, to be honest.
But @robertklep , there is a fix you say?
How? I have been at it since i my found out why my HP2023 was not working since yesterday.
Old = ‘classic’ = Early 201x = all white balls
(I prefer ‘classic’ over ‘old’ though 
while my white ball runs very well and I’ve no reason (okay, & no budget) at all to buy the 2023 model yet)
2 Likes
Yes, just move any code that needs to wait for something out of onInit and into another method:
// before
async onInit() {
...
await waitForSomethingThatCanTakeAWhile();
}
// after
async onInit() {
this.onInit2();
}
async onInit2() {
...
await waitForSomethingThatCanTakeAWhile();
}
I’m not sure how that is possible the only way I see that could happen is if the order of the app starts have changed. As in before the BLL app was maybe always ready before another app started?
Well, i have resetted the HP2023 a few times to factory after testing migrations
Yes, Apps using the BLL npm package had a timing to wait for the BLL to have been started, and it worked very well, even on the old white homey (where app start could take some time overal).
Im sorry, but it looks as if you are forgeting the await. Meaning, devices would start loading before the onInit2 would be finished and thuse before required data would be collected.
Also flowcards can already be activated at that point, while services would not yet be available (and more importantly, i do not know yet if it will be).
No, I’m not.
Using await will make onInit wait until onInit2 is finished, and hit the 30-second timeout again.
That’s a structural issue in your app, and a result of making them excessively tightly coupled. Still plenty of ways around it, for instance just let the devices wait until the requirements are in place before they set themselves as available.
Loading all requirements on app start and return with an exit code is not an structural issue, it’s Good Practice. Most (good) applications do this.
All software that i have ever build, i believe, first loads all required parts before starting up…
Guy’s breath in and breath out. There are more ways to Rome then we know. It will be solved one way or the other way 
1 Like
You’re loading external resources, not requirements. I’m sure it makes sense to you to pass around entire libraries like lodash between apps, but it doesn’t to me. It’s also certainly not how (good) Node.js applications are implemented: they declare their requirements in package.json which then become part of the app project directory. If your app depends on software modules that are hosted externally (which for all intents and purposes, yours are), you’ve created an app structure that makes things (unnecessarily, IMO) difficult.
External resources may, or may not, exist at the time you need them. Apps should be able to deal with that. If your devices depend on external resources, let them wait for them to become available before they set themselves available. That’s a very common method of implementing devices on Homey, and not different from any other app that depends on an external API or physical device to become available before it can continue to run the device implementation.
App lifecycle on Homey is different from “normal” apps, which is something you have to deal with. When onInit() is called, the app has already started and regular requirements have already loaded (if you just bundled lodash or whatever libraries you depend on with your app, you wouldn’t have had this issue in the first place). If you need to wait for external resources to become available, do it outside of onInit(). If your app can’t deal with that, change its structure so it can. It’s not difficult, I had to do the same with HomeKitty.
Please get it straigth: is it normal or not?
