Insteon Feature Options Support (POLL)

[Teken]

The forum members were asked to create a POLL where by it would gauge the demand for UDI to set aside development time to ensure all devices which they have documentation can include all the firmware options (features) a product may have.

 

For those unfamiliar with what has happen in the past, or the present, this is essentially where we are. Insteon by default makes hardware that has firmware that include options or features which can be selected only via a software controller such as the ISY / HL2.

 

NOTE: Not all models, years, firmware, support the same feature sets or options. As historically Smartlabs has either added, removed, or modified native features or options with out notice.

 

Below are some of the most common Insteon devices which have options or feature made available in House Linc 2 Software. But, these same feature options are not present in the current ISY Series Controller. 

 

Your task is to review these options and compare them to what the HL2 software provides and the ISY Series Controller. Should you feel that UDI should support all feature options please do select the appropriate POLL option.

 

If the POLL question does not reflect your thoughts or you need to add some remarks please do so below.

 

UDI is a small, but fast growing company who's primary goal is to provide the greatest performance, reliability, and value to their customers. As such, development is spent on core features that the majority will find value in, and can use.

 

This means only so much time, effort, and development can be placed on doing so. So its a balance of spending time on this or other endeavors which may reap more rewards to the greater masses.

 

My personal thoughts are every Insteon device should be fully supported in all manner. If a feature option is unknown, the developer should reach out to Smartlabs to inquire how to best implement and deploy said features. 

 

Supporting all feature sets in the big picture ensures the full capability of the unit can be harnessed and used in any specific environment. This leads to greater customer satisfaction, adoption of Insteon products, and ultimately sells more hardware for the vendor.

 

I hope every ISY owner will see the business case in selecting the appropriate POLL option and let their voice be heard.

 

In closing, I and every other ISY owner would like to thank the UDI Engineering team for taking the time and effort to consider the feed back from the community.

 

Regards

 

NOTE: There was no method to provide more than three options to the POLL. This is why I am providing screen shots of the various Insteon devices I have for the members to review and compare. Please feel free to upload your own device(s) not listed as I do not have lots of new 2013 / 2015 units for direct comparisons.  

 

 

LAMP LINC DIMMER 2457D2

 

These are the available options with in the current ISY firmware 4.2.22 RC2. These 2457D2 Lamp Lincs were just purchased during the X-MAS 2014 sale. Hardware information is noted as R3.6 produced in 3914, ISY indicates the firmware as v.43. 

 

 

These are the available options as indicated by the last House Linc 2 Software release. The available options are beep test, enable / disable LED, LED on Insteon traffic, Program lock.

 

 

 

MICRO DIMMER 2442-222

 

These are the available options with in the current ISY firmware 4.2.22 RC2. These Micro Dimmer 2442-222 were just purchased during the X-MAS 2014 sale. Hardware information is noted as R1.05 produced in 3314. Extra features noted in the ISY is Resume Dim, and the default option is to turn the LED On / Off. 

 

 

These are the available options as indicated by the last House Linc 2 Software release. The main difference in HL2 is having the ability to actually set the LED brightness which is probably more beneficial for most. This would allow custom LED brightness which suites the end users needs. Probably the most important option is the blink on *Error* this would assist those in trouble shooting a network.

 

This feature will blink green if the responder Acks the message. It will blink red if one or more responders do not Ack the message.

 

 

Motion Sensor: Editing

 

 

Still gathering data please ignore. Trying to add in a new MS sensor for comparions.

 

[larryllix]

I don't understand the third question.  "Should the 2457D2 options be made available?"

 

I have a dozen or so of these units and I am not aware of any options that are not on the device's page? Has something been removed or added recently? I need a better explanation of the objective of this exercise to know how to opine.

 

I think all the options should be available functional and supported for the 2441ZTH thermostats but that doesn't seem to be addressed in the specific polls.

[stusviews]

larryflix, the 2457D2 options that are not available to the ISY include: Beep on Button Press, Disable Local Programming, Blink on Traffic and Error Blink.

[Teken]

