Has anyone figured out why the units report 65535 for iu_indoor_tmp when they are off, but not all the time?
I’ve had it when they’ve reported internal temps when not switched on, permanently - so I can track tmps - but recently it’s gone back to no report unless on…
If I manually query the devices with curl I get:
“iu_indoor_tmp”:“65535”
:\
I thought that too, until I put a temp sensor next to my units, and they were spot on for me. The bigger issue was that because the thermostat is on the unit, it tends to deviate from the room temperature. I ended up using external sensors, and adjusting the setpoint through HA on the fly.
alias: Fix Living Room Heat
description: ""
triggers:
- trigger: template
value_template: |2
{{ (((states('sensor.athom_tem_hum_sensor_b36078_temperature')|float) - (states('input_number.tempcurrent') | float)) % 0.5) | round(1) <= 0.1 }}
for:
hours: 0
minutes: 1
seconds: 0
conditions:
- condition: state
entity_id: input_select.hvacmode
state: heat
- condition: template
value_template: |-
{% set nw = now() %}
{% set last = state_attr('automation.fix_living_room_heat', 'last_triggered') %}
{{ 00 <= nw.hour < 24 and
(last is none or (nw - last).total_seconds() > 300) }}
actions:
- action: climate.set_temperature
metadata: {}
data:
temperature: >-
{{[7,[0,(state_attr('climate.livingroom', 'temperature')|float) -
(states('sensor.h5075_edd2_temperature') |float)]|max]|min +
(states('input_number.tempcurrent') |float)}}
target:
device_id: 2df0e44e4136f2a31b57bd20ac447148
My units were all reading a few degrees off - so I had to calibrate (much better now) - although per above, if they would continue reporting temps when they were “not switched on” (like they used to) that would be handy! :\
One thing I discovered last night is that some attributes get ignored if others are included. A case I observed last night was iu_pow_cons not returning when requested with iu_hmn_det. That said, after rereading your post I don’t think that’s your issue at hand.
I was of the impression that iu_internal_tmp wasn’t produced while the unit was off or in fan mode, but testing now I’m not observing that. I’m gonna give them some time and maybe play with resetting a breaker to see how the system behaves on a clean start without ever going outside of off/fan.
Hi,
I have a Shelly Switch to control the Power Unit Outdoor; basically I turn off if not needed
but the result when I turn off the integration show up : Failed to set up:
It means eaach time when I turn on I need to reload the Integration for each AirCon.
Any idea or suggestions?
Thanks for support
Can you check if the AC’s are getting a new IP address after coming back online? I would assume that they should come back by themselves once back online.
Hi,
ip still be the same
they donìt came back after return online. To have it I need to reload each time
Logger: homeassistant.config_entries
Source: config_entries.py:761
First occurred: 10:35:27 AM (3 occurrences)
Last logged: 10:35:27 AM
Error setting up entry local - CC4740096185 for fujitsu_airstage: Timeout while connecting to device for data {'device_id': 'CC4740096185', 'ip_address': 'xxx.xxx.x.xxx'} and options {'conf_turn_on_before_set_temp': False}
Error setting up entry local - A841F4031CD1 for fujitsu_airstage: Timeout while connecting to device for data {'device_id': 'A841F4031CD1', 'ip_address': xxx.xxx.x.xx'} and options {'conf_turn_on_before_set_temp': False}
Error setting up entry local - 106838E4DB61 for fujitsu_airstage: Timeout while connecting to device for data {'device_id': '106838E4DB61', 'ip_address': 'xxx.xxx.x.xxx'} and options {'conf_turn_on_before_set_temp': False}
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1268, in _wrap_create_connection
sock = await aiohappyeyeballs.start_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<6 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 122, in start_connection
raise first_exception
File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 73, in start_connection
sock = await _connect_sock(
^^^^^^^^^^^^^^^^^^^^
...<6 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 208, in _connect_sock
await loop.sock_connect(sock, address)
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 641, in sock_connect
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 681, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('xxx.xxx.x.xxx', 80)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/pyairstage/airstageApi.py", line 398, in async_call_api
async with self.session.request(
~~~~~~~~~~~~~~~~~~~~^
method,
^^^^^^^
...<3 lines>...
headers=kwargs.get("headers"),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
) as resp:
^
File "/usr/local/lib/python3.13/site-packages/aiohttp/client.py", line 1510, in __aenter__
self._resp: _RetType = await self._coro
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/client.py", line 779, in _request
resp = await handler(req)
^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/client.py", line 734, in _connect_and_send_request
conn = await self._connector.connect(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
req, traces=traces, timeout=real_timeout
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 642, in connect
proto = await self._create_connection(req, traces, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1209, in _create_connection
_, proto = await self._create_direct_connection(req, traces, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1581, in _create_direct_connection
raise last_exc
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1550, in _create_direct_connection
transp, proto = await self._wrap_create_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<7 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1291, in _wrap_create_connection
raise client_error(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host xxx.xxx.x.xxx:80 ssl:default [Connect call failed ('xxx.xxx.x.xxx', 80)]
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/fujitsu_airstage/__init__.py", line 104, in async_get
return await apiLocal.get_devices()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pyairstage/airstageApi.py", line 266, in get_devices
acInfo = await self.get_parameters(
^^^^^^^^^^^^^^^^^^^^^^^^^^
...<14 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/pyairstage/airstageApi.py", line 346, in get_parameters
response = await self.async_call_api(
^^^^^^^^^^^^^^^^^^^^^^^^^^
"POST", f"http://{self.ip_address}/GetParam", json=json.dumps(jsonPayload)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.13/site-packages/pyairstage/airstageApi.py", line 427, in async_call_api
raise ApiError(
f"No valid response after {count} failed attempt{['','s'][count>1]}"
) from error
pyairstage.airstageApi.ApiError: No valid response after 3 failed attempts
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/fujitsu_airstage/__init__.py", line 118, in async_setup_entry
await coordinator.async_config_entry_first_refresh()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 318, in async_config_entry_first_refresh
await self._async_config_entry_first_refresh()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 343, in _async_config_entry_first_refresh
await self._async_refresh(
...<3 lines>...
)
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 419, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 308, in _async_update_data
return await self.update_method()
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/fujitsu_airstage/__init__.py", line 106, in async_get
raise ConfigEntryError(
f"Timeout while connecting to device for data {entry.data} and options {entry.options}"
) from err
homeassistant.exceptions.ConfigEntryError: Timeout while connecting to device for data {'device_id': 'CC4740096185', 'ip_address': 'xxx.xxx.x.xxx'} and options {'conf_turn_on_before_set_temp': False}
You can consider to create an automation where if you turn on the Shelly device after it was ‘off’, it reloads the devices.
What version are you running and now long have you waited after restoring power?
turn on +/- more than 6h
If I understood your point: yeaap that’s was my first idea >> it seems is not restore “entry device”)
Fujitsu Airstage Version 1.7.1
Upgrade to 1.7.3, there have been changes for how connectivity is handled that may improve things for you
okkey updated to 1.7.3 done
Let’s see what happens 
Other minors :
1- it shows >> ASYG12KMCE , in real are KMCF series all 3 AC
2 - with KMCF there is the choice to setup wind direction ( I can imagine not easy to define):
It just shows what your unit is declaring it’s model as.
Sounds like your talking about swing mode. It’s there in the climate card, you may have to swipe the list to see all the options
1 - my label on one of my 3ac:
2 - i talking about up/down airflow direction
there are 6 positions numbered from 1 to 6
could be those ones?
those are F
If you go to developer tools and pull up the climate entity, there is a model attribute in there. That is the model identifier read verbatim from fujitsu. This integration is just showing the information provided
Yes, those are fan direction, which sounds like what you’re asking about
Let’s try in different way, :
1- the model attribute shoen in ha = KMCE is wrong
mine 3Ac are the series KMCF
I do not know which data info are used to be compared/match into “fujitsu database”
serial number??
Model id???
Please let me know thanks in advance
2- Airflow direction ( not Fan Speed)
where i can find this functionality?
Is implemented in this integration?
Thanks in advance for your reply
You keep saying the same thing and I keep giving you the same response. The model being shown from the integration is simply putting out what’s your unit is telling the integration. Period
Yes, that is swing direction, it’s next to fan speed on the climate entity
question:
“I do not know which data info are used to be compared/match into “fujitsu database”
serial number??
Model id???
Please let me know thanks in advance”
answer:
The model being shown from the integration is simply putting out what’s your unit is telling the integration
and before: If you go to developer tools and pull up the climate entity, there is a model attribute in there. That is the model identifier read verbatim from fujitsu. This integration is just showing the information provided
thanks John anyway, we talk “different language”
now it’s time to wish you and your family:
HAPPY CHRISTMAS AND NEW YEAR 
