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 the driver falls back to polling every 3 s. Minimum 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. 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 falls back to 3000; minimum 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). 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 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.
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.