theitprofessor

I see some other folks experiencing door lock issues with ZMatter. So I bit the bullet and did a full move to Eisy and USB ZMatter with a PLM migration on top of it. Everything Insteon is perfect. ZMatter is another story. The issue, my Schlage door lock. Even though it is an S2 Lock it only works in one direction now, meaning I can execute anything from Eisy to the lock and it works fine, however anything that happens at the lock doesn't update on the the Eisy. I believe this has to do with ZMatter/S2 support itself and the reason I think this is everything worked just fine with ISY 300/500 and Polisy with Zooz 700. It stopped working in one direction when I moved to Eisy/Zmatter. Since the Polisy AC and the Eisy AC are basically the same the only thing that's different is ZMatter/S2 support which I did not have with the other three UD combination systems. I've done everything UD has asked me to do to resolve the issue and it just plain doesn't work. I have no idea if of when UD may choose to resolve this so I'm coming to grips that I may need to replace the lock now (ugh). I have 4 other Eisy upgrades/installations pending on hold because of the lock issue. What I looking for is anyone who has successfully moved their door lock to Eisy/ZMatter and has it working the way it should. If so, what make and model? Is this the time I ditch the ZWave door lock and move to a WiFi lock? That just opens up another can of worms and moves me away from a "universal system" that manages everything from one place!

I have the same issue since moving to ZMatter. Mine is with an S2 Schlage door lock. But in my case the programs didn’t work because the communications between the lock and the controller were only one directional meaning the lock would never report it’s status back to Eisy. It’s not a range issue either, neighbor issue, or anything else, I ruled that out. So I tried to exclude the lock and include it again and now it’s so messed up I can’t get it to join again. Worked just fine with ISY 300 and 500, and also with Polisy and Zooz 700. Since IoP and IoX are almost exactly the same I believe the issue is the USB ZMatter. I think it’s a bug with ZMatter as it’s the only thing that makes sense right now. I have no issues with the 35 other ZWave devices in my network. Just the lock. And yes I’ve opened a ticket with UDI.

Oh Man! I hate when I'm right about these things. Not that I don't appreciate everyone's help but not one thing above helped this situation. In fact, it's worse now. I did an exclude before the include each time I tried to add the lock back. I got the S2 ask, gave it the code, verified it, and shortly later the lock status light indicated a failed included and the include window went away. I waited and nothing except one device object showed. So I did an exclude which removed it and tried the include again. Same situation, same result. I don't even get the rest of the device objects just the one. I did this 6 times. Each time it went away, but then some time later now 6 "ghost", that's right ghost objects appear and they are not going away. There is no way any of these are actually linked to the door lock anymore because I've now done a factory reset on the lock. You say a "Z-Wave / Synchronize / New & Deleted" with or without an interview will get rid of them? Not a chance. I think the synchronize is just a new fancy name for Heal Network. I even deleted these 6 objects and then ran a Sync and it brings them right back. This is what I mean by ghosts objects. This ghosting is exactly what happened with older versions of ISY and those dongles. I call it ghosting because the door lock is not paired to anything but the IoX side still has partial remains you can't get rid of (Ghost). The only way I've ever been able to get rid of the ghosts is a ZWave dongle/controller reset. So I'm right back to where I started but now with a bigger mess and I still can't get this lock to pair with the new ZMatter board properly and it all was working just fine on ISY with 300 and 500 and Zooz 700 with the Polisy.

I totally understand a device can only be part of one network. But that’s exactly what I’ve been making sure of. I’ve been using just another way of accomplishing the exact same thing. Schlage door locks are finicky, when you include them in the network you need to have the controller within inches of the lock, which I do every time I do this. An include will not work with communications through repeaters. The bottom line here is ZWave sucks because it’s way more complicated and fussy than it should be, but it turns out they are a necessary evil. I never, ever, have any issues with Insteon devices, wired, or wireless. When I did this ZWave migration to ZMatter I did a ZWave reset on ZMatter to make sure sure nothing was part of it and I did a factory reset on every device before adding it. That’s my method to make sure. The lock was only the second device I added.

Dennis, I’m trying to understand your statement of adding without excluding first. I’ve never done that or even heard about that before and I’ve been working with ZWave about 7 years. Are you saying to run an exclude first? For how long, since I’m not really excluding anything? I have a practice that I do all the time and it’s served me well. I do run a “stop including and excluding” before I do an include and I also do a factory reset on the device so it’s not paired with anything before I start.

Thanks Dennis, I will try these things the next chance I get which won't be for a few days as I'm going to be tied up for a little while. I'll get back to you. Much appreciated.

Scott, one more thing. When you did your include did use the standard old school ZWave include or scan the DSK via UDM? I'm guessing the first one. I scanned the code with UDM on mine.

