Bumbershoot

Yes, agreed. Here's a link to the Quick Start Guide: http://www.insteon.com/support-knowledgebase/get-started-ds01 There's supposed to be a page here one day, according to the flyer in the box: http://www.insteon.com/dial EDIT: No owners manual is available yet.

I added to a scene just fine (with another switch link dimmer), and it responds just as you would hope, with the exception of not updating "Status" when manipulated at the device. When manipulated by the Admin Console, everything works entirely as expected.

Actually, actions performed on the device (not from the Admin Console) do not update the "Status" in the Admin Console. Rotating the dimmer knob to change the "On Level" does not change the "Status" and no data shows up in the Event Viewer. Likewise for pressing the "On/Off" button on the switch -- no change in the "Status" and no data in the Event Viewer. When writing programs however, this dimmer appears to be identical to other Insteon dimmers. It seems to me that it's odd that there is nothing showing up in the Event Viewer when actions are initiated at the device. Wouldn't you think that there'd be some sort of detectable Insteon traffic? I wonder how Insteon deals with this in their app?

Just curious, but can't you bypass discovery by using a .yaml file? They're kind of a PITA to create, but this post indicates that this technique still works on an eisy. I'm still on Polisy, so I'm not having this issue.

My Polisy is back in business, so I'm able to run tests again if you can think of anything relevant.

I have a multimeter, but I'm none too proficient with it. I'll give it a go, though. There were no lights on the Polisy at all. When I plugged it in I could hear a faint ticking sound, but that even went away after a few minutes. I robbed another device, and I'm back in business. In true UDI fashion, I'm being sent another power supply. I've also ordered an eisy, so I'll have a useful backup system again... A few hours of down time, and all is well again.

Okay, I found one that fits (robbing Peter to pay Paul here), and yes, it looks like it's a power supply issue. Back up and running. Thanks.

My Polisy Pro decided not to boot up this morning. Seems odd, as it has been running without issue since I got it. The power adapter shows a very dim blue light when it's plugged in, and I'm wondering if that's not the problem. This is probably a dumb question, but how bright is the light on other folks power supplies? The light on mine can barely be seen if there's any ambient light. I don't know of any way to test it, other than plugging it in my Polisy.

Here you go: -- On -- Sun 01/29/2023 03:44:27 : [INST-TX-I1 ] 02 62 60 11 12 0F 11 FF Sun 01/29/2023 03:44:27 : [INST-ACK ] 02 62 60.11.12 0F 11 FF 06 LTONRR (FF) Sun 01/29/2023 03:44:27 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 2F 11 FF LTONRR (FF) Sun 01/29/2023 03:44:27 : [Std-Direct Ack] 60.11.12-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 01/29/2023 03:44:27 : [D2D EVENT ] Event [60 11 12 1] [ST] [255] uom=100 prec=0 Sun 01/29/2023 03:44:27 : [60 11 12 1 ] ST 255 (uom=100 prec=0) -- Fade Down -- Sun 01/29/2023 03:44:32 : [INST-TX-I1 ] 02 62 60 11 12 0F 17 00 Sun 01/29/2023 03:44:32 : [INST-ACK ] 02 62 60.11.12 0F 17 00 06 LTMCON (DOWN) Sun 01/29/2023 03:44:32 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 2F 17 00 LTMCON (DOWN) Sun 01/29/2023 03:44:32 : [Std-Direct Ack] 60.11.12-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 -- Fade Up -- Sun 01/29/2023 03:44:37 : [INST-TX-I1 ] 02 62 60 11 12 0F 17 01 Sun 01/29/2023 03:44:37 : [INST-ACK ] 02 62 60.11.12 0F 17 01 06 LTMCON (UP) Sun 01/29/2023 03:44:37 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 2B 17 01 LTMCON (UP) Sun 01/29/2023 03:44:37 : [Std-Direct Ack] 60.11.12-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 -- Off -- Sun 01/29/2023 03:44:41 : [INST-TX-I1 ] 02 62 60 11 12 0F 13 00 Sun 01/29/2023 03:44:41 : [INST-ACK ] 02 62 60.11.12 0F 13 00 06 LTOFFRR(00) Sun 01/29/2023 03:44:41 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 2F 13 00 LTOFFRR(00) Sun 01/29/2023 03:44:41 : [Std-Direct Ack] 60.11.12-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Sun 01/29/2023 03:44:41 : [D2D EVENT ] Event [60 11 12 1] [ST] [0] uom=100 prec=0 Sun 01/29/2023 03:44:41 : [60 11 12 1 ] ST 0 (uom=100 prec=0) EDIT: I'm done testing for a while. My Polisy decided to quit playing along and won't reboot. Must be time for an eisy... EDIT2: Power supply on the Polisy failed. I found another I can use, so I'll get back to installing/testing later this week.

