Introducing ZHOUSE HomeControl

[zhouse]

With this there is some problem. App gets data every time it will change. As Garett said with this method it can take long time. So each time when someone want to change vera, must wait for ask every device about its category.

 I think the better way it will be use Category and Subcategory number. This variables are sending with every lu_sdata anyway. So i konw that this is some harder because nobody usues category and subcategory but in long time it will be better to clean this up.

[garrettwp]

Wrong, category and subcategory should be specified by MicasaVerde. We should not be creating our own categories and sub-categories. This is why standards are developed. The new api call data is not retrieved every time a change is made. It is only done on first import of the data and only when a new devices gets added to vera. All other times full or partial refresh updates are very fast.

- Garrett

[guessed]

Garrett is correct.  These are defined by MCV and we simply follow them.  If new ones are required, then the appropriate bug'ing and lobbying are required to get them established.  It's effectively what was done during the standardization effort for Alarm Panels...

If you wanted something more flexible, then looking at the serviceId's implemented would also be viable, if the UI was somehow "composited" from, and it's UI elements bound to, those services... so far though, no-one has done that.

Wrong, category and subcategory should be specified by MicasaVerde. We should not be creating our own categories and sub-categories. This is why standards are developed. The new api call data is not retrieved every time a change is made. It is only done on first import of the data and only when a new devices gets added to vera. All other times full or partial refresh updates are very fast.

- Garrett

[chixxi]

I am not exactly sure what to do now. Are you changing your approach for zhouse?

Or shall I still add the category number as a temporary solution, which is not official and may therefore cause problems later on? I love your app and I would love to see my plugins supported!

[zhouse]

I agree that we should not creating category and subcategory but.... what for they are? In all lu_sdata we get category and subcategory but we should not used this?

Secondlly what for there is option to define category and subcategory when nobody wants to define them?

Or these section are reserved only for actual devices.

I'm waiting what is position of MCV.

[garrettwp]

You'll need to contact MCV if you want to hear their position on this. The category and sub-category numbers in the lu_sdata are for supporting most devices that are not 3rd party plugins with custom device types. So this works well. But when you want to start supporting 3rd party plugins, that changes things. To still use lu_sdata, you'll need to use what I posted in the other thread linked by chixxi.

- Garrett

[mcvflorin]

I don't recommend using categories because it could lead to problems down the line. Use the altid instead. For example the Variable Container plugin could have the altid set to variable_container. And in the ZHouse app you could check if the category is empty, and if it is, check if the altid matches one supported by the app.

[garrettwp]

Problem with the altid is that other plugins use this for child devices etc. So that is not a good solution either for other plugins. I've been down this road, the final solution was to use the device type.

- Garrett

[chixxi]

@mcvflorin and everybody else, thanks for taking part in this discussion.

You know, I guess your discussion is going over my level. But it is not the first time I raise this discussion, in fact I raised a couple of times since I try to get the mighty android app developers to support my plugins.

In fact a plugin variable called "plugin" already exists, but it is not shown in lu_sdata. Would it be an option to add this one to lu_sdata for mcv? Adding this variable would not really increase the size of lu_sdata (since it only exists for plugin devices and it is only a number), it would not be any additional effort for plugin developers, and it would be a definite way to identify plugins/devices for app developers.

I think it is now really time to define kind of a "final solution" to recognize devices. It should be documented in the wiki...

wish you all a nice weekend!

[garrettwp]

This was another option discussed with MCV. It does identify the plugin, but if the plugin has children, how would they no the controls to display?

- Garrett

[mcvflorin]

The best solution is to get the device type using this request:
http://wiki.micasaverde.com/index.php/Luup_Requests#finddevice
finddevice was updated by Aaron specifically for this purpose.

[zhouse]

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.

[garrettwp]

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

[zhouse]

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)

[garrettwp]

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)

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