issues adding a split system

[BKFCAW]

I have two systems: a combined Waterfurnace System 7 and a split System 5. Running mosquitto and the aurora bridge with the USB/ethernet wiring works fine for the System 7, as does access with MacOS MQTT Explorer. For the System 5, I cloned the Raspberry Pi card and set up a new connection. It "sort of worked," but I wondered whether it was really polling the split system. So I deleted the software and reinstalled. Now I have the following issues with the split system:

• I cannot connect to it with MacOS MQTT Explorer - it just says "disconnected"
• Nevertheless, my Telegraf/InfluxDB/grafana stack seems to be recording data, BUT
• When I poll the blower fan "running" element, it alway says "false," even if the fan is running.

[ccutrer]

All topics are sent with the retained flag, so even if it's not running you'll see the last message it sent. Be sure to check the homie/aurora-*/$state topic to see if it's currently communicating with your MQTT server.

[BKFCAW]

Thanks for the input. I discovered that the second Raspberry Pi is running Mosquitto v2, which meant I had to change a config file to gain access to the MQTT server. Now that I’ve done that, both MQTT Explorer and my Telegraf/InfluxDB/Grafana stack run without error messages.

Having said this, I’m not getting any real time-dependent information from the second system. If I forcibly turn the heat on at the thermostat, the compressor shows no activity, the blower running variable is ‘false’, and the entering/leaving water temperature is essentially the local room temperature where the compressor is located. The update flash in MQTT Explorer only shows for the $SYS component and not aurora. The $state topic for both systems says ‘ready’. Is there anything obvious I can look for?

On Apr 20, 2023, at 1:56 PM, Cody Cutrer @.***> wrote:

All topics are sent with the retained flag, so even if it's not running you'll see the last message it sent. Be sure to check the homie/aurora-*/$state topic to see if it's currently communicating with your MQTT server.

— Reply to this email directly, view it on GitHub https://github.com/ccutrer/waterfurnace_aurora/issues/38#issuecomment-1516728695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYOQFI2TJOFYZ3FFUMMEGHDXCF2GLANCNFSM6AAAAAAXFZBLQU. You are receiving this because you authored the thread.

[ccutrer]

Hmm... that does seem like it's communicating. Maybe try stopping the mqtt bridge, and manually using aurora_fetch as described in the readme to synchronously fetch some data. Then make it change state at the thermostat, and then fetch again. Registers 30 and 31 would likely be interesting (outputs and status).

[BKFCAW]

Thanks for your comments.

After several more tests, it looks like the problem is the RS485 adapter. I already had one adapter that you cited in the README file, and bought a second (I have two systems) with a different form factor. The second adapter has a CP2102 chipset. I had posted some of the symptoms to issue #23. The module cp210x is loaded (it apparently came with RPi bullseye), I can see /dev/ttyUSB0, but when I try running aurora_mqtt_bridge manually, I get a timeout error like the issue #23 poster also got. And MQTT Explorer shows $state as ‘lost’. When I use the first adapter, the system works on either of my heating systems.

Is there any way to get this to work with a CP2102 chipset? Part of the reason I bought it is that its form factor doesn’t interfere with other USB devices plugged into the Raspberry Pi.

On Apr 24, 2023, at 2:00 PM, Cody Cutrer @.***> wrote:

Hmm... that does seem like it's communicating. Maybe try stopping the mqtt bridge, and manually using aurora_fetch as described in the readme to synchronously fetch some data. Then make it change state at the thermostat, and then fetch again. Registers 1103 and 1104 would likely be interesting (AXB inputs and outputs, respectively).

— Reply to this email directly, view it on GitHub https://github.com/ccutrer/waterfurnace_aurora/issues/38#issuecomment-1520599690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYOQFI3HKTAXEQV4KL3Z5WLXC25SRANCNFSM6AAAAAAXFZBLQU. You are receiving this because you authored the thread.

[ccutrer]

The serial chipset shouldn't matter, but if it uses a MAX485 transceiver, it won't work, and no there's no way that I'm willing to fix it.

[BKFCAW]

I don’t know how to determine whether my adapter uses MAX485, but it looks like this is a feature that Amazon promotes on some devices (meaning that the lack of any mention may mean that it’s not there). There’s also a rather massive Silicon Labs package for configuring the firmware of the CP2102N, but from your comment, I’m not sure it’s worth learning how to use it.

On Apr 24, 2023, at 3:35 PM, Cody Cutrer @.***> wrote:

The serial chipset shouldn't matter, but if it uses a MAX485 transceiver, it won't work, and no there's no way that I'm willing to fix it.

