Pushing vs. pulling fields and events

[Jonathan]

Dean,

Suppose I wanted to monitor when I came home after dark and upon detection of this event I wanted to switch on the house lights.

To do this I would need to know that it was dark and that I was in "range" of the apartment. Given drivers and fields that provided that information I am confident that the event system as it stands today is able to process a rule of that nature. Half the battle is over :-D

The method I wish to use to determine if I am in "range" of the apartment is to use Bluetooth detection of my phone (ok, so I guess I'm really checking if my phone is in range but since my phone has yet to develop legs and walk on its own and I'm not yet ready to insert RFID tags in my body...)

To do the detection I have sucessfully written a small proof of concept C# application that that does Bluetooth polling and can determine when a new device has come into range and when one leaves. It runs as a standalone .NET service.

The last part of this solution is the method of connection from that application to CQC. I see two options:

1. "Pull" -- Write a socket handler on the C# application and a CML/PDL driver to poll for events from the application and place those into driver fields. This would definite work but it seems less than optimal.

2. "Push" -- Use the XML gateway from the C# application to push field values directly when they change due to detection of a new device entering or leaving.

The second option seems "cleaner" but I've only seen applications so far consume the CQC XML service to publish information (i.e. the viewer) rather than as a mechanism for pushing information into CQC.

From reading the documentation, the only way I can see this working is if I have a "dummy" driver that just has the fields I want to populate and then use the client application to send those values upon change via the XML gateway. Is this the right approach or should I go with option #1? Thoughts?

Thanks.

Jonathan

[Dean Roddey]

The best way would be to do a driver that makes that value available, and then use the triggered event system and just set up a triggered event that does what you want to do. It can be set up on to only trigger at particularly times (including at night or during the day) and when other fields are at particular values.

[bph]

The best way would be to do a driver that makes that value available, and then use the triggered event system and just set up a triggered event that does what you want to do. It can be set up on to only trigger at particularly times (including at night or during the day) and when other fields are at particular values.
So, if I have a driver that just creates a bunch of fields, I can set the value of those fields through the XML gateway? That would be exceedingly cool.

[Dean Roddey]

Youl could do that. It would be just like any other client writing to the fields. So how do you talk to the bluetooth stuff? Is it an SDK or something?

[bph]

Youl could do that. It would be just like any other client writing to the fields. So how do you talk to the bluetooth stuff? Is it an SDK or something?
I dunno about BlueTooth. But I can do all sorts of interesting things in C# and VB.net. For example, Honeywell has a full enviracom API already written, it might be simpler for me to write a wrapper in Visual Studio and have it push the values out than to redo all of their coding in PDL or CML.

I actually believe that if whatever interface(s) you use for CML and C drivers were documented "API"s, driver development would explode. I could write a driver for TV or my thermostat and export functions in a DLL in 1/10 the time of learning CML.

[Dean Roddey]

The gotcha you will always run into if you don't do a driver is that it has to be run as a service, since CQC's back end has to run even if no one is logged in. So if you make it a standard app, then it really suffers in terms of usability relative to a driver.

[Jonathan]

For the Bluetooth interface I'm using a .NET wrapper library (www.32feet.net (http://www.32feet.net)) that interfaces with the Microsoft Bluetooth stack and takes care of all the complexity and gives me a nice API to work with so I can basically call "DiscoverDevices" and get back a collection of device objects. All I then have to do is track what is new and what has dropped off each time I poll. I've had the USB bluetooth module sitting around for a while so I wanted to find a use for it!

It would be simple enough to add a basic socket server to the code so that a PDL driver could open the socket and read the events I create using a simple text protocol and that is what I'll do. The whole thing can run as a service so no one needs to be logged on.

To me I see the XML gateway as a bidirectional solution that looked like a more efficient way for "CQC" enabled custom applications to talk to the CQC server (and have the encryption and authentication advantages too) to send information rather than having CQC poll for it and having to setup both a PDL driver on CQC's side and write a comms server for the custom application.

Maybe this is something that could be enhanced in the future? For example, it would be nice to have a way from the XML gateway to do all the things a CML driver does such as set the field types (SetFields), increment the counters (IncNaks) etc. You might do it by defining a new CQC driver type in the manifest that just defined the moniker as a placeholder and CQC would know that the fields and data would be coming from an external application pushing via the XML gateway.

[bph]

The gotcha you will always run into if you don't do a driver is that it has to be run as a service, since CQC's back end has to run even if no one is logged in. So if you make it a standard app, then it really suffers in terms of usability relative to a driver.
Writing a service is not difficult in VS 2005. Neither is setting up an auto-logon. But if the functionality is exposed as exported functions from a DLL then it can run in the context of the calling program. Services load DLLs all the time.

For that matter it could be done as a web service, if CQC could consume web services.

[bph]

