Device Paradigm

[skavan]

Hi all,

First off, let me precede my G4 comments by stating up front that I'm undoubtedly the 'new guy' here and probably have a lot less experience than the rest of you with both G3 and G4a.

I wanted to open up a thread on what I see (and it could just be ignorance) as a missing paradigm within girder.

When I look at g3 and g4, what I observe is a system that starts with the concept of Actions (Commands, Macros) and then moves to Events that trigger those Actions. Devices seem to be a concept that doesn't really shine through.
Said another way, it seems that the paradigm is:
1. Let's define something that we want done (i.e Turn a light on)
2. Let's define how to do that (Use an X-10 plgin and send it a code)
3. Let's define what triggers this action.

I guess, I approach this space from a home automation perspective with a more device centric view. i.e.

1. Define all my Devices (My Light, which has an ON||OFF)
2. Map actions to properties of the light (i.e. sending an X-10 on drives the property above)
3. Define Macros to do various actions (Turn on Light A, Turn on Light B)
4. Define triggers (At sunset, execute the macro).

So...a) What do others think - and/or am I missing something fundamental in the lens through which I'm looking at G4?

[Ron]

I am not exactly sure what you are trying to express, but the device concept is folded into the action concept. An action can work on a device, depending on what action you have. For example we (will ;-) ) have X10 actions that turn on your lights...

[Promixis]

As Ron said, the device concept is included in the action setup. In fact, I don't like the device centric approach of HouseBot or Homeseer. Girder is design to perform an action based on an event. The idea of having devices is at first intuitive but doesn't serve well over the long run. Lets assume we have certain lights we want to turn at sunset. Here, we want to have commands performed in response to an event. Not to think, I have a device, now when do I turn it on of off. In stead, we can do things the way we think, its getting dark, lets turn on some lights. And we don't have to lump them together as x10 lights, zwave, etc etc. We just setup a macro, include the desired lights, regardless of how they are controled, and then link the event.

In my experience, its the event that drives automation, not the device.

[skavan]

I think, where a device gets realy useful is in the presentation layer.
For example, you DO have the device concept fully represented in NetRemote.

Why? because the way we interact with the world is through ACTION on DEVICES.
Sometimes we can, as you suggest above, think solely of the action.
But other times, we interact with the device directly.

I guess what I'm hoping to find is a NetRemote concept - but exposed through COM, so that,, for example, I could use HTML (a la homeseer) to interact with my devices and actions.

I attach a flow chart with the two areas I'm talking about highlighted.

Think of the web pages that homeseer or housebot expose, and help me understand how I would mimic those...

Also see the screenshots in my post here:
http://www.promixis.com/phpBB2/viewtopic.php?p=114796&highlight=#114796
for another example.

I love this stuff and appreciate you guys debating this through.

Thanks.

Suresh

[Promixis]

Agreed, its interesting to debate how to approach automation. I am not sure that I would call NR a device orientated program. While you can represent a device on a single page, the more important functionality is designing pages that have actions you want. Ie. on my PPC, the button bedtime, tells Girder to turn on the security system and turn off all the mainfloor and basement lights.

However, when you want to get the status of say, x10 devices, then the device concept becomes useful. So although Girder knows about your X10 powerline device, it doesn't give you an easy to setup all the x10 devices attached to your system. This, however, is easily implemented in lua. I have found, though, that I have never done this (although I don't have a web page showing what lights are on or off). X10 just isn't reliable enough to be worth the effort.