I have just updated the primary thread as it was under review by UDI. I have updated it to include the options and features when comparing the two controllers. I understand there are new KPL's with options which are not available via the ISY. Should anyone have these models please do provide a screen capture from the ISY.

 

Since HL2 has not been updated for more than a year some or all features and options may not be listed or made available. If there are any other Insteon products which have options listed in the e-doc but are not available via the Admin UI Console please do lend your voice here so it can be tracked.

 

I thank you all in advance for taking the time to vote and make your voice heard. 

 

NOTE: When providing information about a device please include the hardware revision, production date, and what the ISY indicates as the firmware. Please be aware also sometimes a device simply needs to be removed from the ISY and added back before a feature or option is visible & available for use. 

[stusviews]

Insteon thermostat 2441TH, v1.6, 3013, ISY & HouseLinc report v.0D

 

Available HouseLinc Options:

[Michel Kohanim]

Teken,

 

Thank you. The questions are a little skewed. I.e no one disputes these features might be there. The main poll should have been:

How much resources should UDI expend in reverse engineering features for which there are no documents given that the outcome does not guarantee that the same feature will work across the same model but with different firmware versions.

 

For instance, should we postpone 5.0, multi channel Z-Wave, and about 110 more feature requests to implement these even though the outcome is not guaranteed?

 

With kind regards,

Michel

[Teken]

Teken,

 

Thank you. The questions are a little skewed. I.e no one disputes these features might be there. The main poll should have been:

How much resources should UDI expend in reverse engineering features for which there are no documents given that the outcome does not guarantee that the same feature will work across the same model but with different firmware versions.

 

For instance, should we postpone 5.0, multi channel Z-Wave, and about 110 more feature requests to implement these even though the outcome is not guaranteed?

 

With kind regards,

Michel

Hello Michel,

 

As stated above, the benefit should be focused on the majority when changes to the ISY firmware impacts those on a global scale.

 

Such as the development of 5.XX firmware.

 

Having said this, it's important to note this poll was created solely to track and show direct comparisons to the forum members as you requested in a related thread.

 

With factual data points presented via screen captures there would be no ambiguity as to what is present, available, and possible.

 

I think it's fair to say the bulk of the customers have come to expect quality from UDI. Which has been field proven year after year for me and thousands of others.

 

If something was missed during the initial deployment of a driver for a device. No one is going to throw stones at the team. Once this information has been made aware it's the expectation that a solution be provided.

 

As you clearly stated there are approx 100 user requested features. Many of them will no doubt bring more power, capability, and value to the ISY Series Controller.

 

This is why it is in my mind the only electronic investment that has continued to pay for itself year after year.

 

Having said that, potential (customer requested) features should never compromise what is considered a core (basic) and native features of the product.

 

Many of these core features have been provided in various Insteon devices and the information is known. Whether it be beep, LED brightness, program lock, etc.

 

These features are clearly listed in the e-doc for the lamp linc dimmer in the full users manual. These features can only be used via a software solution such as the ISY / HL2.

 

These features and options were not hidden or unknown they were simply not included as part of the driver release.

 

As this thread develops I am sure many more devices will be listed with features not available via the ISY. This was my first pass at providing factual information for all to see and consider.

 

The POLL was not intended to be lop sided but rather present the facts as they are. If the provided information bolsters one side over the other.

 

Those are simply the facts as they are. ️

 

It's safe to say, I, along with tens of thousands of others have supported the ISY because the core features are solid and robust. I am simply asking the team to review the existing drivers and craft them in such a way that supports the Insteon product as it was intended.

 

Your kind consideration and endless development is greatly appreciated in this regard.

 

 

 

 

 

Sent from my iPhone using Tapatalk

[bpwwer]

While I do think that UDI should have a goal to support all features of all Insteon products, I also understand that there are limited resources and priorities that will impact this.  And that unfortunately makes the data collected by this poll less useful than it could be.

 

