ScreenLogic / EasyTouch Scheduling Problem

Jump to latest Follow Reply
I can't really think of what could be wrong hardware wise - the comms are working and it's not likely that a relay driver is bad. The eeprom (internal to the microcontroller) seems to be fine. It's possible - but not probable - that the microcontroller has some other issue that's causing the problem, so it seems most likely to be a programming or firmware issue rather than something that needs to be repaired. The Easytouch board could be temporarily swapped with another to verify, but that's about all I can think of.

What firmware versions are running on the Easytouch and on the pump?
 
  • Like
Reactions: Jimrahbe
ogdento said:
I can't really think of what could be wrong hardware wise - the comms are working and it's not likely that a relay driver is bad. The eeprom (internal to the microcontroller) seems to be fine. It's possible - but not probable - that the microcontroller has some other issue that's causing the problem, so it seems most likely to be a programming or firmware issue rather than something that needs to be repaired. The Easytouch board could be temporarily swapped with another to verify, but that's about all I can think of.

What firmware versions are running on the Easytouch and on the pump?
Click to expand...
THanks TOm @ogdento . I have done an EEprom erase and reprogram twice now with no change in results, pump running for 1 minute or less at various non-programmed times throughout the day and night. Pump is not running on a relay. I suppose it 'could' be the pump itself receiving erroneous signals, I've thought about disconnecting the RS-485 connection and running separate programs on the pump to see if there is any change. I've also started keeping a journal to see if there's any pattern. Yesterday it came on at 2:18 PM, 18 minutes after it shuts off for the afternoon (11-2) schedule. I will report back after 2:18pm today to see if it runs. Below is my current firmware info.... Thanks for any help
 

Attachments

  • ScreenLogic2.JPG
    ScreenLogic2.JPG
    69.1 KB · Views: 3
Last edited:
Hey not sure if you've gotten any farther, but you do have the latest Easytouch firmware (on the outdoor board anyway - I forget if you had an indoor or handheld remote)

Depending on how far down the rabbit hole you want to go, you "could" install node js pool controller (there are threads on it at tfp) and use it's message monitor to see if there's an actual message being sent to the pump (over rs485) to tell it to turn on.
 
Hey all. No updates in a while due to holidays. Pentair has been zero help. They sent a dispatch to local warranty company who promptly called me for a $200 deposit since the pump is under warranty but the ET4 is not. I will automatically be charged if it turns out its not the pump. Yeah.... but no. I can get a new ET motherboard and install it myself for $400. I had a strong feeling the ET is the culprit here so I disconnected the 485 inputs to the pump and programmed the pump with the same schedules the ET had. No more random starts. Of course this would work perfectly fine at this point for the less neurotic, but I paid good money for this, and I want it to do its job. Plus, I like having all the management under one umbrella, thats the whole point of the ET right ?

I think this pretty conclusively proves its the ET but I'd like a little more evidence to take back to Pentair so I took @ogdento suggestion and built a node.js pool controller. Everything is up and running, I can see the ET and receiving lots of data on the comm port. I found the log settings and set it to file capture triggers for the pump. I'm going to let it capture for a few days but I'm not really sure what to do with the file or how to read it so I could definitely use some guidance from here forward.
 
Last edited:
Allright well, I have figured out from the nice little wiki where to find the message monitor. It seems that since I have a pump but have disconnected it, the ET is constantly trying to find it with the action '4' and action '7' messages. But in the capture attached I do see the action '1' messages to set pump speed which seems curious since I have no programs set right now for the pump at all. Is this normal?

1737935348264.png
 
I finally captured one of the random starts in the message monitor, I have no idea how to read it though to see what it is telling the pump, but you can see in the log it causes a state change at ID: 21633 where there is no program set to run. This happened four minutes after the last program ended for the night (ID 21576) and the pump shut off. @rstrouse , sorry to bother but could you assist in decoding this, I'd love to send this over to Pentair, but I'm not really sure what its saying.

1738204021858.png
 
hey Maverick, not sure if you've found out anything about message 21633... forgive me if you know this already but the blue bytes are those that have changed since the last status check which was message 21607.

What's strange is that - and I'm not a message expert - it appears that the status data from 21633 indicates that the pump is ON... the power consumption is reported at 2200 watts at 3450 rpm (if I calculated it correctly: watts is byte 3*256 + byte 4 = 2200 and rpm is byte 5*256 + byte 6 = 3450)

see the Message Details section in github:
github.com

Message Manager

A dashboard panel for tagyoureit/nodejs-poolController - rstrouse/nodejs-poolController-dashPanel
github.com github.com

check here for more decoding information:
 
Hey Tom,

Nothing yet. I sent the log file off to Pentair this morning to see what they can figure out. What youre saying make sense, I'm learning as I go. 21633 is just a status message. I don't see where the OCP actually told it to turn on. I see a lot of message '6'';s (set drivestate), but they don't all activate the pump so its confusing. I'm attaching a subset of the log, since its too many actions to show in one screen. It starts a little before the change action of turning off the pump for the night based on the programming in the ET. This is message 21395 I believe. The pump turned back on 4 minutes later which would be somewhere around 21633, but as you noted, I don't think this is the actual action.
 

