mizterb / homeassistant-infinitude Goto Github PK

If I manually adjust the temperature via home assistant or on the thermostat itself, it always reverts to whatever the “scheduled” preset was after a few seconds.

This has been working fine for some months, so not sure what broke. I tried restarting everything to no avail; not seeing any logs or errors either. User error? Or did something break?

I'm running HA 2021.9.7

Was working fine the first 48 hours and now I can no longer control the mini split.

Logger: homeassistant.helpers.entity
Source: custom_components/midea_ac/climate.py:129
Integration: midea_ac (documentation)
First occurred: 9:32:07 AM (1214 occurrences)
Last logged: 2:35:25 PM

Update for climate.office_mini_split fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 446, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 641, in async_device_update
raise exc
File "/config/custom_components/midea_ac/climate.py", line 129, in async_update
await self.hass.async_add_executor_job(self._device.apply)
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.9/site-packages/msmart/device.py", line 264, in apply
self._send_cmd(cmd)
File "/usr/local/lib/python3.9/site-packages/msmart/device.py", line 208, in _send_cmd
responses = self._lan_service.appliance_transparent_send_8370(data)
File "/usr/local/lib/python3.9/site-packages/msmart/lan.py", line 136, in appliance_transparent_send_8370
data = self.security.encode_8370(data, msgtype)
File "/usr/local/lib/python3.9/site-packages/msmart/security.py", line 117, in encode_8370
data = self.aes_cbc_encrypt(data, self._tcp_key) + sign
File "/usr/local/lib/python3.9/site-packages/msmart/security.py", line 57, in aes_cbc_encrypt
return AES.new(key, AES.MODE_CBC, iv=self.iv).encrypt(raw)
File "/usr/local/lib/python3.9/site-packages/Cryptodome/Cipher/AES.py", line 232, in new
return _create_cipher(sys.modules[name], key, mode, *args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/Cryptodome/Cipher/init.py", line 79, in _create_cipher
return modes[mode](factory, **kwargs)
File "/usr/local/lib/python3.9/site-packages/Cryptodome/Cipher/_mode_cbc.py", line 274, in _create_cbc_cipher
cipher_state = factory._create_base_cipher(kwargs)
File "/usr/local/lib/python3.9/site-packages/Cryptodome/Cipher/AES.py", line 92, in _create_base_cipher
if len(key) not in key_size:
TypeError: object of type 'NoneType' has no len()

I'm having a problem with the climate.py script.
It doesnt seem to be pulling the localTime correctly, here is the error message
File "/config/custom_components/infinitude/climate.py", line 193, in update "%Y-%m-%dT%H:%M:%S") # Strip the TZ offset, since this is already in local time File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime (data_string, format)) ValueError: time data '2019-06-02T14' does not match format '%Y-%m-%dT%H:%M:%S'

When I go to the infinitude page i can see localTime does not have a timezone offset.

localTime | 2019-06-02T15:19:08

So I removed the string slice on line 193 and updated to this and it seemed to do the trick.
original
dt = datetime.datetime.strptime(getSafe(self._systemStatus, "localTime")[:-6], "%Y-%m-%dT%H:%M:%S") # Strip the TZ offset, since this is already in local time
updated
dt = datetime.datetime.strptime(getSafe(self._systemStatus, "localTime"), "%Y-%m-%dT%H:%M:%S") # Strip the TZ offset, since this is already in local time

I live in Europe, and normally use Celsius over Fahrenheit. At the moment the unit is hard-coded. It would be nice if component picked it up from the API

Home Assistant 2021.12.* - adding infinitude integration causes UI to hang at "loading data" when opening a new window. Affects all browsers, iOS app, and incognito mode.

At this point would you recommend using InfinityTouch or Infinitude? Is it possible to run either on a system setup with a "stock" HassOS HA image?

The Infinitude proxy is setup and functioning (I can telnet to port 3000 and generate an error in the log) and I've configured the IP and Port (3000) in the Carrier wall control, but I never get any data from the Carrier unit to the proxy, just constant

[2022-12-16 17:57:47.26488] [6] [info] Websocket opened, but no streaming source is available

in the logs. The wall unit is using the latest software version, 4.31. Any suggestions?

As documented in testing here, when I set a preset in HA, the preset name updates quickly, but the temperature values can take over a minute to indicate that preset's temperate range.

2021-03-03 14:01:18 WARNING (MainThread) [homeassistant.loader] No 'version' key in the manifest file for custom integration 'infinitude'. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of 'infinitude'

this appeared with latest release, FYI (not sure if this is still being maintained?)

In my logs, getting the following message:

"ClimateDevice is deprecated, modify InfinitudeZone to extend ClimateEntity"

I don't see anywhere in the code where you can assign a name to the system. In my non-zoned system, it simply gets a name of climate.zone_1 instead of a friendly name. You can always customize this name within HA, but perhaps a "name" parameter should be added. This could get tricky with multiple zones though.

I use Home Assistant to run two thermostats that are controlling two different HVAC systems (don't ask, previous owner installed). When I first set up infinitude, there was an issue running multiple components, so I had to rename the HA custom_component folders (I used "infinitude-1" instead of "infinitude") via a symbolic link to the infinitude repo folder. Later HASS changes required me to make a duplicate of the custom_component folder (infinitude-1, and infinitude-2), because there were code changes required to make sure the "domain" (infinitude-1 or 2) matched the custom_component folder name. In particular, I had to modify the manifest and the climate.py places where "infinitude" was given as the domain name, so my two copies now have "infinitude-1" and "infinitude-2". This appears to be working well right now, but infinitude has been a source of trouble with all these recent HA changes.

a) is it still necessary to run differently named components? Can I just have two components named "infinitude"?
b) if not, what code changes could be made to make it simper to maintain this type of situation?

I can't tell if this is a quirk with my installation or if this is a problem with the plugin. It appears to be crashing on zone names. I've tried various iterations of naming them in the configuration.yaml or excluding the key. I've updated the zone names in the thermostat too and made them match or not match.

Not sure if this is just a symptom of the upstream problem with infinitude either. I suspect the device should show up but as unreachable if the infinitude proxy is not working right.

Just can't seem to get it to work:

Logger: homeassistant.components.climate
Source: custom_components/infinitude/climate.py:111
Integration: Climate (documentation, issues)
First occurred: 12:10:56 PM (1 occurrences)
Last logged: 12:10:56 PM

Error while setting up infinitude platform for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 281, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/infinitude/climate.py", line 111, in setup_platform
zones = status["zones"][0]["zone"]
TypeError: 'NoneType' object is not subscriptable

I have a pretty simple HA-Infinitude setup running, but the system is not registering a device for Infinitude. The integration shows up in the integration list under about (but not in the main integration list), I've performed the configuration steps, and an entity is defined with data being reported successfully, but no device shows up in my device list.

Here's the first element from my zones array:
{"zoneconditioning":["idle"],"currentActivity":["home"],"occupancyOverride":["off"],"id":"1","otmr":[{}],"occupancy":["unoccupied"],"enabled":["on"],"hold":["off"],"rh":["57"],"damperposition":["15"],"fan":["off"],"htsp":["65.0"],"clsp":["75.0"],"rt":["71.0"],"name":["ZONE 1"]}

Ideas?

Is it possible to add new entity attributes?

I am talking exactly about :
filter_level:
humid_filter_level:
uv_filter_level:

They are available in this add-on:
https://github.com/nfriess/carrier_infinity/issues
The controller transmits this data, so maybe homeassistant-infinitude could be added?