Somehow priorities need to be accounted for since decisions about what features can be supported in a given time are rarely black and white.  For example, if the choice was between fully supporting all features of the 2457D2 and supporting basic functionality of a new Insteon device, I'd vote for adding the new device every time.

 

So if there were no resource constraints, then yes, please support all options of all devices, past, present, and future.  But knowing that there are resource constraints, I think leaving out support for things like beep, etc. is acceptable.

[Teken]

While I do think that UDI should have a goal to support all features of all Insteon products, I also understand that there are limited resources and priorities that will impact this.  And that unfortunately makes the data collected by this poll less useful than it could be.

 

Somehow priorities need to be accounted for since decisions about what features can be supported in a given time are rarely black and white.  For example, if the choice was between fully supporting all features of the 2457D2 and supporting basic functionality of a new Insteon device, I'd vote for adding the new device every time.

 

So if there were no resource constraints, then yes, please support all options of all devices, past, present, and future.  But knowing that there are resource constraints, I think leaving out support for things like beep, etc. is acceptable.

 

That is a pretty fair assessment and balanced approach for sure. I would like to counter that view with the simple fact nobody including myself would fault UDI in taking longer to support a newer product.

 

Rushing out to support a new product for the sake of doing so is not the hall mark of quality. This historically causes the vendor(s) to redo the same work twice or more.

 

The reality is, nobody expects UDI to be all knowing when speaking about how Smartlabs is going to deploy a product. But, the reality is any vendor who is making software / hardware for Insteon have paths to follow to obtain the most relevant information and specification for said product.

 

This is why vendors such as UDI are participants in the developer program and sign NDA documents.

 

As others have stated in the past sometimes this is like trying to hit a moving target. This is nothing new to UDI and the team as a whole. They have in the past and currently have great lines of communications with Smartlabs.

 

It is simply reaching out to those resources and to apply what is relevant and germain to the product at hand. 

[Xathros]

The following was my original reply to this that didn't post when the poll disappeared on Friday afternoon:

 

Had to look up the 2457D2 (Lamplinc Dimmer 2Pin). Not sure what features it has that the ISY does not support. (Fixed in the latest version of the Poll - Thanks Teken!)

 

 

Of course it would be awesome if the ISY supported all features of every Insteon device. That said, I'm not sure I would want to draw resources away from things like V5.x development to make that happen.

 

Instead, maybe a smaller scale side project to add the ability to send raw commands to any linked device that we (the user community) can use to enable/disable features that are not directly supported (Bink on RX/TX, Beep On/Off, Program Lock etc). This can be documented as an advanced feature with a warning that you my corrupt your device and require a factory reset to recover if your not careful. Possibly make this an add on module like Pro or Networking - but less expensive than those .

 

Now that Smartlabs seems to be offering up developer data to the masses, we can work out for ourselves the commands to be sent and document same here on the forums for other less advanced or adventurous folks.

 

This way, UDI can focus on core feature support and continue with their normal development process and not have to dedicate excessive resources to re-working support for all of the older devices or directly supporting the less needed features on newer devices.

 

I have posted this to the UDI IdeaScale site as well at: http://udi.ideascale.com/a/dtd/Insteon-Options-Module/79334-32911  Please add your vote there if you fell this is a good idea.

 

 

-Xathros

[kck]

Is there possible a middle ground where UDI could implement once an escape mechanism that would allow the creation of extra manual commands to be associated with a device type?  If I understand the missing capabilities they don't seem to be ones that require the ISY unit to retain state information but rather are more of the nature of being able to issue specific Insteon commands and receive responses.  If there were an "expert" mode extension capability then it would seem to enable the much larger community of UDI users to create libraries of added functions that would need to be explicitly loaded and used "at your own risk".  However, it would avoid an endless demand on UDI to support corner case commands which while very useful/important to a subset of their users don't make the cut line when prioritized against resources in the larger context.  Such an extension mechanism is pretty common in most programmable environments.  It just seems that as things stand UDI is boxing themselves into a pretty unsustainable corner by putting themselves in the blocking role for any new capability that they can't reasonably get to for resource reasons and that tapping the larger community as a way of amplifying their capabilities for low demand or really new capabilities would benefit both them and their users for the cost of a one time investment.

