Changing IntelliFlow pump RPM results in outbound message error.

[brentratliff]

Changing IntelliFlow pump RPM results in outbound message error.

Changing the pump speed results in:

Message aborted after 3 attempt(s): 165,1,16,33,155,47,1,128,0,0,0,6,10,1,11,0,0,0,0,0,0,0,0,0,0,0,0,3,190,134,0,0,0,0,0,0,232,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,109

Stack Trace:

ApiError: Message aborted after 3 attempt(s): 165,1,16,33,155,47,1,128,0,0,0,6,10,1,11,0,0,0,0,0,0,0,0,0,0,0,0,3,190,134,0,0,0,0,0,0,232,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,109 at SendRecieveBuffer.writeMessage (/home/pi/nodejs-poolController/controller/comms/Comms.ts:421:27) at SendRecieveBuffer.processWaitPacket (/home/pi/nodejs-poolController/controller/comms/Comms.ts:371:29) at SendRecieveBuffer.processOutbound (/home/pi/nodejs-poolController/controller/comms/Comms.ts:379:30) at SendRecieveBuffer.processPackets (/home/pi/nodejs-poolController/controller/comms/Comms.ts:362:21) at Timeout. (/home/pi/nodejs-poolController/controller/comms/Comms.ts:393:59) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7)

Pool Equipment

• EasyTouch2 8

• Controller Model: EasyTouch2 8P

• Controller Firmware Version: ?

• Pump(s) manufacturer and model: IntelliFlow

• Chlorinator: None

• Heater(s): Pentair 400 natural gas

• Chemical controller: None

• Valves: Intellivalve x 2

• replay.zip

• OS: Windows 10

• Chrome

• Version: latest

I can still change the pump speed in ScreenLogic. It appears to be changing the pump speed via PoolController as well. I changed it with PC, then verified it via SL. Yesterday, however, it was reporting the incorrect speed and wattage. Today it is reporting the same as SL.

[brentratliff]

I was already up to date on dashPanel. Now, water balance is correct and changing levels no longer causes an error. It does however, keep resetting the level of both PH and ORP on the save of either.

[brentratliff]

It looks like it saves the new value and then decreases both tanks by on a second later.

[rstrouse]

I was already up to date on dashPanel.

Did you perform a hard refresh of the browser on dashPanel?

It does however, keep resetting the level of both PH and ORP on the save of either.

Do you mean that when you change the pH or ORP setpoint the levels change to the setpoint?

It looks like it saves the new value and then decreases both tanks by on a second later.

I think we got some bum advice on the tank levels. The code looks like it is shifting the values by one so that it is never really 0. When you captured the log for me the reading that came back was: ORP Tank Level = 4 pH Tank Level = 6

At the time of the capture was the Chlorine tank completely full? 100%

Edit: I got these backwards: pH Tank Level = 4 ORP Tank Level = 6

[brentratliff]

All the setpoints are working perfectly. I did do a hard reset of the browser. The tank levels are what are strange. When I increase the level in either tank, it saves correctly and then decreases both tanks by one. They were not both full in the packet capture. I think ph-3, orp-4 so it may be doing exactly that.

[rstrouse]

Is the max tank level 6?

[brentratliff]

I changed the levels from 3->4 on PH and 4-3 on ORP. The max level is 6.

[brentratliff]

I just got this error, decreasing the Acid level:

ApiError: Message aborted after 2 attempt(s): 165,0,144,16,146,21,2,238,2,198,2,2,0,249,0,43,0,150,20,0,0,0,0,0,0,0,0,5,118 at SendRecieveBuffer.writeMessage (/home/pi/nodejs-poolController/controller/comms/Comms.ts:341:27) at SendRecieveBuffer.processWaitPacket (/home/pi/nodejs-poolController/controller/comms/Comms.ts:291:29) at SendRecieveBuffer.processOutbound (/home/pi/nodejs-poolController/controller/comms/Comms.ts:299:30) at SendRecieveBuffer.processPackets (/home/pi/nodejs-poolController/controller/comms/Comms.ts:282:21) at Timeout._onTimeout (/home/pi/nodejs-poolController/controller/comms/Comms.ts:254:109) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7)

[rstrouse]

You mean the Acid tank level?

[brentratliff]

It lets me change the levels intermittently now, but with any save to either tank, will decrease both tanks my one.

You mean the Acid tank level? Yes

[rstrouse]

When you increase the acid tank to 6 using EasyTouch what is displayed in dashPanel?

[brentratliff]

I set PH->6, ORP->3 on EasyTouch. Displaying perfectly in dashPanel.

[rstrouse]

Perfect. That tells me that the values on the message are actually 1-7 not 0-6. 0 must mean that there is no tank. Another weirdo thing.

