Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Pushing vs. pulling fields and events
#1
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
Reply
#2
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#3
Dean Roddey Wrote: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.
Reply
#4
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?
Dean Roddey
Software Geek Extraordinaire
Reply
#5
Dean Roddey Wrote: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.
Reply
#6
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#7
For the Bluetooth interface I'm using a .NET wrapper library (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.
Reply
#8
Dean Roddey Wrote: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.
Reply
#9
Jonathan Wrote: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).
Reply
#10
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?
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  CQC WebRiva not pulling up IVB 21 1,483 01-19-2018, 10:55 AM
Last Post: George M
  Scheduled Events? jkmonroe 9 839 01-06-2018, 09:08 AM
Last Post: Dean Roddey
  FailOnErr in events IVB 6 495 01-01-2018, 06:20 PM
Last Post: Dean Roddey
  Suggestion - Scheduled Events karenlee 2 793 05-10-2017, 05:37 PM
Last Post: Dean Roddey
  Lumagen Radiance fields missing dlmorgan999 14 2,911 02-18-2017, 11:04 AM
Last Post: dlmorgan999
  Field Check Box fields George M 2 905 01-25-2017, 04:14 PM
Last Post: George M
  Cant use fields of Denon driver in global actions George M 4 1,646 12-18-2016, 06:21 PM
Last Post: Dean Roddey
  How do I 'count' fields? jkmonroe 37 4,781 08-02-2016, 06:27 PM
Last Post: jkmonroe
  Persistent Fields Ron Haley 1 699 05-06-2016, 03:31 PM
Last Post: Ron Haley
  Logic Server Fields Limit zra 11 2,394 03-20-2016, 07:59 AM
Last Post: zra

Forum Jump:


Users browsing this thread: 1 Guest(s)