Improper Programm Behavior Since Firmware Update.

[apostolakisl]

I have a bunch of programs written like this.

 

If
       Status  'Master Bedroom / Master/Bath Cans L' is Off
   And Control 'Master Bedroom / Master/Bath Cans L' is switched Off

Then
       Set 'Master Bedroom / Master/Bath Cans L' 25%

Else
  - No Actions - (To add one, press 'Action')

 

After the most recent firmware update, then program is running the "then" section nearly every time I do anything to the switch. It is not a communication issue.

 

For example, I turn the light "on". The ISY admin console changes from "off" to "on" on the main page. So, ISY knows it is "on". I click "off" on the switch, it turns off, then a second later it goes to 25%.

 

Why is the program executing the "then" section? It doesn't happen 100% of the time, but it is happening maybe 2 out of 3. Is there a timing issue? For example, I click "off" the ISY changes it's status to "off", then the program tests the status?

[Michel Kohanim]

Hello apostolakisl,

 

We will look into it ... it's surely a timing issue.

 

With kind regards,

Michel

[LeeG]

apostolakisl

 

When the command being received could change the ISY "Status" of the device and the Program is checking for both the command (Control) and status (Status) what is the expectation?

 

Should the Program If evaluate what the Status was before the Off command was received or should the If evaluate the Status after the current Off command is processed?

 

That is, in the example where the device was On and an Off command is sent, is the expectation the Status should be On as before the inbound Off command is processed or Status should be Off as after the inbound Off command is processed.

 

Makes a difference in how an If is evaluated when the Status and Control are for the same device.

 

Lee

[apostolakisl]

apostolakisl

 

When the command being received could change the ISY "Status" of the device and the Program is checking for both the command (Control) and status (Status) what is the expectation?

 

Should the Program If evaluate what the Status was before the Off command was received or should the If evaluate the Status after the current Off command is processed?

 

That is, in the example where the device was On and an Off command is sent, is the expectation the Status should be On as before the inbound Off command is processed or Status should be Off as after the inbound Off command is processed.

 

Makes a difference in how an If is evaluated when the Status and Control are for the same device.

 

Lee

 

The program is designed such that pushing the "off" side of the paddle when the light is already off turns it on to 25%. I implemented a bunch of these programs a long time ago and actually copied it from the wiki I believe. It is (had been) a nice way to turn the lights on dimmly during the night. It has worked great until the new firmware installation. Now, about 75% of the time, the program runs when I shut the light off even when it was not initially off. In other words, the light is "on", I click "off", the light turns off, but then the program turns it back on to 25% a half second later. The program was only intended to run when "off" is pushed when the light is already "off".

 

It would seem that the new firmware has changed the order of evaluation. It used to be that clicking the off paddle caused the program to run, then the light turned off (if it was already on). Now, it looks like the light is turning off before the program is running (most of the time). So, in effect, the program is seeing the light as off every time you push the off button, regardless of what state it was in when you hit the off button.

 

Flow chart: (old way) starting from light NOT off

1) light status not off

2) push "off" button

3) program triggers, evaluates to false and doesn't run then clause

4) light turns off (this is good, what I want)

 

Flow chart: (new way) starting from light NOT off

1) light status is not off

2) push "off" button

3) light turns off

4) program triggers and evaluates to true

5) light comes back to 25% (this is bad)

 

Flow chart: (not affected by new firmware) starting from light off

1) light status off

2) push "off" button

3) program triggers and evaluates to true

4) light turns on to 25% (as intended)

[LeeG]

So the expectation is all initial Program If evaluation will be based on device Status before the effect of the current inbound command is posted. That pesky old multi tasking. The ISY will have to delay posting a device Status change until all Program Ifs have been evaluated except it cannot be that simple. The Status change itself causes Programs to trigger. Will be interesting to see how the ISY solves that dilemma.

 

EDIT: need something like If Status xxxxx was Off to indicate the Program is looking to check the prior status of the device, not the status as a result of the If Control command.

 

EDIT2: a Program with an If Status xxxxx is Off expects the Status to be Off when an Off command is received so this check normally wants to look at the device status after the inbound command has posted the resulting Status. Otherwise the Status is Off does not produce the expected results. Where in the If Status combined with If Control case the desire is to have the Status checked be before the inbound command has posted the resulting Status. Tricky logic to sometimes use the before value and sometimes use the after value.

[TJF1960]

How about using Fast Off instead. Seems to me I have had troubles with programs like originally posted so I have been using Fast Off instead.

 

If

Status 'Master Bedroom / Master/Bath Cans L' is Off

And Control 'Master Bedroom / Master/Bath Cans L' is switched Fast Off

 

Then

Set 'Master Bedroom / Master/Bath Cans L' 25%

 

Else

- No Actions - (To add one, press 'Action')

[apostolakisl]

So the expectation is all initial Program If evaluation will be based on device Status before the effect of the current inbound command is posted. That pesky old multi tasking. The ISY will have to delay posting a device Status change until all Program Ifs have been evaluated except it cannot be that simple. The Status change itself causes Programs to trigger. Will be interesting to see how the ISY solves that dilemma.

 

EDIT: need something like If Status xxxxx was Off to indicate the Program is looking to check the prior status of the device, not the status as a result of the If Control command.

 

EDIT2: a Program with an If Status xxxxx is Off expects the Status to be Off when an Off command is received so this check normally wants to look at the device status after the inbound command has posted the resulting Status. Otherwise the Status is Off does not produce the expected results. Where in the If Status combined with If Control case the desire is to have the Status checked be before the inbound command has posted the resulting Status. Tricky logic to sometimes use the before value and sometimes use the after value.

 

 

What you say is true. The point is that it used to work and now it doesn't. The ISY has changed either how fast it processes or the order of processing. I liked the way it used to work and would like it to still work that way.

 

And tjf1960 makes a fine suggestion, it is just that at 3am you are swatting blindly at a light switch, trying to get a double click may be out of the quesiton.

[LeeG]

"I liked the way it used to work and would like it to still work that way."

 

It is normal not to want to recode something that was "working" in the past. That may not be possible in this case. It will require Status updates happen before a Program is triggered when triggered with an If Status and after a Program is triggered and the If evaluated when the Program is triggered with an If Status and If Control for the same device. Not very logical but that may be what the intent has been all along and the latest image introduced a timing difference. Or the latest image introduced a timing difference and something that was never intended to work no longer works.

 

Will be interesting to see what UDI comes up with.

[apostolakisl]

I have taken tjf1960's idea and slightly altered it. For now, I am using the "fast off" to turn the light off when I actually want it off. The sinlge off will still get me the 25%.

 

It is almost comical. Turn the light off, 1 second later it comes on to 25%. Click off again, it goes off, then boom, 25% again. It isn't the same for every switch. Some do it darn near every time, some not so often.

 

I don't know what the creators of ISY intended when writing the first code for it, but they definitely pointed out this feature. As I mentioned, I did not brain storm it up myself, it was from an official UD publication that I got the idea.

 

Before this firmware, this happened every once in a while, but now, it happens most of the time.

 

EDIT: I do believe that ISY is responding very quickly to status changes of devices and communicating better than ever with this firmware. I do like it. So, a simple workaround to get this particular program functioning again would be great.

[LeeG]

So it has never been a totally reliable technique. That is interesting and should be helpful information to UDI.

 

Where did you find the example? I would like to see the context of the example.

[apostolakisl]

So it has never been a totally reliable technique. That is interesting and should be helpful information to UDI.

 

Where did you find the example? I would like to see the context of the example.

 

It happened so rarely before that I couldn't repeat the event while investigating. There is a very good chance that it was a failure to comunicate when the light was turned on, resulting in a proper execution of the program (from the perspective of ISY which thought the light was off).

 

The programs were presented to be used exactly as I am using them. This is a "night light" program and was presented as such. I quickly perused the wiki and didn't see this program. But I found this set of programs which is the exact same thing except for if status is on, and it is switched on (instead of off). But it is functionally the same thing. http://www.universal-devices.com/mwiki/ ... tion_Order

[LeeG]

Thanks for the Wiki link. That sure makes it look like the Status check should be predictable.

[apostolakisl]

