guykuo
Getting comfortable
The new Web 5.0 GUI cameras will respond correctly to the old CGI calls if and only if one first sets them to Self-Adaptive working mode in the web GUI.
That leaves them in a state that will accept the old CGI commands issued by software written to control the older cameras via....
cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=0 <-- day profile
cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=1 <-- night profile
This seems to be related to the cameras being left in VideoInMode[0].Mode=0 which is the mode that accepts the old profile switches via Config[0].
If one forgets and leaves the Web 5.0 cameras in Customized Scene working mode (VideoInMode[0].Mode=3), the web 5.0 cameras refuse the old Config[0] settings.
VideoInMode[0].Mode=3 <-- camera is in scheduled customized scene mode and won't accept Config[0] settings
VideoInMode[0].Mode=0 <-- camera is in constant profile mode and WILL accept Config[0] settings
If camera is already in VideoInMode[0].Mode=0, I can freely change VideoInMode[0].Mode back and forth via API calls between VideoInMode[0].Mode=3 and VideoInMode[0].Mode=0
Unfortunately, I can't seem to force VideoInMode[0].Mode=0 if camera was left in VideoInMode[0].Mode=3 via the GUI.
That means I can't write a universal API call sequence to force the web 5.0 cameras into the needed VideoInMode[0].Mode=0 before issuing VideoInMode[0].Config[0]=0 or VideoInMode[0].Config[0]=0 commands.
Still poking away at it. There seems to be some setting that the GUI can adjust but we don't have via CGI.
Interestingly, when in that "locked" state after GUI set VideoInMode[0].Mode=3, the CGI does accept VideoInMode[0].Mode=3, but not other values. So, the command is recognized.
That leaves them in a state that will accept the old CGI commands issued by software written to control the older cameras via....
cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=0 <-- day profile
cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=1 <-- night profile
This seems to be related to the cameras being left in VideoInMode[0].Mode=0 which is the mode that accepts the old profile switches via Config[0].
If one forgets and leaves the Web 5.0 cameras in Customized Scene working mode (VideoInMode[0].Mode=3), the web 5.0 cameras refuse the old Config[0] settings.
VideoInMode[0].Mode=3 <-- camera is in scheduled customized scene mode and won't accept Config[0] settings
VideoInMode[0].Mode=0 <-- camera is in constant profile mode and WILL accept Config[0] settings
If camera is already in VideoInMode[0].Mode=0, I can freely change VideoInMode[0].Mode back and forth via API calls between VideoInMode[0].Mode=3 and VideoInMode[0].Mode=0
Unfortunately, I can't seem to force VideoInMode[0].Mode=0 if camera was left in VideoInMode[0].Mode=3 via the GUI.
That means I can't write a universal API call sequence to force the web 5.0 cameras into the needed VideoInMode[0].Mode=0 before issuing VideoInMode[0].Config[0]=0 or VideoInMode[0].Config[0]=0 commands.
Still poking away at it. There seems to be some setting that the GUI can adjust but we don't have via CGI.
Interestingly, when in that "locked" state after GUI set VideoInMode[0].Mode=3, the CGI does accept VideoInMode[0].Mode=3, but not other values. So, the command is recognized.
Last edited: