New PLM

[Whisp]

I saw a few other posts about new PLM woes but I didn't want to hijack their threads.   My PLM finally died and I received a replacement.

 

The Short:  ISY can send messages to devices but doesn't receive status changes from any wired or wireless device.

 

The Longer:  I have followed every guide I can find/post/wiki.  The general idea of what I have done is  

* Unplug everything

* Replace PLM, replug everything in

* Restore Modem

* Restore ISY from backup

* Update/Restore/Write to devices

* Tried some factory resets

* Lots of variations of the above steps

 

Tad more info: 

* I ran link counts on PLM and it looks correct

* If I view links on a random switch I do see new PLM listed

 

I am... well.. flummoxed.. to say the least.  Any direction I should go next?

 

 

[Teken]

I am going to assume you followed the WiKi to the letter but as a sanity check this is what should have been done.

 

1. Unplug the old PLM

2. Power down the ISY

3. Configure the new PLM to the ISY and apply power to the PLM

4. Apply power to the ISY Series Controller.

 

5. Perform a restore PLM

6. Perform a restore devices for battery operated devices.

 

7. If all of the above was done exactly as outlined you may have to do a restore from a good known back up of the ISY. As you probably noted this whole thing is quite tedious and stressful from start to finish.

 

If you have a pro version please ensure you disable the battery write this will speed up the restore PLM modem process. As you probably read do not try to write to more than one battery device at a time. Doing so will just link the devices together and that will cause you more headeaches and loss of hair on your head. 

[stusviews]

After plugging in the PLM, wait a few or more seconds before powering up the ISY.

[Teken]

Also, best practice is also to be using the latest firmware which is 4.4.5 RC: http://forum.universal-devices.com/topic/18353-release-445-rc2-is-now-available/

 

Please do follow all the steps as outlined in the instruction guide and use the correct Admin Console from the same link. Confirm both UI and firmware are the same when viewing the Help-> About.

 

Lastly, this may or may not have been called out in the various threads you have read. The 994 Series Controller will need to be hard rebooted meaning complete power removed. I am not sure what has changed but many of us have noticed doing a software (soft boot) does not always bring the device back in normal status.

 

I've seen this odd behavior since 4.XX was released which was never present in the 3.XX firmware releases. Essentially hard rebooting the controller clears out any ghost / program processes in the system. I know this for a fact because there are several programs that track and monitor variables in the system that never reset and clear when a soft boot is invoked.

 

But do after several hard reboots are completed . . .

[stusviews]

IMO, unless you're an experience ISY user, it's best to use the latest Official Release which is currently 4.3.26.

[Teken]

IMO, unless you're an experience ISY user, it's best to use the latest Official Release which is currently 4.3.26.

 

I agree, but 4.4.5 RC is a culmination of many 4.XX Beta updates which translates to this Release Candidate being - Very soon to  becoming a Official Release.

 

This assumes no major bugs are reported before it being declared as such.

[Whisp]

I appreciate all the replies

 

 

I am going to assume you followed the WiKi to the letter but as a sanity check this is what should have been done.

 

.. snip ...

 

If you have a pro version please ensure you disable the battery write this will speed up the restore PLM modem process. As you probably read do not try to write to more than one battery device at a time. Doing so will just link the devices together and that will cause you more headeaches and loss of hair on your head. 

- Yes I did, I was attempting to make my post not a copy/paste of the wiki and deter potential readers.

 

- I did make the mistake during one of many attempts of not turning off the battery device setting, after that i had a bunch of wacky wireless behavior.  I did some factory resets and they seem to have gone away.

 

Also, best practice is also to be using the latest firmware which is 4.4.5 RC: http://forum.universal-devices.com/topic/18353-release-445-rc2-is-now-available/

 

Please do follow all the steps as outlined in the instruction guide and use the correct Admin Console from the same link. Confirm both UI and firmware are the same when viewing the Help-> About.

 

Lastly, this may or may not have been called out in the various threads you have read. The 994 Series Controller will need to be hard rebooted meaning complete power removed. I am not sure what has changed but many of us have noticed doing a software (soft boot) does not always bring the device back in normal status.

 

I've seen this odd behavior since 4.XX was released which was never present in the 3.XX firmware releases. Essentially hard rebooting the controller clears out any ghost / program processes in the system. I know this for a fact because there are several programs that track and monitor variables in the system that never reset and clear when a soft boot is invoked.

 

But do after several hard reboots are completed . . .

- This feels like a "du'h" moment, I have been running the 5.0.2 beta release and haven't thought about it since.  I needed some new programming features to finally get the WifeAcceptance™ factor high enough she was happy. (worth sharing I suppose in another post what I did).  I could try down grading if not just to learn if that is the source of my problems.

[Teken]

Its a lot work and probably some programming changes to go from 5.02 back to the 4.XX series firmware. But it would remove one potential area for problems as 5.02 is very much Alpha firmware.

 

I can't honestly say if 5.02 is the issue or not but its another possible step to try. Please do keep us all in the loop as to what you find keeping in mind you can always submit a service request and UDI will certainly get you squared away: http://www.universal-devices.com/contact-support/

 

Please do reference this thread so they can mark it as solved once completed.

[SteveT]

I am having the same problem.  Replaced a PLM, and it looks like control is working, but i do not see communication when a switch is triggered locally.

 

I am also running 5.02 - Have not done a configuration restore yet..

[SteveT]

Follow-up, deleted, and re-added a device, and now the local triggering is showing under the debugger.. Looks like something not getting fully restored to the PLM?

 

Trying to avoid re-linking every device,.. Ideas?

 

Thanks

[Michel Kohanim]

Hello all,

 

The most important thing to check:

http://wiki.universal-devices.com/index.php?title=INSTEON_No_Status_Feedback_From_Devices

 

