Overview
This guide covers the most common Farenhyt gateway failures Chipkin is likely to see: wrong driver-family selection, loop-level mapping mistakes, and cases where serial RX activity never becomes usable BACnet state changes. The strongest internal evidence is around Farenhyt IFP family panels, so treat this guide as IFP-centered rather than a blanket claim for every related panel variant. Use it with the Farenhyt when bridging fire-panel events into a supervisory system.
Diagnostic Flow
- Confirm the exact panel family and model.
- Confirm the selected driver family is correct.
- Confirm loop numbering and point inventory.
- Trigger a known event and capture diagnostics.
- Only then review target-side exposure.
Symptoms & Solutions
| Symptom | Likely Cause | Action | Related Page |
|---|---|---|---|
| RX activity is visible but BACnet points do not change | The wrong driver family is selected or event translation is failing | Recheck whether the site is truly Farenhyt and validate one known event with diagnostics | Farenhyt |
| One loop maps correctly but higher loops do not | Loop offsets or per-loop assumptions are wrong | Rebuild the mapping from the actual panel schedule instead of copying one working loop | Farenhyt |
| Alarm states work but supervisory or restore states do not | Event coverage is incomplete or firmware behavior differs | Validate the exact event type and compare with current driver behavior | FieldServer |
| Team keeps changing BACnet objects but source behavior never improves | The real problem is still on the fire-panel side | Prove source event translation first before touching target mapping | BACnet |
| The panel family is described inconsistently by the site | The wrong fire-panel assumptions were carried into the config | Stop and confirm the real family before more revisions | Notifier |
The Driver Family Is Wrong
This is the first branch in Farenhyt troubleshooting.
Confirm The Real Panel Identity
Confirm:
- Exact panel model
- Family name used in vendor documentation
- Whether a prior config came from a different panel family
- Whether current diagnostics match the selected driver expectations
[!WARNING] If the site cannot confirm the panel family, repeated config revisions often just move the error around instead of fixing it.
The Loop Mapping Was Copied Incorrectly
Fire-panel mappings do not always scale cleanly from one loop to another.
Rebuild The Event Map
Look again at:
- Loop count
- Address ranges
- Common alarm and trouble references
- Supervisory and restore behavior by loop
If only one loop behaves correctly, assume the loop model is incomplete until proven otherwise.
[!WARNING] Do not promote a partially working multi-loop config to “supported” just because one loop or one event class validates. Farenhyt jobs can look healthy on Loop 2 and still fail on higher-loop alarm or trouble mappings.
Traffic Exists But Translation Does Not
This is the most misleading failure mode.
Separate Transport From Semantics
Confirm:
- The panel is generating a known live event
- Diagnostics capture that event at the serial layer
- The selected driver should recognize that event class
- The downstream point changes after translation, not just after polling
Do not call the job healthy based on RX activity alone.
Quick Diagnostic Decision Tree
- Start by confirming the exact panel family and model.
- If that is unclear: stop and resolve it first.
- If it is clear: continue to driver validation.
- Check whether the selected driver family matches the installed panel.
- If not: correct that before more testing.
- If yes: continue to loop validation.
- Check whether the loop inventory and point schedule are documented.
- If not: collect them before changing the map.
- If yes: continue to live-event testing.
- Check whether a known event appears in diagnostics and changes the exposed point state.
- If not: treat source translation as the main issue.
- If yes: continue to target-side validation.
- Check whether exposed points are still wrong after source translation is proven.
- If yes: recheck BACnet presentation.
- If no: the main fault was on the panel-side or driver-side path.