implement suspend/resume for plugins about smarthome HOT 8 CLOSED

Any plugin may itself decide what to do and what not. In general being suspendend should mean "do not take action towards any item or logic but keep an eye on what's going on and care for internal records"

from smarthome.

One assumption in the feature request is false. The plugin thread is neither started by run() nor killed by stop().

run() and stop() should only tell the plugin to start or end processing.

All plugin threads are started before the run() method of the first plugin is called. The thread of a plugin is stopped only, when the unload_plugin() method in lib.plugin is called with the config-name of the plugin as a parameter or when SmartHomeNG is terminating.

from smarthome.

@bmxp: so if a suspended plugin receives a message, e.g. knx receives a telegram setting 1/3/4 from 0 to 1, it should not change any associated items. After resuming, the internal cache of the plugin might be updated (if present), but the state of any associated item is ... compromised; restarting shng with cache or database enabled might then cause switch actions to be sent to the knx network.

To be honest, stopping the plugin and restarting it later will have more or less the same effect...

resp. your russound example: you would have to implement a plugin-internal (item) cache to store all "suspended data" occurrences and "replay" this later. Implementing this might be relatively easy, but replaying all missed changes in rapid succession might even have more severe consequences....

I understand the idea to stop plugins from querying (thus creating errors for non-connected devices).

This might easily be circumvented by a simple member variable besides self.alive, e.g. self.active. This, set to False, could prevent / skip any network requests. That would leave open the question on how to set/unset it. Accessing it via the webif everytime I switch on/off my AV receiver seems unpractical.

Possibly the plugin could check for a "control item" (fixed item path or configured via plugin.yaml), and before each (network) action it queries the item, just like self.active in the previous example.

from smarthome.

(esp. at @bmxp ) If the actual functionality is described, i.e.

• what may the plugin do in suspended
• what must it not do in suspended
• how should it behave in not explicitly specified situations (e.g., "default behaviour")

I could implement this for the smartplugin class, trying to find a way to make it "not break" anything (at least too much ;) ).

Switching would be via a class member, optionally you could set an item via plugin function or plugin config which works as a switch (see previous comment).

But frankly, as I don't see added value, I will not invest if the requirements are not described in detail :)

from smarthome.

Im sdp als umfangreichem Framework ist das mittlerweile enthalten und nutzbar, steuerbar über ein Item. Suspend (dort: "standby") heißt, dass die (Netzwerk)Verbindungen geschlossen werden und beim Verlassen des Standby wieder geöffnet.

Für das "reguläre" SmartPlugin ist eine generische Implementation in der Plugin-Klasse wenig hilfreich, da die meisten Methoden, die angepasst werden müssen (init, run, send, connect usw), alle nicht existieren und erst vom Plugin-Autor geschrieben werden. Insofern müsste der jeweilige Plugin-Autor das im jeweiligen Code selbst implementieren. Aus dem gleichen Grund ist auch der (schon begonnene...) Versuch, das im Core abzubilden, hinfällig. Ein "hartes" stop/start ist bei restartable-Plugins relativ problemlos.

Vielleicht kann sdp dort als Vorlage bzw. Anregung dienen.

@bmxp Hilft dir das? Brauchst du noch weitere Infos oder Sonstiges? Ansonsten würde ich empfehlen, das hier zu schließen.

from smarthome.

Naja ich bin schon der Meinung das Suspend und Resume Funktionen auch im Smartplugin sinnvoll sind. Sie müssen ja nicht implementiert werden sondern können als pure Funktionen dienen. Aber mit der Sicherheit das sie für jedes Plugin aufgerufen werden können. Da ich aktuell aber keine Zeit für solche Arbeit sehe würde ich das auf eine zukünftige Version verschieben und in der Zwischenzeit für das Plugin was es betreffen würde einfach was implementieren wenn wieder etwas Luft ist

from smarthome.

Ich sage nicht, dass es nicht sinnvoll wäre. Man kann die API (zwei Funktionen und eine Variable) in smartplugin.py einbauen - aber die eigentliche Implementierung muss für jedes Plugin einzeln und jedesmal von Neuem erfolgen.

Mindestens run, connect, send und update_item müssen angepasst werden, wenn das funktionieren soll, und die schreibt der Plugin_Autor selber.

Wenn ich die Idee ablehnen würde, hätte ich es ja nicht implementiert 😉

Du wolltest das für knx, richtig? Es soll ja weiter "lauschen" (was für mich weniger "suspend", sondern eher "mute" oder "restrict" wäre). Was passiert mit den Daten, die in der Zeit

• vom Device
• von Items (über update_item)
  Reinkommen?
• Loggen? Machbar
• Verwerfen? Dann könnte das Plugin auch angehalten sein (?)
• Zwischenspeichern? Dann müsste man danach eine Art "replay" machen - schlimmstenfalls die Rollos zigmal hoch- und runterfahren?

Im sdp habe ich das .. "radikal" umgesetzt: die Netzwerkverbindung wird getrennt oder - wenn sie noch nicht zustande gekommen ist - nicht aufgebaut. Item-Änderungen werden geloggt und ignoriert. Es ist simpler als stop/run, aber vergleichbar.

Wie gesagt: wenn ich verstehe, was du erreichen willst, versuche ich es umzusetzen 😉

from smarthome.

Für das knx nicht, das war das Russound Plugin

from smarthome.