API de Revit: pasa de ejecutar comandos a crear herramientas
Si trabajas con Revit, seguramente conoces la escena. Hay que revisar un parámetro en varios cientos de elementos, preparar las mismas vistas en cada modelo o repetir una exportación que solo sale bien cuando la hace la persona que “sabe dónde tocar”. Al principio lo resolvemos con paciencia. Después con una hoja de instrucciones. Y, cuando esa hoja ya tiene más excepciones que pasos, alguien pregunta si no se podría automatizar.
Ahí es donde empieza a tener sentido la API de Revit. No porque programar sea automáticamente mejor que hacer clic, sino porque permite convertir una regla conocida en una herramienta que pueda repetirla sin cansarse y, sobre todo, sin improvisar. La API nos deja consultar elementos, leer datos, modificar el modelo y añadir funciones que Revit no ofrece tal como las necesita nuestro equipo.
Ahora bien: tener acceso a la API no convierte una mala idea en una buena automatización. Si nadie se pone de acuerdo sobre qué puertas deben llevar un código, el script tampoco lo sabrá. Y si una tarea tarda cinco minutos al mes, quizá no necesites un complemento, un instalador y tres reuniones de soporte. Vamos a ver dónde está la diferencia.
Tabla de contenidos
La API de Revit no es un botón más grande
Revit guarda un proyecto como un conjunto de elementos relacionados. Un muro no es solo lo que ves en planta: tiene una categoría, un tipo, parámetros de instancia, geometría y vínculos con otros objetos. Las vistas, las láminas y las tablas también son elementos. La API es el contrato que permite a nuestro código trabajar con esa estructura sin tener que simular clics por la interfaz.
Esto cambia la forma de plantear el problema. Cuando una persona selecciona “las puertas del núcleo” puede apoyarse en lo que ve y corregir sobre la marcha. Un programa necesita criterios explícitos: categoría, fase, nivel, familia, parámetro o cualquier combinación que realmente identifique ese conjunto. Si la selección está mal definida, la herramienta hará exactamente lo que le hemos pedido. Incluidos los disparates.
La ventaja es que, una vez expresado bien el criterio, podemos volver a aplicarlo. Podemos saber qué elementos se han revisado, qué regla ha fallado y qué valor se encontró. Esa trazabilidad suele valer más que el ahorro de clics, especialmente cuando el modelo debe pasar controles periódicos o el mismo proceso se repite en varios proyectos.
Antes de programar, busca una tarea que se deje explicar
Un buen candidato tiene entradas claras, una regla relativamente estable y un resultado que puedes comprobar. Detectar espacios sin código, crear vistas a partir de una convención o preparar una exportación con opciones acordadas son ejemplos razonables. “Mejorar la calidad del modelo” no lo es todavía. Suena bien en una reunión, pero no dice qué debe hacer el programa.
Yo empezaría escribiendo el proceso como si se lo fueras a pasar a una persona que no conoce el proyecto. Qué documentos intervienen, qué elementos entran, qué excepciones existen, qué cambia y cómo se revisa el resultado. Si dos compañeros interpretan la instrucción de forma distinta, no abras aún el editor de código. Primero hay que resolver esa conversación.
También conviene echar una cuenta sencilla. Frecuencia, tiempo manual, número de personas y coste de equivocarse. Una revisión de diez minutos que hace todo el equipo cada semana puede compensar. Una tarea de cuatro horas que ocurre una vez quizá se resuelva antes con un procedimiento. Y si el error puede modificar mil elementos, el ahorro previsto debe incluir pruebas, vista previa y mantenimiento; no solo el minuto glorioso en el que pulsas “Ejecutar”.
Dynamo, Python o C#: elige por el recorrido de la herramienta
Dynamo encaja muy bien cuando la lógica se entiende como una cadena visual: recoges elementos, filtras, transformas datos y produces un resultado. Puedes construir un prototipo rápido y enseñar el grafo a otro perfil BIM. El problema aparece cuando ese grafo crece hasta ocupar tres pantallas, depende de varios paquetes y contiene cables que cruzan como una instalación sin coordinar. Sigue siendo programación, aunque no haya muchas líneas de texto.
Python permite expresar mejor las condiciones, separar funciones y manejar estructuras de datos sin montar desde el primer día un complemento completo. Es una buena opción para scripts de equipo, controles y prototipos con cierta lógica. Pero “Python para Revit” no es un entorno único. El motor, las bibliotecas disponibles y la forma de ejecutar el código dependen de la herramienta que utilices. Antes de copiar un ejemplo, comprueba dónde se ejecuta y para qué versión fue escrito.
C# empieza a compensar cuando la automatización ya se parece a un producto: necesita una interfaz estable, instalación controlada, pruebas, registro de errores y mantenimiento entre versiones. Requiere más trabajo inicial, pero permite organizar una solución que va a crecer. No es el destino obligatorio de toda automatización. Un pequeño grafo bien documentado puede ser más profesional que un complemento enorme que nadie mantiene.
| Opción | La elegiría para | La señal de alarma |
|---|---|---|
| Dynamo | Flujos visuales y acotados que el equipo BIM necesita entender. | El grafo acumula ramas, paquetes y excepciones que nadie quiere tocar. |
| Python | Consultas, reglas y automatizaciones con lógica propia. | El script crece sin estructura y solo funciona en el ordenador de su autor. |
| C# | Complementos distribuidos, mantenidos y con una experiencia de uso cuidada. | Se construye una aplicación completa antes de validar el problema. |
Si dudas, empieza con la opción más pequeña que permita comprobar la idea. No necesitas diseñar la herramienta definitiva para descubrir que el parámetro que ibas a automatizar se llama de tres maneras distintas.
Primero lee el modelo; ya habrá tiempo de cambiarlo
La primera versión de una herramienta debería observar. Imagina que quieres normalizar el código de clasificación de las puertas. Empieza recuperando las puertas afectadas, leyendo el valor y generando un informe. Esa fase te obliga a descubrir si el dato vive en el tipo o en la instancia, si hay familias que lo guardan en otro sitio y cuántos valores inesperados existen.
La salida debe ayudar a tomar una decisión. Incluye el elemento, la regla aplicada, el valor encontrado y el motivo por el que aparece. “37 errores” es un dato espectacularmente poco útil. La persona que corrige necesita volver al objeto y entender si falta información, si el formato es incorrecto o si la herramienta no ha podido evaluar el caso.
Separa precisamente esos estados. Un elemento que incumple una regla no es lo mismo que uno que el programa no ha podido leer. Si ambos terminan en la misma columna —o peor, si el segundo se considera correcto— el control transmite una seguridad que no tiene. En BIM ya tenemos suficientes tablas con celdas verdes como para añadir otra que no sabemos interpretar.
Modificar el modelo exige una salida de emergencia
Revit controla los cambios mediante transacciones. Dicho de forma práctica: tu herramienta agrupa una serie de modificaciones y Revit necesita saber si debe confirmarlas o revertirlas. Es una protección útil, pero no sustituye una buena selección. Si eliges el conjunto equivocado y la operación es válida, puedes aplicar perfectamente el cambio incorrecto.
Por eso prepararía una vista previa antes de escribir nada. Cuántos elementos van a cambiar, cuáles se omiten y algunos ejemplos de valor actual y valor propuesto. Si ya existe información, la herramienta no debería sobrescribirla salvo que esa decisión sea explícita. El usuario tiene que poder cancelar sin dejar el modelo a medias.
Tampoco confiaría todo al botón Deshacer. Durante el desarrollo, trabaja con copias. En una herramienta compartida, registra qué versión se ejecutó, sobre qué documento y qué resultado produjo. Si algo falla en mitad del proceso, el mensaje debe explicar si no se aplicó ningún cambio o si hay que revisar una parte. Ocultar la excepción para que la ventana quede bonita es una forma bastante cara de fabricar misterio.
Vamos a poner un ejemplo: completar códigos de puertas
La petición inicial podría ser “rellena el código de todas las puertas”. Antes de escribir el bucle, necesitamos varias respuestas. ¿Todas significa también las existentes y demolidas? ¿El código depende del tipo o de la instancia? ¿Qué hacemos con los valores ya informados? ¿Hay puertas de armarios o paneles que deben quedar fuera? El código de la operación es sencillo; el criterio no.
Un flujo responsable puede dividirse en dos fases. La primera analiza y clasifica cada puerta como actualizable, omitida o dudosa. La segunda muestra el resumen y modifica solo los casos confirmados. Al terminar, genera un informe con el identificador del elemento, el valor anterior, el nuevo y la regla utilizada. Así puedes revisar una muestra sin volver a reconstruir mentalmente lo que hizo el script.
Para probarlo, crea casos deliberadamente incómodos: una puerta sin valor, otra con un código válido, un parámetro bloqueado, un elemento dentro de un grupo y una familia que usa una convención diferente. Esos ejemplos enseñan más que ejecutar directamente sobre el modelo grande y celebrar que no haya aparecido un mensaje de error. Que Revit siga abierto es un requisito bastante modesto para una herramienta de calidad.
El salto difícil: de mi script a nuestra herramienta
Un script personal puede depender de que tú sepas qué vista abrir, qué archivo escoger y qué aviso ignorar. En cuanto lo usa otra persona, todo ese conocimiento invisible se convierte en fallos. La herramienta debe validar sus entradas, explicar qué necesita y negarse a continuar si no puede garantizar el alcance. Ser estricta a tiempo resulta más amable que corregir el modelo después.
Conviene separar tres piezas: la lógica de negocio, el acceso a Revit y la interfaz. La regla “este código debe seguir este patrón” puede comprobarse sin abrir un proyecto. La API se ocupa de recuperar y modificar elementos. La ventana recoge opciones y muestra resultados. Si todo está mezclado en un único bloque, cualquier cambio obliga a probarlo todo a mano.
Usa control de versiones para el código, pero guarda también las configuraciones y los modelos mínimos de prueba. Documenta las versiones de Revit y los entornos que realmente has comprobado. Los ejemplos de internet envejecen y muchos materiales mezclan información técnica con promoción de cursos o herramientas. Cuando una decisión dependa de una clase, un evento o una compatibilidad concreta, contrástala con la documentación oficial de la versión que vas a soportar.
Lo que suele salir mal no es la sintaxis
Copiar un fragmento sin entender su contexto es un clásico. Puede asumir que hay un documento activo, utilizar referencias de otra versión o depender de un entorno distinto. Reduce el ejemplo hasta entender las entradas y añade una comprobación cada vez. Si pegas cincuenta líneas y funciona, todavía no sabes qué parte necesitabas. Si deja de funcionar dentro de seis meses, tampoco.
Otro problema es automatizar la consecuencia en lugar de la causa. Si cada semana corriges el mismo parámetro porque la plantilla lo crea mal, quizá la solución no sea un script más rápido. Puede ser cambiar la plantilla, la familia o la regla de trabajo. La API es muy buena repitiendo decisiones; también repite con una eficacia admirable nuestras malas decisiones.
Y queda el mantenimiento. Cambian versiones, parámetros, nombres de familias y personas. Antes de distribuir la herramienta, decide quién la mantiene, cómo se reporta un error y qué ocurre si deja de ser compatible. Si la respuesta es “ya llamarán a quien la hizo”, no tienes una herramienta de equipo; tienes una dependencia con icono.
Cuándo dejar la API tranquila
No usaría la API para una tarea excepcional que Revit ya resuelve de forma segura, ni para un proceso que cambia cada semana. Tampoco si nadie puede verificar el resultado o asumir el soporte. En esos casos, una tabla de control, un procedimiento o un prototipo de Dynamo pueden aportar más valor y menos deuda.
También hay problemas que viven fuera de Revit. Procesar IFC, sincronizar archivos en la nube o conectar un sistema empresarial puede requerir otros componentes y otras APIs. Meter toda la arquitectura dentro de Revit porque es la herramienta que tenemos abierta suele bloquear al usuario y complicar el despliegue.
La API merece la pena cuando puedes describir un problema estable, medirlo, probarlo y asignar a alguien que cuide la solución. Entonces dejas de programar una sucesión de clics y empiezas a empaquetar criterio BIM. Para mí, esa es la prueba de una buena automatización: hace una tarea concreta, cuenta lo que ha ocurrido y permite que otro profesional confíe en el resultado sin tener que llamar al autor cada martes.
Respuestas