Clearing "Pending Write" for battery devices

[gduprey]

Howdy,

About 6 months ago, my PLM died and had to be replaced.  It took a few hours to get everything relinked (I have a fairly large insteon setup), but all the plugged in devices eventually were updated and talking reliably to the new PLM.

The same cannot be said for my battery powered devices.  There about 34 of them spread around the house - motion sensors, door sensors, leak sensors, etc.  They are all marked as having a pending write (the '1011' symbol next to each device on the admin console display).  The problem is a lot of these things are "dug in" (like door sensors) and pulling and waking all of these will take a long time.  More importantly, it appears entirely unnecessary -- all the battery devices are working fine (heartbeats, batter reports, activity, etc).  No delays or anything.  I suspect being RF based, they don't have as "tight" a bound/link to the PLM as the powerline devices do.

So everything is OK and has been for months, but I want to "clear" those pending write icons.  I clearly do not need them (and am willing to live with any problems, unseen in 6 months, as skipping this write may create).  I just want to clear/delete that constant "nudge" in the console.

Is there a way (short of 4 days of wandering around the house) to clear the pending write flags?

Thanks,

Gerry

 

[Goose66]

This has been discussed several times before, including back in early January when I made a suggestion for just such a feature. I think the net-net is that there is currently no way to clear the pending changes. If the primary problem is the time that the Admin console takes to write to those devices every time you make a change to anything, then the suggestion is to disable the wireless devices until you can get around to them to perform the updates. They should still operate normally even if disabled.

[stusviews]

Write a program for each sensor that'll update when the sensor is activated. It's most useful for motion sensors. door sensors, etc. A leak sensor requires tapping the set button. It's best to keep the program disabled to save battery usage.

BR Courtyard Sensor

If
        Control 'BR / Devices / BR Courtyard-Opened' is switched On
 
Then
        Set 'BR / Devices / BR Courtyard-Opened' Write Device Updates
        Wait  4 minutes
        Disable Program 'BR Courtyard Sensor'
 
Else
   - No Actions - (To add one, press 'Action')

[gduprey]

So without doubt, the "write a program for every device" was the "best" solution - Thanks Stu!

That said, what a awful, painful and klunky way to handle this - battery powered devices are a bit of a pain and swapping the PLM makes this something that truly sucks for larger installs.  This seems like the ISY could provide some generalized ability to auto-program any battery device with pending writes when it hears from the device (even if that had to be turned on).  Since there is no generic way to write such a program, this is dumping a nasty situation on the end user with no practical solution.

And no, I don't expect UDI to fix every situation, but replacing a PLM is something they have already expended a good amount of time to make work.  And it does - for non-battery devices.  Why not complete the effort for battery based devices as well?

Gerry

[larryllix]

4 hours ago, gduprey said:

So without doubt, the "write a program for every device" was the "best" solution - Thanks Stu!

That said, what a awful, painful and klunky way to handle this - battery powered devices are a bit of a pain and swapping the PLM makes this something that truly sucks for larger installs.  This seems like the ISY could provide some generalized ability to auto-program any battery device with pending writes when it hears from the device (even if that had to be turned on).  Since there is no generic way to write such a program, this is dumping a nasty situation on the end user with no practical solution.

And no, I don't expect UDI to fix every situation, but replacing a PLM is something they have already expended a good amount of time to make work.  And it does - for non-battery devices.  Why not complete the effort for battery based devices as well?

Gerry

Many/most battery devices will not perform this. I had the battery write later option on with programs to update them and my MSes wouldn't do it. The result? A cache full of Insteon commands that was grinding my Insteon network into the ground every time an MS motion was detected. 20-30 seconds responses became typical. 

 

Letting the updates "drain" made my system fly like new again.

[gduprey]

I feel like at this point, UDI knows enough about battery powered Insteon devices, that they know each devices behavior.  If there are devices that can only be "reprogrammed"/written to with a physical button push, then they would know to wait for that.  My thinking is just a mode where when enabled (after a PLM is replaced or manually turned on), anytime they receive a message from a battery device that 1) has a pending write and 2) can be remotely written to, they should do it.  Any exceptions would be omitted.