All of a sudden, the climate entity is no longer available. Has there been a breaking change or somewhere to look to find out why this is happening. Logs only show that this integration is taking too long to load and that there is a date out of range.

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/infinitude/climate.py:371
Integration: infinitude (documentation)
First occurred: 10:08:42 AM (1 occurrences)
Last logged: 10:08:42 AM

Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
File "/config/custom_components/infinitude/climate.py", line 216, in init
self.update()
File "/config/custom_components/infinitude/climate.py", line 371, in update
dt = datetime.datetime(
OverflowError: date value out of range

I'm not familiar with either Home Assistant or Infinitude, so apologies if this should be obvious.

I just bought a house with an Infinity system and one of the major benefits I was hoping to gain with a smart thermostat was historical usage data. Now that my ecobee dreams have been crushed, I'm hoping Infinitude can provide this data.

I wasn't able to see anything in the readme that indicates that it stores usage or sensor data anywhere. However, looks like it displays the current temperature/humidity/airflow and your settings.

So does this component and HA store the data anywhere? Or could it be configured to?

My version of the thermostat does not support the presence detection feature. Thus Infinitude API do not return an attribute for that.

Unfortunately this leads to the component crashing during the HA load fase (and not being loaded as the result)

I am attempting to move to infinitude in Hass.io, and am receiving the following error when starting up Hass.io.

Error while setting up infinitude platform for climate
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 179, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
    return fut.result()
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/infinitude/climate.py", line 78, in setup_platform
    zones = status["zones"][0]["zone"]
KeyError: 'zones'

I am running Infinitude in docker, and have tried a few instances running on different hosts, and get the same error. The output in the API appears to be ok. I only have 1 zone, and the output matches what is in the Infinitude UI.

I appreciate your help. Please let me know if there is any additional information I can provide.

The infinitude API reports an attribute named ‘mode’. On my system it tells me if heating is using the heat pump or the hydronic system. This attribute would be useful to me in HA but I’m not seeing it there. This is the same attribute that shows in the Global section of the infinitude web page as ‘operating mode’… so perhaps calling it global_operating_mode in HA would make sense.

Thanks much for the effort!

Accidentally updated last night — still receive the message about the custom component loading, but I no longer have an entity under climate and UI elements come back as unknown.

Will up my log level and try to add to this shortly.

Some change was made specifically in HA Core 2023.5.0.dev20230401 that prevents the HVAC card from reading about half of the info this integration should be providing. The breaking change is still present in as recent 2023.11.3.

Screenshot below:

It appears that the main infinitude code doen't like when you set the temperature on a non-zoned system. Overall it works, but complains about $zone_id and $prop as shown below.

[Sun Mar 10 13:10:58 2019] [debug] GET "/api/config/zones/zone/0/activities/activity/4/"
[Sun Mar 10 13:10:58 2019] [debug] Routing to a callback
[Sun Mar 10 13:10:59 2019] [debug] 200 OK (0.323625s, 3.090/s)
[Sun Mar 10 13:10:59 2019] [debug] GET "/api/config/zones/zone/0/"
[Sun Mar 10 13:10:59 2019] [debug] Routing to a callback
[Sun Mar 10 13:10:59 2019] [debug] 200 OK (0.356275s, 2.807/s)
[Sun Mar 10 13:10:59 2019] [debug] GET "/api/status"
[Sun Mar 10 13:10:59 2019] [debug] Routing to a callback
Use of uninitialized value $zone_id in pattern match (m//) at ./infinitude line 170.
Use of uninitialized value $prop in pattern match (m//) at ./infinitude line 177.
[Sun Mar 10 13:10:59 2019] [debug] 200 OK (0.005593s, 178.795/s)
[Sun Mar 10 13:10:59 2019] [debug] GET "/api/config"
[Sun Mar 10 13:10:59 2019] [debug] Routing to a callback
[Sun Mar 10 13:10:59 2019] [debug] 200 OK (0.102339s, 9.771/s)
[Sun Mar 10 13:11:10 2019] [debug] systems-331XXX6-status cached or passthru disabled
[Sun Mar 10 13:11:10 2019] [debug] /systems/331XXX6/status
[Sun Mar 10 13:11:10 2019] [debug] Saving status
[Sun Mar 10 13:11:10 2019] [debug] POST "/systems/331XXX6/status"
[Sun Mar 10 13:11:10 2019] [debug] Routing to a callback
[Sun Mar 10 13:11:10 2019] [debug] ********** There are changes. ****************

Can we add a sensor entity that exposes the oat (Outdoor Air Temperature)? That's useful data, especially for graphing against the other climate data we get. Other sensors like rh (Relative Humidity) would be useful too,

Pretty easy to work around with a template sensor but being builtin would be nice.

Based on https://community.home-assistant.io/t/carrier-infinity-integration/17161/118

We should see how we can get this component to set the current activity for the thermostat. In the climate component, home assistant has the constant of SUPPORT_AWAY_MODE, however this is a boolean field and not a string field. I think we should be able to override this constant and allow the away mode to be a string field and not boolean.

First need to update the activity index, since it is erroneously listing away twice and missing wake.

ACTIVITY_INDEX = {
    "home": 0,
    "away": 1,
    "sleep": 2,
    "away": 3,
    "manual": 4
}

API calls to infinitude will probably look like this:

http://infinitude:8080/api/config/zones/zone/0/?hold=on&holdActivity=home&otmr=
http://infinitude:8080/api/config/zones/zone/0/?hold=on&holdActivity=away&otmr=
http://infinitude:8080/api/config/zones/zone/0/?hold=on&holdActivity=sleep&otmr=
http://infinitude:8080/api/config/zones/zone/0/?hold=on&holdActivity=wake&otmr=

But, if we set the hold on all the time without an end time (in the otmr field), the normal Infinity schedule won't ever really take affect, unless you do scheduling with HA instead of the Infinity itself. If we want to respect the current schedule (which is probably the correct way to do this), would need to be able to first do a query to find out when the next scheduled activity is, and instead only do a hold until the next scheduled activity, that way the schedule on the Infinity would still apply. We already know this information in self._nextActivityStart and self._nextActivity. Just have to think through the best way to write this into the component.

I'm trying a plain vanilla install with all default options but ran into this error:

log file

2020-07-20 09:55:50 ERROR (MainThread) [homeassistant.components.climate] Error while setting up infinitude platform for climate
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 178, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 416, in wait_for
    return fut.result()
  File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/homeassistant/.homeassistant/custom_components/infinitude/climate.py", line 90, in setup_platform
    devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
  File "/home/homeassistant/.homeassistant/custom_components/infinitude/climate.py", line 183, in __init__
    self.update()
  File "/home/homeassistant/.homeassistant/custom_components/infinitude/climate.py", line 290, in update
    matches = re.match(r'^(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2})([+-]\d{2}:\d{2})?$', local_time)
  File "/usr/lib/python3.7/re.py", line 173, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object

configuration

climate:
  - platform: infinitude
    host: rpi
    port: 3000
    zone_names:
      - Home Zone

response from infinitude for api/status (I don't see 'localTime'):

{"cfgauto":["on"],"cfgcph":["4"],"cfgdead":["2"],"cfgem":["F"],"cfgfan":["on"],"cfgpgm":["on"],"cfgtype":["heatcool"],"filtrlvl":["88"],"humid":["off"],"humlvl":["0"],"mode":["off"],"oat":["80"],"statusCode":["10"],"uvlvl":["0"],"vacat":["off"],"vacatrunning":["off"],"vacend":[{}],"vacstart":[{}],"ventlvl":["0"],"version":"1.3","zones":[{"zone":[{"clsp":["77"],"currentActivity":["manual"],"enabled":["on"],"fan":["off"],"hold":["on"],"htsp":["65"],"id":"1","name":["ZONE 1"],"otmr":["00:00"],"rh":["48"],"rt":["77"]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"2","name":["Zone 2"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"3","name":["Zone 3"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"4","name":["Zone 4"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"5","name":["Zone 5"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"6","name":["Zone 6"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"7","name":["Zone 7"],"otmr":[{}],"rh":["48"],"rt":[{}]},{"clsp":["80"],"currentActivity":["away"],"enabled":["off"],"fan":["off"],"hold":["off"],"htsp":["60"],"id":"8","name":["Zone 8"],"otmr":[{}],"rh":["48"],"rt":[{}]}]}]}

A working install not working since latest 0.114 and most recent 0.115.1 updates.
No changes to the configuration or anything else. HA seems to work fine otherwise, and infinitude is also accessible.

`
2020-09-19 11:28:27 ERROR (MainThread) [homeassistant.components.climate] Error while setting up infinitude platform for climate

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 193, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
File "/config/custom_components/infinitude/climate.py", line 216, in init
self.update()
File "/config/custom_components/infinitude/climate.py", line 342, in update
matches = re.match(
File "/usr/local/lib/python3.8/re.py", line 191, in match
return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object
`

related config file:
`climate:

• platform: infinitude
  host: 192.168.0.15
  port: 3000
  zone_names:
  • Bedrooms
  • Living Area`

could this be related to? #22

When mode is set to auto, lovelace UI seems to struggle. It should show the min and max button on the lovelace UI thermostat, but when in auto seems to only show one dot for temperature. Not sure what lovelace is expecting, maybe the variable name aren't matching what lovelace wants. A workaround is to pull up additional details on the thermostat and you can set the heat/cool temps there.

This is not an issue against this integration. It seems to be working well for me. I would have posted this in the Discussions section, but it doesn't appear to be enabled.

Since HA supervised does not support Portainer, requiring an unsupported installation of the unofficial Portainer add-on, would it be possible for you to create an Infinitude add-on like I've seen other developers do with projects like Z-Wave JS UI, etc?

Here's my discussion on the unofficial Portainer add-on repo for more context.

Since whether underground does not provide free api keys anymore I did not configure any in my infinitude instance.
https://www.wunderground.com/weather/api/

Unfortunately this leads to the component crashing during the load fase as it expects a value and gets an empty array in place of outside temperature

Delete THIS.

if I disable schedules entirely on infinitude, the integration will no longer connect. It might be an issue with the integration. See nebulous/infinitude#128 for discussion.

I successfully installed this component and the infinitude proxy. If I navigate to the http://<ip_addres>:[port] of the proxy server I see valid data coming from my system, which is reflected in my HA thermostat card.

If I try to change a setting from the HA thermostat card, say fan to high. I can see the change is made on the Infinitude "Comfort Profiles" page but the action never makes it to my actual thermostat unless I hit the "save" button on that Infinitude page. It seems to me the api call from HA isn't complete or isn't posting. The only infinitude/api/ instances I find in my logger, related to a specific change are:

Note: (the repeating dots are placeholders for actual data returned).

2020-03-08 09:43:45 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] http://x.x.x.x:x/api/status
2020-03-08 09:43:45 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] {'cfgem'..................

2020-03-08 09:43:45 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] http://x.x.x.x:x/api/config
2020-03-08 09:43:45 DEBUG (SyncWorker_7) [custom_components.infinitude.climate] {'data'..................................'status':'success'}

Is this normal? Am I missing something?

Component fails to start with the following error in my logs. I am running Home Assistant 0.114.4.

Error doing job: Future exception was never retrieved

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
    devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
  File "/config/custom_components/infinitude/climate.py", line 216, in __init__
    self.update()
  File "/config/custom_components/infinitude/climate.py", line 371, in update
    dt = datetime.datetime(
OverflowError: date value out of range

When trying to load HA at first, I get an error:
Error while setting up platform infinitude Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform SLOW_SETUP_MAX_WAIT, loop=hass.loop) File "/usr/local/lib/python3.7/asyncio/tasks.py", line 416, in wait_for return fut.result() File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/infinitude/climate.py", line 69, in setup_platform devices.append(InfinitudeZone(infinitude, zone["id"])) File "/config/custom_components/infinitude/climate.py", line 111, in __init__ self.update() File "/config/custom_components/infinitude/climate.py", line 134, in update self._occupancy = self._zoneStatus["occupancy"][0] # occupied, unoccupied, motion KeyError: 'occupancy'

Haven't been able to get this to work yet, in my environment I only have 1 zone, and from reading some other errors, it seems to be coded for multiple zones.

Any help is greatly appreciated

Hello, I'm looking to set the thermostat temperature (ie. Current Temperature) from a remote Z-wave temperature sensor which I have added to Home Assistant. My thermostat is not in an ideal location to appropriately obtain an accurate temperature for the heat zone, therefore I'd like to use the remote sensor to set the 'current' temperature for the zone. Is there any way to accomplish this?

Getting the following error in startup. I have configured with an IP / port in the configuration.yaml.

If i go to http://my-ip:3005/api/config - a valid response is returned. I only have 1 zone. I see a previous comment with this error has been closed, but the suggestion does not seem to fit here.

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 178, in _async_setup_platform await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT) File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for return fut.result() File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/infinitude/climate.py", line 79, in setup_platform zones = status["zones"][0]["zone"] KeyError: 'zones'

When trying to set the fan speed by using the thermostat card and setting "Fan mode" to medium, it would return an unknown value. I believe the thermostat requires an setting of "med" to change the speed to medium, but Home Assistant is sending "medium".

Fixed the issue by adding the lines 646 and 647 to the climate.py file.

def set_fan_mode(self, fan_mode):
    """Set new target fan mode.
    When set to 'auto', map to Infinity's internal value of 'off'
    """
      if fan_mode == FAN_AUTO:
          fan_mode = "off"

646 if fan_mode == FAN_MEDIUM: #added this and following line
647 fan_mode = "med"

Sometimes everything will stop working. No ability to set thermostat, read temperatures, etc. I noticed this would always happen overnight. I reboot HA, and everything works. After some looking through logs, it seemed to happen around 4:00 am. My router was set to reboot daily at 4:00 am. This leads me to believe there is some sort of issue when my router restarts where HA-infinitude loses contact with the infinitude server. Of course the simple workaround is changing the router setting. However, it might be worth looking into.

Infinitude expose the gas consumption in a different API
http://HOST/energy.json

I think it will be cool to create a sensor and expose that to home assistant

thanks

Would be nice if other attributes can be pulled in to the HA climate sensor, such as:

• Outside temperature (api/status/oat)
• Occupancy override
• blower CFM (api/status/idu)
• Heat Mode (heat pump vs aux heat)
• current Activity (home/away/sleep/wake - looks like it may be in code already, but not exposed in HA sensor)

Can the hold_until attribute be changed to match the full timecode format used by scheduled_activity_start and next_activity_start? I'm trying to use it in some templates, but cannot manipulate it using the typical methods (e.g. as_timestamp and these format codes) since it's just the time as a string.

It appears we are using incorrect logic when determining the HVAC_ACTION which in essence affects CURRENT_HVAC_* and how this is displayed in HA. It has gone mostly unnoticed since HA never really exposed this in the Climate Lovelace card until the recent climate overhaul.

We are in the height of summer now, so I've only calculated the test cases for when the mode is cool. I'm not sure if any of my below data will change during heat or auto. Note, I have a single zone carrier system.

• If the thermostat says "cooling..." that means that opmode=cooling and mode=cool and zoneconditioning=active_cool according to infinitude API.

• If the thermostat says "dehumidifying..." that means that opmode=cooling and mode=dehumidify and zoneconditioning=active_cool.

• If the thermostat is off, then opmode=off and mode=dehumidify (or presumably, the last used mode), and zoneconditioning=idle

So, this means that when the system is in a dehumidify state, it is actually being reported as CURRENT_HVAC_COOLING which simply shows as cooling in HA. But Cooling isn't the same as Dehumidify. I believe when it is in a dehumidify state, we should report this as CURRENT_HVAC_FAN (as there is no option for dehumidify in the constants). To do this, the logic being used around line 412 will need to take into account more than one field.

There's actually a "TODO" comment in line 417, so let's take this into account in any rework of this field when Fan is handled.

Looking for some help on config for fan mode and humidifier status. Since updating to 2023.5.1 these two sensors are creating error messages and showing as "Unknown" (there were only warnings prior). The log message is one I've searched for without ever finding an answer (hours). Here's a snippet of my config containing the two invalid entries related to infinitude:

template:
  - sensor:
      - name: "HVAC Fan Mode"
        unique_id: fan_mode
        icon: mdi:fan
        unit_of_measurement: ""
        state: >
          {{(state_attr('climate.infinity', 'fan_mode') )}}

      - name: "HVAC Current Activity"
        unique_id: current_activity
        icon: mdi:thermometer
        unit_of_measurement: ""
        state: >
          {{(state_attr('climate.infinity', 'current_activity') )}}

      - name: "HVAC IDU Modulation"
        unique_id: idu_modulation
        icon: mdi:thermometer
        unit_of_measurement: "%"
        state: >
          {{(state_attr('climate.infinity', 'idu_modulation') )}}

      - name: "HVAC Humidifier Status"
        unique_id: humid
        icon: mdi:thermometer
        unit_of_measurement: ""
        state: >
          {{(state_attr('climate.infinity', 'humid') )}}

The error messages are:

ValueError: Sensor sensor.hvac_fan_mode has device class None, state class None unit  and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: low (<class 'str'>)
2023-05-05 13:41:25.706 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved

I'm not sure how to define this item as string, if it's needed in the config or in the infinitude program. Any help is greatly appreciated.

Thanks.

Can you add "set_property" service to the integration as generic command to the thermostat?
This would follow the rest api of infinitude and allow for the users to setup any property of the thermostat

set_property

• entity_id: example: climate.house
• api_path: example "/api/config"
• api_comamnd: example: {"heatsource": "idu only"}

Hi

Is avaible any method to change heat source in HA? If not could you pls add?

Hi, I have no idea how to connect. I use standard configuration of yaml file.

What could be the problem?

Logger: homeassistant.components.climate
Source: custom_components/infinitude/climate.py:278
Integration: Klimat (documentation, issues)
First occurred: 09:07:41 (1 occurrences)
Last logged: 09:07:41

Error while setting up infinitude platform for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 281, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/infinitude/climate.py", line 122, in setup_platform
devices.append(InfinitudeZone(infinitude, zones[i]["id"], zone_name))
File "/config/custom_components/infinitude/climate.py", line 216, in init
self.update()
File "/config/custom_components/infinitude/climate.py", line 278, in update
self._current_temperature = float(get_safe(self.zone_status, "rt"))
TypeError: float() argument must be a string or a real number, not 'NoneType'

I have a two-story house with two infinity touch thermostats, furnaces, etc. Apparently these two systems aren't connected and both see themselves as "ZONE1" and use ID=1.

This same situation has been brought up by some Infinitude users in the past and the general consensus is to use two Infinitude proxies: nebulous/infinitude#94

This works until trying to use the HASS-infinitude integration.

When I add two climate items to my configuration.yml like this...

climate:
  - platform: infinitude
    host: IP
    port: 3000
    zone_names:
      - Downstairs

climate:
  - platform: infinitude
    host: IP
    port: 3001
    zone_names:
      - Upstairs

only the second one shows up in HASS as an entity:

In the picture above, I had commented out the "upstairs" to confirm that it's always the second one which is used.

Can HASS-infinitude be altered to assign unique entities to each Infinitude Climate instance to support multiple thermostats?

I have two, separate, Bryant HVAC systems (each with it’s own thermostat, each with it's own instance of Infinitude running). Before the re-write of this component I got them working by simply having two instance of this component running simultaneously, and using the custom zone name feature to differentiate the two in HA (as both systems are running on their own independent Zone 1).

Now that the zone naming has been deprecated they both come in as “climate_zone_1” and “climate_zone_1_2”, respectively. The issue is that whenever I restart my HA server they’ll switch entity names depending on which one HA sees first, which wreaks havoc on my automations. So, one time "climate_zone_1" will be my upstairs thermostat and "climate_zone_1_2" will be my main-level thermostat, but if I restart HA they'll spontaneously switch.