Fujitsu FGLair (fglair-eu): 403 Forbidden when sending local_reg POST requests

[antaflos]

Using AirCon 0.3.10 on Home Assistant 2022.3.5, running Home Assistant OS 7.5 in a VM.

We have five Fujitsu air conditioners (3x ASYGO7KMCC, 2x ASYG12KMCC, not sure if that matters), each equipped with a WiFi module which Fujitsu lists as UTYTFSXW1. I can control them using the FGLAir android app so I assumed the AirCon add-on would work, but it seems these WiFi modules expect different POST requests?

The configuration is as follows:

log_level: DEBUG
mqtt_host: 192.168.1.205
mqtt_user: iot
mqtt_pass: verysecret
port: 12345
app:
  - username: redacted@example.com
    password: alsoverysecret
    code: fglair-eu

When starting the logs show this, over any over again:

D0317 22:26:56.587  notifier.py:112] [KeepAlive] Sending POST http://192.168.2.17/local_reg.json {"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}
D0317 22:26:56.588  notifier.py:112] [KeepAlive] Sending POST http://192.168.2.20/local_reg.json {"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}
D0317 22:26:56.588  notifier.py:112] [KeepAlive] Sending POST http://192.168.2.18/local_reg.json {"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}
D0317 22:26:56.588  notifier.py:112] [KeepAlive] Sending POST http://192.168.2.16/local_reg.json {"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}
D0317 22:26:56.589  notifier.py:112] [KeepAlive] Sending POST http://192.168.2.19/local_reg.json {"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}
D0317 22:26:56.603  universaldetector.py:234] no data received!
D0317 22:26:56.603  universaldetector.py:271] no probers hit minimum threshold
E0317 22:26:56.603  notifier.py:117] [KeepAlive] Sending local_reg failed: 403, 
D0317 22:26:56.604  universaldetector.py:234] no data received!
D0317 22:26:56.604  universaldetector.py:271] no probers hit minimum threshold
E0317 22:26:56.604  notifier.py:117] [KeepAlive] Sending local_reg failed: 403, 
D0317 22:26:56.605  universaldetector.py:234] no data received!
D0317 22:26:56.605  universaldetector.py:271] no probers hit minimum threshold
E0317 22:26:56.605  notifier.py:117] [KeepAlive] Sending local_reg failed: 403, 
D0317 22:26:56.605  universaldetector.py:234] no data received!
D0317 22:26:56.605  universaldetector.py:271] no probers hit minimum threshold
E0317 22:26:56.605  notifier.py:117] [KeepAlive] Sending local_reg failed: 403, 
D0317 22:26:56.607  universaldetector.py:234] no data received!
D0317 22:26:56.607  universaldetector.py:271] no probers hit minimum threshold
E0317 22:26:56.608  notifier.py:117] [KeepAlive] Sending local_reg failed: 403, 

(Note: the air conditioners, as well as almost all other "smart" devices, are in their own VLAN and subnet, 192.168.2.0/24, and Home Assistant has an interface in both 192.168.1.0/24 and 192.168.2.0/24)

Each WiFi module is reachable via HTTP on port 80 from a web browser or curl, and returns a 404, which I understand is expected.

And indeed, when sending the POST request manually with curl I get a 403 as well:

