-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issues adding a split system #38
Comments
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. |
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 <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYOQFI2TJOFYZ3FFUMMEGHDXCF2GLANCNFSM6AAAAAAXFZBLQU>.
You are receiving this because you authored the thread.
|
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). |
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 <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYOQFI3HKTAXEQV4KL3Z5WLXC25SRANCNFSM6AAAAAAXFZBLQU>.
You are receiving this because you authored the thread.
|
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. |
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 <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYOQFI54DXGOX7HIA2JTTTLXC3IYLANCNFSM6AAAAAAXFZBLQU>.
You are receiving this because you authored the thread.
|
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 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. |
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. |
From the documentation for CP210x at Silicon Labs: 2.3.1 Baud Rate I'm out of my depth at this level of hardware, not sure how to set parity - or is that done in your code? |
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. |
I just ran the following code:
It has output: parity EVEN I don't know if this is useful. Maybe there are other tests I can do. |
not to be overly pedantic, but since you're using this to test, would be a good idea to catch the return from
A complete mod looks like:
|
Thanks very much. I just tried your expanded code, and still get parity EVEN |
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 <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB2J6EUBSPAMHDLAUJZC23XDA5P3ANCNFSM6AAAAAAXFZBLQU>.
You are receiving this because you commented.
|
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. |
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. |
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. |
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:
The text was updated successfully, but these errors were encountered: