Thanks. I did file two small bugs under issues on the github page of your HA custom extension. We’ll likely need to create a fork of what you did in order for it to work with infinitude and the api that it uses there.
This may be a red herring but I could probably also make Infinitude play nice as an MQTT Thermostat if that’s less work than making changes to @texnofobix’s (or other) module.
Docker PR for Infinitude is submitted. As noted in the description, I just tried rebuilding the Docker image, and am getting a Wunderground API build failure. So this is not ready to be committed yet. I’m interest in knowing if others are seeing the same issue in a ‘traditional’ deployment.
I’ve also shared my old Infinitude custom component to GitHub. As noted on the README, I haven’t used it in about a year, and it isn’t working right now. I should be able to port the logic I created for my custom proxy server pretty easily. But for now, I just wanted to raise awareness that I have release this into the wild.
Didn’t Weather Underground just stop supporting their API service?
I really like this project, and have gotten pretty close, but when I put the component in the custom components folder and put climate:
- platform: Infinitude
into my configuration.yaml file I get an error,
Invalid config for [climate]: required key not provided @ data['host']. Got None. (See /config/configuration.yaml, line 55). Please check the docs at https://home-assistant.io/components/climate/any help is appreciated.
InfinitUDE is not presently working on HA. If you think you’ve found a way, would love for you to share more details.
InfinitIVE is currently working on HA.
A known working configuration for InfinitIVE look like this.
climate: - platform: infinitive host: 192.168.10.10 port: 8080
@nebulous How up to date is the Infinitude API documentation at https://github.com/nebulous/infinitude/wiki/Infinitude-API-calls?
It looks like you may have made some changes last December to allow for additional gets/sets?
In order to get my HA component back up and running, I need the ability to update
as well as
otmr within the config of each zone
Is this possible?
That documentation is… as up to date as I might expect
Any variable should be accessible to the API. The documentation such as it is was intended to demonstrate that by example, but I’ve always had a knack for miscommunication, so here’s the basics of what Infinitude does.
Infinitude at its core is a system to deterministically convert the stat’s xml to json, said json back to xml, and allow for it to be copied into the stat. So, one could, if sufficiently motivated, do all of the transformations outside of infinitude (with curl and jq for example) and pass in the results.
/api/config makes it a little bit simpler(though not much) to tweak one or two variables within that structure. It doesn’t use a full-featured path resolver like JSONPath, but maps basic URIs to attributes within in an admittedly haphazard way. Anything this level can’t do, the “lowest level can”, though I’ll be happy to tweak this to make things easier if I can. Apologies, I’m not in a location where I can explore my own setup to demonstrate right now, so this is all from memory, I recommend getting a JSON browser plugin to make it easy to visualize the structure, and hitting /api/config/(whatever paths) to explore the data.
/api/*path where *path can be (key|index)/(key|index)/etcetc
Infinitude’s web interface is an editor for systems.json, display for status.json, and optionally renders the RS485 stream. It pulls /systems.json, changes values therein, and posts back to the server for conversion to xml and queues itself up to get downloaded by the thermostat.
Thank you - that is helpful, and I have been doing some experiments to confirm the behavior at the ‘medium’ level. I’m taking the leap to assume that the list indexes are constant and reliable (i.e. /activities/4/ is always ‘manual’), which I can work with for now. Hoping to get my Infinitude components full up and running again today.
For those who are interested, I have rebased by custom component for integrating Home Assistant and InfinitUDE here:
I got infinitive setup this week using Will1604’s fork and it’s working, but the logs are flooded with the “retransmitting frame” and “action time out”. See snippet of log below. Is anyone else experiencing this? I seem to be able to control the thermostat, but it’s slow to update. I’m trying to figure out if this is normal. I tried switching from a raspberry pi zero w to a raspberry pi 3 to see if that would help, but it didn’t. Any suggestions?
Mar 14 01:13:59 raspberrypi infinitive: time="2019-03-14T01:13:59Z" level=info msg="encoded frame: 9201 -> 2001: READ 003b03" Mar 14 01:14:00 raspberrypi infinitive: time="2019-03-14T01:14:00Z" level=debug msg="timeout waiting for response, retransmitting frame" <-- this line normally repeats 5 times between reads. Mar 14 01:14:00 raspberrypi infinitive: time="2019-03-14T01:14:00Z" level=debug msg="transmitting frame: 200192010300000b003b03ecba" <-- this line normally repeats 5 times between reads. Mar 14 01:14:00 raspberrypi infinitive: time="2019-03-14T01:14:00Z" level=info msg="action timed out"
Yes I see the same issue in my log file. It does work overall though.
[[email protected] log]$ zcat infinitive.log-20190311.gz | grep -c 200192010300000b003b03ecba 15626 [[email protected] log]$ zcat infinitive.log-20190311.gz | grep -c "timeout waiting for response, retransmitting frame" 2266 [[email protected] log]$ zcat infinitive.log-20190311.gz | wc -l 234213
I know that people have had issues if they went with stranded cable vs solid core. Not sure what you’re using there. From my reading, the serial protocol has some architecture issues where you’ll have collisions on the bus because it doesn’t do any kind of CSMA/CD. If you don’t have a physical issue with the cable you may be seeing collisions of the original packet or the acknowledgement. Not really anything we can do about it from what I can tell.
I’m using solid 18AWG for the wiring. I assumed that would be sufficient. What are you using for cables and are you not seeing the timeouts in your logs? In my logs ~5 out of 6 logs are timeouts. It’s very frequent.
The collision issue could certainly cause some problems, but I wouldn’t think it would be so frequent. I could be wrong though. I may probe the signals with an oscilloscope to see if I can figure out what’s going on. Probably won’t be of much use, but it’s worth a shot.
I’m sure 18AWG would be sufficient. I had some leftover in the attic that was about that size. That’s what I’m using. And you’re right, I wouldn’t expect to be seeing that many timeouts. I’d imagine your cable run is relatively short so I wouldn’t expect noise on the line to be a problem. You could report an issue in Will1604’s Infinitive repo. I’ll keep looking and see if I can find anything that may help.
I’m using 20AWG solid wire for my runs, and I saw the same thing on Infinitive. I also have seen crashing issues on infinitude, which may be related to this as well, but not able to fully confirm, as it could be something else that is going on with the serial bus. I can’t imagine that the wire is “bad” on my 20 ft run.
I just upgraded and it stopped working. I think the key message in the log is:
ImportError: cannot import name ‘STATE_AUTO’ from ‘homeassistant.components.climate’ (/usr/local/lib/python3.7/site-packages/homeassistant/components/climate/init.py)
Actually I found an issue with the way that it was setup and fixed it (I had it at climate/infinitive.py instead of infinitive/climate.py). I did, however, have to comment out these lines (starting at 234) in climate.py in order to get it to work:
#self._heatpump_coil_temp = self._status['heatpump_coilTemp'] #self._heatpump_outside_temp = self._status['heatpump_outsideTemp'] #self._heatpump_stage = self._status['heatpump_stage']
Just posting this follow-up in case it helps anyone.
I’ve actually been out of town for the last few weeks and haven’t upgraded. It’s on my to-do list for next week and I’ll report back after I give it a shot. Thanks for the heads up.