Bug Report

[apostolakisl]

After migrating to IoP, the following program style no longer works.  It is supposed to be true only when you click the off paddle when the light is already off.  But it is running true when you turn the light off from on.  Curiously, does not run true when you click off the second time from 25%.

 

Bath Night Lt. Can - [ID 0076][Parent 0083]

If
        'Master Bedroom / Master-Bath Cans L' Status is Off
    And 'Master Bedroom / Master-Bath Cans L' is switched Off
    And Program 'Dark Outside' is True
 
Then
        Set 'Master Bedroom / Master-Bath Cans L' On 25%
 
Else
   - No Actions - (To add one, press 'Action')
 

 

[vbPhil]

I've never used that style before but it's interesting. I gave it a try and it is working for me in IoP.

Quote

Debug - [ID 0005][Parent 0001]

If
        'Outside Front / FrontDoor' Status is Off
    And 'Outside Front / FrontDoor' is switched Off
 
Then
        Set 'Outside Front / FrontDoor' On 25%
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Edited April 25, 2022 by vbphil
typo

[bhihifi]

@apostolakisl Try re-sequencing the “if” clauses so the switched off is the first condition: does behavior change? I predict that it will not. I believe the clauses are evaluated sequentially but the status changes before your switch is detected so the first condition goes true even when switching off from on.

Polisy executes faster than a standalone ISY so you may have a timing issue for your first two conditions.

What you want is to know if the switch was off when switched off, but the status may update too quickly to use it directly.

Perhaps a state variable could help here. It would change when switched off or on, but only after a slight delay.

Edited April 24, 2022 by bhihifi
Added state variable concept

[apostolakisl]

14 minutes ago, bhihifi said:

@apostolakisl Try re-sequencing the “if” clauses so the switched off is the first condition: does behavior change?

 

I tried that last night, no dice.  This has happened with past firmware updates which they have corrected.

[apostolakisl]

1 hour ago, vbphil said:

I've never used that style before but it's interesting. I gave it a try and itis working in IoP.

 

Curious.  How "on" was the light.  I have found it works correctly when the light starts off at 25%.  But when it is closer to 100%, it does not.

It is one of my favorite programs.  At night, you might get up to go to the bathroom.  Instead of pushing and holding to get the light to just turn on a bit, you just click "off" and you get a nice dim night light.  

Also the WAF on this program is very high.  (wife acceptance factor).  

[bhihifi]

@apostolakisl Sorry your reply crossed my edit. You might eliminate timing issues with a state variable.

[apostolakisl]

Just now, bhihifi said:

@apostolakisl Sorry your reply crossed my edit. You might eliminate timing issues with a state variable.

I could, but I have a bunch of these.  This problem has happened with other firmware versions and UD has always been able to fix it.

[vbPhil]

1 minute ago, apostolakisl said:

Curious.  How "on" was the light.  I have found it works correctly when the light starts off at 25%.  But when it is closer to 100%, it does not.

It is one of my favorite programs.  At night, you might get up to go to the bathroom.  Instead of pushing and holding to get the light to just turn on a bit, you just click "off" and you get a nice dim night light.  

Also the WAF on this program is very high.  (wife acceptance factor).  

I have our bathroom light’s On Level set to 25%. So it comes on dim all the time. If you want full brightness you double tap the switch. Been working this way for years. Seems to fit our logic okay. We have several other lights set same way. 

[bhihifi]

@apostolakisl I understand your predicament. Being new to this, I take the belt and suspenders approach.

My extra caution is due to prior experience in writing real-time embedded system software. Anything that relies on timing will screw things up.

If the status condition is supposed to indicate the recent past then your view of this difference with IoP as a bug makes sense.

Curious to learn what UDI will say.

 

 

[apostolakisl]

12 minutes ago, vbphil said:

I have our bathroom light’s On Level set to 25%. So it comes on dim all the time. If you want full brightness you double tap the switch. Been working this way for years. Seems to fit our logic okay. We have several other lights set same way. 

That works, but I'm not a huge fan of the Insteon double click.  Often times you don't get the click rate right, especially if you are kind of moving quickly or have stuff in your hands.

[MrBill]

I suspect this is because Polisy is much faster than 994.  It's able to update "status" more quickly than 994.

[apostolakisl]

7 hours ago, MrBill said:

I suspect this is because Polisy is much faster than 994.  It's able to update "status" more quickly than 994.

Possible.  I don't recall that when it happened with previous firmware that it only happened from higher starting levels.  I think at those times the only way to get the light off was to do a fast off.

[apostolakisl]

I looked into this further.  The program is working correctly.  But IoP is not registering the status of the light correctly.  I have tested many switches and the are all having issues.  For example, my bedroom closet.  ISY seems to always register an "off" command as well as dim and and dim down.  But never recognizes on "on".  So the light is off, I turn it on, but IoP still says it is off.  So when I shut if off, the program incorrectly triggers.  Something like this or similar is true for just about every switch in my house I have tested.  This problem started after IoP was installed.  I had virtually perfect correlation between ISY status and actual status prior to the switch and it has been that way for years through many ISY firmware updates.

[larryllix]

This can be a problem when we play the anomalies of a system. Then the system keeps changing and we wonder why our ingenious quirks stop working. Many have argued over the years here, ISY's engine doesn't always process things n the order that seems apparent, or by order of the code lines.

[apostolakisl]

2 minutes ago, larryllix said:

This can be a problem when we play the anomalies of a system. Then the system keeps changing and we wonder why our ingenious quirks stop working. Many have argued over the years here, ISY's engine doesn't always process things n the order that seems apparent, or by order of the code lines.

This is an issue not of ISY program processing but rather ISY (IoP) acknowledging the correct state of the device.  Based on the displayed status of devices, IoP programs are behaving correctly.  As it is, this is a much bigger problem than that program type.  It is just the very first program type I found to have the issue and I jumped to the wrong conclusion about the cause based on the fact that I have seen that style go wonky twice before over the past 10 years or so.

I tried doing a restore on that one device, but no dice, same thing.  IoP still not showing an "on" command.  But reports other commands.  Dim up, dim down, off, etc.  This is not a comm issue.  I have tested about a dozen devices now and all have issues.  There were zero issues prior to the IoP update.  My comm has been rock solid for years.  I made no changes to the PLM or devices, just switched serial cables and plugged into IoP instead of 994i.  Perhaps a "restore plm" will help, but I don't know why it would.

[larryllix]

16 minutes ago, apostolakisl said:

This is an issue not of ISY program processing but rather ISY (IoP) acknowledging the correct state of the device.  Based on the displayed status of devices, IoP programs are behaving correctly.  As it is, this is a much bigger problem than that program type.  It is just the very first program type I found to have the issue and I jumped to the wrong conclusion about the cause based on the fact that I have seen that style go wonky twice before over the past 10 years or so.

I tried doing a restore on that one device, but no dice, same thing.  IoP still not showing an "on" command.  But reports other commands.  Dim up, dim down, off, etc.  This is not a comm issue.  I have tested about a dozen devices now and all have issues.  There were zero issues prior to the IoP update.  My comm has been rock solid for years.  I made no changes to the PLM or devices, just switched serial cables and plugged into IoP instead of 994i.  Perhaps a "restore plm" will help, but I don't know why it would.

Yeah, a single missing link or botched link could destroy one status or trigger signal continuity.

Since Insteon sends separate signals for toggle position as well as dimmer status, it is quite and very  possible.

[apostolakisl]

4 minutes ago, larryllix said:

Yeah, a single missing link or botched link could destroy one status or trigger signal continuity.

Since Insteon sends separate signals for toggle position as well as dimmer status, it is quite and very  possible.

Don't see how this could be a link issue.  Links are between Insteon devices.  Nothing was changed between Insteon devices.  The PLM is just another Insteon device.  In addition, I have seen no Insteon to Insteon comm failures.  All scenes are working as expected at all switches.

I also tried doing a query of the one representative switch.  I clicked "on", the light turned on, but ISY control panel still shows off.  I do a query, and it still shows off with no errors reported on the query.  I then click and hold a dim up on the switch that is already 100%, and now IoP shows "100%".   Something weird here.

[larryllix]

16 minutes ago, apostolakisl said:

Don't see how this could be a link issue.  Links are between Insteon devices.  Nothing was changed between Insteon devices.  The PLM is just another Insteon device.  In addition, I have seen no Insteon to Insteon comm failures.  All scenes are working as expected at all switches.

