Skip to main content

Panamax / Furman Power Conditioner (HTTP)

This driver controls Panamax and Furman network-controlled power conditioners over their local HTTP/XML API on the customer LAN. It turns each switched outlet into a controllable zone — on, off, and reboot (power-cycle) — and polls the unit for outlet state so a UI or automation always reflects reality.

It talks to the unit's on-board web control directly (no Bluebolt cloud round-trip), using HTTP Basic authentication with a local web user you create on the conditioner. Two request paths are used: the unit's status XML for reading outlet states, and /ctrl.xml for switching.

Three Panamax transports — pick HTTP for BlueBOLT-CV2

GEM ships three Panamax/Furman drivers for the different control interfaces these units expose. Use Panamax / Furman (HTTP) — this driver — for units with a BlueBOLT-CV2 ethernet card (the km4315/km4320 families and the UPS models), which serve the XML control API over HTTP. The Panamax / Furman (UDP) and Panamax / Furman (Telnet) drivers cover units that instead speak the local UDP XML protocol or a telnet command line. If you are unsure, HTTP is the right first choice for any recent CV2-equipped unit.

Prerequisites​

  • A Panamax or Furman power conditioner with network control (a BlueBOLT-CV2 ethernet card, or a legacy unit with a status/control XML interface), on the same LAN as the GEM controller and reachable over HTTP.
  • A local web user with control privileges, created in the unit's Bluebolt/web interface. This is not your Bluebolt cloud account — the cloud login will not authenticate against the unit's local API. Create a dedicated local user and use those credentials here.
  • A static IP (or DHCP reservation) for the conditioner, so the address GEM polls does not move.
  • For a BlueBOLT-CV2 unit, nothing else is needed — GEM discovers the model. For a legacy unit without a CV2 card, know the unit's product class string (e.g. m4315) so the driver can reach the correct status URL; you can read it by opening http://<ip>/ in a browser.

Setup​

  1. Assign a static IP to the conditioner (or reserve its DHCP lease) and confirm you can reach its web UI in a browser.
  2. Create the device under System → Devices (Open Devices) with driver panamax_http. Set:
    • Panamax IP Address (ip) — the unit's address, e.g. 192.168.1.80.
    • Bluebolt Username (username) — the local control user you created.
    • Bluebolt Password (password) — stored encrypted.
    • (BlueBOLT-CV2: leave blank) Device Class (device_class) — the product class string, e.g. km4315 or km4320. On a CV2 unit this is auto-filled from the unit on first connect, so leave it blank. On a legacy non-CV2 unit, pre-fill it (e.g. m4315) so GEM can build the correct status URL.
    • (BlueBOLT-CV2: leave blank) MAC Address (mac_address) — the unit's control identifier used in switch commands. Auto-filled on first connect; only set it by hand if outlet commands are silently ignored (see Troubleshooting).
    • (optional) Status Poll Interval (ms) (status_interval) — how often GEM re-reads outlet states. The form pre-fills 10000 (10 s); if you clear it (or enter something that is not a positive number) the driver falls back to polling every 3 s. Values below 1000 are raised to 1000.
  3. Save. On connect the driver reads the unit's identity, then on the first successful status poll it auto-creates one zone per outlet in the Power subsystem (see below). No manual zone setup is needed for normal control.
  4. Verify by opening System → Zones (Open Zones) and filtering to the Power subsystem — after a poll cycle you should see one Outlet N zone per switched outlet, each showing its current on/off state. Toggling a zone should switch the physical outlet.
Inline help on the device form

The Devices form shows a short inline quick-start for the driver and a link that opens this page. If it is missing, the driver selected on the device is not panamax_http.

How the driver finds the right status URL​

Panamax/Furman units serve their outlet status at different URLs depending on the model, so on connect the driver reads /meta.xml to identify the unit and pick the correct status endpoint:

  • BlueBOLT-CV2 conditioners (km4315, km4320) → status at /m43.status.xml.
  • BlueBOLT-CV2 UPS units (kmb1500, kf1500, kf1500e) → status at /ups.status.xml.
  • Legacy units without a CV2 card → status at /<device_class>.status.xml, which is why you must pre-fill Device Class for those units.

Control is always written to /ctrl.xml. All of these requests use HTTP Basic auth with the username/password you entered. While reading /meta.xml (and again from the status feed), the driver auto-fills device_class and mac_address if they are still blank, so a CV2 unit becomes fully self-describing after the first connect.

If you swap the unit or upgrade firmware, reload the device (the reload control on the device page) to re-run this discovery.

How outlets become zones​

On the first successful poll, the driver reads the outlet list from the unit and creates a zone for every outlet it finds:

  • The zones land in the Power subsystem — one of GEM's default subsystems. If it has been deleted, the driver recreates it (Power).
  • Each zone's address is the outlet number reported by the unit — outlet 1 is address 1, matching the physical labeling.
  • Each zone is labeled Outlet N and created with the power_default control, so it renders as a simple on/off control on UIs and reports its current state (on / off), refreshed every poll.

Discovery runs on the first poll after each connect and skips outlets that already have a zone, so it will not create duplicates. A zone whose address names the same outlet with a leading zero (01 for outlet 1) counts as that outlet's zone. If creating a zone fails, the driver waits 10 minutes before trying that outlet again. Renaming the zone label under System → Zones is safe — the driver keys outlets by address, not label.

Device attributes​

You enter the connection attributes; device_class and mac_address are normally discovered for you.

AttributeTypeNotes
ipstringRequired. Conditioner IP, e.g. 192.168.1.80.
usernamestringRequired. Local Bluebolt/web control user (not the cloud login).
passwordstringRequired, stored encrypted.
device_classstringProduct class string (km4315, km4320, …). Auto-filled from the unit on CV2 models; pre-fill it for legacy non-CV2 units.
mac_addressstringControl identifier sent in switch commands. Auto-filled from the unit; set by hand only if commands are ignored.
status_intervalint (ms)Poll interval for reading outlet states. Form default 10000; blank or invalid falls back to 3000; values below 1000 are raised to 1000.

Zone attributes​

AttributeTypeNotes
addressstringRequired. Outlet number. Auto-set on discovery.
statestringon / off, refreshed every poll.

Commands​

getCommands() declares the following. The standard on/off verbs map to the matching commands, so an on/off control on an outlet zone works with no extra configuration; the named commands are there for macros and triggers. The outlet commands take address = the outlet number.

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).
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. The wait defaults to 5000 ms (5 s); a blank, non-numeric or negative delay also uses 5 s, and 0 switches back on immediately. 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}});

Outlet commands return an error, and send nothing, when the address is blank or an unfilled placeholder, when the device has no IP or credentials, or when mac_address is not yet known (the unit would ignore the command anyway; it is filled in from the unit on connect). A reply that is not a 2xx status, such as a 401 from wrong credentials, is returned as an error rather than as success. If the off half of a reboot fails, the driver still sends the on after the delay, so a load is never left off by a lost reply, and the command reports that the power cycle may not have happened.

A passthrough command row is also created by the sync, but this HTTP transport does not act on it — only the outlet verbs (power_on / power_off / reboot) do anything here. Ignore it; use the outlet commands above.

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
No outlet zones ever appearThe status poll is not succeeding, so discovery never runs. On a legacy unit, confirm Device Class is set to the model string in the unit's status URL (open http://<ip>/ to read the model code). On a CV2 unit, confirm the credentials are a local control user, not the Bluebolt cloud login.
404 on every polldevice_class does not match the model string the unit uses in its status XML URL. Read the correct code from http://<ip>/ and set Device Class.
Commands return but the outlet does not switchMAC Address must match the unit's actual control identifier — the unit silently ignores a switch command with a mismatched id. It is normally auto-filled; if it is wrong or blank, read it from the Bluebolt portal or the unit's About page and set it by hand.
Polling slows down while the unit is unreachableThis is intended. After three failed status polls in a row the driver waits longer between polls, doubling up to 5 minutes, and logs the failure once instead of on every poll. The first good reply puts it back on the normal interval.
Status sometimes empty / flakyThe unit serializes status updates. If the Bluebolt cloud is also polling it, the two contend — increase Status Poll Interval to reduce the contention.
401 / "Unauthorized" on every requestThe username/password are not a valid local control user. Remember the Bluebolt cloud account is separate — create a local user with control privileges on the unit and use those credentials.
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.

There are two more Panamax/Furman transports for units that do not speak HTTP: the Panamax / Furman (UDP) driver (panamax_udp) for the local UDP XML protocol, and the Panamax / Furman (Telnet) driver for the telnet command line. Choose the transport that matches how your unit exposes control.