LinuxMCE Forums

General => Developers => Topic started by: chrisbirkinshaw on January 16, 2009, 10:15:48 pm

Title: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 16, 2009, 10:15:48 pm
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
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: hari on January 16, 2009, 10:22:50 pm
you want to re-implement the lighting plugin in ruby?!?

br, Hari
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: bulek on January 17, 2009, 11:34:30 am
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.
 




Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chriss on January 17, 2009, 02:38:33 pm
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.

Quote
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...

Quote
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  :P

br,
/chriss


Title: Re: Coding an Automatic Lighting controller in GSD
Post by: hari on January 17, 2009, 02:45:59 pm
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
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: hari on January 17, 2009, 02:50:55 pm
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.

Quote
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.

Quote
Haven't looked into GSD yet so maybe this is basically the same  :P
No, GSD is a quick way to write DCE devices with ruby.

best regards,
Hari
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chriss on January 17, 2009, 03:14:30 pm
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.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 17, 2009, 05:19:59 pm
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
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: Zaerc on January 17, 2009, 05:55:19 pm
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?
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 17, 2009, 07:33:56 pm
Yes.

-Thom
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: PeteK on January 17, 2009, 07:56:27 pm
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.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chriss on January 17, 2009, 08:55:46 pm
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.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 17, 2009, 08:59:48 pm
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
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: bulek on January 17, 2009, 10:41:38 pm
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.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 17, 2009, 11:02:36 pm
*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
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 17, 2009, 11:35:07 pm
Sorry, I did not mean to yell.

Ok,

Prove me wrong.

Do a proof of concept.

-Thom
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: Zaerc on January 18, 2009, 12:02:55 am
...
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...
...

So far there have been weekly updates for 0810 (alpha).

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.

Those are what we call bugs and need to be fixed properly.  And changes will always take time and effort, what you call reasonable or not isn't very relevant.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: jondecker76 on January 18, 2009, 12:40:58 am
Also remember that you can respond to events with your own commands without having to code a thing in C++ or GSD at all. In fact, most things should be possible with just these features alone.

For those special situations where you absolutely have to have complete control over things, I did finish implementing an "Unmanaged" room type that will have absolutely no automatically generated scenarios. For 0810, if you want your own behavior you can use this room type, and make your own event responses and scenarios (though you would be surprised at how much you have to manually add in order to get the functionality that LMCE has already provided by generating them for you)
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: bulek on January 18, 2009, 09:14:40 am
Hi,

...

I agree,what can be done with simple event handling and timed handling and scenarios over web-admin, it should be. I think we can get idea from enhancements to event handling that MiaCasa or Casaverde (whatever it is) did. We need some easier interface to do it...

What my idea is also talking about is to prepare few Ruby modules/classes that would ease implementation of SW for more complex behaviour/criteria/action things... It would be nice to have easy to understand skeleton in Ruby that would start, connect to DCERouter with possibility to register interceptor, and then ability for easy access to state of devices, acting upon received events, doing some actions (sending commands,new events, read data, etc...). Something similar DDamron did with PLCBus driver...

Also we should disect existing set of "prepackaged" special events and contribute missing parts that would ease handling...

I also think that Unmanaged room is a good idea, but maybe easier dealing with autogenerated scenarios (one click to disable certain scenarios - they can stay there, just being disabled) is a better answer... But in the mean time , Unmanaged room is also a good option...

Regards,

Bulek.


Title: Re: Coding an Automatic Lighting controller in GSD
Post by: Zaerc on January 18, 2009, 12:23:50 pm
...
Also we should disect existing set of "prepackaged" special events and contribute missing parts that would ease handling...
...

Good idea, keep us posted on your progress.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 18, 2009, 07:28:17 pm
Thom is right, of course, that we have the respond to events in the web admin and we should just extend that.

My problem is however that I have no C programming skills so I am unable to help directly.

I had hoped that I could create some "duct tape" which would help a few people out getting automatic motion-triggered lighting working in the mean-time. Eventually as the respond to events in improved this would no longer be necessary. At the moment I have misterhouse, interfaced over sockets to the DCE router, which is quite untitdy as I have to map X10 codes to device ids in there too.

I'm basically just looking for advice to help me create this duct-tape. I am also happy to make suggestions for improvements to the Lighting Plugin and help out with testing, Wiki writing etc. It's not one or the other.

Regards,

Chris


Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 18, 2009, 07:29:06 pm
BTW if the Respond to Events was enhanced this would be way better than Misterhouse anyway. Nobody wants to write code as a configuration step!

Chris
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: bulek on January 19, 2009, 02:56:44 am
Thom is right, of course, that we have the respond to events in the web admin and we should just extend that.

My problem is however that I have no C programming skills so I am unable to help directly.

I had hoped that I could create some "duct tape" which would help a few people out getting automatic motion-triggered lighting working in the mean-time. Eventually as the respond to events in improved this would no longer be necessary. At the moment I have misterhouse, interfaced over sockets to the DCE router, which is quite untitdy as I have to map X10 codes to device ids in there too.

