Domotize a traditional air conditioner making it compatible Appthe HomeKits (via Homebridge)

14 minutes of reading
PURPOSES OF PROJET:
  • Domotize a traditional air conditioner (or an air conditioner, or an inverter) so that it can be used with Appthe HomeKit and Siri
  • Difficulty level: medium / high
  • Cost: reduced (<30 €)
CONCEPTS FACED:
SOFTWARE COMPONENTS USED:
PHYSICAL DEVICES USED:
  • An air conditioner / air conditioner / inverter controlled by infrared remote control
  • Un Broadlink RM Mini 3 (o Broadlink equivalent with infrared emitter)
procasting more suitable for:

Apple-200x200

Notes and disclaimer
  • qualsiasi modifica all'impianto elettrico dev'essere progettata ed effettuata da personale qualificato;
  • any changes implemented in probefore is a propersonal responsibility as well as a profirst risk and danger (the contents of the present page are purely educational);
  • any changes implemented in proprior to a device it voids the guarantee, quality approvals and certifications.
revision projet: 1.1

Mitzubishi MSZ-SF35VE3

Abstract

One of the most appreciated functions in home automation is to be able to remotely control, or "from afar", the functions of the profirst home.

Remote control is even more welcome when the element to be checked is related to air conditioning, which is winter (heating) or summer (cooling): the possibility of turning on / off a system in our absence, maybe automatically according to probefore GPS position ("when I leave work, turn on the air conditioner at 27 degrees, if the temperature in the room is higher").

While to control the control of independent heating systems in home automation the solutions are multiple and mostly economically affordable (as in the end, in fact, it is only to replace the thermostat), for the scope of cooling the situation it's very different.

Net of interesting solutions (see the SUMMER SPECIAL), the only alternative to insert an air conditioner in an organic home automation system is - in most cases - to replace it, by purchasing one natively domotic - which is not necessarily compatible, in any case, with the homogeneity we seek for our personal domotics.

This approccio it is therefore a loser, since it is very difficult to think of facing an important expense only to introduce a single additional functionality - as valuable as it is - especially if the air conditioner already present in the proenvironment is fully functional and appropriate to propurpose.

The purpose of this projet it is to demonstrate how, with a paltry expense, it can be piousnamehome automation a traditional conditioner in order to make it compatible and controllable through the final management tools of the world Appthe HomeKits (and, consequently, with Siri).

For this procast we will use an infrared emitter Broadlink RM Mini 3 and a modern air conditioner: the methods described here are essentially the same for practically all traditional air conditioners controlled by infrared remote control, even the most dated.

As listed in the beginning, you must be in possession of:

  • instantiate Homebridge working (running on Windows, macOS, Raspberry Pi: it makes no difference)
  • un Broadlink RM Mini 3 (o Broadlink equivalent model as long as it emits infrared, eg. mod. PRO)
  • a working conditioner and relative manual and an infrared signal control remote control.

It starts

Philosophy of projet

Let's start with a ragionamesimple.
Since:

  • Homebridge is recognized da Appi iOS (iPhone, iPad) as "BRIDGE compatible Apple HomeKit ”- therefore as a“ natively ”domotic element;
  • Homebridge (With appspecial plug-in) can send infrared signals means Broadlink;
  • the air conditioner it is controllable via infrared signals,

therefore, it is therefore possible to control the air conditioner via Appthe HomeKit, then control it with Siri and automate it with the rest of the home automation.

Analysis

Analyze the functionality of the air conditioner controllable by remote control

The conditioners are strange creatures. The models available on the market are the most disparate, some merely turn on and supply cold air until a given target temperature (ie the set temperature) is reached; others have adjustable fans, programs of automatic cooling and silent modes. Some also provide ventilation functions, others also dehumidification, not to mention functionality "Inverter”, Which allows the unit to be used not only for summer cooling but also for winter heating.

The present projet will domotize a modern unit of one of the best known brands, which presents the totality of the functionalities listed above. This is because, as we will see later, since not all of these functions of a conditioner are necessarily reproducible through home automation by Apple, it goes without saying that any elementary conditioner will be even easier to domotize based on the following.

We place ourselves directly in the most complex case: everything below will be easier to carry out.

Understanding the "air conditioner" accessory on Appthe HomeKits

Appthe HomeKits It provides the ability to configure an accessory called "air conditioner" such as to check the most classic of the features described above.

To be honest, this accessory it is far from perfect. It does not include, for example, the hypothesis (realistic) that the conditioner has adjustable fans (in terms of power, therefore of blowing) or of the adjustable wings. Nor does it consider the hypothesis of dehumidification, or ventilation, to name a few.

What he can do - and he does it well - is to turn on and adjust the air conditioner in hot or cold mode based on the chosen target temperature (via a slider at theapp"Home"), or set the automatic hot or cold mode, or simply automatic based on the ambient temperature. Obviously, it is also able to turn off the unit.

Conditioner on Appthe HomeKits

Without prejudice to the current limitations of the "Conditioner" accessory of Appthe HomeKits, waiting for any changes to the framework by Appwe will now see how to hit "the big goal", that is that of turning the unit on / off and adjusting the target temperature through what we have technically available.

Understanding the functional logicnameremote control

Premise: beyond the use of infrared (which we take for granted), not all remote controls work in the same way. On the whole, however, the behavioral model is always the same, that is what we are going to illustrate.

Nb. to address the remaining part of this projet / guide, it is necessary have the proown remote control, the manual of the profirst conditioner / air conditioner / inverter, as a reference to understand precisely what features are available.

The TV remote control has (usually) a functionnamento extremely trivial. Presents - simplifying - an on / off button, 10 keys related to numbers from 1 to 10, two keys for the volume (+ and -) and little else. Each key has a HEX code infrared specific. Once these few codes are captured, it will be enough to reprolast individually to simulate the original remote control. This approat the base of the procast relating to the domotization of a strip of colored LEDs.

The remote control of an air conditioner is a device a little more complex. Usually, the number of infrared HEX codes is equal to the number of combinations given by the various proselectable grams and modes; in essence: the pressure of a given key no proalways produces the same infrared HEX code, far from it. Code proin fact it is always linked to the combination of features in use at the given time.

We explain better. The following is the schematic image of the remote control taken as an example for this projet:

Air conditioner remote control

As can be seen from the image, this remote control has a button ("MODE") to scroll 6 operating modes (ventilation - dehumidifier - conditionnamento - heating and two other "specials"), two buttons to increase or decrease the temperature target (from 16º to 31º celsius), a key to scroll through the 5 air emission speeds ("FAN"), finally a key to scroll the 5 possible inclinations of the directional flaps ( "VANE").

Therefore, the HEX codes emitted by the remote control, assuming to keep the temperature constant (to simplify the temperaturenamento), are:

6 (operating modes) x 5 (speed) x 5 (inclinations) = 150 codes (possible combinations)

If we then consider that the possible temperatures are 14 (from 16 ° to 30 °), the possible codes are actually:

150 (codes) x 14 (possible temperatures) = 2100 (total codes)

Nb actually the remote control of this example no plans to set a temperature in the "ventilation" and "dehumidification" modes (the indicator disappears), but the above is to understand the concept and give an order of magnitude.

A conditioner usually it's stupid, in the sense that "he doesn't remember the last thing he was doing the last time he found himself on". This is why the remote control is able to send so many codes (and the air conditioner is able to understand as many): because pressing a key sends a code given by the combination of the settings currently set on the remote control + the change brought by the specific button pressed.

For example, sending the code corresponding to:

  • mode: conditionnamento
  • target temperature: 27 °
  • fan speed: 1
  • inclination of flaps: 1

rather than:

  • mode: heating
  • target temperature: 27 °
  • fan speed: 3
  • inclination of flaps: 5

has an effect immediate in the operational change of the unit, however it is operating previously.

All this complicates not just the achievement of our purpose, but the important thing is to understand the scenario well and appdescribe the following concept.

Identify infrared HEX codes useful for our home automation

First to ask yourself proproblem of capturing the codes, the healthiest thing is to jump on ours COLLABORATIVE ARCHIVE of infrared / radiofrequency codes. With any luck, you may already find the job done. Differently, don't forget (always through that page) after collecting yours, to send them to the archive!

Since we cannot realistically think to insert hundreds of infrared HEX codes into our configuration, È necessario reduce the circle to about twenty.

You will already have figured out that you're goingproit is practically impossible to completely change the functionality of the remote control.

What to do then?

Since the slider for adjusting the "Conditioner" accessory by HomeKit provides at most twenty target temperatures, at this point it will be necessary to capture and define 20 HEX codes relating to the various temperatures configured with the combinations that we prefer in terms of functionnameoperating system.

If for example "usually" the conditioner is used - only by varying the target temperature - with a maximum fan speed and a specific inclination, the 20 codes supplied by the remote control relating to the target temperature 20 will be selected. leaving the other variables (fan speed, inclination and, obviously, "conditional" modenament ") fixed as I chose them.

The remote control of our example provides, for speed and fans, an "auto" mode, able to perfect the conditionnameof the environment by varying, over time and automatically, the speed of the fans and the inclination. A good idea could be, instead of going to manually choose speed, inclination and maybe high factors, leave the "auto" setting for these variables to concentrate on capturing HEX codes related to various temperatures.

Installation and configuration

Install the "home" pluginbridge-broadlink-rm "

Installing the plugin is as easy as always, the command it's really trivial:

npm install -g homebridge-broadlink-rm

Nb. for more info on the installation there is a card apposita on inDomus. Once installed, it is always necessary provvedere to the basic plugin configuration.

Capture of the infrared codes supplied by the remote control

ATTENZIONE: in case you have a computer available Windows, as an alternative to the methods described in this paragraph, we recommend using one faster and more practical based on free TOOL "Broadlink Manager ”, described in detail in this guide.

Once the plugin is installed and performed the basic configuration on Homebridge, at theapp "House of Appthe iOS appa named switch will appear "LearnIR". Now, to acquire the infrared HEX codes of our remote control will be necessary position yourself in front of the Broadlink with Homebridge running (for command-line convenience rather than as a service) and activate that button.

At this point, the Broadlink will get it in "listening" of any infrared HEX codes and, once received, will display them on the screen via Homebridge. Then press the "LeanIR" button on theapp"Home" indication, point the remote control towards the Broadlink, press the key you wish to acquire and observe the terminal.

Here is an example taken from the Raspberry terminal when acquiring the "power" button of a Samsung TV:

Broadlink RM captures HEX codes

The HEX code - which is usually a string starting with "2600" - appare so:

2600460093951237123812381213121212131213111312381238123812121213121311131213121212381213111312131113121312121238121312381139113911391138123812000d050000

At this point, learned the proprocedure, acquire all the remote control codes based on the considerations amply illustrated in the paragraphs above.

Nb. It will be a good idea to save the infrared HEX codes captured on an Exel sheet, for future uses in the eventual variation of the configuration.

Definition of the Home configuration filebridge

Now it is necessary create a new entry presso the Home configuration filebridge in order to create at Appthe HomeKits a new "Conditioner" type accessory.

It is therefore necessary, in the configuration file, to insert between the accessories of the block - “platform""BroadlinkRM" - an accessory similar to this:

{
"name": "Condizionatore",
"type": "air-conditioner",
"minTemperature": 10,
"maxTemperature": 31,
"defaultCoolTemperature": 29,
"defaultHeatTemperature": 19,
"replaceAutoMode": "cool",

"data": {
  "off": "codice HEX infrarosso per lo spegnimento",
  "temperature16": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per la temperatura 16 gradi"
    }
  }
}

In the first block the operating parameters are definednamento basic accessory:

"name": "Condizionatore",
"type": "air-conditioner",
"minTemperature": 10,
"maxTemperature": 31,
"defaultCoolTemperature": 29,
"defaultHeatTemperature": 19,
"replaceAutoMode": "cool"

where:

"name"defines the name of the accessory at theapp Appthe "House"
"type"defines the type, for theappanointed "air-conditioner "
"minTemperature” / “maxTemperatureindicate to the accessory what the operating range of the slider is for temperature regulation
"defaultCoolTemperature"/"defaultHeatTemperature"indicate the default temperatures for cold and heat
"replaceAutoMode" indicates to the plugin which one prowire activate automatically if "Auto" mode is selected on theapp "Home", if cold (cool) or hot (heat)

In the second part, or in the block “date", Nested you define the codes for switching off (" off ") and then many values ​​as there are temperatures of the operating range (of the slider at" Home ") indicated with the parameters" minTemperature "and" maxTemperature "above:

"data": {
  "off": "codice HEX infrarosso per lo spegnimento",
  "temperature16": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per la temperatura 16 gradi"
  }
}

The functionnamento appthen the wipe:

Conditioner with Broadlink and Homebridge - Hybrid configuration

