Hot take: The Emerson 375 and 475 Field Communicators were the best handheld process tools ever built. Rugged, simple menu tree, worked with basically every HART device you'd walk up to, and the interface just makes sense.

Emerson pulling DD library support and sending them to end-of-life was a mistake. There are thousands of these still sitting in perfectly good working order in shops and trucks, and the only reason they're getting shelved is that they can't read newer devices anymore and can't be updated!

So here's my honest question: if you could load modern Device Descriptors onto your 375/475 again would you keep using yours? Or has everyone already moved on to a TREX or Laptop / Tablet setup?

If you could use current DDs on your Field communicator that load as "Un-Tested" built with a DD compiler that isn't bound by the original 2012 tool's limits, would you give it a try?

I'm at the point where I need some real world testing. If you've got a 375 or 475 (bonus if you've got a HART device or two to point it at that the October 2020 DD set didn't support) and you'd be willing to try loading some rebuilt DDs and report back, drop a comment.

Trying to figure out how much appetite is even out there for keeping these things alive. 1GB SD Card in your 375/475 communicator is a hard requirement.

https://preview.redd.it/wtd0o3dl6hjh1.png?width=1428&format=png&auto=webp&s=c96d8da9003b76808012de255000b3b885178de9

TL;DR  I own a couple of 2GIG GC2 alarm panels and got curious about what's actually inside the firmware image. So I wrote FWres — a little Python app that opens a panel firmware BIN, parses the container, and lets you browse the bitmaps, fonts, sounds, code and radio blobs. It reconstructs the panel's UI screens from the ARM code, plays, swaps and adjusts volume of the built-in sounds and it can back up and reflash the panel over the service port with a pile of safety rails. All on gear I own, on the bench, for tinkering and recovery. Not a break-into-someone-else's-house tool. Screenshots + honest caveats below. The GC2 and GC2E are susceptible to BRICKING. USE AT OWN RISK and Have a JTAG handy

https://github.com/afallows/2gig_fwres

1. Firmware View

The panel's screens aren't stored as images — they're built at runtime by constructor calls in the ARM code. So FWres reads those calls and reconstructs each screen, then draws it on a canvas at 1x–4x zoom right next to a widget-tree inspector.

•      Pick a widget in the tree → it gets outlined on the render.

•      Hover the render → the matching widget highlights in the tree.

•      Either one can jump straight to the bitmap or font record it references, back in the main resource tree.

Big caveat, and I want to be upfront about it: this is a reconstruction, not a screenshot. The panel is 480×272. Anything compose() had to approximate — widgets with no recovered position, strings it couldn't place, guessed fonts, invisible colors, low decoder confidence — is spelled out under the render rather than hidden behind a clean-looking image. I'd rather show you an ugly-but-honest render than a pretty lie.

This is the heart of it. You point FWres at a GC2/GC2e firmware .bin, it reads the container format, and you get a browsable tree of everything inside — about 685 records, grouped by kind:

•      Bitmaps — the icons and images the panel draws

•      Fonts — with a live ASCII specimen + a “type here” preview

•      Audio — the chimes, voice prompts and DTMF blips

•      Code — the ARM blobs

•      Radio — the transceiver-side bits

https://preview.redd.it/nug8mmsrf5jh1.png?width=1065&format=png&auto=webp&s=240ebd96da671e9a09a79997fd9fc1b84391f7ab

2. Screen viewer (Screens tab)

The panel's screens aren't stored as images — they're built at runtime by constructor calls in the ARM code. So FWres reads those calls and reconstructs each screen, then draws it on a canvas at 1x–4x zoom right next to a widget-tree inspector.

•      Pick a widget in the tree → it gets outlined on the render.

•      Hover the render → the matching widget highlights in the tree.

•      Either one can jump straight to the bitmap or font record it references, back in the main resource tree.

Big caveat, and I want to be upfront about it: this is a reconstruction, not a screenshot.

