Everything is Awesome !!!
It seems to work (LuaUPnP.log created and “alive” command responds “OK”)
But, when I call “http://127.0.0.1:3480/data_request?id=lr_ALTUI_Handler&command=home#”
the response is “No handler”.
The ALTUI files are in /etc/cmh-ludl
Well, not quite everything, it would appear…
It seems to work (LuaUPnP.log created and "alive" command responds "OK")Looking at the log file, then, are there any error messages from ALTUI ? There are really three places to look: (a) early on, to be sure that the create device process has worked, [code] 2015-07-10 17:04:49.229 luup.create_device:: [5] D_ALTUI.xml / I_ALTUI.xml 2015-07-10 17:04:49.233 luup.attr_set:: 5.device_json = D_ALTUI_UI7.json [/code]
… and (b) a bit later after the scheduler starts up and runs the job initialisation.
2015-07-10 17:04:51.798 openLuup.scheduler:5: device startup
2015-07-10 17:04:51.801 luup_log:5: ALTUI: initstatus(5) starting version: v0.52
2015-07-10 17:04:51.838 luup.register_handler:5: global_function_name=myALTUI_Handler, request=lr_ALTUI_Handler
2015-07-10 17:04:51.841 openLuup.scheduler:5: device startup completed: status=nil, msg=nil, name=nil…and (c) a bit later still because ALTUI also has a delayed startup branch.
2015-07-10 17:05:04.421 luup_log:5: ALTUI: startupDeferred, called on behalf of device:5
2015-07-10 17:05:04.425 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Debug was: EMPTY now: 0 #hooks:0
2015-07-10 17:05:04.427 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Version was: EMPTY now: v0.52 #hooks:0
2015-07-10 17:05:04.430 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Present was: EMPTY now: 0 #hooks:0
2015-07-10 17:05:04.432 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.RemoteAccess was: EMPTY now: https://vera-ui.strongcubedfitness.com/Veralogin.php #hooks:0
2015-07-10 17:05:04.434 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.ThemeCSS was: EMPTY now: #hooks:0
2015-07-10 17:05:04.436 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Version was: v0.52 now: v0.52 #hooks:0
2015-07-10 17:05:04.449 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.PluginConfig was: EMPTY now: {...But, when I call "http://127.0.0.1:3480/data_request?id=lr_ALTUI_Handler&command=home#" the response is "No handler".There should be a log file entry where ALTUI does a luup.register_handler - do you see that? ALTUI also does a lot of fetches of files through the port:80 server - look for 404 errors in your regular HTTP server log.
The ALTUI files are in /etc/cmh-ludlI have a feeling that I didn't mention this in the Guide, but you need to start up the openLuup process with your default directory as /etc/cmh-ludl/
One more question: have you create any other devices? I’ve not tested ALTUI on openLuup without any. Did you start the VeraBridge, for example?
Anyway, some progress is good. ALTUI is actually a complex app to begin with, but we really have no choice since we need the interface!
Forget all that… I think I have found it.
ALTUI uses a shell script to determine its machine’s IP address. openLuup used to do the same, but now has a pure Lua way to do it…
The answer I posted a while ago here: [url=http://forum.micasaverde.com/index.php/topic,31078.msg225192.html#msg225192]http://forum.micasaverde.com/index.php/topic,31078.msg225192.html#msg225192[/url] !!
[quote=“akbooer, post:26, topic:186265”]You can suppress this message by creating the file [tt]/usr/bin/GetNetworkState.sh[/tt] with the contents:
echo -n 172.16.42.88replacing the IP address with that of your own (RPi) machine. [/quote]
in the absence of this script, ALTUI should have failed with an error message… which should be in the log?
I’ve never removed my copy from my machine, so all runs smoothly, although I had long forgotten it was there!
It’s OK now. The file “L_ALTUI.lua” was missing.
Really great !
some remarks :
[quote=“vosmont, post:36, topic:187412”]- In ZeroBrane log, there is an error about “GetNetworkState.sh”
Both of these are related and solved in my previous post (posted just before yours!)
…and just to be clear, you DO need all the .xml, .json files in /etc/cmh-ludl/ so that openLuup can load them.
Actually, here, now, is a better version of [tt]GetNetworkState.sh[/tt] which uses a Lua script to, quite generally, find your IP address…
#! /usr/bin/env lua
--------------------------------------------------------------------------------
-- discover main IP address of machine and write to standard output
-- http://forums.coronalabs.com/topic/21105-found-undocumented-way-to-get-your-devices-ip-address-from-lua-socket/
--------------------------------------------------------------------------------
local socket = require "socket"
function myIP ()
local mySocket = socket.udp ()
mySocket:setpeername ("42.42.42.42", "424242") -- arbitrary IP and PORT
local ip = mySocket:getsockname ()
mySocket: close()
return ip or "127.0.0.1"
end
io.write (myIP())
--------if you have multiple versions of Lua installed, you may need to change the first line to:
#! /usr/bin/env lua5.1This should be much better than having to craft a file specifically for your own machine IP - I’ll put it in the next distribution.
As I am on Windows, I’m not sure that the script “.sh” will work.
For the moment I’ve modified the function getIP in L_ALTUI.lua, and it’s OK.
I can controll the lights on the Vera via the bridge.
ALTUI is OK and putting the files of the plugin in /etc/cmh-ludl, lets ALTUI display their tabs.
The plugin RGB Controller doesn’t work :
http://ip:3480/data_request?id=action&output_format=json&DeviceNum=41&serviceId=urn:upnp-org:serviceId:RGBController1&action=GetColorChannelNames
returns “-1”
I will do more tests but for the moment it seems to work well 
Bravo !
[quote=“vosmont, post:39, topic:187412”]The plugin RGB Controller doesn’t work :
http://ip:3480/data_request?id=action&output_format=json&DeviceNum=41&serviceId=urn:upnp-org:serviceId:RGBController1&action=GetColorChannelNames
returns “-1”[/quote]
I think the problem is that this action is for the distant Vera (the plugin is installed on it). So when it is executed on openLuup, it can’t respond.
So for the javascript in the tab of the distant plugin, it lacks perhaps a proxy.
[quote=“vosmont, post:39, topic:187412”]As I am on Windows, I’m not sure that the script “.sh” will work.
For the moment I’ve modified the function getIP in L_ALTUI.lua, and it’s OK.[/quote]
I never imagined that openLuup would be run on a Windows machine! A fair number of plugins will be written with the assumption that the underlying system is Unix. In particular, anything with an [tt]os.execute(…)[/tt] call will likely fail. Your ALTUI fix is what I originally did - hooray for open source!
[quote=“vosmont, post:40, topic:187412”][quote=“vosmont, post:39, topic:187412”]The plugin RGB Controller doesn’t work :
http://ip:3480/data_request?id=action&output_format=json&DeviceNum=41&serviceId=urn:upnp-org:serviceId:RGBController1&action=GetColorChannelNames
returns “-1”[/quote]
I think the problem is that this action is for the distant Vera (the plugin is installed on it). So when it is executed on openLuup, it can’t respond.
So for the javascript in the tab of the distant plugin, it lacks perhaps a proxy.[/quote]
A couple of points here:
[ul][li]An action call to a device bridged by VeraBridge will be re-routed to the remote machine device - this is how turning on lights, etc., works. So the underlying mechanism should be working. Actions which have return variables are not fully working at this time. The definition of which variables to return is given in the service .xml files and I’ve been trying to avoid them, since this brings me too close to UPnP syntax nonsense. The same with scene triggers.[/li]
[li]Obviously, a plugin which assumes that it’s manipulating the local machine GUI is going to struggle when bridged. The solution is surely, simply to run RGB Controller on the openLuup machine - this is what it’s for, to offload things from the original Vera. **** see edit below ***[/li][/ul]
Sounds like you’ve made a lot of progress. Interested in hearing further.
Edit: having re-read my reply, I suddenly realise that the action call you are making, which needs to be handled by VeraBridge, is NOT in its list of implemented actions (as given in the implementation file.) This is perhaps what you implied by mentioning a proxy. It would be a step forward to insert that action into I_VeraBridge.xml, but you may still have difficulties with the JavaScript. Running it locally still makes sense to me.
Just for the sake of completeness, the serviceId / actions currently handled by VeraBridge are:
<serviceId>urn:upnp-org:serviceId:SwitchPower1</serviceId>
<name>SetTarget</name>
<serviceId>urn:upnp-org:serviceId:Dimming1</serviceId>
<name>SetLoadLevelTarget</name>
<serviceId>urn:micasaverde-com:serviceId:DoorLock1</serviceId>
<name>SetTarget</name>
<serviceId>urn:upnp-org:serviceId:TemperatureSetpoint1_Heat</serviceId>
<name>SetCurrentSetpoint</name>
<serviceId>urn:upnp-org:serviceId:HVAC_UserOperatingMode1</serviceId>
<name>SetModeTarget</name>
<serviceId>urn:upnp-org:serviceId:WindowCovering1</serviceId>
<name>Up</name>
<serviceId>urn:upnp-org:serviceId:WindowCovering1</serviceId>
<name>Down</name>
<serviceId>urn:upnp-org:serviceId:WindowCovering1</serviceId>
<name>Stop</name>
<serviceId>urn:micasaverde-com:serviceId:SecuritySensor1</serviceId>
<name>SetArmed</name>Hi
I tried this in Ubuntu and get the following response:
/etc/cmh-ludl$ sudo lua5.1 openLuup_release_1.lua /dev/null
lua5.1: ./openLuup/logs.lua:6: module ‘socket’ not found:
no field package.preload[‘socket’]
no file ‘./socket.lc’
no file ‘./socket.lua’
no file ‘/usr/local/share/lua/5.1/socket.lua’
no file ‘/usr/local/share/lua/5.1/socket/init.lua’
no file ‘/usr/local/lib/lua/5.1/socket.lua’
no file ‘/usr/local/lib/lua/5.1/socket/init.lua’
no file ‘/usr/share/lua/5.1/socket.lua’
no file ‘/usr/share/lua/5.1/socket/init.lua’
no file ‘./socket.so’
no file ‘/usr/local/lib/lua/5.1/socket.so’
no file ‘/usr/lib/x86_64-linux-gnu/lua/5.1/socket.so’
no file ‘/usr/lib/lua/5.1/socket.so’
no file ‘/usr/local/lib/lua/5.1/loadall.so’
[quote=“tomvanbreda, post:43, topic:187412”]Hi
I tried this in Ubuntu and get the following response:
/etc/cmh-ludl$ sudo lua5.1 openLuup_release_1.lua /dev/null
lua5.1: ./openLuup/logs.lua:6: module ‘socket’ not found:[/quote]
Yes. I think it means what it says - you haven’t installed the LuaSocket library.
See the bottom line of this earlier post: [url=http://forum.micasaverde.com/index.php/topic,32315.msg240753.html#msg240753]http://forum.micasaverde.com/index.php/topic,32315.msg240753.html#msg240753[/url]
It may be that you need a different instruction on Ubuntu to install it, but if you have already managed to install Lua then this should be along the same lines.
So I tried this and got quite a long way using this startup code:
do -- RGB Controller
local Drgb = luup.create_device ('', '', "RGBW Controller", "D_RGBController1.xml", "I_RGBController1.xml")
luup.attr_set ("device_json", "D_RGBController1_UI7.json", Drgb)
luup.variable_set ("urn:upnp-org:serviceId:RGBController1", "DeviceType", "FGRGBWM-441", Drgb)
luup.variable_set ("urn:upnp-org:serviceId:RGBController1", "DeviceId", "217", Drgb)
endI had to force the DeviceType and DeviceId variables, because I couldn’t get the settings tab on the control panel to display for some reason. The problem I ran into, however, is that, currently, the VeraBridge does not honour parent/child relationship from the bridged Vera: all remote devices are children of the VeraBridge (I think this is how it works on natively bridged Veras too, so it wouldn’t work there either.) This means that the target master device (Fibaro, in my case) does not have any RGBW children.
If you want to discuss this further, I’d recommend starting a new thread because we are drifting away from the general issues around openLuup. Thanks.
I have now modified the behaviour of VeraBridge and it does now reflect the parent/child relationships. Attached is an ALTUI Parent/Child map now showing clearly that some of the remote machines have Netatmos attached with their plethora of child devices. Also some multi-sensors and an RGBController.
If you want to discuss this further, I'd recommend starting a new thread because we are drifting away from the general issues around openLuup. Thanks.So I ignored my own advice, because this is a general issue, but I have also discovered why my setup screen is not displaying for the RGBController - I'll raise that on the appropriate thread.
Oh hi there! I was wondering if I should post instructions on transitioning to openLuup, but I thought I would make sure it worked OK for others first! [tt]DataYours[/tt] certainly works for me on this distribution, although I have made one change to it to make startup easier on openLuup.
All you would need to do is add to the startup code:
do -- DataYours
local dy7 = luup.create_device ('', '', "DataYours", "D_DataYours7.xml","I_DataYours7.xml") -- create the device
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "DAEMONS", "Graph, Dash, Cache, Watcher", dy7)
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "LOCAL_DATA_DIR", "/nas/whisper/", dy7)
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "VERAS", "172.16.42.10, 172.16.42.11, 172.16.42.12, 172.16.42.14", dy7)
end…obviously with IP addresses, etc. tailored to your system.
I’ll post the update to [tt]DataYours[/tt] on that thread, to keep this focused on openLuup issues.
Thanks for the interest.[/quote]
Hi akbooer,
I’ve installed openLuup with AltUI Veraridge on another Rpi and all seems ok.
To install Datayours on this Rpi I’ve to copy all the Datayours Lua files on /etc/cmh-ludl directory and add the code to startup.lua as you indicated in this post ?
tnks
donato
[quote=“d55m14, post:47, topic:187412”]I’ve installed openLuup with AltUI Veraridge on another Rpi and all seems ok.
To install Datayours on this Rpi I’ve to copy all the Datayours Lua files on /etc/cmh-ludl directory and add the code to startup.lua as you indicated in this post ?[/quote]
Excellent! Glad it’s going well - I have a new release of openLuup very soon (with scenes, timers, actions, ALTUI history, …)
You need the full set of installation files, since ALTUI (and, to some extent, openLuup) also need the S_xxx.xml, D_xxx.xml, I_xxx.xml, D_xxx.json information, as well as the actual Lua code - all in the same directory (/etc/cmh-ludl/)
[quote=“akbooer, post:48, topic:187412”][quote=“d55m14, post:47, topic:187412”]I’ve installed openLuup with AltUI Veraridge on another Rpi and all seems ok.
To install Datayours on this Rpi I’ve to copy all the Datayours Lua files on /etc/cmh-ludl directory and add the code to startup.lua as you indicated in this post ?[/quote]
Excellent! Glad it’s going well - I have a new release of openLuup very soon (with scenes, timers, actions, ALTUI history, …)
You need the full set of installation files, since ALTUI (and, to some extent, openLuup) also need the S_xxx.xml, D_xxx.xml, I_xxx.xml, D_xxx.json information, as well as the actual Lua code - all in the same directory (/etc/cmh-ludl/)[/quote]
Hi akbooer,
where can I find the full updated set of Datayours files to upload on Rpi ?
tnks
donato
Release 2 attached, including VeraBridge plugin to connect to remote Veras.
New features include:
[ul][li]scenes (with timers, but not triggers)[/li]
[li]persistence of rooms and scenes[/li]
[li]better integration with ALTUI[/li]
[li]scene and variable history (through ALTUI)[/li]
[li]uses S_xxx.xml files for definition of action return variables[/li][/ul]
This should run on any Unix system - someone even has it running under Windows (some features don’t work there.)
The biggest thing missing is still the luup.io module so some plugins (including Arduino) do not yet run - it’s really the next thing on the list.
Edit: This release has been superseded. Please see link on post #1 of this thread for latest
Hi akooer
I copied all files of Datayours on etc/cmh-ludl directory and modified the startup.lua as you indicated, but when I call the dashboard ("http://xxxxxxxx:3480/data_request?id=lr_dashboard2&page=home) I get the msg “no handler” . Do I have to do any other operation ?
tnks
donato
You should be using the Lua files here?
[url=http://forum.micasaverde.com/index.php/topic,30808.msg242800.html#msg242800]http://forum.micasaverde.com/index.php/topic,30808.msg242800.html#msg242800[/url]
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules