Battery (Leak and Motion) devices stop reporting status

[ISY4Me]

Since I migrated to ISY on Polisy, I have had issues with Leak and Motion sensors stopping status updates.  A query will update some of the attributes for the device, but not the status.

This has happened three times since my isy994 to IoP conversion.  During the process of evaluating the problem, I found that Restoring the PLM will allow normal status reporting to restart.  My "fix" is to reset the PLM first and then start the normal Restore PLM procedure.  In today's recovery, I disabled the updates to battery devices and the status reporting for them returned before I went around to write updates to them.

What I don't know is why the status reporting stops... I will see some unexpected program response and when I go and look, the status field for the sensors are empty.  In the three occurrences, all 3 motion sensors and 1 leak sensor all stop updating the status at the same time.

My only thought is that it is a PLM issue, but why would it only be an issue with the status of the battery devices stopping their reporting?  The PLM is quite old, probably 10 years, but this is the only unusual behavior that has been observed... all other PLM control over numerous Insteon devices has been normal.  Any thoughts from the community?

I do have a spare 2413S PLM, but if I swap them out I will not know for weeks whether or not that is a source of the problem.  Also, I have been focusing on getting all programs stable on IoP, so I have not upgraded yet... still on 5.3.0.

[larryllix]

48 minutes ago, ISY4Me said:

Since I migrated to ISY on Polisy, I have had issues with Leak and Motion sensors stopping status updates.  A query will update some of the attributes for the device, but not the status.

This has happened three times since my isy994 to IoP conversion.  During the process of evaluating the problem, I found that Restoring the PLM will allow normal status reporting to restart.  My "fix" is to reset the PLM first and then start the normal Restore PLM procedure.  In today's recovery, I disabled the updates to battery devices and the status reporting for them returned before I went around to write updates to them.

What I don't know is why the status reporting stops... I will see some unexpected program response and when I go and look, the status field for the sensors are empty.  In the three occurrences, all 3 motion sensors and 1 leak sensor all stop updating the status at the same time.

My only thought is that it is a PLM issue, but why would it only be an issue with the status of the battery devices stopping their reporting?  The PLM is quite old, probably 10 years, but this is the only unusual behavior that has been observed... all other PLM control over numerous Insteon devices has been normal.  Any thoughts from the community?

I do have a spare 2413S PLM, but if I swap them out I will not know for weeks whether or not that is a source of the problem.  Also, I have been focusing on getting all programs stable on IoP, so I have not upgraded yet... still on 5.3.0.

Battery devices will not respond to status queries unless they are placed in linking mode first.

However by clicking on Query for battery devices you can flood your Insteon comm cache until ISY bogs right down.

I suggest you put each battery operated device in linking mode, one at a time, and then use write updates to each device before doing the next, until all your 1011 icons are gone again.

[ISY4Me]

Additional information I should have included in the original post…

When I noticed that the status fields were not populating, I manually triggered each motion sensor and the status did not indicate any activity.  I also manual tested the leak detector and the status field did not populate or indicate that it was wet.  This completely empty status field that didn’t change with activity is what I observed in all three problem periods. 
 

i also went to each device and put them in the linking mode and initiated a query there as well and the status field remained unpopulated. 
 

The odd thing I observed this evening is that after Resetting and Restoring the PLM with battery updates disabled, there were no 1010 icons next to the motion or leak sensors… yet the sensors were responsive to activity and the status field updated with any trigger…. essentially all these sensors were working as expected. 
 

I will continue evaluating tomorrow and check daily to see if I can catch when this non-responsive status field returns. 

[larryllix]

Do you have dual band Insteon devices nearby each battery operated device? Battery operated devices are RF only and not likely to communicate with your PLM directly.

[ISY4Me]

1 hour ago, larryllix said:

Do you have dual band Insteon devices nearby each battery operated device? Battery operated devices are RF only and not likely to communicate with your PLM directly.

Two of the motion sensors are surrounded with dual band Insteon devices. The remaining motion sensor and the leak sensors are a little more isolated, but probably are within 25 feet.  
 

That being said, what I have seen is when one sensor has lost status updating, they all lose it.  The motion sensors have been in use for 5-7 years and status updating issue never occurred before switching to IoP this year. 
 

I need to isolate if this is a PLM “end of life indicator” or IoP issue, which will require the PLM to be replaced with my spare unit. Then, it is just waiting to see if it is stable… I don’t know what triggers the status update failure, so I need to monitor closely.  It could take a while to post feedback on this experiment. 

[larryllix]

2 hours ago, ISY4Me said:

Two of the motion sensors are surrounded with dual band Insteon devices. The remaining motion sensor and the leak sensors are a little more isolated, but probably are within 25 feet.  
 

That being said, what I have seen is when one sensor has lost status updating, they all lose it.  The motion sensors have been in use for 5-7 years and status updating issue never occurred before switching to IoP this year. 
 

