SWG setPoint changes immediately revert

[johnny2678]

To Reproduce In dashPanel:

• change pool setPoint using the +/- (or manual entry)
• it will revert to original value

Expected behavior new setPoint will be committed

Packet Capture attached... replay (1).zip

Pool Equipment

• Controller: EasyTouch 2 4
• Controller Firmware Version: not sure
• Pump(s) manufacturer and model: Pentair VS
• Chlorinator: IntelliChlor-40
• Heater(s): Pentair Mastertemp
• Chemical controller: homegrown

Additional context

looks like SWG packets aren't completing

3|poolController  | [2/21/2021, 11:23:59 AM] info: [11:23:59 AM] 192.168.5.31 PUT /state/chlorinator {"id":1,"poolSetpoint":75}
3|poolController  | [2/21/2021, 11:23:59 AM] verbose: Wrote packet [255,0,255,165,56,16,33,153,10,1,15,0,0,0,0,0,0,0,0,1,193].  Retries remaining: 3
3|poolController  | [2/21/2021, 11:23:59 AM] verbose: Wrote packet [255,0,255,165,56,16,33,217,1,0,1,232].  Retries remaining: 3
3|poolController  | [2/21/2021, 11:24:08 AM] debug: Packet not processed: 255,255,0,255,165,56,16,34,215,1,1,1,232
3|poolController  | [2/21/2021, 11:24:08 AM] debug: Packet not processed: 255,255,255,255,255,255,255,255,0,255,165,56,15,16,23,16,1,0,0,0,1,245,8,52,0,0,0,0,0,1,0,128,2,215
3|poolController  | RS485 Stats:{"bytesReceived":385536,"success":13282,"failed":191,"bytesSent":10858,"collisions":0}
3|poolController  | [2/21/2021, 11:24:12 AM] debug: Chlorinator message marked as invalid after not finding 16,3 in payload after 26 bytes
3|poolController  | [2/21/2021, 11:24:12 AM] debug: Chlorinator message marked as invalid after not finding 16,3 in payload after 26 bytes
3|poolController  | [2/21/2021, 11:24:14 AM] info: [11:24:14 AM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/21/2021, 11:24:14 AM] info: [11:24:14 AM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/21/2021, 11:24:15 AM] info: [11:24:15 AM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/21/2021, 11:24:15 AM] info: [11:24:15 AM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/21/2021, 11:24:15 AM] info: [11:24:15 AM] 192.168.5.31 GET /state/chlorinators {}
3|poolController  | [2/21/2021, 11:24:15 AM] info: [11:24:15 AM] 192.168.5.31 PUT /state/chlorinator {"id":1,"poolSetpoint":75}
3|poolController  | [2/21/2021, 11:24:15 AM] verbose: Wrote packet [255,0,255,165,56,16,33,153,10,1,15,0,0,0,0,0,0,0,0,1,193].  Retries remaining: 3
3|poolController  | [2/21/2021, 11:24:15 AM] verbose: Wrote packet [255,0,255,165,56,16,33,217,1,0,1,232].  Retries remaining: 3
3|poolController  | [2/21/2021, 11:24:16 AM] silly: Retrying outbound message after 1.007secs with 3 attempt(s) left. - 165,56,16,33,217,1,0,1,232
3|poolController  | [2/21/2021, 11:24:16 AM] verbose: Wrote packet [255,0,255,165,56,16,33,217,1,0,1,232].  Retries remaining: 2
3|poolController  | [2/21/2021, 11:24:17 AM] silly: Retrying outbound message after 1.08secs with 2 attempt(s) left. - 165,56,16,33,217,1,0,1,232
3|poolController  | [2/21/2021, 11:24:17 AM] verbose: Wrote packet [255,0,255,165,56,16,33,217,1,0,1,232].  Retries remaining: 1
3|poolController  | [2/21/2021, 11:24:32 AM] info: [11:24:32 AM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/21/2021, 11:24:32 AM] info: [11:24:32 AM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/21/2021, 11:24:33 AM] info: [11:24:33 AM] 192.168.5.31 GET /state/pumps {}

rstrouse
@rstrouse
11:31

Happy to provide more information - just let me know what you need.

[johnny2678]

Can I see what you have in your probe device feed for MQTT? I'd like to publish to a different topic, separate from what njspc publishes...

I got this far but nothing has been created in MQTT. Do I need to put some kind of js in the box to send the probe value?

[rstrouse]

If you return nothing it will return the entire value by default so essentially what you see below is the same as not entering anything. In your case you chose Probe pH as the send value and this will be sent as a number. If you chose All Values it would emit the entire state for the probe which includes temperature and pH.

Make sure your MQTT connection is marked as active on the general tab.

[johnny2678]

Interesting... not sure what my setup is missing

These values come in pretty frequently and I added the entry over an hour ago so I would have expected it to populate by now.

MQTT connection is marked active on the general tab

[rstrouse]

Restart REM by pressing the Reload Server button on the general tab. If you added a new MQTT server I don't think it initializes it right away.

