Please Clarify...

[brettonw]

This looks like an amazing project, as I keep wondering if I need to replace my Inifinity Thermostats with basic smart thermostats. I'm a bit confused, though. Is this a replacement for the thermostat, or a device you expect to put somewhere to act as a thermostat proxy? Or is it something else entirely?

I'd love a wired PoE box attached to my furnace units that understood how to turn on two stage inifinity systems, but wasn't at all locked to the stupid thermostats. If it just exposed a multi-stage on-off mechanism, the HA generic climate control could probably interface a python script to decide how to turn on the system.

Maybe I'm just fantasizing...

[nebulous]

So far it's not much of anything - a nascent idea that I've been wanting to do for a long time. Unfortunately it is not going to be able to replace your thermostat, but ideally it will be able to control your thermostat directly via the rs485 bus rather than through Carrier's API or even Infinitude's inpersonation of Carrier's API. I've decided to split it into two parts:

1. A firmware targeting ESP32 which will expose a Home Assistant climate device which controls the thermostat via an rs485 adaptor. I've recently started using this rs485 to ethernet adaptor as the interface in order to keep the serial hardware completely isolated and to allow Infinitude access in the mean time, but have used several different usb adaptors and even an esp8266 board in the past.
2. A firmware specifically for the esp32-box-lite which will present a thermostat interface for a home assistant climate device. Originally I had wanted both points one and two to run on the same device, but that would end up being awkward for a few reasons, not least of which in my case it would mean I'd have to run thermostat wire to another location in my house or have a thermostat buried in the basement utility room where it's useless :)

[brettonw]

So (1) is intended to replace something like an infinitive server?

Why do you need two HA Climate interfaces - I'm not following why this is two boxes for you?

Does the ABCD bus control the thermostat, or the furnace system?

[jftaylorMn]

@nebulous - Maybe this is a refinement of the issue I posted for this project. It seems like it would be ideal to develop a library that manages the communications with the system via rs485 bus, regardless of implementation (thermostat, HA, or?) and specific hardware interface (TTY or ethernet). From a REST API perspective, it would expose GET and PUT functionality. I can't think of any POST or DELETE use cases. As enhancements are made or bug fixes released, a new library version would be available for developers to pull into PlatformIO, Arduino IDE, or?? I'm not sure how much more work is involved beyond creating header and cpp files. I guess training examples would be good.

Taking the thought a bit further... If your goal is to have an esp32 (an 8266 might actually be sufficient) at the furnace and another with a display, I think it would be pretty simple to wrap the functionality of the cpp library into a handful of API endpoints (see https://microcontrollerslab.com/esp32-rest-api-web-server-get-post-postman/) then use regular API calls between the esp32 based thermostat and the "server". Similarly, ESPHome could wrap up the library functionality for interaction with HA. if that's a direction someone wants to take it. Maybe someone would want to use an ESP-NOW approach instead? In my case, I could use the same library to report data via mqtt over cell modem. Only the common library needs to be updated if/when the new capability or bug fixes are ready.

I've been looking at the cardump.c code in the infinitude repo, but don't have a good grasp yet on how to map frames to values returned in the status API call, nor do I have a working example to poke at. Since the code hasn't been touched in a lot of years, maybe the secret decoder ring is elsewhere for the infinitude web page? I can provide some help converting the raw data to JSON, if that would be helpful.

[nebulous]

So (1) is intended to replace something like an infinitive server?

basically. It would be akin to a self-contained Infinitive server which works with touch instead of legacy thermostats and automatically appears to Home Assistant as a climate device.

Why do you need two HA Climate interfaces - I'm not following why this is two boxes for you?

Separation of concerns/decoupling. point 1 is what I really want, but I have this fun little touchscreen device which would function well as a physical thermostat interface. Said interface could control any HA climate device, making it more generally useful to others, and many(most?) people, @jftaylorMn aren't going to need or care about the box. So on fantasy island where all of this is complete, I could pop this esp32-lite box on my wall upstairs to be another interface/controler for my Infinity system

Does the ABCD bus control the thermostat, or the furnace system?

The thermostat controls everything. Even with a SAM that's the case. the ABCD bus is the medium for comms. While it's technically possible to eliminate the thermostat and replace it with a microcontroller, it's practically impossible since the protocol is undocumented and reverse-engineered. It took me 9 years to finally uncover how to control the touch thermostats via serial and that's still sketchy. A complete discovery implementation and control nuances over tens or hundreds of physical devices with slightly different features is out of scope by a mile.

[nebulous]

It seems like it would be ideal to develop a library that manages the communications with the system via rs485 bus, regardless of implementation (thermostat, HA, or?) and specific hardware interface (TTY or ethernet)

indeed it would and that's the general stretch goal. but I know from hard won experience that a hacky solution which exists is often easier to maintain than an elegant solution which doesn't. If possible I'd like to create a Kaitai implementation of the serial protocol and use its C++ output as the parser. Unfortunately Kaitai isn't reversible so I'd still need to implement writes, but at least it's not completely reinventing the wheel.

From a REST API perspective, it would expose GET and PUT functionality.

This is actually one of the reasons why I'm attempting to make this an esphome project. It already supports mechanisms to implement REST clients and services as well as MQTT, common sensors, etc. It doesn't require HA to be in the loop either, but makes interfacing with it joyously simple.

I've been looking at the cardump.c code in the infinitude repo, but don't have a good grasp yet on how to map frames to values returned in the status API call, nor do I have a working example to poke at. Since the code hasn't been touched in a lot of years, maybe the secret decoder ring is elsewhere for the infinitude web page? I can provide some help converting the raw data to JSON, if that would be helpful.

Were it only so simple... The majority of the content in Infinitude is provided by the thermostat as XML via tcp. Any additional data obtained from the serial bus has been discovered by painstaking reverse engineering. Infinitude tries to help users with said RE by providing a UI which understands the basics of the serial protocol framing and shows changing values, but no such secret decoder ring exists which maps elements in the serial stream to state values in the XML/JSON from Infinitude.

[jftaylorMn]

I have 20+ years of experience serializing and deserializing XML objects as well as using XSLT to transform XML into all sorts of things. In the last few weeks, I have successfully used tinyXML on the ESP32 to navigate the infinitude status response and convert it to a flattened JSON using ArduinoJSON. It's lots of repetitive code mostly generated using a spreadsheet. The resulting JSON is being passed as a message using MQTT. Nothing developed to consume or visualize the messages yet. Since I don't care about multiple zones, I chose to add JSON arrays only for temps, fan speed, and humidites where I record current as well as min and max (over a duration). Rather than nesting IDU and ODU properties, I just renamed the properties with conflicting names. I suspect that if I knew what the possible values are for opstat I would want to report distinct values over the reporting duration. Would one indicate a frozen over vent pipe? I now know that there is a thermostat submenu to see code history which might shed some light on that. When I get back there...

It seems like most new stuff is JSON. In the .Net development I've been doing over the past decade, I have mostly been working with JSON. It's a no-brainer to serialize/deserialize to either XML or JSON there. (sigh)

Maybe I'll learn to like ESPHome. Like most frameworks, it provides a lot of canned functionality (as you mention), at the cost of some flexibility. I did look into what comprises a climate device, and didn't readily see how some of the useful infinitude status elements would fit into that structure. I'm sure a totally custom ESPHome device could be defined, but that might be a lot more work. You are probably way ahead on that.

I had not heard of Kaitai, but looking at the web reference makes it look like it will do some of what is needed to decipher the streams from RS485. If you only need to develop the code to update settings, that should reduce the problem complexity.

It would really be nice if Carrier cooperated.