openLuup - running unmodified plugins on any machine

Hello,

I try to install Release 4 on my Ubuntu server.
When I try http://MyIP:3480/data_request?id=lr_ALTUI_Handler&command=home# I have message No handler

If I try http://MyIP:3480/data_request?id=user_data I have a lots of data from my Vera but it never stop.

Thank you
Ninux

[quote=“ninux, post:141, topic:187412”]I try to install Release 4 on my Ubuntu server.
When I try http://MyIP:3480/data_request?id=lr_ALTUI_Handler&command=home# I have message No handler[/quote]
I suspect that you have not installed the ALTUI plugin modules correctly?

If I try http://MyIP:3480/data_request?id=user_data I have a lots of data from my Vera but it never stop.
It should stop, but it may well be several hundred kilobytes.

If you’re following the installation steps, do the LuaUPnP.log and user_data.json files look right ( like the Appendices in the user guide)?

Akboor - OpenLuup is interesting. Would you be willing to consider a licensed version? If so please reply with a message. mlavelle42

it’s called O P E N

Some ALTUI was missing, now I have not error message, but nothing on page http://myip:3480/data_request?id=lr_ALTUI_Handler&command=home# only page Name VERA AltUI…

http://myip:3480/data_request?id=user_data return all the file correctly.

Does the log file give any insights?

The ALTUI startup is quite extensively reported in the log file, showing several distinct phases and the loading of all the JavaScript files, so at least you should see where it’s getting stuck.

What machine are you running this on?

Just wanted to point that that you can now trigger scenes in openLuup - not because of any update I have made, but because of the fabulous work that @amg0 has done on the latest release of ALTUI. It uses variable watch callbacks to trigger scenes. This is the method I’ve been using in my HA code, but now we have a super interface to make it easy for folk other than developers.

very cool… thanks to you both!

It uses variable watch callbacks to trigger scenes.

Yep that’s what device property inputs to PLEG are … they greatly expand the automation options … no longer limited to pre-defined triggers.

So you have plugins, scenes, and a UI. How long until we can plug in a zwave stick, define our own zwave devices (much in the same way one has to do in OpenHAB) and remove Vera from the equation altogether?

This is coming from a guy that can get PLEG to work, but not without quite a bit of trouble, so I realize my question may (inadvertently) trivialize some really hard underneath-the-covers work to be done. It certainly seems like a worthy goal, though. I’ve been playing with OpwnHAB a bit and editing sitemaps and item files and it all makes sense, but your combined solution is much easier and way more elegant for the somewhat experienced “layman”, in my opinion.

Of course…compliments to both akbooer and amg0 for amazing work so far

Yes, it’s an obvious next step. I haven’t looked into a USB stick yet - for me, Vera has been that stick, but it would be good to have an alternative.

Actually, my first alternative has been MySensors (ie. abandoning Zwave altogether) and I have just got a combined Arduino MySensors RF gateway and openLuup running on a single Arduino Yun board (this is a combination of an Arduino 16Mhz micro-controller and a 400Mhz Linux system.) So in one small package I have a WiFi accessible Vera-like controller and bridge to other sensors. The Linux processor itself is currently running a configuration managing the MySensors network, two WiFi connected Netatmo systems, the DataYours suite logging key events to a remote NAS, ALTUI, and a remotely bridged Vera with around 70 devices.

Even with the relative low-power processor the Linux cpu is only running at about 5% loading and the whole system fits in under 10 Mbytes. Also, unlike Vera, it does not spontaneously reset and has run continuously for many weeks.

It does have a spare USB port too, so room for that stick…
… I have no idea how difficult that might be. Any experience anyone?

your combined solution is much easier and way more elegant for the somewhat experienced "layman", in my opinion.
I wanted an easy transition for existing Vera users (ie. me), because I like Luup (but not UPnP) and Lua.

Hi,

I have a raspberry pi with an open z-wave card called Razberry. This is an internal card, not USB. (http://razberry.z-wave.me/).

Do you think this will work with Openluup? I am ready to give it a try but would like know how likely this will work before potentially waisting hours of time on something that will not work anyway.

One more question about the bridge plugin: I currently run 2 vera’s in upnp bridge mode. Do I need to remove this bridge mode first before installing the bridge plugin from Openluup/AltUI?

Finally, for an easy installation of Openluup on the rpi, would it be possible to create an SD card image with all necessary files?

Thanks a lot,

Jacques

[quote=“jcsv75, post:152, topic:187412”]I have a raspberry pi with an open z-wave card called Razberry. This is an internal card, not USB. (http://razberry.z-wave.me/).

Do you think this will work with Openluup? I am ready to give it a try but would like know how likely this will work before potentially waisting hours of time on something that will not work anyway.[/quote]
No, out of the box, it won’t work.

I’ve taken a look at USB sticks, and the Razberry, and for the most part they seem to support a fairly low-level serial protocol. There is a Zway library which also supports a higher-level JSON interface, which I think would be the one to use. But it would be a lot of work, which, for the moment, I’m not considering. Also, frankly, this is the bit which tends to go wrong with anyone’s Zwave implementation, so my current approach of using Vera as the ‘stick’ seems not so bad. Vera is well enough behaved if you don’t load it with extra plugins, etc., which is what openLuup is all about.

One more question about the bridge plugin: I currently run 2 vera's in upnp bridge mode. Do I need to remove this bridge mode first before installing the bridge plugin from Openluup/AltUI?
Not if you're happy with it (I never was, or at least not for long.) You could simply bridge openLuup to your primary machine and it should see all the devices. However, performance is likely to be better using openLuup's VeraBridge. Having said that, I do know that 'unbridging' Veras is not totally trivial, so for a start I wouldn't try that yet.
Finally, for an easy installation of Openluup on the rpi, would it be possible to create an SD card image with all necessary files?
Yes, this is a really good point which I've been considering. I'm not sure if I'm allowed to include the basic Zwave device files which come with Vera. Also, I must ask @amg0 if I can bundle ALTUI into a distribution like that. I am currently implementing the auto-update functionality for ALTUI so that you could easily keep it up to date (a necessary thing with the rate at which @amg0 develops code!)

Hi,

First of all thanks a lot for all your efforts. I do believe your approach is the way to go. I tried the openluup together with altui but bumped into 2 issues.
FIrst one is that the rooms defined in the startup.lua are not visible and I cannot find a trace of the create rooms in the logs
Second issue is that none of the scenes are created which seems normal as the user_data only contains “scenes”:[]
Could it be something is missing in the bridge?

I appreciate all your help

Thanks for that!

I tried the openluup together with altui but bumped into 2 issues. FIrst one is that the rooms defined in the startup.lua are not visible and I cannot find a trace of the create rooms in the logs
OK. Need a bit more information here, but I can guess... The [tt]startup.lua[/tt] file is read just once to initialize a new system. If you're using the [tt]openLuup_reload[/tt] shell script, then supplying [tt]startup.lua[/tt] as a parameter will run it, initializing your system. If you don't, it will never be read. Subsequently, any reloads (without that parameter) will not access that file, but just reconstruct the system from the [tt]user_data.json[/tt] file.

So if you never specified that startup file, you’ll never have defined any rooms (although VeraBridge should create a room named after the remote Vera and place all the bridged devices into that.) If you’ve done any significant customization of the system and don’t want to reinitialize, then it’s trivial to create the rooms you need, either manually, with a luup call, or using the ALTUI interface.

Second issue is that none of the scenes are created which seems normal as the user_data only contains "scenes":[] Could it be something is missing in the bridge?
Scenes are not bridged from the remote machine to the openLuup environment. The simple reason for this is that all the device numbers are different on the bridged machine and it's not so straight-foward just to take a scene definition and remap all the device numbers (because a scene can be very complex with Lua code, device lookups, ...) Define new scenes on openLuup (using ALTUI and the variable watch triggers NOT the original Vera style ones.)
I appreciate all your help
It's quite possible that I've not really addressed your issues, so just ask again if necessary.

Thanks for your reply,

I do use the reload and startup.lua but I have the impression the startup.lua is not loaded. If I load the startup example file I should see 2 new rooms “upstairs” and “Downstairs” which is not the case. I run ./openLuup_reload ./startup.lua
This is what I see in the log
2015-09-30 16:58:05.345 :: openLuup STARTUP ::
2015-09-30 16:58:05.346 openLuup.init:: version 2015.08.30 @akbooer
2015-09-30 16:58:05.422 openLuup.scheduler:: version 2015.08.23 @akbooer
2015-09-30 16:58:05.424 openLuup.server:: version 2015.08.23 @akbooer
2015-09-30 16:58:05.443 openLuup.scenes:: version 2015.08.30 @akbooer
2015-09-30 16:58:05.452 openLuup.chdev:: version 2015.08.26 @akbooer
2015-09-30 16:58:05.457 openLuup.io:: version 2015.08.15 @akbooer
2015-09-30 16:58:05.458 openLuup.luup:: version 2015.08.26 @akbooer
2015-09-30 16:58:05.479 openLuup.rooms:: version 2015.08.15 @akbooer
2015-09-30 16:58:05.480 openLuup.requests:: version 2015.08.24 @akbooer
2015-09-30 16:58:05.509 luup.create_device:: [1] urn:schemas-micasaverde-com:device:ZWaveNetwork:1 / no-implementation-file
2015-09-30 16:58:05.538 luup.create_device:: [2] urn:schemas-micasaverde-com:device:SceneController:1 / no-implementation-file
2015-09-30 16:58:05.538 openLuup.init:: loading configuration user_data.json
2015-09-30 16:58:05.539 openLuup.init:: loading user_data json…
2015-09-30 16:58:05.564 openLuup.init:: loading rooms…
2015-09-30 16:58:05.564 openLuup.init:: …room loading completed
2015-09-30 16:58:05.565 openLuup.init:: loading devices…
2015-09-30 16:58:05.565 openLuup.init:: [1] ‘ZWave’, urn:schemas-micasaverde-com:device:ZWaveNetwork:1
2015-09-30 16:58:05.570 openLuup.init:: [2] ‘_SceneController’, urn:schemas-micasaverde-com:device:SceneController:1

SHould there be an entry when loading the startup.lua?

Thanks for clarifying the scenes. I was just thinking today it would be nice to have a kind of mapping between the real device ID and a logical name which can be used in the code. I already had to replace twice a device and it’s not funny to search and replace the old device ID all over the code. Maybe an idea for new plugin :slight_smile:

I appreciate your help

OK, my bad, good catch. Truly embarrassed about this - an error not caught by my extensive (no joking) unit testing. Some refactoring of the init module for Release 4 meant that no callback handlers were defined before the startup code was run. So it WAS run, but those particular luup.inet.wget requests were never run. Everything else in startup should have worked (eg. device creation, etc.) Replacement module below…

Thanks for clarifying the scenes. I was just thinking today it would be nice to have a kind of mapping between the real device ID and a logical name which can be used in the code. I already had to replace twice a device and it's not funny to search and replace the old device ID all over the code. Maybe an idea for new plugin :-)

My solution to this is always to use Lua code in scenes to effect any action. Then I always use a table lookup to map between device name (which changes rarely) and and device number (which, as you have found, is a moveable feast.)

Please tell me that the new init module works OK.

and guess what, it’s working! Thanks a lot for solving this
I also use lua code in my scenes but how do you use the device name? For example the call_action command expects an ID not a name
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“0” },75)
I use this to act on motion sensors. My experience is that the call_action works much faster than using the gui to select the action on the device