— Reply to this email directly, view it on GitHub https://github.com/ccutrer/waterfurnace_aurora/issues/38#issuecomment-1520720543, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYOQFI54DXGOX7HIA2JTTTLXC3IYLANCNFSM6AAAAAAXFZBLQU. You are receiving this because you authored the thread.

[BKFCAW]

Another note: now I think I see that the person posting issue #23 may have the same problem as me. To quote:

"I do have a different model USB to RS-485 Adapter than you show You list the DSD TECH SH-U11 USB to RS485 RS422 and I have the DSD TECH SH-U10 USB to RS485 Converter. Could that be the issue or do I have something else going on?"

It turns out that DSD TECH SH-U10 has a CP2102 chipset rather than FTDI, though it is the same vendor as the one you originally cite.

[ccutrer]

Interesting. Makes me wonder if somehow the CP2102 isn't accepting the serial parameters, or just flat out doesn't support the particular parameters WaterFurnace uses (19,200 baud, even parity). I know I've had issues on a different project that is also RS485 where ESP devices couldn't handle 4,800 odd parity.

[BKFCAW]

From the documentation for CP210x at Silicon Labs:

2.3.1 Baud Rate The baud rate property is set to 57600 bps, but can be set to any of the baud rates supported by the CP210x. (See the current data sheet for the list of supported baud rates for the CP210x.) 2.3.2 Parity The parity is set to NOPARITY, however it can also be set to ODDPARITY, EVENPARITY, SPACEPARITY, and MARKPARITY if supported by the CP210x. (See the current data sheet for the list of supported parities for the CP210x.)

I'm out of my depth at this level of hardware, not sure how to set parity - or is that done in your code?

[ccutrer]

My code requests the operating system set the serial parameters (including baud and parity). But it's up to the driver to properly forward that request to the hardware.

[BKFCAW]

I just ran the following code:

#include <stdio.h>
#include <unistd.h>
#include <termios.h>
#include <fcntl.h>

int main()
{

    struct termios RSopt;
    char str[3] = { 0x10, 0x05, 0x0};
    int fd;
    fd = open( "/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY );    

    tcgetattr( fd, &RSopt);
    int TT = RSopt.c_cflag;
    if ((TT & PARENB) != 0)
      printf("parity EVEN\n");
    else
      printf("parity not EVEN\n");
    int speedtest = cfsetspeed ( &RSopt, (speed_t)B19200);
    printf("speedtest = %d\n", speedtest);

    close( fd );

    return 0;
}

It has output:

parity EVEN speedtest = 0

I don't know if this is useful. Maybe there are other tests I can do.

[rabarar]

not to be overly pedantic, but since you're using this to test, would be a good idea to catch the return from tcgetattr( ) and make sure you're not getting back EBADF, EINTR, EINVAL or ENOTTY... for sanity sake ...

    if (tcgetattr(fd, &RSopt) < 0) {
        ...

A complete mod looks like:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <termios.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

int main()
{

    struct termios RSopt;
    char str[3] = { 0x10, 0x05, 0x0};
    int fd;
    fd = open( "/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY );    

    if (tcgetattr( fd, &RSopt) < 0) {
                fprintf(stderr, "tcgetattr failed: %s\n", strerror(errno));
                exit(1);
        }
    int TT = RSopt.c_cflag;
    if ((TT & PARENB) != 0)
      printf("parity EVEN\n");
    else
      printf("parity not EVEN\n");
    int speedtest = cfsetspeed ( &RSopt, (speed_t)B19200);
    printf("speedtest = %d\n", speedtest);

    close( fd );

    return 0;
}

[BKFCAW]

Thanks very much. I just tried your expanded code, and still get

parity EVEN speedtest = 0

[rabarar]

Yeah - you’re good - just this way you get notified (in the unlikely case) if the call fails to get the attributes!

On Apr 25, 2023, at 5:17 PM, BKFCAW @.***> wrote:

Thanks very much. I just tried your expanded code, and still get

parity EVEN speedtest = 0

— Reply to this email directly, view it on GitHub https://github.com/ccutrer/waterfurnace_aurora/issues/38#issuecomment-1522429696, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB2J6EUBSPAMHDLAUJZC23XDA5P3ANCNFSM6AAAAAAXFZBLQU. You are receiving this because you commented.

[BKFCAW]

Well, OK, that possibly eliminates parity and baud rate as the reason why the CP2102N -based adapter times out on aurora_mqtt_bridge with no data transfer.

[BKFCAW]

In the absence of anyone stating that they have gotten a CP2102N adapter to work in this application, I will return what I have to Amazon and order an adapter with an FTDI chipset. Perhaps the README should also recommend this.

[BKFCAW]

To close the loop on this, I bought a DTech adapter with FTDI (the previous DTech I had came with CP2102N), and it worked right out of the box.