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.0.2.95. Leading or trailing spaces are ignored.
    • 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). A port that is not a whole number from 1 to 65535 stops the driver from starting, with a warning in the log naming the bad value.
    • 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). A blank, zero, negative or unreadable value uses the 5 s default, and anything from 1 to 999 is raised to 1000 (1 s), the shortest interval the driver will poll at.
  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.
  • A zone address with a leading zero (01) follows the same outlet as 1.

When the unit does not answer​

The driver keeps sending status queries whether or not the unit has answered yet, so a conditioner that was off or still booting when GEM started is picked up as soon as it replies. (Earlier builds waited for an answer to the very first query and never asked again until the device was reloaded.)

  • After three queries in a row go unanswered, the driver logs one warning and doubles the wait between queries each time, up to 5 minutes. The first reply puts it straight back on the normal interval and logs that replies resumed.
  • A unit that has answered and then goes quiet is marked disconnected once three queries have gone unanswered and at least 45 seconds (or three poll intervals, whichever is longer) have passed with nothing heard. The next reply marks it connected again. Earlier builds left such a unit showing connected indefinitely.
  • A unit that has never answered since the device was last started is not marked disconnected. Check the port, MAC, class and local UDP setting (see Troubleshooting).

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.

Leading and trailing spaces in address are ignored. An address that is blank, still an unfilled placeholder such as [@zone.address], or contains a quote, <, > or & is refused with an error and nothing is sent.

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}});

A blank, negative or unreadable delay uses the 5 s default. A delay longer than 2147483647 ms (about 24.8 days) is refused before the outlet is switched off, because the timer could not hold it and would have switched the outlet straight back on.

If the device is reloaded or disabled while the outlet is off, the driver still sends the on at the end of the delay so the load is not left dark. If the on cannot be sent at all, the command returns an error saying the outlet was left off.

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.0.2.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); minimum 1000. Backs off while the unit does not answer (see When the unit does not answer).

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.
Zone state follows the unit but power_on / power_off / reboot never switch an outlet (before 2.0.5077)Earlier builds sent outlet commands with no destination port and malformed XML quoting, so the unit never received them. Update GEM; nothing needs reconfiguring. A command with no outlet address is now refused with an error.
Log says no reply to status queries, backing offThe unit has not answered three status queries in a row. Check it is powered and reachable and that the UDP Port, MAC Address and Device Class are right. Polling continues at a slower rate and goes back to normal on the first reply.
Device shows disconnected although outlets still switchThe unit stopped answering status queries for at least 45 seconds. Outlet commands do not get an answer, so they can still work while status does not. Check whether something else (such as the BlueBOLT cloud) is keeping the unit busy, and check the network path back to GEM.
A command returns invalid outlet addressThe address was still an unfilled placeholder or contained a quote, <, > or &. Pass the plain outlet number.
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.