HouseBot

Hi Scott,



I would like to write a C# script device. I'm not a big fan of VBScript for lots of reasons.



Using HbControlMod.dll I can get and set many of the useful items in HouseBot. However, to have the power that is really desired, there needs to be a way to get asyncrounous notification of property changes from devices.



I can't find anything in the SDK that would provide property notification from any device. It is desired it to be able to do this just as a Task can?



I know when implementing a device a handle exist that can be signalled. After that the property value that changed can be pulled from the queue. However, this is not the level that I really want. The property change can abandoned or failed by the device. The real notification that is wanted is after the device device indicates a ChangeRequestCompleted.



How can this be done? Either allow registering a callback for a particular device property or provide a handle / queue contruct for completed properties or ???



I see that PROPERTY_HANDLE and PROPERTY_VALUE_HANDLE are not real Win32 handles that can be used with WaitForSingleObject.



Setting up a separate task for every property that desires monitoring is not a solution. I would produce very hard to follow logic and a poor design.



What is happening inside of tasks? Does the SDK have access to the correct handles?

csharp wrote:What is happening inside of tasks? Does the SDK have access to the correct handles?

The hooks that drive the Tasks are pretty tightly wired into the application. There aren't any handles that you can wait on to perform what you need.



The Device SDK/API will only receive Property Change signals on the semaphore handle that they manage themselves.



I'm not sure of the needs of the Device that you are looking to create. Are you wanting to just hook into another Device that is already running on the system, or create your own Device?



How about a new C++ Device that simply acts as a proxy to your C# code? It could send the info in a Windows Message or other form of IPC?? If it's something fairly generic and useful by other users, I'd consider writing it (since it sounds really simple :)), but I would need more specifics on what would work for you.

Jus like your VBScript device, I'd like to allow the user (me) to supply C# code to run as a script. Unlike the VBScript device, I would like to be able to receive notification of Property changes from any device.

The same type of conditions that a Task can watch would be desired.



This needs to be efficient mechanism too. It could be something that I access in the CSharpScript Software Device in C++ and forward onto the CSharp script itself that is supplied by the user to the Device. In C# this would likely be done with a delegate (nothing more than a type safe function pointer).



Suggest mechanisms: waitable event with queue, subscribe/unsubscribe to particular device properties. I'd prefer not to use Windows Messages because this will likely be done on a non-UI thread without a message pump.



I want to make this C# device to more directly handle richer logic. For instance a room occupancy control for the lights:



Input: motion sensor over room area (maybe multiple sensors for larger rooms)

Input: timer counting since motion last detected in room

Input: door open switch for each entry door (doors close, motion detected, someone is definitely in room)

Input: motion sensor in door way for each door (is someone entering/leaving room)

Input: room / house mode (sleeping, ignore motion)

Input: time of day (no longer likely sleeping, respond faster)

Output: automatically switch lights on efficiently without intervention



To do something like this requires monitoring inputs in real time and running logic that if pieced together using Task, Device, VBScript would be hard to build, debug, tune, and maintain. If I could get the Input notifications, it would be fairly straightforward in a single C# file.



Let me know what is possible Scott.



Thanks,



Derek

Derek,



I agree that a better solution is needed for some situations. Tasks are great because they're wired into the system and are evaluated without much overhead. However, they are very limited on what they can do. Devices (including the script device) don't have the same limitations, but suffer from not having the condition evaluation capabilities that Tasks do.



I really see two different issues here.

1. There's no way for Devices to be informed about Property Changes for properties that do not belong to them.
2. No support for C# Devices/Scripts.

I could probably add some kind of subscription/notification support to the current Device SDK to allow any Device to be notified of Property Value changes in any other Device. I could even create a C++ Device that allows you to select what Property Values you want to receive notifications for. The Device could then forward the notifications using [ fill in your preferred IPC method here ] to let external applications act on the information. But I don't know if that (or that alone) will really help you.



I've not had my cup of .net kool-aid just yet, so I'm at a disadvantage on offering too many ideas for the C# solutions. Maybe we can work at it from both ends and come up with a solution. Since C# isn't an interpreted language or supported by the Microsoft ActiveX scripting platform, I don't really see any way to simply add C# support to the current Script Device. It would be nice if MS had a similar ActiveX control (not the entire .net runtime) that I could create something similar for C#. I don't know of such a thing... do you?



Is it possible to compile a .net/C# Plugin using the existing SDK?

Scott,



As a C++ programer for 14years (back when it was a preprocessor front end for C), I assure you I don't like the tast of Kool-aid. But a good tool makes me more productive and creative. C# (and .Net) do provide that for me.

I could probably add some kind of subscription/notification support to the current Device SDK to allow any Device to be notified of Property Value changes in any other Device. I could even create a C++ Device that allows you to select what Property Values you want to receive notifications for. The Device could then forward the notifications using [ fill in your preferred IPC method here ] to let external applications act on the information. But I don't know if that (or that alone) will really help you.

Since I'm trying to build the scripting device, an API for getting these notifications would be better than having my device rely upon another device to supply the notifications.





MS does provide a way to compile C# code in .Net. I already have this part is working. I started writing it my self and then found another person had already done most of the work. So I'm try to addapting that.



My approach is to get a C++ device to call C# code to compile and execute the script. I have not had time to debug this yet. For lots of reasons (.Net specific that I could go into if your interested), this seemed simpler than trying to make a .Net/C# Plugin that the existing SDK would call directly.



I don't think I need your help if I only wanted to provide the same level of functionality that exist in your scripting device. However, processing property change events would make the system a lot more powerful and so I had to ask if support for this was possible through an SDK API addition?



Derek

Derek,



How about new Device APIs like:

• SubscribeToPropertyChange( const char* szDeviceName, const char* szPropertyName )
• UnsubscribeFromPropertyChange( const char* szDeviceName, const char* szPropertyName )
• PropertyChange(const char* szDeviceName, const char* szPropertyName, const char* szNewValue). This is an exported function in the plugin that would get called when any of the subscribed Properties change.

This is just the easiest and most obvious implementation. Would something like this work for you?

Scott,



This would work fine.



Is it correct to assume that these API strictly deal with Runtime state. As such, I need to Subscribe every time I run? Also if things crash during debugging, I don't have to worry about any messed up state on your side by my inablity to unsubscribe?



How costly is it to subscribe? Do I need to keep the number small or does it not really matter? If needed I could try to to inforce a limits.



I hope to have time over the Christmas holidays to complete this work. I don't know where it would fit on your schedule. Like I said, it would be the icying on the cake to be able to add this to the Device. I coudl get everything else working first then come back and add this later if you do not have time currently.



Will yall be setting up a means for people to share Device support with other users?



Thanks,



Derek

csharp wrote:Is it correct to assume that these API strictly deal with Runtime state. As such, I need to Subscribe every time I run? Also if things crash during debugging, I don't have to worry about any messed up state on your side by my inablity to unsubscribe?

It's easier to implement if it's a runtime registration. I think it makes it more dynamic and flexible for the Devices also. If the Device plugin crashes, it will probably crash the server as well, so it may be moot. However, it would probably cause some problems if this happens.

The Unsubscribe call is really just there for completeness. Since the subscription would be dynamic, it would automatically be unsubscribed when the app is closed. For most needs, you wouldn't even really need to call it. If you implement some exception handling, it might be a good idea to add the call to the handler.

How costly is it to subscribe? Do I need to keep the number small or does it not really matter? If needed I could try to to inforce a limits.

I was thinking of having each Property (internal to HB) have a list (probably an MFC CArray) of registered Devices. So registering will simply mean adding an internal Device object to an array. I wouldn't advise registering every property in the system, but I think it should support a fairly large list.

I hope to have time over the Christmas holidays to complete this work. I don't know where it would fit on your schedule. Like I said, it would be the icying on the cake to be able to add this to the Device. I coudl get everything else working first then come back and add this later if you do not have time currently.

I don't see it being much work for me really, so I could have it done soon. However, it will require a new HouseBot server. I'll need to send you a beta NDA if you want to work on this before the next release is available.

Will yall be setting up a means for people to share Device support with other users?

Yes. Eventually the 'MAID' system that is used to share Meedio Essentials contributions is supposed to be improved to add HouseBot support.