delay plugin startup about smarthome HOT 9 CLOSED

Ich vermute es liegt daran, dass das Plugin in der Startphase geladen wird und die
WMZ auslesen will

Wenn das nur eine Vermutung ist, weiss ich nicht ob wir sowas implementieren sollen. Klar wenn jemand Zeit und Lust hat, kann man das gerne mal tun. Um zu pruefen ob das tatsaechlich ein Problem ist, koennte man temporaer auch in das entsprechende Plugin eine Verzoegerung mal einbauen und damit erstmal testen. Damit waere dann sichergestellt, dass das auch etwas bringt.

Ich habe auch ein USB-Device, was ab und an mal nicht mehr funktioniert (aber ziemlich selten). Loesen laesst sich das auch nur mit aus- und wieder einstecken. Ich vermute aber, dass es nicht am Neustart liegt, sondern eher am Device oder den Treibern selber, die sich in irgendeiner Konstallaktion "verhaken" und dann einen "Reset" brauchen. Daher die Befuerchtung, dass die Verzoegerung nicht helfen wird.

from smarthome.

There is already the possibility to give the scheduler an offset. What needs to be done within each plugin is to put an offset in the plugin configuration and when scheduling the first query or interaction, we can pass the offset to the scheduler.

from smarthome.

So this is more a "first cycle update delay" for the mentioned plugin and not a general feature to delay the whole plugin startup (delay the start of a plugin thread).

I guess @cstrassburg thought about to have a general solution to delay the whole plugin startup instead of doing a delay within the plugin implementation when adding scheduler tasks. But the latter could also "solve" the problem from the reporter.

But: @cstrassburg did you checked if a delay really solve your problem?

from smarthome.

For me it looks like the solution could be implemented in the run method of the plugin that has this problem.

instead of setting self.alive = True instantly, start a scheduler, that calls a methond run2 which then sets self.alive = True.

from smarthome.

The feature request was created based upon an assumption which could completely be wrong. It's still not verified that the root cause is the system load. So I suggest to close this feature request if no body else requires such a plugin startup delay.

from smarthome.

The suggestion of @msinn makes sense to me. As @cstrassburg will be able to implement this by himself if he has some time again I will close this issue now and we can reawake it if needed later on.

from smarthome.

@bmxp will he?

from smarthome.

Nope. @msinn favours a solution within the core, not the plugins.

from smarthome.

And we should define the use-case more precise.

If you want a delay to startup different instances of a plugin to different times so message don't collide on the serial bus both instances share (eg. RS485), it might not be a good idea. On startup the collision is avoided, but it will hit during the runtime.

If you need a delay to ensure some other software or hardware has to become ready first, a delay might be a good idea. To get some control if the initialization is done, it should not be done in the plugins but it should be controlled by lib.plugin.

from smarthome.