I did a fresh install of ALTUI on a fresh install of openLuup and found the attached error. It occurs when pressing the ALTUI logo for the home screen. I also saw this same error before the fresh installs, but I wanted to make sure there wasn’t a problem related to my installation of the software. The port reference (for openLuup at least) creates a duplicate append on the http call for the home screen. I don’t see this anywhere else in the software.
However, I thought it might be relevant to some other exception errors I’m seeing as there appear to be some routines that auto load the ALTUI home screen. Thx guys.
Here’s an example of what I meant by an exception. You can see in the url bar that there is a call to home–this after doing a manual “reload Luup Engine” under the misc dropdown. The log for the time signature doesn’t show any errors, though there is a mention of a delay in loading ALTUI.
[pre]2018-02-28 21:29:38.000 luup.create_device:: [10008] D_BinaryLight1.xml / X / D_BinaryLight1.json
2018-02-28 21:29:38.002 luup.create_device:: [10009] D_BinaryLight1.xml / X / D_BinaryLight1.json
2018-02-28 21:29:38.004 luup.create_device:: [10011] D_BinaryLight1.xml / X / D_BinaryLight1.json
2018-02-28 21:29:38.006 luup.create_device:: [10012] D_BinaryLight1.xml / X / D_BinaryLight1.json
2018-02-28 21:29:38.007 luup.create_device:: [10013] D_DoorLock1.xml / X / D_DoorLock1.json
2018-02-28 21:29:38.010 luup.create_device:: [10014] D_BinaryLight1.xml / X / D_BinaryLight1.json
2018-02-28 21:29:38.012 luup.create_device:: [10123] D_BinaryLight1.xml / X / D_BinaryOpenClose1.json
2018-02-28 21:29:38.014 luup.create_device:: [10125] D_BinaryLight1.xml / X / D_BinaryOpenClose1.json
2018-02-28 21:29:38.015 luup_log:5: creating device numbers: [1,10002,10003,10004,10005,10007,10008,10009,10011,10012,10013,10014,10123,10125]
2018-02-28 21:29:38.015 luup_log:5: device[1] parent set to 5
2018-02-28 21:29:38.015 luup_log:5: device[10002] parent set to 1
2018-02-28 21:29:38.015 luup_log:5: device[10003] parent set to 5
2018-02-28 21:29:38.015 luup_log:5: device[10004] parent set to 1
2018-02-28 21:29:38.015 luup_log:5: device[10005] parent set to 1
2018-02-28 21:29:38.015 luup_log:5: device[10007] parent set to 1
2018-02-28 21:29:38.015 luup_log:5: device[10008] parent set to 1
2018-02-28 21:29:38.015 luup_log:5: device[10009] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10011] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10012] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10013] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10014] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10123] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: device[10125] parent set to 1
2018-02-28 21:29:38.016 luup_log:5: linking to remote scenes…
2018-02-28 21:29:38.016 luup_log:5: scenes: existing= 0, new= 0
2018-02-28 21:29:38.016 luup_log:5: v18.2.24
2018-02-28 21:29:38.160 luup.variable_set:5: 1.urn:micasaverde-com:serviceId:HaDevice1.Configured was: EMPTY now: 0 #hooks:0
2018-02-28 21:29:38.160 luup.variable_set:5: 10002.urn:micasaverde-com:serviceId:HaDevice1.Configured was: EMPTY now: 0 #hooks:0
2018-02-28 21:29:38.160 luup.variable_set:5: 10003.urn:micasaverde-com:serviceId:HaDevice1.Configured was: EMPTY now: 0 #hooks:0
2018-02-28 21:29:38.162 luup.set_failure:5: status = 0
2018-02-28 21:29:38.163 luup.variable_set:5: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2018-02-28 21:29:38.163 luup.variable_set:5: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2018-02-28 21:29:38.163 luup_log:5: registering with AltUI [3] as Data Storage Provider
2018-02-28 21:29:38.163 luup.register_handler:5: global_function_name=HTTP_VeraBridgeMirror_xx.xx.xx.xx, request=HTTP_VeraBridgeMirror_xx.xx.xx.xx
2018-02-28 21:29:38.163 luup.call_action:5: 3.urn:upnp-org:serviceId:altui1.RegisterDataProvider
2018-02-28 21:29:38.163 openLuup.scheduler:: [5] VeraBridge device startup completed: status=true, msg=OK, name=VeraBridge
2018-02-28 21:29:38.163 luup_log:3: ALTUI: UPNPregisterDataProvider(3,Vera@xx.xx.xx.xx,http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_xx.xx.xx.xx,[{
“default”:“device.serviceId.name”,
“key”:“mirror”,
“label”:“Mirror”,
“type”:“text”
}])
2018-02-28 21:29:38.164 luup.variable_set:3: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {“Vera@xx.xx.xx.xx”:{“url”:“http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_xx.xx.xx.xx",“callback”:"”… now: {“Vera@xx.xx.xx.xx”:{“url”:“http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_xx.xx.xx.xx",“callback”:"”… #hooks:0
2018-02-28 21:29:39.166 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3[/pre]
Yes, probably the same issue. I’m running on Armbian, on an Orange Pi PC 2. openLuup was a fresh download and install on Feb 28th.
The connection to the home problem is the “ALTUI_handler&command=home” in the url bar. But, not knowing the program flow, maybe they’re not connected at all.
The stack trace in Chrome doesn’t show much that pinpoints anything. Just some standard Jscript calls populated with nulls.
There were two missing icons files: intro.png, and favicon.ico. I created temp versions and placed them in the icon folder and those errors related to the icons disappeared from the log. But that fix did not stop the “controller did not respond” error on reloads.
[quote=“Buxton, post:4, topic:198716”]But that fix did not stop the “controller did not respond” error on reloads.[/quote]You are seeing this message in the GUI, not in the openLuup logs, correct? If so, that’s simply saying that openLuup is not responding because it is reloading. AltUI is constantly polling openLuup for an update. When it is reloading, it isn’t responding to AltUI because it is busying reloading.
If you are referring to something else then ignore the above…
If the error message is related to a stoppage of normal polling, then a manual Luup reload should optimally pause polling until the reload completes. Only a reload related to equipment problems should notify the user that the controller stopped responding. It’s not a major problem by any means if this is what is happening, but it’s far better to have error messages bring attention to true errors so that the user can take some diagnostic action.
@jswim788 is quite correct in the diagnosis… I had obviously not understood the description of the symptoms. Actually, I rather like watching the count up when I reload for development updates. My biggest system takes six seconds, several others under two. Vera takes somewhat longer!
[quote=“Buxton, post:1, topic:198716”]I did a fresh install of ALTUI on a fresh install of openLuup and found the attached error. It occurs when pressing the ALTUI logo for the home screen. I also saw this same error before the fresh installs, but I wanted to make sure there wasn’t a problem related to my installation of the software. The port reference (for openLuup at least) creates a duplicate append on the http call for the home screen. I don’t see this anywhere else in the software.
However, I thought it might be relevant to some other exception errors I’m seeing as there appear to be some routines that auto load the ALTUI home screen. Thx guys.[/quote]
check the LocalHome variable value of ALTUI device and fix it to be /data_request?id=lr_ALTUI_Handler&command=home
not sure yet how this happens, will continue to look but this is enough to fix it
[quote=“Buxton, post:9, topic:198716”]That fixed it. Thx amg0.
akbooer, I was reloading luup after manually installing the missing graphics files. I saw the error notice and tried to track it down.
Edit: This fix also seems to stop the exception errors I was seeing on a luup reload.[/quote]
v2315 should include the fix.
People who already have a value in the LocalHome value should fix it to be /data_request?id=lr_ALTUI_Handler&command=home
Best Home Automation shopping experience. Shop at Ezlo!