Diesel

Your last remaining error seems to be a ghost from a legacy IoX auto-update mechanism that UD stopped using years ago. The error flag is most likely stored in IoX's config flag rather than a table which is why the Restore PLM worked to clear all the others, but not this one. Download a backup in Admin Console and then restore ISY with that backup. The legacy error flag shouldn't carry over in the backup so it should be gone for good.

Seems like the app's DB is corrupted. It's trying to add a Polisy UUID during sync that already exists. Delete Polisy in Settings | Controllers. Then Add Controller - Local or Portal however you normally connect. Log back in and run Sync.

The error popups are old historical persisted error records trapped inside IoX that never got cleared. Essentially ghosts from the past. IoX replays them every time the Admin Console connects. The issue isn't in your Java cache. It's stored... and currently trapped in IoX. Try running a Restore Modem (PLM). It should force IoX to rebuild its internal tables and clear the stale error states permanently.

Well done! Glad to help

If you're not familiar or comfortable in SSH reach out to UDI for support. Otherwise proceed at your own risk..... SSH into Polisy using your current admin password. ssh admin@<polisy-ip> Stop IoX and PG3 sudo service isy stop sudo service pg3 stop Remove the entire IoX configuration (devices, programs, Z-Wave/Insteon data, certs, etc.) sudo rm -rf /usr/local/isy Remove all Polyglot / node server data sudo rm -rf /var/polyglot Remove portal credentials and association sudo rm -rf /var/polyglot Reset network settings back to default DHCP sudo rm -f /etc/wpa_supplicant.conf sudo rm -f /etc/network/interfaces Reboot Polisy sudo reboot After factory reset credentials will default to admin/admin

Hi, I'm not sure what's really on your mind, but I sense from your posts that you're very concerned about something. Although it's unclear what that is. A few of the architectural conclusions in your post don’t match how the current platforms actually work. On Eisy, the controller does not run bare-metal firmware. Eisy runs FreeBSD as a full host operating system. IoX and PG3x are user-space services started by the OS at boot, just like any other daemon. This is why you can SSH into Eisy and see standard BSD processes, services, filesystem, and package manager. On older hardware like the ISY99 and ISY994, the controller was much closer to firmware-style embedded software. That’s likely where your impression comes from. Elk module vs PGx, this was mostly a historical product strategy shift rather than a technical limitation. The Elk module was compiled directly into the 994 firmware. Polyglot came later as a way to externalize integrations instead of baking them into firmware, which is what eventually led to node servers replacing modules. Conceptually, it's reasonable to say the same IoX lineage runs from ISY99 through Eisy. But today IoX is a process running on top of FreeBSD rather than being the entire device image as it was on the earlier controllers. That's why IoX can be restarted independently of the box and why PG3x continues running when IoX is restarted. That separation didn't exist on the ISY99 and ISY994. PG3x is not a small helper module inside IoX. It's a separate service running alongside IoX on the operating system. Its roles are to host and run node servers as separate processes, provide the store, install, and update interface, handle licensing checks with UD’s portal, and translate node server data into nodes that IoX can consume through its API. PG3x communicates with IoX over local APIs and sockets. IoX itself is blind to whether a node originated from Insteon, Z-Wave, or a node server. Licensing does involve communication with UD’s portal, but the node servers and PG3x runtime operate fully locally. Portal credentials are stored locally so the Eisy can authenticate to UD’s portal for remote access and license validation for paid node servers. There's no indication that PG3x streams device data to UD. Node servers run locally and communicate locally with IoX. So.... what's troubling you?

Smart outlet with hardware built-in watchdog that monitors your gateway connectivity Keep Connect | Automatic Router Rebooter Rebooter Pro – Automatic Router and Modem Rebooter Also possible to reboot most modems with a curl command. For example for Aaris Surfboard cable modems curl -u admin:password http://<modem ip>/goform/Goform_Reboot (Replace admin:password with your credentials).

