Coding an Automatic Lighting controller in GSD

[chrisbirkinshaw]

So I've started to try and program a DCE device to do some automated lighting logic in Ruby. My idea is that you add the device, tell it which room it's in, and then it uses security sensors in that room and knowledge about the watching media state etc to control the lights. You should also be able to specify a delay period for the counter, after which period of no movement your lights are turned off.

I know you can register for commands from child devices, but how do I register for commands from non-child devices and run some ruby code when this happens? As a first test I want to create something which looks for certain commands being executed and then does something in response.

Thanks,

Chris

[hari]

you want to re-implement the lighting plugin in ruby?!?

br, Hari

[bulek]

Hi,

well those thoughts also cross my mind very frequently.

Let me explain :
- we currently have plugins that are coded in C++ and do whatever they do. Their behavour is hardcoded and barely settable by any settings. And also, it's quite hard to change their behavour, cause you have to be experienced C++ and LMCE programmer to do anything with it...

- on the other hand majority of us need somekind of custom determined behaviour and a lot of users probably feel quite incompetent to do anything useful (including my self from time to time).

EXAMPLE: the most obvious example of above thoughts is that your light comes up, when you start watching media and sun is shining happily through your living room windows. I know, you can try to change that behavour, but this task is certainly beyond ordinary user.... And in those eyes LMCE is pretty useless if disregards day or night.... :-)

Let me stress some similar program with some similar community. Misterhouse is not similar to LMCE, but is useful backend where any average user with some newbie knowledge of Perl can contribute useful things, modules and change behavour of the system according to his needs.... What is the secret ? Simple, they have pretty well prepared easy code access to all needed info, objects, their data, events in system, etc... - so user writes just simple if-then-else behaviours without digging into internals...

And sadly this is the state where LMCE is nowhere near that... What we would need to have is basically remove that behaviours from hardcoded plugins (except maybe those that are really needed) and then try to prepare everything in GSD and Ruby way (so user could write minimal code with easy access to objects, data, events , etc...).

GSD is the best example of this, now we need something like GSD for event handling and simple behaviour coding...

If still disagree, try to compare how many GSD devices were contributed and how many changes were done in plugins... And this is the key, we could have a lot of users contributing and working on similar features as are currently present or missing from plugins, if we make that step...

Of course, I'm willing to help as much as I can, and there is one thread where one user is trying to do so. But a push from Ruby and GSD gurus would be really helpful... I guess this will be easier that we think (Ddamron did nice example skeleton for device driver in Ruby, we need similar for event/state/action programming).

DDamron, if you're around please tell us if you can help with this and have some time or at least help us with guidance how to start building that skeleton in proper way - I guess no one is at your knowledge level in this area ...

I feel that this leap forward will give all of us a push in right direction...

Thanks in advance,

regard,

Bulek.
 

[chriss]

Hi bulek,

- we currently have plugins that are coded in C++ and do whatever they do. Their behavour is hardcoded and barely settable by any settings. And also, it's quite hard to change their behavour, cause you have to be experienced C++ and LMCE programmer to do anything with it...

- on the other hand majority of us need somekind of custom determined behaviour and a lot of users probably feel quite incompetent to do anything useful (including my self from time to time).

ack.

What we would need to have is basically remove that behaviours from hardcoded plugins (except maybe those that are really needed)

still with you here...

and then try to prepare everything in GSD and Ruby way (so user could write minimal code with easy access to objects, data, events , etc...).

but  this is the point I don't really get. Again this plugin would be "hardcoded in Ruby" instead of "hardcoded in C++" and in some months somebody will start to do it again as "hardcoded in Java" because he doesn't like Ruby and C++? Or am I missing something?
I think, we should have some sort of "macro language" to define automation behavior on an abstract level, i.e. without having to think of DCE connectors, messages or whatever. This macro language would be interpreted by some plugin. I know, this is similar to responding to events, but it should be more powerful, i.e. allow to leave the lights off when starting a movie while the sun is shining brightly (and maybe activate your blinds instead). BTW, having some concept of inheritance would be great, e.g., define a movie scenario for the whole house but only modify some things in you bedroom and still be able to benefit from improvements done to the main scenario automagically...

Is this what you are thinking of? Haven't looked into GSD yet so maybe this is basically the same 

br,
/chriss

[hari]

I don't agree. If you want scriptable logic for scenarios and events we should extend the event plugin to allow more advanced conditions and such. Yes, it is limited at the moment, but we should improve it instead of rewriting all plugins (or only parts and add more to the mess) in an embedded script language. I don't feel like wrapping another interpreter, we have enough troubles on alpha with the GSD. And it would have to be wrapped to share the dcerouters memory space. Yes, I know we could attach a perl script to the dcerouter via sockets and handle logic there. But please let's try to not spread it all over different places and languages.

Ruby makes sense for GSD. But look at the troubles ddamron had with implementing a lighting interface (e.g. the messagetranslation and whatnot, problems with objects and the wrapper, ..). Or look how impossible it seems for some people to even interface a security panel via GSD.

And yes, we had community contributions to plugins. E.g. Jondecker contributed to the lighting plugin.