As far as a COM object, luacom, allows you to create a com server that you could use to do this (but I haven't tried it)!

[skavan]

Mike (et alia),

I think the basic foundations of Girder will allow us to have our cake and eat it to.
While I don't disagree with your X-10 comments, it's reliability of X-10 isn't really the point. I think there is a great opportunity here to extend the Girder franchise to cover what HomeSeer, Housebot and others bring to the table. After all, most of the work in these systems is on the I/O side, which Girder has more than covered. On top of the Event I/O, all these systems really bring to the table are:

1. Device Management (i.e. displaying devices and mapping device items to actions and events)
2. Scheduling (at time x do y)
3. State relationships (if x occurs, do y -- more than covered by Girder)
4. Display functionality (i.e. Web interface to Devices, Actions)

Of these, 1 and 4 are what girder could easily replace (3 is in the bag already) leaving only 2 - which isn't the most complex thing in the world and if 1 and 4 were done - could easily be accomplished in a plugin.

So, now, in order: #1, Device Management.
The girder concept of nested groups and commands is really, really close to the capabilities required to handle devices.

Attached is a simple diagram of a device object model.
A device has one or more groups. A group has one or more sub-groups and one or more items. An item equates to a button or state of part of a device.
In girder speak, a device = a group. a group/subgroup = a group and an item = a command.
The power is all there, it just seems to be missing a few functions.
To handle this broader paradigm, a Group would need a extra properties (see the attachment) like:
Visible: Long 'Needed to facilitate UI presentation
GroupLevel: Integer 'Needed to facilitate UI presentation
Description: String 'Needed to facilitate UI presentation
DisplayMode: Long 'Needed to facilitate UI presentation
Flags: Long 'e.g are the items in a group Mutually Exclusive etc...
GroupType: Long 'DeviceGroup or normal Girder Group etc...

And a command would need a few extra properties (actually, an extra Tab could hold all of these):
DataType: Long 'i.e. Boolean (Radio) etc...
Default and Current Value: String
Value Max, Min and Step: String

Then there would need to be a couple of extentions on the event side.
- A group should be able to have an attached eventstring
(i.e. if this event happens, it affects the group, so process accordingly)
(case: Eventstring = InputSelected changes the states of the individual inputs of a receiver)
- Ideally an Item (Command) would be able to have a sub group.
(i.e. depending on the state of theparent command, children may be affected)
(case: selecting input=tuner on a receiver, enabled the "select station" group).

And that, I believe is it.

On the output side (#4), simple COM access to the Groups, Commands and Events would allow the programmatic (and very easy) creation of web pages and the like that show the state of the devices/actions etc... and allow for changes thereof.

With these capabilities, HomeSeer, Housebot and co. become unneccessary complications in life and the power of Girder underlies the whole darn system.

Whaddya think? Without this stuff, there will be a need for the home automation crew to pull all of this type of functionality into something above Girder - and then Girder becomes the I/O and event management hub only.

Apologies if this rambles or is confusing.

[Ron]

For group eventstrings look at conditional nodes, they control if a node is triggered based on some condition, currently that is Window Exists or Window Foreground.

[Ron]

I didn't get a chance last time to carefully read your posts, but I have to say interesting ideas. We will be thinking a great deal about these for the next major rev (4.1). We have to keep the feature creep at a minimum at the moment as we are trying to reach release :-)

[skavan]

OK - just wrote a whole post and seemed to have lost it - yeuch!

Anyway - I've been playing with the device paradigm and Girder for a couple of weeks now...I attach an XML file (renamed as a GML so I could upload it).
This is the XML for a simple receiver.

It is hopefully self-explanatory - and shows the nodes and attributed required to describe a device.

I have written a small program to xform the XML into DHTML (could have used XSLT - but too complicated for me). It was really pretty easy -- and a standard script library completes the code. I haven't attached the code and script yet...if people wnat it - no problem - just holler.

I attach a screenshot of the XFormer program that takes the XML and renders the DHTML.

All that is missing for this to come to life, is to get the ability to send Events and Payloads to Girder using COM, and a way to receive prcessed events and payloads from Girder using com.

Thoughts??

[Ron]

That looks great. You can create that Com server by using LuaCom. I don't have any experience with this myself though.

As I said before we are currently rounding off development, so we can't implement any major new features (this would be a major new feature ;-) ), however for the next major rev, we will definately consider this.

Thanks for thinking along!

[skavan]

Thanks for the feedback...
The whole Lua Com thing is a bit daunting to me - I couldn't really understand the docs very well - maybe I'll have a play and see what can be done...

What about that HomeSeer activex plugin that someone wrote -- it sends events to Girder and I believe captures events back...is it tied to HomeSeer only?

Is there any other pre-existing COM capability that I could leverage?

all I need is Event + payload form Girder to COM world, and Event + payload from COM world to Girder.

s.

[Ron]

Currently we only have COM to Girder not the other way around.

[skavan]

OK - one more question --- what's the most robust way (other than com) to send messages from Girder to an app - is it SendMessage to a (hidden) window - or is that less than robust? Or maybe there's another way of doing it?

s.

[Promixis]

ComServer