[johnny2678]

hmm, did the restart. MQTT Values still aren't populating.

Also noticing that REM isn't triggering the Acid dosing like it was this morning

Changed REM logging to silly... I think this is the section where REM receives a new probe pH value, I can see where it does the /chemController emitting line, but there isn't a listing for the separate MQTT publish cmd

3|relayEquipmentManager  | verbose: Emitting: /chemController : {"acidDosing":"off","id":50}
3|relayEquipmentManager  | debug: Atlas_EZO-pH command R bytes written:1 result:7.917
3|relayEquipmentManager  | silly: Setting Dirty... true 6691
3|relayEquipmentManager  | debug: Atlas_EZO-pH command T,? bytes written:3 result:?T,21.11
3|relayEquipmentManager  | silly: Setting Dirty... true 6997
3|relayEquipmentManager  | verbose: Emitting: /chemController : {"pHLevel":7.917,"id":50}

Trying to troubleshoot the acid pump not dosing. Was playing with the data smoothing values earlier, but set it back to 1 and it's been that way for a while. Will keep digging

[rstrouse]

There are 5 conditions where the acid will not dose.

1. The pH level is higher than the setpoint - Obvious
2. The body circuit is not running
3. The max limit per rolling 24 hours has been exceeded or falls within the minimum dose that can be applied in 5 seconds.
4. The pH tank is empty
5. There is a hardware error when communicating with the devices.

Check the display in dashPanel are there any errors listed on the device

[johnny2678]

ok, acid is dosing again...

I was playing with the pH feed data sampling. Set it to 5 and then 2 thinking that would smooth out the values over readings. Dosing didn't start working until I changed back to 1.

Still can't see the MQTT values getting published from the additional REM MQTT connection for some reason. Will keep digging.

[rstrouse]

Double check the connection settings for your MQTT. This has been flawless. Perhaps restart REM altogether. It is very odd that the sampling caused it to not dose as well. njspc is totally unaware of the sampling settings. It only responds to the information that it is given and looking at your pH rising this number came from njspc I presume.

Do you have anything else hitting that probe? We have found that the EZO circuits don't like it when you fire requests from more than one source because of the timing that is required between initiating a read and actually reading the registers.

[johnny2678]

Do you have anything else hitting that probe? We have found that the EZO circuits don't like it when you fire requests from more than one source because of the timing that is required between initiating a read and actually reading the registers.

The yellow line is actually from my own influx script for now, not from njspc., but now that I think about it, your data smoothing function probably requires consecutive samples. Every time there was in i2c lock from my script, sampling probably restarted therefore never completing, which is why it started working again when I set it back to 1.

I am still running my old chem script and I'm working on a way to get off it. That's where getting REM->MQTT comes in. If I can grab the value from MQTT now that REM is reading it, then I don't need my own script anymore.

It's marked as active...

And the feed is marked as active...

Is there somewhere in the logs where it checks mqtt configuration? When I save I see this scroll by, but looks like its just writing the config, not necessarily testing the connection...

3|relayEquipmentManager  | debug: Persisting Configuration data...
3|relayEquipmentManager  | verbose: 192.168.5.138 PUT /config/connection {"type":{"name":"mqttClient"},"isActive":true,"id":2,"name":"15620 MQTT","options":{"clientId":""},"protocol":"mqtt:","ipAddress":"192.168.5.140","port":1883,"userName":"john","password":"H1ll1234","sslKeyFile":"","sslCertFile":""}
3|relayEquipmentManager  | info: [6:53:29 PM] 192.168.5.138 PUT /config/connection {"type":{"name":"mqttClient"},"isActive":true,"id":2,"name":"15620 MQTT","options":{"clientId":""},"protocol":"mqtt:","ipAddress":"192.168.5.140","port":1883,"userName":"john","password":"H1ll1234","sslKeyFile":"","sslCertFile":""}
3|relayEquipmentManager  | {
3|relayEquipmentManager  |   type: { name: 'mqttClient' },
3|relayEquipmentManager  |   isActive: true,
3|relayEquipmentManager  |   id: 2,
3|relayEquipmentManager  |   name: '15620 MQTT',
3|relayEquipmentManager  |   options: { clientId: '' },
3|relayEquipmentManager  |   protocol: 'mqtt:',
3|relayEquipmentManager  |   ipAddress: '192.168.5.140',
3|relayEquipmentManager  |   port: 1883,
3|relayEquipmentManager  |   userName: 'me',
3|relayEquipmentManager  |   password: 'XXXXX',
3|relayEquipmentManager  |   sslKeyFile: '',
3|relayEquipmentManager  |   sslCertFile: ''
3|relayEquipmentManager  | }
3|relayEquipmentManager  | silly: Setting Dirty... true 952
3|relayEquipmentManager  | silly: Setting Dirty... true 953
3|relayEquipmentManager  | silly: Setting Dirty... true 953

After this I don't see any mention of mqtt in the silly logs. If you get a chance, could you grab the log message your REM sends when an MQTT value is published so I know what to look for?

