[_CODE_] ActiveRFID Plugin

Cheap RFID solution for Vera. This is now working reliably in UI2 and UI4 beta. Looking for people to test it.

[url=http://code.mios.com/trac/mios_activerfid/]http://code.mios.com/trac/mios_activerfid/[/url]

This is very tempting. I’m going to hold off doing this for the time being as I have multiple other projects on the go and I fear with a new baby around at the moment, the poor thing wont get to know she has a Daddy around :slight_smile:

I love home automation, but the irony of it is that despite whatever time it can save you in the long run, it really does suck up some time initially getting stuff working!

Have you tried to experiment with your scenes a bit to cover multiple transmitters? This is really a place where we need those conditional expressions in vera.

Have you got any other examples of things you are using this for? I think this would be most useful for people with Alarm panels etc that are tied to Vera.

Strangely, it’s very minimal setup, and you being savvy with serial on vera, it should take you no time.

Currently, I am just using 2 40m transmitters on a receiver plugged directly into Vera. I have two scenes triggered off either device to open and close the garage door. I will be adding a luup “and” scene to enable thermostat energy save mode if both devices are gone - probably do that this evening. The security system arm/disarm is probably the most productive concept.

I also have a keychain transmitter that I plan on using to play around with presence sensing around the house; hence my other posts about serproxy…

Its not so much the serial ports I’m worried about time wise, its hours I would then spend tinkering with it :slight_smile:

I also think this would be good for the garage door but I’ve been waiting nearly 3 months for ASI to get the relays back in stock :frowning:
The other things I have on the go are:

Zwave Garage door opening / closing (whenever I get the damn relay)
Patio awning to order, mount on the wall and hack it to work with zwave.
A Kwickset lock to fit.
Aeon energy monitor to fit to my Electrical panel
Etherrain sprinkler controller to install and then replace all my sprinklers (most are worn out), then re-seed my lawn.

After I’ve done all that, then I can see some RFID in my future :slight_smile:

Multiple transmitters on multiple receivers confirmed. Tested with an RSSI receiver plugged directly into Vera, and a standard receiver plugged into another computer on my network via @guessed’s IPSerial plugin.

This looks superb - great work. Once I’ve bedded down a few things with my setup I may look at adding RFID.

One question about how you’ve done your setup as I have come across a similar problem planning my own plugin. I notice you manually create each child object for the transmitters, and then assign them based on the ids found in the logs. Instead would it be possible to dynamically create these child objects as they are seen by the serial device? Would save tailing the file, although you might want it to be a setting to stop it adding ones you aren’t using.

@Klunket - that’s my next step - I’ve been considering different options - automatically adding child devices, or maybe just populating a parent (receiver) state variable with unassigned transmitters, and leaving it up to the user to add transmitters as needed.

But, until MCV adds built-in support for the pl2303, we are still stuck logging in ssh… or using the serial receivers and a supported IP-Serial device.

Automatic discovery of transmitters has now been added, tested in UI4, and committed on the code.mios.com page. Now, we just need MCV to build in support for the PL2303 (hint, hint). I’ll update the wiki with UI4 screenshots when I get some free time.

The next step is to add a “known transmitters” state variable, so transmitters can be deleted without being automatically re-added. Be careful though, if you delete the parent device (RFID receiver) without deleting the child devices (transmitters), and save in UI4, it gets stuck - I don’t think this has anything to do with the plugin.

Note, that the “Transmitters” state variable is no longer used, and has been removed.

This is brilliant - looking at your code has been very insightful about what is possible in Luup.

Is there a luup reference I am missing, or have you just trawled through the built in objects to see what is possible?

Also, I am trying a gutted version of your plugin in UI4 and I can’t see any of the variables you have defined - am I missing something? I was expecting them to just appear like in the UI2 screenshots.

The only state variable that should appear without actually installing the serial port device is ExpireTime. All other variables populate when you install the serial port device and link it to the RFID receiver device, and of course when new transmitters are found by the receiver. I have to make a change today that re-enumerates the id’s of the child devices on startup - with yesterday’s code mods, you’ll have a problem if you delete any transmitters other than the last one added. I will also add a time limit on addind unassigned transmitters - right now it’s set up to add a transmitter if it receives 10 transmissions during a single “uptime” of Vera - I will restrict it to 10 transmissions in 2 minutes.
Use the lua reference manual and the luup lua extensions on the wiki - that should give you all the info you need.

Both of these changes were implemented, tested and committed last night. I will update the wiki in the next couple days, and test exhaustively for the next week.

Woodsby, I’d like to help test all of your hard work. I’m still in the dark as to exactly how it is you’re using it though. Are the 40m transmitters mounted in your vehicles? If so, then 40m might be too much for me, or does it take a while for the system to respond so you want as much early detection as you drive up as possible?

I need more experience with serial and Vera so this might be a good way to get it. Can you explain some of your plans for using RFID, if not here then on your other post which I am having trouble finding, specifically range-wise, where the receivers get placed, smaller transmitters on key-chains possibly. Like I said I’m still confused, but intrigued and ready to spend a bit on this.

@shady, sorry for the delay - had a UPS blow-up to deal with the last five days…
Anyway, I bought a 40m transmitter for each car, opened them up, replaced the batteries with name-brand ones, wrapped the battery pack in electric tape to prevent them from becoming dislodged, and the sealed the transmitters using liberal amounts of liquid electrical tape ($5 at the hardware store). I mounted the transmitters inside the front bumper (behind the plastic bumper, away from the metal frame). In both cars, the bottom of the bumper has cutouts in it, so I was able to ty-rap the transmitters to the bottom of the inside of the bumper. I stretched the antenna out (left-to-right across the bumper) and ty-rap or duct tape it down. I wouldn’t place it inside the car, since the metal frame really interferes.
The plugin doesn’t take long at all when it finds transmitters, so the only delay i see is the z-wave delay opening the door. I would stick with the 40m transmitters - you don’t get nearly 40m with it through walls, and the RSSI receiver has shorter range if you go that route. I have a keychain version, but I haven’t played around with it much.
As for serial setup, I think the final release of UI4 will automatically find the USB version of the receiver. I have not had a chance to update the wiki, but the latest version of the plugin automatically finds transmitters and creates devices for you, so we will soon be able to just plug-and-play.
I don’t know what my plans are just yet. I placed a receiver in the bedroom, but what’s funny is the keychain is found by the RSSI receiver in the family room while standing outside, but is not found by the standard receiver when standing more than 10 feet away. It also seems that the 40m is found by the stardard receiver before it is found by the RSSI receiver. So, I have some playing around to do. I don’t know if the RSSI receiver will offer many benefits at this point, but I do intend to add “signal strength goes above/below” events… if I can.

One last note, I took @guessed advice, and bought a wiznet wiz112sr, and coincidentally enough, I can plug it right into the RFID board and fit it in the same enclosure - just a little bit of soldering involved. I just need to cut out for the network jack and power supply, but when I do, I will post instructions/pictures.

The wiki has been updated for UI4, with updated screenshots. These instructions are compatible with version 1.1.1029 (or later).

Is this so the receiver can link wirelessly via Wi-Fi to Vera?

This particular WIZnet (WIZ110SR) is for wired Ethernet-to-RS232… there are others that’ll do Wireless (WIZ6000) althought I haven’t tried them and, pricing wise, they’re about the same as buying the equivalent iTach Wifi RS232.

Thank you, I couldn’t find that exact part number on their website for clarification.

IMHO, I’m a little uncomfortable using the wired version, since it introduces another point of failure, especially if you’re not plugging the wiznet directly into a Vera eth port… I certainly wouldn’t want to use a wifi connection for this. I have the wiznet working and I am testing. I will say that putting the receiver on the back wall of the garage made range worse, probably due to the metal garage door. I will try to move it to the garage ceiling by the opener and see if it improves this.
On a different note, I have found a couple bugs, that I cannot intentionally reproduce. First, it seems that the “incoming” function (serial incoming) seems to start running before the startup function completes. @guessed (or anyone else), can you confirm if this happens with any of your plugins. One of the first statements in my startup function is to create a variable RFID_Data equal to “”. In the “incoming” function, I concatenate this variable with the next character received. I get an occasional error in the log that it’s trying to concatenate a nil value.
Second, I think very occasionally, it doesn’t correctly enumerate child devices, and one of my child devices isn’t indexed properly, so a new device is created.
I can fix the first issue with two lines of code, but it seems dumb to try to fix it instead of posting a bug report, if it is in fact happening.
The second, I can also fix by re-enumerating the child devices before adding new children, but I’ll spend a little more time trying to identify the problem.

It’s possible, but it would be unlikely I’d run into that case as each of my components [generally] will only tell me something (via [tt][/tt]) when I ask them to send me something.

The Alarm Panel is a little different, but someone would have to Open a Window Zone and/or Move in a Motion Sensor Zone during startup for me to see that behavior. Well, ok, Technically my Onkyo amp could as well, but I dont implement anything meaningful in it’s incoming block.

You’ll want to open a Ticket for that, since it really shouldn’t ever do that until the initializer is complete.

In the meantime, default the “local” to “” at the top, outside of all the functions…

@woodsby

Yes, I can confirm that the ‘incoming’ function gets called before the startup function completes. IIRC, my ‘solution’ was to move the code that instructs my external device (a Squeezebox Server) to send bytes to Vera to the end of the startup function.

We should file a bug report/feature request.