I'm basically just looking for advice to help me create this duct-tape. I am also happy to make suggestions for improvements to the Lighting Plugin and help out with testing, Wiki writing etc. It's not one or the other.

Regards,

Chris



Hi,

I'm not sure why you call your current solution as "duct tape" and untidy. I'm not sure what exactly do you mean by automatic lighting - if you mean motion triggered lighting only, than you're probably ok with event handling under LMCE. But if you're after more advanced presence/lighting features, than I think Misterhouse has some automatic lighting module that is quite complex, but does things in more advanced fashion. If you'll wait for anything similar in LMCE, then you'll probably wait for a loooong time... Why don't you try MH module for presence/lighting if you already have connected those two systems ?

Your situation is exactly my point of discussion. Only few developers are currently able to do something in C++, majority of users wish to customize behaviour. There is now common reasoning going on these forums that everything that is not written in C++ is a duct tape solution. I disagree, cause if you take a look from that perspective than also all drivers currently in Ruby could be declared for duct tape solutions.... I believe that open source systems are about freedom. Everything is allowed, use your imagination and do what you need...

If you'll try to do it in Ruby, than you'll probably study a lot of existing GSD examples...

HTH,

regards,

Bulek.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: Zaerc on January 19, 2009, 11:14:50 am
Thom is right, of course, that we have the respond to events in the web admin and we should just extend that.

My problem is however that I have no C programming skills so I am unable to help directly.

I had hoped that I could create some "duct tape" which would help a few people out getting automatic motion-triggered lighting working in the mean-time. Eventually as the respond to events in improved this would no longer be necessary. At the moment I have misterhouse, interfaced over sockets to the DCE router, which is quite untitdy as I have to map X10 codes to device ids in there too.

I'm basically just looking for advice to help me create this duct-tape. I am also happy to make suggestions for improvements to the Lighting Plugin and help out with testing, Wiki writing etc. It's not one or the other.

Regards,

Chris



Hi,

I'm not sure why you call your current solution as "duct tape" and untidy. I'm not sure what exactly do you mean by automatic lighting - if you mean motion triggered lighting only, than you're probably ok with event handling under LMCE. But if you're after more advanced presence/lighting features, than I think Misterhouse has some automatic lighting module that is quite complex, but does things in more advanced fashion. If you'll wait for anything similar in LMCE, then you'll probably wait for a loooong time... Why don't you try MH module for presence/lighting if you already have connected those two systems ?

Your situation is exactly my point of discussion. Only few developers are currently able to do something in C++, majority of users wish to customize behaviour. There is now common reasoning going on these forums that everything that is not written in C++ is a duct tape solution. I disagree, cause if you take a look from that perspective than also all drivers currently in Ruby could be declared for duct tape solutions.... I believe that open source systems are about freedom. Everything is allowed, use your imagination and do what you need...

If you'll try to do it in Ruby, than you'll probably study a lot of existing GSD examples...

HTH,

regards,

Bulek.


The few developers that are currently able to do something in C++ are getting really fed up with your bitching.  It's not like this is the only issue there is to fix. 
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: hari on January 19, 2009, 11:26:14 am
yeah, we should fix GSD on 0810 first, before even thinking about integrating more scripting stuff.

Quote
But if you're after more advanced presence/lighting features, than I think Misterhouse has some automatic lighting module that is quite complex, but does things in more advanced fashion. If you'll wait for anything similar in LMCE, then you'll probably wait for a loooong time...

Maybe you want to elaborate what exactly is missing.

br, Hari
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: bulek on January 19, 2009, 11:50:41 am
yeah, we should fix GSD on 0810 first, before even thinking about integrating more scripting stuff.

Quote
But if you're after more advanced presence/lighting features, than I think Misterhouse has some automatic lighting module that is quite complex, but does things in more advanced fashion. If you'll wait for anything similar in LMCE, then you'll probably wait for a loooong time...

Maybe you want to elaborate what exactly is missing.

br, Hari

Hi,

the main problem with simple motion detected lighting is that sometimes users sits down doing nothing and light comes off...

I don't know internals of MH implementation very deep, but I know that there is somekind of graph you define (nodes, connections). There are also doors sensors and any other indicating user presence or movement  involved...

Basically that module estimates room occupancy based on informations from sensors, tracks user movements and sets lighting accordindly...

But don't get me wrong, this is probably really specific module that will probably be not needed by majority of users...But fellow user asked about it.  So I'm not saying that it should be imlemented, but it will probably not be available in short time...

Zaerc: I always express gratitude for all work of "developers that can do in C++" and I meant nothing bad about it, just indicating that developers' resources are really limited...

Regards,

Bulek.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: Zaerc on January 19, 2009, 12:45:29 pm
...
the main problem with simple motion detected lighting is that sometimes users sits down doing nothing and light comes off...
...

Have you even bothered to open a ticket for this in trac?  Or does that require C++ skills too?

...
Zaerc: I always express gratitude for all work of "developers that can do in C++" and I meant nothing bad about it, just indicating that developers' resources are really limited...
...

And here is how you express that grattitude:

