CroatianMeteorNetwork
Add a feature to camera control, so that "noon" can be used as a sentinal value which will calculate the local solar noon in camera time
(vRMS) au000a@walnut:~/source/RMS$ sudo timedatectl set-timezone Australia/Eucla
(vRMS) au000a@walnut:~/source/RMS$ date
Sun 3 Aug 21:30:34 +0845 2025
(vRMS) au000a@walnut:~/source/RMS$ python -m Utils.CameraControl SetAutoReboot Everyday,noon
Loading the default config!
Creating directory: /home/au000a/RMS_data
Success: True
Creating directory: /home/au000a/RMS_data/logs
Success: True
2025/08/03 12:45:42-INFO-CameraControl-line:612 - replaced "noon" with 13.0 for machine time noon
2025/08/03 12:45:42-INFO-CameraControl-line:624 - Set autoreboot: Everyday at 1300
Shutting down logging...
Logging shutdown complete.
(vRMS) au000a@walnut:~/source/RMS$ sudo timedatectl set-timezone Australia/Perth
(vRMS) au000a@walnut:~/source/RMS$ date
Sun 3 Aug 20:45:55 AWST 2025
(vRMS) au000a@walnut:~/source/RMS$ python -m Utils.CameraControl SetAutoReboot Everyday,noon
Loading the default config!
Creating directory: /home/au000a/RMS_data
Success: True
Creating directory: /home/au000a/RMS_data/logs
Success: True
2025/08/03 12:46:02-INFO-CameraControl-line:612 - replaced "noon" with 12.0 for machine time noon
2025/08/03 12:46:02-INFO-CameraControl-line:624 - Set autoreboot: Everyday at 1200
Shutting down logging...
Logging shutdown complete.
(vRMS) au000a@walnut:~/source/RMS$ sudo timedatectl set-timezone UTC
(vRMS) au000a@walnut:~/source/RMS$ python -m Utils.CameraControl SetAutoReboot Everyday,noon
Loading the default config!
Creating directory: /home/au000a/RMS_data
Success: True
Creating directory: /home/au000a/RMS_data/logs
Success: True
2025/08/03 12:46:29-INFO-CameraControl-line:612 - replaced "noon" with 4.0 for machine time noon
2025/08/03 12:46:29-INFO-CameraControl-line:624 - Set autoreboot: Everyday at 400
Shutting down logging...
Logging shutdown complete.
(vRMS) au000c@walnut:~/source/RMS$ python -m Utils.CameraControl SwitchMode day
Loading the default config!
Creating directory: /home/au000c/RMS_data
Success: True
Creating directory: /home/au000c/RMS_data/logs
Success: True
2025/08/03 13:13:32-INFO-CameraControl-line:406 - NTP disabled
2025/08/03 13:13:32-INFO-CameraControl-line:612 - replaced "noon" with 4.0 for station solar noon
2025/08/03 13:13:32-INFO-CameraControl-line:624 - Set autoreboot: Everyday at 400
2025/08/03 13:13:33-INFO-CameraControl-line:795 - time set to 2025-08-03 13:13:33.356596
2025/08/03 13:13:33-INFO-CameraControl-line:515 - Set Camera.Param.[0].DayNightColor to 0x00000001
2025/08/03 13:13:34-INFO-CameraControl-line:515 - Set Camera.Param.[0].ElecLevel to 50
2025/08/03 13:13:34-INFO-CameraControl-line:489 - Set Camera.ParamEx.[0].BroadTrends.AutoGain to 1
2025/08/03 13:13:34-INFO-CameraControl-line:472 - Set Camera.ClearFog.[0].enable to True
2025/08/03 13:13:34-INFO-CameraControl-line:472 - Set Camera.ClearFog.[0].level to 30
2025/08/03 13:13:34-INFO-CameraControl-line:92 - Camera rebooting, please wait....
Shutting down logging...
2025/08/03 13:13:40-INFO-CameraControl-line:101 - reboot successful
Logging shutdown complete.
If you think that makes sense, could you also update the default camera_settings.json as part of this PR?
["SetAutoReboot", "Everyday,noon"],
I think Mark is right. If you set the time using the set time command, time zones do not matter.
If you use the camera's NTP client, then it does matter. Since folk might use the NTP client, we should take that into account.
Did I get that right?
So, I have three options.
-
Get the camera time, and whatever it is, compute when solar noon will be. I like that because it changes the fewest settings, but it is a bit eccentric.
-
Set the camera timezone to the machine timezone. That's what I think is most sensible, and what I would do for my own systems.
-
Force the cameras to UTC. I don't think we should be changing settings on people's equipment.
So it's a choice between 1 and 2. Personally, I think 1, because it is the least invasive, but happy to hear other folks thoughts.
All the other comments about inlining, sure, happy to do.
Right, I think if we want to support NTP and non-NTP, and don't want to alter the camera TZ, then option 1 it is:
- set camera time (ignored if NTP enabled?)
- get the delta (d) btw now and target time
- get the camera time (tc)
- set reboot time = round(tc+d).
There was also Mark's idea to reboot a moment before night capture starts. Should the target only be noon? Should dusk be an option?
Then there's also the option to deadman reboot: always attempt to push back reboot to the next hour except for the reboot hour if any (requires a watchdog process).
Edit: actually maybe it doesn't need a watchdog, just send the command moving back reboot to the next hour every hour. If the command doesn't land, camera reboots.
We should not set the camera time as part of this command. A command to set the reboot to noon has a bug if it changes anything other than the reboot time.
An operator might have set the camera time to some time, for some reason that we do not know, and we should not be changing it, unless explicitly asked.
All we need to do is compute the time of station noon, and transform that into camera time, and schedule a reboot at that time. We could reboot at dusk, but that adds complexity, and I'd like to keep the simplicity of this piece of code. The other problem with dusk, is that dusk does not happen everyday everywhere on a planet. Polar regions can go for hundreds of hours without a dusk. I do not consider planets with multiple stars for this pr.
As for resending commands, that is already taken care of. I set the reboot time at each transition to night mode, and I think other code keeps resending the transition to night mode.
Fair point about not setting time first, but then when we do set time or set tz, should it trigger a new noon computation automatically?
I do not consider planets with multiple stars for this pr.
Whut? We just had a request from someone on Tatooin ;)
As for resending commands, that is already taken care of. I set the reboot time at each transition to night mode, and I think other code keeps resending the transition to night mode.
Sorry, I'm not following.
This is the line I'm referring to
https://github.com/g7gpr/RMS/blob/b073443ca0012e0f4a0b3521ccdbf8ee8156bc9b/RMS/CaptureModeSwitcher.py#L53
Fair point about not setting time first, but then when we do set time or set tz, should it trigger a new noon computation >automatically?
No, I don't think we do. If someone wants to change the timezone, or the time, without updating the reboot time, then let them. Far better to do that than have an operator unable to change the timezone or time without changing the reboot time.
I fall back on my philosophy that a command should do what it says it will do, and nothing more, and ideally nothing less.
OK. I've done what I can on this for now. I didn't inline all the functions, as the function to get the camera time got a bit complicated; I'd appreciate @markmac99 looking at the computeCameraTimeOffset function, especially the logic for getting the cameras time, as I'm copying code here.
I fall back on my philosophy that a command should do what it says it will do, and nothing more, and ideally nothing less.
I agree with the philosophy of simplicity, but it should be applied consistently to both the internal and external interfaces.
Users reasonably expect that SetAutoReboot Everyday,noon will cause the camera to reboot at solar noon every day. However, this expectation isn't met with the current implementation.
The issue could be resolved if setting the timezone or time automatically triggered a recalculation of the solar reboot time. From a user's perspective, it's counterintuitive that we need to explicitly reset the auto-reboot schedule every time we update the camera time:
["CameraTime", "set"],
["SetAutoReboot", "Everyday,noon"],
While the internal interface should be as simple as possible to support a simple external interface, it shouldn't be simpler than necessary. The current implementation sacrifices user experience for internal simplicity, requiring users to understand and work around an implementation detail that should be transparent to them.
From a user's perspective, it's counterintuitive that we need to explicitly reset the auto-reboot schedule every time we update the camera time:
If i have followed the logic correctly, we'll only need to do this when the camera is initially set up, or if its moved to a significantly different longitude. Initially its internal clock is likely to be way off since theyre terrible timekeepers and were probably tested in China many many months ago. So we'd need to set the internal clock. Once thats done we can determine the right reboot time to apply based on its longitude and the (now correct) internal value of its clock.
From then on, the clock might drift and hence the actual reboot time might drift. But if the operator corrects the camera's internal clock it'll also correct the drift in the reboot time, without any need to update the latter which will remain correct as long as the camera's longitude doesn't change by more than 15 degrees.
I think i have the logic there correct, but i will see if i can work out a few tests.
Used the already initialised cam object, thanks. I knew I was making heavy weather of it. Returning None instead of zero for failures.
From a user's perspective, it's counterintuitive that we need to explicitly reset the auto-reboot schedule every time we update the >camera time:
How does the code know whether the operator has set the reboot time to "noon" or to a specific local time?
Yes, I think you have the logic correct. I'm writing unit tests at
https://github.com/g7gpr/RMS/blob/feature/Utils/CameraControl/RebootAtNoon/Tests/RebootAtNoonTesting.py
Any feedback on the test would be welcome; they are not yet complete.
From a user's perspective, it's counterintuitive that we need to explicitly reset the auto-reboot schedule every time we update the >camera time:
How does the code know whether the operator has set the reboot time to "noon" or to a specific local time?
One workaround for this is to add a warning to the code that sets the camera time and/or timezone. This could check if the clock is going to change by more than an hour, and if so, print an advisory. Then its up to the operator to decide whether to update the reboot time.
"One workaround for this is to add a warning to the code that sets the camera time and/or timezone. This could check if the >clock is going to change by more than an hour, and if so, print an advisory. Then its up to the operator to decide whether to >update the reboot time.
Yes, I like that. Unless anyone has any better ideas, I'll implement that.
