So now there are two options; 1. Only create very basic plugins which don’t even have their own devicetype, serviceid and servicetype. 2. Ignore compatibility to apps and do some more advanced plugins.
don't know how homebuddy works but it will be interesting to integrate a device scan mecanism if it's possible. So new devices will be discovered.
Automator.app does do this as it seems. The app also works with the virtual switch plugin which has custom devicetypes and serviceid's. It even shows the variables of the variable container plugin.
So what am I supposed to do now? Is it my responsibility to provide plugins which are compatible with apps, or is it the apps developer’s responsibility to provide apps which are compatible with plugins? Did I do bad development because I want a custom icon for a device and add some more features then just a really basic switch?!!
Should we maybe open a new thread since this is concerning compatibility of apps and plugins in general?
[quote=“chixxi, post:1, topic:170412”]So now there are two options; 1. Only create very basic plugins which don’t even have their own devicetype, serviceid and servicetype. 2. Ignore compatibility to apps and do some more advanced plugins.
don't know how homebuddy works but it will be interesting to integrate a device scan mecanism if it's possible. So new devices will be discovered.
Automator.app does do this as it seems. The app also works with the virtual switch plugin which has custom devicetypes and serviceid's. It even shows the variables of the variable container plugin.
So what am I supposed to do now? Is it my responsibility to provide plugins which are compatible with apps, or is it the apps developer’s responsibility to provide apps which are compatible with plugins? Did I do bad development because I want a custom icon for a device and add some more features then just a really basic switch?!!
Should we maybe open a new thread since this is concerning compatibility of apps and plugins in general?[/quote]
Chixxi,
You did nothing wrong as well. You are correct that Automator.app does this and it also requires a lot of work. I followed what was recommended in the wiki docs for 3rd party app development. If that is the case, it would require, the developer of the 3rd party app to add the plugin support (which can be a pain at time, especially if you were to use the lu_sdata direction).
Futzle,
You could use any device type with your custom service type is that correct? This is what I have seen in some of the plugins where they use say binarylight, etc.
Well, this means as for the moment best practice for plugin development would be to not implement any new devicetypes, servicetype or serviceids.
I am glad I didn’t do anything “non-compliant”, but I am not really sure now what to do now. I don’t really want to change back to standard stuff for the virtual switch, but still my superior target is to make as many plugins compatible with as many apps as possible.
How about creating an “official devicetype” list (and of course one for serviceid’s and and servicetypes) where developers could add additional types and services? The app developers could then use this list to implement all these in their apps.
I wonder if you can keep your service type, but change the device type to say maybe a binarylight? And we can see how that works? Nothing wrong with some experimenting! If you want I can test the files for you and see what happens.
Relying on deviceType or category to figure out what a device does is not the best approach, in my opinion. What third party apps should handle is the services that are exposed by the device.
Relying on deviceType or category to figure out what a device does is not the best approach, in my opinion. What third party apps should handle is the services that are exposed by the device.[/quote]
Would you be willing to provide an example? I am just following what is posted in the UI docs of the wiki.
I am really glad that some real developers like you guys show interesst in this topic. I am basically just a hobby programer, thank you!
I am gonna go skiing for 4 days, so I want be able to do any testing, but after that I have time to do some fooling arround. I’ll still be reading the thread.
Maybe we should move this thread, this beacame a very general and important question/topic and maybe we could involve some more of the power users in this forum.
[quote=“chixxi, post:11, topic:170412”]I am really glad that some real developers like you guys show interesst in this topic. I am basically just a hobby programer, thank you!
I am gonna go skiing for 4 days, so I want be able to do any testing, but after that I have time to do some fooling arround. I’ll still be reading the thread.
Maybe we should move this thread, this beacame a very general and important question/topic and maybe we could involve some more of the power users in this forum.[/quote]
Sounds good and have a great/safe trip. My goal is to make sure I can have a good / robust app for android, even though I do not make any money from it, I do gain the satisfaction of the users who are using it.
I’d really like to bring up that topic again since I would very much like to see compatibility in between third party apps and vera plugin’s.
Basically I made up my mind:
With the current setup of vera it is not possible to create plugin’s according to my wishes without implementing my own serviceID’s, therefore I can basically only go ahead and pass that problem on to the third party apps developer’s.
But this is basically means a whole lot of work for these developers as soon as apps.mios.com starts to grow. So it’s a lazy solution for me 8)
Are there any other approaches/ideas? How could we make sure everything is compatible?
[quote=“chixxi, post:13, topic:170412”]I’d really like to bring up that topic again since I would very much like to see compatibility in between third party apps and vera plugin’s.
Basically I made up my mind:
With the current setup of vera it is not possible to create plugin’s according to my wishes without implementing my own serviceID’s, therefore I can basically only go ahead and pass that problem on to the third party apps developer’s.
But this is basically means a whole lot of work for these developers as soon as apps.mios.com starts to grow. So it’s a lazy solution for me 8)
Are there any other approaches/ideas? How could we make sure everything is compatible?[/quote]
Two main things that will help the developers: documenting the services, variables, and interaction of the ui elements with your plugin, and making available a “test” or demo mode for plugins that require third party software/hardware that us devs won’t necessarily have.
Two main things that will help the developers: documenting the services, variables, and interaction of the ui elements with your plugin, and making available a "test" or demo mode for plugins that require third party software/hardware that us devs won't necessarily have.
Good idea. I think it would be nice if apps.mios.com would provide or even demand an option to enter all that data. This would guarantee a standard for the documentation, and I also think it would be a nice place to document. That information would also be nice there for lua coding. Same for the demo mode.
Best Home Automation shopping experience. Shop at Ezlo!
If you want I can test the files for you and see what happens.