All -
I would like to control the dim level of two X-10 lights by using the preset dim X10 codes.
I have been able to set up a script that obtains the desired dim level (0 - 31) by using GetPropertyValue.
However, what I'd really like to do is invoke this script to set the dim levels of the two lights whenever the slider itself is adjusted. Right now, I set the slider to the value I want and press a second button to invoke the script (which basically reads the value of the slider and sends it to the two lights).
Any way I can get this script to invoke directly after the slider is adjusted without having to press a 2nd button? The only way I can see a task executing is when a condition tests an absolute value (e.g a specific quantity) but I would think that the slider would have an arbitrary value so there is no specific value I can test for in order to invoke the script.
One other thing, in the script, I have two SetPropertyValue commands in adjacent lines. So why is there a delay of roughly 2 seconds between the sending of the preset dim command to the first light and then to the second light? Can this be shortened?
Suggestions?
TIA.
Using Sliders to control two lights
-
loo_hoo_ser
- Member
- Posts: 83
- Joined: Sat Oct 30, 2004 4:16 pm
Here's what you can do.
If you are setting both lights to the same level always, one easy way around this is to set them both to the same unit and house code so they respond to the same commands. Doing this would actually eliminate the need for the Task entirely, since you could have the slider directly change the X10 Preset Dim value for the light(s).
- Create a Null Device and add a Property for the light level (You could use an X10 Preset Dim Property if you want).
- Have the slider change the new Property value of the Null Device.
- Create a Task that has a condition on the new value. It's a little strange, but set the condition to Not Equal something it will never equal. So if you're using X10 Preset Dim as the PV, you can set the value to 9999. This will cause the Task to get executed anytime the value of the Property changes.
- For the action of the Task, change it to set the state of your script to Running.
- Have the script pull the new Property value and sent it to the lamps.
If you're sending two different commands, the Hardware Interface will delay a bit to make sure the transmission is complete before sending the second. X10 is very slow, so you may see a delay (what interface are you using?).One other thing, in the script, I have two SetPropertyValue commands in adjacent lines. So why is there a delay of roughly 2 seconds between the sending of the preset dim command to the first light and then to the second light?
If you are setting both lights to the same level always, one easy way around this is to set them both to the same unit and house code so they respond to the same commands. Doing this would actually eliminate the need for the Task entirely, since you could have the slider directly change the X10 Preset Dim value for the light(s).
Scott
-
loo_hoo_ser
- Member
- Posts: 83
- Joined: Sat Oct 30, 2004 4:16 pm
Scott,
Many thanks for your fast reply! That did the trick. I had actually figured out #1 and #2 but was a bit stumped in figuring out #3 of your suggestion. I did see a variation of your suggestion elsewhere in the forums but it didn't click in my head. Now it makes sense. What is happening is a change is taking place but it will always execute the task for any value for the slider. Just what I wanted. Now I can wiggle the slider and the lights will respond.
I am using the Powerlinc hardware interface (X10 lamp modules). To answer your question why I didn't set the lamp modules to the same house and unit code is because I wanted them to remain independent - I can control one, the other or both. Same for 3 or more lights. The other thing I can do to speed things up is to take advantage of scene programming by having the X10 modules instantly respond to a scene change (provided they're members of the scene).
However, not all my modules support scene programming - hence the reason why I wrote the script, to support non-scene capable X10 units.
All I need is a plug-in to bridge HB and Essentials and I'll be in automation nirvana! Kudos to your work on Housebot!
Again, a big thanks!
Many thanks for your fast reply! That did the trick. I had actually figured out #1 and #2 but was a bit stumped in figuring out #3 of your suggestion. I did see a variation of your suggestion elsewhere in the forums but it didn't click in my head. Now it makes sense. What is happening is a change is taking place but it will always execute the task for any value for the slider. Just what I wanted. Now I can wiggle the slider and the lights will respond.
I am using the Powerlinc hardware interface (X10 lamp modules). To answer your question why I didn't set the lamp modules to the same house and unit code is because I wanted them to remain independent - I can control one, the other or both. Same for 3 or more lights. The other thing I can do to speed things up is to take advantage of scene programming by having the X10 modules instantly respond to a scene change (provided they're members of the scene).
However, not all my modules support scene programming - hence the reason why I wrote the script, to support non-scene capable X10 units.
All I need is a plug-in to bridge HB and Essentials and I'll be in automation nirvana! Kudos to your work on Housebot!
Again, a big thanks!
The usb powerlinc plugin will query for the switch status after it sends an command (I don't remember why I did that...). If the switches send status back, it will add a noticeable amount of delay when sending commands quickly.
If you turn on the tracking for the Hardware Interface, it may shed some light on what is happening.
If you turn on the tracking for the Hardware Interface, it may shed some light on what is happening.
Scott
-
loo_hoo_ser
- Member
- Posts: 83
- Joined: Sat Oct 30, 2004 4:16 pm
Controlling amount of delay between X10 commands
Scott,
I wanted to touch upon the delay issue between two successive X-10 commands mentioned earlier in this thread. I don't know where is an appropriate question to ask this except it's been mentioned already in this thread.
Is there any way that the delay between successive X10 commands can be changed? I understand that you have intentionally put in a delay for the sake of sending clear commands but I think it is far too slow. Could the delay be at the user's discretion - it doesn't do any harm if the delay is too short, the system won't work and the user can adjust the delay until the system works reliably. One house may be different from another in terms of powerline quality.
The reason why I bring this up is I have an X10 controller that responds to the doorbell and it flashes the lights very quickly. When I try to do the same thing in Housebot, it is far too slow (On-Off-On-Off) to be of any value (roughly 4 seconds).
If the delay is built in, can it be adjusted and how? If not, could this feature be in the next version?
If the delay is a result of overhead (e.g. script processing) then I suppose there needs to be some work done in that area!
I wanted to touch upon the delay issue between two successive X-10 commands mentioned earlier in this thread. I don't know where is an appropriate question to ask this except it's been mentioned already in this thread.
Is there any way that the delay between successive X10 commands can be changed? I understand that you have intentionally put in a delay for the sake of sending clear commands but I think it is far too slow. Could the delay be at the user's discretion - it doesn't do any harm if the delay is too short, the system won't work and the user can adjust the delay until the system works reliably. One house may be different from another in terms of powerline quality.
The reason why I bring this up is I have an X10 controller that responds to the doorbell and it flashes the lights very quickly. When I try to do the same thing in Housebot, it is far too slow (On-Off-On-Off) to be of any value (roughly 4 seconds).
If the delay is built in, can it be adjusted and how? If not, could this feature be in the next version?
If the delay is a result of overhead (e.g. script processing) then I suppose there needs to be some work done in that area!
-
loo_hoo_ser
- Member
- Posts: 83
- Joined: Sat Oct 30, 2004 4:16 pm
Scott -
I wrote my reply before reading your reply regarding HB having USB Powerlinc query the status after each X10 command. Is it at all possible to have a X10 command sent out without a status request being issued?
In the example of my lights in the previous post, all the units are 1 way lamp modules so there would be no status returned. It would be pointless to do a status request. If this step could be elminated as an option, would it speed things up? For example:
Or something like that?
I wrote my reply before reading your reply regarding HB having USB Powerlinc query the status after each X10 command. Is it at all possible to have a X10 command sent out without a status request being issued?
In the example of my lights in the previous post, all the units are 1 way lamp modules so there would be no status returned. It would be pointless to do a status request. If this step could be elminated as an option, would it speed things up? For example:
Code: Select all
SetPropertyValue("USB Powerlinc Interface.Status Request After Send", "Off")
SetPropertyValue("Lamp Device.Power State", "On")
SetPropertyValue("Lamp Device.Power State", "Off")
SetPropertyValue("USB Powerlinc Interface.Status Request After Send", "On")
Or something like that?
I wanted to see your trace first to see if the status request was really the hold up. I don't really want to start implementing a lot of stuff that won't even fix the problem. So if you could generate that trace for me, I can look at some alternatives.
The status might not even be the issue. There are two other possibilities. One is that the powerlinc itself isn't sending the commands due to congestion on the power line. You might see this from noise, repeaters, etc.
The other possibility is that some of the plugins internal timing might be slowing you down. Most of the internal timing is sensitive and changing it might really hose the transmissions. If you want to try and tune it to see if you get any improvement, I can build a special version that you can alter these values via the registry. PM me with the email address that I can send the test plugin to if you want to try that.
I use the same X10 interface myself, so it's also in my best interest to speed it up as much as possible.
The status might not even be the issue. There are two other possibilities. One is that the powerlinc itself isn't sending the commands due to congestion on the power line. You might see this from noise, repeaters, etc.
The other possibility is that some of the plugins internal timing might be slowing you down. Most of the internal timing is sensitive and changing it might really hose the transmissions. If you want to try and tune it to see if you get any improvement, I can build a special version that you can alter these values via the registry. PM me with the email address that I can send the test plugin to if you want to try that.
I use the same X10 interface myself, so it's also in my best interest to speed it up as much as possible.
Scott
-
loo_hoo_ser
- Member
- Posts: 83
- Joined: Sat Oct 30, 2004 4:16 pm
Scott,
Sorry that it took me a while to generate a trace log that was usable. I'm new to HB so I had to figure out how to get the trace output you were looking for. I believe you wanted the trace data on the USB powerlinc interface itself so here it is.
Also, the wife was a bit tired of watching the lights go on and off while I was playing with the scripts and testing HB. I had to pull this trace off by dimming the lights just a smidge in the hopes she wouldn't notice but I think she just humored me, as usual.
The trace log that I've posted shows that the USB powerlinc IS indeed putting out a status request after each preset dim command. There does not appear to be any slowdown due to retry attempts (assuming that event is logged if it occurs).
As I mentioned earlier in this thread, it would be nice if the status request was optional (e.g. another settable property item that could be changed before issuing any X10 commands). And if there is a delay element that could be adjusted to send the commands out quicker, that would be good as well (again, another settable property element in the USB powerlinc interface.
Let me know if you need more detailed trace data or what I've provided is not what you're looking for and I'll load up the tranqs and knock out the wife next time while I play with the lights.
Sorry that it took me a while to generate a trace log that was usable. I'm new to HB so I had to figure out how to get the trace output you were looking for. I believe you wanted the trace data on the USB powerlinc interface itself so here it is.
Also, the wife was a bit tired of watching the lights go on and off while I was playing with the scripts and testing HB. I had to pull this trace off by dimming the lights just a smidge in the hopes she wouldn't notice but I think she just humored me, as usual.
The trace log that I've posted shows that the USB powerlinc IS indeed putting out a status request after each preset dim command. There does not appear to be any slowdown due to retry attempts (assuming that event is logged if it occurs).
As I mentioned earlier in this thread, it would be nice if the status request was optional (e.g. another settable property item that could be changed before issuing any X10 commands). And if there is a delay element that could be adjusted to send the commands out quicker, that would be good as well (again, another settable property element in the USB powerlinc interface.
Let me know if you need more detailed trace data or what I've provided is not what you're looking for and I'll load up the tranqs and knock out the wife next time while I play with the lights.
Code: Select all
Nov 19 2004,08:02:33PM,Task Block,Audit,"Task [Execute Light Change] Condition Met: [X10 Preset Dim Level] Value [9999]"
Nov 19 2004,08:02:33PM,Task Block,Audit,"Task [Execute Light Change] requesting change of [Dual Lights.ScriptState] to [Running]"
Nov 19 2004,08:02:33PM,Task Block,Audit,"Task [Execute Light Change] Wait satisfied. Property [Dual Lights.ScriptState] = Running"
Nov 19 2004,08:02:33PM,USB Powerlinc,Debug,"--> Getting Status"
Nov 19 2004,08:02:33PM,Task Block,Audit,"Task [Execute Light Change] Wait satisfied. Property [Dual Lights.ScriptState] = Stopped"
Nov 19 2004,08:02:33PM,Task,Audit,"Task [Execute Light Change] Complete"
Nov 19 2004,08:02:33PM,USB Powerlinc,Debug,"Received 9 bytes of Data from PowerLinc USB [00 80 11 00 05 0d 00 00 00]"
Nov 19 2004,08:02:33PM,USB Powerlinc,Debug,"--> Getting Status"
Nov 19 2004,08:02:33PM,USB Powerlinc,Debug,"Received 9 bytes of Data from PowerLinc USB [00 80 11 00 05 0d 00 00 00]"
Nov 19 2004,08:02:33PM,USB Powerlinc,Debug,"SendPresetDim() (1) Writing Data to PowerLinc USB [00 00 04 01 00 00 00 00 00]"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"SendPresetDim() (2) Writing Data to PowerLinc USB [00 00 06 64 00 00 00 00 00]"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"--> Getting Status"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"Received 9 bytes of Data from PowerLinc USB [00 80 15 00 05 0d 00 00 00]"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"--> Getting Status"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"Received 9 bytes of Data from PowerLinc USB [00 80 15 00 05 0d 00 00 00]"
Nov 19 2004,08:02:34PM,USB Powerlinc,Debug,"--> Getting Status"
Nov 19 2004,08:02:35PM,USB Powerlinc,Debug,"Received 9 bytes of Data from PowerLinc USB [00 80 11 00 05 0d 00 00 00]"
Nov 19 2004,08:02:36PM,USB Powerlinc,Debug,"SendPresetDim() (1) Writing Data to PowerLinc USB [00 00 04 02 00 00 00 00 00]"
Nov 19 2004,08:02:36PM,USB Powerlinc,Debug,"SendPresetDim() (2) Writing Data to PowerLinc USB [00 00 06 64 00 00 00 00 00]"