Need clarification Scott - - In admin console: Z-Wave / Network / Communication Speed = 100 (Slowest) Done - In admin console: Z-Wave / Network / Interview Timeout = 30 Seconds Done - In admin console: Z-Wave / Network / Heal Network I've done this twice before and I will do it once more once I understand the rest of your instructions -- Network Heal can take a long time, watch progress in Tools / Diagnostics / Event Viewer Understood and I've monitored through viewer before - Exclude and re-include Schlage lock Not sure what you mean here, are you referring to removing the lock completely from the controller and adding it back in? If so, I will wait do to that as a last resort. The reason is even if I remove it, it will still have ghost objects reappear under certain circumstances and the only way to clear those and not have them come back is to do a reset on the ZWave controller. This means including every ZWave device all over again. Ugh, 25 of my ZWave devices are battery operated and in locations not quick to get at. I've done this process about 10 times for various reasons. Another reason I hate ZWave. Nothing is easy! - Right click on lock and Z-Wave / Update Neighbors Done 3 times now - Right click on lock and Z-Wave / Synchronize / Update with interview Done after Dennis recommendation, no change. It still shows "Interview Not Done" when looking at Z-Wave / X-Ray / DH All Devices / Go but I'm not seeing any side effects. Mine also shows not done. These are the nodes showing up for the lock: I have all the same (7)- ZY 022 Door Lock-- ZY 022 Access Control Alarm-- ZY 022 Hardware Failure Alarm-- ZY 022 Home Security Alarm-- ZY 022 Intrusion Alarm-- ZY 022 Power Alarm-- ZY 022 System Alarm BTW - I used to have an BE469NX and changed it out to the one I have now. Your old one is on S0, isn't it?

Done Dennis, no change. I waited till complete, rebooted Eisy, waited for all starting processes to finish. Still no change.

I have the Schlage Door Look BE469ZP (ZWave) which ran just fine on my ISY 994i ZW with the the 300 and 500 series ZWave boards. It also worked just fine with my Polisy and a Zooz 700 USB ZWave dongle. I’ve moved everything to Eisy now with ZMatter USB and I have some issues with the door lock. It won’t report lock status changes back to IoX now. I can run a query from IoX an get the current status but communication initiated from the lock back to IoX doesn’t seem to be working. Some additional info. The ZWave move from Polisy to Eisy was not a migration, it was wipe/reset everything and reconfigure from scratch so everything is clean to start with. I have about 35 ZWave devices and they all seem to be working just fine. I was running on 5.6.0 on Polisy with the Zooz and on 5.6.0 on the Eisy so that should be about the same. So the only thing that’s really different is the ZMatter and I’m running on S2 with the lock now and wasn’t before. Have I run into a compatibility issue or some bug? Thoughts?

Good to know about the new feature to the portal and thanks. Now just need someone to take on the Rachio NS.

Rachio, the only way to get that to fully work on PG3x is to poke a hole in my firewall from their web service to my PG3x. I'm not sure that's a very good idea.

Just to add to the conversation I use Pushover for all notifications, not texts or emails "this is the way" If the device is in your ISY, IoP, or IoX AC you can monitor the state change with a simple program and send a push notification to your phone or table. Very simple to do in a program, might take a slight learning curve to understand the HTTPS POST string, plenty of easy to read short documentation with examples . But once you do one it's mostly reusable, just copy and replace a few words here and there. So if you have a non Insteon device and you use PG3 with a node server like say a Garage Door Opener which puts that Opener in your AC you can simply monitor if something and like the door just opened. Pushover also has about 20 different musical tones you can add in addition to the push notification. So you can make the audio a little more dramatic and get your attention for something like the garage door just opened and it's 2 AM.

Hi MrBill, no that's not it. Please read my response to Javi and see if that explains it better. If not, I will come back with more detail.

That's cool Javi, but that's not the same thing. UDM is talking "to" the portal and PG3x is talking "to: the portal. Those are both outbound communications from inside my network out to the internet to a joining place, the portal. I don't have to poke any inbound holes in my firewall for that to happen. This is about some other non UDI company communicating inbound to my local PG3x in order to enable the services of a node server. I'm looking for others thoughts on that from a security standpoint from those who are security minded.

This is a philosophical/technical security question/discussion. With PGC shutdown now the only means of controlling a Polyglot device which doesn't have an open local API is to poke holes from some third party webhook through my firewall into PG3x. Coming from a guy who has spend 35 years in IT, I don't trust those 3rd parties to keep there internet facing systems safe and secure. Yes I know the same thing could be said of the code on the devices I put in my home but these are different to me. One is the work of bad actors trying to do harm in the code of the device and the other is a lack of time, effort, and money it takes to keep a public facing service safe and secure. Michel shutdown PGC for security reasons, isn't poking these holes in the firewall to my local PG3x just as bad or worse?