[Teken]

Is there possible a middle ground where UDI could implement once an escape mechanism that would allow the creation of extra manual commands to be associated with a device type?  If I understand the missing capabilities they don't seem to be ones that require the ISY unit to retain state information but rather are more of the nature of being able to issue specific Insteon commands and receive responses.  If there were an "expert" mode extension capability then it would seem to enable the much larger community of UDI users to create libraries of added functions that would need to be explicitly loaded and used "at your own risk".  However, it would avoid an endless demand on UDI to support corner case commands which while very useful/important to a subset of their users don't make the cut line when prioritized against resources in the larger context.  Such an extension mechanism is pretty common in most programmable environments.  It just seems that as things stand UDI is boxing themselves into a pretty unsustainable corner by putting themselves in the blocking role for any new capability that they can't reasonably get to for resource reasons and that tapping the larger community as a way of amplifying their capabilities for low demand or really new capabilities would benefit both them and their users for the cost of a one time investment.

 

I think the over all idea you present is sound. But, there should never be *At your own risk* the documents which support these devices are clear, concise, and known. A software solution should never make, or leave a device in a unknown state that would be against the intended design of the product.

 

To be fair to both sides, there have been times where little to no information is provided and UDI has literally had to plug away until they saw the correct responses from a device under test. Its safe to say most of us know UDI has taken some products which were mediocre in its default state and expanded its use case.

 

I would like to be very clear on these points, these are not hidden features or unknown to those who develop for the Insteon product line.

 

There are many third party hardware / software vendors such as Home Seer, Vera, Revolv, and many others who have successfully included these core feature sets into their application or hardware solution. 

[kck]

Ah - you took my "at your own risk" comment a bit differently than I meant it.  I agree with you regarding the info availability.  What I meant was just that if UDI provided an "add-in" mechanism whereby the community could make additional functions available, their responsibility would be that the add-in mechanism itself worked rather than some particular add-in from a member/user here worked.  This is an active enough community that it could support reviewing, bug-reporting, etc. for user contributed add-ins that would provide reasonable access to these non-UDI supported functions.  The "risk", if you will, would be that a user of a plug in should be able to trust the competency of the plug in supplier.  That's not really any different from using any open source or similar program.  It is pretty much what we have for any of the small other tools  that are mentioned/used in these forums that aren't supplied by UDI.  So, in reality, what I mean is that if someone here supplies a plug-in that locks up one of your switches you'd need to do a factory reset on it and not use the plug-in again until it got fixed. 

[Teken]

Ah - you took my "at your own risk" comment a bit differently than I meant it.  I agree with you regarding the info availability.  What I meant was just that if UDI provided an "add-in" mechanism whereby the community could make additional functions available, their responsibility would be that the add-in mechanism itself worked rather than some particular add-in from a member/user here worked.  This is an active enough community that it could support reviewing, bug-reporting, etc. for user contributed add-ins that would provide reasonable access to these non-UDI supported functions.  The "risk", if you will, would be that a user of a plug in should be able to trust the competency of the plug in supplier.  That's not really any different from using any open source or similar program.  It is pretty much what we have for any of the small other tools  that are mentioned/used in these forums that aren't supplied by UDI.  So, in reality, what I mean is that if someone here supplies a plug-in that locks up one of your switches you'd need to do a factory reset on it and not use the plug-in again until it got fixed. 

 

Understood and 100% agree!

 

People can not throw rocks at people like I/O Guy who offer similar plugins with no profit in return. Same is true with any of the excellent (free solutions) provided by the community. I just wanted to make the distinction for all to see as the two are not directly related.

 

I thank you and everyone else who have taken a few moments to reply and cast their vote.

[MikeD]

Instead, maybe a smaller scale side project to add the ability to send raw commands to any linked device that we (the user community) can use to enable/disable features that are not directly supported (Bink on RX/TX, Beep On/Off, Program Lock etc).