Create 3 scenes. Don't control individual devices. Scene A - All basement lights you want turned ON with keypad button X Scene B - All the OTHER basement lights NOT in Scene A you want turned OFF with keypad button X Scene Basement KPD X LED - include only the keypad X button as a responder Create 2 programs KPD X basement lights ON If Basement KPD X is switched On Then Set Scene A On KPD X basement lights OFF If Basement KPD lights is switched Off Then Set Scene A Off Set Scene B Off Optional - 2 Programs for Keypad LED Trackers that also show if any lights are ON anywhere in the basement Basement Lights Status LED ON If KPD X Status is Off And Basement Light 1 Status is not 0.000% Or Basement Light 2 Status is not 0.000% Or ......add as many OR ....Status is not 0.000% as needed Then Set Scene Status Basement KPD X LED On Basement Lights Status LED OFF If KPD X Status is not Off And Basement Light 1 Status is 0.000% Or Basement Light 2 Status is 0.000% Or ......add as many OR ....Status is 0.000% as needed Then Set Scene Status Basement KPD X LED Off

There was an announcement a few days ago that Polisy is nearing EOL and in maintenance mode. I would keep your Polisy on 5.9.1 and eventually upgrade to Eisy when you're ready.

@dbwarner5 If memory serves, S2 was introduced in 2017. Most Yale locks were S0 before 2018. If your lock is really 10 years old it won't support S2. You can always look up the model spec. S0 is slow & chatty. S2 is quieter, faster, better battery management, and more reliable. To pair an S2 supported lock it needs to be paired close to the main controller using either a QR code or manual DSK entry. Sorry, I don't have a Z-wave radio on my Eisy since I moved all my Zwave & Zigbee devices to Hubitat a long while back. But maybe check Z-Wave-Tools-Z-Wave Diagnostics-Node Information and look for COMMAND_CLASS_SECURITY. If it's 0x98 then it's S0, if 0x9F then it's S2. But hey, if the locks are working like they should sometimes ignorance really is bliss!

@dbwarner5 The SECURITY=True flag in Xray only means the lock is encrypted. It doesn’t distinguish between S0 and S2. To confirm S2, you'd need to see COMMAND_CLASS_SECURITY_2 (0x9F) or S2 Access Control listed. Eisy + Zooz 800 stick improves inclusion reliability, but it doesn’t eliminate the need for close proximity during first-time S2 pairing. Including locks next to the main controller is still the most reliable way to ensure a clean S2 handshake.

Hey, Not sure what brand/model Zwave locks you have, but for secure S2 pairing they need to be right next to the main controller when pairing the locks the 1st time. Then move the locks to their final location and repair network. I had to do this with 3 locks a few years ago when I changed Zwave control from ISY to Hubitat. It was just easier to buy a cheap 75ft ethernet cable off Amazon and temporarily move Hubitat to the locks during S2 pairing then taking 3 locks off the doors. Waiting for decent matter locks to materialize so I can be done with Zwave once and for all.

@sjenkins Very nicely done. Great work! Thank you

Looks solid! Just a bit confused on the static/dynamic terminology change. In the first post you referred to Insteon-like as dynamic, but now default = Insteon = Static? Calling the default “Insteon = Static” may confuse some (many think of “resume last” as “Insteon-like”). In any case; GV0: Mode with editor choices Preset (Static) / Last On (Dynamic). Keeps your proposed behavior; avoids confusion over what is “Insteon-like” Per-node mode with a default and an optional dynamic mode is perfect. Proposed ranges make sense. Static (default) OL (5–100) is a preset the user/programs set. DON/DOF/DFON/DFOF/BRT/DIM do not change OL. Matches lots of non-Insteon devices’ “preset OL” behavior. Dynamic (optional) BRT/DIM update OL to the current level (clamped 5–100). DOF/DFOF set ST→0 and set OL to the last (pre-off) level (“last on”). OL can still be set manually or programmatically (clamped 5–100).

There's no imminent rush to upgrade, so chill and enjoy the serenity in your life for now. The web UI is still very rudimentary and limited at the present time. For example, there's no ability to create/edit programs. Scenes are not there at all. Current Admin Console isn't going away any time soon.

