ISSUE-4339: Add Sub-GHz protocol for Honeywell 5834-4

[herbenderbler]

What's new

Add Sub-GHz Protocol: Honeywell 5834-4 Wireless Security Keyfob

Problem

There is no support for the Honeywell 5834-4 wireless security keyfob in the Sub-GHz application. This 4-button keyfob (Arm Away, Arm Stay, Disarm, Panic) operates at 345 MHz using AM/OOK modulation and is part of the Honeywell 5800 wireless security series. Users cannot decode, save, or generate these signals.

This PR closes #4339

Solution

Added a new dedicated Sub-GHz protocol (Honeywell5834) with full encoder, decoder, and "Add Manually" support.

Why a new protocol instead of extending the existing Honeywell WDB? The 5834-4 keyfob and the WDB doorbell share the same 5800-series frame structure, but they differ in meaningful ways:

• Frequency: 345 MHz (5834-4) vs 916.8 MHz (WDB)
• Preset: AM650 vs AM270
• Timing: Different te_short/te_long/sync values derived from real captures
• Semantics: The state byte encodes security buttons (Arm/Disarm/Panic) rather than doorbell chime patterns, and the display needs to show button names and battery status rather than doorbell-specific fields

Keeping them separate avoids overloading the WDB protocol with branching logic and makes each protocol's decoder state machine, timing constants, and display formatting clean and self-contained.

What Changed

New files:

• honeywell_5834.h — Protocol header
• honeywell_5834.c — Full implementation: 4-step decoder state machine (sync gap → sync pulse → bit accumulation → validation), PWM encoder, parity check, button mapping, get_string() display formatting

Embedded optimizations (Honeywell 5834-4)

Encoder RAM

The transmit buffer is sized to the exact 48-bit frame: H5834_UPLOAD_MAX = 3 + 48×2 (99 LevelDuration entries) instead of 128, saving ~116 bytes of heap per encoder instance when sending.

Modified files:

• protocol_items.h — Added #include "honeywell_5834.h"

• protocol_items.c — Registered &subghz_protocol_honeywell_5834 in the protocol registry

• subghz_custom_event.h — Added SubmenuIndexHoneywell5834_345 enum value

• subghz_scene_set_type.c — Added "Honeywell5834_345" menu entry under Add Manually; generates a random 20-bit serial with default "Arm Away" button and correct parity

• lib/subghz/protocols/honeywell_5834.c:

  • Added the H5834_UPLOAD_MAX constant and a comment (sync + 48 data bits × 2 = 99 entries).
  • Encoder alloc: size_upload is set to H5834_UPLOAD_MAX and the buffer is allocated with that size instead of 128.
  • subghz_protocol_encoder_honeywell_5834_get_upload: The “size exceeds buffer” check compares against H5834_UPLOAD_MAX instead of instance->encoder.size_upload; the comment was updated to reference the 48-bit frame and H5834_UPLOAD_MAX.

Protocol Details

Parameter	Value
Frequency	345.000 MHz
Modulation	AM/OOK (AM650 preset)
Encoding	Pulse-width modulation (short pulse = 0, long pulse = 1)
Frame size	48 bits
Timing	te_short=160µs, te_long=290µs, te_delta=80µs
Sync	710µs gap + 300µs pulse
Data layout	20-bit serial | device type/channel/state/loop | parity bit (LSB)
Buttons	0x40=Arm Away, 0x20=Arm Stay, 0x10=Disarm, 0x80=Panic

Verification

• All firmware variants compile cleanly
• ./fbt lint_all passes (C format, Python format, image lint)
• All 327 unit tests pass on physical hardware
• Manual testing on Flipper Zero: Add Manually → Save → Load → Send round-trip verified; display renders correctly with no text overlap

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[csptechnologies]

How would I test this out?

[herbenderbler]

How would I test this out?

Since I'm in the US, these were the steps I had to take for as comprehensive of an end-to-end test as I could get. Let me know if you run into any issues. It's altogether possible I forgot to document a step 😅

Testing Honeywell 5834-4 SubGHz TX on a US Flipper

The Honeywell 5834-4 preset uses 345 MHz, which is outside US SubGHz transmit bands (304–322 MHz, 433–435 MHz, 915–928 MHz). To test transmit on a US Flipper, the firmware uses a region override: when built with FURI_HAL_REGION_OVERRIDE_UNLOCKED, the device reports hardware region "00" (Unknown) so SubGHz uses the permissive region and allows TX on 345 MHz.

Implementation: In targets/f7/furi_hal/furi_hal_version.c, furi_hal_version_get_hw_region() is compiled so that when FURI_HAL_REGION_OVERRIDE_UNLOCKED is defined it returns FuriHalVersionRegionUnknown (0) instead of the OTP value. Region 0 uses furi_hal_region_zero (0–1000 MHz allowed for TX).

---

Testing steps

1. Checkout the branch

