Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Robo-Tank v6.6 is Ready
#1
For a fresh install click this link - https://www.robo-tank.ca/forum/thread-1786.html
Hello, so it's finally here, v6.6, sorry it took so long. I think this year there will be many more updates to come so please stick with me. K05103 If you come across anything not working as it should, even if it's simple interface issue please let me know. 

Important: This update required two reboots as I enable the RTC using Raspian which confuses the flow. When you update after a minute or so the page should reload and a dropdown will likely show saying update is complete however it's not. It'll appear to work if you refresh the page but it'll lose connection again as it reboots without warning. It's best to simply hit update button and wait 5 minutes so you don't get confused with no connection. Then do the CTRL + SHIFT+ R on keyboard a few times to refresh the cache, even if it loads you have to do this.

Let's start with the good, issued fixed.

  1. This was something I overlooked that was serious, I found the issue when looking into why the system log had so many entries for custom rules being triggered, some of you made me aware of this and I was experiencing it myself which helped. The log was continually showing a custom rule turned off an outlet over and over without ever turning it on, based on the code that should never happen. Turned out it was a DS18B20 temperature sensor issue. I'm sure a lot of you have experienced a temp sensor disappearing from the homepage for a second before it reappears. This happens because I made adjustments to how often the 1wire bus search is done, once I did that sensors would randomly disappear. Reason I did this is for the auto detect system, I didn't like having to unplug a temp sensor and it doesn't disappear for a minute or two, instead it only takes a few seconds to know it's missing. Anyways due to this when a sensor disappears and there are more than one plugged in all the values shift in the variable array in the code. When that happens the custom rule sees a value from a different sensor then it expected which could trigger the custom rule. To fix this when a sensor disappears it's array location for the temperature is filled with an error code so the custom rule says ok the sensor is missing lets not go crazy. Now whenever you unplug a temperature sensor the custom rules are ignored in the backend which is great.
  2. If pH was being used in a custom rule it wouldn't work, now they should.
  3. There were a few problems with the schedules but nothing serious. First you were able to add a schedule without assigning a day so it did nothing but take up space. 2nd, if you created a schedule and used the "repeat every X days" and selected 1 it wouldn't run the first day it was created. And finally if a schedule was disabled and you filtered the schedule list it would disappear until you reloaded the page. 
  4. There were a few other minor UI improvements, bugs fixed and some improvements in various backend code that I didn't record.
Here's a list of changes and improvements.
  • Schedules - Now when a schedule or custom rule is created or edited the frontend list doesn't update until the backend responds saying changes were received and saved. Previously it waited half a second before redrawing the list.
  • Schedules - Removed "Off" option when creating a schedule for a dosing pump.
  • Schedules - Added validation when editing a schedule, without that it was possible to save without important data and crash the program.
  • System Logs - Added the port custom name to source field so it's easier to know the source.
  • Real Time Clock - Removed the setting to enable / disable the RTC however you can still set the date/time for it. Now the RTC is managed by the Pi operating system, if no internet is present it will use the RTC. Could someone please give this a good testing? In theory if you disconnect the internet from the Pi and set the date/time to something wrong you should see that as the working date/time.
The big change was with the dosing system, I completely reworked it, now stirrers are supported, dose in decimals and group scheduling, I think it's much better now. As I get more feedback I'll revisit it again down the road.

Here you can see it looks similar, you can edit the name, click the reservoir to change the color, refill reservoir, manual dose and view details. The difference is the number above each reservoir, that was previously how many doses were remaining but now it's how many milliliters are left in the reservoir. 

[Image: dosing6.PNG]

Now when you click the "Manual Dose" button it'll prompt for how much you want to dose. You can see a different when dosing 0.01 vs 0.1 milliliters.

[Image: dosing7.PNG]

Now you also get a prompt when you fill up the reservoir. I also added a setting to disable the reservoir so the pump runs even if the system thinks the reservoir is empty.

[Image: dosing8.PNG]

