My Vera stopped activating my LIFX notifications

My Vera stopped activating my LIFX notifications (pulse/breathe) last week. Is this related? I’m seriously bummed over this since I have a number of events set up that require these notifications relating to security.

Are there any logs from the Vera, that you can give us to help us isolate the issue? Have you contacted Vera about this issue?

I’m working with someone on the Vera forum, but as far as I know nothing has changed in the scripts of the plugin. My hardware setup hasn’t changed. That is why I was asking about the possibility of the TLS update disrupting things, since the Universal Devices ISY-99 and the Vera are similar devices.
My logs have given me nothing useful as far as I can tell.

Can you link me to the thread in the Vera forum?

I certainly would, but I’ve been private messaging one of the plugin developers in order to determine what the cause is.
All I see in my log when trying to execute a “scene” with a script for my LIFX devices is:

LuaInterface::CallFunction_Scene Scene  22 failed [string "--[[ json.lua..."]:155: attempt to get length of local 'str' (a nil value) <0x7338f520>

I’m not a programmer, but it looks like the script has failed to populate a table or variable. Anything could be the cause, no?

The two threads pertaining to the LIFX plugin are:



It does look like something has failed earlier in the script and its crashing later in the script. Possibly because there was no error checking done at the failure point. Don’t worry, this in common in scripting languages like Python and Lua.

Is there any chance you have the Lua script that you are using? Could you ask the developer to send me a copy?

Both original developers are AWOL. Here is the main script ( lifx_ctrl.lua):

local ltn12 = require ("ltn12")
	local https = require ("ssl.https")
	local json =  require ("lifx_ctrl_json") 
	local auth =  require ("lifx_ctrl_auth")
	-- changed name from json.lua to lifx_ctrl_json.json so not to conflict w/ same file name in U17
	-- using json lib from	slightly modified for Vera				   
