I’m now really confused. You have two bridged Veras, so one of your Veras (possibly both if you have bridged both ways) shows ALL your devices.
Assuming youre only bridged one way, which of the two Veras requires a password? Does the other one work OK with openLuup?
Only the main vera requires a password. The secondary slaved vera does not prompt for credentials. I have no idea why the devices behave this way.
In a browser, the main vera shows all my zwave devices from both veras. The secondary vera shows only its own native devices.
I just tried to bridge to my slave vera and it works just fine… All of the secondary vera devices loaded into Altui. The master-slave connection between the two veras is one way only.
Though all seems to function fine, I am getting a further error when doing a “reload luup engine” from the misc dropdown:
the log entry is:
2018-02-09 15:36:00.854 luup_log:5: registering with AltUI [3] as Data Storage Provider
2018-02-09 15:36:00.854 luup.register_handler:5: global_function_name=HTTP_VeraBridgeMirror_10.17.XX.XX, request=HTTP_VeraBridgeMirror_10.17.XX.XX
2018-02-09 15:36:00.854 openLuup.context_switch:: ERROR: ./openLuup/luup.lua:466: bad argument #2 to ‘format’ (string expected, got nil)
2018-02-09 15:36:00.854 openLuup.scheduler:: job aborted : ./openLuup/luup.lua:466: bad argument #2 to ‘format’ (string expected, got nil)
I tried this several times and I get the same error and log entry each time I fire the reload command.
Thanks for that. I’ll take a look. I have had to make a few changes to the bridge recently because of upcoming Vera changes.
I fixed this in the latest development branch (2018.02.10)
You should now get a valid error message… I’d be very interested in seeing what it is!
I still get an error on a reload, though the bridge plugin is working fine (for the vera that does not require credentials) and there are no errors in the log when changing a given device state. The response of a device to a change is instantaneous, which is very impressive.
Here are the log entries for the reload error as well as some console screenshots:
2018-02-10 14:35:37.641 luup.register_handler:5: global_function_name=HTTP_VeraBridgeMirror_10.17.XX.XX, request=HTTP_VeraBridgeMirror_10.17.XX.XX
2018-02-10 14:35:37.642 luup.call_action:5: 3.?.RegisterDataProvider
2018-02-10 14:35:37.642 openLuup.scheduler:: [5] VeraBridge device startup completed: status=true, msg=OK, name=VeraBridge
2018-02-10 14:35:37.642 openLuup.server:: new client connection from 10.17.XX.XX: tcp{client}: 0x2072d398
2018-02-10 14:35:37.642 openLuup.server:: GET /data_request?id=lr_ALTUI_Handler&command=oscommand&oscommand=top%20-n%201&=1518301641175 HTTP/1.1 tcp{client}: 0x2072d398
2018-02-10 14:35:37.643 openLuup.servlet:: No handler for data_request?id=lr_ALTUI_Handler
2018-02-10 14:35:37.643 openLuup.server:: request completed (153 bytes, 0 chunks, 0 ms) tcp{client}: 0x2072d398
2018-02-10 14:35:38.018 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=302014295&Timeout=60&MinimumDelay=1500&=1518301641176 HTTP/1.1 tcp{client}: 0x2072d398
2018-02-10 14:35:38.520 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3
2018-02-10 14:35:38.539 luup.variable_set:3: 3.urn:upnp-org:serviceId:altui1.Version was: v2.14 now: v2.14 #hooks:0
Typo in this call:
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/less/
Should be:
https://raw.githubusercontent.com/FontAwesome/Font-Awesome/master/less/
[quote=“Buxton, post:10, topic:198545”]Typo in this call:
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/less/
Should be:
https://raw.githubusercontent.com/FontAwesome/Font-Awesome/master/less/[/quote]
This one is nothing to do with openLuup. Either comes from a plugin, or AltUI.
Yes, this one was my fault: a typo not caught by the syntax checker or testing. In fact, it would have stopped mirroring of variables back to the Vera working, but if you’re not using that, then you wouldn’t have noticed.
The response of a device to a change is instantaneous, which is very impressive.
Good news… that’s what we aim for!
Thanks and karma for such excellent diagnostic reporting to help me find and fix this: in latest development branch 2018.02.11.
You’re more than welcome. Amazing work here. I will load the latest development version and test as soon as I have a chance.
I’m still getting an error with the latest development branch. The Verabridge device label lights up red, and an OS error message appears, on a manual luup reload. From digging through the stack, it looks like it comes back to the way altui is handling images. But I could be completely wrong as execution is fairly complicated. But if so, it could be the fault of the hardcoded url in “J_ALTUI_uimgr.js” for “https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/less/” which currently doesn’t point to anything.
I tried going through the FortAwesome github repository, but without knowing what was intended for fonts, I can’t make a call on the new url naming conventions that appear to be in place for the Font-Awesome repo (directory structure is now very different.)
Also, there is an “intro.png” missing from the cmh-ludl/icons directory–which is throwing an exception-- file not found.
This looks like an AltUI issue, which is way out of my understanding. It might be caused by a missing file, but I couldn’t say. @amg0 is needed here, but probably isn’t looking with a thread topic like this.
Suggest you start a topic in the AltUI Board with a more explicit title, or PM him, pointing to this thread.
I contacted Vera about the credential issue and found out that the setting to enable local credentials is in the /etc/lighttpd/lighttpd.conf file and the /etc/lighttpd.conf file.
Basically you comment out the “mod_auth” option in the server.modules section and this cancels local login required.
After disabling credentials, I imported my main vera in verabridge and all my devices imported properly.
Thx a bunch. I’m looking forward to all of things I can do with my Orange Pi that I could not do with my Veras…
Thanks, indeed, for this. Valuable information!
I’ve always planned to experiment with lighttpd configuration, but never got around to it (and don’t need it in openLuup anyway.)
Has there been a solution to this besides disabling mod_auth? I’m also getting a 401 error.
Old post but I cant find any other hits on this. Probably not to many folks use Vera as slave and those that do probably dont access the slave directly enough to realize it doesnt require a password to access
"The odd thing about the credential prompt is that only one of my Veras prompts me for a login and password when going directly into UI7 from the browser. "
This was mentioned within this post but I dont see it answered. I have this issue. Master requires password, slave does not.
Per the above:
that the setting to enable local credentials is in the /etc/lighttpd/lighttpd.conf file and the /etc/lighttpd.conf file. Basically you comment out the “mod_auth” option in the server.modules section
That’s all you need to do to disable authentication.
I want to enable authentication on the slave controller not disable it on the primary. I did not comment out anything to cause this.
It does not matter whether the controller is a slave or master. What does matter is that on the individual controller, the appropriate line (“mod_auth” ) is commented out (authentication disabled) or that it is not commented out (authentication enabled).
This really should be a checkbox in the UI under the appropriate menu item —but it’s not.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules