Not communicating with ScreenLogic--how to debug? #1048
Replies: 28 comments 16 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.
-
|
Ordered another one of the one listed on the wiki. We'll see. |
Beta Was this translation helpful? Give feedback.
-
|
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. I stopped there and ordered a new USB to RS485 dongle. But can you confirm that if that message is missing, communication over the RS485 isn't working correctly? |
Beta Was this translation helpful? Give feedback.
-
|
You are getting communications on the port because the
|
Beta Was this translation helpful? Give feedback.
-
|
Got the new dongle in today. It uses FT3233 instead of CH340. There are three connections and GND is included. That makes more sense to me, since the signals can be referenced to that, rather than the separated device grounds (they are not even on the same circuit breaker!) Now screenlogic works fine when the USB dongle is plugged into the pi, so I thought maybe I was making progress. I see packets on using the od command--I can change set point temperatures for the spa using ScreenLogic and see the packets with the od command. 0003020 c001 00ff a5ff 1001 d922 0001 b201 00ff But still, I'm not seeing the full dash panel display. njsPC is not able to see/access/read the usb port. Yup, 100% agree. But how to fix or at least figure out what's wrong? The messages to the console from the njsPC say the port is open successfully, then closed due to inactivity: 12/24/2024, 5:45:12 PM] warn: Inactivity timeout for 0 serial port /dev/ttyUSB0 after 10 seconds |
Beta Was this translation helpful? Give feedback.
-
|
Here is the console output when I start njsPC, REM is on another rpi, 192.168.0.69. Socket communication over the network between the njsPC rpi (192.168.0.31) and the REM pi appears to be working fine. @PoolController:~/nodejs-poolController $ npm start &
Init state for Pool Controller |
Beta Was this translation helpful? Give feedback.
-
|
Can you point me to the njsPC code that reads the serial port? Maybe I can somehow do some debugging to figure this out? Or, do you have a better idea? |
Beta Was this translation helpful? Give feedback.
-
|
/controller/comms/Comms.ts But this feels more like an access issue. Maybe the user that's running njsPC doesn't have the right permissions? I would recommend to stop the process using the systemctl command. And in the same terminal prompt where you are successful with |
Beta Was this translation helpful? Give feedback.
-
|
I've been doing it that way for a while. That's why the messages print to the console where I did the npm start. I won't enable the startup systemctl stuff until it's working again. |
Beta Was this translation helpful? Give feedback.
-
|
The RS485 activity I'm seeing may only be from the EasyTouch. The od -x < /dev/ttyUSB0 is printing input to the RPI. I should probably make sure that the rpi can actually write to the serial port. Read and write is required, right? |
Beta Was this translation helpful? Give feedback.
-
|
MERRY CHRISTMAS! |
Beta Was this translation helpful? Give feedback.
-
|
The messages to the console about closing serial port 0 due to inactivity are strange. I can toggle something like spillway on/off using Screen logic continuously. The rpi sees the packets as reported by the od -x < /dev/ttyUSB0 command. Yet, while continuously generating RS485 data, njsPC says it's closing the serial port due to inactiviy: [12/25/2024, 7:34:49 AM] warn: Inactivity timeout for 0 serial port /dev/ttyUSB0 after 10 seconds |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps the permissions on /dev/ttyUSB0 have changed in newer versions of linux? I did this: ls -altr /dev/ttyUSB0 Does this mean there are no permissions granted unless accessed by root or group plugdev? (Yet, the message from njsPC indicates the open was successful). I've had similar issues moving up from older Debian distributions. I used to be able to resolve them by changing the permissions of /dev directories but now that won't work. But even running the njsPc npm start as root (sudo npm start &) doesn't change anything. |
Beta Was this translation helpful? Give feedback.
-
|
There is a thread on an RPI forum about an app no longer able to communicate over USB dongle on the latest Debian (Bookworm): https://forums.raspberrypi.com/viewtopic.php?t=378844 They never did figure it out. Too bad if we have to go back to a deprecated version of Debian to run njsPC. Anyone running on Bookworm? |
Beta Was this translation helpful? Give feedback.
-
|
IT WORKS! (with an older image I had on my PC) I forgot that I made a clone of my SD image back last April. I flashed it to a new SD card and everything works fine. OS was Bullseye. So, I think that means something has changed in Bookworm that broke the code in njsPC that communicates with the serial port. My original problem was likely due to a bad USB-serial dongle (everything went south after a lightning storm that took out some other devices). I'll just stick with my old image, but if you want me to try stuff out so you can make sure njsPC will work on newer RPI images, I'll be glad to help. Thanks again for your attention! |
Beta Was this translation helpful? Give feedback.
-
|
Spoke too soon. Everything was working for a few minutes. Then, when I was testing stuff out dashPanel UI went back to what I've been seeing lately. Instead of showing EasyTouch I see "Nixie Single Body". So, I guess the old image had a "cached" configuration that got clobbered after a few minutes of running. Darn! |
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