https://preview.redd.it/kx661hslg5jh1.png?width=1295&format=png&auto=webp&s=edd24ef69527471ac0dade0769cb7e3a1d4abf3b

3. Audio replacement — yes, you can change the chime (and quiet those damn keypresses! That's you dtmf_5)

This is the feature that makes people at the bench go “wait, really?” You can decode and play the built-in sounds (they're panel-native 8-bit PCM at 8 kHz), see the waveform, and then replace a clip from a WAV file. FWres converts your WAV down to the panel's native format, previews it, and queues it as a pending change.

Nothing touches the loaded image or any file until you hit “Generate Binary.” A replacement is queued as a patch, previewed through the same allocator the rebuilder uses, and shown in a Pending Changes panel. The waveform and Play button switch to the queued clip so you can hear it before you commit. Generate Binary then rebuilds a CRC-resealed image — defaulting to <image>_modified.bin beside the original, and it makes you confirm if you aim it back at the input path. If the engine refuses a replacement, it shows you the refusal verbatim — an image that boots then bricks is way worse than a “no.”

A Volume % control on the Audio tab. Instead of swapping the whole clip, you scale a built-in sound's volume by a percentage (50 = half amplitude / about -6 dB, clamped at the rails, byte-identical at 100) about the 0x80 bias, Preview it, and Apply to queue it. Because the scaled clip is the same length, the rebuild is the pure in-place case — volume down and only the CRCs get resealed.

https://preview.redd.it/2b6dle9zh5jh1.png?width=1293&format=png&auto=webp&s=b4894a2d262c46e9c9a55ddc95392b722a71ada3

5. Diagnostics tab — Firmware Flash / Backup

This tab speaks the service-port protocol (the one RFLASHD uses) over a COM port. Pick a port and baud (defaults to 115200), power down the panel, remove the battery and power up while connecting to knock the panel into its bootloader, and you can:

•      Back up the flash to a file (config area, firmware image, panel data, or the full 8 MiB)

•      Restore / reflash the firmware container

•      Change the installer code

•      Change user codes

•      Change the customer / dealer code

This is the tab that can be dangerous, and the one required to make any changes to your panel. A failure here can BRICK YOUR PANEL requiring JTAG to recover.

•      Config edits are always read → erase → write → verify over the whole 4 KiB sector, with the previous contents saved to disk first (NOR flash only clears bits, so writing over live data would corrupt it).

•      Reflash refuses any image carrying data above 0x7B8000 — that's where the codes and the Z-Wave home ID live, and this tool never programs that region. Restore-panel-data is a separate, bounds-checked path.

•      Long operations run on a worker thread with progress and a Stop button, so the UI never freezes mid-flash, and reflash makes you literally type the word REFLASH.

https://preview.redd.it/xxbh48a0l5jh1.png?width=1995&format=png&auto=webp&s=6a5e5dcdbd7c88f1206fe52d988b983ae573a41a

Known issues

•      Controller mode is WIP and flaky —I only built this because the digitizer on my bench unit is NFG. Doesn't always work. Doesn't allow button presses on all screens, mainly just for fun

•      Some records still have no dedicated decoder — you get hex + entropy for those, which is fine, but I'd like proper views for the last stragglers.

•      Diagnostics is GC2 (CP1 HW1 and HW2CostDown Board)-tested — the memory map and flash geometry are pinned to my CP1 board; GC2e specifics still need confirming on hardware, but Based on Firmware assumed to be the same.

I have been working on repurposing the Powerley EnergyBridge 2 as a local home-automation controller that can be interfaced directly with homeassistant.

So far I have two working access paths:

1. A local method using the board’s UART to open up the local MQTT broker on port 2883 so it allows readwrite of all nucleus parameters.
2. A sealed-unit method that uses the provider authentication flow and the bridge’s AWS IoT certificate.

I have also built a browser-based front end for the Nucleus Z-Wave, Zigbee HA and Zigbee Smart Energy services running on the EnergyBridge.

Important disclaimer: This work is being done on hardware I own, using my own utility account and certificates issued for my own EnergyBridge. Do not reuse, share or attempt to obtain another customer’s credentials or device certificates.

Local recovery through UART

The EnergyBridge 2 has accessible UART pads.

I soldered leads to one of these points and connected them to a 3.3 V USB-to-TTL adapter.

Do not connect the adapter’s 5 V or 3.3 V supply line. Only connect:

EnergyBridge GND  → adapter GND
EnergyBridge TXD  → adapter RX
EnergyBridge RXD  → adapter TX

I used Tera Term with:

115200 baud
8 data bits
No parity
1 stop bit
No flow control

After powering on the EnergyBridge, press a key in Tera Term when this appears:

U-Boot 2015.04imx_v2015.04_4.1.15_1.2.0_ga+gede7538 (Dec 15 2016 - 15:19:26)

CPU:   Freescale i.MX6SX rev1.3 at 792 MHz
CPU:   Temperature 37 C
Reset cause: POR
Board: Powerly MX6SX Energy Bridge 2
I2C:   ready
DRAM:  512 MiB
PMIC:  PFUZE100 ID=0x11
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Error: FEC address not set.

Normal Boot
Hit any key to stop autoboot:  3

That puts you at the U-Boot prompt.

Booting a rescue environment

The stock system is not particularly useful for password recovery because booting with init=/bin/sh does not create a usable /dev environment.

Instead, I created a small BusyBox-based rescue initramfs wrapped as a legacy U-Boot ramdisk image.

From U-Boot:

setenv bootargs 'console=ttymxc0,115200 rw'
fatload mmc 1:1 0x80800000 zImage
fatload mmc 1:1 0x83000000 imx6sx-eb2.dtb
loady 0x84000000

When U-Boot reports that it is ready for a YMODEM download, use:

Tera Term
→ File
→ Transfer
→ YMODEM
→ Send

Select the rescue image, such as:

eb2-rescue-agent.uImage

Once it finishes transferring:

bootz 0x80800000 0x84000000 0x83000000

This boots entirely into RAM and drops to a root rescue shell.

Opening the local MQTT broker

The EnergyBridge has two A/B root filesystems:

Bank A rootfs: /dev/mmcblk3p5
Bank B rootfs: /dev/mmcblk3p6

The corresponding boot partitions are P1 and P2.

From the rescue environment, mount the bank you want to modify. It is very likely that your energybridge is running on bank B /dev/mmcblk3p6 with version 1.10.17

mkdir -p /mnt/p5 /mnt/p6

mount -o rw /dev/mmcblk3p5 /mnt/p5
mount -o rw /dev/mmcblk3p6 /mnt/p6

The local Mosquitto listener is normally available on port 2883, but its anonymous ACL only exposes a small subset of the MQTT tree.

topic read event/metering/#

Back up the ACL and open it on the target bank:

cp /mnt/p6/etc/mosquitto/anonymous_acl.conf \
   /mnt/p6/etc/mosquitto/anonymous_acl.conf.bak

echo 'topic readwrite #' \
   > /mnt/p6/etc/mosquitto/anonymous_acl.conf

Then:

sync
umount /mnt/p5
umount /mnt/p6
reboot -f

After the selected bank boots, the full Nucleus MQTT request, response and event trees become available through port 2883.

A quick test from another computer:

mosquitto_sub -h ENERGYBRIDGE_IP -p 2883 -t '#' -v

And a simple publish test:

mosquitto_pub -h ENERGYBRIDGE_IP -p 2883 \
  -t 'test/x' -m 'hello'

Be aware that this change provides unrestricted anonymous MQTT access to anyone who can reach that port. This is suitable for a bench network or isolated IoT VLAN, but I would not expose it to an untrusted LAN or the internet.

A method that does not require opening the EnergyBridge

The more interesting discovery is that local root access is not the only way to communicate with Nucleus.

I captured the authentication flow of my own utility-provider application using a controlled MITM/lab setup. The authentication flow ultimately returns the certificate material used by the application to connect to the AWS IoT MQTT service.

The resulting connection uses:

MQTT v5
TLS
Mutual certificate authentication
device/<bridge-id>/...

Once authenticated with the certificate issued for your own EnergyBridge, the same Nucleus request and event topics that can be made available locally can also be accessed through AWS.

This creates a possible sealed-unit route:

Utility-provider login
→ authorization response
→ Powerley device lookup
→ EnergyBridge PKCS#12 certificate bundle
→ client certificate/private key
→ AWS IoT MQTT
→ Nucleus Z-Wave and Zigbee topics

The utility password does not need to be stored by the application. The user signs in on the provider’s own page, and the application handles the returned authorization result.

Only the BC Hydro provider flow has been verified so far.

Other Powerley utility deployments may use a similar architecture, but they could have different OAuth clients, endpoints, certificate passwords, broker policies or topic permissions. They should be treated as unverified until someone captures and documents their own provider flow.

This approach means it is be possible to access the Z-Wave and Zigbee devices through AWS for a Home Assistant integration without opening or rooting the EnergyBridge at all.

Nucleus Home Automation UI

As a proof of concept, I built a local browser interface around the Nucleus MQTT protocol, this can be ported as a home-assistant integration to use the EnergyBridge as a MQTT-Zwave / MQTT-Zigbee Bridge.

It is not talking directly to the Z-Wave or Zigbee radios. Nucleus continues to own both controllers, so devices can continue operating through the original EnergyBridge services while also being controlled from the new interface.

Current features include:

• Combined Z-Wave and Zigbee device list
• Binary switches and dimmers
• Locks and barrier devices
• Thermostats
• Sensors, meters and battery values
• Device details and raw values
• Device renaming
• Z-Wave S2 inclusion and DSK handling
• Exclusion and abort
• Controller diagnostics
• Network healing
• NIF broadcast
• Associations
• Configuration parameter editing
• Bundled Z-Wave JS device configuration database
• Zigbee HA joining and removal
• Zigbee endpoints, profiles, clusters and attributes
• Raw MQTT request console
• Local EnergyBridge MQTT connection
• Provider cloud/AWS IoT connection

The interface is intentionally similar to Z-Wave JS UI, but the backend translates the controls into native Nucleus MQTT requests.

The first attached screenshot shows a UltraPro Light Switch discovered through Nucleus, including its current state and basic controls being controlled via AWS MQTT

https://preview.redd.it/0oivlxj3kieh1.png?width=2551&format=png&auto=webp&s=edb4deee07a55db3082cf0cbf1196a51fbb29ed0

The second screenshot shows the Z-Wave network management page with secure inclusion, DSK/PIN entry, exclusion, diagnostics, network healing and NIF broadcast.

https://preview.redd.it/o8g67kozjieh1.png?width=1795&format=png&auto=webp&s=5f3c44405bf60596cbe86dc01aee30a72ac79727

I have intentionally not included controller-level operations such as a full Z-Wave controller factory reset in the front end

Where this is heading

The next steps are:

• Package the local and AWS paths into a cleaner Home Assistant integration.
• Add MQTT discovery or direct Home Assistant entities.
• Expand Zigbee HA controls where Nucleus exposes safe commands ( I don't have any zigbee devices currently)
• Document provider-specific authentication flows.
• Determine which other Powerley utility deployments can obtain their own bridge certificate through the same general flow.
• Discover a persistent configuration method that survives firmware updates for local control.

This hardware contains a capable Z-Wave controller, Zigbee HA coordinator and Zigbee Smart Energy radio. It would be unfortunate for all of that hardware to become unusable simply because the original consumer application or cloud service changes.

I am interested to hear from anyone else with an EnergyBridge 2, especially units from providers other than BC Hydro. Please do not post private keys, access tokens, serial numbers or utility-account information.