I like this idea. If this capability existed we could send customized commands to devices without having to rely on what was available in pulldown lists. I never was able to obtain a solution to this request.

http://forum.universal-devices.com/topic/14238-thermostat-cycle-fan-mode/

 

~Mike

[Michel Kohanim]

Hi Xathros,

 

Paul B explained your idea to me but I didn't understand it properly. I like the idea because we already have that feature but completely hidden. The problem is not corrupting the device but also what ISY know about the device. That's why it's been hidden all this time.

 

I have to think about whether or not we would want to make this available.

 

Thanks so very much.

 

With kind regards,

Michel

[Nestor]

I jumped ship from another controller manufacturer just last week because while they rolled out a new firmware version, their advertised Insteon compatibility was still half-baked. I'm referring to what should be an intermediate feature easily found in a full user manual. In my case, the last straw was not being able to change the IOLinc relay modes beyond "latched" or "a" when setting up a garage door. State changes, such as turning on a Switch Linc at the rocker switch, were not being reflected back to the controller. In one situation, had it not been for the Insteon device controller/responder feature, this would have rendered my switches useless from a programming standpoint.

I hope this is useful insight from the standpoint of a new user. There are a number of other issues that drove me to the ISY, but I'm not sure they are relevant to this discussion.

 

 

Sent from my iPhone using Tapatalk

[Xathros]

Hi Xathros,

 

Paul B explained your idea to me but I didn't understand it properly. I like the idea because we already have that feature but completely hidden. The problem is not corrupting the device but also what ISY know about the device. That's why it's been hidden all this time.

 

I have to think about whether or not we would want to make this available.

 

Thanks so very much.

 

With kind regards,

Michel

Hi Michel-

 

I don't think that corrupting a device is all that bad.  At worst, it's a factory reset and a restore device to undo whatever I/we did wrong with a "Manual command".  Again, I think it should be and advanced feature and come with a warning that you very well may corrupt your device if you send bad data to the device - Proceed with caution!  Ideally, the command entry area would sanity check the user's input as much as possible before send (verify valid linked address, calculate checksum and whatever else that can be checked). Obviously it can't know everything about the device or the device would already be fully supported. 

 

As I stated in my first reply, this should probably be an add on module for the ISY like Networking or Pro.  That will keep it out of the hands of the average user and into the hands of those committed enough to pay for it.  With the developer docs now available and the wealth of knowledge on this forum, this capability will resolve much of the "not fully supported" issues that we see here.  Some of us use homeseer, smartenit utility or busyrat utilities to do these things now.  Busyrat is gone and Homeseer is no longer supported AFAIK. To accomplish this, we need to pull the PLM off the ISY and hook to a PC to use these.  It would be soooo much easier if we could just open a window in the admin console and issue a command without taking the ISY offline to do it. (Think: Switch from Master Valve to Zone Valve on EZFlora.  I know this is now supported but only in recently.  How long was this asked for?)

 

The ISY has proven itself to be a professional grade tool.  In my opinion, this would only further that distinction.

 

As always, thank you for your consideration.

 

-Xathros

[kck]

I agree with Xathros with one additional point that I raised above.  If/when you externalized the capability it would be much more useful if it were possible for a user to use prepackaged commands supplied by others easily.  This would make it much easier for the experts here to share their knowledge should they wish to and much safer for the advanced but less expert user. That is what my comments about add in libraries was about.  Someone might well package up a set of useful commands for some device that is only partially supported and make them available.  At the least this would require some amount of device name substitution so that a generic form of a command could be built that was useable in programs etc.  So it would be a little more than just the ability to dump a hex command string into a window if you want it to become a long term assist to you guys in not having to worry about every corner case command for every device.

[MWareman]

The Wiki could be a central repository of 'extended' commands - so I'm not worried about having direct support for prepackaged commands (although I agree it would be nice to have). I throw my full support behind the idea @Xathros.

[larryllix]

The Wiki could be a central repository of 'extended' commands - so I'm not worried about having direct support for prepackaged commands (although I agree it would be nice to have). I throw my full support behind the idea @Xathros.

