fix(e290): eink ghosting, missing USB interface, CI build naming, and add WiFi companion env - #3418
Open
willumpie82 wants to merge 4 commits into
Open
willumpie82 wants to merge 4 commits into
willumpie82 wants to merge 4 commits into
Conversation
Both drivers permanently stayed in fastmode (partial refresh) after begin(), so the panel's residual charge accumulated update after update, causing the display to gradually darken over time. Force a full refresh every 30 updates to clear it before returning to fast partial-refresh mode. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… convention
The Heltec_E290_companion_usb environment never defined
ENABLE_USB_INTERFACE, so after the companion interfaces were
refactored to use MultiSerialInterface, this build registered no
interface at all (no BLE, no USB) - the app/HA could see the serial
port but never get a response, and BLE was never advertised.
Also rename Heltec_E290_companion_ble/_usb to
Heltec_E290_companion_radio_ble/_usb so they match the
*_companion_radio_{ble,usb} suffix build.sh's
get-companion-firmwares-to-build looks for. Without the "_radio_"
infix these envs were silently skipped by CI, so no official E290
companion binary was ever built or released, and it doesn't appear
on the web flasher.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
willumpie82
changed the title
Adds Heltec_E290_companion_radio_wifi, mirroring the pattern used by other boards' WiFi companion envs (compile-time WIFI_SSID/WIFI_PWD). Also keeps ENABLE_USB_INTERFACE so the device can still be configured over USB while WiFi/TCP handles the actual companion connection via MultiSerialInterface. Useful when the companion node needs to sit somewhere with good LoRa reception but no easy USB/host access (e.g. a repeater-like companion that a Home Assistant instance talks to over the network), and also sidesteps the meshcore-py DTR-on-serial-connect bug entirely since no serial transport is involved. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
willumpie82
changed the title
Link meshcore_py#105 (DTR forced low on serial connect breaks native USB-CDC boards) as the concrete motivation for the WiFi/TCP env. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
E290DisplayandE213DisplaycallfastmodeOn()once inbegin()/turnOn()and never leave partial-refresh mode. Repeated partial refreshes never fully re-polarize the panel, so residual charge accumulates and the whole display gradually darkens/ghosts over time.endFrame()now tracks updates since the last full refresh and, every 30 updates, does a full refresh (fastmodeOff()→update()→fastmodeOn()) before returning to fast partial-refresh mode.Heltec_E290_companion_usbnever definedENABLE_USB_INTERFACE. After the companion interfaces were refactored to useMultiSerialInterface, this meant the build registered no interface at all (no BLE, no USB) — the OS would still enumerate the USB serial port, but nothing ever responded to the companion app/Home Assistant's connect handshake, and BLE was never advertised. Added the missing flag.Heltec_E290_companion_ble/_usbrenamed toHeltec_E290_companion_radio_ble/_usbto match the*_companion_radio_{ble,usb}suffix thatbuild.sh'sget-companion-firmwares-to-build(used bybuild-companion-firmwares.yml) looks for. Without the_radio_infix, these environments were silently skipped by CI — no official E290 companion binary has ever been built or released, which is also why it doesn't appear on the web flasher.Heltec_E290_companion_radio_wifi, mirroring the WiFi companion pattern used by other boards (compile-timeWIFI_SSID/WIFI_PWD), withENABLE_USB_INTERFACEalso kept on so the device can still be configured over USB while WiFi/TCP handles the actual companion connection viaMultiSerialInterface. Useful for placing the node somewhere with good LoRa reception but no convenient USB/host access. It also sidesteps meshcore-py#105 —meshcore-py>=2.3.10 forces DTR low on serial connect, which native USB-CDC boards like this one read as "no host attached" and never reply to — since WiFi/TCP doesn't use a serial transport at all.Test plan
Heltec_E290_companion_radio_usb,Heltec_E290_companion_radio_ble,Heltec_E290_companion_radio_wifi, andHeltec_E213_companion_radio_usb— all compile cleanly.bash build.sh get-companion-firmwares-to-buildnow lists both renamed E290 envs.Heltec_E290_companion_radio_usb, confirmed companion app (app.meshcore.nz) connects and syncs correctly over USB.Heltec_E290_companion_radio_wifiwith real credentials locally, confirmed the device joins WiFi, displays its IP on-screen, and Home Assistant connects over TCP instantly.🤖 Generated with Claude Code