Fujitsu
Hey all,
was not able to follow along last weeks and need to go trough it and test it in detail.
But already thank you all for contributing data and workarounds and especially @danielkaldheim for that integration!!
So, for everyoneâs info, the Fujitsu AC technical chaps passed on the âblocked IPâ query to their âHQâ (as they donât run the infrastructure security.
The reply Iâve had back is:
*âThis IP address has been blocked by the security department.*
*The reason for the block is that we have detected unusual and unauthorized access to AIRSTAGE Cloud-Light.*
*For security reasons, it is not possible to unblock the IP addresses that have been blocked for unauthorized access.â*
Iâve agreed it was unusual, but not malicious and asked if that can be appealed/challenged (obviously it can be unblocked, but I suspect process/default is âwe wonât unblockâ.
@danielkaldheim - I would urge you âremoveâ the cloud integration option (force local only) from your integration so that this doesnât trip up others (I know you got blocked, and I see at least one other!)
Hey all,
Sorry for being not fixing issues lately.
Incredibly poor answer from Fujitsu AC!
I have now fixed the Target Temperature issue and removed Cloud integration option from the config flow.
Fix working ok for me in some ways (I.e. the randomly high temperature isnât displayed)
However, my HVAC automation sets a temperature through a service call irrespective of the mode
In fan mode it generates an error and the automation stops
I would suggest that it accepts the temperature call but either silently drops it and puts an info log entry?
(Separate issue I need to look into but the service call to change temp and mode doesnât work)
Hi,
thanks for feedback!
Home Assistant have a method for entities to report what features is supported, so I disabled that feature when the mode is fan only, since that made most sense to me. Thats probably why you get an error when you setting temperature. I will digg in the home assistant core repository to see what other integrations are doing about this case.
def supported_features(self) -> ClimateEntityFeature:
"""Return the list of supported features."""
supported_features = ClimateEntityFeature.FAN_MODE
if self.hvac_mode != HVACMode.FAN_ONLY:
supported_features |= ClimateEntityFeature.TARGET_TEMPERATURE
I saw your github issue, and I have the same problem. The service âSet Target Temperatureâ is home assistant default climate service, so I guess this may be Home Assistant issue and not my implementation.
But I will investigate and see if there is anything I have done or need to do to fix this.
Hi All,
Great work whoever has pulled this together. I was starting to think I was the only guy on earth with HA and Airstage AC!
Can I ask if you all see the your Fujitsu AC units wifi dongles still broadcasting their SSIDs even after being added to you wireless network .i.e AP-WH3E-10XXXXXXXXXX? Is there any way to disable this. Surly after they have been onboarded the internal SSID should be disabled until put into some sort of discovery mode.
We have 6 units and itâs making SSID broadcast noisy.
I have tried to contact Fujistu support via the web and phone and have got no help at all.
Sorry this is off topic but I feel like this is the only place I might get an answer from techinically minded people.
Mine still broadcast SSID and similarly find it annoying!
They stay broadcasting. Probably because if they lost connectivity (mine have) itâs a PITA to get them back on LAN. At least the SSID has WPA - because when on the LAN you can just hit the IP and change WLAN creds without any auth!
Yeah same here with the SSIDs. Very annoying.
So, I updated HACS integration today, as I turned heating on one unit and my home temp list entry showed 605C.
After update, the Indoor temp shows âUnavailableâ - but on the climate unit display itself in HAS I see:
Removed the integration (as originally I did a manual download, prior to HACS) and reinstalled.
One AC was on heat at the time, and it returned 9 sensors - all others returned 8.
Once I turned the heating unit off, and switched others back on, and reloaded each unit after a couple of minutes, they returned 9 sensors - so the indoor temp is being pulled when one unit is on another mode?
Did this happen when you updated to v1.1.3? Do you get any errors in the Home Assistant log?
Yes, itâs latest.
I have checked logs but canât see anything - do I need a debug setting on?
This morning, one unit on heat, and the others are 605C
Although the custom_components folder manifest file shows 1.1.0 (but I checked github and thatâs the same also!) So I think Iâm on 1.1.3âŠ
Querying a unit in 65535 state (mode clashing, it was auto, other unit heating)
{"value":{"iu_wifi_led":"0","iu_af_inc_hrz":"0","iu_af_inc_vrt":"4","iu_set_tmp":"200","iu_indoor_tmp":"65535","iu_outdoor_tmp":"5800","iu_hmn_det":"1","iu_main_ver":"E101V03P00L02-1","iu_eep_ver":"E000V01P00L01-1","iu_has_upd_main":"1","iu_has_upd_eep":"1","iu_fld_set80":"65535"},"read_res":"ack","device_id":"MACHERE","device_sub_id":0,"req_id":"","modified_by":"","set_level":"03","cause":"","result":"OK","error":""}
The unit heating:
{"value":{"iu_wifi_led":"0","iu_af_inc_hrz":"0","iu_af_inc_vrt":"4","iu_set_tmp":"235","iu_indoor_tmp":"7000","iu_outdoor_tmp":"5900","iu_hmn_det":"1","iu_main_ver":"E101V03P00L02-1","iu_eep_ver":"E000V01P00L01-1","iu_has_upd_main":"1","iu_has_upd_eep":"1","iu_fld_set80":"65535"},"read_res":"ack","device_id":"MACHERE","device_sub_id":0,"req_id":"","modified_by":"","set_level":"03","cause":"","result":"OK","error":""}
Actually, thinking out loud, could you have another (custom) binary sensor for âMode Clashâ (or a new âClashâ mode, which isnât user selectable) - and if a unit reports 65535 then you can flag back that a unit is on, but ânot workingâ?
I did some improvements on the api side of the code. I should now get latest good result instead of 65535 error. Hopefully this will help.
Did you open the Airstage app with a device that is in 65535 state?
A binary sensor with clash or error state could be a good idĂ©a. Iâll see if I get some free time tonight to tinker with this.
Thanks for pointing out the manifest file Peter, I forgot to update. Should be ok now.
Thanks for this integration, i got a split ASYG18KMTA with UTY-TFSXH3 adapter and it working perfect.
I was searching how to hide the SSID from the adapter and i read in this topic that i am not the only one who have this problem.
Iâve noticed when a device goes into clash state, the temp disappears from the UI entirely.
Not sure if thatâs intentional?
Also when I have a device in that state, and try to turn it over to match, I get an error - but it then works.
Iâll screen grab in a bit unless it only happened as I updated to the new version when a unit was in clash
[UPDATE] - here we are - when a unit goes into âclashâ the âcurrentâ temp vanishes, ala this:
If you then try to set the temp, or change mode, this error appears
Also getting a LOT of these in logs:
Error processing parameter: 'iu_af_dir_hrz' is not a valid ACParameter
Error processing parameter: 'iu_af_swg_hrz' is not a valid ACParameter
Error processing parameter: 'iu_hmn_det_auto_save' is not a valid ACParameter
Error processing parameter: 'iu_min_heat' is not a valid ACParameter
Error processing parameter: 'iu_err_code' is not a valid ACParameter
Error processing parameter: 'iu_demand' is not a valid ACParameter
Error processing parameter: 'iu_fltr_sign_reset' is not a valid ACParameter
Error processing parameter: 'iu_model' is not a valid ACParameter
Error processing parameter: 'iu_af_dir_hrz' is not a valid ACParameter
Error processing parameter: 'iu_af_swg_hrz' is not a valid ACParameter
Error processing parameter: 'iu_hmn_det_auto_save' is not a valid ACParameter
Error processing parameter: 'iu_min_heat' is not a valid ACParameter
Error processing parameter: 'iu_err_code' is not a valid ACParameter
Error processing parameter: 'iu_demand' is not a valid ACParameter
Error processing parameter: 'iu_fltr_sign_reset' is not a valid ACParameter