General D-Bus adapter design thoughts and requirements

[hn]

Note

This text has been migrated from here and may be a good starting point if somebody wants to design a new solution.

Thankfully, several people have offered to help with a PCB design for a proper D-Bus adapter. I’d like to use this issue to collect and agree on the requirements for the adapter. Please feel free to add your thoughts or suggestions. I’m by far not an expert in these topics, so feedback and ideas are very welcome.

Minimum requirements

• Design based on a popular and widely available microcontroller (ESP32 preferred due to its native ESPHome support and the compatibility of existing software components), ideally a variant with low peak current consumption as raw CPU performance is not critical for D-Bus parsing
• On-board DC-DC converter to step down from VBUS supply voltage
  (9–13.5 V, or preferably a wider range such as 9–30 V). Update: for extractor hoods, a VBUS voltage of 5V has been reported.
• Open-drain level shifter to r/w interface the 5V D-Bus DATA wire with the MCU's GPIOs
• A switchable 10kΩ pull-up to 5V for the DATA wire
• The D-Bus must not be disturbed (e.g., pulled low) while the MCU's GPIO pins are in an unconfigured state (e.g., during boot)
• Proper OSS license and access to all source files

Nice-to-haves

• On-board D-Bus RAST connector, similiar to the COM1 PCB. This only requires the appropriate PCB traces; the connector housing itself could likely be 3D-printed.
• Additional, parallel-accessible breakout pins (you can never have enough, e.g. for a logic analyzer) for GND / VBUS / 5V / 3V3 / DATA:
  • via pin header for Dupont wires
  • via JST connector
  • or both?
• Fully assembled PCB, including all components, by a well-known PCB manufacturing and assembly service
• USB i/f for easy MCU flashing and serial debugging
• LED (D-Bus activity) to MCU GPIO
• LED (status) to MCU GPIO
• pin header to spare MCU GPIOs (for whatever they are needed later)
• For some people, a LoRaWAN interface might be an interesting option, since household appliances are often located in the basement, where WiFi reception tends to be poor.
• Form factor compatible with the COM1 PCB, allowing the adapter to act as a drop-in replacement
  (this imposes constraints on PCB height and width due to the limited space inside the COM1 housing)

Additional Notes

• There will most likely need to be a cable between the adapter and the appliance’s power board, both because of space constraints inside the appliance and to improve WiFi reception — for example, the COM1 module sits under the kickplate, where the metal of the appliance housing does not block the signal.
• Please consider printing warnings on the PCB, for example that the USB port should not be connected at the same time the adapter is attached to the appliance.
• With a 20+ year old washing machine and an ESP8266, I ran into issues because the ESP8266 drew too much current at peak (current spikes of up to 430mA during the WiFi connection phase), which caused the machine to brown out. Hopefully, this will not be an issue with an ESP32 and a better overall design.