Random idea: GUI mapping/management of aliases to device IDs

Developer's Corner General Dev Discussions
1

I was reading a request for PLEG to incorporate an import and export feature for logic to help users share stuff.

That got me thinking about sharing of stuff in general, since code is tied to device ID’s, and complex pieces of code that aren’t plugins where you can define stuff could be a pain to change to match your system.

Too bad there is no way to create an alias in Vera to reference devices by an arbitrary user assigned name instead of the vera assigned device ID’s. For example, you have:

Device type
12 On/Off switch
34 Dimmer
56 MIMOLite

You would have:

Device Alias Type
12 LivingRoomSwitchA On/Off switch
34 KitchenIsland Dimmer
56 GarageDoor1 MIMOLite

It would be nice to have a way to map an alias to these ID’s so that they are easier to manage. Then, instead of using the device ID’s in LUUP, you could use the alias.

Now, I know you could edit the LUUP Startup area and define some variables as static devices there for use, but the average user probably won’t know how or want to mess with this. Something like:

gLivingRoomLight = 12
gKitchenDimmer = 34
gGarageSwtich = 54

Then reference them in your LUUP code, but a way to do this in the GUI and have the Vera do the mappings of IDs to Aliases would help better for something like this. Plus, when you kill the device, the alias will go away with it. Might create hell when the system can’t find an alias associated with a now deleted plugin, but I guess you could always make it give an alert for that in the status area and log.

So, if this was implemented at the GUI level, instead of what you have now (without static defines elsewhere):

local keyPad = luup.variable_get(RNET_SID, "KeyPad", 82)

You would have:

local keyPad = luup.variable_get(RNET_SID, "KeyPad", LivingRoomKeyPad)

Then, if you had a piece of code that was exported, say from the PL series of plugins, or anything else, you could just replace the aliases instead of trying to hunt down device ID’s. Or, if the system allowed multiple aliases to be defined for a device, you could just define another alias (at the risk of adding more complexity and making trouble for yourself later).

Of course, there would have to be some standard defined for device naming if things were ever exported, making it easier to identify a device, such as a light switch from a dimmer (names like s443 and d45 would not make any sense unless you knew what they were)

Or this could just make the Vera too complex, 100 % unstable and just a glorified (and expensive) paperweight.

(It’s just a thought).

2

It’s pretty easy to generate a reverse lookup table to map between ID and device name, see [url=http://forum.micasaverde.com/index.php/topic,14743.msg111814.html#msg111814]http://forum.micasaverde.com/index.php/topic,14743.msg111814.html#msg111814[/url]

Or combine with this object-oriented approach [url=http://forum.micasaverde.com/index.php/topic,15138.msg115045.html#msg115045]http://forum.micasaverde.com/index.php/topic,15138.msg115045.html#msg115045[/url]

Of course, this only works at the Luup level, not the GUI.

3

Thanks.

This is just a random idea that I had. Since some people look at LUUP code and run away, I was just thinking of a way that might help those less technically inclined to play with the such things.

I know that when I started making plugins, the initial learning curve was steep (documentation is more of a code hacker style how-to that is found in various places, and the real kicker was lack of experience with Lua).

4

Lua is a beautiful language, simple syntax, but rather subtle semantics. Investing in a copy of the third edition of “Programming in Lua” will pay dividends. Then it’s just a matter of mastering the API which is Luup…

…and navigating around the Vera implementation bugs.

5

Programming in Lua is an excellent way to learn the subtleties of Lua which, as you say, is a beautiful language. It’s a shame that there isn’t a book to help navigate the minefield of “…Vera implementation bugs.”

Still, if it was too easy you wouldn’t get the satisfaction of beating it into submission. ;D

6

[quote=“RexBeckett, post:5, topic:176249”]Programming in Lua is an excellent way to learn the subtleties of Lua which, as you say, is a beautiful language. It’s a shame that there isn’t a book to help navigate the minefield of “…Vera implementation bugs.”

Still, if it was too easy you wouldn’t get the satisfaction of beating it into submission. ;D[/quote]

I picked that up when I started playing with Lua for making plugins.

You are right, too bad there isn’t a book on the implementation bugs and tips and trick compiled for helping you beat it into submission.

The wiki has potential, but seems to have degenerated into the same state as most wikis – a general mess.

Ap15e seems to have done some awesome things with the Vera, too bad he pulled out and locked his code away making unavailable to new people just coming to the platform. Although I did find one obscure piece of code for a plugin he published that is still available and shared via Google drive like all his other stuff – it was for a USB based CO2/VOC sensor. You can also find it on the wiki here: http://wiki.micasaverde.com/index.php/CO2_Sensor

(Interesting how the wiki’s history page shows that Ap15e modified the wiki page on 2 March 2013)

7
(Interesting how the wiki's history page shows that Ap15e modified the wiki page on 2 March 2013)
Ap15e is still very much alive - he just doesn't post anymore. It's a real shame as he had figured-out how most of the tricky stuff works.
8

my fault sorry :slight_smile:
its for the powernode i send him. he is busy with his private life and has as such not much time left to do stuff here. ill talk to him, see if he’s willing to do some stuff. dont pin me on this pls.

9

[quote=“Da_JoJo, post:8, topic:176249”]my fault sorry :slight_smile:
its for the powernode i send him. he is busy with his private life and has as such not much time left to do stuff here. ill talk to him, see if he’s willing to do some stuff. dont pin me on this pls.[/quote]

We won’t.

From reading his last post, it sounded like he had (has?) high hopes for the system, just got tired of hitting the proverbial wall (bugs) too many times trying to do things that should be possible but isn’t without workarounds.

I can see why someone who is exploring the darker corners of the Vera, hitting its limits, could get frustrated – especially after looking at the bug tracker, or seeing some of the other complaints on this forum about issues that you work around or just ignore.

Too bad MCV doesn’t convert the open parts of their code base and especially those parts of LUUP that are not covered under an NDA (since they interface with Z-wave) into a system where people can download, review, submit patches for fixing bugs and enhancing the functionality of the system.

Then you could go one of two routes:

Either have people who would really like to contribute go buy the $300 Z-Wave SDK off digikey, so they can see the z-wave specific code after it has been confirmed they signed the NDA (and possibly an agreement with MCV).

or

Make stubs for the Z-wave interface code that the unwashed masses could download with everything else, so when they test/hack on the other pieces, their test code doesn’t completely break due to invalid function calls – only a dummy value would be returned.

It would likely accelerate how fast Vera matures as both a hacker friendly and a consumer friendlier device.

10

i agree but this would make it open source and thus rendering the mcv business useless as they need to make some money and are doing that with their device and the signed NDA.
so it would benefit everyone using it but mcv. alas there isnt much that can be changed about this, how fruitfull the external input might be.