Reading level names from selector switch Topic is solved

[jorgh]

Hi all,

I'm trying to find out if it's possible to read the level name associated with the levels of a selector switch. Up till now I've had no success and have not been able to find information on this. In the plugin onCommand, I do get the level value, but I need the corresponding level name.
Does anyone know if this is possible, and how it can be done from a Python plugin?

Kind regards,

Jorg

[oohlaf]

When my pull request is merged, you get access to the Options setting from within the Python plugin system. Have a look at the modified example script. Variable Options is a dict which contains the levelnames.

https://github.com/domoticz/domoticz/pull/1360

[jorgh]

@Oohlaf,

That would definitely solve my issue, I've already tried reading the options setting, but it could not be fetched.
Hope it gets accepted soon, it is a really useful addition, as it allows people to reorder, add, or delete items that can be processed by plugins as they are able to read the content.

Regards,

Jorg

[oohlaf]

Keep in mind that modifying the options after creation is not updated immediately in the webinterface. One needs to reload the page and/or switch to another page and come back. I'm not sure if (and how) a signal is send to the webbrowser to reload the control and if this can be initiated from a plugin.

I'm more or less testing the same functionality in my unreleased Pioneer plugin.

[jorgh]

@Oohlaf,

That should not be an issue in my case. I only want users to be able, to for instance delete inputs they don't use (eg Phono, AM), or reorder them without the plugin getting confused.
I looked at your code, and it seems you've also created some more convenient ways to submit options on device creation. That makes the code more readable. I'll change my plugin code to create the options in this fashion once it's available. I'm currently running a from source compiled Domoticz version from the plugin branch, is it going to be available there too?

Regards,

Jorg

[oohlaf]

That was the whole idea of the pull request. For C++, plugins did not need to base64 encode/decode options as the core already contained convenience methods for it. Now they are reused by the Python plugins also.

About the python branch, that's the playground of Dnpwwo. Up to him to merge it there also. I stopped submitting against his branch and only focus on master.

[Dnpwwo]

@jorgh,

You should be able to switch back to the master branch without losing any functionality. I don't have any outstanding updates in the Python-Plugins branch.