Maybe this is something that could be enhanced in the future? For example, it would be nice to have a way from the XML gateway to do all the things a CML driver does such as set the field types (SetFields), increment the counters (IncNaks) etc. You might do it by defining a new CQC driver type in the manifest that just defined the moniker as a placeholder and CQC would know that the fields and data would be coming from an external application pushing via the XML gateway.
I would make use of such functionality. (Although there are various other ways, too).

[Dean Roddey]

If the BlueTooth API in Windows isn't overly complex, the optimum thing would be to provide a CML wrapper around it to allow CML to access BlueTooth. Is there a separate SDK for that or are those APIs in the base platform SDK?

[Jonathan]

Yes, as of XP SP1 there is support for BlueTooth.

This post may make more sense to you since I don't code C++ but it doesn't look too bad?

http://www.lenholgate.com/archives/000102.html

[znelbok]

Did this go anywhere

Using bluetooth as a means of detecting the arrival/departure of someone is an idea that I like. My new car has a BT handsfree kit so I am hoping that I can use that to detect that the car has arrived in the garage and trigger actions on it.

Moving on from there, the use of mobile phones as an indicator of an individual person is a good next step.

Mick

[CouchPotatoe]

Just an alternative thought - There is a xAP application that already does the Bluetooth proximity detection and runs as a service - and I have a CQC xAP driver nearly finished , and so far working well.

xAP Blue from www.mi4.biz (http://www.mi4.biz)
xAP driver (based on Hitcocknz's code)... from me, real soon now

(edit) You got there before me - just responded to your Q re this in the driver forum .. xAP thread

[sic0048]

Did this go anywhere

Using bluetooth as a means of detecting the arrival/departure of someone is an idea that I like. My new car has a BT handsfree kit so I am hoping that I can use that to detect that the car has arrived in the garage and trigger actions on it.

Moving on from there, the use of mobile phones as an indicator of an individual person is a good next step.

Mick

I like the idea, but you may have problems implementing this in real life. If you can get the bluetooth discovery working in CQC, you still are going to have a basic problem due to the fact that the car isn't going to have the bluetooth on when the car is turned off.

So while the system might be able to correctly register when the car comes home, when you turn the car off, the blue tooth will turn off after a period of time I'm sure. So when you go back out to leave and turn the car on, it will turn the bluetooth on again, and the CQC system will discover it again. It will look like the car as arrived home again instead of actually leaving. This could cause big problems.

If you have an alarm system, perhaps you could write your actions so it ignores a bluetooth discovery for 5 minutes after the alarm is armed or something like that. But without some other event to trigger from I don't think you are going to make the bluetooth detection system smart enough to work with your car alone.

Just something to think about before you work really hard on making the bluetooth system work.

[Squintz]

BlueTooth in CML would be really cool.

[zaccari]

The advantage to using the XML gateway would be that you don't have to have CQC on the workstation but every workstation in the network could have a service that starts and registers data about bluetooth devices that it knows about.

While the CML wrapper is cool, this seems like one of those things that is better independent.

Russ...

[paul]

Wouldnt the distance from the bluetooth reciever to the car be a problem?
The best i could get out of a 100m dongle and be reliable is around 12m with one door and wall to get through.

[klindy]

I like the idea, but you may have problems implementing this in real life. If you can get the bluetooth discovery working in CQC, you still are going to have a basic problem due to the fact that the car isn't going to have the bluetooth on when the car is turned off.

So while the system might be able to correctly register when the car comes home, when you turn the car off, the blue tooth will turn off after a period of time I'm sure. So when you go back out to leave and turn the car on, it will turn the bluetooth on again, and the CQC system will discover it again. It will look like the car as arrived home again instead of actually leaving. This could cause big problems.

If you have an alarm system, perhaps you could write your actions so it ignores a bluetooth discovery for 5 minutes after the alarm is armed or something like that. But without some other event to trigger from I don't think you are going to make the bluetooth detection system smart enough to work with your car alone.

Just something to think about before you work really hard on making the bluetooth system work.

Well assuming it's a handheld mobile phone, the bluetooth connection would remain even after the car is shut off (unless of course the car increases the range of the system). So even if you shut off the car, the handheld bluetooth phone will still be detected.

I would think you'd have issues with the range regardless. I'd love to be able to use my blackberry in the same way but I can't even get my laptop to recognize my phone when it's inches away from it.

[bjkiller]

this idea very nice idea.

i found that bluetooth dongle (w/s&h) $2.55
http://www.dealextreme.com/details.dx/sku.11866

USB cable over CAT5 to door up to 150 feets (w/s&h) $15.17
http://www.dealextreme.com/details.dx/sku.6640

Bluetooth discovery and connection library libarary for .NET (free)
http://c4fdevkit.codeplex.com/

Now that somebody who familiar with CQC to write bluetooth proximity driver.