...
If you'll wait for anything similar in LMCE, then you'll probably wait for a loooong time...
...

Gee thanks, sounds like you're really taking our limited resources into account there.

Just to make things clear, we are not here just to cater to your wishes.  Either help out, or go sit on your ass and wait, but whatever you do quit bitching about duct-taping misterhouse on top of lmce, it is getting really old by now and we have way bigger fish to fry then your fucking light not staying on as long as you'd like, in case you haven't noticed.

Sorry for the harsh words, and I have tried to stay out of this as long as I could but enough is enough.
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 19, 2009, 08:02:10 pm
Ok, given the last few posts I suggest we close this thread as follows:

I will:

1. Submit to trac bugs or feature requests for everything in the Lighting Plugin which I would need changing to get a decent automated lighting system based on occupancy and taking into account whether you are watching media etc.

2. Write a small and lightweight script to satisfy my needs in the interim period which connects via sockets

3. Write a wiki page containing the script and explaining all the things I have submitted to Trac and how these will negate the need for it and build on it in terms of usability and expandability

Does this sound reasonable?
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: tschak909 on January 19, 2009, 08:30:50 pm
Yes.

-Thom
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 22, 2009, 09:25:09 pm

I'm having a problem with ruby code and wondered if anyone can help. This is what I have so far as a test (forgive my first attempts at programming a ruby script!):

Code: [Select]
require 'socket'
include Socket::Constants 

device_id=162
 
def connect_lmce(device_id)
  in_socket = Socket.new( AF_INET, SOCK_STREAM, 0 )
  in_sockaddr = Socket.pack_sockaddr_in( 3450, 'localhost' )
  in_socket.connect( in_sockaddr )

  out_socket = Socket.new( AF_INET, SOCK_STREAM, 0 )
  out_sockaddr = Socket.pack_sockaddr_in( 3450, 'localhost' )
  out_socket.connect( out_sockaddr )

  puts "Setting receiving connection"
  in_socket.send("COMMAND #{device_id}\n",0)
  puts in_socket.recv( 100 )
   
  puts "Setting up sending connection"
  out_socket.send("EVENT #{device_id}\n",0)
  puts out_socket.recv( 100 )
     
  sleep 1

  puts "Registering for plain text messages"
  out_socket.send("PLAIN_TEXT\n",0)
  puts out_socket.recv( 100 )
 
  puts "Finished initialising"
  return in_socket, out_socket
end
 
def register_messages(device_id, in_socket, out_socket)
  puts "Registering for message intercepts (lighting devices)"
  out_socket.send("MESSAGET 24 \n #{device_id} -1000 8 0 5 2 4 84\n",0)
  puts out_socket.recv(100)
   
  puts "Registering for message intercepts (security devices)"
  out_socket.send("MESSAGET 24 \n #{device_id} -1000 8 0 5 1 4 73 \n",0)
  puts out_socket.recv(100)
   
  puts "Finished registration"
end
     
in_socket, out_socket = connect_lmce(device_id)
register_messages(device_id, in_socket, out_socket)
   
messageCount = 0
while data = in_socket.recv( 100 )
  data = data.gsub('"', '').gsub('&', '')
  if data.size > 0
    messageCount += 1
    puts "Received message #{messageCount}: #{data}"
  else
    puts "empty"
  end
end


The last part is of most interest:

Code: [Select]
messageCount = 0
while data = in_socket.recv( 100 )
  data = data.gsub('"', '').gsub('&', '')
  if data.size > 0
    messageCount += 1
    puts "Received message #{messageCount}: #{data}"
  else
    puts "empty"
  end
end

Basically I put the empty check in because I am seeing some weird stuff going on. When I run the script everything works fine while receiving certain messages, but then when one particular kind of message is received the program freezes for 15 secs, then goes into a crazy loop of empty messages. Like this:

Code: [Select]
Finished registration
Received message 1: MESSAGET 18
1234 162 999 9999
Received message 2: MESSAGET 18
1234 162 999 9999
Received message 3: MESSAGET 18
1234 162 999 9999
Received message 4: MESSAGET 35
0 162 9 0  82 -1000 2 9 25 0 
empty
empty
empty
empty
...

Can anyone help me out here?

Thanks,

Chris
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 23, 2009, 09:15:32 pm
I'll make a separate thread
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chrisbirkinshaw on January 30, 2009, 06:56:34 pm

I wrote the code and a Wiki page.

http://wiki.linuxmce.org/index.php/User:Chrisbirkinshaw


I want to put the following into Mantis:

1. In an event responder it is not possible to start a timer with a given name and a command or series of commands to process on completion and then kill that timer by name at any point.

2. In an event responder it is not possible to use device status as a condition, e.g. "AND device 13 is on"


First, does anyone have any comments, and second, is Mantis down? I am getting a 404 error.

Regards,

Chris
Title: Re: Coding an Automatic Lighting controller in GSD
Post by: chriss on January 31, 2009, 10:15:07 am
well, mantis is used as a private system since a couple of weeks. the public bugtracker is Trac by now. you can find it here http://svn.linuxmce.org/