[Solved] Waiting Initial Data

I’ve been having a problem with ALTUI not loading since 2 weeks ago.
I am not sure what is causing it. The exact same symptom is observed both on the Vera Plus itself and on Openluup.

The UI starts loading and is stuck at “waiting initial data”. What could be causing it? I don’t know that I made any changes to the vera itself. Could it be looking for some website information and that my firewall is blocking it?

[quote=“rafale77, post:1, topic:197093”]I’ve been having a problem with ALTUI not loading since 2 weeks ago.
I am not sure what is causing it. The exact same symptom is observed both on the Vera Plus itself and on Openluup.

The UI starts loading and is stuck at “waiting initial data”. What could be causing it? I don’t know that I made any changes to the vera itself. Could it be looking for some website information and that my firewall is blocking it?[/quote]
It must load some js file from various cdn. Check the console log or the dev tools network page in chrome (f12) for some failures.

Thank you.

This is what the I am seeing on chrome (it fails also on Safari and edge)

Failed to load resource: the server responded with J_SiteSensor1_ALTUI.js a status of 404 (Not Found)

I am also getting a warning:
A Parser-blocking, cross site (i.e. different eTLD+1) script, https://www.google.com/uds/api/visualization/1.0/40ff64b1d9d6b3213524485974f36cc0/format+en,default+en,ui+en,table+en,gauge+en.I.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See Chrome Platform Status for more details.

I am going to look up that js file. Not sure why it is not found.

Edit: No idea what this js file is I see no reference to it anywhere…

Found the problem. the sitesensor files are not all being downloaded. got it all fixed by manually uploading them.

I’m seeing this same issue across all browsers after the last update. How do I fix this?

Get on chrome open altui and and check what is in the console JavaScript
Ctrl + J

?dit : I see lots of users already on version 2245 so it must be a local problem

Attached screen cap of chrome output. I have ad-blocker disabled.

please confirm exact version of ALTUI and your setup ( back end / front end )
in case of doubt force full install (onVERA) with
http://:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=35132

Make sure you do luup reload and then browser refresh

I potentially detected a load issue which could be visible on slower environment.
you can try the version on GitHub - amg0/ALTUI: Enhancement Interface for VERA home automation system to see if that works for you and let me know

For whatever reason, it seemed to fix itself, and I was able to grab the next update. Will update if I see the problem again.

@amg0, I am having issues with .js files from apps which were deleted and for which I delete files on vera units.

Somehow when ALTUI loads it is looking for the js files from these apps which are no longer on the unit. I am being forced to keep the .js files for them. I noticed in particular that the apps from Rigpapa have this problem. Both DeusExMachinaII and SiteSensor have been problematic for me. I try to keep my units clean and I sometimes move an app from one unit to another or to Openluup so when I delete an app, I delete all the files too. This prevents ALTUI from loading.

[quote=“rafale77, post:11, topic:197093”]@amg0, I am having issues with .js files from apps which were deleted and for which I delete files on vera units.

Somehow when ALTUI loads it is looking for the js files from these apps which are no longer on the unit. I am being forced to keep the .js files for them. I noticed in particular that the apps from Rigpapa have this problem. Both DeusExMachinaII and SiteSensor have been problematic for me. I try to keep my units clean and I sometimes move an app from one unit to another or to Openluup so when I delete an app, I delete all the files too. This prevents ALTUI from loading.[/quote]

Once an app declared itself into altui to act as a display plugin, it will be required… you can reset altui config to default to overcome that problems.

Thanks! I will try that. How do you reset the config by the way? Sounds like a dummy question but I actually looked and couldn’t find anything on the UI.

Thanks! I will try that. How do you reset the config by the way? Sounds like a dummy question but I actually looked and couldn’t find anything on the UI.[/quote]

Altui device settings page, button : default config. Or you can empty the variable pluginconfig of the altui device
Either method, reload lump after.
( I am not in front of it right now so exact names or label can be slightly different. )

Have something similar. After hitting Default Configuration button in the Settings menu AltUI works normally for a while but then reverts back to Waiting Initial Data. I don’t have AutoVirtualThermostat installed on this Vera - but I do on a separate pi. Is this the issue?

12/03/18 11:06:35.309 luup_log:27: ALTUI: debug: myALTUI_Handler: request is: ALTUI_Handler <0x2e8de680>
50 12/03/18 11:06:35.310 luup_log:27: ALTUI: debug: myALTUI_Handler: parameters is: { “command”: “home” } <0x2e8de680>
02 12/03/18 11:06:36.759 e[33;1mluvd_get_info mg conn can’t read /etc/cmh-ludl//J_AutoVirtualThermostat1_ALTUI.js or /etc/cmh-lu//J_AutoVirtualThermostat1_ALTUI.js from filename /J_AutoVirtualThermostat1_ALTUI.js pPtrFile (null)e[0m <0x2e2de680>
01 12/03/18 11:06:42.253 e[31;1mUserData::WriteUserData saved–before move File Size: 40571 save size 40571e[0m <0x2ba83680>
02 12/03/18 11:06:42.253 e[33;1mUserData::TempLogFileSystemFailure start 0e[0m <0x2ba83680>
02 12/03/18 11:06:42.279 e[33;1mUserData::TempLogFileSystemFailure 4857 res:1

Yes it is the same problem I had. You must have installed it at some point in time and ALTUI’s javascript is now looking for the file when it loads. You need to either install the .js file on that unit or delete it from the default config field.

I had the same issue after removing the reactor plugin. In the ALTUI config it then looks for a file that is no longer there and the GetStyle error pops up. If you have not did anything special to the ALTUI config, just hit the reset button and reload Luup. For me it then all worked again.

After staring at the code for a while I still cannot figure out why the check amg0 put in are not working in this scenario, but it seems specific to plugins that use the GetStyle definition and are then removed. I guess the master needs to way in. ;D

Cheers Rene

[quote=“reneboer, post:17, topic:197093”]I had the same issue after removing the reactor plugin. In the ALTUI config it then looks for a file that is no longer there and the GetStyle error pops up. If you have not did anything special to the ALTUI config, just hit the reset button and reload Luup. For me it then all worked again.

After staring at the code for a while I still cannot figure out why the check amg0 put in are not working in this scenario, but it seems specific to plugins that use the GetStyle definition and are then removed. I guess the master needs to way in. ;D

Cheers Rene[/quote]

another weird VERA behavior. asking a request for anyfile even non existing returns a http 200 so there is no real easy way for ALTUI to know the plugin file is missing especially because ALTUI loads it in the DOM dynamically using javascript . ( for example http://192.168.1.17/port_3480/toto allways works )
then, it tried to call the method in that (supposedly loaded) file and it failed.

so I did 3 things in the next version
a) a javscript console warning message like “the module or function xxx.getStyle does not exist, check your configuration”
b) a warning in the page message area
c) continuing the execution without crashing

beta in github GitHub - amg0/ALTUI: Enhancement Interface for VERA home automation system

Crikey - mixing it up with the Heroes and Master! Cheers guys …