Qeedji 1.11.11 002A, Руководство пользователя

Страница: 29 / 58

29
define the gateway URL to access to internet,
define valid primary and secondary DNS servers.
For further information, refer to the chapter
§ Configuration > Servers ,
§ Configuration > LAN ,
§ Configuration > Date and time ,
☛ In case the SBL10e device can not fetch a valid date and time through NTP, the clock does not progress and stays with the value
01/01/2020
00:00
. The date and time metadata of the files added after this date on the file system is also
01/01/2020 00:00
until they are modified.
☛ When the server NTP is activated and the device is properly configured, the date and time for the SBL10e device is updated automatically by
NTP at the device boot-up. Then it is progressing every seconds.
☛ The support for date and time file metadata display in this pane will be available in a next version.
Application upgrade
The current application can be replaced by pushing a new firmware file
bm0032_m365_room-sbl10e-xx.yy.zz.bin
at the root of the device WebDAV
directory
http://<device-ip-addr>/
with a WebDAV client.
After the firmware file pushing, a device reboot is required so that the new firmware file is taken into account.
Configuration update
The configuration of the application can be updated by pushing an appropriate
prefs.json
configuration file in the
.conf
WebDAV directory
(
http://<device-ip-addr>/.conf
) with the Web user interface or with a WebDAV client.
Edit the
prefs.json
configuration file example and modify the appropriate lines according to your needs. Once saved, drop it back in the WebDAV
directory like explained above.
☛ After the configuration updating with
prefs.json
, a device reboot is required so that the new configuration is taken into account.
☛ Qeedji does not provide
prefs.json
examples. It is up to the end user to save preciously its own
prefs.json
file per each device.
◬
Loading a wrong
prefs.json
, suitable for another application type for example, would lead to some loss of data like the datasource server
configuration. So check the consistency of the
prefs.json
or
.js
file before loading it.
The configuration of the application can be updated also by pushing an appropriate
.js
configuration script suitable for your application in the
.conf
WebDAV directory (
http://<device-ip-addr>/.conf
) with the Web user interface or with a WebDAV client. In this case, the file pattern must be
either:
configuration.js
,
000000000000.js
or,
aabbccddeeff.js
(with aa-bb-cc-dd-ee-ff, the MAC address of the device).
Download it then:
edit the 000000000000.js configuration script and uncomment/modify the appropriate lines according to your needs,
rename the configuration script if required,
once saved, drop it in the WebDAV directory like explained above,
when suitable for your device, save it preciously for future use.
After a
.js
configuration script loading, the device is rebooting automatically once to take the new configuration into account.
A
000000000000.js
template is available for download here .
☛ Pushing a
.js
configuration script in the
.conf
WebDAV directory (
http://<device-ip-addr>/.conf
) with a WebDAV client could raise a
warning at the WebDAV client end, after the
.js
file transferring is completed because the device is automatically rebooting once when it is
received. For example, after the
.js
file sending with BitKinex WebDAV is done, another network request is done by the WebDAV client while the
device is currently rebooting. So a WebDAV error at the WebDAV client end leads to an automatic file resending which is causing another device
reboot and so on, and this, until the WebDAV client application is closed. For example, after the
.js
file sending with CarotDAV WebDAV client,
the error leads only to the displaying of a warning message. The user has just to ignore the error at the WebDAV client end.