Yes, alwAys have. I will try uninstall then reinstall.
Just uninstalled then reinstall. It allows me to login then the app pops a box saying i do not have a license?
Thank you for lowering the price so I could purchase your app! So far, I like the professional look of the UI. It is very clean and functional. Are there any known issues with the camera features? When I click on one of the camera devices, it brings up a “Busy Circle” and nothing shows up. The app will eventually crash giving me the option to send a report. The other items seem to function fine! Overall, I love the layout that you have and I can’t wait to see what else you will be offering!
Thank You 
I dont know why You have busy window. Is it always busa also on remote and local connection? What is Your camera configuration?
For better understanding:
Camer for now takes info from three data: url, streaming and ip. App always trying to launch steraming if it is avilable. So if in Your lu_sdata there is “streaming” variable, then app try to reach streaming video. If “streaming” is not empty there could be second reason: app doesnt get user and password data, so if Your camera is password protected, then app cannot reach streaming.
The best thing to set the camera parameters is to set ip (by DynDNS) parameter with login and password data. So username and data parameters in Vera leave empty and set ip something like this: user:pass@83.57.125.1
This is temporary solution because from my information the camera streaming is not finished by MiCasa yet (i could be wrong). There are some changes. So we waiting to fix this, and make this with programming art.
At this moment U can set DynDNS and set parameters as i written above and all will be work fine. If U have problem to do this, please write me PM with Your lu_sdata file.
Thanks for the explanation of how it works! I’m not worried about it. Sometimes the video feed is there and sometimes it’s not. When it’s not, that is when I get the “send a report” dialog. I’m thinking it has to do with the vera unit and the IP camera and not your application! Everything else is working great and it is very dependable! Thanks for the good work!
Are you still working on the app? Still waiting on the support for the virtual switch and the virtual container. Any information you need? I could provide it…
Yes, we still working. Virtual Switch and Variable Container is now suported but at this moment we testing version 2.0. In this version the app is rebuild so we need some time to tests.
Version 2.0 has its own API, so there is possibility to write own apps, that cooperate with our. Also with it we want to release new app: electric widgets.
For virtual switch and variable container we added to Your plugin <Category_Num> variable, so if You can please add category number 38 for vswitch and 39 for vcontainer.
Oh, very excited to hear this!
So what you are saying is that I should add a variable “category_num” to the plugins and set them to 38/39? Did I get this right?
Yes. This is the files that we was remake.
Can you maybe have a look at this and tell us your opinion about it? http://forum.micasaverde.com/index.php/topic,12444.msg91150.html#msg91150
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.
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
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.
[quote=“garrettwp, post:32, topic:171883”]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[/quote]
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!
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.
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
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.
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
@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!
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