This wouldn't grind down the network - there would be no sending a command until the remote device woke up and sent something.  So one device at a time (from heart beats or when the device is used/triggered).

As things stand right now, I am seeing the "grind the Insteon network" down problem as periodically, the ISY attempts to visit each pending device and write to it (all of which fail).  Switching to a model like the above mentioned program (wait for an event and then write the config) would reduce/eliminate all the traffic from the current fruitless attempts to blindly write to all pending battery devices.

[gduprey]

Also, to extend the usefulness of the above program, at least for Leak sensors, you can also wait for a HBEAT to occur and send the config.  Using that, and with some patience, you can re-program all pending devices without ever having to physically visit them.  I have not had a chance to test this with the motion detectors and door switches, but I would hope they work too.

Here's what I am doing for the moment:
1) A folder where all the battery reconfig programs live
2) A variable that is set to 1 when I want to enable this.  The folder then has that variable enabling (or normally, disabling) all programs in that folder
3) Each program handles one device (tedious, but....) and looks like this:
 

Attic AC Leak - [ID 00BA][Parent 00B3]

If
        Control 'Attic AC Leak Sensor / Attic AC - HBEAT' is switched On
     Or Control 'Attic AC Leak Sensor / Attic AC - HBEAT' is switched Off
     Or Control 'Attic AC Leak Sensor' is switched On
 
Then
        Set 'Attic AC Leak Sensor' Write Device Updates
 
Else
   - No Actions - (To add one, press 'Action')
 

Then if I have reason (like a PLM change) to re-program battery devices, I set the variable to 1 (enable), the folder is active and all the per-battery devices are ready to program next time they wake up.  When they are all programmed (1-2 days), I set the variable back to 0 and disable the process.

Any one curious as to why there are three events,  the HBEAT works by sending a DON one day, then DOF the next (toggle), so the above catches the next heart beat transition (either way) or if they button is pressed on the device (Switched On) and sends along the config.

Gerry

[toflaherty]

Good idea to put the state variable controlling the folder of these programs.  I haven't had an issue with these programs running permanently, but I have still implemented this idea to only run them after a required change.

[larryllix]

In addition to toflaherty's ideas above, I have noticed that when you install a condition in a folder there is no way to make it True = active until the variable changes.

 

IOW, after you install the  code into  the folder conditional section, or modify it in any way, the folder will be negative, disabling all programs inside, until you change that variable value. Saving the programs/ folder doesn't evaluate your expression despite it being True, it will not allow programs running.

[gduprey]

I wonder if that is tied to whether the variable is a state variable or normal.  I guess I could imagine that, like using a variable in a regular program, transitions aren't tracked on change? 

Have you ever tried this using a state variable vs a normal variable?

This is the first time I've ever using an expression on a folder, so in learning mode...

Gerry

[larryllix]

2 minutes ago, gduprey said:

I wonder if that is tied to whether the variable is a state variable or normal.  I guess I could imagine that, like using a variable in a regular program, transitions aren't tracked on change? 

Have you ever tried this using a state variable vs a normal variable?

This is the first time I've ever using an expression on a folder, so in learning mode...

Gerry

Yes. I don't figure an Integer variable would work in any case since it doesn't doesn't cause evaluation of anything upon changing value.

 

I mention it as I found it as a gottcha' when I did the same technique  to be able to enable / disable a bank of programs. After finding none of my programs running  weeks later I discovered that the involved variables must be changed after the folder condition is saved. No evaluation is done upon saving the newly edited logic.

[gduprey]

Hmmm -- hard to come up with a reason for that behavior -- sounds like a bug.  Is there somewhere where that can be noted to UDI for comment or fixing?

[Michel Kohanim]

Hi gduprey,

Yes, you can definitely create a ticket with succinct information on how to reproduce it. Please DO NOT send a link to this topic since it will take much longer to sift through all the back and forth and arrive at the actual bug. Please do make sure you include your firmware version (a screenshot of Help | About is better).

With kind regards,
Michel