[rstrouse]

Ok so that pretty much tells me what is going on. I don't have a setup where there is access applied to the mqtt server so it is likely failing with a permissions issue. This will happen when REM starts up and you can see it in the console when you do a Reset Server.

However, I have done some research and figured out the username and password has to be passed to the connection constructor. Pull a new REM and lets see if it connects.

[johnny2678]

boom - that did it

 | silly: Sending on MQTT Channel {"eventName":"pool/chem/jhorp","value":734.1}

also rewrote my script so I rely exclusively on chem values read by REM now. Not doing direct i2c readings anymore.

logs are looking pretty clean now!

[rstrouse]

Awesome. So based on that I assume you are using njsPC for chemistry monitoring and control. Welcome aboard.

[johnny2678]

Everything was running great today - acid was dosing. pH was level... and then it just stopped dosing for some reason around 4:20PM

I remembered your post from yesterday, but can't figure out what condition is preventing dosing.

There are 5 conditions where the acid will not dose.

1. The pH level is higher than the setpoint - Obvious

actual pH 7.89 > 7.85 setpoint

2. The body circuit is not running

pool is on, pump is running

3. The max limit per rolling 24 hours has been exceeded or falls within the minimum dose that can be applied in 5 seconds.

max in dashPanel settings is 1200mL, dashPanel reporting only 696mL dosed today

4. The pH tank is empty

dashPanel level is pretty accurate with my eyeball measurement on the actual tank

5. There is a hardware error when communicating with the devices.

It was working on autopilot all day and I can trip the acid pump relay Dose Acid button in dashPanel

Once I manually dosed in dashPanel, the mixing timer started again, but nothing happened when it hit zero.

Here's the REM logs at that point

2|relayEquipmentManager  | verbose: Emitting: /chemController : {"pHLevel":7.901999999999999,"id":50}
2|relayEquipmentManager  | silly: Sending on MQTT Channel {"eventName":"pool/chem/ph","value":7.901999999999999}
2|relayEquipmentManager  | debug: Persisting Configuration data...
2|relayEquipmentManager  | debug: Atlas_EZO-pH command Status bytes written:6 result:?STATUS,S,4.98
2|relayEquipmentManager  | silly: Setting Dirty... true 198
2|relayEquipmentManager  | debug: Persisting Configuration data...
2|relayEquipmentManager  | debug: Atlas_EZO-ORP command R bytes written:1 result:718.6
2|relayEquipmentManager  | silly: Setting Dirty... true 10
2|relayEquipmentManager  | silly: Sending on MQTT Channel {"eventName":"pool/chem/orp","value":718.6}
2|relayEquipmentManager  | debug: Persisting Configuration data...
2|relayEquipmentManager  | debug: Atlas_EZO-pH command R bytes written:1 result:7.899
2|relayEquipmentManager  | silly: Setting Dirty... true 772
2|relayEquipmentManager  | debug: Atlas_EZO-pH command T,? bytes written:3 result:?T,21.11
2|relayEquipmentManager  | debug: Persisting Configuration data...
2|relayEquipmentManager  | debug: Atlas_EZO-ORP command R bytes written:1 result:718.5
2|relayEquipmentManager  | silly: Setting Dirty... true 3219
2|relayEquipmentManager  | verbose: Emitting: /chemController : {"orpLevel":718.55,"id":50}

It's reading pH values above the 7.85 threshold, but not triggering the gpio pin the relay is on.

Tried resetting the REM server. It does mention the GPIO pin on initialization:

2|relayEquipmentManager  | info: Initializing GPIO Pins 1
2|relayEquipmentManager  | info: Configuring Pin #36 Gpio #16:out on Header 1.
2|relayEquipmentManager  | info: Pin #36 Gpio #16:out on Header 1 Configured.

but I don't see any mention of it in the logs afterwards. If I recall, there are usually message saying something like, writing value 0 that appear every so often. I just don't see that now.

Probably an easy explanation since it was working earlier, but I'm stumped. I do have data sampling on the pH probe set to 2. This wasn't working yesterday due to conflicts with my own chem script reading values via i2c. But I stopped running that script and data sampling has been set to 2 all day, even when it was working this morning.

And you can see from the logs that REM isn't having any problems getting readings.

Maybe I should try setting data sampling back to 1?

Does this make any sense to you @rstrouse ? Anything else I should try?

[rstrouse]

The sampling should have no bearing since we are getting readings from REM.

In the njspc logs do you see any information related to REM. What is the mL/min you have the pH pump set to? njspc will hold dosing if the delivery would take less than 5 seconds. It does this to keep from overshooting the dose. Also, in the poolState.json file or on your MQTT server you should see acidDemand, what is that value.

[johnny2678]

Acid demand is at 102

njspc logs have a pretty clear repeat pattern that looks like this:

