2.5 RC1: timer program loops forever, mostly locks up ISY

[evarsanyi]

The following program results in the Queries running continuously. There's barely enough time between cycles to get in and disable the program to stop the loop.

 

The 'queries' are in there because of the stupid bug in the Insteon switchlinc that prevents it from sending any status message if 2 switches are pressed at the same time (the original message and all retries overlap and nothing makes it). I figured the queries would update the state but it seems like the program starts over after the first query and keeps this up forever.

 

If

Status 'Mbath/Toilet1 - Fan' is On

And Status 'Mbath/Toilet2 - Vanity' is Off

And Status 'Mbath1 - Shower' is Off

And Status 'Mbath2 - Vanity' is Off

Then

Set 'Mbath/Toilet2 - Vanity' Query

Set 'Mbath1 - Shower' Query

Set 'Mbath2 - Vanity' Query

Wait 20 minutes

Set 'Mbath/Toilet1 - Fan' Off

Else

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

[Chris Jahn]

evarsanyi,

 

Here's a way of making that work ... if you want the Fan to turn off after 20 minutes if the SwitchLinc's are off, you can do that using two programs:

 

If 
    Status 'Mbath/Toilet1 - Fan' is On 
And Status 'Mbath/Toilet2 - Vanity' is Off 
And Status 'Mbath1 - Shower' is Off 
And Status 'Mbath2 - Vanity' is Off 
Then 
    Wait 20 minutes 
    Set 'Mbath/Toilet1 - Fan' Off 
Else 
    - No Actions - (To add one, press 'Action')

 

If 
    Status 'Mbath/Toilet1 - Fan' is On 
Then 
    Set 'Mbath/Toilet2 - Vanity' Query 
    Set 'Mbath1 - Shower' Query 
    Set 'Mbath2 - Vanity' Query 
Else 
   - No Actions - (To add one, press 'Action')

[Mark Sanctuary]

The ISY already tracks the device status. What is the second program for with the queries?

 

Are there devices that the ISY is not managing so one of the lights could be on without the ISY knowing?

 

If this is trying to cover poor communication issues wouldn’t it be better to fix the communication issues?

[evarsanyi]

There's nothing the ISY can do in this case. The lame implementation of the switchlinc has a bug (imo) in that when there's a collision sending a message it immediately retries rather than waiting a pseudo-random amount of time and retrying.

 

Thus, if you have 2 switches next to each other that must do something on the network (talk to the ISY or control another switchlink) and you press both paddles with the same hand at the same time the network traffic doesn't make it.

 

Smarthome's response to this was that 'no one could ever time their paddle presses that accurately'. Well, that's crap. There's debounce and an implicit synchronization with the cmd line zero crossing (16ms or so) -- its quite easy to hit both units on or off so that they end up trying to transmit on the same powerline cycle and failing (over and over again until they give up).

 

Unless the ISY went out and did a timed query of everything now and then (easy to implement using these programs/timers we have today even) it cannot know status reliably.

 

I'll try Chris's workaround, but IMO it shouldn't end up looping in any case -- the program should only restart if the result of the query was a change in state of a queried device.

[Chris Jahn]

I'll try Chris's workaround, but IMO it shouldn't end up looping in any case -- the program should only restart if the result of the query was a change in state of a queried device.

 

After posting my response, I realized that you are right, it is actually a bug. The 'query' should not be sending a status event if the status has not actually changed (and thus should not cause your program to loop).

 

This will be changed for the final release.

[Mark Sanctuary]

Just curious...even one handed why would you push two separate device buttons at the same time?

[evarsanyi]

Just curious...even one handed why would you push two separate device buttons at the same time?

 

In this spot one switch controls the lights on a bathroom vanity and the other switch controls the can lights in the rooms ceiling. When leaving the room we usually press the bottom of the paddles on the way out.

 

