Bumbershoot

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.

@Riggins44, with the initial release of IoX 5.5.2, there was an issue with data from Aeotec Multisensors not populating the AC. That was fixed in release 5.5.3 for at least the Multisensor 6. My USB powered Multisensor 6 now provides motion (through the Home Security node) and LUX updates. Other motion sensors still don't populate the AC correctly, so as I understand it, these will be a focus of the next IoX release. EDIT: added screenshots

Yep. I think it's happened twice with the 5.5.3 release. UDX gets a bump prior to the ISY software, as well.

As an experiment, I performed an exclude/include on my Aeotec Range Extender 7 to see if this firmware would display it in the device tree. The answer is yes, I now have a device ZY 028 Repeater in my device tree.

I share your opinion. I've got several Zen77 dimmers that I put in during a bathroom remodel that was completed during the Insteon "down time". They work in Z-Wave scenes using the "Basic Assoc Only 2" nodes for on/off and "Basic Assoc Only 3" for dimming, but not as elegantly as Insteon hardware in scenes. But, they're okay for now as they work... If the new Insteon i3 dimmers work with UDI software, I'll replace the Zen77's with the new hardware. Otherwise, I'll switch them out to the older paddle Insteon dimmers.

I've got a couple of those switches/motion sensors with the same issue. Here's what it looks like in the Z-Wave log: [2023-01-10 07:17:53.476] [D] [...] SETDATA devices.27.data.lastReceived = 0 (0x00000000) [2023-01-10 07:17:53.476] [W] [...] Node 27:2 CC Alarm: Alarm event but interview is not complete [2023-01-10 07:17:53.476] [E] [...] Error returned from (returnStatus = _zway_cc_call_handler(zway, instance, node_id, data[3], length - 4, &data[4])): Bad arguments (-1) Very glad to hear that the migration went well.

I'm using the Occupancy Node Server built into the UDI Portal, in conjunction with the Locative app on our iPhones to provide this. It's worked for some years very reliably, and it works on my Polisy. The instruction for setting this up are here: https://wiki.universal-devices.com/index.php?title=ISY_Portal_Node_Server_Occupancy_%26_Locative_app_Instructions

I'd be making an assumption. Maybe shut down the box, remove the Zooz dongle and restart. That way you won't cause anything unintended to happen.

I mean the ZMatter board. I'd leave the Zooz dongle alone.

I factory reset my ZMatter dongle and started clean. A plus of factory resetting the dongle (for us OCD types) is that the devices you include will start over with device numbering (the first device you include will be ZY 002xxx). For me, item 2 in your list would be to factory reset the ZMatter dongle. You don't have to exclude any devices using the Zooz dongle, as you can exclude them using the ZMatter dongle. You'll have to exclude each device prior to being able to include it. Item 5 would be to start the exclude/include process. I see that UD Mobile now has the ability to Add/Remove Z-Wave devices, so it might be simpler to use that interface instead of having to run back an forth from the device to the computer that has the AC running. I think the best idea is to start the exclude/include process with devices that are physically closer to the ZMatter board.

This is just an idea... You might look at the "DH All Devices" selection under the Z-Wave | Z-Wave X-Ray menu to see if the devices that don't appear in the device tree are in that device list. In my case, device 2 appears in this list, but nothing shows up in the device tree. Device 2 is a Aeotec Range Extender 7 (it was the first device I included in the network). This won't fix anything, but you might be able to see if the device is actually included. If a device appears in X-Ray, you can run a REST query against it, such as this: http://192.168.1.19:8080/rest/zmatter/zwave/dh/node/2/cc/0 This returns a ton of data for an otherwise invisible device.

I don't know what repeater you're using, but you're not the first to NOT see the device in the device tree. See this post (this is for Aeotec Range Extender 7 devices): I see the device in the Z-Wave | Z-Wave X-Ray tool (see screenshot). The range extender was the first device I included, so it would be device 2. There is no such device in the device tree, however, and I don't see how to discover what the route to the controller is in the latest version of IoX, so I don't know if any devices are actually using the repeater (though I suspect they are due to the distance they are from the Polisy).

You need a node server to do that now. See this:

I have a Polisy and 5.5.2 is running things around here in the usual fashion, which means just fine. There are a couple of Z-Wave issues that UDI says will be addressed in the next build, but that's okay, nothing that can't be dealt with. I'm amazed that UDI released the eisy, ZMatter and a new software stack during the holidays. When I was working, we made sure to never rock the boat just before a holiday, lest we spend the entire holiday period on the phone, in the office, whatever... I feel for these guys. This stuff can be stressful.

There are some Z-Wave issues that need to be resolved, even with a clean install. There are a few devices on my network (I've done both the migration and have factory reset the ZMatter dongle and excluded/included my Z-Wave devices) that don't work as they did under the three previous Z-Wave dongles (300 series, 500 series and Zooz 700 series). Notably, status isn't reported correctly (or at all, in some devices) with the ZMatter dongle. @Chris Jahn indicated that the ZMatter dongle is strict about following the Z-Wave specifications, and some devices vary from the specifications. I have motion sensors and garage door openers that don't report status. In the case of the motion sensors, the dongle receives the notification of motion, but it doesn't process the message and update the status, so it's not actionable in programs. I will say that the range of the ZMatter dongle is much improved, and the speed in which devices react to commands is fast, maybe Insteon fast. I'm running 5.5.2 on a Polisy Pro. I'll get an eisy after the first of the year.

UDI would obviously have to weigh in on this, but I understood that the ZMatter implementation would be as a fully functional citizen of the Matter universe, and not limited to being something akin to a UDI walled garden of Matter devices that only communicate with a Polisy or eisy. I doubt something like that would pass muster with the CSA, as that one of the points of Matter is interoperability. https://csa-iot.org/all-solutions/matter/ One protocol to connect compatible devices and systems with one another. Smart home devices should be secure, reliable, and seamless to use. And with Matter, they are.

I've got one of the same range extenders, and it included into the Z-Wave network, but there aren't any nodes visible in the device tree. See the linked post: