02-16-2023, 09:45 PM
Well it appears I didn't fix that 24 hour issue, (I say 24 hour but technically the first schedule doesn't run) now I'm hoping when you made your schedule instead of ticking every day of the week you used X number of days is 1?
First I edited the schedule I made yesterday so it would run immediately and it did. Then I created a new schedule but this time ticked the days and it worked, yesterday I used 1 day. I thought the schedule didn't actually run but I think I was wrong there, I'll know soon.
Anyways looks like it's nothing serious. You can be confident they will always run but of course monitor the log and how many mL's are remaining so you know. I keep my SSH terminal running 24 hours so I can see what's going on and know if the program ever crashed which I'm happy to say hasn't happened for well over a year and it's ran months not touched. I don't run the robotank.service instead just use sudo ./robotank to run it. I always check to see if schedules and custom rules do as they should, hasn't failed yet in my testing. I do love the scheduling system, when you know what the codes doing it's impossible to skip a schedule unless the program isn't running. Even if the Pi happened to lock up for X number of minutes when it resumes all schedules that were scheduled during the lockup will still run. Of course if the program goes in an infinite loop due to bad code then everything will be missed. This is mainly why I keep the SSH open so I can verify schedules and custom rules ran but that can be done through the log to.
I also just realized I only have the email and log entry happening from the scheduling code, the dosing system doesn't have it. I'm going to add that directly to dosing system as well, the function that starts the pump and when it stops. It adds a lot more to the log as 1 entry will be 3 now but I think it's worth it.
I also just realized I still have the possible infinite loop if the pca9685 can't verify it was actually switched. I'm going to change that to something like 100 tries, why not, and if not it will send alert and log, that should have been there to begin with. Maybe I'll even have it reboot the controller if it fails to verify as it's likely a locked bus. I guess like that though it's possible to have an infinite reboot loop if the I2C was down for the count. I guess I'll have to also add max number of reboots allowed lol. Before a reboot happens I could even save what it was trying to do so after reboot it'll know why it rebooted and then try switching that on/off again. This would be good if say a dosing pump didn't start due to locked I2C bus, after it reboots it would know to try again instead of skipping it.
What do you think of all this rambling? Just trying to think of ways to add fail safes. Before adding more features I want to do some polishing on what's here.
First I edited the schedule I made yesterday so it would run immediately and it did. Then I created a new schedule but this time ticked the days and it worked, yesterday I used 1 day. I thought the schedule didn't actually run but I think I was wrong there, I'll know soon.
Anyways looks like it's nothing serious. You can be confident they will always run but of course monitor the log and how many mL's are remaining so you know. I keep my SSH terminal running 24 hours so I can see what's going on and know if the program ever crashed which I'm happy to say hasn't happened for well over a year and it's ran months not touched. I don't run the robotank.service instead just use sudo ./robotank to run it. I always check to see if schedules and custom rules do as they should, hasn't failed yet in my testing. I do love the scheduling system, when you know what the codes doing it's impossible to skip a schedule unless the program isn't running. Even if the Pi happened to lock up for X number of minutes when it resumes all schedules that were scheduled during the lockup will still run. Of course if the program goes in an infinite loop due to bad code then everything will be missed. This is mainly why I keep the SSH open so I can verify schedules and custom rules ran but that can be done through the log to.
I also just realized I only have the email and log entry happening from the scheduling code, the dosing system doesn't have it. I'm going to add that directly to dosing system as well, the function that starts the pump and when it stops. It adds a lot more to the log as 1 entry will be 3 now but I think it's worth it.
I also just realized I still have the possible infinite loop if the pca9685 can't verify it was actually switched. I'm going to change that to something like 100 tries, why not, and if not it will send alert and log, that should have been there to begin with. Maybe I'll even have it reboot the controller if it fails to verify as it's likely a locked bus. I guess like that though it's possible to have an infinite reboot loop if the I2C was down for the count. I guess I'll have to also add max number of reboots allowed lol. Before a reboot happens I could even save what it was trying to do so after reboot it'll know why it rebooted and then try switching that on/off again. This would be good if say a dosing pump didn't start due to locked I2C bus, after it reboots it would know to try again instead of skipping it.
What do you think of all this rambling? Just trying to think of ways to add fail safes. Before adding more features I want to do some polishing on what's here.
