Teken Posted September 10, 2015 Posted September 10, 2015 Over the years some of the devices firmware features have been renamed. However, I do agree that all options should be made available if the product supports it. If you do a search under my profile you will see where I first asked this same very question. The current shipping lamp linc is still missing several options which are clearly listed in the full users manual. Ideals are peaceful - History is violent
Teken Posted September 10, 2015 Posted September 10, 2015 (edited) Also the on-off module does not use blink on TX. It's blink on error. Whereas the other is LED on TX. Ideals are peaceful - History is violent Edited September 10, 2015 by Teken
LeeG Posted September 10, 2015 Posted September 10, 2015 "All of this thread devoted to Blink on Traffic and in the end, LED on TX is 'Blink on Traffic'!" Same feature, difference is the ISY uses the terms in the developers documents, the other term is what is in the sales document. There are other examples. The PLM Developers document never uses the word Scene (uses Group), yet in the sales document things refer to Scenes and the word Group is hard to find. There are capabilities in the ISY externals that stem from what is in the developers documents that have never actually been implemented in the device firmware. ISY Programs can set individual KPL button Backlight levels yet the setting applies to all the KPL buttons, not just the one being set. The ISY does not chase the sales information. It uses the information in the developers documents which may well be different because the device has not "yet" implemented a given feature/function or the words are different. SmartLabs does not always keep the developer information and the sales information in sync nor use the same wording/descriptions. Something that will have to be accepted.
rlanza1054 Posted September 11, 2015 Author Posted September 11, 2015 Also the on-off module does not use blink on TX. It's blink on error. Whereas the other is LED on TX. Ideals are peaceful - History is violent Hi, The on/off module does offer both, its in the user documentation. Rob
Teken Posted September 11, 2015 Posted September 11, 2015 Hi, The on/off module does offer both, its in the user documentation. Rob So your eyes and screen capture are lying to you? Ideals are peaceful - History is violent
rlanza1054 Posted September 11, 2015 Author Posted September 11, 2015 (edited) "All of this thread devoted to Blink on Traffic and in the end, LED on TX is 'Blink on Traffic'!" Same feature, difference is the ISY uses the terms in the developers documents, the other term is what is in the sales document. There are other examples. The PLM Developers document never uses the word Scene (uses Group), yet in the sales document things refer to Scenes and the word Group is hard to find. There are capabilities in the ISY externals that stem from what is in the developers documents that have never actually been implemented in the device firmware. ISY Programs can set individual KPL button Backlight levels yet the setting applies to all the KPL buttons, not just the one being set. The ISY does not chase the sales information. It uses the information in the developers documents which may well be different because the device has not "yet" implemented a given feature/function or the words are different. SmartLabs does not always keep the developer information and the sales information in sync nor use the same wording/descriptions. Something that will have to be accepted. Hi, So my question is this, is the ISY designed for developers only or for end users. End users are reading the documentation that comes with the device. Today was the first time I heard that there is totally different documentation for developers. I actually blame this on Insteon not ISY. The developer documentation shoud contain the terminology used for programming but also let the developer know that the end user should get the programming terminology translate to putting the label that the end's documentation is using. Remember, the HUB, when it was designed, if the developer of the product used the developer documentation, they actually used the end user the label from the end user documentation. So there is nothing labled LED on TX in any of the devices when using the HUB. And its just not Insteon's Hub, the Houselinc software does not user these developer terms. So honestly, Its either Insteon fault by not being clear in the developer documentation of what term to present to the end user. And this does not explain why then if LED on Tx is equal to Blink on Traffic, then why does the On/Off plugin module offer in options both LED on Tx and Blink on Traffic. If the above line is true, then ISY is beng sloppy by offer both terms within the same device. I have a feeling these two labels are actually different things. The reason, as you will read, I tested it out to by checking off LED on TX to get the 'Blink on Traffic', it did work but now I am getting something odd. What I am about to say, just might be a bug. I think I need to see if there is a list of know problems. I don't want to ask questions about things that are already known. Ok, here is what is happening after I turned on option LED on TX, whenever I adjust the LED brightness, it takes the setting change just fine but then when you go and look at options, it then checked off to 'Lock Programming'? Why when adjusting the LED brightness, is it Locking Programming? Rob Edited September 11, 2015 by rlanza1054
Teken Posted September 11, 2015 Posted September 11, 2015 Hi, So my question is this, is the ISY designed for developers only or for end users. End users are reading the documentation that comes with the device. Today was the first time I heard that there is totally different documentation for developers. I actually blame this on Insteon not ISY. The developer documentation shoud contain the terminology used for programming but also let the developer know that the end user should get the programming terminology translate to putting the label that the end's documentation is using. Remember, the HUB, when it was designed, if the developer of the product used the developer documentation, they actually used the end user the label from the end user documentation. So there is nothing labled LED on TX in any of the devices when using the HUB. And its just not Insteon's Hub, the Houselinc software does not user these developer terms. So honestly, Its either Insteon fault by not being clear in the developer documentation of what term to present to the end user. And this does not explain why then if LED on Tx is equal to Blink on Traffic, then why does the On/Off plugin module offer in options both LED on Tx and Blink on Traffic. If the above line is true, then ISY is beng sloppy by offer both terms within the same device. I have a feeling these two labels are actually different things. The reason, as you will read, I tested it out to by checking off LED on TX to get the 'Blink on Traffic', it did work but now I am getting something odd. What I am about to say, just might be a bug. I think I need to see if there is a list of know problems. I don't want to ask questions about things that are already known. Ok, here is what is happening after I turned on option LED on TX, whenever I adjust the LED brightness, it takes the setting change just fine but then when you go and look at options, it then checked off to 'Lock Programming'? Why when adjusting the LED brightness, is it Locking Programming? Rob Would you please read your own reply. It conflicts with exactly what you posted in the screen capture! It's blink on error! Ideals are peaceful - History is violent
rlanza1054 Posted September 11, 2015 Author Posted September 11, 2015 (edited) Would you please read your own reply. It conflicts with exactly what you posted in the screen capture! It's blink on error! Ideals are peaceful - History is violent For what device? I was showing a Insteon decvice that has both Blink on Traffic and LED on TX. The original reason for starting this thread is that a different Insteon device, not the new On/Off Plug-in module, does not contain 'Blink on Traffic' only LED on TX. Replies are stating that LED on TX is the same as Blink on Traffic. I was trying to point out that if that is indeed true, then why does the On/Off Plugin Module contain both options if they are exactly the same thing. The original topic has turned to point out things that some of the replies are not explaining. And then my last post was pointing out a third item, that when using the option LED on TX, when that is checked off and you make a change in the LED brightness on the Insteon dimmer 2477D, it turns on the option setting of 'Lock Programming'! I have not been saying anything that conflicts. If I have a grammar mistake, I try to fix those after I posted and am sorry if my posts have confused anyone. I am not angry over any of this, its just as a new user of the ISY, I have been encountering things that are strange. I try to ask questions so we can determine if its something I don't yet understand or making sure I am not encountering a bug in the software or point out a development issue. This Blink on Traffic issue has apparently been brought up by other users at a different time and thread, who have even commented here. So if you wish to think this out logically, today I found out that if I check LED on TX, it seems to turn on the Blink on Traffic functionality when the Blink on Traffic option is missing in older devices. Again, think logically, if LED on Tx is the same exact thing as Blink on Traffic, then why are the two options provided on the particular device that is offering both options. Let's take this one step more logicallly, if the two option are the same thing, and presented on the same device, which option should I check if I want that option. Again, take it one more step logically, if I check off for example LED on Tx, and do a query, then if the are indeed the same function, after the query, a check box should show up on both options. If I could get a copy of the developer documentation, maybe I would understand why the term LED on TX is being used over what the end user documentation is listing as the available option of Blink on Traffic. It has been stated that the ISY development team only uses the development documentation not the end user documentation. Again, look at this logically, if everyone is using only the development documentation, then why does the Insteon HUB never use the term LED on Tx but only uses the term that is in the end user documentation of 'Blink on Traffic' and I pointed out that even a third product Houselinc software only offer Blink on Traffic? Trying to solve this puzzle of inconsistencies, I have to logical say that ISY is not getting the same developer documentation as those two other products receive? Is it that Insteon is not providing ISY with a complete details of the developer documentation. To use another industry, Apple provides developer documentation to third party developers and I know for a fact (my brother was a developer of application that was/is used on a Macintosh) that it requires compliance to using standard terms and look. Google is now requiring Android developers to code using the new Material Design look and function. I realize that my examples are mostly UI standards but I was trying to make a point that usually a company of a product wants end users to see a standard set of terms. i asked in a previous post, if the ISY is designed for ONLY developers, if that is the case, then the usually developers and programmers don't really care if the terms are swapped on occasion. I realized that Harry (not a real person) might write the code for Insteon device X and Harold might write the code for device Y. Harry and Harold are not talking to each other, so the pick the term they want to use. Unless there is oversight by a team leader. These few paragraphs are based on a unproven fact that LED on TX and Blink on Error are exactly the same thing. It might turn out that they are different but can look like they are the same, example to prove my point, the command ON and Fast ON can at times result in a light being turned on, but we know they actually do different things. Rob UPDATE: After some additional testing, the paragraph: And then my last post was pointing out a third item, that when using the option LED on TX, when that is checked off and you make a change in the LED brightness on the Insteon dimmer 2477D, it turns on the option setting of 'Lock Programming'! Turns out that it is a totally separate issue/bug/problem not related to the LED on Tx. Its mostly like a bug or maybe its a 'feature'? I will ask this question in a different thread. Also, I asked in a previous post if there is a consolidated list of 'known' issues/bugs/problems that I could look over, so I don't waste anyone's time on something that Universal Devices is already aware of. And I understand that some things just cannot be fixed for whatever reason. But at least I will know. Edited September 11, 2015 by rlanza1054
stusviews Posted September 11, 2015 Posted September 11, 2015 Again, think logically, if LED on Tx is the same exact thing as Blink on Traffic, then why are the two options provided on the particular device that is offering both options. LED on Tx is not the same as Blink on traffic. LED on Tx will blink green if the particular device sends a signal that is ACKed (successful) and will blink red if the transmission is not ACKed. Blink on Traffic will blink if any device on the Insteon network sends a signal at all.
LeeG Posted September 11, 2015 Posted September 11, 2015 (edited) ", then why does the On/Off Plugin Module contain both options if they are exactly the same thing." The 2635-222 Plugin On Off Module Owners Manual describes Blink on Traffic and Error Blink (blinks red if no ACK from a Responder) on page 19. I see no conflicting description for an LED on TX option. Edited September 11, 2015 by LeeG
Teken Posted September 11, 2015 Posted September 11, 2015 For those just reading this thread for the very first time I would like to summerize the over all topic.1. Smartlabs: Has over the years used different naming conventions and phrases for various hardware devices. This has been seen in their HUB (App) controllers, House Linc 2, etc.2. Third Party: Many of the 3rd party vendors have been known to follow the development guid for naming features and options. Where as others have tried to follow the public facing documents and devices / software as listed above in (1).3. Features & Options: Over the years UDI and others have not received all the required information about how to properly impliment code to support for new or existing Insteon hardware. This has been seen in the Leak Sensor, Trigger Linc (Open-Close), Hidden Door, Morning Lock, the list goes on.4. Communications: Smartlabs has over the years not been known for very good communications. This lack of feed back has ultimately resulted in devices not being supported correctly from other vendors such as UDI. Having said this, its my view once this information is made known all features and options should be made available to the end user(s).Because these features are intended for use and applications that may suite a persons use case. An example of a device which has not been properly supported is the latest dual band lamp linc. The option(s) to enable beep, blink on TX are only available via a software controller. These options are not present in the ISY Series Controller and there is no manual method to enable them.5. Firmware: It has been noted that Smartlabs which related to point (4) does not communicate when firmware is adjusted, modified, or deprecated. Meaning a person can have the exact same hardware release date, firmware, ISY version. But the device will operate completely different then others.This was seen in the Leak Sensor where the device would send a change of state from wet to dry with out any user intervention. Later firmware releases required the end user to physically press the set button to change that wet to dry state.This was also seen in the latest Trigger Linc / Open-Close sensor where the device had the ability to see and adjust the heart beat, battery nodes. Previous generation devices did not have either battery / heart beat nodes. Later firmware releases provided heart beat but no method to adjust the interval. The last release of this device indicates the battery / heart beat nodes are not only present but can be adjusted.This was first seen in the hidden door sensor.In closing, the average consumer should not take what the users manual, development guide, or any physical device as the end all, be all. Smartlabs continues to change and update their wares which is fine because over all this makes the product better.But the lack of coninutity and disconnect from published documents often times leads to confusion and discontent from the general public. Because people are referencing forums such as this in the hopes of applying or using said features. The problem is Smartlabs continues to move the goal line and its a moving target that the public simply has to accept and adapt to.Bottom line: Use the forums to obtain the most up to date information as it pertains to features, options, and best practices with programming. Its safe to say all of us continue to learn new things and accept the ever changing features that come with using Insteon products. The reality is in the big picture regardless of all my past bitching about communications.Its apparent to me Smartlabs is listening to the public and have included many features never seen before which is great!
rlanza1054 Posted September 11, 2015 Author Posted September 11, 2015 Finally! A confirmation that what I was saying from the beginning. So that being the case. Is there a possibility in some future (no date required) that the missing options settings functions can be added to those devices that are missing it now using the ISY. That way we won't have to go back to the Insteon Hub to activate those functions. (Bear in mine, that these functions cannot be done locally as I was told they can. Its in the end user documentation.) Thank you. Rob PS At this point the moderator Can close this thread. Sent from my SM-N910P using Tapatalk
Teken Posted September 11, 2015 Posted September 11, 2015 Finally! A confirmation that what I was saying from the beginning. So that being the case. Is there a possibility in some future (no date required) that the missing options settings functions can be added to those devices that are missing it now using the ISY. That way we won't have to go back to the Insteon Hub to activate those functions. (Bear in mine, that these functions cannot be done locally as I was told they can. Its in the end user documentation.) Thank you. Rob PS At this point the moderator Can close this thread. Sent from my SM-N910P using Tapatalk Michel from UDI has indicated their long term plans and intent are to review all Insteon devices and provide the options when this information is finally made known to them. At the current pace and development the team is hard at work in the ISY frame work for Z-Wave / 5.XX. If I was to place a *need* comparing the two I would (surpringly) rather have them invest their resources into Z-Wave / 5.XX frame work. As much as it pains me to say the Lamp Linc for example isn't the end of the world. By default the device does not beep when pressed or flash the LED when Insteon traffic is present which is good. Because most folks rather it not do so hence why its not the default setting from the factory. For those like me and others who have a need to view it as a trouble shooting / diagnostic tool it would be really nice to be able to set the beep, LED TX, and LED brightness.
rlanza1054 Posted September 11, 2015 Author Posted September 11, 2015 (edited) Hi, I would rather they focus on getting 5.0 out, then go back to this! The reason for starting the thread, was because I had not known this was a known issue and wondered if it was ever going to be addressed. I was told that it could be taken care of locally and was not going to be fixed, but it turns out its a software only setting, so it does need for it to be fixed. This was the reason for making the request by starting this thread. I never never asked for a time frame. UDI has asked us not to mix in another central controller such as the Insteon Hub. So the only thing left is for them to fix it, but again no one ever asked for a time frame. And I was just trying to verify if LED on Tx was the same as Blink on Traffic which some users think it is the same. (I never thought it was) So today we have the confirmation they are indeed two different things. For me, I own a Insteon Hub. Until UDI does fix the missing settings. (maybe next year, that it a mental time frame in my head) My method to accessing and using these missing options is as follows: (if you disagree with my steps let me know so if anyone wants to do the same it is correct) 1) Remove the device from any scenes on the ISY. There is no need to delete the scene just the device because it will be added back in later) 2) Remove the device from ISY 3) Manually reset to factory defaults, so that all links are removed and any optional settings are set back to defaults that the ISY does support 4) Add device to Insteon Hub (Just plug it back in to AC. Hopefully your not using Hub so it should not have any devices on it, and hopefully you still have your account setup otherwise you have to do the initial setup all over again) 5) Set the options you want that are missing when using ISY. examples: Blink on Traffic Beep on Button Press (the switch does make the sound but its very low, but a blind person would hear it, so there is a reason to use it) There might be other options depending on device And you can fix any LED brightness issue you had with ISY. (I know in my case even though I had LED at 255 it was only going to 50%. the Hub got it back to 100%.) 6) Delete from Hub (those setting should stay in place as long as you do not reset to factory defaults) 7) Add back into ISY (and you can use default setting of 'remove all existing links, it does not touch default optional settings you just made as far as my tests shows) Add back into your scenes. 9) Disconnect the Hub That's my steps. Again If anyone thinks these steps should be modified or wrong please let me know. And one day in the future, we will not need to do this. Rob Edited September 11, 2015 by rlanza1054
Recommended Posts