Delete a variable?

The Luup extensions page says:

Starting with firmware versions 1.7.1036 (Vera 3 and Vera Lite), 1.7.3917 (Vera Edge), 1.7.3918 (Vera Plus), and 1.7.3919 (Vera Secure), it is possible to delete a variable by setting its value to nil:

luup.variable_set(“urn:upnp-org:serviceId:SwitchPower1”, “Status”, nil, 7)

Does that work for openLuup too? (Or does it even work for Vera?)

[quote=“jswim788, post:1, topic:199745”]The Luup extensions page says:

Starting with firmware versions 1.7.1036 (Vera 3 and Vera Lite), 1.7.3917 (Vera Edge), 1.7.3918 (Vera Plus), and 1.7.3919 (Vera Secure), it is possible to delete a variable by setting its value to nil:

luup.variable_set(“urn:upnp-org:serviceId:SwitchPower1”, “Status”, nil, 7)

Does that work for openLuup too? (Or does it even work for Vera?)[/quote]

I just tried it. It seems to work on 1040 (7.0.27). I cannot seem to get it to work on 3232 (7.0.23) and 963 (7.0.22). So consistent with their statement. I recall it not working on earlier versions as well, so I’ve used another workaround for some time.

on openLuup the variable gets “nil” as the value. :-\

akbooer’s on holiday. I’m sure he’ll be interested in this change when he returns.

I’m back!

Yes, interesting, but it raises a few questions, in particular: what does this do to the variable numbering scheme for the device? For that matter, how many times do you need to do this anyway?

The “safe” way to do this is the way that AltUI implements this… with the ModifyUserData request, renumbering all the remaining variables.

I wasn’t sure that deleting a variable as a side-effect of its value was a great design feature, until I realised that this is exactly the way that Lua treats the nil value! So there’s some consistency, at least.

In the spirit of being Vera-compatible, I can add this to the list, however, following all the talked-of upcoming changes is likely to be a full-time job. There are already a number of luup.xxx() calls which I need to add.

The reason I asked about this is for an energy meter that occasionally loses its connection. The standard display in AltUI shows power and energy very well. But when the meter loses connection, the UI doesn’t know it. So I was thinking of using the DisplayLine1 and Line2 to override the display when the connection is bad. However, since AltUI triggers on the presence or absence of these variables to display them, there is no way for me to get rid of them with openLuup when the connection is restored.

The obvious workaround which I’m doing is to make DisplayLine1 and 2 show the power and energy directly and then switch to the connection failure when there is a problem.

Just curious about this. There may be a better way to indicate a device issue in AltUI than what I’m doing.

Of course. Try luup.set_failure(status, devno) with status = 0 or false for OK, or 1 or 2 or true for not OK.


Edit: This, then, is one of @rigpapa’s classic ‘X-Y problems’ …

[quote=“jswim788, post:6, topic:199745”]The reason I asked about this is for an energy meter that occasionally loses its connection.
[…]
There may be a better way to indicate a device issue in AltUI than what I’m doing.[/quote]

Well it wasn’t the only reason I asked - I’m also generally curious about what can and can’t be done with Lua, luup requests, and openLuup. I should say that I asked both to learn and because I was looking at the problem of status.

luup.set_failure is interesting, but it doesn’t give a place to put a message regarding the failure. I may add it to what I’m doing currently instead of replacing. Thanks!

Sorry. It wasn’t meant as a put-down. I just thought that it was an interesting example. Of course, it’s really good to know what is or isn’t possible. You never know when you might need it.

luup.set_failure is interesting, but it doesn't give a place to put a message regarding the failure. I may add it to what I'm doing currently instead of replacing. Thanks!

It’s also possible, but not yet fully implemented in openLuup, to put a message in the banner message area on the devices page. This is perhaps closer to what you need, but it is a good idea to use set_failure as a quick indicator of which device has an issue. It will be available via the device_message() function…

http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_device_message