Air Temperature Feeds from REM to Pool Controller but Water Temperature Does Not

[FlaMike]

I just built a new Nixie & stack with a Pi4 4GB, Bookworm Lite 64 bit OS, Smart Fan 6+, Building Automation Hat v4, and 8 Relay Board with EZO daughter board with ORP & pH (I think the pressure sensor died--it's rusty on the business end).

I seem to have a few configuration challenges, including the inability to feed successfully the water temperature from REM to Nixie. Air temperature works fine & they're configured similarly.

Also interesting is the lack of a green dot in the main 'Pool' panel, although the filter pump is running as you can see in the attached image. Additionally, no pH mixing time has shown up since the system was broght online. The pH was over 8 so I added some acid manually a few minutes ago because the acid feeder did not run in the few hours since this system was turned on several hours ago. The pH and ORP values seem reasonable & agree with the probe values in REM.

Sorry about the volume of screen shots, but even a mediocre picture is better than 5 pages of me droning on, I think.

Just thought of one possible explanation/cause... I loaded the most recent njsPC backup I had from 3 weeks ago. However, that system may have been from an older version, possibly 7.xx? Could that be the source of my challenges? If so, do I need to do software rebuild of njsPC and/or dashPanel? I reconfigured REM by hand, not from the backup. If I need to just discard the current configurations without rebuilding the software, what files do i need to discard/reset/whatever.

If you can help me solve these mysteries, I'd appreciate it greatly!

[tagyoureit]

Your pool circuit (which should be ID: 6) needs to be of type Pool. Otherwise, the system won't turn on and it won't read the temps. It shouldn't have any connection or device. The connection to the pump (if it isn't speaking RS485) should be on the Pumps page.

[FlaMike]

Thank you for your reply, the challenge is that the circuit type field is greyed out and I cannot set the type, it came up as generic so my only options were to specify No Connecttion or REM as the controller. Given that scenario, I picked REM and Filter Pump as the device, as it seemed the most reasonable choice at the time. I did not create this circuit, it was present when I brought up the system. I did create the other circuits in my previous post.

I'd be happy to select "Pool"as the type, but don't know how to do so. Do I delete this Pool and create a fresh one? How do I specify it is ID 6?

[tagyoureit]

Pull the latest commit. That should be locked to the POOL circuit, not a generic circuit. If you pull, and it still shows generic, then you can stop the app and manually check/update the following:

