Scott,
Works great!!! Thanks for the quick response. Maybe that will fix this interface for some of the others that were having problems.
Mark
Fire Cracker SW interface not working properly
Scott,
Maybe I spoke too fast.
Or, Maybe I found an additional problem.
The Commands sent by FireCracker seem to be correct now but not all of them get sent.
I have a task that modifies the Power State property of five device. When I set the Hardware Interface used to control these devices to Fire Cracker and then execute the task, only two of the five state changes is sent out by the firecracker device. I observe this by looking at the history tab for the composite property returned by my CM11A.
I can work around this by adding delays between the property state changes but since these are used to switch active cameras for my project I would prefer as little delay as possible. There seems to be a problem with queueing of rapidly sent commands by the Fire Cracker interface.
Some of these cameras can only receive the on and off commands from an RF device like Firecracker. So, this prevents me from controlling them via the CM11A.
Thanks,
Mark
Maybe I spoke too fast.
Or, Maybe I found an additional problem.
The Commands sent by FireCracker seem to be correct now but not all of them get sent.
I have a task that modifies the Power State property of five device. When I set the Hardware Interface used to control these devices to Fire Cracker and then execute the task, only two of the five state changes is sent out by the firecracker device. I observe this by looking at the history tab for the composite property returned by my CM11A.
I can work around this by adding delays between the property state changes but since these are used to switch active cameras for my project I would prefer as little delay as possible. There seems to be a problem with queueing of rapidly sent commands by the Fire Cracker interface.
Some of these cameras can only receive the on and off commands from an RF device like Firecracker. So, this prevents me from controlling them via the CM11A.
Thanks,
Mark
Mark,
Try this one. I noticed that the X10 fake remote software was sending out the commands twice. Although the spec does not say to do this, I have modified the plugin to send the commands twice also. Let me know if it works any better for you.
Bob (Innovative), if you're still on this thread, you might want to give this a try also.
Try this one. I noticed that the X10 fake remote software was sending out the commands twice. Although the spec does not say to do this, I have modified the plugin to send the commands twice also. Let me know if it works any better for you.
Bob (Innovative), if you're still on this thread, you might want to give this a try also.
Scott
Scot,
I'm still noticing some issues with the Fire Cracker interface. On my fast computer test I was getting all five commands from my task described in my earlier post. When I tried it on the computer that is actually used to control my cameras I got only four. I can get it to run correctly if I insert a 500msec delay after issuing two property state changes. Then I can issue two more followed again by a delay. etc.
It seems that you may be issuing back to back commands too fast for the Fire Cracker interface to handle.
You said the X10 fake remote software was sending out the commands twice. If I observe X10 fake remote software by watching the composite property returned by my CM11A I see the two commands it sents out onto the house wiring. Now that you are issuing the commands twice I still only see each of them observed by the CM11A a single time. And if you send more than a few back to back some are missing altogether on my slower machine.
I think X10 issues more than one to help increase the odds that a command is not lost due to a collision caused by more than one x10 device sending to the power lines at the same time. They have an option on their Active Home software to issue duplicate commands for the same reason. If two controllers (like CM11A and a motion detector) both send a command on the wiring at the same time, both commands are corrupted and lost. The multiple transmissions help guarantee at least one gets through.
I think for your fire cracker interface to be reliable it may need to enforce a small delay between issuing commands to allow the Fire Cracker device to complete transmission before it receives the next command from you. That would eliminate the requirement for delays in tasks that issue more than one command. Also if multiple tasks are running concurrently there may be no way for us to insert delays between commands sent from the different tasks.
Mark
I'm still noticing some issues with the Fire Cracker interface. On my fast computer test I was getting all five commands from my task described in my earlier post. When I tried it on the computer that is actually used to control my cameras I got only four. I can get it to run correctly if I insert a 500msec delay after issuing two property state changes. Then I can issue two more followed again by a delay. etc.
It seems that you may be issuing back to back commands too fast for the Fire Cracker interface to handle.
You said the X10 fake remote software was sending out the commands twice. If I observe X10 fake remote software by watching the composite property returned by my CM11A I see the two commands it sents out onto the house wiring. Now that you are issuing the commands twice I still only see each of them observed by the CM11A a single time. And if you send more than a few back to back some are missing altogether on my slower machine.
I think X10 issues more than one to help increase the odds that a command is not lost due to a collision caused by more than one x10 device sending to the power lines at the same time. They have an option on their Active Home software to issue duplicate commands for the same reason. If two controllers (like CM11A and a motion detector) both send a command on the wiring at the same time, both commands are corrupted and lost. The multiple transmissions help guarantee at least one gets through.
I think for your fire cracker interface to be reliable it may need to enforce a small delay between issuing commands to allow the Fire Cracker device to complete transmission before it receives the next command from you. That would eliminate the requirement for delays in tasks that issue more than one command. Also if multiple tasks are running concurrently there may be no way for us to insert delays between commands sent from the different tasks.
Mark
Mark,
Try this version. It provides two new settings:
Try this version. It provides two new settings:
- Multi-Command Delay - Specifies the number of milliseconds that the hardware interface will wait between sending commands in quick succession. You can use this instead of trying to put delays in Tasks.
- Command Repeat Count - This is the number of additional times the Hardware Interface will send the command to the FireCracker. It will always send at least one command (if set to 0). I don't know if this will help at all, but it makes it a bit more customizable.
Scott
Scott,
Your new settings seem to work. I still don't see the more than one command sent from the fire cracker interface when I set the command repeat count to 1. If I set it higher I start to get additional commands but not as many as the repeat count would imply.
I got out my Oscilloscope and checked your software against some X10 software to measure the delays between commands. X10 inserts a delay of about 500 ms between the commands whenever they repeat them.
I tested repeating the commands via a task with multiple entries of the command and setting your Multi-Command Delay to insert various delays. I would consistently get the correct commands with a delay of at least 450 ms inserted.
Currently you delay is not inserted between the repeated commands but is sent between multi-commands.
If you add a 500 ms delay between all commands (repeated and multi) I think your interface will work perfectly.
You can decide if you want to leave in the option to vary the delay. But if you do I think you should set the minimum value allowed to 500 ms. I noticed the maximum value allowed is currently limited to 1000 ms.
Mark
Your new settings seem to work. I still don't see the more than one command sent from the fire cracker interface when I set the command repeat count to 1. If I set it higher I start to get additional commands but not as many as the repeat count would imply.
I got out my Oscilloscope and checked your software against some X10 software to measure the delays between commands. X10 inserts a delay of about 500 ms between the commands whenever they repeat them.
I tested repeating the commands via a task with multiple entries of the command and setting your Multi-Command Delay to insert various delays. I would consistently get the correct commands with a delay of at least 450 ms inserted.
Currently you delay is not inserted between the repeated commands but is sent between multi-commands.
If you add a 500 ms delay between all commands (repeated and multi) I think your interface will work perfectly.
You can decide if you want to leave in the option to vary the delay. But if you do I think you should set the minimum value allowed to 500 ms. I noticed the maximum value allowed is currently limited to 1000 ms.
Mark
Mark,
Here's another shot. I've moved the command delay inside of the command repeat loop. See how this works for you.
The "1000" limit is a current limitation in HouseBot, but it should be sufficient for this case. In version 2.0, this will be more configurable. The value will now default to 500, instead of 200.
Thanks for your patience in working this through.
Here's another shot. I've moved the command delay inside of the command repeat loop. See how this works for you.
The "1000" limit is a current limitation in HouseBot, but it should be sufficient for this case. In version 2.0, this will be more configurable. The value will now default to 500, instead of 200.
Thanks for your patience in working this through.
Scott
-
Innovative
- Member
- Posts: 6
- Joined: Wed Dec 24, 2003 5:26 pm