What is the best approach to configure push buttons and lights

Configuration
,
1

I have a self-made 20-years old system in use. It consist of a central linux computer that drives 4 K8000 boards, each with 16 relais, 8 analog outputs & 4 analog inputs.
All the lights in the house are connected to one of those relais.
In every room I have at least 2 push buttons connected to a microcontroller. The microcontroller are all connected to the central computer over a rs485 line.
Push buttons are used stateless: a push can toggle, turn on or turn off 1 or more lights.
motion sensors are connected to analog inputs and can drive 1 or more lights.
Some controllers have been upgrade to communicate over wifi. These can easily be upgraded to send topics over Mqtt (button//).
On the server I will have a service that will subscribe to mqtt topics and drive the relais (k8000/relais/)

To convert this system to HA, what would be the best way to configure this?

I have made a proof-of-concept with:

  1. the light configured as mqtt lights:
  • light:
    • platform: mqtt
      name: ‘Hall Beneden’
      state_topic: ‘k8000/relais/30’
      command_topic: ‘k8000/30/set’
      group: “Gelijkvloers”
      icon: mdi:lightbulb-on-outline
      optimistic: true
  1. buttons configured as automations:
  • automation:
    • alias: hall beneden
      initial_state: ‘on’
      trigger:
      platform: mqtt
      topic: button/42/11
      payload: 1
      action:
      • service_template: >
        {% if is_state(‘light.hall_boven’, ‘on’) %}
        light.turn_off
        {% else %}
        light.turn_on
        {% endif %}
        entity_id:
        • light.hall_beneden

When there are better ways to do this , please let me known as I might still use the principles I developed for my old system in HA!

Note that there is no 1-to-1 relationship between buttons and lights:

  • 1 button can drive multiple lights
  • 1 light can be driven by multiple buttons
2

The first thing that comes in mind is that you can use light.toggle as the service to clean that part up a little.
If you want to group and control more lights with a specific button you can create light groups which gives you a new entity and then keep the light.toggle as the service.

3

Indeed. I have tried it but experienced problems.
They are still not solved, but with the template they do are not so visual anymore.

The problem I have is that when I send a button topic (button/42/11 with payload=1), the service (either light.toggle or turn_on or turn_off) are executed twice. I have seen now that, for an unknown reason, HA subscribes twice to each button topic. Hence the double execution of the automation.
So I need to find out why HA subscribe twice to each topic.
After that I could reconsider using light.toggle instead of the template.

Note also that in case of 1 button and multiple lights, toggle might not work. as each light can be driven by multiple buttons, resulting in mixed status-es. I solved this in my old system by only looking at the status of the first light that is driven by a button. the other lights will follow the state of the first one.

4

It´s hard to say why hass would subscribe twice but for your other questions.

A light group would be considered as on if at least one of the entities in that group is on. If you toggle the group with only one light on, it will turn off that light. Only when all lights in the group are off it will be considered as off. Toggle the group in that state it will turn all lights on.

5

oh ok. Then toggle is still the way to go.
But first need to find out why HA subscribes twice to each button topic.

6

The reason for setting optimistic to true, is if the light does not return a state_topic message when it switches state. Is that the case? If so, is there any way to make it generate one, as it does make the system more reliable.

7

Which broker are you using? I believe the MQTT spec says that there should only be one message sent to each client, even if there is more than one subscription matching the topic.

9

I’ve found the problem of the double subscriptions, but don’t understand really why this leads to double subscriptions.
In my automations I had an automation rule to enable all automations at startup of HA, while at the same time all automations had the initial_state: ‘on’ set.
Removing the automation to enable all automations at startup solved the issue.
(It was a left-over from one of the many tests I did to get to know HA)

10

You are right. This was added for testing purposes only as I am currently testing this without any real hardware connected to the system.
In real life (at least for my case) it should be as follows:
For a push button, which is stateless, optimistic should be set to true.
For a relais, however, a state_topic should be defined. This will set optimistic to false.

The controlling software that drives the relais will return a state_topic as configured.

thank you for your feedback.

11

I think the best way to represent a push button in HA is through a sensor. It doesn’t have a command_topic, only the state_topic, which is the one sent from the button.

However, I think this would only be necessary if you need to read the last message sent at some point in the future. Triggering the responses purely from an automation as you have in your first post is all that is necessary to switch relays.