[Solved] "no handler" browser error after upgrading to 1141 on openLuup

martynwendon · January 22, 2016, 5:10pm

Just a heads up I got an “no handler” error after upgrading to 1141 on openLuup - couldn’t see anything wrong in the logs, restarting openLuup didn’t help.

I reverted to 1129 using:

http://IP:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&TracRev=1129

… back up and running fine.

Tried to update to 1141 again and same problem.

Something wrong in 1141 maybe?

Back to 1129 for now

delle · January 22, 2016, 5:16pm

i confirm, same error for me

akbooer · January 22, 2016, 5:18pm

I’m running 1141 on Debian and Mac OS with, apparently, not that problem. A log from someone showing 1129 actually doing the upgrade to 1141 could be diagnostic, as would a log of the subsequent, if abortive, startup of 1141.

What system are you running on?

martynwendon · January 22, 2016, 5:57pm

Here you go, I have to run out now so didn’t have a chance to drill down to a specific log, I just grabbed them all.

Running under an old Debian Lenny VM install at the moment.

tedp · January 22, 2016, 6:14pm

I wish I would have read this thread before upgrading Same for me.

akbooer · January 22, 2016, 6:29pm

Well, so far the logs show that the AltUI startup code is never run, so, indeed, there will be no handler.

Why this is so is harder to establish…

amg0 · January 22, 2016, 6:31pm

1141 changed json , could that be the problem on openluup ?
dkjson.lua for UI7 or json.lua for UI5 is necessary in /usr/lib/lua/

local json = require("dkjson") if (type(json) == "string") then json = require("json") end

akbooer · January 22, 2016, 6:37pm

Yes, I was just viewing the Trac change log between 1129 and 1141, and the JSON change looks to be the biggest thing. Worth changing back? I can live with it not parsing [], I suppose!

tedp · January 22, 2016, 6:38pm

I was able to restore the previous version and things work using: MiOS Apps and clicking on “Install” for v1129 as a holdover until the issue is fixed.

akbooer · January 22, 2016, 6:41pm

So, you’re saying you downgraded a Vera and then copied the files from there??

That shouldn’t be necessary!

amg0 · January 22, 2016, 6:44pm

Unfortunately I do need this for the management of some data structures in json I use. [] is not uncommon. is it a problem for openluup to have these modules loaded ? at least if it used dkjson, we would garantee the same behaviors between Vera & openluup.

tedp · January 22, 2016, 6:48pm

[quote=“akbooer, post:10, topic:190718”]So, you’re saying you downgraded a Vera and then copied the files from there??

That shouldn’t be necessary![/quote]

I just downgraded the altUI plugin to the previous version just to get things working with it.

akbooer · January 22, 2016, 9:20pm

dkjson used to be horrendously slow - would crash Vera if trying to decode all of user_data - that’s really why I wrote my own. Also, mine does pretty-printing, which is why the user_data is readable.

There’s absolutely no problem using dkjson and/or anything else - openLuup has its own, and uses it.

Now I come to think of the, the reason that this seems to be working for me and not for others is that I DO HAVE dkjson on my machines, whereas most others wont.

Could someone with this openLuup problem simply try adding dkjson (attached) to their /etc/cmh-ludl/ directory ?

amg0 · January 22, 2016, 9:44pm

dkjson used to be horrendously slow - would crash Vera if trying to decode all of user_data - that’s really why I wrote my own. Also, mine does pretty-printing, which is why the user_data is readable.

There’s absolutely no problem using dkjson and/or anything else - openLuup has its own, and uses it.

Now I come to think of the, the reason that this seems to be working for me and not for others is that I DO HAVE dkjson on my machines, whereas most others wont.

Could someone with this openLuup problem simply try adding dkjson (attached) to their /etc/cmh-ludl/ directory ?[/quote]
I could try yours if you want… There is a l_altui_json file where I could put it and then it would be part of the package installed and therefore everybody would get it.as long as importing it with a require is possible that could work.

akbooer · January 22, 2016, 10:04pm

Mine is in the openLuup directory, called json.lua.

martynwendon · January 22, 2016, 10:31pm

This sounds like it was on a “real” Vera?

Upgrade works fine with dkjson.lua added to /etc/cmh-ludl

akbooer · January 22, 2016, 10:46pm

Yes, but then it shouldn’t have been a problem?

Upgrade works fine with dkjson.lua added to /etc/cmh-ludl

Yes! I think this is the answer, then.

I’ll add some notes to the install section, and the configuration check, to try and ensure that it’s there. I still need to see why we didn’t get a decent error message, though. Still, I think that’s solved.

akbooer · January 22, 2016, 10:54pm

It turns out that UI7 has dkjson, but UI5 does not, so this is not exclusively an openLuup issue, so may need attention in the AltUI installation, rather than openLuup?

thegazelle · January 22, 2016, 11:11pm

Not sure if this helps or not, but I was able to upgrade to 1141 without issue on openLuup. From what I can tell, I don’t have dkjson, and my files were copied from a UI5 install. I attached a directory listing on the off chance that helps your troubleshooting.

CudaNet · January 22, 2016, 11:13pm

Step 13 of the guide I’ve been providing instructs the user to install dkjson for OpenWRT and I believe I did the same for Ubuntu.

	-- Step [3] 

	> Install dkjson.

	# opkg update
	# opkg install dkjson

	--

Yes, but then it shouldn’t have been a problem?

Upgrade works fine with dkjson.lua added to /etc/cmh-ludl

Yes! I think this is the answer, then.

I’ll add some notes to the install section, and the configuration check, to try and ensure that it’s there. I still need to see why we didn’t get a decent error message, though. Still, I think that’s solved.[/quote]