Pull njspc I think we have it set correctly now.

[brentratliff]

Works perfectly. Thanks for the help.

[rstrouse]

You are welcome. Thanks for providing the info we needed.

[brentratliff]

Unfortunately, there is no place in the messages coming out of IntelliChem where the current dose amount or time is emitted during the dose. I did figure out that 20 is actually the salt level reported by your controller. It is 20 x 50 = 1,000ppm. In your case you are not using a chlorinator so this is probably the default level.

I forgot to mention that IntelliChem users without a SWG put total dissolved solids in to the salt level. And yes, mine is set to 1000.

[brentratliff]

Are these dosing time/volumes accurate do you think?

pool/state/chemControllers/1/chemcontroller1/ph/doseTime 768 pool/state/chemControllers/1/chemcontroller1/ph/doseVolume 6 pool/state/chemControllers/1/chemcontroller1/pHDosingTime {"pHDosingTime":768} pool/state/chemControllers/1/chemcontroller1/pHDosingVolume {"pHDosingVolume":6} pool/state/chemControllers/1/chemcontroller1/ph/doseTime 1280 pool/state/chemControllers/1/chemcontroller1/ph/doseVolume 10 pool/state/chemControllers/1/chemcontroller1/pHDosingTime {"pHDosingTime":1280} pool/state/chemControllers/1/chemcontroller1/pHDosingVolume {"pHDosingVolume":10} pool/state/chemControllers/1/chemcontroller1/ph/doseTime 1792 pool/state/chemControllers/1/chemcontroller1/ph/doseVolume 15 pool/state/chemControllers/1/chemcontroller1/pHDosingTime {"pHDosingTime":1792} pool/state/chemControllers/1/chemcontroller1/pHDosingVolume {"pHDosingVolume":15} pool/state/chemControllers/1/chemcontroller1/ph/doseTime 2048 pool/state/chemControllers/1/chemcontroller1/ph/doseVolume 17 pool/state/chemControllers/1/chemcontroller1/pHDosingTime {"pHDosingTime":2048} pool/state/chemControllers/1/chemcontroller1/pHDosingVolume {"pHDosingVolume":17} pool/state/time 2021-03-24T08:16:40.000-0400

[rstrouse]

Yes that looks like it is counting up. The unfortunate part is that it never reports when it expects to stop. I do believe the volumes are mL given the times. This puts the metering right around 120mL/min which is what the pump is rated at.

[brentratliff]

Would it work to map those to the ml used fields in dashPanel?

[rstrouse]

Let me think about that one. The crazy thing is that with REM we have it count down to the second when it is going to complete one phase of the dose to the next. For instance, it will say dosing 20mL of 50mL 30 seconds remaining or Mixing 1hour 24min 8sec. When it is dosing what does it currently say in dashPanel for you.

[brentratliff]

Ah, thanks. I have noticed after running reliably over night I can now not get dashPanel to change anything. I get:

ApiError: Message aborted after 3 attempt(s): 165,1,16,33,155,47,1,128,0,0,0,6,10,1,11,0,0,0,0,0,0,0,0,0,0,0,0,3,190,134,0,0,0,0,0,0,232,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,109 at SendRecieveBuffer.writeMessage (/home/pi/nodejs-poolController/controller/comms/Comms.ts:341:27) at SendRecieveBuffer.processWaitPacket (/home/pi/nodejs-poolController/controller/comms/Comms.ts:291:29) at SendRecieveBuffer.processOutbound (/home/pi/nodejs-poolController/controller/comms/Comms.ts:299:30) at SendRecieveBuffer.processPackets (/home/pi/nodejs-poolController/controller/comms/Comms.ts:282:21) at Timeout. (/home/pi/nodejs-poolController/controller/comms/Comms.ts:313:59) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7)

regardless of what I try to change, lights, pump speed, IntelliChem, everything.

[rstrouse]

Hmmm... do me a favor. Do not change the pump setting change a light or some other innocuous circuit and report that error. That message above is for a pump configuration. This looks a lot like an RS485 comms issue. The most common cause is loose wiring.

[brentratliff]

I'm getting the error on lights, everything. Same comms error. I'll check my wiring.

[brentratliff]

Nothing's working, including ScreenLogic. I may have a bad protocol adapter.

[rstrouse]

It is not the same error. What is the error you are getting when you do lights. The message will be different.

[rstrouse]

Since you have used messageManager you can go in there and turn on all messages to see what might be coming across if anything. Click on everything in the include section.

[brentratliff]

I will troubleshoot that. I checked all the wiring and it's solid. I had to power down the Pi completely to get ScreenLogic to start working again. Is there a known issue when using both systems at the same time? Last time I booted the Pi and ran njspc, it never even found the EasyTouch.

[rstrouse]

No there is no known issue with conflict. And both of these devices act as an RS485 slave on the bus. However, a misbehaving RS485 device on the bus can bring the whole thing down. This includes anything attached to it like pumps or IntelliChlor.

The most common condition is where the device adds enough resistance to create an echo effect on the bus. This essentially destroys every message on the bus by scrambling the signal. This is essentially what happens with a loose wire. IntelliChlor is a good culprit for this since the DIN connector can get corroded in the elements. This is true for the pumps as well but the seal seems to be better on that connection. But the most common culprit here is multiple wires into a single comm port on the motherboard. Often the wires are of a different gauge and the one or more of the wires end up loose inside the connection. To make matters worse the housing is nylon that expands and contracts with temperature so at night things go to hell when the temperature drops and works perfectly when you are troubleshooting.

The other common problem is that one of the tranceiver channels dies on the device so it sends out a message and can't hear the reply or it hears all the replies and the master never gets them. When I was running IntelliTouch I had no less than 3 motherboards fail in this fashion. After the third one, I found this project in an attempt to see what was going on on the RS485 bus and subsequently upgraded to IntelliCenter. I now realize that it may have been the power supply in the load center eating the RS485 chips on the motherboard.

[brentratliff]

That sounds like what may be going on. I had this problem before I installed IntelliChem. It started when I wired the Pi to the protocol adapter so that I have both ScreenLogic wireless kit and RS485 wired to the Y/G. The only thing that fixes it is to completely power down the Pi.

[rstrouse]

First check your wiring again. I mean every connection including the connectors between every RS485 device. This includes protocol adapters, pumps, IntelliChlor, and njspc dongle. It might make sense to use a little electronics cleaner on all the connectors exposed to the elements.

The next step would be to replace the RS485 dongle on the pi since this is cheapest component. If you have pigtails connecting all of this into a single comm port then consider ways of wiring this differently. Perhaps a comm expansion board is in order.

[brentratliff]

Thanks, I think that is my issue. The IntelliChem installer came out twice and triple checked everything on the bus at the EasyTouch. I'm pretty sure it's my connection inside.

[rstrouse]

Don't be too sure of that IntelliChem installer. When they wired my IntelliTouch panel originally, the installer actually used these https://www.grainger.com/product/5EKL3?ef_id=EAIaIQobChMIr43Wq7TJ7wIVqwutBh2eeApKEAQYASABEgIxUfD_BwE:G:s&s_kwcid=AL!2966!3!264922886802!!!g!439460816581!&gucid=N:N:PS:Paid:GGL:CSM-2293:99F1R6:20501231&gclid=EAIaIQobChMIr43Wq7TJ7wIVqwutBh2eeApKEAQYASABEgIxUfD_BwE&gclsrc=aw.ds all chained together in a tree structure. I went months with unreliable operation with multiple call outs until I opened the panel and saw that. It was maddening. Really the guy was trying to save 80 bucks for the comm expansion module. I fixed the mess and it was rock solid for 5 years until the first mobo failure.

Then every year or so after that the mobo would fail. Pretty sure that was the power supply dumping too much current. I could tell it was going bad when the MobileTouch started disconnecting randomly.

[brentratliff]

I may order one, but I'm going rewire the RS485 cable with something smaller than the thermostat wire I used. If that doesn't work, I'll replace the adapter and go from there, but I really think it's that connection at the protocol adapter.

[rstrouse]

One way to tell if it is the protocol adapter is to look in messageManager when the failure is occurring to see if there is a flood from it. You don't need to save it to a file but watch the feed if there is a flood overwhelming the bus you should see it. Messages should only occur every second or so and they should be varied with mostly action 2 messages. If the protocol adapter is misbehaving will be constantly asking for information.

[brentratliff]

Good to know. I think eventually I'm just going to place the Pi and protocol adapter outside with the equipment and use the com expansion module. That way, when ScreenLogic inevitably fails, njspc will still work.

[brentratliff]

Issue is with my RS485 adapter. If it is even plugged into the PI, with or without njspc running, it immediately crashes the bus. It started off slowly causing problems and now immediate. I even rewired it with ScreenLogic cables of the same guage. I ordered a different one with a ground. Hope it works. I am also installing a com expansion board at the EasyTouch since I have three sets of wires going into one port; pump, intellichem, ScreenLogic.

[tagyoureit]

I've been having pretty good luck with this one: https://www.waveshare.com/2-ch-rs485-hat.htm

[tagyoureit]

Closing this due to issues outside of njsPC. Hopefully your new adapter fixes everything.