Repository navigation
Replies: 9 comments 9 replies
|
first: I don't think 97/3 CRC split is anything to worry about, that's basically normal and you're right that resync after collisions tends to overstate that. Infinitude has a slightly more sophisticated sync algorithm that moves a sliding window but I went with a simpler mechanism in InfinitESP. The one-shot trigger circuit in the 6ch box does suffer when transmitting long frames however so you might get slightly better numbers by changing to the built-in rmtx component if you're not already using it. thanks for the report.json debug output. You're the first person with a 0x3E device so that's definitely new information and the first person with a refrigerant leak/dissipation board too it looks like. We don't have great data yet on the smart zone sensors, so I'd love to get more information/logs from those at some point (@feisley has them as well if I recall) but to your questions... In your case with a new thermostat and firmware version, I would probably just use InfinitESP unless you want to downgrade the firmware to experiment with Infinitude. Carrier has deprecated their older REST/Atom webservice so there's no traffic for Infinitude to intercept in newer versions of their thermostat firmware. If it turns out that IDUs at address 0x3E contain the same data shape as 0x4 devices, then I can change InfinitESPs default expectations, but until then you have a few options.
sensor:
- platform: infinitesp
type: raw_register
name: "Blower RPM"
device_address: 0x3E
register: 0x0306
offset: 1 # RPM u16 BE at [1..2]
datatype: uint16_be
unit_of_measurement: "RPM"
- platform: infinitesp
type: raw_register
name: "Airflow CFM"
device_address: 0x3E
register: 0x0316
offset: 4 # CFM BE16 at [4..5]
datatype: uint16_be
device_class: volume_flow_rate
unit_of_measurement: "ft³/min"
|
|
InfinitESP 479c7e38 adds |
|
Thanks much for that quick code edit. I attempted to do what you described above in the infinitesp.yaml previously. It compiled and ran fine but it wasn't making it to HA so rather than mess around with that too much I just hacked the .cpp and .h files in a few places and got the rpm and cfm. Your fix is much better, though. In addition to the RPM and CFM it's picking up other stats from the IDU. I don't see the equivalents of those in the logs for the ODU. I'll try to figure out why. The main items I want to see on HA are all coming across, which is great. I'm also able to adjust zone setpoints and holds through HA. I'm not seeing a way to adjust schedules through HA at the moment, which I think is fine. In practice I adjust those very rarely and I can use the app for that. This is all very awesome and well documented, so thankyou much and thanks to everyone that invested the time to reverse engineer the protocols. Are there additional log details you'd like to see? You mentioned the smart sensors. |
|
Nice. Glad to see that change worked at least a bit. the missing ODU equivalents can be expected given your new hardware seems to be slightly different than some of that we've modeled so far. In your capture the thermostat never polls 0310/0311 (cycle counters and runtime hours) or 060e (stage byte) on the ODU, and the ODU never serves them, so a working conclusion is that those entities just have no data source on this generation. The IDU counters you're seeing come from your furnace, which does serve them. This generation seems to poll a different diagnostic set instead (0317, 031b, 0322/0323, 0702-0716), but those haven't yet been decoded. What we might expect to already be working on the ODU side: outdoor temp, line voltage (your capture decodes to 236 V with the current layout, which looks right), compressor target/actual RPM, requested CFM, expansion valve %, the 061f float set, commanded stage, and the ODU manufacture date. If any of those are absent too (not just the counters), post a fresh REPORT? and we can keep iterating. one interesting observation: your 0302 is 56 bytes vs 24 on the older 24VNA9 family. The first few temperature slots decode sanely, but the last two labels (indoor ambient, discharge) look shifted on your unit, so treat those two with suspicion until we can pin them down. Two captures would help a lot, if you're willing:
If your Infinity control has a service screen showing ODU suction/discharge pressures or temps, a note of what it displays alongside capture #1 would also help us confirm which 0302 slot is which. |
|
I feel a little dumb here, but what is the best way to capture raw traffic frames? I modified my yaml previously to allow raw bus monitoring on port 4242, which comes across as the raw data and I can pipe it to xxd and redirect to a file to make it human readable. But it seems like we're limited to either having the ASCII interface available (defaulting to port 23) or the raw data available (defaulting to port 4242). It's easy enough to change up the yaml and recompile if necessary, but I'm wondering if I'm not missing a simpler way. Or if the post-xxd format is the preferred format for sending raw logs. |
|
not dumb at all, and I could probably do a better job of documenting esphome-uart-link but it supports so many permutations that demonstrating them all would be even more confusing. In short, whatever mechanism works for you is fine, but if you have an Infinitude instance running, then using its websocket stream makes for a convenient format. you can configure your infinitesp device like so: then either pipe nc output to a file, or in the case of Infinitude, point Infinitude to your uart_server and use wscat to get the fully parsed frames. when I get to a more proper keyboard I'll see if I can work up an example. |
|
here's a commented distillation of my which uses the same waveshare board which should hopefully work for you. # InfinitESP + Infinitude capture setup.
#
# Topology: uart_bridge owns the RS485 transceiver and fans bytes to both
# InfinitESP and a read-only TCP tap. Infinitude connects to the tap, parses
# the frames, and re-publishes them as JSON on its own websocket.
#
# RS485 -> uart_bridge -> InfinitESP (SAM emulation at 0x92)
# -> TCP tap (read-only, port 4242) -> Infinitude
#
# The SAM ASCII command interface (port 23) runs independent of and alongside the tap:
# nc infinitesp.local 23
# REPORT? (diagnostic snapshot as JSON)
#
# Infinitude side: point it at the tap.
# infinitude.json: { "serial_socket": "infinitesp.local:4242" }
# (docker: -e SERIAL_SOCKET=infinitesp.local:4242)
# Leave Infinitude's EMULATE_SAM off: the tap is read-only, so anything
# Infinitude tries to transmit never reaches the bus.
#
# Dump Infinitude's parsed frames to a file:
# npm install -g wscat
# wscat -c ws://<infinitude-host>:3000/serial | tee frames.jsonl
# Each line is one frame: addresses, register, payload fields, timestamp.
substitutions:
name: infinitesp-capture
friendly_name: InfinitESP Capture
esphome:
name: ${name}
friendly_name: ${friendly_name}
name_add_mac_suffix: false
esp32:
board: esp32-s3-devkitc-1
framework:
type: esp-idf
version: recommended
logger:
baud_rate: 0
api:
ota:
- platform: esphome
wifi:
networks:
- ssid: !secret ssid
password: !secret password
ap: {}
captive_portal:
external_components:
- source:
type: git
url: https://github.com/nebulous/esphome-uart-link
- source:
type: local
path: ../components
# Carrier ABCD bus: 38400 baud 8N1, Waveshare ESP32-S3-Relay-6CH pinout.
# uart_rmtx transmits through the RMT peripheral with a sub-bit line code:
# the board's SP485EEN auto-direction one-shot drops long frames when
# driven by the plain hardware UART. A generic transceiver (DE/RE pin or
# MAX13487E-class on-chip auto-direction) can use a plain uart: block
# instead; see the InfinitESP README.
uart_rmtx:
id: bus_uart
tx_pin: GPIO17
rx_pin: GPIO18
baud_rate: 38400
data_bits: 8
parity: NONE
stop_bits: 1
rx_buffer_size: 4096
sub_bits: 3
rmt_mem_symbols: 64
# Read-only TCP tap. fanout: every client sees the same stream.
uart_tcp_server:
- id: raw_bus_tap
port: 4242
max_clients: 4
client_mode: fanout
idle_timeout: 300s
# SAM ASCII command interface, independent of the bridge below.
- id: ascii_uart
port: 23
max_clients: 4
client_mode: fanout
idle_timeout: 300s
sam_ascii:
id: sam_ascii_server
infinitesp_id: infinitesp_hub
uart_id: ascii_uart
# The bridge owns the hardware UART. flow: from_bridge makes the tap
# monitor-only: bus bytes reach TCP clients, TCP writes never reach the bus.
uart_bridge:
- id: bus_bridge
uarts:
- bus_uart
- uart: raw_bus_tap
flow: from_bridge
infinitesp:
id: infinitesp_hub
# Read from the bridge, not bus_uart. Set sam_address 0 to run passive
# (no bus writes) while the tap keeps streaming.
uart_id: bus_bridge
sam_address: 0x92
zone_controller_address: 0x60
climate:
- platform: infinitesp
infinitesp_id: infinitesp_hub
name: "Zone 1 Climate"
zone: 1 |
|
Thanks, I'm not very bright it seems. I didn't realize that under the uart_tcp_server: section I could include multiple id's. I had duplicated the uart_tcp_server: line for each section and that wouldn't compile because of the duplicate so I just thought my choice was one or the other. I'm attaching a report while the AC is running. Screen shows suction pressure 108 PSI and discharge pressure 269 psi, suction temp 54 F and discharge temp 145 F around when the report was made. Not exactly the same point in time but very close. I'm also attaching a binary log of the raw data from 4242. I didn't try doing it through infinitude because I can't keep it running long on my RPi (usually less than a minute before it stops). |
|
Thanks for the logs, those were parsable. 👍 If suction pressure was ~108psi then this sensor is a guess for where that data might be. sensor:
- platform: infinitesp
infinitesp_id: infinitesp_hub
type: raw_register
name: "ODU Suction Pressure"
device_address: 0x57
register: 0x0302
offset: 18 # measurement slot 4 (2 + 4*4)
datatype: int16_be
scale: 0.01 # raw/100 tracked your screen's 108 PSI
unit_of_measurement: "psi"
device_class: pressure
value_min: 0
value_max: 500 |
|
I assume I should be reading the logs from here: If so, it looks incorrect. Whatever it is that's in that position dropped sharply when the AC started running. When I turned off the AC it climbed back up a bit, then dropped and stabilized at a lower level. |
|
I don't even know enough to be dangerous when it comes to what proper transducer values for an AC should be, but poking around the internet doesn't convince me that the above is necessarily wrong if it's suction pressure it would drop when the ac was running then slowly revert to ~200psi for R410A when not running at ambient temps in the 60s/70s F maybe after it's run for a day or so we can see this graph charted along with some of your others to see if they make sense in concert or if the label mapping needs to be adjusted. |
|
Sorry, I forgot to mention that I was comparing the pattern of what I was seeing on the system control with what I was seeing in the infinitesp data as reported in HA. While the system was off "suction pressures" were reasonably off by about 5 PSI. That remained true for a minute or so when the AC kicked on, but then the HA graph kept dropping with a steady slope while the suction pressure reading on the controller stabilized. That difference in directional pattern continued a few minutes, so I stopped watching. With the system having been off for the last hour or so the controller is showing suction pressure above where it started (210 PSI now) and the "0302 offset 18" reading is still well below where it was this AM (145 psi now, 190 this AM). There was some loose directional correlation, but the difference is not a matter of vertical offset or scaling. I'm going to have to bring a laptop and sit in front of my controller and type in values from the screen in 10 second intervals or something and then look for where the patterns align. What is correct at the moment (e.g., HA matches controller): ODU Air temp, coil temp, suction temp, discharge temp, AC voltage. |
|
it is wrong, your suction pressure is in register 303. with HP = 1 and Fan = 4 in the first nibble yours are for devices 3E, 60, 57 respectively. you should be able to decode each if you record the data stream, take pictures of the temperatures displayed in the service displays on your control screens and then compare the two PS: records 0310 and 0311 have a similar scheme but it is 1 byte id and 3 bytes value. mike small changes in bold |
|
Thanks, that's very informative! I suppose that mechanism of "parameter, value" makes a lot of sense given that the equipment goes through software revisions and this gives Carrier the ability to add or move parameters somewhat flexibly without breaking things. |
|
nice, that's a better mapping. And not the first time dragonflight has swooped in with a correction probably already in their notes for years 😄 |
|
Sorry for the swooping, as I have mentioned before I've been sick for 6
years now, with no respite in sight. I got my system Dec 2020 and helped by
strong steroids (prescription), I managed to decode the protocol in
Jan/Feb (mostly) before I found all the work online, but had to stop the
steroids. I got really bad for a few years (couldn't sit up long enough to
finish a cup of coffee, but the last year has been better, I will open a
discussion and upload my decode files (C and CPP) for the registers that I
have figured out (or guessed at) and they may be of use.
I did decode a lot of the thermostat registers as well, but they're on
paper that I don't seem to be able to put my hands on right now.
mike
…On Wed, Sep 9, 2026 at 9:20 AM nebulous ***@***.***> wrote:
nice, that's a better mapping. And not the first time dragonflight has
swooped in with a correction probably already in their notes for years 😄
this type/data list pattern is used in ZC as well, so I'll see if I can
make more general use of it in an update.
—
Reply to this email directly, view it on GitHub
<#232?email_source=notifications&email_token=AAEAXQPNHGCLJRHYEK7VGHL5OFKLDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGY4TANJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18369055>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEAXQJQPEXKX6HIM52UELD5OFKLDAVCNFSNUABGKJSXA33TNF2G64TZHM4DAMJWGM2TKO2ENFZWG5LTONUW63R3GEYDONRQGM4DPILWAI>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AAEAXQM74D4NJCNHL4IOD5L5OFKLDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGY4TANJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ>
and Android
<https://github.com/notifications/mobile/android/AAEAXQOFX6FVP4TNNWN64F35OFKLDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGY4TANJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>.
Download it today!
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Sorry to hear about the health issues. I hope you find something that gives you sustained relief. Much appreciation for the work and insights on the protocol, though. Very helpful! |
|
seconded! to be clear the "swooping" is a good thing! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
My new Infinity system is up and running with:
I have InfinitESP running on the Waveshare 6 channel ESP, and Infinitude on a RPi 4 being fed over wifi by the raw bus monitor uart bridge in the ESP. I have InfinitESP running as a SAM on 0x92.
InfinitESP picks up and relays most of the core system things to Home Assistant. Step one is to get it so I can see everything I want to see in HA, step two would be controlling zones through HA.
The main oddity I've noticed so far relative to the current codebase is my IDU seems to be communicating as 3E. InfinitESP is expecting it at 40 (or at least 4x). It was simple enough to adjust my local copy of the InfinitESP code to have it look for the air handler blower RPM and CFM on 3x rather than 4x and that seems to work and get communicated to HA.
A separate issues that I am getting a fair number of CRC errors and haven't tried to diagnose that. InfinitESP reports generally around 97% of messages OK, with around 3% CRC errors. The error count is significantly overstated, though, as what appears to be happening is it's getting out of sync with the message starts and ends after the first CRC error. The initial CRC error will produce anywhere from 4 to 20 messages as having CRC errors because it seems out of sync with message starts.
My first question right now is I'm a little confused about is whether I should be focusing my efforts on InfinitESP or Infinitude in trying to get things working. The current version of Infinitude seems to have the capability to emulate a SAM, work over RS485, and integrate into HA (which is where I want to be in the end). Mine is a long way from there at the moment, as it stops receiving data after about a minute. I can "docker restart infinitude" and make it go for another minute. I saw in another post that I could probably connect an RS485 directly to the RPi to address this, which I'm happy to try one of these days.
My second question is what to do with the logs or any of my efforts to incorporate the edits I make into the codebase. I'm attaching a REPORT? dump from InfinitESP here, which shows the communications from 3E that I believe to be from the IDU.
report.json
All reactions