Replacing the IHC Controller with ESPHome

As you know the IHC controller is no longer being produced, and if your existing controller dies you are in bad luck if you can not find and buy a used one.

I have been thinking about what to do when this happens. (Notice the “when” not if - all electronics dies at some point!). That is what this post is all about.

Before you get too exited, this post is a proof of concept - I have not yet replaced my own IHC controller with ESPHome.

The IHC Controller has 2 ways of interfacing - the wireless and the wired:

Wireless

The wireless communication of the IHC Controller is proprietary and I have not been able to find any useful information about it. In an emergency you can connect IHC wireless device without the controller, but then there is no way of controlling them from Home Assistant.

So I have decided to replace all my IHC wireless devices with zigbee, and I am almost done.

I have been using zigbee for many years, and it has been very stable. (Zigbee2mqtt) If I was starting today Matter/Thread would probably be my choice, but today you still have a lot more devices available for zigbee.

Another bonus it the binding feature in zigbee where you can bind a button to control other zigbee devices like light, and it will work even if the zigbee coordinator or home assistant is not available. (Matter also have the binding feature). I most places I can now turn on and off the light without home assistant.

Wired IHC Modules

There are several IHC Wired modules for both input and output, and both 24v and 230v. The input/output modules connect to an data input/output port on the IHC Controller. This data signal is standard TTL 5v levels, and you can find my description about the IHC wired protocol here (a 10 years old post!)

I also have an old post about how to do the IHC protocol on an arduino/esp8266 here. This is also the base for the code for ESP32

I would like to have one single device to handle all my IHC input and output module and thereby replacing the IHC Controller. ESPHome is the easiest way to do stuff like this. I have made 2 ESPHome Components for encoding and decode the IHC data. The encode and decode works like a multiplexer - you have one signal in/out and up to 16 signals in/out.

ESPHome

You can find the code for the ESPHome ihc encoder and decoder here:

The ESPHome ihc encode and decode components on github

The decoder is for connecting IHC input modules, and the encoder is for connecting IHC output modules.

Include the ihc_encoder and ihc_decode components like this in your ESPHome yaml:

external_components:
  - source:
      type: git
      url: https://github.com/dingusdk/ihc_de_encoder
    components: [ ihc_encoder,ihc_decoder]   

For the decoder use:

ihc_decoder:
  - id: my_ihc_decoder
    pin: 5
binary_sensor:
  - platform: ihc_decoder
    name: "IHC Mod1 Input 01"
    id: ihc_m1_in01
    ihc_decoder_id: my_ihc_decoder    
    channel: 1
  - platform: ihc_decoder
    name: "IHC Mod1 Input 02"
    id: ihc_m1_in02
    ihc_decoder_id: my_ihc_decoder    
    channel: 2
    ...

Set the pin to the GPIO pin number where you hare connected your IHC Input module.

You can also add device_class to the binary sensor to match whatever is connected - like a motion sensor.

For the encoder use:

ihc_encoder:
  - id: my_ihc_encoder
    pin: 21 
switch:
  - platform: ihc_encoder
    name: "IHC Mod1 output 01"
    id: ihc_m1_out01
    ihc_encoder_id: my_ihc_encoder
    channel: 1
  - platform: ihc_encoder
    name: "IHC Mod1 output 02"
    id: ihc_m1_out02
    ihc_encoder_id: my_ihc_encoder
    channel: 2
    ...    

The github repository has 2 examples for the encoder and decoder. You can combine the 2 and have one single ESP32 handle both input and output.

You connect the decoder to an input pin of you ESP32, and you can add up to 16 binary sensors to the decoder. The encoder connects to an outout pin, and you can add up tpo 16 switches to the encoder

IMPORTANT ESP32 is 3.3v The IHC module are 5v - do not connect then directly - see the github repository.

Performance

I have been testing this on an ESP32-C3 mini

The encode will share the timer interrupt if you create more than one ihc_encoder. The timer is called with a 156us interval, and the interrupt code use about 2-3us.

For testing to show the timing add this to your yaml:

ihc_decoder:
  - id: my_ihc_decoder
    pin: 5
    show_timing: true

The timing will be shown in the debug logging from the ESP32 each second. You will see the last and a max value.

For the decoder the timing as about the same, and you can similar add the “show_timing”.

I do not have a setup where i can test with a lot of in- and out-put module, but I think the above timing show you should be able to handle several on the same ESP32. If you do test this with many modules please try the “show_timing”, and report back to me the result so I can share them here.

Stability

The decoder will ignore any parity bit in the signal, because it looks like it is only the IHC Controller output that actually add the parity. The encode will add the parity bit, but I guess the IHC output module also ignores this.

The timing margins for the input pulses are fixed in the code. If the decoder get a signal (low/high pulses) not within the margins that “frame” is ignored. This may need adjusting if there are unstable binary sensors.

If you experience this please report back to me about it.