Testing SWG auto-dosing #348
Comments
|
wait a minute... just saw that I didn't have the SWG model set in the Chlorinator settings. Set that to IC40 and got this... looks like it's working! Will track throughout the day |
|
Had a weird hiccup during the 5 minute cycle above where the dosing stopped counting up 20 seconds into the 5 minute cycle. Checked the logs and it said ..which was odd because I had just set it. I set it again and it looks like it has stuck this time. At least it finished the cycle. |
|
kind of an odd sequence at the end of that swg dosing cycle... |
|
hmm, lost the SWG model again... willl try to restart njspc to see if it sticks. |
|
yea, might have to table this until I can get the SWG model to stick in settings. Hope this capture helps. Let me know if you need another one. |
|
@DrJeff said he lost the model, as well. Need to see why that's happening and will dig into your logs. The current calcs are:
It will appear "paused" if... Scenarios 4 & 5 above may take up to 30s to resolve themselves because the OCP only sets the chlor every 30s. The 'no chlor response in 7s' just indicates a lost packet. It shouldn't have any effect on overall performance. |
|
I think I know. It has to do with the 3 message coming back from the Chlorinator. I am running tests now but if you pull I added a check to make sure it doesn't overwrite the model. |
|
Oh, nice. 🤞 I also think we need to normalize the chlorinatorType with the chlorinatorModel maps. We shouldn't need both and one can be set independent of the other but they should be related. But that's a different (internal) issue. |
|
just pulled |
|
Looks like the chlorinator is keeping and it set the proper one off the back, for me so far. |
|
Yep, the SWG sticks in the settings now. Day 1 wrap - partial day so just leaving here as a data point. reminder, my ORP setpoint is 620 and my probe was reading between 590-600. After enabling SWG dosing (and getting it to stick), the SWG alternated between setpoints of 0 and 100, ~5 minutes on / ~10 minutes off: ORP reading fell slight to the ~580 range during this time (to the right of the red line when I turned on SWG dosing). Note: this was not unexpected. SWG dosing has never had an immediate effect on ORP in my pool. But usually increases within a day or two. Will continue to keep an eye on it and take some FC readings in the morning. |
|
DAY 2 Maybe related, I keep getting SWG comms dropouts during dosing cycles. I don't think this is caused by njspc, maybe flow sensor going bad? or maybe just normal operation? It always seems to resolve itself within a few seconds and then dosing resumes. |
|
quick update: dosing was more frequent in the AM when ORP was >50 below the setpoint of 620 after ~1:30 dosing became less frequent, presumably because ORP rose to more than the threshold minus 50 looking good! will check FC and post back in the AM |
|
DAY 3 update: FC dropped to 4 (still good) still looking good! |
|
something that may be of interest... I have pH dose priority turned on. My understanding is that will pause ORP dosing (set to 0%), perform the acid dosing, and then resume the ORP dosing when the acid is done. This is how Pentair does their dosing if you use their dumb IntelliPH controller. I was noticing some short ORP cycles and thought it might be related to pH dose priority so I followed along in the logs and ran across an unhandled rejection around the same time the acid dose was about to start: I didn't get a packet capture, unfortunately. What ended up happening is the acid dosed as expected and the currently running ORP dosing cycle was cancel and ORP mixing started. If this is expected, no worries. I just thought it would resume the ORP cycle once acid dosing was complete. @tagyoureit Let me know if I'm tracking this right... |
|
DAY 5 update: Coming up on the weekend so we'll see how it does when we swim and add chemicals this weekend ;) |
Yes... this is the expected behavior. pH Dose Priority will mean the Chlor (or tank) will stop dosing so there isn't the introduction of new chlorine and acid at the same time. Maybe @rstrouse can help me with the unhandled promise rejections? I've tried 12 different ways from Sunday to capture those so they don't throw an error (hence the final catch-all is the text display of the rejection so the app doesn't actually crash when we move to Node v14/16 and you can't have an app with uncaught exceptions). But it's still eluding me why they are appearing. You can safely ignore them as I'm dealing with them and they won't affect any dosing. I'm pleasantly surprised that the ORP is so accurate. I really did just make a "best guess" and excited to see it working as expected! Thanks for testing it out. |
ok, thanks for confirming DAY 6 update
Took an FC reading this AM and FC was boosted to 8. ORP was ranging between -50/+20 of my setpoint so there was repeated dosings that averaged about 28% output for the last 2-3 days. Today ORP is around 660 (setpoint of 620) so dosing has been off most of the afternoon. Hopefully that will bring FC back down a bit. Otherwise I might have to drop the ORP setpoint to 600-610.
It's going to be a long game to see how the ORP dosing algo does but if it can keep FC in the 3-6 range on average I would call that a win. Will keep posting updates. chem: |
|
Remind me again what you had your chlor set at before allowing njsPC to control it. I know you told me but too lazy to search... I mean it's too hard to find. :) And how did those graphs look compared to these? |
|
This graph sort of shows it. I've been toying with the ORP setpoint (dashed red line) every 1-2 months to dial it in but I'm currently at 620 and ORP was ranging as low as 550 and as high as 700 using my dumb dosing method. Subsequently, FC ranged from 3 to 9 in the same timeframe.
If your dosing algo can tighten up both the ORP and FC ranges, then it's a keeper. Will take time to observe but I'm not going anywhere. |
|
|
|
What field are you using for demand? Didn't see one in the chemControllersOrp measurement.
|
|
|
|
grr... was using a custom influx binding so I'm not on the latest and now stuck in diff land. Probably should write up a script that injects my bindings into the repo InfluxDB.json as it gets updated... |
|
Better yet, your custom binding should be a different name that you specify in config.json. Then you won't get merge conflicts when you pull. |
|
right, I have that - no merge conflicts, just wasn't adding back in the new fields to my custom binding as you guys were adding them to influx.json. all is right with the world now. Will just take a bit for the graph to fill out
|
|
I just pushed up a change that will allow the ChlorORP to go through the full dosing/mixing/monitoring cycle. Previously it was only doing dosing/mixing and if the demand was <-20 the mixing would be the full 15 mins. This worked fine it just meant that there would be emits every single second of every single day no matter what the status. Now there is a true monitoring cycle where Nixie will monitor the demand every 10s and only kick on the dosing/mixing cycles as needed. And one more change, @rstrouse corrected my (yet again, I might add) that Nixie should never actually be setting the Chlor Setpoint. Rather, we are using flags to override the setpoints to either dose at 100% or disable the chlor at 0%. This is a nuanced change but it might affect what you see in the Grafana logs. EG you should not be looking at 'chlor swg setpoint' anymore as it isn't what we are controlling. You should be looking at targetOutput vs currentOutput if you want to see what we expect the chlor to be doing vs. what it is actually doing. (I also added target output to the influx binding because it was missing.) |
|
looks like it is working: re: targetOutput vs currentOutput - what scenario would these two values be different? |
Here are my last few hours with the new changes (image below). On the bottom the orange is the currentOutput and the blue is the targetOutput. It shows the difference in what we are asking for vs. when the chlor actual is dosing the right amount. It should be max ~30s difference if the OCP is slow on telling the chlor what to output. Without Nixie ChlorORP the poolSetpoint would normally indicate the targetOutput but since we aren't controlling the values from the internally passed flags poolSetpoint is being overriden and will not equal targetOutput.
(I can probably downgrade some of those "info" level logging... will look at that. They are just clogging up the logs.) |
|
@johnny2678 I'm guessing your readings might be all messed up because of the probe recalibration, but I've tweaked my graph a bit and wanted to share.
I actually dropped the demand in favor of simplicity and knowing that I never change the setpoint. And once I inverted the demand axis it mimicked the orp so wasn't necessary. Any time the ORP falls below the red line (demand >20) you can see the Chlor stays at 100%. The overall average is only 19% of the time which sounds a bit low but that's over a full 24 hours/day, not the time the pool is on... but still interesting to see it's on quite a bit less then the 44% (over 24 hours) when I just had the chlor set at 100% all the time. |
|
thanks for posting @tagyoureit I can (mostly) match that: But as you said, I haven't really given the autoORP algo a fair shake since turning it on. Ex. #1 in the picture - I chickened out because FC had fallen to 2.5 and SWG dosing hadn't kicked in yet so I upped the setpoint. ORP was falling that day and dosing would probably have kicked in if I had let it. Obviously I dropped it back down to 620 after a day. Also, that day was the day I updated njspc and my influx bindings to include Target Output. #2 - The way I run my pool is 12 hours on a reasonable RPM (2200), and then another 4 hours on a very low RPM (1450), just to keep the water moving a bit longer. The RPM is low enough to trigger the "low flow" state in the SWG, which can be observed in #2 where current output never matches target output. #3 - as you already mentioned, I recalibrated my ORP probe. Here it is with FC added in: ORP is well above my setpoint for now (currently 718 with a 620 setpoint). FC is at 3 - just took the reading. Will try and be more hands-off from now on and let it do its thing ;) |
|
@johnny2678 How has this been working? Has it had a chance to settle in without your meddling? :) |
|
woo boy, not even sure where to start. 1st, I have not been able to give this much attention. New baby, work, life, etc...
2nd, I've had a couple of wild swings in FC but I think it was self-inflicted. My prior dosing routine worked with an ORP setpoint of around 610. FC wasn't entirely stable using my dosing method, but it kept it above above the danger zone (2-3 FC). When I switched to REM dosing, FC tightened up a bit. I think your dosing is more accurate. But I never adjusted my 610 setpoint which probably needed to at least be 650-670. Sure enough, FC dropped below 1 and I had a cloud pool for a week. After a slam at 12FC, it returned to normal so now I'm just on the hunt for the right ORP setpoint.
Not helping matters is I've had a few hangs / drop-outs that either keep the system from dosing at all or leave it pegged at 100%. Not putting this on njspc, I just haven't had time to troubleshoot. Usually a Pi reboot gets everything squawking again. Happy to keep posting back with observations but no reason to keep this issue open. I can always ping you on gitter if I have questions. bottom line, I'm not going back to my dosing method. Just need to get SWG dosing via REM dialed in. |
|
Well congrats on the new baby! I get the busy part, so we'll close this for now. Thanks for all the great feedback and testing! |
@tagyoureit - I turned off my SWG dosing routine and turned on the SWG dosing settings in dash. Will use this thread for questions - status updates
First off - pool FC as of yesterday afternoon was 5.5 ppm
CYA - 20
TA - 70
CH - 400
pH - 7.7 via Atlas Consumer probe (or 7.4 according to Taylor kit - still working that out)
Salt - 3600 via Taylor salt kit
First question:
ORP setpoint is 620 and it's currently reading 601.4. Should it be doing something now?
The text was updated successfully, but these errors were encountered: