Comfort Automation/ Security System Forums
Home Assistant Setup on HAOS - Printable Version

+- Comfort Automation/ Security System Forums (https://www.comfortforums.com)
+-- Forum: Software Applications (https://www.comfortforums.com/forum-4.html)
+--- Forum: Comfort with Home Assistant (https://www.comfortforums.com/forum-143.html)
+--- Thread: Home Assistant Setup on HAOS (/thread-5658.html)

Pages: 1 2 3

Home Assistant Setup on HAOS - Majik - 08-13-2025

I'm documenting this because, during the installation, I came across a couple of minor issues, and this may be helpful for other people.

The background to this:

I've had a HAOS (Home Assistant Operating System) install running on a Linux VM for a little while with a number of integrations already.

I have a UCM/Pi running the standard UCMPI_OS install, and was, originally, considering installing HA on that, but the documented way to do that is using the Docker image, which has restrictions (no addons) which make it a deal-breaker.

I also looked at the options for modifying UCMPI_OS to run HA directly, perhaps extracting the Cytech Node Red components and running these within Node Red installed as an add-on within HA, but that looked too complex. Also, the UCM/PI connects to Comfort with a local serial interface, and Comfort2MQTT expects a network port.

So, whilst I'm hopeful there may be a future UCM/PI setup that is nicely bundled with HA, I abandoned that for the time being.

So I decided to install onto my existing HAOS system which, I suspect for some existing HA users, may be something they want to do. I don't know how different the standard Linux HAOS is from the Raspberry Pi version, but these are some notes.

Firstly, I hit a minor problem with the broker credentials. The instructions say:

slychiu Wrote: Press the Configuration Tab on top to go to the Options. Enter an MQTT Borker User and password that you choose.

That's cool, but the instructions seem to provide no information about needing to configure the Mosquitto Broker with those credentials, so I ended up with Comfort2MQTT not being able to connect to the broker (errors in the logs).

After a bit of scrabbling around (as the Mosquitto Broker docs aren't that helpful on the subject) I worked out how to configure this:
   

The format isn't clear from the docs, but it's this:
Code:
- username: <username>
  password: <password>

After this, it all connected fine. However, I couldn't work out how to upload my cclx file, as the file editor didn't show the addon_configs directory. It appears that, on my installation, the File Editor add-on is restricted to the /root/homeassistant directory, and the addon_configs directory is one level higher than that.

So, in the end I had to use the Terminal & SSH add-on (which I already had installed) and used sftp to upload the CCLX.

Later on, I realised there's a configuration option in the File Editor add-on "Enforce Basepath" which (as per the docs) "If set to `true`, access is limited to files within the `/config` directory.". Unsetting this allows me to navigate to the addon_config directory.

Then I moved onto the configuration.yaml. This is what I configured:
Code:
mqtt:
  alarm_control_panel:
  - name: Comfort Alarm
    unique_id: "comfort2_alarm_0fee8e"  # E.G. Use last six digits of UCM/Eth03 MAC address to make it unique
    code_arm_required: false
    qos: 2
    supported_features:
      - arm_home
      - arm_away
      - arm_night
        # - arm_vacation
      - arm_custom_bypass
    state_topic: "comfort2mqtt/alarm"
    command_topic: "comfort2mqtt/alarm/set"
    availability_topic: "comfort2mqtt/alarm/online"
    payload_available: 1
    payload_not_available: 0
    code: "1234"  # onscreen keypad  Code can be different from Comfort\'s.
                          # This code is for the onscreen Keypad to Disarm, while the Comfort code in Comfort2MQTT
                          # configuration is to login to Comfort itself.
                          # This onscreen keypad code is used in the alarm Keypad to disarm Comfort. It is not the
                          # Comfort user code, although both can be set to the same code. When you enter the
                          # onscreen keypad  code in the alarm Keypad to disarm, Comfort2MTT will disarm the
                          # security by using the saved user code.                   
                          # Secrets can be used EG. "code: !secret comfort_pin


  sensor:
  - name: Alarm Mode
    unique_id: "comfort2_alarm_mode"
    availability_topic: "comfort2mqtt/alarm/online"
    state_topic: "comfort2mqtt/alarm"
    payload_available: "1"
    payload_not_available: "0"

  - name: Alarm Message
    unique_id: "comfort2_alarm_message"
    state_topic: "comfort2mqtt/alarm/message"
    availability_topic: "comfort2mqtt/alarm/online"
    payload_available: "1"
    payload_not_available: "0"

This is nearly an exact copy of the configuration from the instructions, but I found the inline instructions a bit difficult to use as it included additional escape characters which I had to edit out, and copying/pasting it into the file editor messed up the formatting, which needed correction. I'm hoping that using the code block here makes the formatting easier to read and more reliable for copy/pasting.

@slychiu would it be possible to update the instructions to use the code block for better formatting of the configuration.yaml items?

The item "arm_vacation" seems to be commented out, and I'm not clear why.

Then I moved onto adding zones. Again, following the instructions, I added this to my configuration.yaml:
Code:
  binary_sensor:
  - name: Front Door
    unique_id: "comfort2_input1"
    state_topic: "comfort2mqtt/input1"
    availability_topic: "comfort2mqtt/alarm/online"
    value_template: '{{ value_json.State }}'
    json_attributes_topic: "comfort2mqtt/input1"
    json_attributes_template: '{{ value_json | tojson }}'
    payload_on: "1"
    payload_off: "0"
    payload_available: "1"
    payload_not_available: "0"
    device_class: door
   
  - name: Hall PIR
    unique_id: \"comfort2_input2\"
    state_topic: \"comfort2mqtt/input2\"
    availability_topic: \"comfort2mqtt/alarm/online\"
    value_template: \'{{ value_json.State }}\'
    json_attributes_topic: \"comfort2mqtt/input2\"
    json_attributes_template: \'{{ value_json | tojson }}\'
    payload_on: \"1\"
    payload_off: \"0\"
    payload_available: \"1\"
    payload_not_available: \"0\"
    device_class: motion

(Again, mainly posting these for a copy/paste reference)

After a reload, these zones show up in the entities under the MQTT Integration, and under "Binary sensor" in the Overview Dashboard. To reload, I selected "Manually configured MQTT entities" on the Developer tools page.

An interesting point was, I configured one of the binary sensors incorrectly (due to escape chars in the cut/paste) and, after I corrected it, HA still had the original entity as well as the corrected one. I had to manually delete the entity. Maybe a full restart of HA would have cleared this as well, but be aware that this might occur.

That is my adventure to date, and I hope some of this is useful to others. If I come across any other "gotchas" or points of note, I will update.

Cheers,

Keith

RE: Home Assistant Setup on HAOS - slychiu - 08-14-2025

Thanks for the feedback. we are planning a new version of UCM/Pi which will support Home assistant directly and whoich will be easier to configure, using CM4

RE: Home Assistant Setup on HAOS - Majik - 08-14-2025

I thought it might be useful to list some of the device_class names used in HA YAML definitions. These are all used with binary_sensor definitions, for example:

Code:
  binary_sensor:
  - name: Front Door
    unique_id: "comfort2_input1"
    state_topic: "comfort2mqtt/input1"
    availability_topic: "comfort2mqtt/alarm/online"
    value_template: '{{ value_json.State }}'
    json_attributes_topic: "comfort2mqtt/input1"
    json_attributes_template: '{{ value_json | tojson }}'
    payload_on: "1"
    payload_off: "0"
    payload_available: "1"
    payload_not_available: "0"
    device_class: door

The device_class settings I have found to be useful are:
  • door
  • window
  • motion (for PIRs)
  • smoke (for smoke detectors)
  • carbon_monoxide (for CO detectors)
  • moisture (for a leak detector)
  • garage_door

There's a bunch of others that can be found at https://www.home-assistant.io/integrations/binary_sensor/#device-class

Bear in mind that you will have to account for NO or NC in your sensor settings.

Apparently Comfort sorts it out for you (see slychui response below).

For NO:
Code:
    payload_on: "1"
    payload_off: "0"

For NC:
Code:
    payload_on: "0"
    payload_off: "1"

Cheers,

Keith

RE: Home Assistant Setup on HAOS - slychiu - 08-15-2025

For NO:
Code:
    payload_on: "1"

    payload_off: "0"

For NC:
Code:
    payload_on: "0"

    payload_off: "

I think payload on should always be 1 and vice versa regardless of zone N/O and N/C because the zone reports already take that into account. eg when the zone is N/C, opening it leadsa to zone On report

RE: Home Assistant Setup on HAOS - Majik - 08-15-2025

(08-15-2025, 01:28 AM)slychiu Wrote: For NO:
Code:
    payload_on: "1"

    payload_off: "0"

For NC:
Code:
    payload_on: "0"

    payload_off: "

I think payload on should always be 1 and vice versa regardless of zone N/O and N/C because the zone reports already take that into account. eg when the zone is N/C, opening it leadsa to zone On report

Ah, that's good information. I hadn't though of that.

Cheers,

Keith

RE: Home Assistant Setup on HAOS - Majik - 08-15-2025

At the moment, I'm having problems getting the doorbell integration working. My config is as follows:
Code:
  binary_sensor:
  - name: Doorbell
    unique_id: "comfort2_doorbell"
    state_topic: "comfort2mqtt/alarm/doorbell"
    availability_topic: "comfort2mqtt/alarm/online"
    value_template: '{{ value_json.State }}'
    json_attributes_topic: "comfort2mqtt/alarm/doorbell"
    json_attributes_template: '{{ value_json | tojson }}'
    payload_on: "1"
    payload_off: "0"
    payload_available: "1"
    payload_not_available: "0"
    device_class: motion

When I look at the logs I see the doorbell coming through:
Code:
2025-08-15 14:20:13 DEBUG    DB31
2025-08-15 14:20:19 DEBUG    IP0301
2025-08-15 14:20:21 DEBUG    IP0300
2025-08-15 14:20:23 DEBUG    IP0301
2025-08-15 14:20:25 DEBUG    IP0501
2025-08-15 14:20:25 DEBUG    IP0201
2025-08-15 14:20:25 DEBUG    IP0300
2025-08-15 14:20:25 DEBUG    IP0500
2025-08-15 14:20:27 DEBUG    IP0200
2025-08-15 14:20:28 DEBUG    IP0501
2025-08-15 14:20:30 DEBUG    IP0201
2025-08-15 14:20:31 DEBUG    IP0101
2025-08-15 14:20:31 DEBUG    DBFF

And I see the alarm message:
   

But the entity doesn't seem to pick it up:
   

I can't see anything obviously wrong with my definition, but maybe I have misunderstood something.

Cheers,

Keith

RE: Home Assistant Setup on HAOS - Ingo - 08-16-2025

Have a look at the other 'system' examples in the documentation using a similar MQTT topic path.

RE: Home Assistant Setup on HAOS - Majik - 08-16-2025

(08-16-2025, 04:46 AM)Ingo Wrote: Have a look at the other 'system' examples in the documentation using a similar MQTT topic path.

Thanks. In the end I got it working. I used the following:

Code:
mqtt:
...
  event:
    - name: Doorbell events
      unique_id: "comfort2_doorbell_event"
      state_topic: "comfort2mqtt/alarm/doorbell"
      availability_topic: "comfort2mqtt/alarm/online"
      payload_available: 1
      payload_not_available: 0
      event_types:
        - "button_press"
      value_template: >
        {% if value == "1" %}
          button_press
        {% else %}
          none
        {% endif %}
      device_class: doorbell
...
  binary_sensor:
  - name: Doorbell
    unique_id: "comfort2_doorbell"
    state_topic: "comfort2mqtt/alarm/doorbell"
    availability_topic: "comfort2mqtt/alarm/online"
    payload_available: "1"
    payload_not_available: "0"
    payload_on: "1"
    payload_off: "0"
    icon: mdi:doorbell

This gives me a sensor entity (which I can easily attach to a badge) and an event.

It's notable that, in HA, there is no sensor device_class for "doorbell" and the expected approach is that doorbells are modelled as events (which is why I've added the event above), as there is a device_class of "doorbell" for events.

I did some research as to how I could map the event to a badge visual state for my dashboard, but the approach seems to be to create a virtual entity and map the event to it to drive its state. I didn't see the point in that when I could just directly create a sensor from the MQTT subscription.

At this point, I have a dashboard badge which changes when the doorbell has been pressed, and an automation driven from the event.

Comments and improvements are welcome.

Cheers,

Keith

RE: Home Assistant Setup on HAOS - Majik - 08-16-2025

As an update, I've removed the "event" config as, with some more research, there's already an event which carries the doorbell state on the entity "sensor.alarm_message":

Code:
event_type: state_changed
data:
  entity_id: sensor.alarm_message
  old_state:
    entity_id: sensor.alarm_message
    state: Door Bell
    attributes:
      friendly_name: Alarm Message
    last_changed: "2025-08-16T16:11:06.488641+00:00"
    last_reported: "2025-08-16T16:11:06.488641+00:00"
    last_updated: "2025-08-16T16:11:06.488641+00:00"
    context:
      id: 01K2STC8VR8HY9F3XP4VE53APQ
      parent_id: null
      user_id: null
  new_state:
    entity_id: sensor.alarm_message
    state: ""
    attributes:
      friendly_name: Alarm Message
    last_changed: "2025-08-16T16:11:07.742558+00:00"
    last_reported: "2025-08-16T16:11:07.742558+00:00"
    last_updated: "2025-08-16T16:11:07.742558+00:00"
    context:
      id: 01K2STCA2YAY05MJ3GSSYKNDM4
      parent_id: null
      user_id: null
origin: LOCAL
time_fired: "2025-08-16T16:11:07.742558+00:00"
context:
  id: 01K2STCA2YAY05MJ3GSSYKNDM4
  parent_id: null
  user_id: null

Cheers,

Keith

RE: Home Assistant Setup on HAOS - Ingo - 08-17-2025

The next release will change 'Door Bell' to 'Doorbell'.

It will also report in the Alarm Message field which doorbell was pressed eg 'Doorbell 1'. There can be a max of three doorbell units on each system.

Ingo