[2/24/2021, 6:32:15 PM] info: [6:32:15 PM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/24/2021, 6:32:15 PM] info: [6:32:15 PM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/24/2021, 6:32:15 PM] info: [6:32:15 PM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/24/2021, 6:32:15 PM] info: [6:32:15 PM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/24/2021, 6:32:15 PM] info: [6:32:15 PM] 192.168.5.31 GET /state/chlorinators {}
3|poolController  | [2/24/2021, 6:32:17 PM] debug: Sending [chemController] request to Hubitat: {"headers":{"CONTENT-TYPE":"application/json","X-EVENT-TYPE":"chemController"},"host":"192.168.5.56","port":39501,"method":"NOTIFY","path":"/notify"}
3|poolController  | [2/24/2021, 6:32:17 PM] silly: MQTT send:
3|poolController  | topic: pool/easytouch2-4/state/chemControllers/50/remchemcontrol/orp/level
3|poolController  | message: 721.5
3|poolController  | opts:{"retain":true,"qos":0}
3|poolController  | [2/24/2021, 6:32:17 PM] silly: MQTT send:
3|poolController  | topic: pool/easytouch2-4/state/chemControllers/50/remchemcontrol/orpLevel
3|poolController  | message: {"orpLevel":721.5}
3|poolController  | opts:{"retain":true,"qos":0}
3|poolController  | [2/24/2021, 6:32:21 PM] debug: Sending [chemController] request to Hubitat: {"headers":{"CONTENT-TYPE":"application/json","X-EVENT-TYPE":"chemController"},"host":"192.168.5.56","port":39501,"method":"NOTIFY","path":"/notify"}
3|poolController  | [2/24/2021, 6:32:21 PM] silly: MQTT send:
3|poolController  | topic: pool/easytouch2-4/state/chemControllers/50/remchemcontrol/ph/level
3|poolController  | message: 7.8759999999999994
3|poolController  | opts:{"retain":true,"qos":0}
3|poolController  | [2/24/2021, 6:32:21 PM] silly: MQTT send:
3|poolController  | topic: pool/easytouch2-4/state/chemControllers/50/remchemcontrol/pHLevel
3|poolController  | message: {"pHLevel":7.8759999999999994}
3|poolController  | opts:{"retain":true,"qos":0}
3|poolController  | [2/24/2021, 6:32:21 PM] debug: Sending [temps] request to Hubitat: {"headers":{"CONTENT-TYPE":"application/json","X-EVENT-TYPE":"temps"},"host":"192.168.5.56","port":39501,"method":"NOTIFY","path":"/notify"}
3|poolController  | [2/24/2021, 6:32:21 PM] debug: Sending [body] request to Hubitat: {"headers":{"CONTENT-TYPE":"application/json","X-EVENT-TYPE":"body"},"host":"192.168.5.56","port":39501,"method":"NOTIFY","path":"/notify"}
3|poolController  | [2/24/2021, 6:32:21 PM] silly: MQTT send:
3|poolController  | topic: pool/easytouch2-4/state/temps/bodies/1/pool/temp
3|poolController  | message: {"temp":70}
3|poolController  | opts:{"retain":true,"qos":0}
3|poolController  | [2/24/2021, 6:32:31 PM] info: [6:32:31 PM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/24/2021, 6:32:31 PM] info: [6:32:31 PM] 192.168.5.31 GET /state/circuits {}
3|poolController  | [2/24/2021, 6:32:31 PM] info: [6:32:31 PM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/24/2021, 6:32:31 PM] info: [6:32:31 PM] 192.168.5.31 GET /state/pumps {}
3|poolController  | [2/24/2021, 6:32:31 PM] info: [6:32:31 PM] 192.168.5.31 GET /state/chlorinators {}
3|poolController  | [2/24/2021, 6:32:37 PM] debug: Sending [chemController] request to Hubitat: {"headers":{"CONTENT-TYPE":"application/json","X-EVENT-TYPE":"chemController"},"host":"192.168.5.56","port":39501,"method":"NOTIFY","path":"/notify"}

Only odd thing is dashPanel is reporting :

and logs say: 3|poolController | [2/24/2021, 6:33:57 PM] debug: Chlorinator message marked as invalid after not finding 16,3 in payload after 26 bytes

Thought this was a byproduct of the pH dosing priority cycle as these messages would often show up when pump is dosing and I assumed it was njspc shutting down the SWG during dosing. But it hasn't cleared.

The easy touch is not reporting an SWG comms error - this is where they would normally show up:

Would an SWG Comms error in njspc get stuck? Should I try and restart njspc and see if that clears it? Would the comms error cause it not to dose acid?

edit: sorry, forgot to answer the acid pump mL/min question. I have it set for 216.5 mL/min

[rstrouse]

That seems like really high output for the pump.

Yes restart njspc. Perhaps there is a socket hangup between njspc and REM. Are these running on the same hardware?

I don't see a message like in your njspc log. [2/24/2021, 3:54:17 PM] info: Chem acid demand calculated xxxmL for xxmin xxsec Tank Level: xx

[johnny2678]

i did restart njspc. back in business, i think.

lots of these in the logs that weren't there before - guess the REM connection got stale? I did not have to restart REM, just njspc

3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request initiated. GET /status/device/i2c:1:1 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request returned. GET /status/device/i2c:1:1 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request initiated. GET /status/device/i2c:1:2 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request returned. GET /status/device/i2c:1:2 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request initiated. GET /status/device/gpio:1:36 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request returned. GET /status/device/gpio:1:36 
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request initiated. PUT /feed/device/i2c:1:2 {"tempF":70}
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request returned. PUT /feed/device/i2c:1:2 {"tempF":70}
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: Chem begin calculating demand: 7.8845 setpoint: 7.85 body: NaN
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request initiated. PUT /state/device/gpio:1:36 {"state":false}
3|poolController  | [2/24/2021, 7:03:32 PM] verbose: REM server request returned. PUT /state/device/gpio:1:36 {"state":false}

The other really odd thing is on reset I was getting an error because my pool body volume had been cleared:

3|poolController  | [2/24/2021, 7:04:12 PM] verbose: Chem begin calculating demand: 7.8805 setpoint: 7.85 body: NaN

Once i re-set the body gallons in dashPanel, it dosed right away. This value had been set and I didn't clear it.

So not sure I solved anything but at least it's working again.

1) did the body value clear itself? if it happens again, I'll check this first before restarting njspc 2) could this have caused njspc to not even try and connect to REM?

[johnny2678]

about the pump output, you have the same intelliPH pump, right? what's your output?

tho i guess the pump heads could be different. I have the new pump head.

I used my irrigation catch cups to measure output. Prior to REM, I was just dosing a fixed amount of time (10 seconds). Catch cup measured 1.22 oz every 10 seconds.

1.22 oz / 10 seconds = 0.122 oz / sec 60sec 29.5735 mL /oz = 216.5 mL/min

Think I got that right ;)

I have considered using a step down modulator to reduce output as it does run a bit faster than I remember than when it was on the Pentair timer, but it works fine regardless.

https://www.amazon.com/gp/product/B07JZ2GQJF/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

edit: and no, REM is out by the pool and njspc is running indoors on a different pi hooked up to the screenlogic module

[rstrouse]

You do not have a body volume set. The system is going to be all confused about the demand calculation. Check to make sure you have a body capacity set on both the pool and the spa. That message where it says body: NaN is not right and I probably should be trapping that. Also, I am not so sure you want to be dosing acid when in Spa mode anyway. If you set the chem controller body to pool instead of pool/spa it will handle that. In IntelliCenter and IntelliTouch you can actually have a Pool/Pool configuration. You can also have a Pool/Pool/Spa/Spa configuration in IntelliCenter.

I should also check to make sure the Touch interface isn't clearing that value when you reload the configuration since the OCP doesn't natively store that value.

Funny you have irrigation catch cups. Did you by chance perform an irrigation efficiency test on your sprinklers? Anyhow the math looks correct but I don't have my stuff hooked up to run a flow test. I seem to remember @gw8674 reporting his using the same tank at around 93mL/min. Are you powering this with 24vdc?

[rstrouse]

I got way too excited and didn't read your message entirely. Given your information yes it looks like the reset for Touch clears this information and it shouldn't. There are probably other places where information should be preserved. I believe this clearing of information happens when you do a Reload Config or a capture replay.

[johnny2678]

good tip on the pool/spa -> pool mode on the chem controller body. I wasn't really thinking when i set it to pool/spa. You are right, definitely don't want to be dosing in spa mode.

Maybe i did do a reload config before restarting njspc??? I can't remember now - I was trying to trigger it to reconnect to REM so I was just pressing buttons. That might explain the cleared body volume when njspc came back up after a restart, but doesn't explain why I had to restart in the first place.

oh well, I'll let you know if I lose connection to REM again. Pump is off now. It performed great this AM and I should have some more time to observe tomorrow.

Once this is sorted, I'd like to chat about your CSI calculation, and your thoughts on SWG dosing based on ORP values.

Re: catch cups - I use a rachio irrigation controller and one of the zone inputs is Efficiency %. Built a spreadsheet a while back (years) to help me calculate this value which feeds into run time. Didn't kill my lawn so guess it worked out ok 😂

I also use the catch cups to calibrate my rain catcher.

[rstrouse]

Yeah lets keep an eye on it. Just so you know you can change logging levels from dashPanel dynamically so if you want to see more data you simply choose a level at the bottom of the list. Info is the default and gives a pretty clear message as to what is going on on the controller.

[johnny2678]

roger, that's a great feature and I've been watching in verbose mode to catch more REM messages.

[gw8674]

Hmmm... Yea, I did three individual dosing tests with my IntellipH pump using my current relay and using 24vdc and every time it came out to 108 mL/min. The IpH manual says 4 oz/min (118 mL) but I've come to never trust whats in their manuals.
So, 108mL/min is what I currently have set in the flow rate. 216 seems awful high??

[johnny2678]

Just checked again... catch cup reading over 10 seconds is 38 -40 mL

This is even more than the 216.5 mL/min I have set and almost twice the published output of 4oz/min!

Maybe I will look at using a step down converter to get closer to the advertised output. Guessing that will be better on the pump head.

Everything running smoothly today btw...

[rstrouse]

That looks really solid. What voltage are you running that pump at? I believe it should be 24v DC not AC. Depending on the motor circuitry AC current (on an ESC) could make it run twice as fast.

What do you have your mixing time set to? I like the little doses as it doesn't look like there are any waves.

[johnny2678]

yea, it's 24v DC. I tapped into the power coming from the Pentair powercenter, which has the added benefit of only getting power when the pump is on so no accidental software doses. I set that up before REM so no offense meant ;)

Checked it with a voltmeter and everything. It's definitely running faster than it did when it was installed and used as intended by Pentair, before my hackery. But it's working.

This device here (pentiometer?) is supposed to let me step down the power without losing motor torque. Have yet to test it but I could give it a go.

edit: grammer

[johnny2678]

oh, and mixing time is 5 mins and max dosing time is 10s. That's the same settings I was using in my setup. The difference is I was dosing for 10 seconds no matter what if pH was above threshold. Wasn't calculating demand or anything fancy like that.

[rstrouse]

I bought two of those buck converters, actually 2 of these https://www.amazon.com/gp/product/B078Q1624B/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1 for the panel I am building. One will power the fans and the other will power a touchscreen. The power to the pump is coming from a Meanwell SDR-240-24.

I thought the 24v tap in IntelliTouch was actually 24v AC for the valves.

[johnny2678]

Just walked out to the power center. It says 22-39vdc. Maybe it’s just pulling at the higher end of that range?

On Thu, Feb 25, 2021 at 6:14 PM rstrouse notifications@github.com wrote:

I bought two of those buck converters, actually 2 of these

https://www.amazon.com/gp/product/B078Q1624B/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1 for the panel I am building. One will power the fans and the other will power a touchscreen. The power to the pump is coming from a Meanwell SDR-240-24.

I thought the 24v tap in IntelliTouch was actually 24v AC for the valves.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tagyoureit/nodejs-poolController/issues/268#issuecomment-786295164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6WYXZQZLZN67CEQHJCP23TA3KWDANCNFSM4X7FFTQA .

[johnny2678]

[rstrouse]

Oh you are pulling the IntelliChlor transformer not the secondary. That makes sense. I think you will probably find that this it is run in constant current not constant voltage mode with a range like that. With the power draw of the pump I would bet you are at the top end of that range. Some of the bucks will compensate for that.

[johnny2678]

yea, I've been holding off on the bucks because 1) seems to be working ok and 2) space is at a premium in my project box 😂

Don't judge...

[rstrouse]

Compact I like it! The box I chose is 16x16x8. You know if you put a 4relay hat on your pi you could get rid of the monster SSR and heat sink. Don't forget a flyback diode for it though. I haven't torn the pump apart but it may already have one. A good way to tell is if it sparks by running the positive lead across the power source.

[johnny2678]

yea, I'm not even sure the SSR needs the heat sink. That would save me some room. I have another SSR with a notification LED on it that I was thinking of swapping out.

I'll have to google flyback diode ;)

Of course, I went too big on my other project box. Flow Cell and probes look kind of lonely in there.

[rstrouse]

This is as far as I got on mine so far. The cooling fan is in and I fabricated an inner door because I want to use dashPanel at the pad and be able to hit all my other HA components from there.

[johnny2678]

ha! I've got the same AC infinity fan control in my AV closet.

I did think of putting a 120mm fan on the project box, but my pi has sat outside baking in the hot FL afternoon sun for 3+ years now, still going strong.

Really crazy.

I have no allusions about shortening its life but I've got a backup script on it. Would take more time and energy re-seatting everything in a larger project box with a fan than it would just to pop a new pi in there.

show n tell is fun. Keep me posted on your progress.

How are you planning on securing your probes in the flow cell?

[rstrouse]

Yeah got one in the AV closet too.

[rstrouse]

I bought the industrial probes so I re-tapped the holes to 3/4" NPT. The inner door will have a 10.1 inch touchscreen mounted to it and the fire control box will be gutted and placed in there as well as my DMX lighting.

[johnny2678]

Didn't realize the industrial probes were already at 3/4" NPT - that's going to last longer than my cable gland + plumbers tape solution ;)

Went over to Atlas Scientific to check them out and noticed they have some new offerings - this should make the setup process less cumbersome for those just getting going - https://atlas-scientific.com/kits/wi-fi-pool-kit/

[rstrouse]

Yeah not sure what to think of the wifi kit but the combo probe had me intrigued. What they need to do is sell a flow cell that is already tapped to 3/4". You know they do sell 1/2" npt probe holders that have an inner metal ring to support the probe. It seems pretty solid and will screw into your flow cell. The tee is useless. https://atlas-scientific.com/connectors/probe-pipe-fitting/

[johnny2678]

