Not so much an issue as a design request...

[jftaylorMn]

@nebulous - I took a look at the initial commit for infinitesp and will be hoping to see some code (whenever your obligations allow). I think we have common goals up to a point- specifically, I would like to have an API like the infinitive project that runs on more readily available and lower cost hardware (esp32). I'm not so much interested in creating a thermostat that does different things, as much as I'm interested in a more direct path to the details of what is happening in my furnace. I've had pipes freeze twice due to a completely frozen exhaust vent. If the data available via rs485 would expose the fact that the purge process has repeatedly failed (status <> 0), that would be worth the cost of admission. Just knowing that the furnace is not keeping up with the setpoint is probably sufficient. My solution will differ from yours by using MQTT over NB-IoT / GSM cellular to report rudimentary status info on a scheduled basis. Controlling the system over MQTT is a low priority for me.

The more components in a solution, the greater the number of interfaces to fail. Observing operational data directly from the furnace controller board sounds more direct than expecting the thermostat to communicate with infinitude (hosted on docker on rPi or ?) then linking via HA (on docker?) or some other option via MQTT. However unlikely that might be, when anything fails, I have a six hour round trip to resolve it.

So, if I could influence this project in any way, consider designing your solution with an independent API that supports GET (and PUT?) verbs (like Infinitive) that then provides support for the thermostat UI. It sounds like you made some progress with an ESP8266. If that code is in any presentable form, maybe that's a start for what I am looking for?

FWIW... I am not a GO programmer but have seen references to TinyGo that supports GO on microprocessors. Porting the infinitive code might be fine for the API. I'm not sure I want to rewrite the NB-IoT / Cellular code.

One final question/suggestion... I thought I was following how an rs485 adapter would connect to the controller board until I looked at the picture you posted with the esp8266. I expected to see a picture of the board with the ABCD jack. Is the wire that you spliced into actually the thermostat wiring (which communicates using "the bus")?

[nebulous]

The more components in a solution, the greater the number of interfaces to fail

Yes verymuchso. the reason I decided on the es32 box is that it's self-contained with a case. So the tail is wagging the dog a bit by adding an LCD thermostat interface.

It sounds like you made some progress with an ESP8266. If that code is in any presentable form, maybe that's a start for what I am looking for?