Understanding the "pseudo-mode" parameter

At this point it is necessary to understand meaning and purpose of the "pseudo-mode" parameter.

This parameter serves to make theapp Appthe "House" if a given temperature must be interpreted (in home automation) as a cooling or heating action, if the unit is appanointed with function Inverter.

Case A:
traditional conditioner (without prowinter heat production)

Let's say that what we are domotizing is a traditional conditioner able to supply alone fresh air with target temperatures from 18 ° to 29 °.

First, the configuration block appwill appear as follows:

"name": "Condizionatore",
"type": "air-conditioner",
"minTemperature": 18,
"maxTemperature": 29,
"defaultCoolTemperature": 18,
"replaceAutoMode": "cool"

The blocks related to the definition of the temperature they will all be similar to the following:

"data": {
  "temperature16": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per la temperatura 16 gradi in raffreddamento"
  }
}

Since the unit is capable just to cool down, any temperature adjustment will then send codes to set the conditionnamecold and theapp "Home" will react considering the room and the "cooling" unit.

Case B:
conditioner Inverter (With prowinter heat production)

It is probefore the case concerning the unit we are domotizing with this projet, or one able to deliver cold in summer and heat in winter.

Now, there are two ways:

  • define in configuration one accessory able, through sliders, to send in a part of the range of the target temperature adjustment slider cooling codes, while in the remaining part winter heating codes;
  • define in configuration two twin accessories (with different names, of course), one with all the temperatures (and relative codes) that affect summer cooling and one with all those related to winter heating.

Let's start with the second road. In this case, it will be sufficient to indicate in the first accessory all the temperatures (and relative cooling codes) and "pseudo-mode": "cool", while the second all the temperatures (and relative heating codes) with "pseudo-mode": "heat". Naturally also the definition blocks of the two accessories (for the parameters like "minTemperature" and "maxTemperature" etc.) will have to be adjusted accordingly.

In the first case - the one we prefer - it will be necessary to analyze usage habits to carry out the configuration hybrid.

The truth is that both cooling and heating are functions that, if you look at it, are always used by setting a limited range of temperatures during use.

For example, for the conditioner used as an example in this procastings are imposed by the user target temperatures from 25 ° at 30 ° in summer (cooling) and from 16 ° at 24 ° in winter.

With the "hybrid" configuration it will therefore be possible to indicate different codes for different conditions as follows:

Target temperatureTipo di codice HEX“pseudo-mode”
16 °HEX code for heating at 16 °heat
17 °HEX code for heating at 17 °heat
18 °HEX code for heating at 18 °heat
19 °HEX code for heating at 19 °heat
20 °HEX code for heating at 20 °heat
21 °HEX code for heating at 21 °heat
22 °HEX code for heating at 22 °heat
23 °HEX code for heating at 23 °heat
24 °HEX code for heating at 24 °heat
25 °HEX code for cooling at 25 °cool
26 °HEX code for cooling at 26 °cool
27 °HEX code for cooling at 27 °cool
28 °HEX code for cooling at 28 °cool
29 °HEX code for cooling at 29 °cool
30 °HEX code for cooling at 30 °cool

In conclusion, a complete configuration for such a scenario it is the following:

{
"name": "Condizionatore",
"type": "air-conditioner",

"minTemperature": 16,
"maxTemperature": 30,
"defaultCoolTemperature": 25,
"defaultHeatTemperature": 16,
"replaceAutoMode": "cool",

"data": {
  "off": "codice HEX infrarosso per lo spegnimento dell'unità",
  "temperature16": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 16°"
  },
  "temperature17": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 17°"
  },
  "temperature18": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 18°"
  },
  "temperature19": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 19°"
  },
  "temperature20": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 20°"
  },
  "temperature21": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 21°"
  },
  "temperature22": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 22°"
   },
  "temperature23": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 23°"
  },
  "temperature24": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 24°"
  },
  "temperature25": {
    "pseudo-mode": "heat",
    "data": "codice HEX infrarosso per riscaldamento a 25°"
  },
  "temperature26": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per raffreddamento a 26°"
  },
  "temperature27": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per raffreddamento a 27°"
  },
  "temperature28": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per raffreddamento a 28°"
  },
  "temperature29": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per raffreddamento a 29°"
  },
  "temperature30": {
    "pseudo-mode": "cool",
    "data": "codice HEX infrarosso per raffreddamento a 30°"
  }
}
Temperature reading