It could be helpful to add two optional params (global or per-node) that default to current behavior so nothing changes for existing users, but power users have the flexibility to fine tune: MIN_ON = 10 → floor used when OL is 0 or DIM reaches 0 so the next DON isn’t zero. STEP_PCT = 3 → brighten/dim step size.

Yes. Make a backup in Admin Console (File...) and nothing to lose if you also take a backup in PG3x. They are free

As Michel clearly states on that post " If your OS is below 13.2p11 please do not attempt the upgrade. It will brick your system." Either order the USB flash drive or file a ticket with UDI Support and ask if they'll send you the fw file to create a flash drive yourself, but DO NOT try to Upgrade Packages in AC! Yes, your installed version is 14.1 which is newer than 13.2p11 so good to go. Be sure to take an IoX backup in AC and a PG3x backup.

At the very top of the page your OS version is indicate in the line below *** OS *** What you posted is the UDX version.

You'll find many different perspectives on these forums. Such is the variety of life. But there's some basic fundamental covenants to a properly working IoX/Insteon system; 1. Never use manual links between devices unless you enjoy pain. IoX, the main brain of your system, is not aware of them. 2. For Multi-way circuits (3way, 4way, etc) always create a scene, and add all members to the scene as controllers. 3. A device can only be a controller for 1 scene, but a responder to many scenes. 4. When controlling more than 1-2 devices, a scene is considerably more efficient and reliable. 5. Identify a proper naming convention for your devices and scenes, and stick to it. With that out of the way, here's my perspective; I only use programs when I can't achieve what I want from using a scene. From what I gather from your post, you have a multi-way stair case scene with your master and slaves. These devices should be factory reset to remove any manual links, then added in IoX to a StairCase scene. Stair Case1 (this is the master) - controller to Stair Case Stair Case2 (this is a slave) - controller to Stair Case Stair Case (this is the scene) I don't think you'd want to control your daily lights (ie turn on your Daily Lights scene) every time you turn on your staircase lights so there's no point in making it a controller to the Daily Lights scene. Instead use a keypad button as the Daily Lights controller. You can add more than 1 from strategic locations, main floor, entrance, bedroom, etc and control the daily lights from all of them. We also want all devices in a multi-way circuit to remain in sync if they're part of the Daily Lights. To achieve this, Install the Virtual plugin in PG3x and create a virtual switch called Stair Case VS. Add that to the Stair Case scene as a controller. Then add that virtual switch to the Daily Lights scene as a responder. Then when Daily Lights is turned on, your Stair Case lights (and scene) are turned on, and your master and slave are also in sync. Simple, efficient, and no complicated programs needed. Use a program for Daily Lights scene to turn on/off conditionally (time of day or event).