# data/poolConfig.json
  "circuits": [
    {
      "id": 6,  // 6 is the pool circuit
      "name": "Pool",  // You can change the name
      "showInFeatures": false,
      "freeze": false,
      "type": 12,  // it should be type 12
      "isActive": true,
      "eggTimer": 720,
      "master": 1
    }

# data/poolState.json
  "circuits": [
    {
      "id": 6,  // look for circuit 6
      "freezeProtect": false,
      "action": {
        "val": 0,
        "name": "ready",
        "desc": "Ready"
      },
      "type": {  // copy this whole key/value pair for 'type'
        "val": 12,
        "name": "pool",
        "desc": "Pool",
        "hasHeatSource": true,
        "body": 1
      },
      "showInFeatures": false,
      "name": "Pool",  // name should be the same
      "startDelay": false,
      "stopDelay": false
    }

Then restart the app.

[FlaMike]

Looks like we're back in business, but somehow not stable. On PM2 start everything looks good & remains so... for a while. Then RS485 collapses/fails & the pump & salt cell go offline. One "interesting" observation which is likely related, the serial port that the system uses (is active) is ttyAMA0, not ttyS0, as expected. No communication at all with ttyS0. If I select ttyAMA0 in njsPC communication is solid--low packet loss & everything is happy, until is isn't. However, ttyAMA0 doesn't appear to be stable, perhaps leading to the failure I'm seeing.

[tagyoureit]

AI assisted:
The instability you're seeing is almost certainly because ttyAMA0 is the Bluetooth UART on Pi 4. By default on Bookworm 64-bit, the PL011 UART (ttyAMA0) is assigned to Bluetooth, and the mini UART (ttyS0) is mapped to the GPIO pins. When you use ttyAMA0 directly, you're fighting the Bluetooth stack for it -- which is why it works initially then collapses.

You have two options:

Option 1 (recommended): Use a USB RS485 adapter. This completely avoids the onboard UART complications. It will show up as /dev/ttyUSB0. This is the most reliable path and what most Nixie users end up with.

Option 2: Disable Bluetooth to free up ttyAMA0 for GPIO. If you want to use the onboard UART with a TTL-to-RS485 converter on the GPIO pins, you need to reclaim ttyAMA0 from Bluetooth. On Bookworm the config file moved, so edit /boot/firmware/config.txt (not /boot/config.txt):

dtoverlay=disable-bt

Then run:

sudo systemctl disable hciuart
sudo reboot

After that, ttyAMA0 will be properly assigned to the GPIO pins and /dev/serial0 will point to it. Communication should be stable.

Do not use ttyS0 (the mini UART) for RS485 -- its clock is tied to the GPU core frequency and it's not reliable for serial comms at the baud rates we need.

[FlaMike]

Thank you! I will give it a whirl & let you know wassup.

…

On Thu, Apr 9, 2026, 9:14 PM tagyoureit ***@***.***> wrote: Pull the latest commit. That should be locked to the POOL circuit, not a generic circuit. If you pull, and it still shows generic, then you can stop the app and manually check/update the following: # data/poolConfig.json "circuits": [ { "id": 6, // 6 should be the pool circuit "name": "Pool", // You can change the name "showInFeatures": false, "freeze": false, "type": 12, // it should be type 12 "isActive": true, "eggTimer": 720, "master": 1 } — Reply to this email directly, view it on GitHub <#1168 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBA326XPCOWFBXVAFDL4VBKIFAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNJRGA3TIMI> . You are receiving this because you authored the thread.Message ID: <tagyoureit/nodejs-poolController/repo-discussions/1168/comments/16510741@ github.com>

[FlaMike]

I previously disabled bluetooth as well as wifi--I use ethernet for the Pi by editing /boot/firmware/config.txt.   I'm not using an RS485 adapter & just pointed poolControler (via dashPanel) to ttyAMA0.  I may not have disbled bluetooth when the system collapsed shortly after getting everything working, albeit briefly.  I'll have to double-check. I did not run sudo systemctl disable hciuart, however.  Do I need to do so if I'm not using anything on the GPIO pins?  From you note, I am guessing I do need to in order to get /dev/serial0 pointed correctly.

…

On 4/17/26 11:55 AM, tagyoureit wrote: AI assisted: The instability you're seeing is almost certainly because ttyAMA0 is the Bluetooth UART on Pi 4. By default on Bookworm 64-bit, the PL011 UART (ttyAMA0) is assigned to Bluetooth, and the mini UART (ttyS0) is mapped to the GPIO pins. When you use ttyAMA0 directly, you're fighting the Bluetooth stack for it -- which is why it works initially then collapses. You have two options: *Option 1 (recommended): Use a USB RS485 adapter.* This completely avoids the onboard UART complications. It will show up as /dev/ttyUSB0. This is the most reliable path and what most Nixie users end up with. *Option 2: Disable Bluetooth to free up ttyAMA0 for GPIO.* If you want to use the onboard UART with a TTL-to-RS485 converter on the GPIO pins, you need to reclaim ttyAMA0 from Bluetooth. On Bookworm the config file moved, so edit /boot/firmware/config.txt (not /boot/config.txt): |dtoverlay=disable-bt | Then run: |sudo systemctl disable hciuart sudo reboot | After that, ttyAMA0 will be properly assigned to the GPIO pins and /dev/serial0 will point to it. Communication should be stable. Do not use ttyS0 (the mini UART) for RS485 -- its clock is tied to the GPU core frequency and it's not reliable for serial comms at the baud rates we need. — Reply to this email directly, view it on GitHub <#1168?email_source=notifications&email_token=AJ3NIBAHT7TMBPHEGOUGEGT4WJOYJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGA2TIMRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16605426>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBFLNP4DF2P2QRL2K634WJOYJAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRQGU2DENQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[tagyoureit]

Recommendation is to spend $15 and get a rs485 USB. :)

[FlaMike]

I'm preparing to use an RS485 USB stick in the stack. The megabas I have is V4 that has DIP switches rather than jumpers.

While reviewing the megabas documentation, reproduced below, it looks like the RS485 DIP switches should be set to On, On, On so the Pi "drives" RS485 and the 120 ohm termination resistor is enabled.

In addition, it appears you need to tell the megabas to release control of the 485 bus by issuing the command "megabas [0] wcfgmb 0 0 0 0". I cloned Sequent's megabas repository and ran make to install the megabas software on the Pi. The version of megabas software installed is v1.2.9, the "up to date" version. megabas -list returns the board with Id: 0. Good so far.

I then ran megabas -h wcfgmb & got Option "wcfgmb" not found. The command list displayed after running the "megabas" command does not include wcfgmb. Am I doing something wrong here? Do I need to release the bus from the megabas so the Pi runs the show or will the REM or njsPC software do it automagically behind the scenes? If I need to tell the magabas to release the 485 bus, can you please tell me how to do so?

I connected the USB-RS485 stick (yellow to yellow, green to green), selected the port /dev/ttyUSB0 in the poolController UI & hit apply. poolController could send packets but none (or very, very few) were received.

Thank you for your help!!

[tagyoureit]

I would get in touch with Sequent if their software isn't properly controlling their cards. My recommendation is still to get a standalone RS485 usb stick.

[FlaMike]

Gotcha. May have one floating about from the "old" days when easy touch controller was still in the loop with nixie. Now where to find it... or just get a replacement

…

On Tue, Apr 21, 2026, 12:33 AM tagyoureit ***@***.***> wrote: Recommendation is to spend $15 and get a rs485 USB. :) — Reply to this email directly, view it on GitHub <#1168?email_source=notifications&email_token=AJ3NIBDVNMXDE6I2OAPOMID4W4B2VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGQ4DEMRVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16648225>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBBZMPWME2YW2XCB7PD4W4B2VAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRUHAZDENI> . You are receiving this because you authored the thread.Message ID: <tagyoureit/nodejs-poolController/repo-discussions/1168/comments/16648225@ github.com>

[chevyzr1]

FWIW, I had a very similar issue where something was highjacking GPIO14 after booting my pi therefor not allowing my pump to communicate. I drove myself crazy trying to figure it out as it would work fine with my usb-rs485 adapter but not with my sequent relay hat. I discovered that not only was the "pi fan" setting enabled on the pi, but there was also an old GPIO assignment in REM that was highjacking GPIO 14. I disabled both and my pump immediately started communicating. The sad part is I lost an entire Saturday pulling my hair out!

[FlaMike]

Thank you for sharing your experience! These gotchas certainly are frustrating. I did locate my old usb-rs485 adapter. Not sure if I can squeeze it into the waterproof case due to the din rail location 🤞 Did you need to disable the hat's rs485 or was removing the wires to the connector on the hat sufficient? Hoping I don't lose too much hair, it's pretty much a desert already on top.

…

On Tue, Apr 21, 2026, 7:28 AM chevyzr1 ***@***.***> wrote: FWIW, I had a very similar issue where something was highjacking GPIO14 after booting my pi therefor not allowing my pump to communicate. I drove myself crazy trying to figure it out as it would work fine with my usb-rs485 adapter but not with my sequent relay hat. I discovered that not only was the "pi fan" setting enabled on the pi, but there was also an old GPIO assignment in REM that was highjacking GPIO 14. I disabled both and my pump immediately started communicating. The sad part is I lost an entire Saturday pulling my hair out! — Reply to this email directly, view it on GitHub <#1168?email_source=notifications&email_token=AJ3NIBBA5ZH4QUC4Q5UWRV34W5SOFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGU2DOMJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16654717>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBD6ERB2B4XY7GRRB634W5SOFAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRVGQ3TCNY> . You are receiving this because you authored the thread.Message ID: <tagyoureit/nodejs-poolController/repo-discussions/1168/comments/16654717@ github.com>