cd /path/to/flipperzero-firmware
git checkout ISSUE-4339/add-honeywell-5834-4

2. Build with the region override

Use the same --extra-define for every build/flash so the override is active:

./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED

For a full updater package (firmware + resources, e.g. for USB install):

./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED updater_package

3. Flash the Flipper

Option A — USB (Flipper on, connected via USB):

./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED flash_usb

Option B — Debugger (ST-Link or compatible probe):

./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED flash

If you built updater_package in step 2, you can instead install the resulting package from the dist folder via qFlipper or the device’s update flow.

4. (Optional) Run SubGHz unit tests

Build and flash with the unit-tests app set and the same region override:

./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED FIRMWARE_APP_SET=unit_tests updater_package

Flash that build, ensure SD resources are present (e.g. from the built package), then connect via CLI and run:

unit_tests test_subghz

Or run only the Honeywell 5834 tests:

unit_tests subghz_decoder_honeywell_5834_test
unit_tests subghz_encoder_honeywell_5834_test

These tests do not transmit over the air; they use files on the SD card.

5. Test SubGHz TX at 345 MHz on the device

1. Open SubGHz.
2. Add new → Set type → Honeywell5834_345 (creates a key at 345 MHz).
3. Save the key (name as you like).
4. Open the saved key and choose Send.

TX should no longer be blocked; the Flipper will transmit on 345 MHz. You can verify with a receiver or a second device running SubGHz Read on 345 MHz.

6. Restore normal region when done testing

Rebuild and reflash without the override so the device again uses its real hardware region (e.g. US):

./fbt updater_package
./fbt flash_usb

(Or use flash if you use a debugger.)

---

Summary

Step	Action
1	Checkout ISSUE-4339/add-honeywell-5834-4.
2	Build with ./fbt --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED (or updater_package).
3	Flash with the same --extra-define (flash_usb or flash).
4	(Optional) Build/flash with FIRMWARE_APP_SET=unit_tests and run unit_tests test_subghz.
5	On device: SubGHz → Add new → Set type → Honeywell5834_345 → Save → Send.
6	When finished, rebuild and flash without --extra-define=FURI_HAL_REGION_OVERRIDE_UNLOCKED.

Important: The override is for development and testing only. Do not leave the device on an unlocked build for normal use; transmitting outside your region may violate local regulations.

[csptechnologies]

Is there any way you could add this into the unleashed firmware fork?

[herbenderbler]

Is there any way you could add this into the unleashed firmware fork?

Did everything work for you? Exactly which physical card did you use to test?

[csptechnologies]

Yep! But unfortunately when I upgraded back to unleashed, the flipper could not parse the file.

…

________________________________ From: Herbenderbler ***@***.***> Sent: Saturday, March 14, 2026 12:15:59 AM To: flipperdevices/flipperzero-firmware ***@***.***> Cc: Ryan Kim ***@***.***>; Comment ***@***.***> Subject: Re: [flipperdevices/flipperzero-firmware] ISSUE-4339: Add Sub-GHz protocol for Honeywell 5834-4 (PR #4348) [https://avatars.githubusercontent.com/u/2105?s=20&v=4]herbenderbler left a comment (flipperdevices/flipperzero-firmware#4348)<#4348 (comment)> Is there any way you could add this into the unleashed firmware fork? Did it work for you? Momentum pulls in these upstream changes. Ideally this PR will land, get merged, and pulled in downstream. — Reply to this email directly, view it on GitHub<#4348 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIJMCWYDJKWITPIIO7UHT7L4QTTI7AVCNFSM6AAAAACWO2PJRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJZGU3TSNZRGU>. You are receiving this because you commented.Message ID: ***@***.***>

[herbenderbler]

Yep! But unfortunately when I upgraded back to unleashed, the flipper could not parse the file.

It looks like Unleashed pulls in the upstream changes from here. I think the best path forward is to ask the flipperdevices/flipperzero-firmware maintainers to review and merge this PR so all downstream firmware providers can pull it in.

[csptechnologies]

Is there any way you could add this into the unleashed firmware fork?

Did everything work for you? Exactly which physical card did you use to test?

What do you mean by physical card?

[herbenderbler]

Is there any way you could add this into the unleashed firmware fork?

Did everything work for you? Exactly which physical card did you use to test?

What do you mean by physical card?

Just curious which kind of fob you're using to test this. I'd like to get my hands on one to test it in the wild.

[csptechnologies]

Is there any way you could add this into the unleashed firmware fork?

Did everything work for you? Exactly which physical card did you use to test?

What do you mean by physical card?

Just curious which kind of fob you're using to test this. I'd like to get my hands on one to test it in the wild.

It's a Honeywell 5838-4 fob, it goes to my Lynx Touch L5000 security alarm panel. you can program this fob on most honeywell security systems even newer ones, and it works on any other security system brand that uses the 345MHz (Vivint, ADT, 2GIG, Simplisafe)