HomeSeer and CQC


Senior Member
Call me crazy if you want but here I go ;)

I have been missing my RFID system now that I have switched to CQC. IAutomate and CQC have discussed support but it sounds like it wont be in the very near future although it will happen one day. So I figured that I may just use HS and have a script write a xml formated file every few seconds with the RSSI data from my tags. Then I can use CQCs driver development tools to import that xml file in the form of useable data. The data will be in several seconds of delay probably because I wouldnt trust homeseer to update the files any faster but I could atleast use the data for display purposes.
It could be done. Does HS support any sort of socket connection to get data? That would work even better.

BTW, the thing with RFID is not on our side. The RFID guys have done the drivers for other systems themselves, because they don't want to expose their protocol, but they don't want to keep doing this over and over. So they are working on a 'black box' type of deal that all of the readers will attach to. It will digest all the info (of which there is evidentally a lot) and just put out the important conclusions like (Bubba is near reader 19) type messages.

So, we have to wait till they are done with this new widget before we can do a driver. I assume that they will want everyone to use this box, and that other systems would be expected to transfer over to it once they get it done.
I am not sure what a socket is so i can not aswer that for you. I would be using version 1.7 so perhaps someone else can answer that question for me. I do know 1.7 supports a COM connection which may be able to be used.
A socket meaning a TCP/IP socket, which in this day and age is almost the same thing as saying a network connection.
HS supports sockets when using the plugin written by Geoff (same guy that wrote the hsGirder plugin). Check the updater, it's a free plugin,and pretty powerful.
Yes, it is the TCP Manager plug-in. You can create up to 2 sockets with the free version, either TCP or UDP. I am currently using it in my HS setup te receive MBM data via MBM's syslog protocol.

Squintz, if you need any help with setting it up let me know.

Thanks everyone.... I guess its time for me to start learning about this plug-in and sockets.
Yes, that is it. I probably is still in beta, but I have been running for atleast 9 months without issue.

Actually, it was George Photakis that wrote the hsGirder plug-in. Geoff is Geoff Epstein who is now a HomeSeer employee.

I am a little confused about how this thing works.

Do I basically create a script like the example scripts provided with the manager and run those scripts from an event? Or do I uses the the startup.txt to register the script as a call back. Can you provide me with a few step by steps. I am not understanding how the socket is to remain open. I would like HS and CQC to have a constant flow. I really only need it to be one direction since the RFID is only one direction.

Since I don't know anything about sockets I need to know how I should format the data being sent. I assume it is just one big string of data that is sent so I would need to format it in a way that CQC could extract the data. But again I am not sure.

Can someone try to explain this stuff to me.
Working from memory here so dont quote me. ;)

First you need to decide on whether to use TCP or UDP and what port CQC will be listening on. Dean may need to chime in here. I think George provided examples for both TCP and UDP operation, if not my MBM script uses UDP.

Do I basically create a script like the example scripts provided with the manager and run those scripts from an event? Or do I uses the the startup.txt to register the script as a call back.

You will need to initialize your script from the startup.txt and shut it down from the shutdown.txt script. During initialization the script will insctruct the IP Manager to create the socket(s) for you. When the IP Manager receives data on your socket, it will callback to your script to inform you that data is ready to be received. You can also create events that will send data via your script out on the created socket.

Dean will have to provide you with the details on connecting and passing of data back and forth. Once you have that information it should be pretty straight forward.

If the data exchanged is pretty straightforward, then you won't have to really know anything about sockets. You can just do a PDL driver, which will hide all those details.

PDL doesn't have extensive text parsing features, else it wouldn't be simple anymore, so if you are going to pass back multiple values in a message, it would be a lot easier if they were in fixed size fields, so that you can extract each value from a known offset within the message.

If you need more complexity then you can do it in CML, but you'll have to deal with sockets, though they are still quite encapsulated and fairly easily to deal with. The GetASCIITermedMsg() and GetTermedMsg() methods will handle getting a terminated message out for you, and works in terms of either sockets or serial ports, so you don't have to know how to read sockets, you just need to create/destroy them when requested, and to write an outgoing message. There are existing socket based drivers to use as examples.