I'm trying to write a ruby GSD template which you can use to monitor a motion sensor and control a light. It will be more advanced than the respond to events, as a resettable timer will be setup and things like overriding whether it's day or night automatically by detecting someone using the light switch to manually switch the light on, and disabling motion detected in rooms with media playing etc will be supported.

If I want to create a GSD which runs a bit of code when a sensor is tripped or light switched off, or MD starts playing media etc, then how is this achieved? The devices in question would not be children of the GSD so I'm not sure how to get it to look out for these triggers and respond by running ruby code.

Also, how can I add custom attributes to the configuration of my device and then reference these in the ruby code?

I'm trying to write a ruby GSD template which you can use to monitor a motion sensor and control a light. It will be more advanced than the respond to events, as a resettable timer will be setup and things like overriding whether it's day or night automatically by detecting someone using the light switch to manually switch the light on, and disabling motion detected in rooms with media playing etc will be supported.

If I want to create a GSD which runs a bit of code when a sensor is tripped or light switched off, or MD starts playing media etc, then how is this achieved? The devices in question would not be children of the GSD so I'm not sure how to get it to look out for these triggers and respond by running ruby code.

Also, how can I add custom attributes to the configuration of my device and then reference these in the ruby code?

Thanks,

Chris

Hi,

I'm also interested in your work. I probably won't be much of help, since I do most of my work in Perl, but will try to help as much as I can. What I'd think of this is to maybe start with a skeleton to more generic event/action parser and action triggering code in Ruby.

Well the basic start would be (as far as I remember reading posts from other Ruby developers - BTW DDamron used to be GSD Guru for us, but he's not present lately)...:- basically you would have to start a new thread that would continuously run (if you use Idle function in GSD device it's only callled every few seconds; I guess unusable for what we need) - I remember that Ddamron used this (perhaps we can find clue in GSD code he wrote - I think he has written multithreaded device driver in GSD and Ruby)- this thread should register with DCE router mainly as DCE message interceptor (there you can define which messages you will receive).- then I guess we would need some text formal form (maybe xml) to describe desired criterias and actions and then parse it and evaluate... something similar like knxweb and linknx are doing : rules written in xml gets displayed in this manner :

What I would personally like to do is some generic engine in Ruby, where I could easily access devices, device data, messages, events, database, timers and then ability to write simple if-then-else action code that will be executed... Something more flexible than web-admin events handler interface...

So you would prefer something which is external and registers with the core via two sockets for a list of devices we are interested in. Then we have a ruby MVC app which allows you to link triggers to reponses. This app should also be able to get information like names of devices from the database to make creating these things easy and offer some helpers to easily create rules.

Can anyone else comment on whether this seems like the correct approach?

It seems that the GSD should actually run the commands and the MVC web GUI should allow the user to define them. Or should the code which runs the commands be external and link to the core via sockets? I am now getting a bit confused as to what the best architecture would be...

While I for sure cannot tell you which architecture is "right", I am currently _trying_ to implement something similar using an external process, connecting to DCE router with two connections.

The main reason is that I find it easier to manage code in an external file, specially with vi over an SSH connection or running the device on a separate machine. It could also make multi-threading easier (though as Bulek said above, there have been examples of multi-threaded code in GSD).

What I am lacking at the moment is a clear view on how to access device data via the DCE. I have set it up so far via SQL queries, which is breaking away from the client/server model.

I have (had) that already working, using SQL queries to get the info, MessageSend to send the commands, and a ready-made library for jabber connectivity (well, that is until I made a stupid "rm" command on it recently and of course, no backup

Yet it was nice to switch lights on/off and query status from a mobile IM client on my phone

But I wanted to make it "nicer and cleaner" and re-implement fully using DCE. Maybe it's not worth the effort per se, but it's mostly for learning.

Well, the idea is that this would replace Misterhouse in my system, which currently connects via two socket connections. This setup has been heavily criticised in these forums so I am looking for guidance to replace with something people are more happy with and others may find useful. External code making 2 socket connections is therefore not the way to go it seems. What I need is someone with experience of Linux MCE to dictate the basic architecture to me so I can then get on and build the blocks needed to fit it all together.

Well, the idea is that this would replace Misterhouse in my system, which currently connects via two socket connections. This setup has been heavily criticised in these forums so I am looking for guidance to replace with something people are more happy with and others may find useful. External code making 2 socket connections is therefore not the way to go it seems. What I need is someone with experience of Linux MCE to dictate the basic architecture to me so I can then get on and build the blocks needed to fit it all together.

Regards,

Chris

Hi,

funny thing is we're going in opposite directions... You're replacing MH, I plan to go back and use it with LMCE. I just somehow cannot live without it... :-) .... Anyway I'm interested in your work on LMCE side, but also what you did on MH side... I think that MH is great test&run platform for trying new ideas and rapid prototyping things around smart home...

I see Thom's point. We have this Ruby framework and defined classes which expose DCE to the ruby code in a fairly simple way, so it seems silly to have an external Perl app which connects over TCP/IP to do messaging logic. But I really want to know what the best alternative is, as I think that having an external Ruby app connecting over TCP/IP is just the same!

I see Thom's point. We have this Ruby framework and defined classes which expose DCE to the ruby code in a fairly simple way, so it seems silly to have an external Perl app which connects over TCP/IP to do messaging logic. But I really want to know what the best alternative is, as I think that having an external Ruby app connecting over TCP/IP is just the same!

Regards,

Chris

Hi,

I'm not an Ruby and GSD expert, but don't understand, why you make such hard distinction between external and "internal" Ruby application. If you want to write event handler, you will AFAIK have to register message interceptor with DCERouter anyway (also all plugins function in this way) - but under your criteria this makes your application external... But it still is GSD and Ruby code.... Another story is how easy you can access device data, events and other needed DCE stuff. I currently don't know much about this matter and I'm curious if all this already exists and we need only some additional docs, or not...

What I really would like to know is whether GSD currently offer more that we know from docs or are there many things to add in code or documentation....

We should get to the point where all needed data, devices, events etc... will be easily accessed and handled within Ruby framework.

Quick note: look up the PLCBUS code in the wiki:That code has all my ThreadedRuby (I didn't find out until AFTER I coded it that PLCBUS can't handle threaded messages :/)I did comment the code, and it's a bit alpha-ish, but that might help.

Bulek, a note for your if-then-else,the threadedruby code is designed so you can put all your protocol dependant code in a seperate object. because of this, there are certain parts you need to implement:eg: sending a command to insteon, here's the steps:First, each command is an object consisting of a complete structure of data, and flags.

threadedruby intercepts the message from DCEchecks to see if its a response the other way around (eg: a command originating from GSD)when it does this, it passes the message to the device's object (to determine if it's a proper response)if not, it moves on to the next command object, etc, etc.if all that failes, (eg: it's not a proper response to any existing messages) then it creates a new command object, sets the direction, etc, and queues the command for transmission.

The nice thing about threadedruby is that the code for processing data is the same in both directions, ie DCE->GSD, and GSD->DCE.Both GSD and DCE have data to return to each other, and may not be particularly sync'ed up.

The goal of threadedruby was to allow multiple commands/responses to and from GSD/DCE.ThreadedRuby tracks all messages for you.