Using RFID to detect proximity and run TTS using voxcommando

[jitterjames]

Wonderfullllllllllllllllllllllllllllllllllllll Excellenttttttttttttttttttttttt

I test it already as well. Work perfect. I initally plan to do who is home function but you already helped. Nothing I can say, thank you soooooooooooooooo much 

Yes the next proximity is for mobile phone detection by either ping your mobile IP address at home or its bluetooth address. Look forward to seeing more fun using VOX on home automation. I love you guys 

Thanks manfaiho,

It is great to hear that it is working well.

Can you please tell us what command line program you used to detect bluetooth presence?

[manfaiho]

Hi James, I download the source code of BtProx from http://btprox.sourceforge.net/

".....It locks on one of your Bluetooth devices which are paired to the the machine. When you walk away from the computer the device is disconnected and the computer is locked after timeout. It is possible to run a single application together with the lock. This application may be your favorite script dismounting network drives, erasing those dirty files from the desktop or anything else. The program sits in Windows tray showing its current status with tray icon and tooltip baloons...."

I think you can modify it as your bluetooth detector then trigger waht you want. Once you integrate it into VOX, please kindly let us know. Many thanks, James 

[manfaiho]

Hi James, I found some issue for this program in these days. When the Python code run for a while and I turn on all tags, no events are triggered. Once I use FullRestart to restart VOX, all tags near to Reader can be detected, its information can be sent back to the Python code and events can be triggered again. I can reprod it at least one time per day. Not sure why.

As I restart VOX can help, I try to find a way to run VC.RestartFull in regular basis using SetTimer. I found VC.RestartFull is not same with I click the menu item for Full Restart becasue I didn't see Python code is started in the log again. What's the difference between VC.RestartFull and click Full Restart? Besides, is it something wrong in Python engine when I heavily send TCP command (1 request/sec) to its TCP server within Python? Thanks.

Best regards,
Fai

[jitterjames]

RestartQuick detects which groups need to be updated and rebuilds them.  It then reloads all the command macros.

RestartFull purges the cache and rebuilds all groups from scratch and then reloads all groups and all command macros.

Usually you would use an action to perform a GenXML and then to a RestartQuick to update any groups that are affected by the changes to the xml files.

Neither one actually restarts the program itself.

What is the final python code that you are using?

If an error occurs on a thread the thread will quietly die without generating any error so it can be difficult to troubleshoot.  It is unfortunate that you cannot set a longer delay between RFID pings.

[manfaiho]

I think it may be the problem. When I found it can't properly detect the tags in and out, I click Full Restart VOX that can resolve the problem. All in-range tags can be detected normally. Anything I should do? Should we include exception handling on this code such as the logic like close all threads then create all new threads to listen and time watch it again that is same for Full Restart. Or generate more informaiton for debugging? 

[jitterjames]

What is the final python code that you are using?

?

I think it may be the problem.

You think what may be the problem?

[manfaiho]

I am still using the code you post on the last (thread safe one to protect data). I think the code may really got the error somewhere that as you mention so that it quietly die. Nothing it can continue to do that's my case. No tag can be detected until I restart VOX.

[jitterjames]

Hmmm.  I am no expert in python, but I tested that code using many pings per second.  I only let it run for a short time though.  I would need to set up a more rigorous test to try to recreate the problem.

One thing that you can try is to set the delay of the "cleanup" loop to a longer period to reduce the chance of a collision.

[jitterjames]

It is probably getting some other message that has no 6th byte to read and failing on that.

Here is the same code but with some "try / except" added to it.

[manfaiho]

Hi James, thank you very much  You are so helpful.

I will test it and get back you the result.

However, I found one more issue. As it is a 2.4G RFID, I occasionally found unexpected signal comes from somewhere that accidently triggers the arrvial event then immedidately departure after its timeout. I am thinking if the code can be enhanced to add one more counter which can count how many times the Tag is continuous in the range, say continuous 2 or 3 times to confirm if it is valid or not. If the continuous 2 or 3 times for this tag in the range, it can normally trigger the arrival event in order to avoid fault alarm.

Best regards,
Fai

[manfaiho]

Hi James,

I got the problem. I found suddently the arrvied tages are departure then trigger tcp.error then all of those tages are arrival again. Screen attached.

[jitterjames]

It looks like the tag reader is actually sending some message to tell you that the tags have departed.  So I think there is something in the protocol that we have not been told.  Time to pull out the manual, or whatever documentation was provided, to see what message is sent when someone leaves.

Either that or you can try logging the messages yourself and trying to understand what messages are being sent under various circumstances.

If there is any documentation for this product in English please send me a link.

[jitterjames]

Try with this py file.  It first checks to make sure the first byte of a new tcp message is /xFB

It will create a file "pyLog.txt" in the main VC folder and log every message received to it.

If you can recreate the problem with the IDs reappearing after departure, then we can look at the log file to see what message is making that happen.

[manfaiho]

Thanks, James. I install and run a while. I found all tags would suddently be departed simultaneously but this one is no tcp error. The log I see the last stream is just only FB then nothing else. All program stopped there. No tags are detected anyway. I need to restart it back to normal. It is different with before. Las time, once all were departed then I got TCP error then the program can be resumed and all tags can be detected automatically. Any clue?

I am thinking if something wrong in reader then it suddently sent only one byte: FB then nothing else but it can continue a normal stream. When the code trys to get the rest of bytes after FB then got buffer error. Should we check the stream length or exactly data pattern to ensure a complete stream? Every time I got this problem, it can resume normal when VOX app is fully restarted (not VC.FullRestart which will not work so it should crash internally). No idea?

[manfaiho]

Hi James, I checked the logs and found TCP data stream may contain many tag information being detected from reader. That may be the reason why I have occasionally observed some tag suddently departure then immediately arrival. We may need to get the data using the concept of serial communication in TCP, byte by byte check to ensure every tag information within the predefined length of byte can be retrieved. Not sure if it is also the cause we crash the buffer in tcp sometime. Any idea, James? I attached the sample from manufacturer for your reference. They only detect the frquency of tag arrival instead of the logic of arrival and depature. It looks like the reader should have no concept of departure, just stop to report its infomation of tag which is not in-range right after.