how to retry sub-program when module is "missing"?

[aweber1nj]

I have an Insteon outdoor (on/off) module that is out in my detached garage.  For whatever reason it is occasionally not found or "offline" per the ISY.  I assume this is some combination of factors including distance to the garage, what circuits are on in the house, etc., that would take me an unreasonable time to really figure out.

 

For example, I logged into the controller just now and it displayed a message that the module was not found.  When I right-clicked on it and chose "Query", it came back with the current (and correct) status.

 

So my question is if anyone has any code-snippets or best-practices to workaround this situation when I need to switch that module in a program?  It didn't switch-on at dusk (other modules reacted correctly to that program), and like I said, when I went on to the ISY it showed it offline.

 

Does anyone have any recommended "retry logic" that will attempt to re-communicate with the module and make sure it switches to the correct state?  Perhaps with a timeout (like only try 10x over 5min or something so it's not trying "forever")?  Should I insert some kind of explicit "Query" into the program before sending a command and see if that helps bring it online first?

 

Thanks for any ideas/tips/tricks!

 

(Yes, these are Holiday Lights! )

-AJ

[stusviews]

The Motion Sensor is RF only. If you don't already have a dual-band nearby, then start by installing a Range Extender in the garage.

[Teken]

I would perform a query first as one program so the on / off module would refresh its current state. Once known your second program could activate.

 

You can also use IS RESPONDING / is not RESPONDING to ascertain its current status.

 

I also agree with Stu you should deploy another range extender near this location.

 

Encrypted By: Phoenix Security Solutions

[aweber1nj]

The Motion Sensor is RF only. If you don't already have a dual-band nearby, then start by installing a Range Extender in the garage.

This is a 2634-222 outdoor on/off module.  AFAIK, it's dual-band, and it's certainly not a motion sensor.

[stusviews]

Oops

 

What else is in the garage that's on the powerline?

[aweber1nj]

The garage door openers.

 

If I do something like this: 

From 11PM to 11:30PM (same day)
  AND Status Outdoor2 is responding
  AND Status Outdoor2 is On

Then
  Set Outdoor2 Off

Will this program run ONCE between that time when the Outdoor2 module responds?

 

ASSUME: I have another program for that time period that Repeats every 1 Minute, "Query Outdoor2" while it is NOT responding.

 

(I'm still confused as to the "FROM" condition and how often the ISY will check other conditions like the event that the Outdoor2 "is responding" -- since the second program will attempt to query it every minute.)

[stusviews]

The program will run anytime the status of the Outdoor2 changes to On within the time period specified. Status monitors change, no matter how the status changed.

[aweber1nj]

The program will run anytime the status of the Outdoor2 changes to On within the time period specified. Status monitors change, no matter how the status changed.

So the status has to change -- an event regarding a change in status of the module has to occur during the time-period for it to trigger?

 

If that is the case, then those "Status" clauses would always rely upon another program/scene or someone manually activating the module, right?

 

Thinking more about it, that strawman program (outlined above) did work last night, and the module was already responding and On when the time-period arrived.  So maybe if ANY of the triggers changes, the IF statement will be evaluated, which is kinda what I want in this case...

• If the time-period starts, and the lights are on, turn them off.
• If the time-period starts and the module is not responding, then you have to just wait (unfortunately).
• If, during that same time-period, my other program is running a Query-Module every minute until it succeeds...if the module responds to a query, it would (I am guessing here) change its status to "Responding"...so evaluate the IF statement (and turn them off).

That's what I want anyway, I'm still fuzzy on how the FROM-TO part evaluates (and how often it evaluates).

[ergodic]

If you have fluorescent lighting in the garage then you probably need to put them through a filterlinc.

 

If the garage is on a subpanel then you may need to do something there. If not, I agree with the other posts: try range extender(s), put one near the start of the branch that goes out to the garage. If it still doesn't work then even try two with the other in the garage itself.

 

Whatever, since you have a reasonably new dual-band unit and you're having comm issues then it's either poor signal, signal suckers, or line interference from something, and you really want to find out what that something is. No amount program finesse will really ever fix it. Assuming it's only the detached garage it shouldn't be too hard to sort out. It really helps to have a laptop or smartphone with remote access in order to access the ISY console while you're out there testing.

 

Another idea might be to try setting MR=3 inside the ISY configuration via telnet as a test (this sets the max number of ISY retries.) I suspect UDI will say - with good cause - that's not a great idea, but that's how I have mine configured and it does help with some issues  (in my case mainly getting successfully through endless restores on the older non-DB devices when there are a lot of links.)

 

As a last resort, you can of course write a program with no conditional clause and a "repeat x times" that does a query & wait, and call that from your other program. But from experience I can tell you it'll never be very satisfactory.

[LeeG]

At From time the Program is triggered with a True condition that could finally evaluate False based on other checks in the If.

 

At To time the Program is triggered with a False condition that could finally evaluate True based on other checks in the If.

 

In a simple example .....

 

If

  From 2:00 PM

  To 3:00 PM

Then

 

Else

 

At 2 PM the Program is triggered as True running the Then clause

At 3 PM the Program is triggered as False running the Else clause.

[aweber1nj]

@ergodic: I want to thank you for all the good ideas.  I will see which of these I can investigate further.

 

@LeeG: So the From-To doesn't really act like a test after the (milli-)second the time hits the actual "From", except when the time hits the actual "To"?  The way it's worded, I was hoping this is a time-range where the rest of the conditionals can determine the final T/F path -- when there are additional conditionals.

 

In other words, if a STATUS changes during the time-range, does the From-To portion still return TRUE (provided it's not exactly at the TO time)?

 

Thanks for the details!

-AJ

[oberkc]

Yes, it can act also as a time range. If there are other program conditions, the from/to will still be considered TRUE.

 

A program will be triggered by its conditions. From/to conditions are triggered twice only. Status conditions are triggered at any CHANGE in status.

 

Once triggered, however, ALL conditions are evaluated, and the from/to condition will always be evaluated as TRUE between the specified times.

[aweber1nj]

@oberkc:  Thank you for the clarification.  That's the details I was looking for.

 

Still trying to fully solve the original issue, but thank you very much for that info!

[oberkc]

I know of no easy way to troubleshoot communication issues. Unless you have one of the classic problems (failure to couple phases, lots of stuff plugged into same circuit as plm), there is not much I can offer that doesnt take time. Only you can judge whether the amount of time is unreasonable.