I guess my thinking was - I don't even know if this stuff will work. Let me put it together with cheaper components and see if my concept will work and then I'll bump it up.

And now of course that it's in production and I know it works I don't want to touch it 😂

edit: ooo, responded before I clicked your link. That does look like a good replacement for my cheaper cable glands when they fail. I'm actually surprised at the strength of the probes. I have to twist those cable glands pretty tight around the probe body to get a seal and no cracks or leaks.

[johnny2678]

When you have a minute, let me know what your plans are for the SWG dosing based on ORP

This checkbox doesn't do anything right now, right?

[rstrouse]

So here are my thoughts but you have been doing this for a while so I would like to hear about your findings as well. Because of the way the chlorinator works we cannot use the power setting. In fact it is not a power setting at all, it is the % of time the chlorinator cell is engaged over an accumulated period of time. Internal "cell on" time is not deterministic if the percentage is anything less than 100%. Generation output rates are also not deterministic because temperature and chemistry determine how much FC is created by the chlorinator over time. Dosing is always a function of time.

Given that there are limited paths for how this can effectively function. Each dosing period should use 100%. Remember when the cell is actually engaged it always engages at full power. The length of the interval is what the percentage actually does. Come to think of it that also explains the constant current vs constant voltage nature of the power supply. The second part of the dose needs to include a time where the chlorinator will engage the cell @100%. During and after this dosing period we will be sampling to determine how close we are getting to the setpoint.

Like the acid doses the system needs a period of time from a chlorinator run to sense the change in reduction potential. This is the mix time. The mix time is simply to regulate the cell so we don't overshoot too much. If we do, the ORP will always bounce below the setpoint. Our goal will be to smooth a wave by dosing on the limits then resting to see the results. I have thought about watching the rate of increase and predicting the next dose but that might prove to be goofy given the fact that sunlight has a pretty hard impact on it.

The final piece of this is isolation of the chlorinator functions from the OCP. Unfortunately, the OCP will continue to issue commands to the chlorinator. This includes the setpoints and the superChlor function. That being said we already have a model that disables the chlorinator function during an acid dose and will use a similar function that does nothing when the chlorinator is controlled by REM. The only other alternative is to uninstall the chlorinator from the OCP altogether then send the RS485 commands via the RS485 bus. I think we can intercept all setpoint changes however and reset them to the values we want 0 or 100.

[johnny2678]

Your thinking is right in-line with mine. At any given time, the SWG is either dosing or not dosing but there's no on/off switch and the only lever we have is %. So we can force it to be on by setting % to 100 and force it to be off by setting 0 %.

Because there's only a loose correlation between ORP and FCl, I might recommend a simple dosing model:

• SWG is on if ORP is below the threshold
• SWG is off if ORP is above the threshold
• and then a small personal indulgence for me... an Invert checkbox - my pool somehow has an inverse relationship w/ ORP and works exactly opposite of this ;) Strange I know, but I've been monitoring for months, recalibrated the probe, installed a new probe, same results. And it just works for me.

We can still let the user set max dosing time per dose (just like with PH dosing), max dosing time per day, and mixing time between doses.

Also, I don't have this setup, but some folks with larger pools might want to do both. Dose with SWG and a Sanitizer tank. Looks like you already have all the settings you need for the Sanitizer Tank (same as pH really). I just thought a separate check box/options screen would make it more clear when you're configuring one vs the other (or both).

I have thought about watching the rate of increase and predicting the next dose but that might prove to be goofy given the fact that sunlight has a pretty hard impact on it.

I wanted to do this too - I really did. But I've stared at ORP graphs all day and can't make complete sense of it. Sometimes SWG dosing has a quick impact on ORP, sometimes it doesn't seem to move the needle. As you said, it's probably affected by sunlight and other chemistry.

Anyways, If I had your development chops, that's the way I'd do it. And this would definitely get me off my python/nodered method I'm using today. Happy to discuss further.

[rstrouse]

Hmmm... I wonder if what you are experiencing has more to do with high pH > 7.6 and cyanurates. This monkeys with the reduction potential. Perhaps the right answer is to find the relationship with pH and CYA.

[johnny2678]

Maybe, but I’ve kept CYA at zero for months. Recently raised it to 10 just to see what happens. No change.

From what I read, ORP and CYA don’t play well above 20-30.

On Fri, Feb 26, 2021 at 9:50 PM rstrouse notifications@github.com wrote:

Hmmm... I wonder if what you are experiencing has more to do with high pH

7.6 and cyanurates. This monkeys with the reduction potential. Perhaps the right answer is to find the relationship with pH and CYA.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tagyoureit/nodejs-poolController/issues/268#issuecomment-786991130, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6WYXZ5PGDCVGSBOOUWFY3TBBMXZANCNFSM4X7FFTQA .

[johnny2678]

was reviewing my ORP auto-dosing settings this morning and forgot to mention 1 thing:

Since the ORP/FCl relationship is hard to nail down, and will vary from pool to pool, I actually don't set the SWG dosing output to 0 when ORP meets threshold. I just set it to a number above 0 that would not be adequate to sanitize the pool, but will still dose a little bit. In case ORP goes a long time above the threshold.

