Open/Close Sensor

[doctorjerry]

ISY 994i

v.4.2.18

 

I've added an Open/Close Sensor 2843-222.

It registers as a (2421) Trigger Linc v4.0 Is this right?

 

[oberkc]

Mine shows up as a (2843-222) Open/Close sensor v0.0

[stusviews]

Mine show up as TriggerLinc v.36, v.40 and v89.

[Teken]

That was the old name of the unit. Did you use auto or manually select it from the list?

 

 

Ideals are peaceful - History is violent

[Mike Ippolito]

Mine shows up as a (2843-222) Open/Close sensor v0.0

Oberkc - please remove the sensor and add it again CLOSER to the ISY.  If an Insteon device reports v0.0 instead of a real version number it has not added properly.

[LeeG]

doctorjerry

 

That is normal.  At v.40 there should be three nodes, Opened/Closed/Heartbeat 

[stusviews]

None of my TriggerLincs (#3) show a Heartbeat node. They all have Opened/Closed.

[LeeG]

It depends on the firmware level.   My two v.40 Open/Close Sensors have a Heartbeat node.  They also have an external Set button.

 

The v.28 firmware does not have a Heartbeat and the Set button is internal.  

[Teken]

A few of us have noted a discrepancy of how some devices either operate or function. Or some features being added or deprecated all mid stream with the same firmware level.

 

This was prominently seen in the Leak Sensor . . .

 

I am not surprised to read two people with similar firmware with two different experiences. Failing adding back the unit again using the latest ISY 4.2.30 firmware. If the unit still does not show the 3 nodes I would hard reset the device to ensure its OK from that perspective.

 

Once hard reset and added back using the auto feature if its still the same (only 2 nodes) then its likely your device was sold prior to the inclusion of the extra heart beat feature.

[oberkc]

Oberkc - please remove the sensor and add it again CLOSER to the ISY.  If an Insteon device reports v0.0 instead of a real version number it has not added properly.

I understand.  In fact, this is the first time that I specifically looked at the version number an noticed this. 

 

Full disclosure: I have two of these door sensors.  Multiple retries, resets, etc.  have resulted the same...version 0.0 for both sensors  Three nodes.  Status changes to ON and OFF in response to the door opening and closing.

 

Each attempt at linking required me to manually enter the address.  I am unsure if this is normal, but it works (if one ignores the v0.0 problem).  Given that the sensor is attached to the door, and that I did not want to remount, I tried different locations for access points.  None of this seemed to matter.

 

Functionally, both sensors appear to be working without fault.  I begin to wonder, however, if this could be a contributor to those ALL ON events.

[Teken]

I understand. In fact, this is the first time that I specifically looked at the version number an noticed this.

 

Full disclosure: I have two of these door sensors. Multiple retries, resets, etc. have resulted the same...version 0.0 for both sensors Three nodes. Status changes to ON and OFF in response to the door opening and closing.

 

Each attempt at linking required me to manually enter the address. I am unsure if this is normal, but it works (if one ignores the v0.0 problem). Given that the sensor is attached to the door, and that I did not want to remount, I tried different locations for access points. None of this seemed to matter.

 

Functionally, both sensors appear to be working without fault. I begin to wonder, however, if this could be a contributor to those ALL ON events.

Back in the day it was stated battery operated devices would not show a firmware version.

 

Years later some magic was added that polled the battery operated devices to reflect what firmware was present.

 

I had asked about this discrepancies over the years as HL2 clearly was able to provide the same information.

 

I have half a dozen sensors in this state and all operate just fine. I wouldn't worry too much about the v.00 because it wasn't an issue five years ago before the *Magic* was unleashed upon us all!

 

 

Ideals are peaceful - History is violent

[oberkc]

 I wouldn't worry too much about the v.00 because it wasn't an issue five years ago before the *Magic* was unleashed upon us all!

 

Up until yesterday, I was not worried (ignorance).  My only concern right now is what effect, if any, this may have on the ALL-ON events.  If none, I probably won't spend a lot of time trying to figure this out, as all seems to be working fine otherwise.  I can accept that this may be one of those devices that doesn't show version number (though these are relatively new for me...perhaps less than a year old installed).  It is comforting to know that I am not the only one with sensors in this condition, though.  Thanks.

 

The only reason I wonder about the relationship between these sensors and the ALL ON events is that one (but not all) of my events occurred simultaneously with this door sensor changing state.

[Teken]

Up until yesterday, I was not worried (ignorance).  My only concern right now is what effect, if any, this may have on the ALL-ON events.  If none, I probably won't spend a lot of time trying to figure this out, as all seems to be working fine otherwise.  I can accept that this may be one of those devices that doesn't show version number (though these are relatively new for me...perhaps less than a year old installed).  It is comforting to know that I am not the only one with sensors in this condition, though.  Thanks.

 

The only reason I wonder about the relationship between these sensors and the ALL ON events is that one (but not all) of my events occurred simultaneously with this door sensor changing state.

 

Well, from a logistic and technical stand point if this was the case. One would have expected tens of thousands of people to be seeing and impacted by this v.00 issue.

 

The only battery operated devices that have firmware number are new devices I installed last year. All of the other (5 years old) battery operated devices all show v.00.

 

To date I have not been impacted or seen this terrible ALL ON event that some have endured. My belief is there is some kind of conflict which is allowing Insteon commands to perform this action.

 

Going back into the (time machine) what I recall is the following in no specific order:

 

1. Some suggests this is a data collision - I don't subscribe to this theory.

 

2. Some suggests this is a timing issue - Some of this I accept but to a limited degree.

 

3. Some suggests the root cause is from battery operated devices due to the multiple retries - I don't subscribe to this theory.

 

4. Some suggests this is a programming issue - I agree poor programming from end users is one factor.

 

5. Some suggests this is X-10 being a possible culprit - I subscribe to this theory in a limited fashion.

 

6. Some suggests this is a power issue - I subscribe to this theory in a limited fashion.

 

7. Some suggests this is a noise issue - I subscribe to this theory in a limited fashion. 

 

8. Some suggests the ISY is mishandling unknown data incorrectly - I subscribe to this theory in a limited fashion.

 

9. Some suggests this is a ALL ON command issued - I subscribe to this theory as being 98% likely.

 

At the end of the day if nothing has changed and you enter the same exact door, window, etc. Why then does it not happen all the time?? I believe if all 8 of these possibilities are reviewed and action taken a person should be able to negate this problem all together.

 

Or at the very least make it happen at will . . .

 

To date, I have not read of one person providing evidence where someone across the 49th parallel can reproduce, none.  

[oberkc]

Well, from a logistic and technical stand point if this was the case. One would have expected tens of thousands of people to be seeing and impacted by this v.00 issue.

 

The only battery operated devices that have firmware number are new devices I installed last year. All of the other (5 years old) battery operated devices all show v.00.

 

To date I have not been impacted or seen this terrible ALL ON event that some have endured. My belief is there is some kind of conflict which is allowing Insteon commands to perform this action.

 

Yes, you make good points.  As to my own experience, I never had ANY all-on events until recently.  I never had any door sensors, until recently.  Yes, this could very well be a coincidence. In my most recent event, it appeared that Keypads were not affected.  I don't know what one can conclude from that.

 

I suspect if anyone knew with certainty what is causing it, it would be fixed by now.

[Michel Kohanim]

Hello all,

 

Are you using Link Management | Link Sensor? Please note that I2CS devices do respond with IDREQ so if you use Auto Discover and enter the address, then you should also get the firmware version.

 

oberkc, I am pretty confident that this has not much to do with All On issue.

 

With kind regards,

Michel

[oberkc]

Hello all,Are you using Link Management | Link Sensor? Please note that I2CS devices do respond with IDREQ so if you use Auto Discover and enter the address, then you should also get the firmware version.oberkc, I am pretty confident that this has not much to do with All On issue.With kind regards,Michel

Indeed, I am using link management>>>link sensor option from the dropdown menus across the top. I do not recall an "autodiscover" option, and I have always had to manually input the address, but I will check again soon, trying to pay a little more attention.

[LeeG]

oberkc

 

Selecting the specific device type through the Link Management options invokes "New INSTEON Device" with the Device Type pre selected.  If Link Management | New INSTEON Device is selected the same New INSTEON Device popup is displayed with the Device Type set to Auto Discover.  Most devices no longer need a specific Device Type  specified.   Auto Discover uses the Device Type and device firmware information provided by the device.  Auto Discover normally displays the device firmware in the device definition.

 

The TriggerLinc firmware level v28 is displayed because TriggerLinc added using Auto Discover

[oberkc]

oberkc

 

Selecting the specific device type through the Link Management options invokes "New INSTEON Device" with the Device Type pre selected.  If Link Management | New INSTEON Device is selected the same New INSTEON Device popup is displayed with the Device Type set to Auto Discover.  Most devices no longer need a specific Device Type  specified.   Auto Discover uses the Device Type and device firmware information provided by the device.  Auto Discover normally displays the device firmware in the device definition.

 

The TriggerLinc firmware level v28 is displayed because TriggerLinc added using Auto Discover

I will try your approach. I have been using the "link sensor" method as asked by Michel. Perhaps this is why I have not noticed the "autodiscover" option? Interestingly, I recall the open/close sensor being a specific sensor choice when my approach was taken, suggesting (in my mind) that this is a viable approach.

 

I also recall a different method for versions prior to 1.9. Perhaps, also, I took the wrong route here.

 

Will try again and report back.

[LeeG]

I do not see your approach not being viable (except maybe for the newest Mini Remote.  Just that Auto Discover provides more information and may be required for the latest Mini Remote where the ISY must know the Mini Remote firmware so the correct Insteon commands are used. 

[oberkc]

I do not see your approach not being viable (except maybe for the newest Mini Remote.  Just that Auto Discover provides more information and may be required for the latest Mini Remote where the ISY must know the Mini Remote firmware so the correct Insteon commands are used.

 

Perhaps "not viable" is a little too strong, but mike ippolito suggested that having v0.0 (which is the consistent result when my approach is taken) is an indication of a device "not added properly". If this is true, this sounds to me not to be viable. At this point, however, your point is taken and I suspect I am arguing semantics with myself.

[Teken]

Perhaps "not viable" is a little too strong, but mike ippolito suggested that having v0.0 (which is the consistent result when my approach is taken) is an indication of a device "not added properly". If this is true, this sounds to me not to be viable. At this point, however, your point is taken and I suspect I am arguing semantics with myself.

 

I believe moving forward since the *Magic* was unleashed all new Insteon devices should use the (Auto Discover) feature. This ensures all attributes are seen and enabled with in the ISY Series Controller.

 

The only reason I have resisted from re-adding the old battery operated devices is because there are too many programs tied to them. Next, sometimes there are new features in the option list that simply do not work.

 

I gather this is due to the fact someone can have a device that has (listed) firmware that simply isn't fully supported in the device itself.

 

Even if the ISY says its the correct version the actual device firmware doesn't support those new features. This was seen in the Leak Sensor where some had the exact hardware / firmware.

 

Yet theirs did not return from a wet to dry state as others did. I also saw this with the MS where HL2 was able to push updates upon motion detection. Whereas the ISY was still unable to do the same so I don't know what the distinction could be for that scenario. 

[oberkc]

I will try your approach. I have been using the "link sensor" method as asked by Michel. Perhaps this is why I have not noticed the "autodiscover" option? Interestingly, I recall the open/close sensor being a specific sensor choice when my approach was taken, suggesting (in my mind) that this is a viable approach.

 

Well, I tried a couple of different approaches.  After a factory reset of the sensor, and removing it from the ISY, I chose link management>>>New Insteon Device.  Set to autodiscover, nothing happened.

 

I then tried link management>>>:Link a sensor>>>Open/Close sensor.  I entered the address, found the autodiscover option, and chose it.  The link process failed. 

 

I then went back to link management>>>:Link a sensor>>>Open/Close sensor and added the device, keeping default settings.  Link worked, but I am back to v0.0.

 

Teken...throughout this process, I never had to rebuild any programs.  The one program I had with this sensor as a condition came back as good as before, without any intervention on my part.

[Teken]

That's not very encouraging to say the least. But am not very surprised by the results either.

 

 

Ideals are peaceful - History is violent

[LeeG]

"Well, I tried a couple of different approaches.  After a factory reset of the sensor, and removing it from the ISY, I chose link management>>>New Insteon Device.  Set to autodiscover, nothing happened."

 

Of course the option is yours but I would like to see an Event Trace at LEVEL 3.  Using New INSTEON Device,  enter the sensor Insteon address, Name of your choice, and Auto Discover.  Of course the sensor must be put into linking mode with Set button before clicking Ok on New Insteon Device.  I certainly understand if you are not interested. 

 

Doing a factory reset before deleting device would cause errors during the delete because the link records were missing.  That might have prevented the delete from completing.

[oberkc]

"Well, I tried a couple of different approaches.  After a factory reset of the sensor, and removing it from the ISY, I chose link management>>>New Insteon Device.  Set to autodiscover, nothing happened."

 

Of course the option is yours but I would like to see an Event Trace at LEVEL 3.  Using New INSTEON Device,  enter the sensor Insteon address, Name of your choice, and Auto Discover.  Of course the sensor must be put into linking mode with Set button before clicking Ok on New Insteon Device.  I certainly understand if you are not interested. 

 

Doing a factory reset before deleting device would cause errors during the delete because the link records were missing.  That might have prevented the delete from completing.

I am certainly interested if further experimentation, but may not have the opportunity soon.

 

Yes, I reset the device before removing from the ISY. I saw no errors displayed, but the process appeared to be performing some write action without the sensor being in linking mode. Perhaps this contributes to the mystery.

 

Yes, the sensor was in linking mode when initiating new insteon device.

 

Next chance I get, I will try a few more options and report back.