Este completo tutorial explica el cableado preciso, la configuración de Zigbee2MQTT, la integración de Home Assistant y Alexa. Un único botón del panel de control + información sobre el estado real + comando de voz «Alexa abre el portal».
Mis tres objetivos Portal de domotización
He establecido tres objetivos específicos para domotizar mi portal de golpes Came equipado con una tarjeta de control ZL180.
- Un solo botón en el panel de control del Home Assistant activa el portal a través de una secuencia de impulsos precisa: contacto seco ON durante 500 ms, romper 500 ms mínimo, luego OFF.
- Retorno de estado real que muestra si la puerta está abierta o cerrada en cualquier momento, utilizando un sensor de posición.
- Control de voz simple con Alexa: "Alexa, abre el portal" o "Alexa, cierra el portal".
Este tutorial reemplaza el anterior utilizando el módulo QS-Zigbee-S10-C03 que causó desconexiones frecuentes de la red Zigbee. Artículo obsoleto: Domotización QS-Zigbee-S10-C03.
Mi tarjeta de pedido Llegó ZL180
Mi portal de golpes funciona con la tarjeta electrónica Came ZL180 que maneja todos los movimientos, seguridad y extremos de carrera.
Ficha de información técnica oficial completa: Descargar PDF ZL180.
Terminales de pedidos de tarjetas ZL180
Todas las conexiones domóticas se conectan a los bloques de terminales en la parte inferior derecha de la tarjeta ZL180. Estos 10 terminales permiten el control del portal y la lectura de los estados.
Portal de apertura/cierre de control
La tarjeta ZL180 controla la apertura/cierre mediante un contacto seco (sin tensión) entre los terminales 2 (COM) y 7 (IMP). El contacto seco simplemente significa cerrar el circuito eléctrico sin aplicar voltaje.
- Cierre el contacto terminal 2-7 durante exactamente 500 milisegundos (0,5 segundos).
- Mantenga un descanso de al menos 500 ms antes de volver a ordenar.
- Abra el contacto (OFF) para completar el pulso.
Esta secuencia del pulso es obligatoria y se describe en la página 8 del prospecto ZL180.
Retorno de estado del portal abierto/cerrado
La tarjeta ZL180 no proporciona contacto seco directo para el estado de la puerta. Ofrece una señal de 24V entre los terminales 5 (COM) y 10 (OUV) cuando el portal está completamente abierto.
Para convertir esta señal de 0/24V en contacto seco compatible con la automatización del hogar, instalo un relé IEC255 de 24V en la carcasa Came. El relé aísla eléctricamente los circuitos y crea un simple contacto seco abierto / cerrado.
Aquí está mi relé IEC255 montado en soporte DIN en la carcasa Came:
Interruptores de configuración DIP cruciales
Problema frecuente: algunos impulsos no se tienen en cuenta. La causa es a menudo la función "Stop" activada en el interruptor DIP 2 de la tarjeta ZL180. Esta función detiene el portal en cada impulso recibido.
Solución: colocar el DIP2 en OFF para permitir controles parciales (apertura/cierre normal).
Mi módulo de elección Zigbee MOES
Probé varios módulos, pero elegí el MOES ZM-102-M por su estabilidad Zigbee, precio asequible y funciones de puerta completa.
- IOMZB-110 FRIENTE : Excelente pero 60€.
- Interruptor inteligente ZG-005-RF : 4 salidas a 18€ pero sin entrada.
- NODON SIN-4-1-20 : No hay entrada de contacto seco.
- MOES ZM-102-M elegido a 17,90€.
- QS-Zigbee-S10-C03 : Desconexiones frecuentes, abandonadas.
El MOES ZM-102-M-MS Incluye fuente de alimentación de 230V, salida de pulso, entrada de contacto seco y sensor magnético. Versión ZM-102-M = módulo único sin sensor.
¿Dónde comprar este equipo?
Aquí está el enlace a la página dedicada a ZM-102-M. Hice referencia a los vendedores y los precios.
Fijación precisa MOES ZM-102-M
- L y N : Fase 230V + fuente de alimentación neutra.
- S4-S5 : Entrada de contacto seco (conectada al relé IEC255 para el estado del portal).
- S1-S2 : Salida de pulso a terminales 2-7 tarjeta ZL180.
Diagrama completo del cableado del portal
Emparejo el módulo Zigbee2MQTT
Encendido = modo de emparejamiento automático (el led azul parpadea 10 min). Botón de emparejamiento detrás del módulo. Coloque temporalmente cerca del coordinador Zigbee si la distancia es significativa.
En Zigbee2MQTT en modo "Permit Join", el módulo aparece como _TZE200 _fabuwqzo _ts0601. Yo lo llamo "Came Portal".
Características expuestas MOES
El módulo establece estas propiedades esenciales:
- disparador (binario): Envía el pulso S1-S2. true=open, false=close. Inteligencia: no envía si el estado ya es correcto.
- _door _contact Garaje (binario): Estado S4-S5. true=closed, false=open.
- conteo (0-43200s): Impulso forzado tras retraso.
- run_time (-1 a 120 s): Movimiento de tiempo de espera. Alarma si está abrumado.
- estado : Normal / RunTimeAlarm / OpenTimeAlarm.
Integración automática Home Assistant
Las entidades aparecen automáticamente en Home Assistant después de reiniciar o actualizar Zigbee2MQTT.
- binario_sensor.portal_came_garage_door_contacto : Estado real (off=closed, on=open).
- switch.portal_came_trigger : Botón de pulso (ON 500ms luego auto-OFF).
- sensor.portal_came_status : Estado del módulo.
Mi configuración Portada Portal
Yo creo una entidad de cubierta unificada que combina el estado real (_sensor binario) y el comando (switch). Un Cover Home Assistant representa cualquier elemento viable: Puerta, puerta, persiana.
Añadir en configuration.yaml debajo de la plantilla → cubierta:
- cubierta: - nombre: Portal único de _id: cover.portal device_class: Icono de puerta: > {% si es_state('binary_sensor.portal_came_garage_door_contact', 'off') %mdi:gate {% de lo contrario %mdi:gate-open {% endif %} estado: > {% si es_state('binary_sensor.portal_came_garage_door_contact', 'off') %} cerrado {% de lo contrario %} abierto {% endif %} open_cover: - servicio: script.actionne_le_portal_toggle close_cover: - servicio: script.actionne _le _porttail _toggle
Botones del portal de mi panel de control
Versión simple de la tarjeta de botón
Tipo: custom:botón-tarjeta show_name: false tap_acción: Acción: entidad de conmutación: estado cover.portal: -valor: color cerrado: gris - valor: color abierto: rojo
Versión avanzada picture-elements
- tipo: custom:botón-tarjeta color_type: entidad de la tarjeta: cover.portal show_nombre: false tap_acción: Acción: estado de conmutación: -valor: color abierto: "#4f010a" icono: estilos mdi:gate-open: tarjeta: - animación: blink 2s easy infinite - operador: color por defecto: "#Icono de 49556c": estilos mdi:gate: tarjeta: - altura: 110px - anchura: Estilo 110px: parte superior: 93% izquierda: 5%
Portal de control de voz de Alexa
Exponer la entidad cover.portal a Alexa para el control de voz.
- Configuración → Asistentes de voz → "x entidad(es) a exponer".
- Seleccionar
cover.portal. - Órdenes: "Alexa, abre el portal", "Alexa, cierra el portal".
Bonificación de pulso visual
Confirmación visual inmediata del envío del pulso mediante el icono parpadeante. Crear entrada_boolean.pulse_portal vía Settings → Devices & Services → Helpers → Switch.
Tipo: custom:entidad de tarjeta de botón: input_boolean. impulse_portail nombre: Portal de Impulsión show_state: falso show_name: Icono falso: estilos mdi:access-point: icono: - color: | [[ if (entity.state === 'on') return '#39FF14»; retorno «transparente»; ]]] - animación: | [[[ if (entity.state === 'on') return 'blink 0.4s linear infinite'; devolver «ninguno»; ]]] tarjeta: - anchura: 150px - altura: 150px - radio fronterizo: 12px - color de fondo: transparente - caja-sombra: ninguno
Script opera _le _portal _toggle (que se creará en scripts.yaml):
secuencia: - servicio: switch.turn_on objetivo: _id (entidad): switch.portal_came_trigger - servicio: input_boolean.turn_on objetivo: _id (entidad): input_boolean. impulse_portal - delay: en segundo lugar: 1 - Servicio: input_boolean.turn_off objetivo: _id (entidad): input_booleano. impulse_portal alias: Opera el portal
Bonus Rustine Apertura
He encontrado, por una razón que todavía me escapa, que aproximadamente una vez cada veinte, la orden de abrir el portal se activa correctamente: Aparece el pulso al módulo, no aparecen errores … pero no pasa nada.
Todo sugiere que el módulo está en modo de espera en el momento del pedido y simplemente no reacciona.
Por otro lado, si devuelvo un segundo pulso en cuestión de segundos, el portal se abre inmediatamente.
Por lo general, soy bastante alérgico a las «rustinas». Me gusta entender y corregir el problema en la fuente. Pero en este caso, la solución más pragmática me pareció que era añadir un mecanismo de recuperación.
La idea es simple:
Si, después de un comando de apertura, el portal todavía se detecta como cerrado después de unos segundos, entonces el script devuelve automáticamente un segundo pulso.
En el peor de los casos, perdemos dos segundos.
En el mejor de los casos, se corrige un peligro invisible para el usuario.
Por lo tanto, configuro el siguiente script:
secuencia: - alias: Guarda el estado del portal antes de las variables de pulso: etat_portal_avant: «{{{states('binary_sensor.portal_came_garage_door_contact') }}» - alias: Envía el impulso al portal de acción: objetivo switch.toggle: _id (entidad): datos del switch.portal _came _trigger: {} - paralelo: - alias: Parpadea el envío de pulsos en la secuencia de Dashboard: - acción: input_boolean.turn_on objetivo: _id (entidad): input_booleano. impulse_portal data: {} - retraso: en segundo lugar: 1 - Acción: input_boolean.turn_off objetivo: _id (entidad): input_booleano. impulse_portal data: {} - alias: Rustina solo si el portal fue cerrado secuencia: - si: - condición: valor de la plantilla _template: "{{ etat _porttail _avant == 'off' }}" entonces: - alias: 2s de espera máxima para que el portal abra wait_template: >- {{ is_state('binary_sensor.portal_came_garage_door_contact', 'on') }} Tiempo de espera: en segundo lugar: 2 continúa _on _timeout: verdadero - si: - condición: valor de la plantilla _template: "{{ no wait.completed }}" entonces: - alias: Reinicia el impulso si el portal no ha reaccionado a la acción: objetivo switch.toggle: _id (entidad): datos del switch.portal _came _trigger: {} alias: Opera el portal de descripción: ""
Este script establece un mecanismo de verificación simple después de enviar un pulso al portal, con una lógica de recuperación en caso de problemas.
El primer paso es recordar el estado del portal antes de cualquier acción. Se registra si está abierto o cerrado en el momento del envío del pedido (binary_sensor.portal_came_garage_door_contact). Esta información es importante porque permite saber si activar o no la lógica de copia de seguridad.
Una vez guardado este estado, el script envía el pulso al portal a través del módulo (switch.portal_came_trigger), exactamente como en funcionamiento normal. Paralelamente, se activa un pequeño indicador visual durante un segundo (input_boolean.pulse_portal), simplemente para materializar el envío del pulso al salpicadero.
Es entonces cuando entra en juego la «rustina», pero solo en un caso muy específico: si la puerta estaba cerrada en el momento del pedido. Esta precaución evita efectos indeseables, especialmente si el portal se está cerrando, porque en este caso puede tardar varios segundos en reaccionar y es importante no devolver un impulso.
Si el portal está cerrado, el script espera hasta dos segundos para ver si entra en estado abierto (binary_sensor.portal_came_garage_door_contact). Esta expectativa está activa: Si el cambio ocurre rápidamente, el script lo detecta inmediatamente y se detiene allí.
Por otro lado, si no pasa nada durante esos dos segundos, se considera que no se tuvo en cuenta el impulso inicial, probablemente debido a un módulo aún en modo de espera. A continuación, el script envía automáticamente un segundo pulso a través del módulo (switch.portal _came _trigger).
Al final, este mecanismo actúa como una red de seguridad. En la mayoría de los casos, es inútil y permanece invisible. Pero en las raras situaciones en las que el portal no reacciona, permite corregir el problema sin intervención manual, con un simple retraso de dos segundos.
Documentación técnica completa
Foro Intercambios Feedback Experience
Preguntas, comentarios, diagramas adicionales: Discusión del Foro HACF.
Spanish 
French 
English 
Chinese 
German