I need to isolate if this is a PLM “end of life indicator” or IoP issue, which will require the PLM to be replaced with my spare unit. Then, it is just waiting to see if it is stable… I don’t know what triggers the status update failure, so I need to monitor closely.  It could take a while to post feedback on this experiment. 

Sounds like you have some interference with your comms happening.

Possibly your new PLM is not good? Are you using the same PLM as your ISY994?

Have you done factory reset and Restore  on each device?

[ISY4Me]

Due to it’s age, I also have suspected the PLM.  It is date coded 1329… I think it was put into service around 2014-2015.  That is why I want to try swapping out with my backup (which I have not yet done). The backup PLM is date coded 1439, but it has been in storage since it’s purchase… probably around 2016. 
 

That original PLM was the same I used with the isy994.  If it still had useful life, I wasn’t ready to retire it when the Polisy was commissioned. 
 

As far as resetting every device in the system… no,  I have not done that, but I can try that next before switching to the backup PLM (trying not to change more than one thing at a time).
 

Just note. The failure that I am experiencing does not have a defined trigger.  So when I try something, I just have to make the change and then wait to see if the status stops updating.  I will update this discussion when I see what happens with the original PLM and resetting all devices, which I will do this morning.  
 

In an attempt to define a trigger for the problem… I have experienced some power glitches since all this started, so I simulated a power glitch this morning (toggle the main breaker) to see if that was a trigger.  When the system restarted, all the battery devices were reporting their status and they self updated the status with motion and leak test. 

[Techman]

13 hours ago, ISY4Me said:

Additional information I should have included in the original post…

When I noticed that the status fields were not populating, I manually triggered each motion sensor and the status did not indicate any activity.  I also manual tested the leak detector and the status field did not populate or indicate that it was wet.  This completely empty status field that didn’t change with activity is what I observed in all three problem periods. 
 

i also went to each device and put them in the linking mode and initiated a query there as well and the status field remained unpopulated. 
 

The odd thing I observed this evening is that after Resetting and Restoring the PLM with battery updates disabled, there were no 1010 icons next to the motion or leak sensors… yet the sensors were responsive to activity and the status field updated with any trigger…. essentially all these sensors were working as expected. 
 

I will continue evaluating tomorrow and check daily to see if I can catch when this non-responsive status field returns. 

Put your battery operated devices into the linking mode and then do a restore device.

Only one battery operated device should be in the linking mode at any one time. After you do the restore device push the set button to take the device out of linking mode, the led should then stop flashing.

[ISY4Me]

2 hours ago, larryllix said:

Sounds like you have some interference with your comms happening.

Possibly your new PLM is not good? Are you using the same PLM as your ISY994?

Have you done factory reset and Restore  on each device?

At this point I am convinced that this is a PLM issue.

I reset all devices in the network with the Polisy and PLM powered down.  I then reset the PLM again and then powered up the Polisy and executed a Restore on IoP (battery updates disabled).  The mistake I made was walking away when I did this, as when I returned I could not communicate with the newer Insteon Dual-Band devices, but could communicate with the old Insteon devices.  

Confused at all of this, I executed the Restore again (battery device updates disabled).  This time I watched it and it would get to 6% and then abruptly stop and I still could not communicate with the Dual-Band Insteon devices.  

This behavior make me seriously question the PLM... so I commissioned the backup PLM, reset the backup PLM and re-powered the Polisy.  This time I watched the Restore process and it proceeded past 6% and shortly thereafter I heard the ding on the first device is it was updating, then the 2nd and so on.  This seemed normal and the restores I had been doing of the issues of the last three months where not like this.

This time, after the restore process was completed, I did have the 1011 icon on the battery devices... which I did not see during the system restores of the last three months.  I proceeded to write the updates to all the battery devices one by one.  That process went as expected.

At this point everything appears normal and I can communicate with all devices.  Considering the observations during this process, I am expecting things to stay stable going forward, but only time will tell.  I think it is time to rebuild the old 2413S and see if it can be put back into normal operation for future backups.

Thank you for all the help.

 

[MrBill]

@ISY4Me Disclaimer: I did quit reading a few posts ago, but if you have any 1011 icons to the left of any battery powered devices.  Deal with that.  It causes problems.  @larryllix did mention it in his second reply.   Unwritten instructions to battery devices reek havok on insteon communications, because the ISY keeps trying.

[dex]

@ISY4Me Have you discovered a fix for this?  I am in a nearly identical situation.  Migrated from ISY to ISY on Polisy (IoP) earlier this week and my insteon motion sensors (v. II) states/events are not being picked up.  

