|Re: Asynchroneous ThingHandler initialization [message #1759382 is a reply to message #1759332]
||Tue, 11 April 2017 07:20
| Simon Kaufmann
Registered: January 2011
Is it OK for the ThingHandler.initialize() method to just create a scheduler task that will take care of the initialization and return control to the framework immediately without waiting ?
It's not just okay, it is actually the perfect way of doing it (unless you can determine the status immediately).
You just have to guarantee that you eventually set one of ONLINE/OFFLINE/UNKNOWN status, otherwise the Thing will remain in INITIALIZING forever and you will not be able to use it. There are cases where you cannot actively communicate with your device (e.g. a door/window contact running on low power, only waking up by itself every four hours), but you still want to signal that you are ready to used it from a ThingHandler's perspective. In that case it would make sense to set it to UNKNOWN and wait for the first real successful communication until you set it to ONLINE.
Is it OK for the task to keep trying to initialize at fixed interval until initialization is successfull ?
With some devices you simply have no other choice. However, you should distinguish if it is really the ThingHandler which is not initialized, or the communication to the device which simply cannot be established. In the later case you might want to simply set the Thing status to OFFLINE with COMMUNICATION_ERROR or CONFIGURATION_ERROR. So if you have everything you need and simply have to retry a couple of time, it sounds like OFFLINE is the right thing to do. If the device is simply slow and it takes a while to set up the connection and exchange all the parameters, then it fully makes sense to not set a status at all until you are finished. But again: You must GUARANTEE that eventually SOME status will be set!
In general, is it much preferable to schedule a recurring task rather than a looping one-time task and sleep the thread between cycles?
Yes, please use a recurring task. Threads are (rather) expensive and blocking them just for sleeping is not a nice thing to do resource wise. That's what we have the schedulers for.
Powered by FUDForum
. Page generated in 0.01476 seconds