I appreciate your help

Thank you for finding the error!

I also use lua code in my scenes but how do you use the device name? For example the call_action command expects an ID not a name luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },75) I use this to act on motion sensors. My experience is that the call_action works much faster than using the gui to select the action on the device

I have some generic code in my Startup Lua (the one that is run each time, NOT the openLuup startup.lua !!)


-- generic reverse lookup table constructor for element table.field
function lookupTable (table, field)
	field = field or "description"		-- default field name
	local lookup = {}  
	for i,d in pairs (table) do  		-- create the lookup table
		lookup [d[field] ] = i
	end
	return lookup
end

-- deviceNo (deviceName) returns matching device number
function deviceNo (name)
    deviceLookupTable = deviceLookupTable or lookupTable (luup.devices) 
	return deviceLookupTable[name]
end

-- sceneNo (sceneName) returns matching scene number
function sceneNo (name)
    sceneLookupTable = sceneLookupTable or lookupTable (luup.scenes) 
	return sceneLookupTable[name]
end

this enables me to use:

local devNo = deviceNo "myDeviceName"
local scnNo = sceneNo  "mySceneName"

You might also care to look at this post from a while ago: Object-oriented get/set of Luup device variables which lets you write stuff like:

t = OutDoorTemp:get()
Temp:set(42)

wow, respect! that’s exactly what I was looking for.
I’m not at the point of writing my own plugin but all my scenes are running mostly luup code so this is realy a very big help.
One more question, I just checked and find out the plugins screen is only showing the three default plugins(altui,verbridge and zwavenetwork) is that a normal behaviour?

Thanks again