$ curl -v -d'{"local_reg": {"ip": "192.168.1.113", "notify": 1, "port": 12345, "uri": "/local_lan"}}' http://192.168.2.19/local_reg.json
*   Trying 192.168.2.19:80...
* TCP_NODELAY set
* Connected to 192.168.2.19 (192.168.2.19) port 80 (#0)
> POST /local_reg.json HTTP/1.1
> Host: 192.168.2.19
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 87
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 87 out of 87 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0

Sending a POST requests with empty data results in a 400 Bad Request, and sending GET to http://192.168.2.19/local_reg.json just returns a 404.

Could it be that the UTYTFSXW1 WiFi module is not compatible with this add-on? Or am I doing something wrong?

I'll gladly provide any additional information or data you may require.

[meichthys]

I'm also seeing this with a very similar setup (fglair-eu). I also am using separate vlans (homeassistant has an interface on each).

[meichthys]

After a little more investigation, it does seem to be the Vlan/multiple NIC situation on Homeassistant that is causing the issue. If you disconnect or disable all the NICS not on the same network as your AC units, then the setup will probably work (it did for me). It continued to work even after re-enabling the NICs but i suspect that it will stop working after a HA reboot.

[antaflos]

@meichthys Interesting, I will try that and report back, thank you for the suggestion. But I wonder what the cause behind that behavior could be and why having Home Assistant be part of multiple VLANs would result in HTTP requests not working as expected.

[meichthys]

I think it has to do with the route the add-on traffic is taking. There's no fine grained control that allows us to tell home assistant to use a specific interface for an add-on, but we do have some options here that allow us to specify which vlan to use for integrations. If i choose the vlan which contains my AC unit, then it seems to work, but there may be side effects of changing that setting, so be careful! https://my.home-assistant.io/redirect/general/

[antaflos]

Seems like the AC units only accept the POST request when the IP in the data payload {"local_reg": {"ip": "...", ... } is in the same subnet as the AC units themselves, otherwise they respond with the 403 Forbidden. It does not seem to matter if the POST request actually originates in the same subnet or not. The following POST request, sent from my workstation in 192.168.1.0/24, results in a 202 Accepted:

curl -H"Accept: application/json" -H"accept-language: en"  -v -d'{"local_reg": {"ip": "192.168.2.100", "notify": 1, "port": 12345, "uri": "/local_lan"}}' http://192.168.2.18/local_reg.json
*   Trying 192.168.2.18:80...
* TCP_NODELAY set
* Connected to 192.168.2.18 (192.168.2.18) port 80 (#0)
> POST /local_reg.json HTTP/1.1
> Host: 192.168.2.18
> User-Agent: curl/7.68.0
> Accept: application/json
> accept-language: en
> Content-Length: 87
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 87 out of 87 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 202 Accepted
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0

I have not had any success getting the AirCon addon to work by selecting a different adapter in https://my.home-assistant.io/redirect/general/ so at the moment it seems I must reconfigure the Home Assistant VM to be "home" in the IOT VLAN/subnet 192.168.2.0/24 instead of the default subnet 192.168.1.0/24 (either that or moving the AC units from the IOT subnet to the default subnet).

Consequently I suggest the following improvement to the AirCon module: make the IP address used in the POST data payload optionally configurable in the AirCon module so that a user with segregated VLANs can set the correct one to send to the AC unit.

[meichthys]

I can also report that changing the adapter in homeassistant doesn't seem to work consistently. I'm not sure why it seems to work sometimes and not others.

[louisvangeldrop]

Where can I find the rest-api-specs of the hisense/fglair airco's? I have seen your curl-statements, but how did you discover/find these statements? Dos Hisense has a software-api guide?

[antaflos]

@louisvangeldrop I just looked at the debug log output (set log_level: DEBUG in the Options YAML). Don't know of any API specs but they must exist somewhere, otherwise @deiger probably wouldn't have been able to write this addon.

[louisvangeldrop]

Thx for the explanation. I want to use the api in order to integrate the wifi-module into a nodejs-module (ioBroker), A straightforward document explaining what is to be done would help.

[vyruz1986]

I've been looking into this. Just leaving some notes here in case it might help someone:.

The local IP is determined in this method: https://github.com/deiger/AirCon/blob/a30f6092268119079aa9bda2dc984db8c75c6f29/aircon/notifier.py#L48-L57

I tried copying that method into a test script and running it inside the aircon container on my HA instance, but couldn't figure out a way to get it to return my 2nd IP address. It keeps returning my primary IP which is in another VLAN than the AC devices I have. Note that running ifconfig inside the aricon container does show an interface with my 2nd IP, so it is available to the container.

Reading this seems it's quite hard to implement a robust way in python to discover IP addresses...

[vyruz1986]

I've made a PR with a workaround (the ability to specify the IP address in configuration) to this issue, tested it on my setup and it fixed the communication with the AC units.

[kevtuning]

Hi @vyruz1986 ,

I get your point but in my setup, my HA hasn't an IP in each VLAN... (and honestly I don't understand why)

My HA is in a "internal" VLAN and all my IOT stuff are in an "IOT" vlan and I simply manage Firewall rules to allow "internal" to go to "IOT" and drop the reverse connections (with an exception for the MQTT ports)

I have exctly the same issue ... The Aircon is not replying to a different subset.... and I absolutely don't know how to workaround it.

[vyruz1986]

Hi @vyruz1986 ,

I get your point but in my setup, my HA hasn't an IP in each VLAN... (and honestly I don't understand why)

My HA is in a "internal" VLAN and all my IOT stuff are in an "IOT" vlan and I simply manage Firewall rules to allow "internal" to go to "IOT" and drop the reverse connections (with an exception for the MQTT ports)

I have exctly the same issue ... The Aircon is not replying to a different subset.... and I absolutely don't know how to workaround it.

I would also rather not give my HA instance an IP in the IOT VLAN, but to work around this issue with the Fujitsu wifi module requirement, it's the best option I see (better than putting the aircon units in a non-IOT VLAN and giving them, and any malware that might infect them, access to a host of other services on that same VLAN).

Perhaps there's another solution on a network level (Something like port forwarding, but then for IP's, so you could say in your router for example that when a request is received on some IOT VLAN IP, it should be forwarded to another IP on another VLAN, not sure if something like that exists, at least in my router I don't see an option for it) which could provide a solution to this, but that goes beyond the scope of this repository I think.

Ideally we should be able to 'configure' the Fujitsu wifi modules to allow requests from other networks than their native one, but I'm not going to wait for Fujitsu to make this configuration option available. Perhaps stating the obvious here, but in general this whole solution is a quite 'hacky' way of integrating a 'smart' product in a way it was never intended by the manufacturer, I also see a very real risk in Fujitsu pushing a future firmware option which breaks/removes this integration completely.

[kevtuning]

Thanks for the explanation @vyruz1986 .

I have a stupid question/idea.

Is the Aircon trying to reply to HA or to the MQTT server ?

If it's MQTT, we could use a MQTT bridge in the IOT vlan in order to forward the messages to the HA MQTT server....

[vyruz1986]

@kevtuning So this repository provides an 'add on' for HA, it sets up communication with the aircon units, then publishes correponding messages on the MQTT broker, which then get picked up by HA.

To answer your question: Neither, the software from this add-on (more specifically the web server it sets up to provide the commands to the aircon units) is the only part that communicates with the aircon units. Now, it depends on how you have HA set up (see this link for details on the various installation methods), if you run the OS/supervisor version, then any add-ons (including this one) are run in docker containers on the HA host OS. If you run HA in a docker container itself, HA lacks the add-on function, because itself runs in docker and thus cannot start addons as additional docker containers. In that last case you would need to run addons like this in separate docker containers (or natively if the addons supports that) which you manage yourself. This latter case is also an option if you run HA supervised/OS, but it's more cumbersome as you would have to maintain the addon yourself, instead of using the nice HA features to perform common tasks like updates, backups, etc...

[kevtuning]

My idea was to use a MQTT bridge in the IOT Vlan in combination with your workaround PR.

In the IP you specify, you put the IP of the MQTT bridge who is tranferring packets to HA.... so for HA, it's transparent...

(it's purely theoretical, I am not an expert at all in mosquitto etc... )

It may work no ?

[vyruz1986]

@kevtuning What do you mean by 'MQTT Bridge'?

If you want to run this software standalone from HA in your IOT VLAN, you would not even need the PR I made, since the automatic IP detection would only detect whatever IOT VLAN IP you gave the standalone instance.

[kevtuning]

I was referring to this: http://www.steves-internet-guide.com/mosquitto-bridge-configuration/

[vyruz1986]

I see. I don't think that's necessary since there's no requirement for the MQTT broken to be available on the IOT VLAN, only the application from this repository needs to run on the IOT VLAN, you could perfectly run this software on the IOT VLAN and have it connect to the MQTT broken on another VLAN (where also HA is running). But as I mentioned this way of running things (same as with the MQTT bridge you suggest) would be a lot more hassle compared to setting this up as an HA addon.

[SlasherF]

I ran into the same problem, only with the Docker version. Here I was able to solve it by creating a macvlan network (in Docker) in the same subnet as the air conditioners. I don't know if something like this is also possible within the Home Assistant OS.

[kevtuning]

I've made a PR with a workaround (the ability to specify the IP address in configuration) to this issue, tested it on my setup and it fixed the communication with the AC units.

Hi @vyruz1986,

I finally got your solution tested...

And it's quite strange... Everything seems like to communicate (I am able to ping from the HA command line...) .... but the Entity is still noted as Unknown in HA...

I receive MQTT message "Online" but no answer when I try to change the status for example...

Any thoughts ?

[kevtuning]

Wow after letting it like that for some hours and a tenth add-on restart it works!

[Misterbianchi]

Can someone make a guide on how to resolve this ?

[ceemjay]

I have opened an issue as I am struggling to get the add-on working with my Fujitsu aircon unit so I would really appreciate a guide too or some assistance to get it working.