Si estás leyendo esto, es probable que hayas montado un bus con varios dispositivos, como los populares medidores PZEM, y te hayas encontrado con un comportamiento extraño: todo funciona a medias. Lees datos sin problema, pero en el momento de intentar algo más complejo, como cambiar la dirección de un dispositivo (con el comando setAddress), todo falla.

Lo más frustrante es que, a menudo, el culpable no es un componente defectuoso, sino un pequeño detalle de diseño que, aunque necesario, introduce un efecto secundario inesperado. Este es el caso de los diodos en un bus de colector abierto con múltiples dispositivos.Analicemos por qué ocurre esto y cómo diagnosticar el problema.

La Necesidad de los Diodos: Protegiendo el Bus

En un bus donde varios dispositivos comparten la misma línea de comunicación y usan salidas de colector abierto (o drenaje abierto), los diodos son esenciales. Su función es evitar que un dispositivo que está en reposo (con su salida en alta impedancia) bloquee la línea de pull-up cuando otro dispositivo intenta comunicarse.

La orientación correcta, y la que seguramente tienes, es con el cátodo hacia el pin TX del PZEM y el ánodo conectado al bus común. Esta es la configuración estándar para que un bus de colector abierto funcione correctamente. Sin estos diodos, el bus quedaría permanentemente bloqueado.

Por lo tanto, el problema no es la presencia de los diodos en sí, sino un efecto secundario de los mismos que interfiere con la comunicación bidireccional completa que exige el protocolo.

El Diagnóstico: Por qué la Lectura es Posible y la Escritura No

Para entenderlo, veamos qué sucede en los dos escenarios típicos con un bus que tiene esta topología.

1. Lectura por Broadcast (Funciona sin problemas)

Imagina que tu ESP32 envía una solicitud de lectura a todos los dispositivos (broadcast).

1. La orden sale: La señal de tu ESP32 viaja directamente por la línea TX hacia los pines RX de todos los PZEM. No hay ningún obstáculo.
2. La respuesta llega (a medias): El PZEM que tiene la dirección solicitada procesa el comando y debe responder por su línea TX.
   • Para enviar un ‘0’ lógico (nivel bajo), el pin TX del PZEM se conecta a tierra. El diodo conduce y la señal llega limpiamente al bus y al ESP32. Perfecto.
   • Para enviar un ‘1’ lógico (nivel alto), el pin TX del PZEM se pone en alta impedancia (desconectado). Aquí es donde el diodo de ese PZEM se polariza inversamente, actuando como un interruptor abierto y bloqueando la señal.

En este modo de broadcast, el ESP32 no espera una respuesta directa de un único dispositivo. El sistema puede funcionar porque el flanco de bajada (‘0’) es lo suficientemente claro para que el maestro interprete la comunicación, aunque la señal esté degradada. Por eso no se detecta un fallo inmediato.

2. Escritura con Confirmación (setAddress) (Falla estrepitosamente)

Aquí es donde se revela el verdadero problema. El comando setAddress no es una simple orden que se envía y se olvida. El protocolo Modbus-RTU, que utilizan los PZEM, exige una confirmación.

1. El ESP32 ordena: Envía el comando para cambiar la dirección al PZEM M3.
2. El PZEM M3 confirma: Para que el comando sea exitoso, el PZEM M3 debe enviar una trama de confirmación (ACK) de vuelta al ESP32.
   • El ‘0’ sí pasa: Para enviar un ‘0’ lógico, el TX del M3 se pone a tierra, el diodo conduce y la señal llega al ESP32. Perfecto.
   • El ‘1’ es bloqueado (¡problema!): Para enviar un ‘1’ lógico, el TX del M3 se pone en alta impedancia. En ese instante, el diodo del M3 se polariza inversamente y bloquea completamente la señal. La línea de datos se queda «flotando», sin que el pull-up pueda subirla a nivel alto.

El resultado es que el ESP32 nunca recibe los bits en ‘1’ que forman parte de la trama de confirmación. La comunicación se corrompe, el checksum no coincide y el comando setAddress falla.

En Resumen

El diodo actúa como una válvula unidireccional desde la perspectiva del PZEM hacia el bus. Permite que el PZEM tire de la línea a tierra (para enviar un ‘0’), pero le impide soltarla para que la resistencia de pull-up la lleve a estado alto (para enviar un ‘1’). Este comportamiento, que es inherente a la forma en que están colocados los diodos, es letal para un protocolo bidireccional y basado en flancos como Modbus.

Ahora que sabes que los diodos son la causa del bloqueo, el siguiente paso es buscar una solución. ¿La más común? Implementar un puente removible de modo que cuando vayamos a programar la dirección de un modulo PZEM podemos cortocircuitar el diodo de modo que una vez programado podamos liberar ese cortocircuito en su operación normal. Algo mucho mas avanzado es montar un circuito que convierta las señales unidireccionales en verdaderamente bidireccionales, como un adaptador de nivel lógico o un circuito discreto con transistores. Pero esa, como suele decirse, es una historia para otro post.