When you click the "View Details" button the other pumps disappear and it expands showing all the schedules. You can still view these from the main schedule screen. Notice the description in the pic says "Tester - 1 of 24" etc, these were created using the new group schedule feature, later I'll have groups collapse so they're easier to navigate. 

[Image: dosing9.PNG]

When you click "Add Single Schedule" button it takes you to the main schedule page, down the road I will integrate this into the screen above, I got lazy. When you save it will take you back to dosing screen. Now you can enter how many milliliters to dose for each schedule you create instead of one setting for everything.

[Image: dosing10.PNG]

When you click "Add Group Schedule" you can add a group of schedules like I mentioned previously. That group had 24 schedules which is why is said 1 of 24 etc.

With this you first select the total number of milliliters you want to dose and select a start and finish time. Then you have two options.
  1. Dose X milliliters per dose which will do the following. Example: 120 mL total between 6am and 6pm dosing 10 mL per dose would give you 12 schedules or 10 mL per hour.
  2. X number of doses during time frame. Example: 120 mL total between 6am and 6pm split between 12 doses. This would also you give 10 mL per hour.
[Image: dosing11.PNG]

If you click the "Stirrer" button you get the following screen. Here's all the settings for the stirrer. 
  1. First box you can see checkbox to enable the stirrer and a drop down to select a port. To add stirrers to the system you go to the "Configure Ports" screen, select the port AC or DC that you want to plug in stirrer and change the "function" to "dosing pump stirrer". If you have 3 ports setup as stirrers they will all appear in the drop down unless one or more stirrers are assigned to another dosing pump. This makes sure you can't accidiently assign the same stirrer to multiple pumps. 
  2. Next box you can set the speed of the stirrer if using a DC port, if you use AC port it won't do anything. When you move the slider the stirrer will turn on so you can instant feedback on the speed.
  3. Next box is how long the stirrer runs.
  4. Last box is how long to let the reservoir settle. When a dose is activated the stirrer will immediately turn on for X seconds, when it turns off it'll pause for X seconds before running the pump.
[Image: dosing12.PNG]

If you click the "Calibrate" button you get the following screen, this is the same however now you can adjust the speed of the pump if using a DC port. I felt this was a good spot for it as it's likely to be adjusted during calibration. Like the stirrer when you click on the slider the pump will start running so it's easier to tune. It's possible this could be bad in some scenarios so I may add a checkbox so the pump doesn't start when adjusting.

[Image: dosing13.PNG]

And finally when you click the last button "Settings" you get the following screen. 

  1. First box you can adjust the reservoir capacity, when you release the up/down buttons it'll show a popup asking if you want to refill the reservoir. I did this as it's possible you want to adjust the size but not refill it. It's also a bit of pain, if you press up 5 times in a row you get 5 popups. Down the road I'll allow a user to override the milliliters remaining with any number.
  2. Next is "Minimum Delay Between Doses", this is basically a fail safe so the system doesn't overdose for whatever reason. I need a better title for this, if you set it to 120 minutes that means the pump won't run more than once in a 2 hour period not matter what other systems want.
  3. Next you can enable/disable the reservoir feature. If enabled the pump won't run when reservoir is empty, if disabled the pump will still run.
  4. And the last two boxes allow you to setup an email alert when the reservoir is low. One of these days I'll get the dashboard alert system running, it won't be too difficult. 
[Image: dosing14.PNG]

Here's a couple pics for the custom rules showing the changes for dosing pumps. You can see one that activates 2 dosing pumps, one doses 10.2 mL and the other 5.8 mL. One doesn't start for 10 seconds after rule starts and the other 2 seconds. (Upset it says "Switches 10 seconds" I thought I change that to "Dosing starts", too late now, haha) And the last setting it suspends more dosing for 30 minutes and 10 minutes. This is another fail safe so it can't overdose.

[Image: rules26.PNG]

And this is where you enter the delays etc when creating the custom rule, I also did a little cleaning up the formatting. One day I plan to redo these screens as I'm not in love with them.
[Image: rules27.PNG]