After another espresso or 2....some more thoughts to ensure it doesn't impede anyone using it as a bridge to programs, and actually enhances program functionality in Phase A; Phase A (enhancement) Minimal, philosophy-pure changes that help everyone and don’t alter scope. 1)nodedefs.xml — add sends on the existing Virtual Dimmer + include fast on/off (If Virtual’s “dimmer/generic” already exists, extend that nodeDef; otherwise add a “VLDIM” nodeDef.) <nodeDef id="VLDIM" nls="VLDIM" name="Virtual Dimmer" icon="LightDimmer"> <sts> <st id="ST" editor="percent" uom="51" /> </sts> <!-- What this node can ACCEPT from scenes/programs --> <accepts> <cmd id="DON"><p id="value" editor="percent" /></cmd> <cmd id="DOF"/> <cmd id="BRT"/> <cmd id="DIM"/> <cmd id="DFON"/> <cmd id="DFOF"/> </accepts> <!-- What this node can SEND (for Programs to “Control is … then …”) --> <sends> <cmd id="DON"/> <cmd id="DOF"/> <cmd id="BRT"/> <cmd id="DIM"/> <cmd id="DFON"/> <cmd id="DFOF"/> </sends> <!-- Optional program-only convenience --> <cmds> <cmd id="SETLVL"><p id="value" editor="percent" /></cmd> <cmd id="QUERY"/> </cmds> </nodeDef> If your schema uses cmds only and no explicit <accepts>/<sends>, we still add handlers for DFON/DFOF and ensure controller events fire so Programs can “Control … is Fast On/Off”. 2) Node class — just add DFON/DFOF handlers and emit sends In the existing Virtual Dimmer node: def cmd_DON(self, command): # update ST and fire “DON sent” (so Programs can trigger) self._set_local_level(self._value_from(command, default=100)) self.reportCmd('DON') def cmd_DOF(self, command): self._set_local_level(0) self.reportCmd('DOF') def cmd_BRT(self, command): self._step(+self.step_pct) self.reportCmd('BRT') def cmd_DIM(self, command): self._step(-self.step_pct) self.reportCmd('DIM') # NEW: Fast On/Off (for parity with physical dimmer) def cmd_DFON(self, command): self._set_local_level(100) self.reportCmd('DFON') def cmd_DFOF(self, command): self._set_local_level(0) self.reportCmd('DFOF') # SETLVL remains for programmatic level changes (program use) def cmd_SETLVL(self, command): pct = self._value_from(command, default=100) self._set_local_level(pct) # optional: do not report a scene “send”; this is a program-level op reportCmd('XXX') should be whatever the Virtual server currently uses to raise the “Control is …” events so Programs can key off Tap On / Tap Off / Fast On / Fast Off / Brighten / Dim. Result: Users can now write Programs like: If Control ‘Virtual Dimmer’ is Fast On → Then Set Scene ‘SceneXYZ’ On If Control ‘Virtual Dimmer’ is Brighten → Then Network Resource “SceneBRT” …without the plugin doing any scene logic itself. Phase B (Optional - opt in): one-line “Relay” to a target node (still a bridge) Add a single param to the Virtual Dimmer (e.g., FORWARD_TO_NODE). When set, the node mirrors the exact sent command to that node via IoX REST. This doesn't introduce scene logic; it’s just pass-through. Add two drivers/params for visibility & control (optional): GV0 (string) — the target node address (scene group or device), display only. GV1 (bool) — “momentary” cosmetic reset (return ST to 0 after 0.4s), optional. In each send path (DON/DOF/BRT/DIM/DFON/DFOF): if self.forward_to: # For scenes: DON with an optional level argument is supported by IoX REST. # For devices: DON/DOF/BRT/DIM/DFON/DFOF are passed as-is. self._isy.cmd(self.forward_to, 'DON', level_0_to_255) # only when DON has a % value # or self._isy.cmd(self.forward_to, 'DFON') # etc. This still keeps Virtual squarely in “bridge/relay” land: Program patterns (what users can do with Phase A) Single-scene control (ramp by scene presets): - IF Control ‘Virtual Dimmer’ is switched On → Then Set Scene ‘X’ On - IF Control ‘Virtual Dimmer’ is switched Off → Then Set Scene ‘X’ Off Fast on/off: - IF Control ‘Virtual Dimmer’ is switched Fast On → Then Set Scene ‘X’ On (or 100% via NR) - IF Control ‘Virtual Dimmer’ is switched Fast Off → Then Set Scene ‘X’ Off Brighten/Dim stepping: - IF Control ‘Virtual Dimmer’ is Brighten → Then Network Resource calling /rest/nodes/<scene>/cmd/BRT - IF Control ‘Virtual Dimmer’ is Dim → **Then … /DIM` Set exact level (%): - Use SETLVL to set ST (program semantics), then NR: /rest/nodes/<scene>/cmd/DON/<0–255>. - IoX Programs typically don’t pass a % to a Scene “Set On” natively; NR handles it cleanly.

