theitprofessor

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?

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.

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.

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 for the explanation Javi, it makes a lot of sense. Putting more text on a UDM screen might be too much. However, maybe a reference to these situational errors in a Wiki or something with a lot of the detail there might be more appropriate. This was triggered by a large migration. I'm sure there will be others. Thanks!

From the Hue log file... The highlighted seems to point to the problem.... 2022-12-03 16:30:41,174 Thread-1 udi_interface INFO phue:connect: Attempting to connect to the bridge... 2022-12-03 16:30:41,175 Thread-1 udi_interface INFO phue:connect: Error opening config file, will attempt bridge registration 2022-12-03 16:30:41,187 Thread-1 udi_interface ERROR hue:connect: IP Address OK. Node Server not registered. 2022-12-03 16:30:41,189 Thread-1 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot. 2022-12-03 16:30:41,274 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2022-12-03 16:30:41,277 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2022-12-03 16:30:41,424 Thread-4 udi_interface.interface INFO interface:updateProfile: Sending Install Profile command to Polyglot. 2022-12-03 16:30:41,427 Thread-4 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot. 2022-12-03 16:30:41,647 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2022-12-03 16:30:41,889 MQTT udi_interface.interface INFO interface:_message: Profile installation finished

I just upgraded to PG3 Version 3.1.15 on my Polisy Pro over the latest PG2 version. I also migrated my ISY994 to IoP 5.4.5. I installed the new production Hue node server 0.1.11 on PG3, reboot everything. After coming back up and implementing with the Hue hub button press and restart node server in less than 30 seconds it cannot find any Hue hub servers. I'm dead in the water here. Was working fine on PG2 and ISY994. Is it possible there are new instructions for adding Hue hubs under PG3?

Hi Javi, sorry too late. I can't reproduce it anymore as you can see by my follow up post shortly after I started this, I fixed the problem another way, which was sort of weird. I'm aware it's probably a node/program/variable issue but I couldn't find one anymore. But if that was the case then why did my solution fix the issue. I seems like something old was stuck on my iPhone and in a mismatch. However, I did manage to grab a screenshot (attached) earlier when there were only 3 errors. Please disregard the push notification message which popped up right as I was taken the screenshot. It has noting to do with this.

NVM, I deleted the app and data, reinstalled the app again, logged in new, and now I get a sync with no errors.

Where can I find a log or more detail on when UDM is having database sync errors? I very recently re-flashed my Polisy SSD to PG3 and migrated my ISY to IoP. As expected I lost everything that had to do with Zwave and Node Servers and must put those all back in manually and reconfigure. This will take days but I'm trying get to a stable situation first. I started with over 280 errors and then got down 3. Most of the errors were tied to defunct programs tied to Zwave and Node Server objects. I've went through and cleaned up everything obvious but now I'm flying blind and guessing. I see stuff that shouldn't matter and change or delete it and now I'm making it worse. I'm up to 26 errors now. I don't want to select the option to "remove unused values" without understanding what it is I will be removing. I'd rather clean it up from the IoP side and get no errors on a UDM sync. But I need to know what as it's not obvious at this point.

Thank you Javi, I see the change now and it's working as expected.

You are correct on both assumptions Sir. However, from the Wiki it looks like it's supposed to be there for Type Node so you can shortcut to the dashboard of a device or scene as well. I don't see it on those Favorite items either.

Ok, OK, I made the move. You all talked me into it. I'm running UD Mobile now with the ISY Portal. My family was giving me such a hard time because in my house everybody is so dependent on voice control we rarely touch a switch for anything. I was tired of waiting for anybody from MobiLinc to respond so I bit the bullet and made the change. The portal change was fully self service as long as all those modules are there and enabled. The last time I did this it was not the case and I needed assistant from UD (Thanks Michel). As far as the rest of the change over it was more involved as I needed to do a massive cleanup on the ISY Portal as it hasn't been used for over a year and I'm a heavy user of Echo. As far as I'm concerned this issue is now closed as I have removed MobiLinc X and MobiLinc Connect from the equation and everything is functioning as before with two difference. I'm becoming familiar with an old friend I haven't seen in awhile (ISY Portal) and a new one I need to get use to (UD Mobile). Thanks everyone for all your input, as always it's very much appreciated.

Wiki says... "because we have a Display Node there is a menu (three dots) which will open the Node's Dashboard". Has this changed? I cannot get those 3 dots to appear.