I also tried doing a query of the one representative switch.  I clicked "on", the light turned on, but ISY control panel still shows off.  I do a query, and it still shows off with no errors reported on the query.  I then click and hold a dim up on the switch that is already 100%, and now IoP shows "100%".   Something weird here.

Strange. I have been finding my main SwitchLinc switch doesn't seem to produce a dim signal if it already off. I was sure it always did in the past as I use to signal to turn on my automatic dimming programs/scenes. When the Switchlinc is partially on it works 100% but when the Switchlinc is already off it misses sometimes. I am still using my old ISY994 also so it is not a IoP thing. I had a lot of other weird things take place on mine for the few months I tested it but after some other serious problems I went back to my ISY for now.

Previously I also used my ensuite Switchlinc dimmer to trap a fast off signal to activate RGBW strip lights along the floor behind the tub etc.. Each double tap down, while off, would trigger a colour change if done within 5 seconds of the last d.Tap. Waiting for longer than 5 seconds would cancel the sequence and turn the RGBW LED strip off. It never had problems producing the fast Off signal while off. Something does seem like things have changed but it always seemed to point to the Switchlincs. Not likely possible. Maybe some core logic in ISY/IoP has changed a while back??

[MrBill]

11 hours ago, apostolakisl said:

I looked into this further.  The program is working correctly.  But IoP is not registering the status of the light correctly.  I have tested many switches and the are all having issues.  For example, my bedroom closet.  ISY seems to always register an "off" command as well as dim and and dim down.  But never recognizes on "on".  So the light is off, I turn it on, but IoP still says it is off.  So when I shut if off, the program incorrectly triggers.  Something like this or similar is true for just about every switch in my house I have tested.  This problem started after IoP was installed.  I had virtually perfect correlation between ISY status and actual status prior to the switch and it has been that way for years through many ISY firmware updates.

Now this sounds like an easily reproducible bug.  One that you should open a ticket to make certain it gets attention.

Edited April 25, 2022 by MrBill

[apostolakisl]

I have narrowed the problem down to IoP processing error.  I watch event viewer, click "on" paddle, I get a "DON" along with the correct Insteon address, but no change to lights status in the admin console.

@Michel Kohanim

EDIT:  Here is a query result.  It does register 100% after a query.

Edited April 25, 2022 by apostolakisl

[stillwater]

I am confused.  The original program that wasn't working was looking for  DOF command and now you are focused on DON not translating into proper state in IoP?   Are you thinking these are the same problem (i.e. in the program the IoP thought the load was ON when it was OFF?) 

 

[apostolakisl]

16 minutes ago, stillwater said:

I am confused.  The original program that wasn't working was looking for  DOF command and now you are focused on DON not translating into proper state in IoP?   Are you thinking these are the same problem (i.e. in the program the IoP thought the load was ON when it was OFF?) 

 

The program is working correctly based on its understanding of the state of the device.  The problem is the program is being told the incorrect state of the device.  The program thinks the light is off even though it is on.  The reason it thinks it is off is because IoP seems to be ignoring "DON" communications.  It is receiving the DON, but it is not updating the device state.

EDIT: And this is the case for every device I have tested so far.

Edited April 25, 2022 by apostolakisl

[MrBill]

13 minutes ago, stillwater said:

I am confused.  The original program that wasn't working was looking for  DOF command and now you are focused on DON not translating into proper state in IoP?   Are you thinking these are the same problem (i.e. in the program the IoP thought the load was ON when it was OFF?) 

 

The program is checking two things Status and looking for DOF.  In DON never changes the status to On the compound statement won't be evaluated.

I gotta hand it to @apostolakisl this is a cool programing technique.... I haven't moved over to Polisy yet but I've already used it..

[apostolakisl]

I can't believe I'm the only one with this issue.  I have rebooted polisy and that didn't fix it.

If a switch is the responder to a scene and you turn the scene on, the status properly updates.

But the below program runs correctly.

tes - [ID 008E][Parent 0093]

tes - [ID 008E][Parent 0093]

If
        'Kitchen / Kitchen Intercom-Island L' is switched On
 
Then
        Wait  3 seconds
        Set 'Kitchen Puck S' On
 
Else
        Set 'Kitchen Puck S' Off
 

So ISY does recognizes that it is receiving the on command from the switch, it just isn't updating the status.

[Michel Kohanim]

Hello everyone, we'll take a look.

With kind regards,
Michel