This happens frequently in another location at the head of a stairwell. One switch controls the lights in the stairwell ceiling and the other a chandelier at the top of the stairs. Same use case, someone's coming up stairs and wants to shut the lights off behind them, however in that case its worse because both switches are controllers for switchlincs elsewhere that drive the loads -- so you get to the top of the stairs and hit both switches to shut off the lights and nothing happens.

 

It happens to my wife all the time, its not just me being picky.

[aLf]

Just a thought, evarsanyi..

 

Rather than push two paddles. Set up ISY to, in the case of a fast off on paddle (1), switch (1 & 2) go OFF. This way ISY will do the timing. Works on my system!

 

aLf

[evarsanyi]

In most other locations where I need to control N lights in the same room I use a KPL or Controlinc -- now that events work well I will also use fast on/off in a couple of new places. Its a great new way to get extra control.

 

The WAF of having to learn to turn off 2 lights on 2 switches that used to work fine on the old Switchlinc X10 system (and before that mechanical Decora paddles) in a new way is *very very* low. It would be like trying to explain to someone you're loaning your car to how you reversed the gas and brake but its *much* better this way.

 

Other problem is turning them on, TW usually holds the 'on' of both paddles down until the lights get bright enough then lets them go (at different times). Yes, scenes could do this if you're willing to imagine what modes you want to have for the room -- when I've tried this no one can remember the events needed to get a given scene unless its a well labeled KPL (and even then the general populace seems to be happier just adjusting each light manually where there's only 2 of them).

[evarsanyi]

Another datapoint here: I recently discovered you have to wait many seconds to reliably make the ISY see the state of 2 co-located devices changing. Initially I thought I had to hit them pretty close together in time (16ms or so) but it turns out the switchlinc's I've got (rev 1.5 I think?) get confused if one starts transmitting any time the the other is already sending (so maybe seconds if retries are required).

 

I keep coming home to the bathroom fans running (turning them off is gated by the lights being off in the bathroom), checking the status on the ISY and finding it thinks both lights are still on.

 

Maybe I'll try to make a 5 minute poll that just checks the status of these two (and 2 others in a similar situation) over and over.

 

This insteon stuff is really turning into pretty much the same set of headaches as X10 had (flakey) -- which in no way reflects on UD's most excellent ISY.

[Mark Sanctuary]

When it’s dialed in I have to disagree. It works as good as if it was hardwired. In no way was my X10 setup close to my Insteon setup.

[evarsanyi]

I guess I've got more dialing to do. This setup replaced 60 or so of the older X10 smarthome xxxLincs and when I finally had that running well (with the right repeaters and filters) it was pretty reliable, if slow. I have all the same filters (though I shut off the X10 repeaters/bridge) as before. The filters should be wide enough to cover the slightly higher frequency that Insteon runs at (the are basically low pass filters tuned to pass 60hz well). Any suggestions on tweaking would be greatly appreciated.

 

and in isolation any single operation is *much* more reliable (and fast). Taken as a system however they have some bugs to iron out ... keypad lincs crashing, unreliable PLM firmware, random startup states after power failure, a total joke of a protocol attempt in the PLC, implementation issues around retransmit collisions, and bad QA on the actual switchlinc paddles (I've had about 20% of them go bad mechanically -- the newer replacements are all much better I think I just got a bad run as an early adopter). SHP is a great company and replaces all the ones that have issues instantly, I have no complaints there.

 

SHP did an amazing job making X10 "reliable" (though it was still a toy for early adopter types for the most part) so they had a high bar to make insteon as good or better. I'm sure they'll get it eventually. The reaction I got above is the kind of attitude that will cause them trouble crossing the chasm -- you're not going to get away with telling a luxury home buyer they can't push two switches too quickly after they spent $10K for an upgrade to Insteon in a new house. They'll kick the builder into the next county and that builder will think long and hard before offering Insteon in the next house (and he'll go back to selling hard wired lutron/etc). To the extent things like the ISY can wallpaper over the flakey implementation it will keep knowledgeable installers gainfully employed and the tech hopping (and hopefully get keep us all in new versions with fixes as time goes by).

 

My totally offtopic .02 anyway.

[Mark Sanctuary]

The crazy thing is I have ~30 Insteon devices, two Accesspoints, and no filters, and I am in a old house that has some new grounded romex and the rest is the two wire tar paper wrapped stuff. Not the best circumstances, but I am able to get it all working great.

 

Most of the quirkiness I have found has been me writing the programs wrong or the darn keypadlinc programming shortcomings, but that is eventually surpassable too.

 

I also tried all that stuff Smarthome tried to make and call a controller with their PLC. Now that stuff was most unreliable that is for sure.

 

If I was the reaction forgive me. Please hang in there buddy, it will come together.

[Michel Kohanim]

evarsanyi,

 

Would you be kind enough to do me a favor:

Can you please make sure the status of ISY gets updated when you physically turn on/off your SWLs? It's true that you cannot send immediate commands (they have to be around 500 m.s. apart otherwise sometimes the PLM does not hear them --> ISY does not hear them) but I believe the likelihood of being to accomplish that feat is low. So, there might be some other problems we are dealing with here namely: ISY's status is not updated when physically change the status of your switches.

 

Also, if I am not mistaken, you are using PLM v.52 (or below) some of which had a problem with X10 sensitivity/lockup.

 

With kind regards,

Michel

 

 

Another datapoint here: I recently discovered you have to wait many seconds to reliably make the ISY see the state of 2 co-located devices changing. Initially I thought I had to hit them pretty close together in time (16ms or so) but it turns out the switchlinc's I've got (rev 1.5 I think?) get confused if one starts transmitting any time the the other is already sending (so maybe seconds if retries are required).

 

I keep coming home to the bathroom fans running (turning them off is gated by the lights being off in the bathroom), checking the status on the ISY and finding it thinks both lights are still on.

 

Maybe I'll try to make a 5 minute poll that just checks the status of these two (and 2 others in a similar situation) over and over.

 

This insteon stuff is really turning into pretty much the same set of headaches as X10 had (flakey) -- which in no way reflects on UD's most excellent ISY.

[evarsanyi]

The state gets updated immediately in the applet display when I click either unit on/off w/o issue. My PLM is v52, though the only X10 involved is from an RF transmitter sending the initial trigger (L9 ON) the devices are all insteon.

 

The issue that this seems to be is one SHL and I went around about right after Insteon came out... I have 2 'slave' Switchlincs (no load) at the top of some stairs and its a popular activity to press both on or off with one hand at the same time. The switchlincs don't back off a 'random' interval when retransmitting, so if you get lucky enough to have both of them sync to the same 16ms powerline window (which is actually amazingly easy to do) they do their 5 retransmits on top of each other and the messages never get through. I'm fairly sure this is whats happening here except the loads are on the switches locally so they both go off, its just the ISY that doesn't hear about it.

 

Is there a better PLM version out that doesn't hang when doing lots of reprogramming/setup? If so I'll see if I can get SHP to swap this out...

[Michel Kohanim]

Hello again,

 

Ok! Now I understand ... thanks so very much for the clarification.

 

With kind regards,

Michel

 

The state gets updated immediately in the applet display when I click either unit on/off w/o issue. My PLM is v52, though the only X10 involved is from an RF transmitter sending the initial trigger (L9 ON) the devices are all insteon.

 

The issue that this seems to be is one SHL and I went around about right after Insteon came out... I have 2 'slave' Switchlincs (no load) at the top of some stairs and its a popular activity to press both on or off with one hand at the same time. The switchlincs don't back off a 'random' interval when retransmitting, so if you get lucky enough to have both of them sync to the same 16ms powerline window (which is actually amazingly easy to do) they do their 5 retransmits on top of each other and the messages never get through. I'm fairly sure this is whats happening here except the loads are on the switches locally so they both go off, its just the ISY that doesn't hear about it.

 

Is there a better PLM version out that doesn't hang when doing lots of reprogramming/setup? If so I'll see if I can get SHP to swap this out...