Hi @sjenkins I really appreciate you for all the effort you've put into enhancing Virtual, and even more-so for being open to discussion. The issue I'm trying to solve is Insteon's inherent disfunction with scenes. Native Insteon scenes were created by Insteon because they're the only reliable way to simultaneously control multiple devices. Unfortunately, IoX considers scenes to be stateless, but not really. If a device is a member of multiple scenes, all of those scenes are considered to be in the same state as that device, even if that scene was never called. A scene doesn't have a "truth indicator" that indicates whether a scene is on or off. So we end up having to create a spaghetti of programs to work around this disfunction. As we move forward with Insteon to work with HomeKit, Matter, and other platforms, this disfunction becomes an even bigger issue. A multi-way circuit is just an example of this disfunction. Insteon's native approach is to add the devices all into a scene to keep them in sync. It works as expected when controlling any of the physical devices, but not within UDM or any other platform unless you control the scene itself. What's missing? A Virtual device to act like the physical device(s) in that scene. In my mind, a virtual device would behave the same as a keypad button that acts as a scene controller. A keypad button always reflects the true state of it's scene. It turns the scene on when turned on, turns it off when turned off, brightens and dims the scene when pressed. That said, I appreciate your thoughtful response and I understand your “bridge, not replace Programs” philosophy. Giving some more thought on how to keep Virtual within that scope, but still achieve what I believe can be a game changer for everyone, I propose; Phase A (bridge-only): Extend the Virtual Dimmer’s accepts/sends set to include DFON/DFOF alongside the existing DON/DOF/BRT/DIM. The node will handle/emit those events so Programs can key off Fast On/Off in addition to Tap/Dim/Brighten. No scene awareness or coordination in the plugin. Phase B (optional, default off): Add a single optional text param FORWARD_TO_NODE. When set, the dimmer simply relays whatever it sends (DON/DOF/BRT/DIM/DFON/DFOF) to that node via IoX REST. It remains a bridge/relay — still no scene membership knowledge or multi-dimmer logic inside the plugin. Users who prefer pure Programs can leave it blank and get the exact behavior you described. This way Virtual stays true to its mission (bridge signals to Programs), while enabling a parity command set with physical dimmers and, optionally, a tiny relay convenience for those who want it. Let me know your thoughts and whether you need me to elaborate further.