best regards,
Hari

[hari]

but  this is the point I don't really get. Again this plugin would be "hardcoded in Ruby" instead of "hardcoded in C++" and in some months somebody will start to do it again as "hardcoded in Java" because he doesn't like Ruby and C++? Or am I missing something?

no, thats exactly the point.

I think, we should have some sort of "macro language" to define automation behavior on an abstract level, i.e. without having to think of DCE connectors, messages or whatever. This macro language would be interpreted by some plugin. I know, this is similar to responding to events, but it should be more powerful, i.e. allow to leave the lights off when starting a movie while the sun is shining brightly (and maybe activate your blinds instead). BTW, having some concept of inheritance would be great, e.g., define a movie scenario for the whole house but only modify some things in you bedroom and still be able to benefit from improvements done to the main scenario automagically...

yes, some kind of an easy ha logic macro language for the event plugin would be cool.

Haven't looked into GSD yet so maybe this is basically the same 

No, GSD is a quick way to write DCE devices with ruby.

best regards,
Hari

[chriss]

thanks for the info, hari.

i just digged through the GSD pages. Seems GSD is a bit more than the name suggests, but still not meeting the requirements - at least not in its current state.

[tschak909]

Guys, let me break it down for you...

Any automated logic that is house-wide, must go into a plugin. No if ands or buts. This automatically rules out GSD, and thus this all must be done inside the C++ code of the respective plugins, themselves.

We already have sufficient division of the individual systems, including an Event Plugin and a General Info Plugin, please look at these, learn these, and extend these as needed.

But also remember, that we have UpdateEntArea, which does all calculation of scenario and event generation any time the router is reloaded. This is the application that makes all the automatic events, and it makes all the scenarios in response to certain devices being available, etc. Add anything pertaining to this here, and only here.

The only things that need to be added to the plugins are abstract primitives that we do not already have.....seeing as we have a great many of them which can be combined to do pretty much whatever is needed, I don't see a reason to extend this, you may prove me wrong.

Guys, I know a lot of you are control freak hacker geek types, I am too. But attaching programming languages in odd places is not the answer everywhere, this system needs to be accessible to a much wider range of audiences, and what we SHOULD be doing, is building logic tables to try to create automatic behavior in response to certain things being present/not present.

-Thom

[Zaerc]

Maybe I don't fully grasp the issues here, but couldn't all this be done by simply extending what is already there and possibly fixing a few small bugs in the event handling?

[tschak909]

Yes.

-Thom

[PeteK]

FWIW, I'm going to agree with Thom, Hari, Zaerc, and the other guys.  I think we're best served by extending the functionality of the core c++ components to allow needed flexibility rather than re-implementing their functionality as GSDs.

[chriss]

But also remember, that we have UpdateEntArea, which does all calculation of scenario and event generation any time the router is reloaded. This is the application that makes all the automatic events, and it makes all the scenarios in response to certain devices being available, etc. Add anything pertaining to this here, and only here.

agreed, but my point is, that all these calculations and rules are hard coded in there. They should not be replaced with another hard coded implementation but with a system being able to interpret some form of external rules, i.e., it should not be necessary to recompile this plugin everytime the rules are changed. please correct me, if this isn't necessary right now or if i'm wrong.

[tschak909]

If you look at the individual rules in this program, you'll see why this isn't really feasible.

We need to make this as automatic as possible, and yes, this program will get very large.. but we can come up with a sane set of rules that will handle the majority of use cases.

The good thing is, that this is where sql2cpp, the database, and the rest of the code marry together to make this less of a headache.

-Thom

[bulek]

Hi,

I see this matter attracted some discussion.

Maybe I was a bit misunderstood... I'm not saying or thinking about rewrite of plugins in Ruby, but am trying to say, that putting too much "smart" behaviour into hardcoded plugins that will actually change with each release being on half or full year schedule is not IMHO a way to go...  ok I agree, we can have smart tables with events actions, but I doubt we will get to this stage soon. So right now, I think the best way would be to fix current behaviour of plugins and put effort more in additional modules that would make implementations of custom behaviour in Ruby easier... Yes behaviour will be hardcoded, but user will be able to do it in much easier way.. Of course, codebase could be organized as templates, modules, behaviours that could be selected/unselected...

There will probably be as many different desires for different behaviour as there will be users using LMCE... Why not letting them a possibility to create and contribute...

What if for instance Media plugin will do something that you don't like (for example: in my case Media plugin switches my amplifier off, when screensaver starts on our main hybrid and we loose music - ok, I can untie a pipe etc... Also, try to make speech announcemet while playing playlist it will tear your system apart - at least does to mine...)? Then you will not be able to change that behaviuor with reasonable time or effort.

But anyway, this is just my opinion...

Regards,

bulek.

[tschak909]

*hmm*

damn it, I keep having this argument over and over.

Sorry, duct taping over problems for each individual user is not the right way to go.

I will not weigh in on this matter any further, I have argued it to death.

THIS SYSTEM IS _NOT_ MISTERHOUSE! DO NOT TREAT IT AS SUCH!

-Thom