Also, Not sure this matters, but I only turn on dosing when ORP is below threshold MINUS a percentage, and then turn off when ORP is above threshold PLUS a percentage.

This is obviously inverted for my wacky setup.

Including a list of SWG dosing parameters that I am using currently.

[auto_swg]
  # Settings used to automate swg dosing using the super chlorinate function
  # orp_threshold = the orp reading below which will trigger the swg superchlorinate function
  # orp_percent_threshold = the std must be below this number to dose.  If not skip the dose until readings stabilize
  # swg_min_runtime = the time the swg will run once it's triggered.  If orp is above the threshold when time runs out, the swg will turn off.  If not, it will keep running and swg_runtime will reset
  # swg_baseOutput = the % that will be set when auto dosing is off
  # swg_dosingOutput = the % that will be set when auto dosing is on
  # swg_orp_relationship = direct or inverted

  auto_swg_enabled = True
  orp_threshold = 770
  orp_percent_threshold = 3
  orp_percent_bounding = 1
  swg_min_runtime = 600
  swg_mixing_time_period = 1200
  swg_baseOutput = 15
  swg_dosingOutput = 100
  # direct or inverted
  swg_orp_relationship = inverted

[rstrouse]

Thanks. I need to understand this inverted thing. Just to be sure, what you have experienced is that when you add chlorine the numbers go down? It doesn't matter where you add it from either the SWG or at the end of the barrel of a Clorox bottle, the more you add the lower the numbers go. Is that what's happening?

This would indicate a reduction in the oxidation potential and that doesn't make any sense. This does have an effect on pH but an increase in potential should only drive the pH higher not the other way around. The more I look at this, the less I understand how this can be. Now I can see why CYA would cause the ORP to hover in the lower range because that buffers the oxidation reaction and we are actually measuring the react-ability not how long it can do it until it runs out of steam.

This also explains all the goofiness with trying to run without CYA but in my little pea I can't seem to understand why that would be desirable. The kill time with or without CYA is in the lower seconds but the amount of time for e-coli to make it from somebody's butt to somebody's face is constant, While the kill time increases, the potential for there to be any sanitizing effect at the location it is needed also dramatically increases.

When you look out over the endless surface area of an outdoor pool the one thing that you notice is that the UV exposure is pretty high and a great source of escape for our oxidizing agent. These days we don't turn over our pools near as quickly as we did when we ran them full steam with a 2hp pump all day so there are likely spots in the pool that don't get the turnover as often as other areas. I am not saying the water stagnates there but the oxidizer doesn't rapidly fill into places where there is none either. That is if the esoteric solubility tests that I have read regarding dispersal of oxidation agent are true.

CYA acts to keep the oxidation agent (chlorine) in the pool and UV tends to make it off-gas. Logic seems to dictate that keeping CYA in the 20s fixes the sensors but destroys the goal. I think our goal is to have sanitizer available just in case somebody Caddyshack's the pool and have it available at the location and time where the organic matter enters the pool. If we were ant man we might be able to swim in the flow cell, but that water isn't purely representative of that vast unexplored territory in the pool.

I haven't had the benefit of seeing any of this myself. My ORP probe is sitting in storage solution, inside a box. My dissertation above is simply me trying to apply logic to the whole ORP thing. The big ORP fans out there seem to indicate this is the end all but it is an indirect measurement of an action or inaction that occurred in the past. To add to the madness is that the action we take will be drawn out over time and the effect is most likely not linear as indicated by the FCL to ORP charts.

Sorry for the dump but I just needed to get this out of my mental morass. What I really need is a better understanding of how adding chlorine to the water decreases the ORP reading.

[johnny2678]

the amount of time for e-coli to make it from somebody's butt to somebody's face is constant

I have no response to this but quoting it anyways. 🤪

You wrote a post that included the phrase "just in case somebody Caddyshack's the pool" and that isn't even the most memorable line.

@tagyoureit showed me one of his influx graphs for SWG dosing a while back on his gitter and it was a pretty clear direct relationship between SWG dosing and ORP rising - just how it should be.

When I dose, I see the opposite. I could probably play with the chemistry and run all kinds of tests to figure out why that is, or just go with it.

For reference, here's my latest chem readings as of this morning:

FC: 3.5 Combined Cl: 0 CH: 375 TA: 60 - *added some baking soda this am to bring this up to 75-85, of course this jacked up the pH until auto-dosing brought it back down to 7.85

CYA: 10 Salt: 3900ppm pH: 7.85 ORP: ~740 Water Temp: 79 CSI: 0.04

Pool water looks great, CSI levels are constant, which is why I guess I'm not looking into this too much. If my SWG has an inverse effect on ORP and my pool water stays clear, then so be it

Curious you keep mentioning CYA - what do you keep your CYA levels at? I was at 60-70 before putting in the ORP probe but I keep reading that CYA levels that high render ORP readings useless.