Obviously what has been stated so far allows us to check the unit's settings, but no allows us to "read" the temperature of the environment in which the unit is installed. This information it's vital in case of automations of the type "when I leave work I activate the air conditioner at 27 degrees if the temperature in the house is greater than 30 degrees".

Actually this powerful home plug-inbridge proalso sees to solving this proBlema.

It is in fact possible to indicate to the accessory (and therefore to HomeKit) the detected temperature in three modes:

  • indicating to the plug-in a fixed temperature (this of course it will not be a real read but only a fixed value - zero utility);
  • indicating to the plug-in where to read it (on file, if some other tool is able to write on text file);
  • indicating to the plug-in a MQTT telemetry.

In the first (useless) case it is sufficient to indicate in the block defining the characteristics of the accessory the following parameter:

"pseudoDeviceTemperature" : X

Where "X" will be the (fixed) value to be indicated. The default (where not indicated) is 0.

To implement the second case, it will be sufficient to indicate:

"temperatureFilePath": path,
"temperatureUpdateFrequency": X

Where is it "path"Will be the path and the name of the file (text) from which to acquire the temperature and" X "the number of seconds to check for variations (the default is 20).

Finally, the third case, the most functional and recommended one: read a temperature directly from a sensor with an interface MQTT, for example a Sonoff TH-10 (or TH-16) equipped with temperature sensor and - for MQTT support - riproprogrammed Sonoff-Tasmota.

In the case of the availability of a Sonoff TH, consulting the topic MQTT:

tele/Sonoff/SENSOR

it will be possible to survey the ambient temperature real-time (obviously the sensor must be in the same room / environment as the air conditioner) via the json payload it supplies.

At this point the integration will therefore be sufficient, in the block defining the accessory, of the following parameters:

"mqttURL": "mqtt://xxx.xxx.xxx.xxx",
"mqttUsername": username,
"mqttPassword": password,
"mqttTopic": topic

where:

"MqttURL"broker's url
"mqttUsername”username at the broker
"MqttPassword"user password at the broker
"MqttTopic" topical mqtt from which to draw on the data (eg, as above, “tele /Sonoff/SENSOR")

Obviously the use of an MQTT topic does not apply only to i Sonoff TH, but for any thermal sensor with MQTT interface.

Implementation of MQTT telemetry opens at many other integration scenarios, for example the transformation of the reading from another source to an MQTT telemetry topic using Node-RED.

Nb We also recommend to read carefully also the guide dedicated to the theme of configuration of the MQTT components in the profirst home automation.

Configuring a virtual fan

Give the intrinsic limits to the accessory "Conditioner" of Appthe HomeKits, It is not possible to wire the simple ventilation function in the configuration of this accessory.

To remedy this proBlema is possible - always via the "home" pluginbridge-broadlink-rm ”- take advantage of the“ Fan ”accessory features. This is the subject of a procast to itself, that found here on inDomus.

Configuration precautions

Before feeding any configuration file to Homebridge, remember always to verify its syntactic correctness at JSONLint.

For all the detailed information on the characteristics and configuration parameters of the "Conditioner" accessory via the "home" pluginbridge-broadlink-rm ”refer directly to the online guide.

Device configuration Broadlink

We are almost done, but before commanding our air conditioner through the combined use of Home Assistant and of the component appena configured, it is necessary that the Broadlink is already present on ours Wi-Fi. If this step has already been done before, it is possible profollow over.

To make the infrared emitter enter (and remain) inside yours Wi-Fi just download theappe-Control reporting for Android o for iOS and follow the instructions.

In case of difficulty, it is available the manual in Italian.

utilization

At this point the accessory è pronto. Beyond being used manually (as seen in the configuration phase), it can be commanded by Siri in a natural way, for example “Adjust the temperature degrees in 20", Or"Turn off the air conditioner"

Obviously, this accessory it can also be used in automations di AppHomeKits, for example, switch on at a certain time rather than adjust the target temperature when leaving the workplace and much more.

For any questions (and this projet raises it many) the inDomus community is on the FORUM, on Facebook, on Telegram.


Logo Appthe HomeKitsATTENZIONE: remember that there is on our FORUM community an ad hoc section dedicated to Appthe Homekits, for any doubt, question, information on the specific merit of these components.


telegram

Stay up to date through ours Telegram channel!