It's not always clear to new users how Infinitude works:

[jftaylorMn]

I extracted the comment below in another open issue 160 related to proxmox setup. Today, I have been looking without success for the code that serves as the proxy, capturing the various XML files to the SD card (on a RPi). I'm at a disadvantage since I don't know Perl. I guess I'm thinking that a bit more technical detail on how the code works, where functionality exists, and maybe some troubleshooting details (memory leaks, firmware issues, logs, etc) would be of benefit. There have been some users who found solutions in open and closed issues, but that doesn't seem too efficient.

I hope to look at the API for PUT actions sometime in the future. I find the documentation is confusing in that the "parameters" appear to be a mix of routes and body text, but I suppose they could be query parameters. I'm sure I will get it with some trial and error... That's another area where docs could be improved (to match what might be set up in Postman for example).

It seems like the entry below would be a good start for a technical overview. A few notations on the connecting arrows that would lead to repository files/folders or wiki pages might really help. While there have been a handful of contributors to the code, it seems like you are probably in the best position to author the basic information. Once the framework is defined, others can add to it.

Here is my motivation behind the issue... While Infinitude seems stable on the RPi Zero 2W (with scheduled reboots), I am still concerned that sooner or later, my SD card will fail if XML files are being overwritten frequently. Hence... I am thinking about rewriting the proxy server functionality (Read only for now) in the ESP32 environment so that these files are maintained in memory. The ESP devices can be access points, can manipulate XML, create JSON, which seems like all that is really happening in the infinitude block for GET operations. I was hoping to see what if any response (200?) is sent back to the thermostat.

I know this isn't your "day job", and suspect others will be willing to help flesh out details. I think you mostly need to figure out if this should be a wild-west wiki page or under pull request control (readme.md).

Here's your post to issue 160:

        It's not always clear to new users how Infinitude works so maybe this diagram will help:

Infinitude runs by default on port 3000, both its local web interface, and as a web proxy so that it can intercept the polling traffic between the thermostat and Carrier's servers. Talking to Carrier's servers is something that I don't really do and I become decreasingly interested in problems as they get further up and to the right in this diagram.

So as @jftaylorMn said, your thermostat will need to be able to contact the Infinitude instance on whatever port you select (tends to be 3000). Leave the server settings alone at whatever they're configured to by default (either carrier or bryant or ion) and only add an http proxy to Infinitude.

Originally posted by @nebulous in https://github.com/nebulous/infinitude/issues/160#issuecomment-1351755528

[nebulous]

To get this over with up front - It's totally okay to make changes to the wiki, or PRs to the README with any clarifications. Infinitude is a pile of hacks glued together with another pile of kludges to make use of a service that is downright terrible in the best of times. So I totally get how it could be confusing, but as I'm a fish in this water I rely on outside perspective to learn what needs more explanation.

Also feel free to bump a thread like this if I manage to lose track of it :)

To answer your more specific questions:

I have been looking without success for the code that serves as the proxy

The before_dispatch sub handles the bulk of that.

If Infinitude gets a request from the thermostat(as identified by the Host request header being carrier/bryant/ion/or localhost) it forwards along the request to Carrier if the update timer has elapsed, the change flag is set or if the cached value for the url has not been set or has expired.

capturing the various XML files to the SD card (on a RPi)

It then stores several versions of the data - a raw request/response, the xml payload, and the xml payload transformed into json. It uses a key/value cache store for all data persistence with the CHI cache wrapping interface. By default that uses Files, but different backends can be transparently swapped out for persistence (memcache/redis/memory/shared memory/etc/etc. You might find that using a different driver alleviates your SD card concerns - though I'd recommend using f2fs and/or a loopback fs for your state folder which should, along with the kernel's default file caching, result in a pretty easy time on the SD card.

[github-actions[bot]]

Stale issue message

[jftaylorMn]

@nebulous - Its good to see some activity here.. I have not forgotten about this. I think my issues related to my cellular modem are under control and started to pay more attention to Infinitude. Based on the inactivity on this repo and your ESP32 repo, I'm guessing that life continues to get in the way for you. Anyway, I put together a component map that illustrates my "from the outside" perspective on how/where infinitude fits.

InfinitudeComponentMap.odp

I hoped to try to break out the four sub components to identify code that covers the features. I haven't done that yet, so haven't modified the wiki. I'm thinking that it would be best to create a new wiki topic called "component map",

Still hoping to find a way to add a proxy server/local storage of infinity payloads on the ESP32 so I can take the rpi out of the landscape. SD card stability is my main concern. I still don't have aspirations to enable remote/home automation control. I did buy a cheap rs232 to 485 adapter and might see what I can. It seems risky to leave such a device on the bus during the heating season while I'm hours away for weeks at a time.

BTW- it's perfectly fine to close this issue.