Eric2XU Posted February 25, 2016 Posted February 25, 2016 Somewhat unrelated but I wrote a NodeJS Web Service running on a Raspberry PI that is the middle man between Amazon Echo, Philips Hue, and the ISY. Things are great, I tell Alexa to turn on kitchen light to 25% and she can do it BUT because I am interacting with the device directly not the Scene which has the SwitchLinc and the KeypadLinc Button D part of, the keypadLinc button D does not light up (gets out of sync). Now sure I could control the Scene if I wanted straight on (100%) and off (0%) but what about when I want to turn on the lights to a dimmed value like 31%? As far as I know there is no API to allow the setting a KeypadLinc button to a dimmed percentage. BUT I know its possible, if I manually hold down the KeypadLinc button for a second and let go, sure enough both Scene members (KPL and SWL) set to 31% as shown in the photo below So is there anyway to do this or do I have to live with a 0/100 or KeypadLinc button out of Sync life? Some extra info, I have been using an ISY for about 5 years now, Scene's always seem to be the thing that derails all of my good ideas, hopefully I am just missing something?
MWareman Posted February 25, 2016 Posted February 25, 2016 (edited) You could write a program that adjusts the on level of both devices in a scene to 31% and then turns the scene on, finally resetting the devices scene on level back to 100%, and have Alexa trigger that... However, Insteon does not support turning a scene anything other than 'on' or 'off' directly. Finally, I don't think having a KPL button at 31% will cause it to be any dimmer than 100%. I thought those were purely on/off devices that can only be controlled via membership in a scene. Edited February 25, 2016 by MWareman
Eric2XU Posted February 26, 2016 Author Posted February 26, 2016 I definitely don't have a problem with controlling more than one device, in fact my nodeJS app allows me to add an unlimited amount of ISY commands to a single Alexa command. However http://isy/rest/nodes/8052/cmd/DON/128or http://isy/rest/nodes/2B%20FD%2080%204/cmd/DON/128 just doesn't work to set the KPL directly. Can you give me insight to how you do it?
MWareman Posted February 26, 2016 Posted February 26, 2016 I definitely don't have a problem with controlling more than one device, in fact my nodeJS app allows me to add an unlimited amount of ISY commands to a single Alexa command. However http://isy/rest/nodes/8052/cmd/DON/128or http://isy/rest/nodes/2B%20FD%2080%204/cmd/DON/128 just doesn't work to set the KPL directly. Can you give me insight to how you do it? You cannot send direct dim commands to a scene - only a device. If you need scene members to come on at different levels that usual, you need to either adjust the scene (changing it back afterwards), or use multiple scenes (with the members having differing on levels).
LeeG Posted February 26, 2016 Posted February 26, 2016 (edited) Eric2XU Everything MWareman has posted is right on. I thought adding some background might be helpful. Insteon does not support an override On Level on a Scene command. http://isy/rest/nodes/8052/cmd/DON/128 - Insteon Scene command has no field for the 128 value ISY has the Adjust Scene Program Action for changing a Scene device On Level and Ramp rate (as MWareman indicated) Only a KPL Primary load control button (Main A 8 button; ON/Off buttons 6 button) can be controlled with a Direct command. KPL Secondary buttons can be turned On/Off only with a Scene command. Again, this is an Insteon requirement. The On Level values 1-254 have no affect on Secondary KPL buttons. Setting a Secondary KPL button to 30% On Level has no visual affect. No need to set a Scene KPL Secondary button to anything but On or Off. A Scene definition of a KPL Secondary button with 0% On Level will turn the Secondary KPL button Off with a Scene On command. Hope these details help. Edited February 26, 2016 by LeeG
Eric2XU Posted February 26, 2016 Author Posted February 26, 2016 I think I understand the limitation. Did the designers of Insteon consider this secondary KPL button out of sync issue and if so how do I make sure it doesn't happen. I am perplexed by the idea that the KPL Secondary key itself can effect a SwitchLinc switch to a dimmed value but I have not abilty to do the very same thing via the ISY console or in particular to this thread through the ISY API. Is there a REST API for adjusting the ramp rate? I dont mind setting it, turning it on, then reverting it back if that's needed but looking over the API I dont see the ability to do that.
Jimbo.Automates Posted February 27, 2016 Posted February 27, 2016 Write ISY programs to adjust the ramp rate, and you can run those programs via REST or use variables to trigger the programs and change the variables via REST. Sent from my Nexus 6P using Tapatalk
LeeG Posted February 27, 2016 Posted February 27, 2016 Eric2XU Ok, lets do this the other way. What does the Secondary button D being displayed at 31% mean to you? Button D intensity is less than it would be at 100%? A linked device is set to 31% when button D Status is 31%? Something is different about button D when its Status is 31%? ????
andrew67 Posted May 9, 2016 Posted May 9, 2016 Did this ever get fixed? It seems it partially got fixed... I can dim a scene now from the echo, so obviously something got fixed, and I can turn a scene on and off right now, but I can't set it to a percentage???
stusviews Posted May 9, 2016 Posted May 9, 2016 T'was never broken. The Insteon protocol does not include setting a scene to a percentage, only devices. Changing the basis of what commands do is not a trivial matter. Even if it were possible, what would it mean? Does set the scene to 31% mean set each responder device to an On-level of 31%. Or is it 31% of what each dimmer is currently at? What happens to On/Off devices? What does 100% mean? Turn devices on to their respective scene On-level or turn every device in the scene full on? Benoit found a way to adjust scene responders by about 9% in each direction, dim or brighten.
MWareman Posted May 9, 2016 Posted May 9, 2016 (edited) Even if it were possible, what would it mean? Does set the scene to 31% mean set each responder device to an On-level of 31%. Or is it 31% of what each dimmer is currently at?31% of whatever the scene on level for the device is..... That would be the naturally expected result. Edited May 9, 2016 by MWareman
stusviews Posted May 9, 2016 Posted May 9, 2016 31% of whatever the scene on level for the device is..... That would be the naturally expected result. And 100% would be? The scene On-level for each device? If so, then how does one bring the devices to full on? If not, then how can the scene levels be resurrected?
MWareman Posted May 9, 2016 Posted May 9, 2016 And 100% would be? The scene On-level for each device? Yes. If so, then how does one bring the devices to full on? Why would you want to bring a member of a scene such as this to 100%? If a members scene on level is 50% - your intent for that scene is to have that load at 50% - setting it's brightness to a level with relation to other loads in the scene - to create a scene. If you want to set the load to 100% outside of your scene then command the load directly - or a separate scene where the devices scene on level is 100%. If not, then how can the scene levels be resurrected? Set the scene to 100% - or set it on. For scenes with multiple loads potentially at differing on levels, then what's important to a dimmed scene is that the relationship between the loads is preserved. For instance, if it takes 5 seconds to dim 50%, and your scene members in a scene one scene have on levels of 50% and another 100%, what happens when you hold a scene controller paddle for 5 seconds? You get the first scene member at 25% and the second at 50%. That's the expectation for asking for a scene to be on at 50% - each member at 50% of its default on level.
LeeG Posted May 9, 2016 Posted May 9, 2016 "For instance, if it takes 5 seconds to dim 50%, and your scene members in a scene one scene have on levels of 50% and another 100%, what happens when you hold a scene controller paddle for 5 seconds? You get the first scene member at 25% and the second at 50%. That's the expectation for asking for a scene to be on at 50% - each member at 50% of its default on level. " Unfortunately Insteon Scenes/Devices have never operated that way. Devices Fade Up/Down at the same rate. When the Fade Stop is issued, if the 100% On device has faded down to 50% the device that started at 50% will be Off. Devices Fade Up/Down at the same rate. Keep in mind Insteon devices are designed to be operated by a human. If the device at 50% On had a defined ramp rate of 8 minutes it would take 4 minutes to ramp down to 25%. Not practical for several reasons. No human will hold a button/paddle for 4 minutes, holding a button for that long would put the device into linking mode, and on and on. All devices ramp up or ramp down at the same rate when commanded to ramp.
stusviews Posted May 9, 2016 Posted May 9, 2016 Yes. Why would you want to bring a member of a scene such as this to 100%? If a members scene on level is 50% - your intent for that scene is to have that load at 50% - setting it's brightness to a level with relation to other loads in the scene - to create a scene. If you want to set the load to 100% outside of your scene then command the load directly - or a separate scene where the devices scene on level is 100%. Set the scene to 100% - or set it on. For scenes with multiple loads potentially at differing on levels, then what's important to a dimmed scene is that the relationship between the loads is preserved. For instance, if it takes 5 seconds to dim 50%, and your scene members in a scene one scene have on levels of 50% and another 100%, what happens when you hold a scene controller paddle for 5 seconds? You get the first scene member at 25% and the second at 50%. That's the expectation for asking for a scene to be on at 50% - each member at 50% of its default on level. That's your opinion--which I fully respect. All I'm saying is that opinions differ and setting a scene to a particular level varies among users. For example, if I have a scene that has a device at 50% and I want the light to be at 30%, I'd like to be able to say 30%--the level I want, not 60% (3/5 of the current level). To me, it's counter-intuitive to have to say 60% when I mean 30%. That plus having to calculate the percentage of the current On-level to achieve a new On-level. For example, it a load is at 75% and I want 50%, I'd have to ask for the level to be at 67% And if I can't use 100% when I mean full on or any other level above the preset On-level, then that minimizes the use of setting scene percentages.
oberkc Posted May 9, 2016 Posted May 9, 2016 Why would you want to bring a member of a scene such as this to 100%? If a members scene on level is 50% - your intent for that scene is to have that load at 50% - setting it's brightness to a level with relation to other loads in the scene - to create a scene. If you want to set the load to 100% outside of your scene then command the load directly - or a separate scene where the devices scene on level is 100%. . From a purely intellectual and logical perspective, one would want to do this for the same reason that one would want to set a scene members level to something LESS than the pre-defined ON level. If we accept that there are times that one may want to turn on a scene a reduced values, it seems logical that there might also be times that one might also want to turn them on at increased levels, no? Fortunately, I find stusviews assessment spot on....nothing is broken. The insteon design allows for this by allowing the creation of multiple scenes. Pre-define scenes at the levels desired and call it a day. I would add, also, that insteon DOES include the options to redefine scene responder levels, correct? Given this, another question that could be asked is why echo cannot properly interpret a request to set set scene levels to something other than pre-defined levels is not properly executed using the tools at hand...ie, when is the echo going to get fixed? Ultimately, neither insteon, echo, or the ISY is "broken" in this case and expectations of any being fixed are misplaced. Instead, there are existing methods to solve this problem and that is: scenes and more scenes.
andrew67 Posted May 9, 2016 Posted May 9, 2016 Actually, Insteon is very badly broken, and was from the day it was conceived, which is partially why the ISY exists in the first place. The basic problem is that the insteon protocol was never intended for true home automation, and is about 20x to 100x too slow to actually perform its desired function. Hence the "commands" are deliberately shortened to the point where there isn't even a set scene to value command as an "operating" command. Using live re-programming of devices to add functionality would take minutes per command, and even routing commands through the isy and leaving all devices as linked only to the modem and not part of a scene (which theoretically is the right way for a HA system to work) is much too slow as well. This leaves the ISY to try to clean up the mess. Its function seems to be best left as link management, but that leaves lots of dumb Insteon stuff, like: a 3 way light switch setup is a scene, and not a device, and can't be set to 50%. So now everyone is trying to get their echo to do cool things, and the workaround for setting a scene to 50% is to create a 50% scene and then mess up the echo's grammar to fix it. Now we are fixing the original problem with not one but two counter programmed hacks. Perhaps there would be a way to have the isy interpret a set scene to 50% command as a series of device commands rather than a scene command, or have access to multiple scene commands. It has the information, and it would work, but be slow. However that "program" can't be written because: 1) programs can't be set to a value 2) a generalized program can't traverse the tree of devices so you would have to write them manually 3) you would be programming scenes for a decade for any non-trivial system at an even reasonable scene density If #1 can be fixed, then #2 and #3 could be done with "helper apps" on the ISY.
oberkc Posted May 9, 2016 Posted May 9, 2016 Actually, Insteon is very badly broken, and was from the day it was conceived, which is partially why the ISY exists in the first place. Well, broken is relative. Insteon is a known commodity. Broken, to me, suggests that it does not do something that it claims to do. This is like claiming that since insteon does not wash your car, it is, therefore, broken. There are no claims made about scene commands such as discussed. Perhaps a better way of putting is it that insteon is not well suited to meet everyone's desires...not suited for all purposes. Perhaps there would be a way to have the isy interpret a set scene to 50% command as a series of device commands rather than a scene command, or have access to multiple scene commands. Of this, I am more confident. This could be done with a program(s). Then, one would have create the echo>ISY command relationships. There may be some around here that can help with that. I am not one of them.
Jimbo.Automates Posted May 9, 2016 Posted May 9, 2016 Perhaps there would be a way to have the isy interpret a set scene to 50% command as a series of device commands rather than a scene command, or have access to multiple scene commands. It has the information, and it would work, but be slow. However that "program" can't be written because: 1) programs can't be set to a value 2) a generalized program can't traverse the tree of devices so you would have to write them manually 3) you would be programming scenes for a decade for any non-trivial system at an even reasonable scene density If #1 can be fixed, then #2 and #3 could be done with "helper apps" on the ISY. ISYHelper does #2 in the PyHue interface. While this isn't the "Insteon way" it's works perfectly. I have scenes that are really meant to be "groups" where I want all devices act together, but can also be controlled individually. For example, 2 bedroom lamps 'lamp a', and 'lamp b' in a scene called 'bedroom lamps'. So Alexa can set brightness of both lamps together, or independently. Makes sense to everyone, especially my Wife which is what counts. If I had to create specific scenes and tell her how to use them because that's "how insteon works", she would roll her eyes, and just not use it. This is probably the only reason I have not moved to the Portal.
andrew67 Posted May 9, 2016 Posted May 9, 2016 If you replace "claims" with "as the user expects given the claims" then I think we agree. The reality is that insteon is terrible from many perspectives, and I probably would not have installed it if I had known just how bad it was. However, I am stuck with 150 devices, and re-wiring is not an option... next time I'm not buying anything without a 10 year warranty. I've replaced (parts inside of) 150 of 150 devices.... i.e. 100% failure rate at 4 years, so I'm sorry if I'm a little jaded. Whats PyHue? ANd how does that relate to the portal and controlling ISY?
Jimbo.Automates Posted May 9, 2016 Posted May 9, 2016 (edited) Whats PyHue? ANd how does that relate to the portal and controlling ISY? Part of ISY Helper: http://forum.universal-devices.com/forum/118-isyhelper/ Edited May 9, 2016 by Jimbo
apnar Posted May 9, 2016 Posted May 9, 2016 I've often wanted for a true virtual device in the ISY that mimics a single device but is backed by one or more scenes. For example I have a whole bunch of fanlincs with matching 6 button key pads. To make them work you need to create 4 scenes (one for each fan speed), but for every use I want those 4 scenes treated as a single device with 4 speeds. Same thing with 3 and 4 way switches, I always want them treated as a single device. I envision it as picking the type of device to mimic (on/off, fan, dimmer) then for each state (or range of dim values) you pick which scene backs that state. It might be a little tricky to make a decent UI for but I don't see why functionally it couldn't work. You might end up with a ton of scenes though. You can sort of fake this with programs but it'd be I think it'd be better as a virtual device.
Recommended Posts