Use this forum to discuss possible implementation of a new feature before opening a ticket.
A developer shall edit the topic title with "[xxx]" where xxx is the id of the accompanying tracker id.
Duplicate posts about the same id. +1 posts are not allowed.
I have a question which I could not find answers to on the forum. According to url you can have:
SerialPort - used by ‘serial’ transport
Address - used by non-serial transports
Port - used by non-serial transports
Mode1 - General purpose
Mode2 - General purpose
Mode3 - General purpose
Mode4 - General purpose
Mode5 - General purpose
Mode6 - General purpose
Username - Username for authentication
Password - Password for authentication
I have tried to add an extra <param>. On the web page of the plugin, it is shown. But with the use of the <param> I get an error. 'onConnect' failed 'NameError':'name 'Mode7' is not defined'.
Would it be possible to bump the number of modes from 6 to say 10, I think this change could be done pretty quickly be someone ho knows the codebase of domoticz.
IMHO, there is no end to it. Let's say it is increased to Mode10, someone, sometime will come up saying i need Mode15. So there are 2 solutions; either the domoticz code should be enhanced so that it would take as many mode parameters as you want (I am sure that would create some other problems), or you could either use the User Variables or an .ini file (txt file) which you could add all your extra parameters as much as you want. I generally go for the .ini file, since there is no native access to user variables in plugins, you should use urllib for that. As again, that is my humble opinion...
In this respect, Plugins have been a victim of their own success. I didn't envisage them being used to integrate hardware requiring a lot of parameters so just used the existing column in the hardware table. With hindsight that was not such a good idea
Options:
Add extra columns: Easy to do but just pushing the problem out until next time someone wants/needs more
User Variables: Not what they were designed for and doesn't solve the issue of configuration through the web interface
Ini file: Doesn't solve the issue of configuration through the web interface and not stored in database so system restoration is messy
Make web UI return JSON parameter blob to plugin to store how it likes: would require the plugin to be running so wouldn't work the 1st time
Extend XML and web UI to support 'sub-params' or 'complex-params' tags inside (or alongside) the existing <param> tag that are encoded as JSON blobs containing multiple values that are stored in existing database columns: Probably my favorite:
Backwards compatible
Stored in database
No changes to data model
No hard coded maximum number of parameters
Easy to do and change is contained to just the web UI (although plugins would needs to unpack the JSON)
Needs a bit of thought to get the data model right
The reasonable man adapts himself to the world; the unreasonable one persists to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw
Dnpwwo wrote: ↑Wednesday 13 March 2019 7:30
[*]Extend XML and web UI to support 'sub-params' or 'complex-params' tags inside (or alongside) the existing <param> tag that are encoded as JSON blobs containing multiple values that are stored in existing database columns: Probably my favorite:
Backwards compatible
Stored in database
No changes to data model
No hard coded maximum number of parameters
Easy to do and change is contained to just the web UI (although plugins would needs to unpack the JSON)
[/list]Needs a bit of thought to get the data model right
I really like that approach... willing to contribute to testing with my Smart Virtual Thermostat plugin for which I had to pack many parameters into a few csv strings... definitely not user friendly.