EDIT3: All the testing performed in the post was performed from the Admin Console, not from the device itself. Given that I'm less than thrilled with my Zen77 dimmers that I installed during the Insteon pause, I took a chance and ordered a new Insteon i3 dimmer to take a look at to see if I like them. One arrived in the mail this afternoon, so I hooked it up to my test jig and took it for a spin. Observations: It linked/installed quickly (using UD Mobile as the interface) when I used the "set" button on the device. On/Off works as expected. Fast On/Fast Off works as expected. Dimming works as expected. Ramp Rate works as expected. On Level works as expected. Fade Up/Fade Down works as expected. The only thing that doesn't work as I expected is that the "Status" doesn't change on a Fade Up/Fade Down unless I query it. The "Status" value seems to update on every other operation that I've tested so far. It shows up in the AC as an "Unsupported Device". I haven't configured the dimmer as an On/Off switch yet (I didn't know that was possible, but apparently it is). I'll install this is a working environment later this weekend, and do some further testing. So far, however, it's perfectly functional as I would intend to use it. Ergonomically, it's a nice device, and the WAF seems high. If they bring light almond to the market, I'll likely buy quite a few more. Polisy Pro running 5.5.4 with ZMatter installed. EDIT: Added screenshot

On my iMac (Apple M1 chip running macOS Ventura 13.2) the Activity Monitor app reports that the ISY Launcher is using 1.81 GB of memory, using more memory than any other app on this system. EDIT: That's the running footprint for the AC, not the startup values for the Java app that launches it.

The passwords aren't connected. Change it in the console.

If Insteon provides UD with the appropriate documentation and support, it'll still very likely take a firmware upgrade to get these into IoX. I suspect UD has their hands full with ZMatter for the time being, but if Insteon cooperates... Maybe these will work on some level if the addressing is the same and the basic functionality in the dimmer's firmware is the same. IoX might just think it's another Insteon dimmer... Who knows?

I think that the GPL license (which is a copyleft license) caused issues for UDI, ruling out Linux. The FreeBSD license is permissive. https://en.wikipedia.org/wiki/Permissive_software_license

I'm really not sure what you're trying to do, but I set the on level of several Insteon dimmers to a variable in a single program: KitchenLights - [ID 0077][Parent 000A] If $s.KitchenLights is not 1000 Then Set 'Devices / dirKitchen / sldKitchenSink' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldDining' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldKitchenIslandSouth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldKitchenIslandNorth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldTrackLightSouth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldTrackLightNorth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldUnderCounter' On '$s.KitchenLights %' Else - No Actions - (To add one, press 'Action') This program is used to interface with Alexa, and uses a STATE variable ($s.KitchenLights) to set a brightness value for the lights in the kitchen. "Alexa, set the kitchen lights to 50" will set the STATE variable to 50, which causes this program to run. I also use the "adjust scene" functionality on groups of dimmers that are included in a scene.