[chevyzr1]

Haha, I hear you on the desert. Unfortunately for me I received my father's hairline(or lack thereof) at age 35.

On the hat, I enabled passthrough mode in REM, deleted the TTYUSB that previously held the RS485 connection from my pentair pump, and finally after many hours of troubleshooting disabled the PI fan on GPIO14 as well as the left over configurations in REM that utilized GPIO 14 & 15 (pins #8 & 10) Attached a picture of where I disabled the fan in pi config. Very satisfying once I finally got this working without needed to provide an extra module. I'll attach some pics of my setup as well for some inspiration (don't judge as I'm not yet finished with the wire management aspect) lol.

I'm currently in the process of ordering a pentair IC40 as well as the Atlas Scientific sensors for all of the fun monitoring.

Overall, I'm extremely happy with the setup. It's so refreshing to me projects like this exist to satisfy my crave for learning and problem solving.

[chevyzr1]

One quick note, if you're using a USB-RS485 adapter, the configuration above shouldn't matter in your case. This example is specific to if you're using a hat on the pi that utilizes GPIO #14&15 for TX&RX. In your case, after connecting the adapter via USB all you should need to do is switch your RS485 COMM to *TTYUSB or something to that effect. Once the adapter is plugged in it should display as an option in your dash panel comms config. Good luck!

[FlaMike]

Thank you for the ongoing inspiration, pix, et al. My setup does not use the Pi's GPIO pins directly for anything--though I'm sure the HATs talk through them minimally. And they feed power between the HATs.

I'm running a case fan that's controlled by the Pi stack's relay board. I feed the Pi's CPU temperature to contol the relay. It turns on the case fan when the CPU is 120 F or higher.

Good luck with the chlorinator & chem probes. ORP doesn't work well in my setup & it didn't work in our previous house either. I just set it by % run time & check the Cl level periodically. If you use CYA to give the Cl longevity, once your setup is dialed in, it should be pretty sweet. The pH probe & acid feeder make life much, much easier. troublefreepool.com has tons of helpful information on pool equipment, water chemistry, & maintenance.

I, too, enjoy the challenges although I'm drinking through a firehose far too frequently. The end results are sweet as sugar, though.

On the hair thing, most of mine was history by the time I reached 25. As I'm now on the cusp on 69, my biggest concern is sunburn :-( My wife knew what she was getting into, as far as hair is concerned, when she met me.

[FlaMike]

Cool!  Thanks!!!!!

…

On 4/22/26 2:05 PM, chevyzr1 wrote: One quick note, if you're using a USB-RS485 adapter, the configuration above shouldn't matter in your case. This example is specific to if you're using a hat on the pi that utilizes GPIO #14 <#14>&15 for TX&RX. In your case, after connecting the adapter via USB all you should need to do is switch your RS485 COMM to *TTYUSB or something to that effect. Once the adapter is plugged in it should display as an option in your dash panel comms config. Good luck! — Reply to this email directly, view it on GitHub <#1168?email_source=notifications&email_token=AJ3NIBGWHH52DSLAGOUFX2L4XEJYVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWG42DCOJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16674198>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBGRA2RFUJWVQ4AMYW34XEJYVAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRXGQYTSOA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[FlaMike]

I will contact Sequent--good suggestion! I  did try using the RS485 usb stick that I used with the Easytouch before building Nixie.  It was able to send packets from poolController but did not receive anything from REM.  As far as I could tell, both  were configured correctly & I selected USB0 as the port in pool controller .  The A & B lines on the usb stick were connected as the manufacturer stated in its data sheet.  No idea why it was messed up.  I'm open to suggestions, if  you have any to share. Thanks!

…

On 5/3/26 11:51 PM, tagyoureit wrote: I would get in touch with Sequent if their software isn't properly controlling their cards. My recommendation is still to get a standalone RS485 usb stick. — Reply to this email directly, view it on GitHub <#1168 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBCB5I7Y65D6WSN4XOL4ZAOVXAVCNFSM6AAAAACXOQGU7WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOBQGA4DIMA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[tagyoureit]

It was able to send packets from poolController but did not receive anything from REM.

REM never communicates over RS485. njsPC and dP use API's to talk to each other. The USB stick shouldn't even be in this equation. I'm a bit lost on your setup at this point, tbh.

[FlaMike]

Please forgive me if I was not clear or my understanding is far off base. Both are likely. If REM is not in the 485 loop, I assume it's the pump and salt cell with which the pool controller is communicating. The pool has a Pentair Intelliflo VSF pump and an Intellichlor salt cell.

As in years past, when I run the system using the RS485 connection to the megabas board, use "485 Pass Thru" on the megabas, and set the "Comms" page in the pool controller, nominally to /dev/ttyS0, there is a fair amount of traffic displayed on the Comms page as in the screenshot below. (The screenshot shows the system using /dev/ttyAMA0 because /dev/ttyS0 isn't working correctly on this installation-- which is why you suggested I switch to the USB stick for RS485 communication.) The pump & salt cell function correctly with the settings shown in the screenshot.

When I installed the RS485 USB stick on the Pi, moved the megabas' RS485 wires to the USB stick, and selected /dev/USB0 for the Comms port, the traffic was unidirectional and neither the pump nor the salt cell functioned. If I recall correctly, the same may have been true if I selected /dev/ttyS0, but I am not sure because it's been a couple of weeks since I tried the USB stick. I do know I tried both USB and S0 without succces. The megabas still had 485 Pass Thru selected, but I assume it was moot since the only way it could receive or propogate RS485 would be through GPIO pins.(?) I did not change any of the RS485 DIP switches on the megabas from their positions when using the megabas' RS485 connection to the Pentair equipment. Could that be the problem? I believe they're set to OFF, OFF, ON.

Because there was limited RS485 communication at the Comms page and the associated Pentair equipment did not function correctly, I returned to using the megabas' RS485 connection and /dev/ttyAMA0.

I hope this clarifies what's going on. If it's not, please let me know what's unclear & I'll try again. I can also head to the pad change wiring or DIP switches to fix things, of course. I truly appreciate your patience and help!

[tagyoureit]

When I installed the RS485 USB stick on the Pi, moved the megabas' RS485 wires to the USB stick, and selected /dev/USB0 for the Comms port, the traffic was unidirectional and neither the pump nor the salt cell functioned.

Did you try to switch the D+/D- (or red/yellow or A/B) wires? That's the most likely cause if you aren't receiving traffic.

But it sounds like it's working, no? You might want to also try disabling the megabas port so it doesn't conflict.

Are you having other problems or is it just the rs485 comms you are trying to resolve?

[FlaMike]

I'll try swapping the A & B wires & see if that does the trick. To disable the megabas port, should I change the DIP switches to On, On, Off from Off, Off, On per Sequent's instructions? Is there anything I need to do from REM's UI?

I tried using the cli command to tell the megabas processor to release the bus: ~$ megabas [0] wcfgmb 0 0 0 0 but got an error message even though the board is detected.

michael@nixie:~ $ megabas -list
1 board(s) detected
Id: 0

My only other issue at the moment is the SmartFan as we've talked about in a different thread. Much lower priority at the moment. And the controller is working fine using /dev/ttyAMA0 as shown above (using the megabas' 485 port, not the USB-RS485 stick).

Thanks for your help!