I have been working on a fork of infinitive in which I have fixed some old bugs and added multi-zone support as well as a number of extra sensors and debug/tracing features. Instead of messing with the existing home-assistant integration, which became an unwelcome challenge (for me) to extend for multiple zones, I added optional MQTT pub/sub support for infinitive’s sensors and controls in a form that’s compatible with the standard MQTT Climate integration. This way a fairly simple config blob (which soon should be created by MQTT discovery) creates fully working HA climate entities for each HVAC zone, without needing a custom integration. Plus, efficiency is improved and latencies are reduced since it benefits from MQTT’s “push” model rather than polling.
It is still a work in progress and in particular I have not bothered making releases/builds, not knowing if there is any broader interest, but I can do if there is. I have tried to maintain backward API compatibility so any existing clients of other infinitive forks should still work fine on a one-zone system (or just see Zone 1 on a multi-zone system as they would today). But there has been no testing to validate these things. This and a number of other caveats are mentioned in the README.
I was going to wait a little longer to publish this once it is a little more polished but was inspired by seeing some recent activity on this thread. I will be happy to try to address any feedback or push releases if others want to make use of it and report results.
Interesting, I’m in the process of re-writing infinitive as a driver in node.js/Typescript, with the intent to package it as a standalone driver, and as a separate package with a socket/api wrapper, and eventually a Home Assistant integration. (I’ve modeled it off node-zwave-js as I’m a minor part of that project.) I’m trying to avoid mqtt if I can. Like you I suspect, this is mostly a project to work on and I’m not sure how big of a demand there is. I was looking to explore a serial project in node.
I’m only a few days into it, up to the point of successfully reading the parsed frames from the serial port, so it’ll be a while before mine is finished.
Have you figured out what’s going on with the vacation mode yet? I am trying to make an automation to set the thermostat to vacation mode when no one is home.
Yes, looks like this is one of the things I fixed, it was a simple math error trying to calculate the number of vacation days based on the number of hours remaining. A one-line fix in commit e0708bb at tabes.go line 86/88.
I also added API support to get/set vacation time in units of hours (rather than days) since that’s how it is actually tracked in the serial API and could be useful.
I noticed that Infinitive saw some merges tonight for the first time since 2021, which changes the api. I imagine it’ll break the integration for good. Just an FYI for everyone.
Hey all. Sorry I’ve been gone for a while. Life and work changes have taken all my free time. I’m trying to make myself set some time aside for my HA hobby.
For the integration, it may be best to transfer that repo to someone else in the community who can push it forward. I had to replace my HVAC a little while back and couldn’t get another Bryant/Carrier unit. As of now I don’t even have anything to test with.
If anybody’s interested let me know. There’s also the underlying pyinfinitive Python package hosted on pypi.
Until then I’ll do my best to pay attention to the repo so that any PRs that come through we can merge.
Hi @laur ! So I was about to start digging into ACD’s repo and noticed you did pretty much what I was trying to achieve, which was multi-zone support ! Thank you so much !!!
The only thing is that I’m a bit lost about where to put the MQTT additional options mentioned in the instructions. The service is running as a daemon per mww012 instructions, I added 1 config per zone in my configuration.yml but I’m not able to retrieve any data to my sensors.
Hi. Very cool that you want to give this a try. I am assuming you’ve got an MQTT broker running and you have set up the HomeAssistant MQTT integration to poll it. You need to know the hostname or address, and username/password for your MQTT broker.
If you have followed @mww012’s excellent instructions to set up a daemon using systemd, you’ll need to change the ExecStart= line to two lines, something like:
of course, you will need to provide the pathname of the infinitive executable built from my branch, and also substitute your serial device name and MQTT parameters in those lines. With that in place, reload the systemd unit file if needed and restart the service.
Once infinitive starts posting to MQTT, HomeAssistant should auto-discover several entities. If it isn’t obviously working, I recommend looking at the infinitive log using journalctl -u infinitive to see if it is connecting to MQTT or reporting failures.
That’s a lot and I don’t know where you are starting from, so have a look and let us know how far you get.
Thank for help @laur . I did update my ExecStart= and I can see something is happening when checking the status of the service with systemctl status infinitive :
And I can confirm that Infinitive works properly because the value return to the web ui are correct (except that outdoor temp that is not right for some reason … ) :
So @laur I managed to make it work ! Turns out that using the MQTT Broker hostname (core-mosquitto in my case) in the mqtt option was the issue. But using the ip address of the broker did the trick.
So for anyone using this as a service, here’s the proper infinitive.service config you need :
If anyone is struggling with setting a temp to their thermostat from Home Assistant, instead of using Service: Climate - Set Target Temperature, you need to use the publish topics mentioned in @laurdocumentation and use Service: MQTT Publish instead.
Here’s an example (adjust the topic and value based on your need):
I’m really glad to see you got it working. Regarding your experience that climate.set_temperature is not working for you, it appears to require specifying both the low and high temp settings, for example this works for me:
If only one of the target_temp_xxx values are provided, I get an error when making the service call:
Failed to call service climate.set_temperature. some but not all values in the same group of inclusion 'temperature' @ data[<temperature>]. Got None
Must be something in the climate entity or the MQTT climate integration. Makes it a little inconvenient for some use cases so your workaround to post directly to MQTT could be helpful. But I’ll point out that it works fine with the common thermostat UI cards so they must take this into account already.
Just curious how you managed to make this work using the HAT @blhoward2 ? I’ve got 6 Bryant evolution systems scattered around in a large building that I’d like to get into HA. As a late comer I’ve scared up at least 5 different repos to tackle this. I haven’t had any luck with any repos that require installing go. But I have got the ACD repo working and than adding the IP of the pi to config yaml. Got Pi 4 to usb 485. Only trouble with this setup is HVAC action and blower rpm are not working.
So my question. Which is the best repo to use today? And what do I replace serial=/dev/ttyACM0 with in the infinitive.service file with to make the hat work.
With go1.24.2 linux/arm installed on pi zero I get: unrecognized command-line option ‘-marm’ part way through go install github.com/mww012/infintive@latest
I can’t help with the HAT wihtout more specifics, but you should check the documentation or sample code for the specific device or driver you are using, or just look in /dev, and you should be able to discover the device name to use.
I currently use go1.23.5 on a pi 3b, and I expect it should work with 1.24.x. If you tried and had trouble, open an issue with details in github and I would be happy to try to help.
Appreciate the reply! think I’ll keep trying here a little more to get this working. As for the RS485 hat issue a simple uart enable in the config.txt made ttyS0 show up in /dev. Somewhere along the way I read someone was using raspberry pi os lite. does it make any difference if I use 32 bit or 64 bit with this project? or whats recommended?
Edit: went the 32bit route and setup a repo so I can replicate this 5 more times onto 5 more rpi’s for the rest of the HVAC’s as they are scattered about the building. I’m hoping this MQTT method works as single zones for each hvac as I’m sure it wouldn’t be a good idea to tie the 485 lines on all the hvac units together to make zones… I don’t fully understand how zoned systems work here but I guess fixing to learn. Will take this working rpi zero and install it latter today and see if we get anything into HA. I still don’t fully understand the correct way to use go, so if someone looks over my install method and has any pointers, please let me know!
I have not tested on 32-bit but glad to hear it is working.
Bridging the serial lines on multiple systems is not recommended because each system uses the same well-known device addresses on its bus, and I have never heard of a way to change that to avoid the conflicts that would happen.
Multiple HVAC systems is different from a zoned system which uses one controller, blower, heater/heat pump/AC, etc, with multiple room sensors, and controls baffles to route conditioning to different parts of the building as needed. If you have multiple complete systems, you need to treat them each separately.
I have not tested but you should be able to use a multi-port rs485 HAT and/or multiple USB rs485 serial adapters on the same Pi, and run multiple instances of infinitive, each pointed to distinct serial and http ports (and instance name if you use mqtt). The infinitive process itself uses very little system resources so I expect even a small Pi should be able to run a few instances. My old Pi 3B+ with 1GB RAM reports about 1% cpu and 1% mem being consumed by one infinitive instance. Obviously ymmv depending on your hardware and what else you run on it. If you do run multiple instances, you also need to take steps to map consistent serial device names across reboots and hardware changes.
Really appreciate all your work on your repo @laur !! it just works!! and I’m getting the hvac_action returned into HA now, I haven’t been able to get that in any of of the other repos I’ve tried. Also, hopefully going this MQTT route results in longterm support with HA. I’ve one more question to bother you with as I haven’t figured out how to set the instance name from the rpi side yet and before i make another 41 entities…! (Already got 92 unused in here that I’ll need to figure out how to delete) I put this in the service file: ExecStart=/home/pi/infinitive -httpport=8080 -serial=/dev/ttyUSB0 -instance=HVACc_Hall_East -mqtt=tcp://[email protected]:1883
Which results in: May 06 18:23:51 hvactestmqtt infinitive[473]: time="2025-05-06 18:23:51" level=info msg="MQTT PUB: HVACc_Hall_East/blowerRPM -> 740" May 06 18:23:54 hvactestmqtt infinitive[473]: time="2025-05-06 18:23:54" level=info msg="MQTT PUB: HVACc_Hall_East/coilTemp -> 47"
the climate entities are changed easy enough in HA, but I’d like to use some of the sensors and buttons and once I install all 6 RPI’s at all the HVAC units this entity page will become nearly unmanageable.
So, what’s the correct way to set the name from service file on rpi, and once set can I expect all buttons, sensors and climate entities to show up in HA with their proper name? Thanks for your help!!
I appreciate your not wanting to have to rename the entities, which would get tedious and confusing. I see what’s happening here… it is due to deficiencies in the MQTT Discovery messages we create which will be simple to fix, and there are at least two issues:
the climate entity is named based on the zone name in the Infinity control, but because you have a single-zone system its name is the default “ZONE 1” which you probably can’t change on your control - and it will be the same on every one of your systems, so you are getting two climate entities called “ZONE 1”.
the sensor and button entities we create end up being named the same in each instance, so you will need their names to be differentiated by the instance name.
I’m happy to work up a fix. Please open an issue on github and we can continue discussing the fix offline there.
Great work @laur!! works perfectly! Now to automate!! I’ve a question for those that have been using this for some time. It appears this approach requires both hi and low temps sent whenever HA sends mqtt message to infinitive. So of course the regular thermostat on the ui in HA works perfect, but is there someway to build simple automations straight from the dashboard with the scheduler card or something similar? (I don’t want day to day users for this building digging through setting>automations) There some simple way to edit schedular card to send both hi and low temp? What’s your favorite way to interact with this climate entity? @CptnWookie ??