This is what the system settings page looks like now. The box to enable/disable RTC is gone and a new button to view the version log. 

[Image: system3.PNG]

One new addition is a version log. Since the beginning I tables in the database to track changes although many things I did I didn't record so it's incomplete. Anyways you can see this using the button shown above. If you expand an update you see the changes. I know nothing exciting and I didn't spend much time on it.

[Image: versionLog.PNG]
Reply to top
#2
Tried to upgrade, but even after clearing the cache, pressing CTRL+SHIFT+R, waiting 15 minutes, manually rebooting the Pi, i'm still getting a black page
Reply to top
#3
I was able to bring the system online again, but now both temperature sensors are missing.
Reply to top
#4
Sorry not sure what could have happened. For the temp sensors if you go in the database to "DS18B20" table, you can change "plugged" to 1, reboot and they should reappear.
Reply to top
#5
Setting that to 1 they appear, but doesn't fetch temperatures.
I had to change the pin in dtoverlay inside the config.txt
it's 23 not 22 (or the opposite, I don't remember)

Anyway, after a while of proper working, one of the two temp sensors stopped to read tempeatures again.
Reply to top
#6
dosing schedule doesn't work. i can see the notification email but the pump doesn't dose. manual dosing works.

changing the pump speed doesn't work, i can drag the slider but no changes happens on DB
Reply to top
#7
That's disappointing. I have 32 schedules I've been running for a few weeks and they have never failed so I just added a new one and as you reported it doesn't work yet my others are still working. Looks like I broke something, I'll have to dig into it and see where the problem lies. I can confirm the schedule is triggering so it seems the problem is with the dosing system.

Not sure about the temp sensors, I need more info to look into it as I can't replicate the problem.

I think changing the pump speed may be related, I just tried mine and it's working so not really sure at this point but will look at the code.

If you haven't already it might be worth doing a fresh install, if the temps and pump speed is still and issue send me your database so I can try and find the problem. As I experience the schedules not fully triggering I should be able to find the problem.
Reply to top
#8
but if you confirmed the problem adding a new schedule, why you need the database? Just curious...

the Speed issue is due to the wrong db field, you are using a tinyint (-127 to 127) to save values up to 4095 that wont fit. changing the column type fix saving the Speed on DB but still doesn't run the automatic dosing
[-] The following 1 user Likes gandalf's post:
  • Rob F
Reply to top
#9
Now dosing is started again, i didn't touch anything.
Probably the first dose happens 24h after the reboot ? yesterday i've rebooted the Pi and nothijgn changes, but now seems to dose as expected.
Reply to top
#10
I was asking for the database to hopefully track down the pump speed issue. I typically ask people to send it if I can't reproduce the problem as we are using the same code so the only difference should be data in the database. I also enjoy seeing how people have things setup and helps me to see things in a different light sometimes. Probably for next update I'll have a button so people can send it easy, it'll remove login password even though it's not possible to decrypt, at least not for me, and remove the email credentials which can be easily decrypted even though I would never do that as I just don't care. :)

Thanks for finding and letting me know the issue with the pump speed, this is the 2nd time you've pointed out a bad variable type however this time I have a reason. Checked my database and I have a small int which is good to 65535 but when I first added the setting I was only using 0-100% vs now 0-4095. When I made that change I forgot to change it in the update function, just checked that and yeah it's set to tiny int. I'll have to start going though that function just before I publish to make sure I didn't do something like this. 

Glad the dosing is working, the 24 hour is a good guess but I'm thinking it's something else. Unfortunately I was around when the new schedule I made yesterday went off so not sure if it works now. In v6.5 if you created a schedule using X number of days set to 1 it wouldn't fire until 24 hours passed but in that scenario the schedule didn't fire. With this the schedule was definitely being triggered, that's the reason you still got the email and I could see in my terminal that it was activated but for some reason the dosing didn't get triggered. Tonight I'm going to try and see what it is.
Reply to top
#11
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.
Reply to top
#12
i reply better in a hour but yes im using the 1 day repeat but im almost sure i had the same with ticking each days. in fact i've recreated the schedules by choosing 1 day repeat because the ones with each day selected didnt started
Reply to top
#13
(02-16-2023, 09:45 PM)Rob F Wrote: 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.