function lifx_ctrl(selector, mode, color, bright, cycles, period)
	https.TIMEOUT = 5
	--local selcolor = '"#ffffff"' -- white
	local resp = {}
	local payload = ''
	local selmethod, selurl, key, value, stat, power, connected, err
	local token = auth.getToken()

	-- Default values
	color = color or "#00ff00" -- if color nil or false then use green at brightest
	bright = bright or .2  -- if bright nil or false then use .2
	period = period or 1  -- if period nil or false then use 1
	cycles = cycles or 1  -- if period nil or false then use 1
	if mode == "pulse" then
		selmethod = "POST"
		selurl = "" .. selector .. "/effects/pulse"
		payload = '{"cycles": ' .. cycles .. ', "power_on": true, "persist": false, "color": "'
					.. color .. '", "period": ' .. period .. '}'
	elseif mode == "breathe" then
		selmethod = "POST"
		selurl = "" .. selector .. "/effects/breathe"
		payload = '{"cycles": ' .. cycles .. ', "power_on": true, "persist": false, "color": "'
					.. color .. '", "period": ' .. period .. '}'	
	elseif mode == "on" then
		selmethod = "PUT"
		selurl = "" .. selector .. "/state"
		payload = '{"power": "on", "color": "' .. color .. '", "brightness": ' .. bright .. '}'
	elseif mode == "off" then
		selmethod = "PUT"
		selurl = "" .. selector .. "/state"
		payload = '{"power": "off"}'
	elseif mode == "toggle" then
		selmethod = "POST"
		selurl = "" .. selector .. "/toggle"
		payload = ''
	elseif mode == "list" then
		selmethod = "GET"
		selurl = "" .. selector
		payload = ''
	elseif mode == "scene" then
		selmethod = "PUT"
		selurl = "" .. selector .. "/activate"
		payload = '{"duration":"'.. period ..'"}'
	local result, statuscode, response_body, status = https.request {
		url = selurl,
		method = selmethod,
		headers = {
				   ["Authorization"] = "Bearer " .. token,
				   ["Content-Type"] = "application/json",
				   ["Content-Length"] = payload:len() },
		source = ltn12.source.string(payload),
		sink = ltn12.sink.table(resp)
	local jsondata = json.parse(resp[1])  --resp is a table where resp[1] is string containing json
	key, value = pairs(jsondata)
	if type(value["results"]) == "table" then 
		jsondata = jsondata.results[1]
	elseif type(value[1]) == "table" then 
		jsondata = jsondata[1]
	for key, value in pairs(jsondata) do
		--print(key, value)
		if key == "power" then
			power = value
		elseif key == "connected" then
			connected = value
		elseif key == "status" then
			stat = value
		elseif key == "error" then
			err = value
	luup.log("lifx: " .. resp[1])

	return stat, power, connected, err, resp[1]

	local data = resp[1]
	print (string.find(data, '"status":"ok"'))

	print (data)
	print ('statuscode: ', statuscode)
	print ('result: ', result)

	print('status: ', status)

	for k, v in pairs(response_body) do
	   print(k, v)


There is also a lifx_ctrl_json.lua file as well, if you need that, too. The explanation commented out at the beginning of the file:

Because the Lua nil value cannot be a key, and as a table value is considerd
equivalent to a missing key, there is no way to express the json "null" value in
a Lua table. The only way this will output "null" is if your entire input obj is
nil itself.

An empty Lua table, {}, could be considered either a json object or array -
it's an ambiguous edge case. We choose to treat this as an object as it is the
more general type.

To be clear, none of the above considerations is a limitation of this code.
Rather, it is what we get when we completely observe the json specification for
as arbitrary a Lua object as json is capable of expressing.

## json.parse:

This function parses json, with the exception that it does not pay attention to
\u-escaped unicode code points in strings.

It is difficult for Lua to return null as a value. In order to prevent the loss
of keys with a null value in a json string, this function uses the one-off
table value json.null (which is just an empty table) to indicate null values.
This way you can check if a value is null with the conditional
`val == json.null`.

If you have control over the data and are using Lua, I would recommend just
avoiding null values in your data to begin with.

json lib from changed
the name to avoid conflicts and changed the module syntax, Majimus

Okay, so since you are talking to the Vera developers. Could you get me the version of Lua, and OpenSSL on the Vera. Then if possible a list of SSL ciphers that the Vera supports.

If you think its related to the Universal Devices issue this will help.

The code looks … hacky, but I guess it should work. I’ll see if I can test it here later today.

If you have a shell on the device (I just thought of this because some of the posts allude to scp’ing files to the device.) you should be able to run the following commands to get those details:

lua -v
openssl version
openssl ciphers

I’ll need the output from those three separate commands.

I’m only working with a plugin developer that seems to know the platform extensively. He is not the creator of the LIFX plugin, but he knows his stuff. I will ask him if he can help with those items. I tried plugging the Lua commands into a Vera scene and got nothing in the log, and tried testing them in the “test Lua” box as well, but there is no area for output there. I’ll get back to you once I hear back from him.

Received a reply.
Lua 5.1, OpenSSL 1.0.1l. It supports SSLv2, v3, TLSv1, 1.1, 1.2.
– but he thinks that it’s the modified JSON library included with the plugin and a couple of errors in the main LIFX plugin script.
It beats the hell outta me why this suddenly started acting up the other week when I’ve been using it reliably for many months already. Have there been no changes aside from the TLS version that could be the cause? If it’s nothing on your side, I’m thinking maybe my Vera has some corrupted data or something.

I can’t pinpoint any changes that may have caused this on our end. There have actually been very few changes to the API in the last few months. The main one was the TLS update we did for security reasons.

We still support TLS1.2 from that list, so provided we both support some ciphers in common it should work fine. I expected the cipher list to look more like this (from my laptop):

[daniel@triboluminescense ~]$ openssl ciphers

Also you might want to update your Vera if there are updates available. According to OpenSSL version 1.0.1 is no longer supported.

Thanks Daniel,
I’ve been short on patience since I’ve had many points of failure in my system lately, even though it was functioning (almost) perfectly for months. I’m getting a little tired of fixing stuff that I’ve already taken weeks or months of my time to set up, but I’m sure you can relate.
I am really not knowledgeable when it comes to cryptography. The company that spawned Vera is now under new ownership (for the last ~6 months, I think?). Perhaps it would be in your best interest (and theirs) if you had a developer contact them so you guys could work in unison to put out a plugin. Their primary focus is Zwave – a direct competitor to you guys – but they are not concerned about boosting Zwave as far as I can tell and only hope to build a versatile home automation device.
I’m still putzing around with this thing, but my contact on the Vera board has been extremely helpful and I think he’s making headway. I’ll keep you posted.