With the new firmware update (3.1. the problem is nearly elliminated. I turned several of the switches with this program on/off dozens of times. The problem did occurr a few times. I did have my laptop with me to confirm that isy registered all actions on the switches and that it wasn't a com failure.

 

There were zero com failures in the 30 or 40 on/off cycles.

 

I didn't take exact counts, but the program now is mis-behaving maybe 5% of the time versus maybe 75% of the time with 3.1.7.

[TJF1960]

Interesting. Thanks for the update.

[Michel Kohanim]

Hello apostolakisl,

 

Thanks so very much for the update. We did go through the code yet again and that path has not been updated: i.e. we do make sure that the sequence of activities line up before processing the events. This said, we'll do a more thorough review once we are satisfied with stability of the system as a whole.

 

With kind regards,

Michel

[apostolakisl]

I played with it some more last night. I think saying it functions properly 95% of the time is pretty accurate. I was able to get 2 more misfires of the program out of roughly 40 tries.

 

I am sure you guys will get it 100% soon enough. It is not that big of a deal at a 5% error rate in this context. However, there might be a time when someone wants to use that program technique in a less forgiving application where 5% failure would be bad.

[Michel Kohanim]

Hello apostolakisl,

 

Thanks so very much for the feedback. We'll surely revisit this issue as soon as we are comfortable system stability.

 

With kind regards,

Michel

[Hurting2Ride]

Interesting. When I recently bought my ISY I tried to implement this approach (I hadn't seen the wiki - just trial and error). I ran in to the same problem of devices "bouncing" from off back to some level of on so I assumed it was not intended to be used this way. If this data point helps, that was on 3.1.2; I have not tried it since but would definitely make use of it if it can be used consistently.

[apostolakisl]

You might try updating to the latest firmware. "bounce" would be a good adjective for how it behaves when it isn't doing what it should. But with the current firmware, this is a pretty rare event.

 

It is a little odd to me that it happens like this. It would seem more likely to me that it would happen every time or none of the time. 5% is kind of odd. Especially considering that at the time I was testing it, the ISY had no other active programs. I can only assume that it has something to do with Insteon communciation fluctuations since I would thin ISY was in a steady state at the time.

[apostolakisl]

Now that I have been using the lights "real world" for about a week, I am sad to say that it is behaving improperly a lot more than when I just stood there hitting on/off/on/off etc. It is probably running the program when I turn the light off from a "not off" status 25% of the time. This is probably too much to keep the programs running. I think I am going to have to disable them.

[TJF1960]

apostolakisl,

 

Odd, I set up a couple of switches using your exact original program in the first post. It worked 100% of the time. Light was on, turned it off and it stayed off. Light was off, turned it off, it turned on.

 

The first switch I tested was an Icon relay controlling a 4’ fluorescent light. So then I thought perhaps it was an issue with dimmers. I set up the program to control the load of a 6 button kpl dimmer. Still worked 100% of the time. I then set the program up on a SL dimmer. Same thing, worked like a champ.

 

I don’t get it. I know in the past, a long time ago I had issues with this type of program so I used the fast off method. But now it seems to work in my system. Granted I haven’t tested it for days or weeks, nor have I tested it 50 or 100 times, but probably 20 or 30 times over a 15 minute period….with 100% success rate.

 

So that leads me to wonder – what is the difference between our systems?

 

I am running 3.1.9. The switches I have tested are within 2 years old. The kpl is v.36, the SL dimmer is v.38 and the Icon relay is v.39. 1500sq ft house with about 70 devices with 2412s plm.

 

Just had a thought, do you have the newer 2413 plm? I have heard they process a bit quicker than the 2412, could that be a possible reason why you are experiencing the bounce?

 

Tim

 

Edit: Have you tried changing the status from "Off" to "< 5%" or something similar?

[apostolakisl]

I have a 2412s modem that I bought 7/09. I have both icon dimmers and switchlinc dimmers running the program and all of them are the newer models with the beeper in them (less than 2 years old). The problem is happening with both the icons and the switchlincs. I really didn't have this issue prior to firmware 3.1.7.

 

The programs all say "off" and "switched off", not "less than 5%" and "switched off"

[IndyMike]

Hi Lou,

 

I tried your program and am sorry to report that I receive the same results as reported by Tim. I tried multiple ramp rates, on/off/fast on combination's - worked correctly every time (100+ attempts).

 

Is it possible that you're getting a "double bounce" via RF? I have only one accesspoint installed. Not sure whether "many" AP's could produce a bounce that the ISY would read as a second press on the switch.

 

If
       Status  'Basement / BSMT Fam Cans' is Off
   And Control 'Basement / BSMT Fam Cans' is switched Off
Then
       Set 'Basement / BSMT Fam Cans' 25%
Else
  - No Actions - (To add one, press 'Action')

[apostolakisl]

Hi Lou,

 

I tried your program and am sorry to report that I receive the same results as reported by Tim. I tried multiple ramp rates, on/off/fast on combination's - worked correctly every time (100+ attempts).

 

Is it possible that you're getting a "double bounce" via RF? I have only one accesspoint installed. Not sure whether "many" AP's could produce a bounce that the ISY would read as a second press on the switch.

 

If
       Status  'Basement / BSMT Fam Cans' is Off
   And Control 'Basement / BSMT Fam Cans' is switched Off
Then
       Set 'Basement / BSMT Fam Cans' 25%
Else
  - No Actions - (To add one, press 'Action')

 

 

Hmmm. That's something to think about. I do have maybe 4 rf doohickies plugged in around the house. I have had those all along however. It would be no big deal to unplug them and see what happens.

 

I do have 3 breaker boxes in the house and don't wan't to lose signal through the different panels and their phases.

[TJF1960]

Is it possible that you're getting a "double bounce" via RF? I have only one accesspoint installed. Not sure whether "many" AP's could produce a bounce that the ISY would read as a second press on the switch.

A second off, like an echo? That would explain the program running. Surely the event view would capture that right?