
Llevaba tiempo con el Fermax WiBox en el cajon por no poder integrarlo con Home Assistant, el problema de fondo no es tanto que dependa de una nube externa (que tambien), sino que la aplicacion practicamente no recibe soporte, se ha quedado con funcionalidades basicas sin cubrir sobretodo en las ultimas versiones de Android y no hay manera de integrarlo en Home Assistant.
La idea es simple: mismo hardware, mismos cables, pero cambiando el software de dentro para que el modulo se integre con MQTT en HomeAssistant, ver quien esta en la puerta, hablar, abrir, y sobre todo poder disparar automatizaciones desde Home Assistant como una entidad mas, ademas de que todo pase a ser local.
Aviso antes de nada: esto sustituye el firmware del fabricante. El original sigue dentro del dispositivo y hay un modo factory para volver a arrancarlo, asi que la vuelta atras existe. Aun asi, haz las copias de seguridad que se explican en la guia de instalacion ANTES de tocar nada. No te saltes ese paso.
Información WiBox
- SoC: Goke GK7102S, la misma familia de los DVR y camaras IP chinas baratas
- Programa original: el binario propietario que habla con la nube
- Sistema de ficheros de userdata: cramfs (por eso hace falta reconstruir la imagen para parchearla)
- Bus del portero: VDS, el protocolo propietario de Fermax
- Acceso de rescate: UART serie y, segun version, telnet
La base es un Linux embebido bastante estandar de estos SoC, y eso es justo lo que permite jugar con él.
Implementado en el custom firmware
- Video H.264 de la camara, servido por RTSP
- Audio bidireccional por WebRTC: oyes la calle y te oyen a ti, sin depender de un servidor SIP
- Abrir la puerta desde Home Assistant o con
#durante la llamada - Eventos de llamada
- Snapshot de quien ha llamado, gestionado desde Home Assistant
- Integracion con Home Assistant por MQTT
- Actualizaciones OTA desde Home Assistant o desde shell
- Metricas Prometheus, por si dispones de grafana
El daemon SIP del fork original sigue ahi por debajo y puedes usarlo contra cualquier servidor SIP si lo necesitas, pero no es el foco de esta version. Yo he tirado el proyecto hacia WebRTC para toda la parte de llamadas: es lo que me deja tener el interfono dentro de una card de Home Assistant (wibox-intercom-video-card), con voz de ida y vuelta, sin montar ni depender de un servidor SIP.
El origen de todo
| Proyecto | Que aporto |
|---|---|
duhow/wibox |
Abrio el dispositivo: parcheo del firmware, instalacion y recuperacion |
Conclusio/wibox-audio |
Trazo el hardware de audio y construyo el puente de audio |
segator/wibox-media |
El daemon de media SIP, la integracion con HA y el sistema de updates: la base que sigue este fork |
cmos486/wibox-intercom-video-card |
La tarjeta de HA que lo une todo en pantalla |
Mi fork (cmos486/wibox-media) añade el audio bidireccional por WebRTC, monitorizacion de estado y diversos fixes.
Lo que tocaba averiguar (la parte que no esta documentada)
Buena parte de este firmware existe por cosas que no estaban escritas en ningun sitio y hubo que sacarlas a base de un laboratorio de pruebas con una instalacion Fermax real: placa de calle, monitor original y WiBox. Estos tres puntos son la diferencia entre que esto funcione o funcione a medias:
- El bus VDS. Como funciona el bus de Fermax, por que el modulo necesita una direccion y que pasa cuando esta mal. Spoiler: no pasa absolutamente nada, y en silencio. No hay error, no hay log, simplemente las llamadas de la calle no llegan nunca.
- Compartir el bus con el portero original. La pregunta obvia: esto rompe el videoportero que usa el resto de la casa? Probado con los logs guardados. Respuesta corta: no.
- Los codigos UART. El set completo de comandos que el firmware de fabrica usa para hablar con el microcontrolador de Fermax, recuperado desensamblandolo, con checksum incluido.
Manos a la obra
Paso 1: lee antes de flashear
La guia de Getting Started cubre acceso, copias, primer flasheo y primer arranque. La copia de seguridad la hacemos en el Paso 3, justo antes de escribir en flash. Las versiones de fabrica probadas:
| Firmware de fabrica | Acceso |
|---|---|
V500.R001.A103.00.G0021.B007 |
telnet |
V500.R001.A103.00.G0021.B010 |
telnet |
V500.R001.A103.00.G0021.B013 |
solo serie (telnet bloqueado) |
Ojo con esto: cualquier version mas nueva, tratala como solo via serie hasta que alguien demuestre lo contrario. Si te toca la B013 o superior, vas a necesitar el cable serie desde el minuto uno.
Paso 2: descarga el firmware
VERSION="v0.18.14"
wget -O wibox-media.img \
"https://github.com/cmos486/wibox-media/releases/download/${VERSION}/wibox-media-${VERSION}.img"
A tener en cuenta: ese wget se lanza en tu ordenador, no en el WiBox. El wget del dispositivo de fabrica no puede con las descargas HTTPS de GitHub. El fichero se transfiere despues con nc, como explica la guia.
Paso 3: flashea la imagen
Necesitas una shell en el WiBox: telnet en las B007/B010, o serie si tienes la B013 o telnet no responde.
La transferencia por nc que viene a continuacion asume que el WiBox y tu ordenador estan en la misma red. Si entraste por telnet, ya lo estan: un stock que has usado con la app Fermax sigue asociado a tu WiFi (por eso lo alcanzas por telnet). Si has entrado por serie y el aparato no tiene red, no puedes usar nc por red: transfiere la imagen por la propia serie o usa el metodo de U-Boot de la guia de recovery.
Primero, copia de seguridad. Como minimo salva la mtd4 (la cramfs de fabrica), pero salvarlas todas cuesta lo mismo. En tu ordenador:
for i in $(seq 0 6); do nc -l -p 8888 > "mtd${i}.img"; done
En la shell del WiBox (pon la IP de tu ordenador):
PC_IP=192.168.1.100
for i in $(seq 0 6); do
dd if=/dev/mtd${i} bs=4096 | nc "${PC_IP}" 8888
sleep 1
done
Ahora el flasheo. Se transfiere la imagen por nc porque el WiBox no puede descargarla de GitHub. En tu ordenador:
nc -l -p 8888 < wibox-media.img
En la shell del WiBox:
PC_IP=192.168.1.100
nc "${PC_IP}" 8888 > /tmp/update.img
md5sum /tmp/update.img
dd if=/tmp/update.img of=/dev/mtdblock4 bs=4096
sync
reboot
Compara el md5sum con el de tu ordenador antes del dd: si no coinciden, no escribas nada. Este es el unico paso con el que puedes dejar el aparato tieso, ten el acceso serie a mano por si toca recuperar.
Paso 4: conectalo al WiFi
Tras el primer flasheo, el modulo levanta su propia red WiFi llamada IDS7938XXXX (el Device ID esta impreso en la etiqueta). Te conectas a ella, abres http://192.168.111.1/ y metes los datos de tu red. Sin cable.
Para moverlo a otra red mas adelante: manten pulsado el boton WiFi 5 segundos. LED azul parpadeando quiere decir que la pagina de configuracion esta arriba otra vez.
Paso 5: configuralo
Toda la configuracion vive en un fichero del dispositivo:
/mnt/mtd/sip_media.conf
Para la mayoria de instalaciones solo importa el bloque de MQTT:
mqtt_host=192.168.0.203 # tu broker MQTT / Home Assistant
mqtt_user=wibox
mqtt_pass=change-me
El video y el RTSP vienen apagados de fabrica (video_enabled=0, rtsp_enabled=0) y se activan luego desde Home Assistant: las entidades publican valores MQTT retenidos que mandan sobre el fichero, asi que no tiene sentido pelearse con el .conf para eso.
Paso 6: metelo en Home Assistant
Con MQTT discovery activo, el dispositivo aparece solo. No hay que escribir nada a mano ni instalar ninguna integracion: sale con todo ya cableado, controles, sensores y eventos.