I've edited the schedule multiple times but never started until the 24h (or near that) expired.

Quote: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.

Seems all good and the new dosing schedule is very interesting, i'm using with 24 dose daily on each pump

BUT as you changed the dosing system allowing for groups, you should add a "parent_id" field in database to join the schedules together. In this case, when you have to change something, you can change from the parent schedule (the one with "parent_id" null), then delete everything having "parent_id" set to the main schedule and re-add them from scratch with the updated parameters. Actually I have to delete 5 * 24 schedules every time i need to do a variation. I don't think having a mass-update would be any usefull, if you can delete and add sub-schedules every time.
Let's suppose I want to temporary disable the pump 3 schedule, I have to disable 24 schedules one by one. with my proposal, it's just one click on the main schedule (then all sub-schedules are deleted and recreated with disable flag set)

It should be trivial to add this feature.

Anyway, one of the two temp sensor doesn't work.
Reply to top
#14
That's what I experienced when editing the schedule as well, after 24 hours it was fine.

I do plan on keeping groups together, just didn't do it now as I want to see how this goes and didn't want to spend all the time on the UI till I know this will work for most. I may still add a few options on the group schedule that could affect the layout. I know having pages of schedules definitely isn't ideal. When I change I can use the custom name to find groups.

Don't know what to think about the 2nd sensor other than it happened to die. Do you see both sensors in the /sys/bus/w1/devices/ folder and can you read it from there?

If so maybe go in the database, delete it from the DS18B20 table, reboot the controller and see if it finds it again. If your start the app with sudo ./robotank you'll see output of how many sensors are detected. Maybe it shows up there just not in the UI. I haven't touched the temp system for a long time so I don't think I just caused it, maybe an older bug causing it.
Reply to top
#15
(02-14-2023, 10:07 AM)gandalf Wrote: I was able to bring the system online again, but now both temperature sensors are missing.

And how, pray tell, did you achive that? :D
I've got the same black page. Tried to log in via phone and there actually was the robo-tank login page, but after login: blackness. (Or ist that page cached? No idea how to hard reload using a phone ^^; )
Could it be something about the browser? I Didn't test others than Firefox yet. Because lately the graphs have been glitching in and out of existence. That's actuayll why I manually triggered the 6.6 update.
[-] The following 1 user Likes TheYear2525's post:
  • Rob F
Reply to top
#16
I would like to know that as well. :)

It may or may not be cache related, sounding like it isn't though. Firefox should be fine, Once and a while I open it in Firefox and Edge to do some basic tests, I use Chrome for developing so know it best. If a browser is an issue it's typically something in the UI that doesn't look right.

If you have Chrome, right click on the page and click "inspect", a window will open in the browser. In that window there are tabs at the top, click the "console" tab. Then reload the page again, this time click and hold the refresh button and a drop down will appear. Then click "empty cache and hard reload". If it's still blank send me the info in the "console" you opened. That should tell me where it's getting stuck.

Clearing cache is a pain on the phone, you have to go in settings and clear history and click all checks. This will empty all cache though so maybe you don't want that. I'll have to look at renaming the cached files during updates so the refresh isn't necessary.

For the graphs, how long have you been running the software? After the get a few months of data they definitely load slower but have never experienced glitching, what do you mean by that?
Reply to top
#17
I had to change some php code, i don't remember exactly which files.
For sure, there was some error in some queries, some variables was not used properlty (missing the "$" sign, thus php was considering them as undefined constants)
Reply to top
#18
I'm not doubting you have found some issues, please let me know when you do, but I don't think this is the cause as a couple others have updated with no issue. If the problem was in the code that wouldn't have been possible nor would I have been able to update multiple times from fresh 6.5. The blank screen after update is a definite issue though, hopefully I can sort it soon. That issue you pointed out with the stirrer speed won't matter during update as the database isn't trying to save a value out of range, only when a person goes to change it. I have fixed that for the 6.6 update so it shouldn't be a problem going forward.
Reply to top
#19
(02-22-2023, 07:58 PM)Rob F Wrote: If you have Chrome, right click on the page and click "inspect", a window will open in the browser. In that window there are tabs at the top, click the "console" tab. Then reload the page again, this time click and hold the refresh button and a drop down will appear. Then click "empty cache and hard reload". If it's still blank send me the info in the "console" you opened. That should tell me where it's getting stuck.

Clearing cache is a pain on the phone, you have to go in settings and clear history and click all checks. This will empty all cache though so maybe you don't want that. I'll have to look at renaming the cached files during updates so the refresh isn't necessary.

For the graphs, how long have you been running the software? After the get a few months of data they definitely load slower but have never experienced glitching, what do you mean by that?

I'll try that this weekend.

I have been running robo-tank for 14 months now. I keep the browser tab open and occasionally need to log in again. That's no problem. Robo-tank is so far only running a temp and a pH probe which are displayed on the dashboard and show the latest 7 days. Starting a few weeks ago these sometimes didn't display anymore, including the grid. They used to display instantly after login, so I don't think that any lag has been gradually building up there. After some time and/or wildly clicking around in the ui they might reappear but sometimes only the upper one (temperature) appears. Going to the graphs tab in the ui and back to dashboard did make this one reappear last time.
Even when the graphs are not shown, the settings for them will appear when you hover over the approriate area (that bar where you can click on buttons like "7" (days) etc.

In case your chrome suggestion won't lead to anything I'll try to get into the system this weekend, I think I've forgotten the pi login, though. Note to self: start using a password manager already K0505 !
Maybe I restarted the pi too early after seeing nothing happening after the update was supposedly done (= keep getting a black page for a few minutes after hard reloding). I didn't know this update would take longer than usual. Maybe robo-tank isn't loaded at all? But in that case, wouldn't there be just a page/server not found error?
Reply to top
#20
Oh wow, that's a long time and will be an insane amount of data for the graphs, with some quick math at 5 minutes per write would be 122,400 lines per chart. I think maybe that's the limit for dygraphs which is pretty decent. I just made my own chart for dosing and ATO, after a few hundred lines there's a lag haha. Unfortunately dygraphs reads from CSV files which are much harder to edit via code, I need to add a trim method so maybe no more than 100,000 entries are recorded. As things are recorded every 5 minutes ideally I would like to remove lines between readings say after a week or two, maybe space readings out 1-2 hours which should be fine for historic data.

To fix this you need to either delete the chart CSV files or open them and remove 90% of the data. Opening them in the SSH could be difficult as that's a large file. Here's how to get to the chart files via SSH.

cd /var/www/html/chartData

Then run ls command to see the files. The sensor ID is the file name.

To delete the file run the following commands but replace the file name with yours. Note C and F have their own file.

sudo rm 0317028addff_C.csv

sudo rm 0317028addff_F.csv

For program not running do the console thing which will tell us if problem is in the frontend. Then do the following to see if problem is with the backend. Run the following commands to start the program manually, if it runs and doesn't crash then backend is ok.

cd /var/www/html/cpp

sudo systemctl stop robotank.service

sudo ./robotank


If it crashes you'll be able to run another command, if it runs you can't run any more commands in that SSH terminal as the program is running, you would need to open a 2nd.

If it crashes run the following command.

g++ -o robotank robotank.cpp `mysql_config --cflags --libs` -lpthread -lquickmail -lcurl


The run this again.

sudo ./robotank

If it still crashes it could be a database issue. Send me the output from the SSH so I know where it's crashing.
Reply to top


Possibly Related Threads…
Thread Author Replies Views Last Post
  Robo-Tank v6.0 is Ready - Now v6.5 Rob F 403 175,770 02-13-2023, 12:03 AM
Last Post: Rob F

Forum Jump:

Current time: 03-28-2024, 11:40 PM