# nodes/virtual_dimmer.py import time import requests import udi_interface LOGGER = udi_interface.LOGGER class IsyRest: """Tiny helper to call IoX REST for scene commands.""" def __init__(self, base_url, user, password, verify_ssl=True, timeout=5): self.base = (base_url or '').rstrip('/') self.auth = (user, password) if user else None self.verify = verify_ssl self.timeout = timeout def cmd(self, node_or_scene_addr, command, *args): if not self.base: raise RuntimeError("ISY_BASE_URL not configured") url = f"{self.base}/rest/nodes/{node_or_scene_addr}/cmd/{command}" if args: url += "/" + "/".join(str(a) for a in args) r = requests.get(url, auth=self.auth, verify=self.verify, timeout=self.timeout) r.raise_for_status() return True class VirtualDimmer(udi_interface.Node): """ Virtual Dimmer that: - As a Responder: updates its own ST on DON/DOF/BRT/DIM/etc. - As a Controller: forwards DON/DOF/DFON/DFOF/BRT/DIM/BMAN/SMAN to a native IoX scene (group). """ id = 'VLDIM' # must match nodedefs.xml # Drivers: # ST : 0-100 % level (uom 51) # GV0 : scene/group address this node controls (display) # GV1 : momentary flag 0/1 (if 1, returns to 0% after send) drivers = [ {'driver': 'ST', 'value': 0, 'uom': 51}, {'driver': 'GV0', 'value': 0, 'uom': 56}, {'driver': 'GV1', 'value': 0, 'uom': 2}, ] def __init__(self, polyglot, primary, address, name, isy_rest: IsyRest, scene_addr: str = None, momentary: bool = False, step_pct: int = 3): super().__init__(polyglot, primary, address, name) self.isy = isy_rest self.scene_addr = scene_addr # e.g. 0001, 0012 (group id) self.momentary = 1 if momentary else 0 self.step_pct = max(1, min(20, int(step_pct))) # ---------- lifecycle ---------- def start(self): self.setDriver('GV1', self.momentary, report=True, force=True) if self.scene_addr: try: self.setDriver('GV0', int(self.scene_addr), report=True, force=True) except Exception: # not numeric; ignore—GV0 is display only pass self.reportDrivers() def query(self, command=None): self.reportDrivers() # ---------- helpers ---------- @staticmethod def pct_to_255(pct: int) -> int: pct = max(0, min(100, int(pct))) return round(pct * 255 / 100) def _set_local_level(self, pct: int): pct = max(0, min(100, int(pct))) self.setDriver('ST', pct, report=True, force=True) def _send_scene(self, cmd, *args): if not self.scene_addr: LOGGER.debug(f"{self.address}: no scene_addr configured; skip send {cmd} {args}") return try: self.isy.cmd(self.scene_addr, cmd, *args) except Exception as e: LOGGER.error(f"{self.address}: scene command failed: {cmd} {args} -> {e}") def _momentary_reset(self): if self.momentary: time.sleep(0.4) self._set_local_level(0) # ---------- command handlers ---------- # DON (optionally with level 0-100 from Admin Console) def cmd_DON(self, command): lvl = 100 if command and 'value' in command: try: lvl = int(command.get('value')) except Exception: lvl = 100 self._set_local_level(lvl) # responder behavior self._send_scene('DON', self.pct_to_255(lvl)) # controller behavior self._momentary_reset() def cmd_DOF(self, command): self._set_local_level(0) self._send_scene('DOF') self._momentary_reset() def cmd_DFON(self, command): self._set_local_level(100) self._send_scene('DFON') self._momentary_reset() def cmd_DFOF(self, command): self._set_local_level(0) self._send_scene('DFOF') self._momentary_reset() def cmd_BRT(self, command): new_lvl = min(100, int(self.getDriver('ST')) + self.step_pct) self._set_local_level(new_lvl) self._send_scene('BRT') def cmd_DIM(self, command): new_lvl = max(0, int(self.getDriver('ST')) - self.step_pct) self._set_local_level(new_lvl) self._send_scene('DIM') def cmd_BMAN(self, command): self._send_scene('BMAN') def cmd_SMAN(self, command): self._send_scene('SMAN') # Explicit “Set Level” from programs (0–100) def cmd_SETLVL(self, command): try: pct = int(command.get('value')) except Exception: pct = 100 self._set_local_level(pct) self._send_scene('DON', self.pct_to_255(pct)) self._momentary_reset() commands = { 'DON': cmd_DON, 'DOF': cmd_DOF, 'DFON': cmd_DFON, 'DFOF': cmd_DFOF, 'BRT': cmd_BRT, 'DIM': cmd_DIM, 'BMAN': cmd_BMAN, 'SMAN': cmd_SMAN, 'SETLVL': cmd_SETLVL, 'QUERY': query, }

Thanks for this! Ideally, a Virtual Dimmer would behave the same as a physical dimmer for consistency. Consider a potential common use case of a virtual controller of a multi-way circuit scene.Virtual dimmer controls and keeps the scene, and physical dimmers all in sync. Maybe something along these lines? User action (virtual dimmer) Exact behavior to emulate Commands to send (to scene) Notes Single tap ON(top paddle) Go to scene’s programmed On Levels with scene’s ramp DON (no level parameter) Mirrors what a physical dimmer sends when used as a scene controller. Single tap OFF(bottom paddle) Ramp responders to off per scene link DOF Double-tap ON Fast On (immediate to full) DFON Bypasses ramp to 100%. Double-tap OFF Fast Off (immediate off) DFOF Bypasses ramp. Press & hold ON (top hold) Start brightening until release BMAN (once), then periodic BRT until release, then SMAN Repeat rate ~300–400 ms? Press & hold OFF (bottom hold) Start dimming until release BMAN (once), then periodic DIM until release, then SMAN Same repeat rate. Set Level(slider/command with %) Jump scene to specific runtime level DON/<0–255> Useful for admin UI or programmatic ontrol.