Attachments

  • pentaircapture.txt
    60.6 KB · Views: 2

Enjoying this content?

Support TFP with a donation.

Give Support
Update. Some good people still work at Pentair. I got in touch with one of my regional service managers (Rolando) and got some movement finally. They came out and swapped the motherboards on both the ET and the Intellifo 3. Unfortunately, this did not fix the issue :brickwall: . I'm noticing some potential patterns in the message file when the problem occurs. See below two examples where the log is missing/skipping a whole lot of messages then all of a sudden it wakes up exactly when the problem is happening. Its like the communications goes to sleep. In screenshot one the issue occurs between messages 41578 and 19079, in screenshot two it is between 25756 and 35203. These are huge jumps between message numbers with hours in-between with no messages, this is not normal as usually there is communication every few seconds. Note: no filters are applied in the log. I'm not sure what else could be causing this considering the changed out both motherboards.


Capture1.JPG2Capture.JPG
 
I'm starting to think possibly this must have something to do with the screenlogic maybe, its the only component left that wasn't replaced. Any thoughts anyone?
 
MaverickFL said:
its the only component left that wasn't replaced
Click to expand...
Not so. 90% of electronic issues are due to fault/dirty cables and connectors. 99.5% of that statistic was made up, but the number is up there. Review, clean, lube and tighten connectors to eliminate that potential problem. Then consider replacing cables.
 
I have never heard of anyone lubing their cables or connectors, thats a new one, but, I have double and triple checked all the wiring and connectors several times and although I could replace all the cables, nothing is pointing to that as a leading cause. Why would the cables cause problems only when no programs are running ?
 
You can disconnect the RS-485 Screenlogic connection or the PA and let your system run for a while and see if the problem occurs.
 
  • Like
Reactions: Dirk and MaverickFL
MaverickFL said:
I have never heard of anyone lubing their cables
Click to expand...
The grease I linked is for the metal contacts of connectors (not for the wire cable itself). The grease inhibits corrosion, which can break an electrical connection, or worse, introduce resistance that can theoretically play havoc with communication signals.

MaverickFL said:
Why would the cables cause problems only when no programs are running ?
Click to expand...
Any answer would be a guess (one guess is above).

Troubleshooting 101:
- Isolate components (exactly as @ajw22 is suggesting above), to determine if any one component is responsible for the problem.
- Replace components (including cables), one at a time, to determine if any one component is responsible for the problem.

Sounds like you're working through those steps, I was just pointing out an often overlooked potential problem source (cables).
Another potential problem is the possibility that more than one component is causing the issue (which really complicates the "replace one at a time" MO, or worse two components together cause a problem, but neither separately.

Not much help, I realize. Just brainstorming...
 
Thanks for all the suggestions guys. Trying to work through this methodically since as noted it is a complicated issue. I think the logs could hold some clues but Pentair basically dismisses the pool-monitor tool/logs and refuses to review the data.

Anyway, last night I disconnected the ScreenLogic transponder from the ET. It was cool here last night in S FL and I slept with the doors open and didn't hear the pump go on, which I usually would. Too soon to make any conclusions because it could just be that I slept through any startups, but potentially positive.

On another note, I'm learning some things about the monitoring. What I stated above about the packets 'stopping' seems to be the result of the monitoring tab on the browser 'going to sleep', and it stops recording packets, not the ET itself. When I check the packet logs directly on the Pi, it does not skip thousands of packets. I also see that the packet count goes from 0-80,000 and then resets itself automatically back to 0 again pretty consistently. In checking the log, the packets do seem continuous at those times where I'm having the problem, so what I think is happening is that when I hear the pump go on, I run into the office and 'wake' up the monitor tab on the computer and it starts recording again.

Going to keep posting here until a resolution is found.
 
  • Like
Reactions: Dirk
When using the PoolMonitor app from an external browswer like Edge, the default setttings are too sleep unused tabs to conserve resources, there is setting under settings, "system and performance" / "Never put these sites to sleep" to prevent certain sites from sleeping, this will keep the log from skipping entries as what happened to me. Add your PoolMonitor IP address here:

1739906390034.png
 
  • Like
Reactions: ogdento
Perhaps the final update for this thread. Although I cant say why, or 100% for certain, the screenlogic adapters seem to have somehow been causing the problem. I disconnected the screenlogic for a few days and did not notice any phantom starts on the pump. Then I shut everything down on the screenlogic and rechecked all the wiring and connections, I brought it back up a week ago and haven't had any phantom starts that I've noticed since then. I've been sleeping with the door open for a few nights and typically within a week I would have experienced the issue several times by now. Unless something changes, I'll call this one resolved. Anybody want to buy a Raspberry PI fully configured ?
 
  • Like
Reactions: Dirk

Enjoying this content?

Support TFP with a donation.

Give Support
You must log in or register to reply here.
Top Bottom
Back
Jump to latest Follow Reply