Can I Count Number of Times an ioLinc Relay is Triggered?

[SteveSBE]

Hi - 

I am triggering a Chime using an ioLinc relay to tell me which of 4 different activities happen (e.g. door opened = 1 ring, mail delivered = 2 rings, etc.). In the past I used a program that contained a Repeat statement to trigger the Chime a specific number of times. The Relay was set for Latching: Continuous. But sometimes the Chimes would not stop. I figured a momentary Relay would be better in this case and would stop the runaway chimes.  So I changed the Relay to use Momentary A  triggered by On.  Would there be a way for me to count each time the Relay was triggered (and the chime rings) if it would continue to run beyond a maximum number times?  I would like to have a fail safe program count the number of times the Relay was triggered so that I could explicitly stop the runaway triggering of the Relay (and resulting chimes).  I'm hoping that would not happen now that I moved to a Momentary A Relay setting...but just in case I'd like to not have the chime keep on going!

Thanks,

Steve

 

[Whitehambone]

I have not used variables for counting, but it seem like it should work great.  Just increment up the variable every time the IOLinc is triggered.  Then run a program to stop and reset everything when you get to the desired number.  I found this post that counts heat and cool cycles.

https://forum.universal-devices.com/topic/14719-t5800t5900-hvac-humidity-cycle-and-runtime-programs/

[SteveSBE]

Whitehambone -

Thanks. I tried using similar counters when the ioLinc was in Latching mode, but the problem continued. So, I went back to square one and re-read the information I could find on the ioLinc.

After reacquainting myself with the ioLinc and having it sink into my old brain I think that I figured out my issue. I believe my past problem was created by sending an On command to the ioLinc with the ioLinc in latching mode. This would close the relay and trigger the chime until I sent an Off to the ioLinc which would open the relay. It looks like the ioLinc would often not receive the Off commands I sent and therefore the relay remained closed after my program ended which left the relay closed and allowed the runaway chiming . In addition if figured out that my original programs had Wait and Repeat commends that sometimes shut down the original programs early so that the Off command was never sent to the ioLinc.

To remedy this issue, I set the ioLinc to be in Momentary A mode and broke the Wait and Repeat commands into separate programs. I think these changes will prevent the relay from staying closed and the resulting runaway chimes. It's worked for a day...we'll see.

My original question was asking for a way to detect if the relay was left closed causing runaway chiming. But I do not think it’s necessary now.

Thanks for your reply…

Steve

 

[larryllix]

1 hour ago, SteveSBE said:

Whitehambone -

Thanks. I tried using similar counters when the ioLinc was in Latching mode, but the problem continued. So, I went back to square one and re-read the information I could find on the ioLinc.

After reacquainting myself with the ioLinc and having it sink into my old brain I think that I figured out my issue. I believe my past problem was created by sending an On command to the ioLinc with the ioLinc in latching mode. This would close the relay and trigger the chime until I sent an Off to the ioLinc which would open the relay. It looks like the ioLinc would often not receive the Off commands I sent and therefore the relay remained closed after my program ended which left the relay closed and allowed the runaway chiming . In addition if figured out that my original programs had Wait and Repeat commends that sometimes shut down the original programs early so that the Off command was never sent to the ioLinc.

To remedy this issue, I set the ioLinc to be in Momentary A mode and broke the Wait and Repeat commands into separate programs. I think these changes will prevent the relay from staying closed and the resulting runaway chimes. It's worked for a day...we'll see.

My original question was asking for a way to detect if the relay was left closed causing runaway chiming. But I do not think it’s necessary now.

Thanks for your reply…

Steve

 

If the com path is not good in the first place you will have problems and the backup schemes will have problems also. There are some work-arounds for bad comms but solving the real problem is the best and doesn't clog up your Insteon signal paths with multiple retries. They can add up to several minutes of attempts to get through, and nothing else gets done.

[SteveSBE]

larryllix -

I forgot to mention that I also replace the original ioLinc and the new one responds much faster and so far has always been reliable. So I wonder if the old ioLinc was having internal problems. I've noticed that one additional ioLincs I have is having connection problems when I start the Admin Console. Is that more a sign of a comm problem or of a slowly dying ioLinc? 

 

[larryllix]

2 hours ago, SteveSBE said:

larryllix -

I forgot to mention that I also replace the original ioLinc and the new one responds much faster and so far has always been reliable. So I wonder if the old ioLinc was having internal problems. I've noticed that one additional ioLincs I have is having connection problems when I start the Admin Console. Is that more a sign of a comm problem or of a slowly dying ioLinc? 

 

That would be hard to say. My guess is a slight comm problem and the older i/oLinks may have a weaker signal? Most apps for these are GDO control/monitoring and I have found personally, and heard many times here, GDO produce a lot of electrical noise, even while sitting idle. I had some problems with my old AC motor unit that I never found, but with my newer Chamberlain DC backup up GDO, my Insteon comms were crippled and basically became useless. Two FilterLincs helped my whole system to speed up again.

[SteveSBE]

I did put FilterLincs on both of my Chamberlains (based on your comments in previous topics) so hopefully that will help too. Thanks.