yeah I was able to get an esp8266 to parse frames by porting the C-based parser I wrote ages ago, but the 8266 struggles a bit with parsing(at least with my terrible code and servicing wifi. The esp32 is really a better platform for this since it has two faster cores and is still cheap in single unit quantities.

consider designing your solution with an independent API that supports GET (and PUT?) verbs (like Infinitive) that then provides support for the thermostat UI.

The goal is to provide an implementation of a home assistant Climate device - either as a custom esphome climate device, an mqtt climate device, or both. It sounds like your vote is mqtt, but whatever I end up doing I want it to be standalone - with no requirements for a SBC/docker/anything. So I think our needs are in alignment.

Is the wire that you spliced into actually the thermostat wiring (which communicates using "the bus")?

yep. I just connected the microcontroller to the thermostat wire at the existing A,B wirenut connections where the thermostat wire went into the air handler. Technically the bus should be in a terminated line without branches, but in practice the datarate is so low that reflections aren't an issue.

[jftaylorMn]

@nebulous - I just ordered an RS485 adapter today and was actually just looking at the c code you used to parse data. I have yet to find the secret sauce where meaningful data is gleaned from the bits. I also found a carrier doc online that specifically says that wire-nutting the circuit as you describe is acceptable. Relative to your comments about two cores... yes that is an advantage of the ESP32. I've also read that core 0 is really intended to be used for critical background stuff like wifi and bluetooth. rs485 data might fall into that category. Adding tasks to that core is possible, but there are cautions. That said, it appears that defining multiple tasks that run on core 1 works well and prevents blocking. The added speed by itself will probably help a lot.

I have yet to convince myself that home assistant needs to be part of my landscape. I have little interest in the control aspect (so far). I've read up on ESPHome, and like the concept in general. A framework like ESPHome has a lot of advantages and the expense of some flexibility. I think it would require me to maintain multiple nodes to achieve my goal. What I need most is a way to confirm that several systems are operational from remote- Key data points include furnace data, refrigeration, scattered temperature/freeze/water sensors and hall effect sensors on the propane tank gauge. I think that goes beyond a typical climate device, but is within the scope of what one ESP32 can handle. There is no ISP to provide network there, so I am relying on a GSM modem and AT commands that implement MQTT. Originally, I was going to place the MQTT server in the remote location, but that puts more things to break (LAN/WiFi, host for Docker, portainer, mosquito, HA, Infinitude, Influx, grafana etc) 3 hours away. So my current plan is to have as few devices as possible there (1 ESP32 is entitlement) , connecting to a cloud based MQTT server. From there, I will have a fast internet and can decide whether the rest of the architecture will be in my home or in the cloud (or hybrid?). As long as the GSM connection works, everything else can fail and I can still confirm that there aren't frozen pipes, a leaky water heater, or rotting food.

I like that the project will run on a readily available microcontroller. It might be that I end up forking your code or stealing some common functions at some point to create a one-off that aggregates data beyond your scope. My gut reaction is that a HA or ESPHome climate control isn't broad enough. The stumbling block is the single communications gateway (GSM modem). I could be convinced otherwise, so don't give up pushing back!

[jftaylorMn]

upon further review... ESPHome generated code must expose an API that HA uses. I assume it is well documented, but don't know. Worst case, it should be observable using a sniffer. I keep forgetting that I can't run two separate programs (web service and consumer) on an ESP32. Adding a router and and a second mcu for the non-climate stuff and MQTT via GSM might be the way to keep my needs in alignment with your direction. It would be better than requiring a platform for docker, HA, etc in the remote location.

[nebulous]

ESPHome can speak to HA via HA's api - it advertises itself and publishes the various switches/devices/and in this case standard thermostat/climate device to HA. It also can pub/sub mqtt and makes a basic REST/Websocket interface available as well as a webserver. It's pretty awesome and solves a lot of the basic problems that need solving without reinventing the wheel. And of course, if you use HomeAssistant it's a nobrainer because everything JustWorks™ in a way that's pretty outstanding if you're accustomed to the slog of manual one-off embedded development.

An ESP32 can definitely run both a consumer of web services as well as provide services simultaneously fwiw.

[jftaylorMn]

OK, In my quick look at the climate API, the list of items seems more limited than what I see in infinitude, but I assume you are seeing how it will be extensible to include items not in the base class (e.g. humidity, filter state, outside temp, cfm, zones). I work better with examples... I'll let you get something together and see where/how it will fit in my environment. No rush.

If I need to run HA and an ESPHome device for the climate data and another device for the other details and GSM connectivity I'm up to three devices (plus WiFi router) and will have new data stored (without backup) on the far side of a marginal connection. Maybe that's the best/most reliable solution? There is benefit in not reinventing the wheel.

I just read a this that says among other things that the ESPHome native API is much more efficient than MQTT. I have a wyse 5060 with a reasonable SSD that can run HA as an OS or docker container so I can't use the rpi4 shortage excuse. HA adds complexity. Maybe that shouldn't matter if it never breaks and recovers automatically from power outages. Then, "my" one-off development is pulling the recent carrier/bryant data from HA/mariaDb, adding the non-climate data, then sending it to the cloud MQTT host using the NB-IoT cellular modem.

Your wiki references Modbus, but I think it's only similar to Modbus (frames/addresses/functions). I see a few arduino libraries out there to support modbus and also that expressif is actively supporting ESP- specific code. Even if the protocol isn't exactly the same, you might find that you can use patterns to identify different message types and extract details more effectively than your esp8266 solution from several years back? Just a thought to consider when you get beyond the "does the display work" issues (sounds like you may be there?).

An ESP32 can definitely run both a consumer of web services as well as provide services simultaneously fwiw.

True, multiple tasks can execute on a couple cores but an esp32 can only run one program. I would need to fork your mainstream code to add functionality beyond the scope of carrier thermostats/controllers.

I'll keep squeezing the balloon.

[jftaylorMn]

@nebulous - My current focus is to get data collected by ESP32, transmitted using MQTT over GSM, inserted in an InfluxDB database. Rather than using the InfluxDB libs to push the data directly or using telegraf to process the MQTT data, I decided to look into the capabilities of Node-Red. One of the selling points is that through extensions, it can interact with many different sources and targets (SQL, influx, prometheus, csv, JSON, XML, and others). It can also expose API endpoints and web pages. A quick search of custom extensions today determined that Node-Red has connectivity to modbus via serial or tcp.

This may not be new info to you. Node-Red can easily interact with HomeAssistant and developers are working on a direct link to ESPHome Devices. It could change the way you (and I) think about the task to interact with the infinity controller board via rs485. Maybe you could leverage the built-in capabilities with one of the existing Modbus extensions to save data to a time series database, then the ESP32 could interact with the database or Node-Red could interact with your ESPHome device?

If an existing extension doesn't provide what is needed, skills in HTML and JavaScript are needed to program new node types for Node-Red. I've only looked at the main topic

Thoughts?