No pending updates (per @MrBill's suggestion).

Plenty of dual-band coverage (per several commenters).

All sensors are behaving the same way (7 of them).  In linking mode they restore fine, they respond to Query, etc.  When operating mode, the LED flickers with motion.

When I do a Query (in linking mode) the admin interface instantly gets temperature, ambient luminance, etc., but Status and Battery Level are not reported.  Is that possibly a clue?

Any hunches or suggestions?

[ISY4Me]

@dex My system has undergone many changes since the original discussions, so these comments are coming from memory.  

I convinced myself that my PLM was flaky, but I had no definitive proof.  So I replaced the capacitors on the PLM, factory reset when powering up for the first time and restoring the PLM when IoP was operational. To be safe, I took the approach of factory resetting all devices in my network before I powered up the rebuilt PLM for the first time... it was an attempt to try to start from an as clean a slate as possible.  

When updating for that first power up, I put all the battery devices in linking mode before the process started, but you can always disable that on the menu bar and manually update the battery devices after the power up.   As you stated, the battery devices should be set in linking mode when the user queries the devices to get the original update... that is normal behavior.  

After all of this, I did see more "normal" battery device behavior.  The Insteon motion sensors were exercised regularly... the Insteon Leak sensors did show updates in battery level when there was a significant change.

Sadly, I didn't operate in that setup for very long, so I can't comment if it was a true solution.  Shortly after that effort, I decided to convert all hardware to Z-Wave.  Battery devices on z-wave still have some similar constraints... that was not the reason I moved to z-wave, but there are some always powered z-wave sensor hardware options and that has helped stabilize the motion and leak sensors in my setup.

[MrBill]

@dex  Keep in mind with wireless sensors traffic is one way, and the sensor decided when to send heartbeat and low battery.  Those values will remain unpopulated in the the ISY (or IoP) until the sensor talks. 

Have you waited 24+ hours for the heartbeat.   What model wireless sensor?  what heartbeat program are you using?  (hint right click the name in the program tree and select "copy to Clipboard" from the the context menu and then paste into a forum post.   Asking because there are multiple heartbeat programs used.  Some will autostart with the first heartbeat, at least one needs to be manually started.

[dex]

@MrBill I am using an Insteon Motion Sensor II.  I have several of them and had them working just fine for a few years with ISY 994.

 

Confusing Observations:  I put an MSII into linking mode and then Query the device.  

      Status:
      Battery Level: 80%
      Temperature: 70.3F
      Battery Powered: False
      Luminance: 59%

The devices have a battery and it's even reporting a battery level, yet the Battery Powered state is False.  That's puzzling.  

Since all of my MSIIs are working the same way, I have to believe the communication issue is something with the Polisy or IoP.  Those are the only new things in the equation.

 

Heartbeat Program

I do not have a heartbeat program.  Do MSIIs send a heartbeat pulse that could get received, even if motion events are not getting through?  Or, do the motion events serve as a heartbeat?

Just wondering what I'd learn from having such a program.  And, is there a simple one you'd recommend?

I do have several motion-detection programs.  They are all pretty simple, such as this one...

Gar Motion/Entry Lights On - [ID 000B][Parent 001A]

If
        'Garage Sensors / Garage 43 Motion' is switched On
     Or 'Garage Sensors / Garage 47 Motion' is switched On
     Or 'Garage Sensors / Garage 4D Motion' is switched On
 
Then
        Set 'Garage / Garage Overheads' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Edited September 15, 2022 by dex

[larryllix]

5 hours ago, dex said:

@MrBill I am using an Insteon Motion Sensor II.  I have several of them and had them working just fine for a few years with ISY 994.

 

Confusing Observations:  I put an MSII into linking mode and then Query the device.  

      Status:
      Battery Level: 80%
      Temperature: 70.3F
      Battery Powered: False
      Luminance: 59%

The devices have a battery and it's even reporting a battery level, yet the Battery Powered state is False.  That's puzzling.  

Since all of my MSIIs are working the same way, I have to believe the communication issue is something with the Polisy or IoP.  Those are the only new things in the equation.

 

Heartbeat Program

I do not have a heartbeat program.  Do MSIIs send a heartbeat pulse that could get received, even if motion events are not getting through?  Or, do the motion events serve as a heartbeat?

Just wondering what I'd learn from having such a program.  And, is there a simple one you'd recommend?

I do have several motion-detection programs.  They are all pretty simple, such as this one...

Gar Motion/Entry Lights On - [ID 000B][Parent 001A]

If
        'Garage Sensors / Garage 43 Motion' is switched On
     Or 'Garage Sensors / Garage 47 Motion' is switched On
     Or 'Garage Sensors / Garage 4D Motion' is switched On
 
Then
        Set 'Garage / Garage Overheads' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

No heartbeat. Insteon battery devices that send a low battery signal do not send heartbeats.

UDI could never get co-operation from Smarthome, in the form of a protocol/spec sheet so the whole interface was hacked. Some data is still not understood perfectly.

I ignore the non-MS style parameters. They always appear incorrect and random. Any attempts I have made to "calibrate" them has resulted in further errors in readings.

[MrBill]

@dex  I agree with @larryllix that you may never make sense out of MSII data, I also wasn't aware that MSII doesn't send heartbeat-- but I don't own any MSII's either.

Most Insteon wireless devices tho do send heartbeat and have a heartbeat node, there are simple programs to monitor heartbeats and report when they have stopped.