Skip to main content

Panamax / Furman Power Conditioner (UDP)

This driver controls Panamax and Furman network-controlled power conditioners over their local UDP XML protocol on the customer LAN. It turns each switched outlet into a controllable zone — on, off, and reboot (power-cycle) — talking straight to the unit's local control endpoint with no Bluebolt cloud round-trip.

UDP is the right transport for units that expose Panamax's local UDP control interface. Unlike the HTTP driver, the UDP protocol has no login: each datagram carries the unit's MAC address and its device class to identify exactly which conditioner it is addressing, so there is nothing to authenticate — but you must know both of those values up front, because the UDP driver has no discovery step to learn them for you.

Three Panamax transports — pick the one your unit speaks

GEM ships three Panamax/Furman drivers for the different control interfaces these units expose. Use Panamax / Furman (UDP) — this driver — for units that present the local UDP XML control endpoint. The Panamax / Furman (HTTP) driver covers BlueBOLT-CV2 units that serve the XML control API over HTTP (and it self-discovers the unit's class and MAC), and the Panamax / Furman (Telnet) driver covers older units that only expose a telnet command line on port 23. If your unit has a BlueBOLT-CV2 ethernet card, prefer HTTP; use UDP for units where local UDP control is the interface available to you.

Prerequisites​

  • A Panamax or Furman power conditioner that exposes local UDP control on the same LAN as the GEM controller.
  • Local UDP control enabled on the unit. Some firmware ships with local UDP control disabled by default — turn it on in the unit's BlueBOLT/network settings before adding the device.
  • The unit's MAC address — read it from the network page of the unit's web UI.
  • The unit's device class string (its BlueBOLT model class, e.g. m4315). You can read this from the unit's web UI or its BlueBOLT/Panamax documentation.
  • The UDP port the unit listens on for local control (in the unit's BlueBOLT/network settings).
  • A static IP (or DHCP reservation) for the conditioner, so the address GEM sends to does not move.
  • The outlet numbers you intend to control. Outlets are 1-based and match the physical labeling on the back of the unit.

Setup​

  1. Assign a static IP to the conditioner (or reserve its DHCP lease), and enable local UDP control on the unit if it is not already on.
  2. Create the device under System → Devices (Open Devices) with driver panamax_udp. Fill in the Connection group:
    • IP Address (ip) — the unit's address, e.g. 192.168.1.95.
    • UDP Port (port) — the UDP port the unit uses for local control. This is required (there is no fixed default; on many units it is a high port such as 57010 — confirm yours in the unit's settings).
    • MAC Address (mac_address) — the unit's hardware MAC, e.g. 00:11:22:33:44:55. Colons are optional and it is lowercased automatically, so 00:11:22:33:44:55 and 001122334455 both work.
    • Device Class (device_class) — the unit's BlueBOLT model class string, e.g. m4315.
  3. (Optional) Open the Advanced group and set Status Poll Interval (ms) (status_interval) if you want a different read cadence — it defaults to 5000 (5 s).
  4. Save and enable the device. GEM sends a status query and begins polling. If MAC Address or Device Class is blank, the driver logs a warning and does not start — both are required for the UDP protocol.
  5. Create one zone per outlet you want to control, under System → Zones (Open Zones):
    • Put each zone in the Power subsystem (or wherever you keep switched-power zones).
    • Set the zone's Address to the outlet number (1-based) — outlet 2 is address 2.
    • Point the zone at this device so its controls dispatch here.
  6. Verify by toggling a zone on and off — the corresponding outlet should switch, and after the next status poll the zone's on/off state should reflect the unit (see How outlet state is reported below).
Inline help on the device form

The Devices form shows a short inline quick-start for the driver and a View integration guide toggle that opens this page. If the toggle is missing, the driver selected on the device is not panamax_udp.

This driver does not auto-create zones

Unlike the Panamax HTTP and WattBox drivers, the UDP driver does not discover outlets or create zones for you — the local UDP protocol gives it no outlet list to enumerate. You create one zone per outlet by hand and set each zone's Address to the outlet number. A zone with no address has no outlet to switch, so give every outlet zone an address before you rely on it.

How outlet state is reported​

The driver actively polls the unit: it sends a status query on connect and then repeats it on the Status Poll Interval (default 5000 ms / 5 s). Each status reply lists every outlet and its current value, and GEM writes the resulting on/off state onto the matching outlet zone. Practical consequences on a job:

  • Because it polls, the zone state tracks changes made at the front panel or by another controller too — it does not depend on the unit pushing unsolicited updates. The trade-off is latency: a change shows up in GEM on the next poll (within the interval you set), not instantly.
  • For a zone's state to update, a zone with the matching address must already exist — the driver ignores a status entry for an outlet number that has no zone.
  • Tightening Status Poll Interval makes state feel more responsive at the cost of more traffic; loosening it reduces traffic if snappy feedback is not important for that unit.

Commands​

The driver declares the following commands, which are synced to this device's command rows on every boot. The standard on/off verbs map to these, so an on/off control on an outlet zone works with no extra configuration — GEM resolves on→power_on and off→power_off, and fills in the outlet number from the zone's Address automatically. The named commands are there for macros and triggers.

CommandAliasesEffect
power_ononTurn the outlet on. address = outlet number.
power_offoffTurn the outlet off. address = outlet number.
reboot—Power-cycle the outlet: off → wait → on. address = outlet number; optional delay (ms).

When you drive an outlet zone from a UI, the outlet number comes from the zone's Address, so you do not type it. When you invoke a command directly in a macro or trigger, pass address = the outlet number yourself.

Reboot is an off → delay → on power-cycle

reboot is performed by the driver as off, wait, then on — the unit has no atomic device-side power-cycle over the UDP protocol. The wait defaults to 5000 ms (5 s). If a load needs longer to power down cleanly before it comes back, pass a longer delay:

await gem.command({device_id: <id>, command: 'reboot', args: {address: '4', delay: 12000}});

Attributes​

You enter only the connection attributes plus an optional poll interval; there is nothing else to fill in.

Device attributes​

AttributeTypeNotes
ipstringRequired. Conditioner IP, e.g. 192.168.1.95.
portintRequired. UDP port the unit listens on for local control (no fixed default).
mac_addressstringRequired. Hardware MAC of the unit. Colons are optional and it is lowercased automatically. Sent in every command to identify this unit.
device_classstringRequired. The unit's BlueBOLT model class string (e.g. m4315). Sent alongside the MAC in every command.
status_intervalint (ms)Poll interval for reading outlet states. Default 5000 (5 s).

Zone attributes​

AttributeTypeNotes
addressstringRequired. 1-based outlet number. You set this when you create the zone.
statestringon / off, updated on each status poll.

Automation ideas​

  • Scheduled reboot of a stuck device. A macro schedule firing reboot on the outlet feeding a flaky modem, AP, or media player overnight clears a lockup before anyone notices.
  • Recovery trigger. Pair a device-offline condition with a reboot of that device's outlet to auto-power-cycle gear that has hung — add a guard so it does not loop.
  • Scene power-down. A "goodnight" or "away" macro that turns off the outlets feeding always-on-but-non-essential gear (a game console, a display) trims standby draw.

Troubleshooting​

SymptomWhat to check
Device does not start; log says it is missing MAC or classBoth MAC Address and Device Class are required for the UDP protocol — the driver will not connect until both are set. Fill them in and save.
No response to status queriesConfirm the unit allows local UDP control (in its BlueBOLT setup — some firmware ships with it off) and that the UDP Port matches what the unit listens on. Also confirm the port is reachable from the GEM controller (no firewall/VLAN blocking it).
Outlet commands silently ignoredThe MAC Address and Device Class must match the unit's own values exactly. Re-read both from the unit's web UI and re-enter them (the MAC is matched case-insensitively and colons are optional).
Outlet switches, but the zone's on/off state does not followThe state comes from the status poll, so it needs a zone whose Address matches that outlet number to exist. Confirm the outlet zone exists and its Address is the correct 1-based number.
XML parse warnings in the logs right after connectSome early M-series firmware emits one or two malformed status packets on boot; these self-correct after the first valid status push and can be ignored.
reboot leaves the outlet offThe 5 s default delay was too short for that load to settle — pass a larger delay (ms) as shown above.

Choose the transport that matches how your unit exposes control: UDP for local UDP XML, HTTP for BlueBOLT-CV2 web control, or telnet for the command-line console.