Jump to content

Subset of devices won't write


Snibley

Recommended Posts

Posted

I'm Stuck...

I've fully set up two homes with Insteon devices and ISY controllers and until now have never had the following problem before....

A subset of my household devices, despite a longstanding and unaltered existence in my home, suddenly will not accept updates (writes), no matter what I try.

I've also had eight leak sensors which work perfectly, but I tried adding two more and the system sees them as devices but won't poll them, with the associated program sending daily "Heartbeat" error messages for just the two new adds.

I've tried completely removing several types of devices then reintroducing them, and they appear to register fine.  They even perform correctly in preexistent scenes.  But they Will Not receive updates (writes).

Where these examples worked perfectly in prior time and without complaint, now I can plug the PLM in right next to them and they still won't receive writes.

I've long been running under 4.7.3 but just updated to 5.0.16 RC1, literally hours ago.  No change in the situation.

Also, an alternate and new PLM has been installed and still no change.  Values match under Help | About and Java V8 U231 cache was cleared.

I'm missing something; any ideas?

Posted

Hello Michel,

 

I seldom write but have lurked this forum for years; I know you...and I also miss LeeG.

>>

In my original post, I meant to infer that this too has already been tried...  

> ….now I can plug the PLM in right next to them and they still won't receive writes. <

Having also done this in prior time, I've seen a change of PLM position produce absolutely stellar results.  But in the current problem, there is a concrete refusal among all affected devices to make any change at all.  Watching the Link count when attempting to write to the affected devices (PLM in new position), the count stays at Zero.  Normally I'd expect a "hard of hearing" situation to at least gain a link or two during a write, but not now.

Here's another symptom:

I have five dual-band devices in my two-car garage and reception there is steadfastly good.

Each of two cars has an RL2 keypad on the visor, each programmed identically.  One button of each pad does the following:

a) Switch garage lights on or off (which is direct interaction with other Insteon devices via Scene.)

b) In either case [On or Off] of (a), Wait 2 minutes then turn on a bug light for an hour. (wherein the ISY senses the On/Off command then invokes the additional Bug Light program)

##

BOTH KEYPADS USED TO PERFORM IDENTICALLY AND PERFECTLY but now....

One pad continues to work perfectly but...

...the other will only turn the lights On/Off, Will Not invoke the Bug Light program via ISY.

I've tried Factory Reset / Reprogramming that keypad (no change) and also changing to a completely different keypad, again no change.

Further, I've tried re-writing the program in the ISY...again the ISY refuses to invoke the bug light program even in a new RL2.

But the Bug Light program runs fine from anywhere else but not that one keypad...original or new, doesn't matter.

>>

It's as if the ISY has developed a mule-like prejudice against some functions in a pick-and-choose fashion.

Hopefully the additional detail will help, and thank you for your attention Sir.

   - Snibley

Posted

@Snibley,

Yes, @LeeG is missed very much!

Can you please open the Event Viewer, change the Level to 3, retry any of the devices and then paste the output of the Event Viewer?

Based on your last statement, I suspect something is creating a LOT Of noise on the line. Do you happen to have any INSTEON thermostats?

With kind regards,
Michel

Posted

Yes, one wired wall Insteon thermostat (which has been powered long-term, and easily predates the problems I'm now having), and one wireless unit which is not enrolled but does have batteries installed.

Okay...Two versions pasted, both reflecting a Write command to the same exampled and affected "deaf" device...

1: Nothing touched, system exactly as described in long-term configuration....

Thu 10/31/2019 12:32:16 : [2B A7 D1 1  ] Link    3 : 0FE0 [A2714C18BCFF1F08] Writing [....4C18BC......]
Thu 10/31/2019 12:32:16 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:32:16 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:32:16 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:32:16 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:32:21 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:32:21 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:32:22 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:32:22 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:32:27 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:32:27 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:32:27 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:32:27 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:32:27 : [2B A7 D1 1  ] Link    3 : 0FE0 [A2714C18BCFF1F08] *Failed Writing [....4C18BC......]
 

###

2: Wall stat pulled open to remove power, batteries removed from wireless unit...

Thu 10/31/2019 12:35:24 : [2B A7 D1 1  ] Link    3 : 0FE0 [A2714C18BCFF1F08] Writing [....4C18BC......]
Thu 10/31/2019 12:35:24 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:35:24 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:35:24 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:35:24 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:35:29 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:35:29 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:35:30 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:35:30 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:35:35 : [INST-TX-I2  ] 02 62 2B A7 D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78
Thu 10/31/2019 12:35:35 : [INST-ACK    ] 02 62 2B.A7.D1 1F 2F 00 00 02 0F E7 08 A2 71 4C 18 BC FF 1F 08 78 06        (00)
Thu 10/31/2019 12:35:35 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC AF 2F FF           (FF)
Thu 10/31/2019 12:35:35 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Thu 10/31/2019 12:35:35 : [2B A7 D1 1  ] Link    3 : 0FE0 [A2714C18BCFF1F08] *Failed Writing [....4C18BC......]
Thu 10/31/2019 12:35:36 : [INST-SRX    ] 02 50 2B.A7.D1 4C.18.BC A3 2F FF           (FF)
Thu 10/31/2019 12:35:36 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0
Thu 10/31/2019 12:35:36 : [D2D EVENT   ] Event [2B A7 D1 1] [ERR] [1] uom=0 prec=-1
Thu 10/31/2019 12:35:36 : [  2B A7 D1 1]      ERR   1
 

FWIW Wall stat doesn't control anything, just polled for humidity and temp values to control a fan.

Thank you Michel!

Posted

@Snibley, your devices are returning a NACK:

Thu 10/31/2019 12:35:36 : [Std-Direct Nack] 2B.A7.D1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

So, either they do not have a link to your PLM or something is wrong with them. What I suggest (intrusive):

1. Reboot ISY
2. Unlink the device and link it back … if it works, then probably the PLM is not the same as the PLM with which you configured these devices. If that's the case, you need to find a good backup and do File | Restore ISY and then File | Restore Devices

If it does not work, then I am out of ideas ...

With kind regards,
Michel

Posted

 

>If that's the case, you need to find a good backup and do File | Restore ISY and then File | Restore Devices<

Um....Can a system running 5.x restore backups done under 4.x?...

 

I haven't tried your recommendations yet but the fine hairs on my neck say I might have to hand-rebuild the whole network.  Argh.

Oh well, wife visiting family for three weeks...

Poor Snibley.

Thanks again Michel.

Posted

New complication...

I started reverting back to 4.7.3, which I've successfully done in prior time.

This time, I've getting 1st 3 blues solid with blinking red.

You advised someone else to contact support....me too?  Support ticket?...

 

  • 2 weeks later...
Posted

Following is an "epilogue" to bring closure to this thread, and hopefully help others that may encounter similar symptoms as depicted in earlier posts of this thread...

After several exchanges under a support ticket, Michel decided that my PLM had lost some links.

Up to this point nothing had improved; I still had most devices working perfectly with the ISY yet others...even those that were long-established in the net and whose function remained unchanged long-term, except for needing updates related to negotiation with other devices...some of these devices absolutely refused to accept Writes.  Yet they remained enrolled with the ISY as line items in the device list.

I had tried replacing the PLM with a new one, to absolutely no benefit; the new PLM "restored" to exactly the same behavior as the prior (and apparently fully good) PLM...most devices worked perfectly, but the same problem devices...though looking like proper citizens in the device list...continued absolute refusal to accept Write commands.  Hence the ISY was forever indicating these units had a Write waiting.

"What Worked":

I had done this before with several problem devices, but at Michel's behest I deleted and re-enrolled problem units...and as I did so these devices now accepted introduction to scenes, accepted writes fully on the first try, etc.  Just like they used to do before going "deaf".

That they Did Not respond this way in earlier attempts...I can only conjecture (due to my own lack of prowess with the ISY platform...) that I had re-enrolled them, then maybe restored the PLM afterward, which *Might* (again thus stated because I'm not proficient with ISY function...) have also restored the original problem right back into the subject device.

At any rate, the only problem devices in my system now, are the ones that I haven't yet deleted then re-enrolled.  A bit of a pain in the tail, but far better than having to reestablish the entire house completely from scratch.

 In my original complaint, therein was also mentioned eight Leak Sensors which continued performing perfectly...but also the two newest which, also driven by the excellent program set contributed to a UDI forum years back...steadfastly sent "Heartbeat Error" emails to me twice a day without fail.

I have also deleted and re-enrolled those two late-addition Leak Sensors...and sending of the endless Heartbeat error messages stopped cold.

Thanks again to Brad, and Michel the Tech Support guy, whom I am informed also has a couple of other roles around the UDI offices.

   - Snibley

"...Who was that masked man?...."

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...