Not communicating with ScreenLogic--how to debug? #1048
Replies: 58 comments 34 replies
-
|
I see warnings about the serial port being "inactive", and opening and closing serial port messages: [12/6/2024, 11:29:43 AM] warn: Inactivity timeout for 0 serial port /dev/ttyUSB0 after 10 seconds |
Beta Was this translation helpful? Give feedback.
-
|
It's pretty clear the serial communication is not working. I think the njs app is closing the port when there is 10 seconds of inactivity, then reopening it. When I do "od -x > /dev/ttyUSB0 on the rpi, it just hangs. I think this means there's nothing on the serial interface. But, when I do lsusb -v on the rpi: Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter Maybe I've connected the wires from the USB dongle to the Pentair protocol adapter incorrectly, but I'm pretty sure the connections are the same as when everything was working:
What's the easiest way to test the serial interface? Seems like I'll need another USB to serial adapter for my windows machine or another rpi to test it. Is there a better way? |
Beta Was this translation helpful? Give feedback.
-
|
I may have figured out what's wrong. I found this:
I had the D+ signal wire from the RPI serial dongle connected to +15 on the protocol adapter! I know the wires came loose from the terminal block at some point and I probably just matched the wire colors going to the serial dongle to the wire codes going from the protocol adapter to the Pentair wireless adapter. The red wire from the protocol adapter to the wireless interface adapter was actually 15V, not the +DT signal Now when I move the D+ wire from the rpi to the +DT on the protocol adapter, not only do I see nothing on the RPI serial input, but screenlogic quits working. So, I'm thinking I've fried the CH340 by putting +15 on the D+ input and it now loads the Pentair +DT so that it won't toggle I could just order a new one and try it, but I'm first going to see if I can figure a way to test if it is actually damaged. Maybe I'll bother to lug my o-scope or logic analyzer down to where the protocol adapter is mounted and take a look at what's going on. |
Beta Was this translation helpful? Give feedback.
-
|
Got the new CH340 but I'm still having issues. Not the same symptoms thoug. First, when the CH340 is connected to the protocol adapter, ScreenLogic can't connect. But, if I power down the RPI, screenlogic connect and works normally. When the rpi is powered back up, ScreenLogic disconnects. Is it Ok to have both serial interfaces wired simultaneously? I think that's what I've had in the past. Now I see stuff from the rpi: pi@PoolController:~ $ od -x < /dev/ttyUSB0 But, the dashPanel is still not valid except for the Chemistry section:
Now the logs have some more interesting info; I'm pretty much stuck now and could really use some help. |
Beta Was this translation helpful? Give feedback.
-
|
Anyone still monitoring the discussions? Unless someone has a better suggestion, I'll try a new rpi and starting over. It would really help to know if it's ok to have the CH340 driving the same D+ and D- signals that are being being driven by the Pentair protocol adapter... |
Beta Was this translation helpful? Give feedback.
-
|
You should not have both interfaces running simultaneously. Stick with the RS485 interface. It gives full control. The Screenlogic interface is very limited and should only be used when there isn't another option or the end user doesn't have the technical skills. |
Beta Was this translation helpful? Give feedback.
-
|
It worked fine with both connected for a couple of years... I agree dashPanel is much better, but sometimes things are working right and it's nice to fall back to ScreenLogic. BUt, anyway I can get njsPC working again I will do! I have tried disconnecting the protocol adapter from the serial lines but it doesn't change anything. I have a new RPI and new CH340. I'm seeing packets on the RPI usb/serial interface. I see screenlogic messages in the dashPanel logs. REM works fine with dashPanel, dashPanel finds the njs PC server without issue. But, I no longer see much on the dashPanel, no pumps, temps, etc. What can I do to check if config.json is correct? Or how else How should I proceed to debug? |
Beta Was this translation helpful? Give feedback.
-
|
But, I didn't try starting over with only the CH340 connected to the Pentair Wireless adapter. Do you really think having both the "protocol adapter" and the RPI driving the serial interface could cause what I'm seeing? I was under the impression from an rstrouse post (months ago) that having both drive the DIN shouldn't be an issue (clearly having both watch DO shouldn't cause an issue. It seems more like a software configuration option. Should the screenlogic equipment be automatically found after installation and start up, or do I need to edit something in the config.json? (Restore of old back up files fails with a stack dump) |
Beta Was this translation helpful? Give feedback.
-
|
You should be only using the RS-485 connection. If you use the CH340 but wire directly into the protocol (wireless) adapter then that's still RS-485. Only if you select Screenlogic in the comms section will it try to connect using TCP to the Screenlogic interface. If you are seeing screenlogic messages in the logs then, yes, you should make a backup of the ./data files and start over. The system will read all of the settings directly from the OCP. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't know about the option to use a tcp interface to ScreenLogic. That seems better if it eliminates the need to use the RS485 dongle. Is that correct, the RS485 interface is not required for an interface to screenLogic? Or will that limit the functionality I could have versus using the RS485 interface? I found the ScreenLogic in the pulldown for PortType and my ScreenLogic is found at the correct IP address and it seems to nitializes properly. Still, my dashPanel is minimal: And I'm seeing no packets in the packetLog Short of creating an entire new rpi image, what do I need to start over with a new poolController and dashPanel install? I've tried npm start, but that hasn't changed anything. I guess I'd like to uninstall everything npm and go through the documented install process from there. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
First off, as I mentioned above, the Screenlogic interface is limited compared to RS485. Stick with RS485 and ignore the Screenlogic connectivity. I'm not seeing anything in your logs about trying to open the comms port. You need to figure out how you have njsPC started (PM2? systemd?). Then stop/restart njsPC or reboot the RPI because the chem controller is still trying to run even though you chose the option to 'capture configuration reload' (this should be fixed in 8.0.5). You don't need to reinstall everything. |
Beta Was this translation helpful? Give feedback.
-
|
I use systemd. I've tried sudo systemctl "restart poolController" and "systemctl restart dashPanel" many times. Those services are enabled at boot. Is restarting the services sufficient for a query to be issued to get the installed equipment? njsPC is great when it works. But, often I have issues and need to still turn off/on spa, etc. That's why it's nice to be able to use either interface like I did for several years. But, again, let's ignore that. right now I just want to get nodejs working again. Does using the tcp interface (by selecting scrrenLogic under RS485 port type limit functionality? I thought maybe I didn't need RS485 that if communictating with the Pentair equipment using a TCP connection. (Just because you labelled it ScreenLogic, I didn't assume that meant only ScreenLogic would work. I figured packets would be sent over TCP instead of the serial interface.) Can you explain if/how the serial interface to the Pentair equipment limits functionality versus a TCP connection that is achieved by choosing ScreenLogic as the "RS485" comm type (I know it's not RS485, but it's under than menu in dashPanel UI). If it will work that way without limitation, less hardware is better. Thanks for your attention. |
Beta Was this translation helpful? Give feedback.
-
|
Also, you didn't see the comm port open in those logs because I wasn't using the RS485 interface. When I use the RS485 interface, you see the successful open of the serial port in the logs. If I can't get full functionality without using the RS485 interface, I'll next confirm I can communication from the RPI over the RS485 interface using something other than the Pentair stuff. I was seeing packets on the serial interface, but not now. Maybe the terminal block connections aren't good, broken wire, or something like that. I was hoping use of TCP would eliminate the need for the serial interface, but I'll go back over that at this point. I don't what else to try. |
Beta Was this translation helpful? Give feedback.
-
|
Screenlogic limits the amount of control we have over the OCP. TCP is only used between the Screenlogic interface and Pentair servers some on the internet. The OCP doesn't talk TCP - it only talks RS485. As soon as we see any packets on the RS485 bus we will initiate a full configuration with the OCP. Here's your plan:
In #1048 (comment) 2 weeks ago, you were seeing the correct packets come through. If you are still seeing those, you can either look at the ./data/poolState.json file or put in http://{server}:4200/state/all (which will return the same thing). If you are seeing your pool data there, then you have an issue with dashPanel connecting to njsPC. dP will connect to njsPC based on the connection menu (open it with the hamburger menu in the upper left). 
|
Beta Was this translation helpful? Give feedback.
-
|
I reconnected the CH340 to the Pentair Wireless Transceiver. To be clear, here's what I'm doing:
I'm using od -x < /dev/ttyUSB0 to check if the RPI is seeing anything on the serial interface. Interestingly, I didn't see anything until I reversed the D+ and D- wires. I thought I'd see data either way, but the bits would be inverted if I got them switched.... When I issue http://{server}:4200/state/all I see this {"systemUnits":{"val":0,"name":"english","desc":"English"},"startTime":"2024-12-21T07:37:04.452-0500","time":"2024-12-21T07:55:00.143-0500","valve":3,"delay":{"val":0,"name":"nodelay","desc":"No Delay"},"batteryVoltage":0,"status":{"val":1,"name":"ready","desc":"Ready","percent":100},"mode":{"val":0,"name":"auto","desc":"Auto"},"appVersion":"8.0.5","appVersionState":{"gitLocalBranch":"master","gitLocalCommit":"6e5663132986e544dd83fed910470ea505a39751","installed":"8.0.5","status":{"val":2,"name":"ahead","desc":"Ahead of published version"},"nextCheckTime":"2024-12-23T06:45:51.628-0500","githubRelease":"8.0.4","equipmentType":"appVersion"},"clockMode":{"val":12,"name":"12 Hour"},"clockSource":{"val":3,"name":"server","desc":"Server"},"controllerType":"nixie","model":"Nixie Single Body","sunrise":"2024-12-21T07:22:29.000-0500","sunset":"2024-12-21T17:06:21.000-0500","nextSunrise":"2024-12-22T07:22:57.000-0500","nextSunset":"2024-12-22T17:06:53.000-0500","alias":"DavePool","freeze":false,"valveMode":{"val":0,"name":"off","desc":"Off"},"temps":{"units":{"val":0,"name":"F","desc":"Fahrenheit"},"bodies":[{"id":1,"heaterOptions":{"total":0,"gas":0,"solar":0,"heatpump":0,"ultratemp":0,"hybrid":0,"mastertemp":0,"maxetherm":0},"isCovered":false,"heaterCooldownDelay":false,"startDelay":false,"stopDelay":false,"showInDashboard":true,"heatMode":{"val":0,"name":"off","desc":"Off"},"name":"Pool","setPoint":87,"circuit":6,"type":{"val":0,"name":"pool","desc":"Pool"},"heatStatus":{"val":0,"name":"off","desc":"Off"}}],"equipmentType":"temps"},"equipment":{"messages":[],"model":"Nixie Single Body","maxBodies":1,"maxCircuitGroups":16,"maxCircuits":40,"maxFeatures":32,"maxHeaters":16,"maxLightGroups":16,"maxPumps":16,"maxSchedules":100,"maxValves":32,"single":true,"shared":false,"dual":false,"controllerType":"nixie","equipmentType":"equipment","softwareVersion":"1.0.0","bootLoaderVersion":""},"pumps":[],"valves":[],"heaters":[],"chlorinators":[],"circuits":[{"id":6,"freezeProtect":false,"action":{"val":0,"name":"ready","desc":"Ready"},"type":{"val":12,"name":"pool","desc":"Pool","hasHeatSource":true,"body":1},"showInFeatures":false,"name":"Pool","startDelay":false,"stopDelay":false,"equipmentType":"circuit"}],"features":[],"circuitGroups":[],"lightGroups":[],"virtualCircuits":[{"id":246,"isActive":true,"isOn":false,"type":{"val":246,"name":"freeze","desc":"Freeze"},"name":"Freeze","equipmentType":"virtualCircuit"},{"id":247,"isActive":true,"isOn":false,"type":{"val":247,"name":"poolSpa","desc":"Pool/Spa"},"name":"Pool/Spa","equipmentType":"virtualCircuit"}],"covers":[],"filters":[{"id":1,"name":"Filter 1","body":{"val":0,"name":"pool","desc":"Pool"},"filterType":{"val":3,"name":"unknown","desc":"Unknown"},"equipmentType":"filter"}],"schedules":[],"chemControllers":[{"id":50,"saturationIndex":0.792,"flowDetected":true,"orp":{"probe":{"saltLevel":0,"level":392.7,"equipmentType":"probe","enabled":true,"master":1,"remFeedEnabled":true,"type":1,"connectionId":"1e9e8a0b-9b1b-4609-819b-ac059f99e13d","deviceBinding":"i2c:1:1","remFeedId":1},"chemType":"orp","useChlorinator":false,"type":"orp","tank":{"capacity":15,"level":0,"units":{"val":1,"name":"gal","desc":"Gallons"},"alarmEmptyEnabled":true,"alarmEmptyLevel":10,"equipmentType":"tank","master":1},"pump":{"isDosing":false,"equipmentType":"pump","type":{"val":1,"name":"relay","desc":"Relay Pump","ratedFlow":true,"tank":true,"remAddress":true},"ratedFlow":75,"enabled":true,"master":0,"connectionId":"1e9e8a0b-9b1b-4609-819b-ac059f99e13d","deviceBinding":"gpio:1:38"},"dosingTimeRemaining":0,"delayTimeRemaining":0,"dosingVolumeRemaining":0,"doseVolume":300,"doseTime":0,"lockout":false,"level":392.7,"mixTimeRemaining":0,"dailyLimitReached":false,"manualDosing":false,"manualMixing":false,"flowDelay":false,"dosingStatus":{"val":2,"name":"monitoring","desc":"Monitoring"},"enabled":true,"freezeProtect":false,"doseHistory":[],"dailyVolumeDosed":0,"demand":0,"demandHistory":{"time":[1734785733,1734785722,1734785712,1734785702,1734785691,1734785681,1734785671,1734785661,1734785651,1734785640,1734785630,1734785620,1734785609,1734785599,1734785589,1734785579,1734785569,1734785558,1734785548,1734785538,1734785527,1734785517,1734785507,1734785497,1734785486,1734785476,1734785466,1734785455,1734785445,1734785435,1734785425,1734785414,1734785404,1734785394,1734785384,1734785373,1734785363,1734785353,1734785343,1734785332,1734785322,1734785312,1734785302],"value":[407.2,407.3,407.2,407.3,407.3,407.4,407.4,407.2,407.1,407.3,407.3,407.2,407.2,407.1,407.4,407.4,407,407.1,407.1,406.9,407.2,407,407.2,407.2,407.3,407.1,407,407.1,407.1,407.2,407.4,406.9,407.2,407.2,406.9,406.9,407.1,407.1,407.2,406.8,407.2,406.9,800],"slope":-0.12313525167805967},"volumeDosed":0,"timeDosed":0,"equipmentType":"orp","setpoint":800,"chlorDosingMethod":0,"tolerance":{"low":650,"high":820,"enabled":true},"phLockout":8.4,"doserType":{"val":1,"name":"extrelay","desc":"External Relay"},"dosingMethod":{"val":2,"name":"volume","desc":"Volume"},"startDelay":0,"flowReadingsOnly":false,"flowOnlyMixing":true,"maxDailyVolume":4000,"disableOnFreeze":false,"master":1,"chlor":{"master":0},"maxDosingTime":0,"maxDosingVolume":300,"mixingTime":600},"ph":{"probe":{"temperature":25,"level":7.995,"tempUnits":{"val":4,"name":"C","desc":"Celsius"},"equipmentType":"probe","enabled":true,"master":1,"remFeedEnabled":true,"type":1,"feedBodyTemp":false,"connectionId":"1e9e8a0b-9b1b-4609-819b-ac059f99e13d","deviceBinding":"i2c:1:2","remFeedId":1},"tank":{"capacity":15,"level":0,"units":{"val":1,"name":"gal","desc":"Gallons"},"alarmEmptyEnabled":true,"alarmEmptyLevel":10,"equipmentType":"tank","master":1},"pump":{"isDosing":false,"equipmentType":"pump","type":{"val":1,"name":"relay","desc":"Relay Pump","ratedFlow":true,"tank":true,"remAddress":true},"ratedFlow":75,"enabled":true,"master":0,"connectionId":"1e9e8a0b-9b1b-4609-819b-ac059f99e13d","deviceBinding":"gpio:1:40"},"dosingTimeRemaining":0,"delayTimeRemaining":0,"dosingVolumeRemaining":0,"doseVolume":0,"doseTime":0,"lockout":false,"level":7.995,"mixTimeRemaining":0,"dailyLimitReached":false,"manualDosing":false,"manualMixing":false,"flowDelay":false,"dosingStatus":{"val":2,"name":"monitoring","desc":"Monitoring"},"enabled":true,"freezeProtect":false,"chemType":"ph","type":"ph","doseHistory":[],"dailyVolumeDosed":0,"demand":0,"equipmentType":"ph","setpoint":7.6,"phSupply":{"val":1,"name":"acid","desc":"Acid pH-"},"acidType":5,"tolerance":{"low":7.3,"high":7.799999999999999,"enabled":true},"dosePriority":true,"doserType":{"val":1,"name":"extrelay","desc":"External Relay"},"dosingMethod":{"val":2,"name":"volume","desc":"Volume"},"startDelay":4.999999999999998,"flowReadingsOnly":false,"flowOnlyMixing":true,"maxDailyVolume":3000,"disableOnFreeze":false,"master":1,"maxDosingTime":0,"maxDosingVolume":300,"mixingTime":600},"flowSensor":{"state":{"val":1,"name":"on","desc":"On","inst":"The pin is currently on.","gpio":1,"boolean":true},"type":{"val":1,"name":"switch","desc":"Flow Switch","remAddress":true},"enabled":true,"master":1,"minimumFlow":1,"minimumPressure":1,"connectionId":"1e9e8a0b-9b1b-4609-819b-ac059f99e13d","deviceBinding":"gpio:1:37"},"type":{"val":4,"name":"rem","desc":"REM Chem","ph":{"min":6.8,"max":8},"hasAddress":false},"alarms":{"flow":{"val":0,"name":"ok","desc":"Ok - No alarm"},"pH":{"val":2,"name":"phhigh","desc":"pH Level High"},"orp":{"val":16,"name":"orplow","desc":"orp Level Low"},"pHTank":{"val":0,"name":"ok","desc":"Ok - No alarm"},"orpTank":{"val":0,"name":"ok","desc":"Ok - No alarm"},"probeFault":{"val":0,"name":"ok","desc":"Ok - No alarm"},"pHProbeFault":{"val":0,"name":"ok","desc":"Ok - No alarm"},"orpProbeFault":{"val":0,"name":"ok","desc":"Ok - No alarm"},"pHPumpFault":{"val":0,"name":"ok","desc":"Ok - No Faults"},"orpPumpFault":{"val":0,"name":"ok","desc":"Ok - No Faults"},"chlorFault":{"val":0,"name":"ok","desc":"Ok - No Faults"},"bodyFault":{"val":0,"name":"ok","desc":"Ok - No Faults"},"flowSensorFault":{"val":0,"name":"ok","desc":"Ok - No Faults"},"comms":{"val":0,"name":"ok","desc":"Ok"},"freezeProtect":{"val":0,"name":"ok","desc":"Ok - No alarm"}},"warnings":{"waterChemistry":{"val":2,"name":"scaling","desc":"Scaling May Occur"},"pHLockout":{"val":0,"name":"ok","desc":"Ok - No limits reached"},"pHDailyLimitReached":{"val":0,"name":"ok","desc":"Ok - No limits reached"},"orpDailyLimitReached":{"val":0,"name":"ok","desc":"Ok - No limits reached"},"invalidSetup":{"val":0,"name":"ok","desc":"Ok - No limits reached"},"chlorinatorCommError":{"val":0,"name":"ok","desc":"Ok - No Warning"}},"siCalcType":{"val":0,"name":"lsi","desc":"Langelier Saturation Index"},"status":{"val":0,"name":"ok","desc":"Ok"},"lastComm":1734785732463,"body":{"val":0,"name":"pool","desc":"Pool"},"name":"REM Chem1","isActive":true,"csi":0.664,"lsi":0.792,"activeBodyId":1,"equipmentType":"chemController","borates":0,"alkalinity":100,"calciumHardness":400,"cyanuricAcid":0,"lsiRange":{"low":-0.5,"high":0.5,"enabled":true},"master":1,"firmware":"2.000"}],"chemDosers":[],"delays":[]} poolState.json is attached[ But, no change on what I see in dashPanel. dashPanel seems to find the server without issue:
|
Beta Was this translation helpful? Give feedback.
-
|
The fact that the rpi only sees activity on the serial port when the wires are "reversed" (relative to what I think they were when everything was working) makes me think the serial comm is not really working.
Do you agree? Thanks for your continued help and patience! |
Beta Was this translation helpful? Give feedback.
-
|
The indoor Pentair wireless transceiver has a terminal block with 4 connections labelled like this:
The CH340 has only a D+ and D- connection. No ground reference, so I've been assuming the D- is reference and D+ is the data. (versus one signal being Rcv and one being Tx). I see this referenced on your wiki:
I do NOT see FF00FFA5 repeated a number of times. But, I see nothing at all when I reversed the D+ and D- connections. I tried a brand new CH340 (I bought two when I started chasing this again), but same result. If you confirm this means serial comm isn't working, I'll pull new wires between the RPI and Pentair wireless adapter. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible that the wireless transceiver doesn't actually drive the D- (presumably the reference for the data signal) since it would normally be an input from the protocol adapter? That would explain why everything worked when the protocol adapter was left connected--it was driving the D- input versus leaving it floating. I'll try connecting the D- only of the the protocol adapter (assuming it's an output) to the CH340 and wireless adapter. But leave the D+ from the protocol adapter unconnected. |
Beta Was this translation helpful? Give feedback.
-
|
Didn't help--still no data seen by RPI unless wires D+ and D- are reversed--and then the data doesn't have the "magic" signature. |
Beta Was this translation helpful? Give feedback.
-
You can have both the CH340 and the protocol adapter wired to the transceiver at the same time. Do you have njsPC stopped when using And if your screenlogic app works (when hooked up) then there are proper comms between on the D+/D- wires. You need both wires for RS485 to work properly. |
Beta Was this translation helpful? Give feedback.
-
|
You can have both the CH340 and the protocol adapter wired to the transceiver at the same time. I thought this was what you were telling me NOT to do. Did I misunderstand? Or did you mean to only use USBTTY0 as the port in dashPanel? (That's what I was doing all along, until you mentioned it, I didn't even know ScreenLogic was an option there). So, now I back to having the Protocol Adapter driving the wireless transceiver. When D+ and D- are also connected to the CH30, ScreenLogic won't connect. Now I see the expected signature packets using od -x: pi@PoolController:~ $ od -x < /dev/ttyUSB0 But still the same "partial" dashPanel:
The log files indicate the serial port is being open, but then later closed due to inactivity. (same as what I've always seen in this configuration. replay (13).zip |
Beta Was this translation helpful? Give feedback.
-
You should not have both screenlogic protocol in the app and the rs485 port enabled at the same time. The actual rs485 bus can have any number of devices connected. Since you are seeing the correct results in |
Beta Was this translation helpful? Give feedback.
-
|
You should not have both screenlogic protocol in the app and the rs485 port enabled at the same time. The actual rs485 bus can have any number of devices connected. Ok, so I've never had screenlogic protocol enabled in the dashPanel app, except when I briefly tried it as a "fix" after seeing: Only if you select Screenlogic in the comms section will it try to connect using TCP to the Screenlogic interface. In one of your replies. There are two instances of node dist running, one for dashPanel and one for njsPC; pi@PoolController:/etc/systemd/system $ ps -ef | grep node The node instances have different WorkingDirectories: [Unit] [Service] [Install] dashPanel: [Unit] [Service] [Install] If I stop both services, I don't see an instances of nodejs: @PoolController: |
Beta Was this translation helpful? Give feedback.
-
|
And, after restarting both services, dashPanel only sees one instance of the server:
|
Beta Was this translation helpful? Give feedback.
-
|
Despite the warnings, I tried doing a restore of an old backup when everything was working. But now, even though the njsPC server is found, dashPanel says it won't connect. At this point, I think I need to delete and re-install njsPC and dashPanel. I don't care how long it takes--what do I need to do "clean up" before I git the latest and start over? |
Beta Was this translation helpful? Give feedback.
-
|
At a minimum delete all associated directories for the pool apps. But if you haven't done a fresh install of the o/s in a while, maybe something else is going on? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, all new RPI image (latest for RPI 3B+). When I do the npm start & in the nodejs-poolController. I don't see the "found controller board Intellicenter" in the resulting messages as documented in the install instructions. I think this means the RS485 communication isn't working.
Init state for Pool Controller But, the RPI is still seeing things on the serial port: pi@PoolController:~ $ od -x < /dev/ttyUSB0 |
Beta Was this translation helpful? Give feedback.
-
|
Basic question about the RS485 communication. Why are the two signals on the CH340 dongle labelled D+ and D-? These are the signal names on the USB interface, not typical RS485 signal names (ie TxD, RxD). I can find no documentation on the dongles I bought from Amazon, but here is a schematic of CH340 USB to serial converter:
The D+ and D- signals are on the USB side!! Maybe the damn dongles I bought don't really work for both Transmit and Receive? Note that just connecting the dongle kills the ability to use ScreenLogic--it shouldn't if it's true that any number of RS485 devices can be connected, right? rstrouse? Where can I find a USB to serial converter that is known to work in this application? |
Beta Was this translation helpful? Give feedback.
-
|
Turning filter pump off on from EasyTouch panel |
Beta Was this translation helpful? Give feedback.
-
|
Let me know when you've looked at those logs and what you learn. I can hook up to the serial wires at the EasyTouch panel, but that's a bit of a hassle and I don't want to bother unless you really think we'll learn something by doing that. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This thread is too long... I think it might be useful to summarize what we know.
History:
|
Beta Was this translation helpful? Give feedback.
-
|
I can't get a simple loopback test using minicom to work. Tried both the newer "Industrial" version that uses an FT232 and the older CH340. I don't get any echos from key presses using minicom. Both show up under /dev/ttyUSB0. Permissions for /dev/ttyUSB0: pi@PoolController:/dev $ ls -altr ttyUSB0 Note there is no write permission for user. But one of the first things I tried (weeks ago) was adding user pi to group dialout and also chmod 777. I wasn't doing the wrap test then, just using njsPC and noticing only input data, no output. Running minicom as sudo doesn't make it work either. Not supposed to need a driver on Linux. I tried disabling bluetooth in config.txt, but that didn't change anything. I was thinking maybe flow control was on be default, but I haven't been able to do any configuration that makes the wrap test work. I think I need to get the simple serial wrap test working! I'll keep researching and maybe ask for help on that. |
Beta Was this translation helpful? Give feedback.
-
This isn't possible. If you have two different usb serial ports plugged in at the same time the second one should be on ttyUSB1. Still, njsPC isn't trying to write anything because it isn't receiving the right packets. |
Beta Was this translation helpful? Give feedback.
-
|
I did not have them plugged in at the same time. Separate experiments. I have three USB to serial dongles. None of them echo characters using minicom on Linux. One of them echos using putty on Windows 10, but not the right character. Seems like I need to get something that passes a wrap back test before chasing other stuff. Agree? |
Beta Was this translation helpful? Give feedback.
-
|
In other words, I tried both usb serial dongles (seperately). Both were recognized correctly--they showed up under /dev/ttyUSB0. I never had two plugged in the same time. What kind of idiot do you think I am? Wait, don't answer that... |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha. I thought you were trying to send from one and receive on another. |
Beta Was this translation helpful? Give feedback.
-
|
All three captures show the same thing - you are only receiving packets that are being sent from ScreenLogic to the OCP. Your previous Are you sure that Screenlogic is getting updates from the OCP? If you change a circuit, or turn a pump on/off, etc at the OCP does it reflect the change in Screenlogic? My guess is the rs485 chip in the screenlogic might be bad. Or maybe one on the OCP. I've had to replace the RS485 chips on my main OCP and also the intellichlor power center. #619. |
Beta Was this translation helpful? Give feedback.
-
|
btw, having od -x running kills reception of the data by njsPC. Researching that--it's expected. You have to go through hoops to have more than one process listen in on the serial port. Just mentioning that, because inconsistent results may have been reported in previous weeks since I was not careful to kill the od command when experimenting with njsPC. I've been careful about that the last week or so. |
Beta Was this translation helpful? Give feedback.
-
What is OCP? I think you mean to push buttons on the EasyTouch panel. But, I can't do that right now--pool is in freeze protect mode again. I do know that when I use screenlogic on my pc or phone, changes to set points, pool versus spa on/off, etc. show up on all devices. But, I don't know where that state is saved. |
Beta Was this translation helpful? Give feedback.
-
|
OCP = outdoor control panel. Yes, I mean to press a button on the panel. I believe Screenlogic will both set it's state locally and broadcast the change (it's been a while since I verified that). The theory is that Screenlogic looks like it's in sync, but it doesn't actually verify it because none of the status packets are being sent back to it. |
Beta Was this translation helpful? Give feedback.
-
|
Pool is still in freeze mode. I will try toggling stuff on OCP this afternoon. But, it sounds like you're not sure that we can conclude anything?
But, I agree with with where you are going-- I need to figure out how to test two way serial communication between the OCP and output of the indoor wireless transceiver. Meanwhile, I have another USB2Serial dongle ordered. Maybe I've been killing them when connecting to the (maybe damaged) wireless transceiver/protocol adapter. I can't get any of them to do the wrap test on either my windows machine or RPI as detailed in several online tutorials. That will get here in a couple of days. Meanwhile, I'm going to move the rpi close to the EasyTouch OCP and try wiring directly into the OCP wires there. I haven't opened up the EasyTouch top section in a while--I don't know how easy it will be to identify the RX and Tx wires. If I have disconnect the Pentair Wireless transceiver from the OCP, will njsPC work? Does it have any dependency on the protocol adapter that's inside and communicating with the other side of the wireless adapter (it's on the LAN)? |
Beta Was this translation helpful? Give feedback.
-
There's no dependency on the protocol adapter, other than if you are using that to physically connect the rs-485 wiring from it to your Pi. |
Beta Was this translation helpful? Give feedback.
-
Yes, when I turn the filter pump on/off at the OCP the state change shows up on the mobile ScreenLogic amp. |
Beta Was this translation helpful? Give feedback.
-
|
So strange we didn't see any of these messages in the logs. Next step, I would try to connect the Pi to the OCP directly and see what happens. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but only after I have a USB to serial that I verify works using loopback test. I should get it tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
I hooked up my oscope to the RS485 signals this morning. I wanted to check the signal levels to see if maybe the output drivers (or input buffers) of the Pentail protocol adapter/Wireless adapter were not driving to full voltage levels or loading the signals. The DT+ signal does look suspicious.... First, the DT- signal--it looks reasonable.
It looks like the up level is about 4.8 volts and the down level is 280 mv. There is an intermediate level of 1.5V--probably when nothing is driving the signal except pull up/pull down resistors. I'll brush up RS485 physical to check what the logic levels should be. IIRC a logic 0 is voltage high, logic 1 voltage low. Contrast that with the DT+ signal:
Up level is 4.7 volts, but it looks like the signal is never driven low--just high impedance at 2.0 volts. However, if I take lots of samples, I do see some traces where DT+ seems to be driven sorta low (840 mV), but 840 mv would be a marginal down level I thin
That would only make sense if nearly all bytes on DT+ are 0xFF. But that's not expected, is it? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, showed my ignorance. Reading up, RS485 is differential. So communication must be half-duplex, since there is only one set of wires. The DT+ and DT- shown in the Pentair Wireless adapter documentation make sense now--differential pair. I will retake the oscope images with DT+ minus DT- ... |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, so the DT+ and DT- don't look like what I've seen other pictures of DT+ and DT-. The examples I've seen show them the same, but opposite polarity. If you invert the DT-, the signals look the same. So, I think that means either the protocol adapter or Wireless transceiver RS485 I/O has been damaged. I have a buddy who has a similar setup. I'm going to put the oscope on his RS485 signals to see what they look like. I'm guessing as tagyoureit hinted, interfacing at the OCP RS485 will work. If it does and njsPC and dashPanel prove reliable, I won't even need the protocol adapter (or wireless transceiver)? But, I'd be "flying without a net", and there's been many times when I was having issues with njsPC/dashpanel and "fell back" to ScreenLogic. But, maybe those issues were a result of damage Pentair components (but strange they did not affect ScreenLogic, only njsPC). If I can determine whether the protocol adapter or transceiver is bad (assuming what I think I'll see is confirmed) I'd buy a replacement or maybe try to repair. Won't get to trying interfacing at the OCP today--I want to wait until it's a little warmer. |
Beta Was this translation helpful? Give feedback.
-
|
No such thing as an RS485 loopback test! I was confusing RS485 with RS232, aka, serial interface. As I said previously, the two wires on the RS485 are NOT send and receive (Txd and Rxd) but rather a half duplex, differential signal. So, you can't simply connect the D+ to the D- and expect to see anything echo'ed using minicom, putty, hyperterm, etc. You need two USB2RS485 converters talking to each other. On a windows 10 machine, I used two of the USB/RS485 adapters and two putty sessions. I could type in one putty session and the characters would show up on the other. Both ways OK. I tried the same on the pi using minicom Both dongles are recognized, one as /dev/ttyUSB0 and /dev/ttyUSB1. I started a minicom session for each: minicom -d 9600 -D /dev/ttyUSB0 and minicom -d 9600 -D /dev/ttyUSB1 But, typing characters in either session don't show up in the other session. However, when I close one of the minicom sessions, everything I typed showed up in the other session. So, there must be some sort of buffering in place that doesn't send characters until something like an EOL is sent. I need to get to the bottom of that first. Probably some parameter on minicom needs to be set to disable the buffering. Regardless, based on my o-scoping of the RS485 between the Pentair Protocol and Wireless adapters, that one of those two modules is either not driving one of the signals, or is driving when it shouldn't. As you suggested, I'll try connecting to the RS485 in the OCP. Still waiting for not so nasty weather to do that. Thanks for your support. |
Beta Was this translation helpful? Give feedback.
-
|
Same issue, someone else: |
Beta Was this translation helpful? Give feedback.
-
|
Needed to configure minicom to disable flow control (on by default) and
I'll find code snippet in njsPC where the serial port is configured to make sure flow control is disabled. I |
Beta Was this translation helpful? Give feedback.
-
|
FINALLY! Connecting the RPI RS485 wires to the outdoor Pentair wireless link fixed it! I think that means that the storm that broke njsPC actually damaged the indoor, wireless link. On of the RS485 wires oscillates in one of the states instead of being in the opposite state of the other wire. What made this so difficult to troubleshoot is that the Pentair protocol adapter deals with the "corrupted" differential signal without issue. That's really surprising after looking a the actual signals. Also, my careless assumption about RS485 being more like RS232 led me astray. If I'd read up on RS485 instead of assuming i knew all I needed, I would not have concluded the the USB/RS485 dongles were bad and maybe getting damaged. Should have oscoped the signals first thing rather than thinking I'd botched something up in njsPC configuration. I'm certainly not going to "pony up" for a replacement, Pentair wireless link. I can just locate the Pentair protocol adapter inside the outdoor enclosure that houses the REM rpi (which now also runs njsPC). I realize I don't really need ScreenLogic, but why not preserve that alternative? It provides redundancy to the njsPC hardware and software. And that back-up has proven to be a necessity over the several years I've been running njsPC. Thanks again for your attention! |
Beta Was this translation helpful? Give feedback.
-
|
Glad you found the culprit. That was quite an adventure! |
Beta Was this translation helpful? Give feedback.
-
It used to all work--I could use either ScreenLogic or the njs UI for setting temps, monitoring pump, status, etc.
Several months ago control via either UI became unreliable. When I disconnected the two wires from the ScreenLogic controller to the RPI running njS, screenLogic became reliable. I figured the USB to serial converter dongle had gone bad and ordered a new one.
I just got around to trying the new dongle, but it seems the interface to the Pentair stuff still isn't working (REM continues to work fine):
Here's a log file, but I can figure out what's wrong from it:
replay (3).zip
Can someone advise on how to debug what's wrong?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions