I'm using a W800RF32A to receive RF signals with HouseBot. I notice that I get a lot of false RF commands. These are due to collisions when more than one RF device transmits concurrently.
I did some experiments using two RF remotes pushing buttons at the same time. If I use the RF32.exe "W800 32Bit Data Decoder" program from the WGL web site I see mostly the proper commands as sent by the remotes along with indications of "Unrecognized/Corrupt Packet". If I observe the HouseBot Composite Property I see incorrect house/unit codes mixed in.
The protocol as described:
http://www.wgldesigns.com/protocols/w80 ... otocol.txt
Shows that byte 1 and byte 2 must be compliments and byte 3 and byte 4 must be compliments. If not then the command is probably corrupt due to collision or other interference.
Does the HouseBot plugin check for packet corruption? If not can it be changed to do this?
Thanks,
Mark
W800RF32A false commands
I don't believe it does check. If you could generate a Hardware Interface trace of this happening, it might help in getting to the root of the problem.Does the HouseBot plugin check for packet corruption? If not can it be changed to do this?
The W800 plugin code is a bit nasty, and doesn't align 100% with the spec that you referenced. It was written from the spec (roughly), but probably is due for a re-write if there are many more issues with it.
Scott
Could be. Since the W800 only sends the received RF commands to HouseBot, it won't effect anything unless HouseBot is specifically configured to handle the RF reception and act on it.Could this possibly explain why my lights are turning off and on all by them self?.?.?
If this is the case, I'd suggest looking in the history for the Property that is controlling your lights. See if it's changing at times when you don't expect.
Scott
Scot,
I managed to create a trace that shows the issue.
I used two remotes. One I always sent O1-Off which should produce the 4 byte sequence 28 d7 20 df. The other remote was sending M1-On which should produce the 4 byte sequence 00 ff 00 ff.
The trace shows many cases of other byte sequences received when pushing the buttons on the two remotes close to the same time. Sometimes the incorrect bytes are “ignored-debounced”. Other times they are interpreted as commands (occasionally as the correct command). At other times they produce the wrong command.
The remotes and motion detectors send the byte sequence multiple times for each button push. Unless the buttons are push exactly at the same time both valid commands are observed along with the corrupt ones created during the collisions from the overlapping transmissions.
Adding a check for valid commands by checking for the byte compliments should eliminate most of the corrupt ones. It is always possible that an occasional bogus one might get created that happens to pass this test but it should be extremely rare.
The debounce logic might be made slightly smarter by looking at only the valid commands and debouncing only the ones that match the previous accepted command during a debounce window. That would allow both the valid commands to be received even if they are close enough together to overlap for some of the transmitted byte sequences.
Hope this helps. Let me know if you want the trace file.
Mark
I managed to create a trace that shows the issue.
I used two remotes. One I always sent O1-Off which should produce the 4 byte sequence 28 d7 20 df. The other remote was sending M1-On which should produce the 4 byte sequence 00 ff 00 ff.
The trace shows many cases of other byte sequences received when pushing the buttons on the two remotes close to the same time. Sometimes the incorrect bytes are “ignored-debounced”. Other times they are interpreted as commands (occasionally as the correct command). At other times they produce the wrong command.
The remotes and motion detectors send the byte sequence multiple times for each button push. Unless the buttons are push exactly at the same time both valid commands are observed along with the corrupt ones created during the collisions from the overlapping transmissions.
Adding a check for valid commands by checking for the byte compliments should eliminate most of the corrupt ones. It is always possible that an occasional bogus one might get created that happens to pass this test but it should be extremely rare.
The debounce logic might be made slightly smarter by looking at only the valid commands and debouncing only the ones that match the previous accepted command during a debounce window. That would allow both the valid commands to be received even if they are close enough together to overlap for some of the transmitted byte sequences.
Hope this helps. Let me know if you want the trace file.
Mark
I added the complement validation to the logic. I don't have any way to test the scenario (I only have one wireless remote), but I've tested the normal operation and it doesn't seem to have broken anything.
You will need to copy the plugin DLL in the attached zip file into your \HouseBot\Plugins\Interfaces directory over the old plugin and then restart HouseBot. Let me know how it works for you.
You will need to copy the plugin DLL in the attached zip file into your \HouseBot\Plugins\Interfaces directory over the old plugin and then restart HouseBot. Let me know how it works for you.
Scott
Scot,
Works like a charm!!!
I see all the invalid commands being detected and not used in the trace file. I did get one command through that did not match what the remotes were sending. The collision just happened to produce a code were the bytes were compliments. There is nothing you can do to detect that. It took a lot of collisions get one. This is certainly not a normal occurrence.
I get quite a few RF commands at my vacation house because I use some x10 cams. They send out like five equivalents of a remote button push each time the cams are switched when scanning which happens once per minute. Add and occasional signal from a motion sensor and you’re bound to get a few collisions. It took me a while to figure out why my lights were coming on randomly. The collisions sometimes produced the same code as some RF light switches I use.
All fixed now!!
Thanks once again,
Mark
Works like a charm!!!
I see all the invalid commands being detected and not used in the trace file. I did get one command through that did not match what the remotes were sending. The collision just happened to produce a code were the bytes were compliments. There is nothing you can do to detect that. It took a lot of collisions get one. This is certainly not a normal occurrence.
I get quite a few RF commands at my vacation house because I use some x10 cams. They send out like five equivalents of a remote button push each time the cams are switched when scanning which happens once per minute. Add and occasional signal from a motion sensor and you’re bound to get a few collisions. It took me a while to figure out why my lights were coming on randomly. The collisions sometimes produced the same code as some RF light switches I use.
All fixed now!!
Thanks once again,
Mark
W800 collision
Hi Scott,
I'm delighted to hear you've got your baby back!
Please can you re-attach your modified W800 plug-in to this thread? I'd like to try it to see if it reduces the false signals my W800 picks up during the night - not fun when the lights starts acting up at 3 am
!
Thanks in advance.
Andre
I'm delighted to hear you've got your baby back!
Please can you re-attach your modified W800 plug-in to this thread? I'd like to try it to see if it reduces the false signals my W800 picks up during the night - not fun when the lights starts acting up at 3 am
!Thanks in advance.
Andre
Andre,
You can download the latest plugin dll here. You will need to manually copy the dll into your Plugins\Devices HouseBot directory and restart HouseBot.
You can download the latest plugin dll here. You will need to manually copy the dll into your Plugins\Devices HouseBot directory and restart HouseBot.
Scott
W800 collisions solved!
Thanks Scott,
This solved the problem perfectly - I was getting more than 300 false X10 commands, mostly during the night - so many in fact that I was about to disconnect the W800 permanently and try find a different wireless solution.
With the new DLL, there are now ZERO false commands.
Cheers,
Andre
This solved the problem perfectly - I was getting more than 300 false X10 commands, mostly during the night - so many in fact that I was about to disconnect the W800 permanently and try find a different wireless solution.
With the new DLL, there are now ZERO false commands.
Cheers,
Andre