+1.Good halfway point and long term workable.

[Michel Kohanim]

Thanks so very much everyone and especially Xathros.

 

While we are inside the code for 5.0 we are going to take a look and see if we can easily provide an API for Get/Set operating flags. This is much safer than providing unrestricted access to INSTEON which could wreack havoc on everything including the PLM. So a hybrid of Xathros suggestion and a limited command set.

 

With kind regards,

Michel

[jwagner010]

Hi Michel-

 

I don't think that corrupting a device is all that bad. At worst, it's a factory reset and a restore device to undo whatever I/we did wrong with a "Manual command". Again, I think it should be and advanced feature and come with a warning that you very well may corrupt your device if you send bad data to the device - Proceed with caution! Ideally, the command entry area would sanity check the user's input as much as possible before send (verify valid linked address, calculate checksum and whatever else that can be checked). Obviously it can't know everything about the device or the device would already be fully supported.

 

As I stated in my first reply, this should probably be an add on module for the ISY like Networking or Pro. That will keep it out of the hands of the average user and into the hands of those committed enough to pay for it. With the developer docs now available and the wealth of knowledge on this forum, this capability will resolve much of the "not fully supported" issues that we see here. Some of us use homeseer, smartenit utility or busyrat utilities to do these things now. Busyrat is gone and Homeseer is no longer supported AFAIK. To accomplish this, we need to pull the PLM off the ISY and hook to a PC to use these. It would be soooo much easier if we could just open a window in the admin console and issue a command without taking the ISY offline to do it. (Think: Switch from Master Valve to Zone Valve on EZFlora. I know this is now supported but only in recently. How long was this asked for?)

 

The ISY has proven itself to be a professional grade tool. In my opinion, this would only further that distinction.

 

As always, thank you for your consideration.

 

-Xathros

Don't just show a warning force an ISY backup before the user can use this functionality (better yet force a backup only if one hasn't been made within last 24 hours). That way if all goes completely wrong (ie with ISY or PLM not just the device) UDI can be assured the user made a current backup up of ISY that can be used to restore devices, PLM, etc if needed.

 

Also really like the idea of using the wiki where user community can log these options and what device versions they have tested successfully on.

 

Finally I also think this would be a way for UDI to use the community to improve the product. Ie if the user community is discovering these options and implementing them, then after a period of time (call it an alpha testing of the option), UDI can then determine if it wants to build that option into the ISY / admin console.

[Xathros]

Don't just show a warning force an ISY backup before the user can use this functionality (better yet force a backup only if one hasn't been made within last 24 hours). That way if all goes completely wrong (ie with ISY or PLM not just the device) UDI can be assured the user made a current backup up of ISY that can be used to restore devices, PLM, etc if needed.

 

Also really like the idea of using the wiki where user community can log these options and what device versions they have tested successfully on.

 

Finally I also think this would be a way for UDI to use the community to improve the product. Ie if the user community is discovering these options and implementing them, them after a period of time (call it an alpha testing of the option), UDI can then determine if it wants to build that option into the ISY / admin console.

In this case, an ISY backup wouldn't really help much.  It's the target insteon device that may be corrupted, not the ISY.  While having an ISY backup is a good thing, it would,'t be of any use in recovering a device corrupted by a bad config message.  A factory reset of the target device and a restore device issued at the ISY is all that would be needed.

 

Your idea has value however.  If the admin console could track how long it has been since last backup, or how many changes have occurred since last backup and prompt the user to make a new backup after some threshold has been passed, I think this is a good idea.

 

-Xathros

[kck]

Whatever mechanism is chosen needs to be able to have the commands issued from within programs since some of the extended features aren't necessarily set once items (e.g., beeping).  This also means that the device address itself should be the name the device has within the UI and not the underlying numeric address since the latter would change in the case of device replacement.  Some of the discussion here seems (perhaps not but just the wording) to assume a one time model of the user actually issuing a command from a special menu in the admin console.  IO don't think that would be really quite enough.