Los controles son lo que pulsas (abrir puerta, snapshot, encender o apagar video y RTSP, fijar la direccion VDS del piso, programar un reinicio nocturno). Los sensores son lo que te cuenta (estado de llamada, salud, uptime, version de firmware, y el snapshot del ultimo que llamo). Los eventos son lo que acaba de pasar (pulsaciones del timbre y el trafico crudo del bus, que es lo que miras cuando algo se comporta raro).
Paso 7: dile que piso es (direccion VDS)
Este es el paso mas importante para detectar las llamadas El WiBox tiene que saber a que pulsador/timbre/piso tiene que escuchar.
Borra la direccion antigua con cinco pulsaciones cortas del botón PB2 interior, se seteara a 250 y luego escribe el numero en la entidad VDS Address de Home Assistant.
La tarjeta de Home Assistant
Aqui es donde el enfoque WebRTC toma sentido, para tener la experiencia real de tener el videportero en Home Assistant (el video, un boton para hablar y otro para abrir, funcionando en moviles y tablets de pared, en casa y fuera) hice una tarjeta a medida en lugar de depender de un cliente SIP:

La card monta la llamada por WebRTC directamente contra el firmware: pulsar y mantener para hablar, abrir la puerta, colgar, todo dentro de Home Assistant sin app de intercomunicador aparte. Si en la esquina pone RTC conectado, la conexión WebRTC es correcta, que es el que lleva tu voz de vuelta a la placa. Si en cambio pone MSE, el stream es solo de video.
Conexión cable serie TTL
Aviso importante: usa un adaptador de 3.3V. Uno de 5V puede cargarse la placa. Comprueba el jumper antes de enchufar nada.
Tres cables, y TX va a RX:
| Placa WiBox | Adaptador USB-TTL |
|---|---|
| GND | GND |
| TX | RX |
| RX | TX |
Y luego, a 115200 baudios:
picocom -b 115200 /dev/ttyUSB0
Supervisión
El firmware esta pensado para instalarlo y olvidarte, asi que se vigila a si mismo:
- Watchdog: si el daemon muere, se reinicia
- Auto-reparacion de audio: una captura que se queda muda se detecta y se reinicia
- Reinicio programado: opcional, apagado por defecto, la hora se fija desde HA
- Reloj correcto: sincronizado en el arranque, con tu zona horaria
- Entidades de salud:
HealthyHealth Detailen HA te dicen que va mal
Las actualizaciones se instalan OTA desde Home Assistant, y la direccion VDS sobrevive a los updates.
Si algo no va
| Sintoma | Donde mirar |
|---|---|
| Nadie llama cuando pulsan en la calle | La direccion VDS. |
| Pantalla azul en vez de la camara | El bus no se ha abierto |
| El video va, el audio es un siseo flojo | Mismo origen que el anterior |
| No te oyen | La guia de audio bidireccional |
| El timbre da ocupado a veces | Compartir el bus con el monitor original |
| No arranca | Recovery + serie TTL |
Compilar desde codigo
Solo si vas a cambiar el firmware. Para instalar no hace falta.
make docker # construye la imagen del toolchain
make build # construye el firmware
make verify # comprueba el resultado
Utiles durante el desarrollo:
make build-media # recompila solo el daemon y el updater
make deploy-runtime # empuja el daemon a un WiBox vivo (volatil: se pierde al reiniciar)
make verify-device # comprueba runtime + MQTT contra un dispositivo real
Ojo con make deploy-runtime: es solo para pruebas, no sobrevive a un reinicio. Si quieres que el cambio se quede, instala una release de verdad.