6. INTERNAL firmware current

6. INTERNAL firmware (current)

Firmware labeled as INTERNAL lets the adapter operate independently as an eBUS participant — no external control software like ebusd is needed. External eBUS clients such as ebusd are still supported; they are optional and can connect to the same TCP ports as in bridge mode (see Firmware modes). It plays two roles on the bus:

• Passive listener — observes all bus traffic, matches telegrams against the command store, and decodes known ones into values (published via MQTT, readable via HTTP).
• Active master — participates under its own eBUS address: sends cyclic polls (asks devices for values), writes (sets values), and scans (device identification), arbitrating for the bus like any physical device.

To clarify: there is no automatic configuration like in ebusd. Commands must be installed into the internal command store before their results are evaluated, published via MQTT, or readable via HTTP.

This firmware is powered by the ebus library: C++ library for eBUS communication.

In INTERNAL mode, the TCP listeners and external eBUS client handling are provided by the eBUS library's ClientManager. The adapter's own participant and these optional clients share the same bus; the TCP interfaces are distinct from the firmware's HTTP/web UI and MQTT interfaces (see 6.3 HTTP & web UI and 6.4 MQTT).

Talking ebusd to the adapter

Same ports, same timing rules as bridge mode — see 5. Bridge mode, section Timing over WiFi.

Channel rule

• Machine data → MQTT push (values, errors, discovery).
• Human/debug → HTTP pull (health, metrics, logs, values).
• Exceptions: the web UI composes views from HTTP, and liveness (online/offline) is announced on both channels.

Time (SNTP, internal firmware only)

Wall clock comes from SNTP (Configuration page, section SNTP): Enabled (sntpEnabled), Server (sntpServer, default pool.ntp.org), Timezone (sntpTimezone, default UTC0). It drives console timestamps (ebusd-comparable), tap correlation, and cron wall-clock schedules. Unsynced, timestamps fall back to boot-relative [+s.ms] — values and polling are unaffected.

First boot checklist

Condensed path — the full walkthrough with diagnostics is 6.6 First boot & troubleshooting:

1. Flash, then open the web UI and check the Bus section. The default address is ff; set one suitable for your environment (e.g. 30 — ff is reserved for service devices). Leave scan on startup off unless you need it.
2. Install a command set (via HTTP upload or MQTT), matching your devices (any filename — commands.json is just an example).
3. Watch Logs: valid telegrams appear as master / slave hex lines.
4. Watch Values: ages should stay within one poll cycle.
5. Set up MQTT if you want pushes and Home Assistant discovery.

Further pages (6.x)

• 6.1 eBUS configuration
• 6.2 Command definition
• 6.3 HTTP & web UI
• 6.4 MQTT
• 6.5 Home Assistant (needs MQTT)
• 6.6 First boot & troubleshooting

Reference (ships with code)

Curl-level command reference, versioned with the handlers it documents: doc/commands.md in the repository.