Also, you may have done File | Restore Modem on a dead PLM. So, check for 00.00.00 in the middle of link records for those devices that do not report status. If so, then you need to restore a GOOD backup from before the PLM died (not immediately before) and then do File | Restore Devices.

 

With kind regards,

Michel

[kck]

Michel,

Is there any possibility that you could add code to the system to have it do a rebuild of its internal database for cases like this.  The symptoms above are very similar to mine where no scenes got pushed to the new PLM.  My case also would not "see" some locally triggered events.  I can fix things by individually deleting and readding devices to the scenes but this is labor intensive, particularly if the device in the scene has individual level/RR settings.  The odd thing is that the ISY clearly "knows" what things should look like because the display in the admin console shows it all.  It is just that somewhere internally the ISY isn't pushing all the info to the new PLM.  (E.g., in my case looking at the new PLM tables showed relatively few entries but one I would delete and then readd a device to a scene additional entries would become populated in the PLM)  So it seems that there is something miscomputed between the visible database and the pushed one.  If there were a way to essentially automate the fix of recreating the internal versions of scenes it sure would make fixing this case a lot easier.  I can go back to a backup but I'm not sure if my  most recent backup has all my changes (better user discipline would help here but we are all fallible).  It just seems that this case related to a replaced failed PLM gets reported here often enough that a better repair mechanism would be of great value.

[Michel Kohanim]

Hi kck,

 

That's precisely what ISY does and that's why in these circumstances I always recommend using a GOOD BACKUP and then do File | Restore Devices.

 

With kind regards,

Michel

[kck]

Michel,

I guess that leaves me confused.  The admin console shows a correct setup for scenes etc.  However, what gets pushed to the PLM does not contain all the scenes.  Since the PLM is new and reasonably assumed good where is the problem arising from.  At the HI level the ISY knows exactly what the relationships among the devices is but it is unable to push that info correctly to the PLM and devices - so where does the issue arise if you are rebuilding your internal structures?   It seems to me that since the HI shows correct info there must be something within the ISY code that is in error - no?  After all nothing is being changed in the network/PLM to make things work.  I certainly believe that you are rebuilding something but given that the ISY appears to have within itself 2 world views - the one it shows me and the one it pushes out - there ought to be a way to say to it make the internal world view correspond to the one you are showing me.  And none of this should be related to a backup.  As a thought experiment, were I to query the entire status of the ISY via the rest interface and then issue the necessary commands to automatically delete items from scenes and readd them with correct settings I think I would get back to a physical system that corresponded to the one shown in the admin console. If that would in fact work then why can't you do this internal to the ISY if requested?

 

Kevin

[Michel Kohanim]

Hi Kevin,

 

With all due respect, please trust me!

 

For your reference:

Information in ISY: it all depends on what was DONE right before you decided to CHANGE the PLM. For instance, some try File | Remove Modem, some tried File | Restore Modem on a dead PLM. All these change what's going to be written back to devices and the PLM. And these have NOTHING to do with HouseLinc.

 

With regards to "none of these should be related to backup", well, they are: backup from a working system recreates all the linkages based on the working system and regardless of what may have transpired after the backup. So, if PLM linkages were corrupted for any reason (and could not be recreated), then the backup will restore them.

 

With kind regards,

Michel

[kck]

Michel,

Sorry - I didn't mean to imply I didn't believe you.  I'm a lifelong software guy so I always try to mentally rearchitect devices I use to understand what is going on.   I just don't personally understand how the HI can have the right information but that there is no way to extract that info and then reinput it to recreate the correct internal linkages.  Still don't after your explanation but it is your product and for the most part I am a happy user of it and certainly greatly appreciate your personal level of customer support so while I'd love to understand for purely personal curiosity reasons what is going on in this failure case I guess I'll have to content myself with just being a user. 

 

Kevin

[SteveT]

I performed the RESTORE from an old backup, and things seem to be back to normal.  Thanks Michael.

 

This is in addition to running the PLM restore previously (first).  I am running 5.0.2 .

 

-Steve

[Michel Kohanim]

Hi Kevin,

 

No worries at all.

 

Every time you link, add to scenes, change anything all are stored in ISY. When you backup, all is backed up. If you Restore PLM when the PLM is dead all records will reflect that. Now when you get a new PLM, corrupted data (based on the dead PLM) is going to be restored to the new PLM. The only way to fix this is to restore a backup from before doing the restore modem.

 

With kind regards,

Michel

[stusviews]

Hi Kevin,

 

No worries at all.

 

Every time you link, add to scenes, change anything all are stored in ISY. When you backup, all is backed up. If you Restore PLM when the PLM is dead all records will reflect that. Now when you get a new PLM, corrupted data (based on the dead PLM) is going to be restored to the new PLM. The only way to fix this is to restore a backup from before doing the restore modem.

 

With kind regards,

Michel

 

Thus the request need for a scheduled backup.

[jerlands]

Thus the request need for a scheduled backup.

 

+1

 

 

Jon...

[kck]

I'd also second the scheduled backup option with a setting to keep at most n backups.  I have other systems that do this and it works well in that you always have a few recent backups (enough to get back before any corruption) but at the same time don't fill your disk with old backups.  Actually in the case of ISY you could even think about conditioning the backup timing on the existence of changes to links/scenes/devices - no reason to backup if it will be the same as the previous backup.

 

Kevin

[Whisp]

I wanted to update I ended up contacting support.  Unfortunately I needed to remove my devices from ISY and add them back.

 

Interestingly, my programs retained the correct devices (programs must store the insteon address instead of an ISY id) but they didn't seem to work.  I found that if I click on a line of a program that contains a device, make no changes, click "update", and press save, I can get them working again.