Vera Control : the wish list of a developer

Dear Vera Control, Ltd,

I’m a user of the Vera since several years, and I develop regularly scripts and plugins.
There are some limitations that are annoying.

So, here is my wish list :

1/ Managing http POST request in handlers.

Handler is a great feature to exchange structured information, as a webservice.
But the problem is that it does not support POST request… worst this kind of request is making the Vera crash.
So for exchanging lots of information, there’s just the upload of file, which is not very convenient.

2/ Make functions luup.xxx able to manage functions and not just name of functions.

The luup functions (e.g. luup.call_delay, luup.variable_watch, …), that take a callback as parameter, just accept string (name of the function).
It implies that this name has to be in the global namespace.
When you have a lot of methods that you want to regroup in a namespace, it raises a problem.
One solution is to make a fake namespace in global namespace :

_G["RulesEngine.Event.onDeviceVariableIsUpdated"] = Event.onDeviceVariableIsUpdated

This is not really elegant.

3/ Be able to stop a watch or a timer.

When you set a watch with luup.variable_watch, or set a timer, you can’t cancel it.
The only way is to restart the luup engine. It’s surely the reason of these so many luup reloading when adding or updating a device or a scene.

4/ Change unicity rule and add an alias for a device.

To identify a device, you have its id, name (description) and room.
As user, it’s simplier to use a common name in the UI (e.g. “main light”) and use it with the room (e.g. in voice recognition “main light in the living room”). As the description must be unique in the system, it can raise a problem with some devices (e.g. “main light” in a guest room and “main light” in living room).

4.1/ an unicicity rule using the description AND the room could resolve this issue.
4.2/ remove the limit of 20 characters in description

When you want to handle devices outside of the Vera, in an event collector by example, it’s more simplier to use a synthetic description and/or the id (e.g. “LivingRoom_MainLight” instead of an id that could change with an upgrade of the Vera or of the device).
This description is not compatible with the “human-readable” description in the UI.

4.3/ Adding a new field “alias” could resolve this issue.

1/ Managing http POST request in handlers.

Handler is a great feature to exchange structured information, as a webservice.
But the problem is that it does not support POST request… worst this kind of request is making the Vera crash.
So for exchanging lots of information, there’s just the upload of file, which is not very convenient.


This (the crash with a post) is supposed to be fixed in the next release.
Currently you need to use a UPNP SOAP message to post large amounts of data. That’s how LUA code is handled in Vera.

[quote=“RichardTSchaefer, post:2, topic:191405”]

1/ Managing http POST request in handlers.

Handler is a great feature to exchange structured information, as a webservice.
But the problem is that it does not support POST request… worst this kind of request is making the Vera crash.
So for exchanging lots of information, there’s just the upload of file, which is not very convenient.


This (the crash with a post) is supposed to be fixed in the next release.
Currently you need to use a UPNP SOAP message to post large amounts of data. That’s how LUA code is handled in Vera.[/quote]

Great news ! Do you mean that the crash will be resolved or that the POST request will be correctly handled ?

EDIT:
Have you some examples about this UPNP SOAP message ?

ModifyUserData requests use SOAP. Documented here http://wiki.micasaverde.com/index.php/ModifyUserData.

OK, thanks !

I’ve found the function “runUpnpCodeDataRequest” in the UI7 that seems to do that.
But I’m not sure that I can send data to a plugin by this way, as the execution environments are surely not the same.
I will try

It won’t work for openLuup!

:), yes but with openLuup, I have no fear ! I know that POST request with handler will be possible

Great news ! Do you mean that the crash will be resolved or that the POST request will be correctly handled ?

My hope is both … I gave them a simple one line test case for both the SOAP and REQUEST model as a test case.
They know my intention is to SEND a LARGE amount of data and need the POST request to handle this.

I have the same need for ALTUI. ALTUI does implement the ModifyUserData soap request and it did work ( you can still find it in the source code ) but I reverted back to http GETs for openluup compatibility. that presents the lengths problem on many things ( scene, or even saving the custom pages data structures ) so I do vote for the POST for handlers and even if possible for VERA http requests to support ( PUT DELETE ) to get some restfull api to do CRUD operations on device/scene/rooms etc