It looks like Insteon and UDI are cooperating on the PLM repair service that Insteon provides: https://www.universal-devices.com/plm-repair-service/ I hope this is a sign of Insteon being more cooperative with UDI in other aspects as well.

I have six Zen77 dimmers -- three have completed the interview and three haven't. I haven't a clue as to why some complete and some don't. In one case, one that completed and one that hasn't are in the same junction box. Z-Wave seems a bit fickle at times...

I just noticed this thread. I have a Synchrolinc working just fine in 5.5.4, for what it's worth. Mine has been in use for several years, so it was installed on an ISY994i.

Not yet. In a post somewhere in this forum it was indicated by UDI that they're looking to add Matter/Zibgee functionality in March, 2023.

I only did on one (in fact I did an exclude/include on it), but I have two. The second started working after I restarted the AC. I doubt there's a relationship between the AC and these devices starting to work, however. As it is, I don't understand what made them work. Here's the log for the motion event prior to the sensor starting to work: [2023-01-19 16:56:08.466] [D] [...] RECEIVED: ( 01 1B 00 04 00 00 1D 11 56 01 60 0D 02 00 71 05 00 00 00 FF 07 00 00 0A 12 D1 00 00 91 ) [2023-01-19 16:56:08.466] [D] [...] SENT ACK [2023-01-19 16:56:08.466] [D] [...] SETDATA devices.29.data.lastReceived = 0 (0x00000000) [2023-01-19 16:56:08.466] [W] [...] Node 29:2 CC Alarm: Alarm event but interview is not complete [2023-01-19 16:56:08.466] [E] [...] Error returned from (returnStatus = _zway_cc_call_handler(zway, instance, node_id, data[3], length - 4, &data[4])): Bad arguments (-1) Here's the log for the motion event after it started to work (the node value went from 29 to 30 because I performed an exclude/include on the device): [2023-01-21 16:53:15.101] [I] [isy] UYZCmdClassCallback(7.8): Run callback for Value Update (type=0x01) [2023-01-21 16:53:15.101] [I] [isy] in alarm 7 callback 30.0 (113/70008) pnodeId=5 [2023-01-21 16:53:15.101] [I] [isy] in alarm 7 callback 30.0: path=[devices.30.instances.0.commandClasses.113.data.7.8] [2023-01-21 16:53:15.101] [I] [isy] Preparing STANDARD event [2023-01-21 16:53:15.101] [I] [isy] in alarm 7 callback: event=8 isOn=false [2023-01-21 16:53:15.101] [I] [isy] EventMgr: sending status: [ZY030_308] level=0 [2023-01-21 16:53:15.102] [I] [isy] in alarm 7 callback: event=8 isOn=false : ZY030_155 st=0 dc=DOF [2023-01-21 16:53:15.102] [I] [isy] EventMgr: sending status: [ZY030_155] level=0 [2023-01-21 16:53:15.102] [D] [...] SETDATA devices.30.instances.0.commandClasses.113.data.7.status = True [2023-01-21 16:53:15.102] [D] [...] SETDATA devices.30.instances.0.commandClasses.113.data.7 = Empty In the above, ZY030_155 is the "Motion Sensor" and ZY030_308 is "Home Security Alarm".

I’m out of town for a bit so I can’t confirm, but I got two nodes to update, I think “Motion Sensor” and “Home Security Alarm”. Both update, though I won’t know the update values until I return.

I interviewed one and even did an exclude/include on it, but neither one worked until I simply restarted the AC, then both of them did. I should have mentioned that.

Progress: I have a couple of Enbrighten motion sensor/switches. With the update to 5.5.4, these switches are now reporting motion in both the "Home Security Alarm" node and the "Motion Sensor" node.

No, but I did send @Chris Jahn some data of these in operation from the Z-Wave log, at his request. I think UDI have what they need.

Go to the Node Server Store, click on the "ELK" button, click on the "Install" button on the "Perpetual" row, then click on the "Reinstall here?" button. I think there's a bug in PG3 that prevents the automatic upgrade.