stusviews Posted February 10, 2015 Posted February 10, 2015 And you could fade devices in your scene, as Michel suggested.
fahrvergnuugen Posted February 10, 2015 Author Posted February 10, 2015 (edited) And you could fade devices in your scene, as Michel suggested. That limits you to developing a GUI based on buttons instead of sliders, with no way to fine tune the brightness of a light if it has a 3 way switch. Seems like a ridiculous limitation. The sliders in this UI work awesome until you have a 3 way switch. Edited February 10, 2015 by fahrvergnuugen
MWareman Posted February 11, 2015 Posted February 11, 2015 My take is the request is valid and useful in the context requested, but detrimental to the way most of us currently use scenes. Not taking a side here, its just how I see it. In general, if there is a way to the solution that doesn't involve breaking the way others use the feature, then the change isn't likely to be accepted.
fahrvergnuugen Posted February 11, 2015 Author Posted February 11, 2015 My take is the request is valid and useful in the context requested, but detrimental to the way most of us currently use scenes. Not taking a side here, its just how I see it. In general, if there is a way to the solution that doesn't involve breaking the way others use the feature, then the change isn't likely to be accepted. The new feature wouldn't impact any legacy systems or scenes in any way, at all, ever. If the ISY receives a command to set a scene brightness to 56%, it would loop through each of the devices in the scene and set each of them to 56% by sending them "/DON/143" commands. That's it. It has nothing to do with on levels, ramp rates or anything else. It wouldn't change the behavior of any of the existing scene commands in any way.
Jimbo.Automates Posted February 11, 2015 Posted February 11, 2015 Which devices will it adjust? I have kpl buttons in scenes as responders with on level of zero to show the scene that it is a controller of has been turned off. I don't want it to turn on. I don't want to take sides either, because I would also like the ISY to have extra functionality on top of insteon scenes, but it's not as simple as it seems.
fahrvergnuugen Posted February 11, 2015 Author Posted February 11, 2015 (edited) Which devices will it adjust? I have kpl buttons in scenes as responders with on level of zero to show the scene that it is a controller of has been turned off. I don't want it to turn on. I don't want to take sides either, because I would also like the ISY to have extra functionality on top of insteon scenes, but it's not as simple as it seems. If you have a scene that you don't want to be affected, then don't ever send it a direct brightness command. This is an API level command that would be available in the script interface or via REST (they could also add a text box to the java admin GUI at the scene level so you could type a brightness value in and hit enter). Point is, there isn't really a reason to interact with this proposed feature with a physical switch, only via script. I just want a way to be able to tell a group of devices to go to X% (where X = whatever brightness I happen to feel like at the moment from 0 - 255). There is currently no possible way of doing this without writing an external program. Edited February 11, 2015 by fahrvergnuugen
Jimbo.Automates Posted February 11, 2015 Posted February 11, 2015 But if it can not be defined as to how it will work in all cases, then I doubt UDI will implement a function that only makes sense in certain situations. Sent from my Nexus 7 using Tapatalk
Michel Kohanim Posted February 11, 2015 Posted February 11, 2015 Hi fahrvergnuugen, As others have suggested, scenes have native meaning to both Z-Wave, INSTEON, Zigbee, and UPB. Z-Wave/Zigbee are more attuned to what you want done since scene commands (depending on the number of devices in the scene) might be a series of direct commands to each device. Furthermore, there's a little problem with sending 56% to a scene: 1. Do devices that are less than 56% (including off) brighten and devices that are more than 56% (including on) dim? Or is it relative to their current state? I think you are suggesting the former 2. What should happen to devices that do not support dimming such as relays? Do they turn off below 50 and turn on above 50? 3. Based on #2 alone, anything we do with our existing scenes will break what everyone else is using including elaborate scenes with buttons, relays, contact closures, etc. So, if indeed this is something we should consider, then scene (with its current semantics) is not the correct aggregation for it. We have to come up with something else in order not to break existing configurations. With kind regards, Michel
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 (edited) Hi fahrvergnuugen, As others have suggested, scenes have native meaning to both Z-Wave, INSTEON, Zigbee, and UPB. Z-Wave/Zigbee are more attuned to what you want done since scene commands (depending on the number of devices in the scene) might be a series of direct commands to each device. Furthermore, there's a little problem with sending 56% to a scene: 1. Do devices that are less than 56% (including off) brighten and devices that are more than 56% (including on) dim? Or is it relative to their current state? I think you are suggesting the former 2. What should happen to devices that do not support dimming such as relays? Do they turn off below 50 and turn on above 50? 3. Based on #2 alone, anything we do with our existing scenes will break what everyone else is using including elaborate scenes with buttons, relays, contact closures, etc. So, if indeed this is something we should consider, then scene (with its current semantics) is not the correct aggregation for it. We have to come up with something else in order not to break existing configurations. With kind regards, Michel Hi Michel, Yes, the whole point is to send a specific brightness command and all the devices should go to that brightness no matter what their current state. The initial problem I was trying to solve was synchronizing dimmers in a very simple 3+ way virtual circuit. I want to tell my dining room light to go to XX% brightness and have all the dimmer LEDs reflect that. I think they should be ignored. What happens with such devices today when you send a scene bright or dim command? I assume nothing... All it should do is automate the process of physically setting a brightness level for each individual node in the scene. I can turn a scene on and then manually adjust individual devices to different brightness levels today and it doesn't break anything. I would expect that if I sent a scene level of 56%, all dimmable devices would go to that level. If I then sent a scene "on" or "off" command, the scene should react exactly as they would today if I walked around and manually set each device to 56%... So it shouldn't break anything at all with existing scenes because this is a new command that automates a manual process you can do today. Of course adding another paradigm is also fine (although it increases complexity), but I think it can fit inside the scene paradigm without causing any issues. Remember, the whole point is to be able to synchronize dimmers in a 3+ way circuit, and to create the circuit in the first place you need to setup a scene... Edited February 12, 2015 by fahrvergnuugen
BamBamF16 Posted February 12, 2015 Posted February 12, 2015 How would you propose handling a scene where 2 responders on level is 100% and 2 responders level was 50%. If you called for scene 50% would you expect 50/50/25/25 or all 50%. The latter doesn't seem to make sense. Since that would be 2 at 56am % and 2 at 100%. Jeff
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 How would you propose handling a scene where 2 responders on level is 100% and 2 responders level was 50%. If you called for scene 50% would you expect 50/50/25/25 or all 50%. The latter doesn't seem to make sense. Since that would be 2 at 56am % and 2 at 100%. Jeff Hi Jeff, The idea was to set them all to to the same level. If a direct scene brightness command of 50% is sent, then all devices would be set to 50%. Another idea came up about also being able to send relative brightness commands, which would allow the 50/50/25/25 you described. See this post from the product suggestion thread I started here: http://forum.universal-devices.com/topic/15383-direct-scene-brightness/?p=131347
fitzpatri8 Posted February 12, 2015 Posted February 12, 2015 (edited) How is this superior to changing the app and slider behavior to be consistent with normal Insteon operation? When you bring up a scene in your app, why not show the slider in the middle? If a user drags it toward the bright side, send a fade up until it is released, or send a sequence of brights to the group appropriate to the degree of movement from center. If the user drags to left, send fade down until released, or send a series of dims to the group appropriate to the degree of movement from center. That 1) avoids having to make repeated button taps, 2) acknowledges that you are adjusting the scene up or down, 3) recognizes that once devices hit maximum or minimum brightness, brightness of multiple devices with different start levels has changed relative to other members of the scene, and 4) remains true to the behavior you would see if you held a switch or keypad button. Alternatively, you could implement something similar to what Wes does in MobiLinc to indicate a 'scene brightness'--add up the levels of each member device, divide by number of modules, then show the average. Use the slider to send dims/brights/fades as described above relative to the degree of adjuster movement. Edited February 12, 2015 by fitzpatri8
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 How is this superior to changing the app and slider behavior to be consistent with normal Insteon operation? When you bring up a scene in your app, why not show the slider in the middle? If a user drags it toward the bright side, send a fade up until it is released, or send a sequence of brights to the group appropriate to the degree of movement from center. If the user drags to left, send fade down until released, or send a series of dims to the group appropriate to the degree of movement from center. That 1) avoids having to make repeated button taps, 2) acknowledges that you are adjusting the scene up or down, 3) recognizes that once devices hit maximum or minimum brightness, brightness of multiple devices with different start levels has changed relative to other members of the scene, and 4) remains true to the behavior you would see if you held a switch or keypad button. Alternatively, you could implement something similar to what Wes does in MobiLinc to indicate a 'scene brightness'--add up the levels of each member device, divide by number of modules, then show the average. Use the slider to send dims/brights/fades as described above relative to the degree of adjuster movement. Because if I have a light with a single dimmer on it I can use a slider - why shouldn't I be able to do the same with a 3 way circuit? It doesn't make any sense to not be able to have the same interface for a light that has multiple dimmers vs one that has a single dimmer. The bright and dim commands are great when you have a scene with different devices set at different brightness levels and you want to just raise or lower the brightness level by a predefined arbitrary amount. My app has the GUI to support this option too. But it makes no sense to me that I have a light switch that i can physically press and the light brightens, but if i virtually press it by sending it a command, nothing happens. It also makes no sense to me that there is no way to keep the dimmer values in sync or tell a group of dimmers to go to a specific value. They are supposed to be smart!
fitzpatri8 Posted February 12, 2015 Posted February 12, 2015 But it makes no sense to me that I have a light switch that i can physically press and the light brightens, but if i virtually press it by sending it a command, nothing happens. It also makes no sense to me that there is no way to keep the dimmer values in sync or tell a group of dimmers to go to a specific value. They are supposed to be smart! Insteon modules are smart. Here's how they work: If it is currently off and you tap a SwitchLinc's ON paddle, it 1) turns on the local load, using its local dim level and ramp rate, and 2) sends a 'Group On' command to linked responders. Responders react using the ramp rate and dim level defined when you created the scene. If it is already on and you tap a SwitchLinc's ON paddle, it 1) alternates between moving the local load to 100% instantly or back to its local dimmer setting, and 2) sends a 'Group On' command to linked responders. Responders react using the ramp rate and dim level defined when you created the scene. If you hold a paddle down, it sends a Fade Up or Fade Down to linked responders while you hold it. Dimmable responders brighten or dim from their current state. If you do a quick double-tap On, it turns the local load on 100 % instantly and sends a Fast On to linked responders. Fast On overrides local ramp rate and dim levels. If you tap Off, it turns off at the local ramp rate and sends a Group Off message to linked responders. Responders react using the ramp rate defined when you created the scene. If you do a quick double-tap Off, it turns the local load off immediately and sends a Fast Off to linked responders. If your app sends the same commands, you can do the very same things remotely. There is no 'keep synchronized' mechanism in the Insteon communications protocol, devices link as controllers or responders only. It is the responsibility of each device to listen for messages and respond as programmed.
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 Insteon modules are smart. Here's how they work: If it is currently off and you tap a SwitchLinc's ON paddle, it 1) turns on the local load, using its local dim level and ramp rate, and 2) sends a 'Group On' command to linked responders. Responders react using the ramp rate and dim level defined when you created the scene. If it is already on and you tap a SwitchLinc's ON paddle, it 1) alternates between moving the local load to 100% instantly or back to its local dimmer setting, and 2) sends a 'Group On' command to linked responders. Responders react using the ramp rate and dim level defined when you created the scene. If you hold a paddle down, it sends a Fade Up or Fade Down to linked responders while you hold it. Dimmable responders brighten or dim from their current state. If you do a quick double-tap On, it turns the local load on 100 % instantly and sends a Fast On to linked responders. Fast On overrides local ramp rate and dim levels. If you tap Off, it turns off at the local ramp rate and sends a Group Off message to linked responders. Responders react using the ramp rate defined when you created the scene. If you do a quick double-tap Off, it turns the local load off immediately and sends a Fast Off to linked responders. If your app sends the same commands, you can do the very same things remotely. There is no 'keep synchronized' mechanism in the Insteon communications protocol, devices link as controllers or responders only. It is the responsibility of each device to listen for messages and respond as programmed. I know exactly how they work. Keeping the LED in sync works fine as long as you are physically using the switch as you described. However, it's a whole different ball of wax though when you are sending commands from a an application to the ISY's REST interface (or even using the ISY's admin panel). If you tell the slave switch to dim to a certainly level, the load is not affected and the LEDs go out of sync. There is currently no possible way to adjust the brightness of a dimmable load with more than one controller and keep all the LEDs in sync to reflect the brightness of the load WITHOUT using a program external to the ISY.
Xathros Posted February 12, 2015 Posted February 12, 2015 (edited) There is currently no possible way to adjust the brightness of a dimmable load with more than one controller and keep all the LEDs in sync to reflect the brightness of the load WITHOUT using a program external to the ISY. You issue adjust scene statements to however many devices in the scene you want to change then issue a scene On command or issue direct ON commands the the member devices with whatever brightness you desire. -Xathros Edited February 12, 2015 by Xathros
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 You issue adjust scene statements to however many devices in the scene you want to change then issue a scene On command or issue direct ON commands the the member devices with whatever brightness you desire. -Xathros I'm not sure I follow you... What would the REST commands look like?
Xathros Posted February 12, 2015 Posted February 12, 2015 I'm not sure I follow you... What would the REST commands look like? Not sure on the adjust scene part as I've never done that via REST. The direct ON commands are simply: /rest/nodes/12 12 1F 1/cmd/DON/143 /rest/nodes/12 12 1E 1/cmd/DON/143 /rest/nodes/12 12 1D 1/cmd/DON/143 -Xathros
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 Not sure on the adjust scene part as I've never done that via REST. The direct ON commands are simply: /rest/nodes/12 12 1F 1/cmd/DON/143 /rest/nodes/12 12 1E 1/cmd/DON/143 /rest/nodes/12 12 1D 1/cmd/DON/143 -Xathros Ok, got you. 1F 1 is the Master and 1E & 1D are the slaves, then there's no reason to send a scene command at all. What drives me crazy about the insteon protocol is that sending /rest/nodes/12 12 1F 1/cmd/DON/143 is not the same as physically pressing the paddle and adjusting it to 143. You get two different results, meaning there is no easy way to emulate someone pressing the button with a script.
Xathros Posted February 12, 2015 Posted February 12, 2015 (edited) Ok, got you. 1F 1 is the Master and 1E & 1D are the slaves, then there's no reason to send a scene command at all. What drives me crazy about the insteon protocol is that sending /rest/nodes/12 12 1F 1/cmd/DON/143 is not the same as physically pressing the paddle and adjusting it to 143. You get two different results, meaning there is no easy way to emulate someone pressing the button with a script. That is because they are two entirely different actions. In the first case, the ISY's PLM is sending a DIRECT command to the ONE device in question. In the second case, the Device itself is sending a group command to all linked devices when you press the paddle. It's actually a very common to have this confusion with new users here. "Why when I control a device from the ISY does it not control the other devices linked to the device I controlled?" The difference is that the ISY and most other HA controllers are controlling the device with direct commands - not group/scene commands. If you were to analyze what happens when you brighten the scene by holding the paddle, you would see that the device is sending "Fade Up" then Fade Stop" to the group. You can do that same thing from your App via the PLM. The difficulty here is going to s specific brightness as that is NOT built into the protocol for a group command. -Xathros Edited February 12, 2015 by Xathros
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 That is because they are two entirely different actions. In the first case, the ISY's PLM is sending a DIRECT command to the ONE device in question. In the second case, the Device itself is sending a group command to all linked devices when you press the paddle. It's actually a very common to have this confusion with new users here. "Why when I control a device from the ISY does it not control the other devices linked to the device I controlled?" The difference is that the ISY and most other HA controllers are controlling the device with direct commands - not group/scene commands. If you were to analyze what happens when you brighten the scene by holding the paddle, you would see that the device is sending "Fade Up" then Fade Stop" to the group. You can do that same thing from your App via the PLM. The difficulty here is going to s specific brightness as that is NOT built into the protocol for a group command. -Xathros I know why it works that way. It doesn't mean it doesn't drive me crazy that theres not a way to set a specific brightness to a scene
Xathros Posted February 12, 2015 Posted February 12, 2015 I know why it works that way. It doesn't mean it doesn't drive me crazy that theres not a way to set a specific brightness to a scene Hmmm - Just noticed this in my notes: /rest/nodes/<node- id>/cmd/<command_name>/<param1>/<param2>/.../<param5> eg: /rest/nodes/<node-id>/cmd/DOF - turn off a device or a scene Insteon - /rest/nodes/<node-id>/cmd/DON/128 - turn on a scene to 50% This was copied from an older WSDK document an may be a typo. I have not tested this yet but will in a minute. -Xathros
fahrvergnuugen Posted February 12, 2015 Author Posted February 12, 2015 Hmmm - Just noticed this in my notes: /rest/nodes/<node- id>/cmd/<command_name>/<param1>/<param2>/.../<param5> eg: /rest/nodes/<node-id>/cmd/DOF - turn off a device or a scene Insteon - /rest/nodes/<node-id>/cmd/DON/128 - turn on a scene to 50% This was copied from an older WSDK document an may be a typo. I have not tested this yet but will in a minute. -Xathros I tried that before posting Let me know if you find a different result, but this is EXACTLY what I'm asking UD to support...
Xathros Posted February 13, 2015 Posted February 13, 2015 Hmmm. I replied to this around 4:30. Dunno what happened to my reply. Anyway, I tested and got the expected result- fail. Pretty sure that was a typo and should have read Device rather than Scene. -Xathros Sent from my iPhone using Tapatalk
Michel Kohanim Posted February 13, 2015 Posted February 13, 2015 Hello Xathros, thanks so very much. Indeed a typo. Hello fahrvergnuugen, Going back to relays within scenes: as you already know, those relays can their own on/off levels within scenes. So, you can send an On to the Scene and one relay may turn off. Anyway, and since - and with your impressive experience - I am sure you already know the risks of changing a stable, well tested, and understood function and all the regression and bugs that might be introduced. Unfortunately we cannot implement this for scenes. I have however created a product request (#168) to analyze what else we can do with minimal impact to existing operations. With kind regards, Michel
Recommended Posts