The best solution is to get the device type using this request:
http://wiki.micasaverde.com/index.php/Luup_Requests#finddevice
[tt]finddevice[/tt] was updated by Aaron specifically for this purpose.
It is not good solution for us. This will slow down connection very much. Fast connection is for us priority.
Chixxi if You can please put to lu_sdata any unique variable that can be identify by our app. Thats how we recognize apps like google weather. Can You do this? You can put some variable in altid as mcvflorin said.
This will not slow down the connection. You only need to do this once and for any new device that gets added. As a developer your solution is more a hack and should not have to force the developer to add something to distinguish their plugin when you can retrieve the device type via the api command. Again this only needs to be done on the initial loading of the Vera data and no more. If a user adds a new device, you can call the api to get the device type.
- Garrett
Garret i really dont know what is the problem with altid for You. Belive me it will slow down the app in some cases and will make some troubles. I know how our connection engine works.
Especially it will slow down app with changing server. After change server You must send several dozen of requests. When You are on remote connection it will take really lot of time.
Secondly there are situations when You are changing device type file. What about then? Option in app to refresh device types? No. It must work full automatically.
I think the best solution for this problem is to reserve about 3 categories as plugins eg. 44,45,46 are plugins and recognize them by subcategory. But Mcvflorin said than there can be problems. So altid is also good solution. Especially that altid is send always anyway. So what is the problem. This is not a hack. This is what for these variables are (i think. if not, mcvflorin please correct me)
[quote=“zhouse, post:44, topic:171883”]Garret i really dont know what is the problem with altid for You. Belive me it will slow down the app in some cases and will make some troubles. I know how our connection engine works.
Especially it will slow down app with changing server. After change server You must send several dozen of requests. When You are on remote connection it will take really lot of time.
Secondly there are situations when You are changing device type file. What about then? Option in app to refresh device types? No. It must work full automatically.
I think the best solution for this problem is to reserve about 3 categories as plugins eg. 44,45,46 are plugins and recognize them by subcategory. But Mcvflorin said than there can be problems. So altid is also good solution. Especially that altid is send always anyway. So what is the problem. This is not a hack. This is what for these variables are (i think. if not, mcvflorin please correct me)[/quote]
I do not know how you developed the app to retrieve and store the data. I am not sure if you are misunderstanding how I get the device data. The device data is not retrieved all of the time. It is only retrieved once when first configuring the app. It does not issue the api call any other time when updating the data. However, if a new device or plugin is added, the device type api call will get called. When parsing the full data, you check to see if the device type is setup, if not you call the device type api to retrieve the data and store it. It will never have to be called again. So the only slowness you will experience is on the initial loading of the data at first run.
You should never have to change the device file type. So that is not an issue. The altid is a bad idea because many 3rd party plugins use this field already. Some examples are DSC alarm panel plugin, Altsteon plugin, Weather Underground plugin, and the list goes on. The altid field gets used for plugins that have child devices.
I have been down this path and worked with MCV on this very issue with my app. I worked with the lead developer of Vera to come up with a solution that we can both agree with. We discussed using the plugin id, but this will not tell you what type of device controls to use if the plugin has child devices with different device types. I asked to have the device type added to the lu_sdata, but they turned that down to to increasing the size of the data. It all came down to using the finddevice api. Yes, it causes x number of additional requests, but only on the initial setup of the app and the vera unit. So that compromise is a small price to pay.
- Garrett
Garett i understand… really. I told You that it is NOT good solution for us. Really. And we will NOT apply this solution for our app. Please read what i said before.
I understand that U r using this solution and it is good for You, but not for us.
And we cannot take this “compromise”. App must be fast as it can.
@zhouse,
I’ve read through this conversation, and Garrett is correct. Everything else is a hack, and something that has a likelihood of breaking in a future release of MiOS.
Garrett’s suggestion is merely to call, out of band, to get the additional supporting metadata when you first see a new device. This can then be cached to a persistent store, within in the device, so that no subsequent calls need ever be done, ever.
For example, both SQRemote and AutHomation both have similar caches. Although they’re done differently, the caching/intent is the same - not forcing plugin changes, not utilizing something that’ll break in future MiOS releases, and to maintain overall performance with minimal first-time-only impact to the user. I’m sure a number of the other control points are doing the same thing.
Seems like a reasonable internal architecture to have, no?
Fast and NOT functional will get your app removed from a phone.
Messing with properties that can have negative side effects to apps using the properties as intended will get folks to avoid your app like the plague for all eternity.
As a plugin writer I am unlikely to change things to support a remote app.
There are too many out there to allow this type of coupling.
Not to mention that it violates a fundamental design principal.
If you present a use case for new functionality for an end user that’s a different story.