So I've migrated to Eisy with Insteon and PG3x now functional. Now comes the dreaded ZWave migration. I've decided the best thing to do is to rebuild the ZWave network. I have ZMatter installed and I've Enabled it via UDM. Interesting thing is when it rebooted, Insteon and ZWave enablement became unchecked under system configuration after the ZMatter reboot. After enablement of Insteon and ZWave reboot I could no longer get into the the AC. The portal showed it online but I couldn't bring up the local AC login screen from the Launcher. So, I rebooted the Eisy from the portal and then it started working again after a couple mins. Questions... 1. Was the unchecking of Insteon and ZWave support after the ZMatter enablement an expected automatic behavior of enabling ZMatter? 2. Was I supposed to re-enable both of them? S0/S2 I have Aeotec Range Extender 7's to make the ZWave network more reliable. 3. When I try to add the the Range Extenders I get prompted with both S2 options enabled and two other options one of them being S0. Do I need to enable S0 on the Range Extenders If I have "some" S0 devices that will be dependent on the Extenders? I have a mixer of S0 only and S2 devices on my network. 4. Third line in the main AC menu under ZWave is Use Secure Inclusion, on or off. Do I need to leave this on all the time with a mixed network or change it when adding S0 devices?

Done, upgrade complete.

I can also confirm the 5.6.0 fixed it. I just upgraded to 5.6.0 from 5.5.9, 20 mins ago and manually ran my time sync program and it corrected the time. It was on GMT before the upgrade. To clarify I have a program that runs once a week very early morning that makes sure the time on the thermostat is correct (takes care of any drift). It looks as simple as this.... If On Sun Time is 4:00:00AM Then Set 'Hall and Stairs / Thermostat' Set Time Else - No Actions - (To add one, press 'Action')

IoP Firmware & UI are both on 5.5.9. I'm not sure what to look for in the log and which log to look in. If you can be specific I will take a look and get back to you.

My EZFlora – Model # 5010A, just died. I read an old post where everyone was saying to go with Rainmachine. But Rainmachine is either another dead company, or they have a huge supply and demand problem. No products available for sale and it looks like for some time now. So who has another "sustainable" option?

I can now add my Polisy to this list of phantom reboots. It happen to mine this morning. Very weird, no idea what caused it.

Yup, now it's working for me too. I don't understand what triggered this. It's so weird. I plugged everything back in and restarted both after they came up and now everything is working fine. I've started a detailed log of times and actions to see if I can pin down what may actually cause this if it even happens again. I noticed the issue the first evening when certain programs were not working and they should have been. I did some poking around and saw one of the PLMs was offline. And here's the really, really, weird part. When I was having the issue I saw the PM ID of the one that was working from the AC as being the PLM of the other unit. I immediately said "what, that can't be", did I plug them in wrong? So I triple checked Layer 1 and when in and out of the AC for both a few times and made absolutely sure which AC I was in. It's not that easy to make a mistake "for me". One PLM starts with a 4 and is serial having different cabling of the other which starts with a 5 and is USB. And, one AC is loaded with devices and the other has nothing in addition to Help > About, clearly telling me where I am. No I'm not crazy, it was really happening, I'm positive. The only way I could solve the problem was to completely power off the Eisy and restart the Polisy and everything returned to normal. The next day I brought them both back online and everything is now working the way it should. I don't get it. It's my understand these two boxes in no way shape or form talk to each other locally, so then that leaves only the portal or UDM and UDM just uses the portal from my understanding. So the only thing that makes any sense to me was something funky weird going on with the portal that night. Some sort of crosslink going on that would cause me to see a device from one box in the AC of the other. No Michel, I'm not blaming UDI. Everything is now working fine but I thought I would explain this here, now, in case it ever happens again or someone else experiences something similar.

OK I’m not sure which topic this belongs under so I’ll start with it here since the issue started when I introduced my new Eisy into the network. I have a Polisy Pro and Serial PLM running IoP in production using the portal and PG3. I brought a new Eisy online yesterday with a USB PLM plugged into the same electrical network. This caused my Polisy PLM to go offline. I thought they could coexist. Nothing is linked to the Eisy PLM at this point. Here is the even more interesting part. I unplugged the Eisy PLM from the electrical network and rebooted the Polisy and still it’s has its PLM offline. It was only when I powered off the Eisy completely and rebooted the Polisy that its PLM came back online. Has anyone seen this before or is this a known incompatibility?

Thanks folks.