NEW Threaded support for RUBY.

[ddamron]

Status Update:

Well, after much twisting of the brain, we have success.

I have successfully implemented a 'Home Automation Contoller' interface with PLCBUS.

Just what does it do?

Well, it's a set of Ruby Objects that 'encapsulate' home automation protocols.
(Actually, it can be used for ANY GSD device requiring bidirectional support)

Why is this good?

This is good for many reasons:

• This effectively eliminates the threading issues with Ruby.
• This handles multiple commands simultaneously, and bidirectionally.
  (by multiple commands, I mean it implements a command queue for you, so you don't have to.)
• When Bidirectional support is needed, these routines automatically handle the 'command=response' queuing.
  You determine if a response is accepted for the current command, or if it should be rejected.
  If the response is rejected, it is NOT tossed, instead, the routines then take that rejected response and add it as a COMMAND to the queue to be processed later.
• These routines have a full error handler, to handle things like Message Timeouts, max. message retransmits, and optionally sends transmission failures to your protocol.  You decide what you want to do in that case.
  
• Tracks the state of devices, and updates them as needed automatically.
  
  This is best explained by example.
  
  Let's say, you send a SETLEVEL command to a device. (say 50%)
  
  Then, you want to turn it off, so you send an OFF command to said device.
  The device won't turn off.
  
  Why?
  
  As far as the device is concerned, it IS off. (or it's STATE is OFF/x)
  The x being (50%) didn't change the state of the device, therefore, the device assumes it was never turned on!
  
  These routines will automatically track the state of the device.  IF a SetLevel command is sent when the device is OFF,
  they will automatically send a command (to itself) to set the state to ON before it sends out the SetLevel command.
  

How do I use these routines?

Simple.  I'll include a sample class file.  Here's What you'll need to do:

• You simply fill in the blanks (protocol info) in the class file.
  e.g. when an ON command is received, send THIS out.
• You can analyse BOTH the sent command, and the response back to determine if the response is what you were waiting for.  If it is, you set the cmdComplete flag to TRUE.  If it's not, don't set the flag.
• Certain circumstances will require you to wait for MULTIPLE responses.  No Problem.  If you determine you need to receive more data, simply set the needMoreInput flag. (Johnny 5 is alive! yeah, I know)
  
• Again, circumstances may arise when you need to re-send the command..(maybe slightly modified)
  and again, you simply set the reSend flag.
  
  

How did I do it?

With a lot of patience, lots of debug output, and a little magic

Cool!  Can I start using it now?
no.
Not quite yet.

I still have to nail down some 'usage' details, I know how I want to do it.. but the code (as you can well imagine) is quite complex, and each minor change required MAJOR inspecting, to make sure it doesn't break anything else...

Stay tuned,

Dan.

P.S.
Ok, I'll give you a peek..  Here's some of my comment extracts... keep in mind, they may change...

Code:

##############################
#Class RubyCommand
##############################
class RubyCommand
  # This class is a container for a protocolObject Instance.
  # This class is responsible for the DIRECTION of communication of a specific command.

##############################
#Classe RubyCommands
##############################
#RubyCommands is an ARRAY of RubyCommand
# This class is responsible for keeping the ORDER of commands straight.
# also, for creating the RubyCommand objects.
# TODO:  Sometimes, certain commands need to be ignored.
# TODO:  Sometimes, certain commands need to INSERT a command to be sent first.
# TODO:  Sometimes, certain commands need to APPEND a command to be send right after?
#
#Actions
#we need to define actions for:
# => 0x001 Direction DCE=>GSD/GSD=>DCE
# => 0x002 Command Sent/NotSent
# => 0x004 Response (Received/Rejected)
# => 0x008 Re-send needed(true/false)
# => 0x010 Re-receive needed(true/false)
# => 0x020 IgnoreNextDCE(true/false)
# => 0x040 IgnoreNextGSD(true/false)
# => 0x080 SendThisFirst(true/false)
# => 0x100 SendThisNext(true/false)

#####################
# class ChildDevice #
#####################
# This class holds a child device.
#
# Methods:
# ChildDevice.devdata[] hash of devdata
# ChildDevice.deviceid <int> Device ID
# ChildDevice.template <int> Template ID of Child
# ChildDevice.parent <int> parent ID of Child (doesnt seem to work)
# ChildDevice.state <string> Current state of child

#################
# class Devices #
#################
# This is a HASH collecion of ChildDevice.
#
# Methods:
# Devices.append(device) <ChildDevice> adds a child device to the hash
# Devices[deviceID].<ChildDeviceMethod> this is how you get info.
# eg: d=Devices.new d.append(child102) d[102].state = "ON/100"


#####################
### PLCBUS OBJECT ###
#####################
#  This is a generic replaceable object
# This object needs the following methods:
#
# When creating this class, make sure to keep seperate variables
# to hold dce vs gsd.  This is so we can compare the variables
# later.
#
# dcein(cmd)
#   dcein is a command or event sent from dce
#   this method should take the command and prepare
#   the output into gsdout(string)
#   This command will set the direction to DCEtoGSD
#   
# dceout(cmd) cmd is dce Command Object (Command.new)
#   This method contains the command to be sent to DCE
#   
# gsdin(string)
#   gsdin is a command received from GSD
#   This method should take the string and prepare
#   the output command in dceout
#   
# gsdout(string)
#   This method contains the output string to be sent to the device
#   
# direction(DCEtoGSD|GSDtoDCE)
#   This READ ONLY property determines which direction the current command is going
#
# cmdComplete (TRUE|FALSE)
#   This is the flag you set when a response for a command is accepted.
#   This property allows the user to compare the command vs response.
#
#   It is up to the programmer to make sure what needs to be compared, is.
#   
#   When this is set to true, the command will be removed unless needMoreInput is set.
#
# neetMoreInput (TRUE|FALSE)
#   Use this flag to allow multiple response messages to come to this command. 
#
# responseNeeded(TRUE|FALSE) this is a read/write property telling the command object
#   this command requires a response.
#   this is used for bidirectional communication.  If this is set, this command will WAIT for a response from the other side.

[nlb]

Dan,

Stupid question:
To your knowledge is possible to develop a Basic Stamp and control it via the PLCBUS controller?

cheers
Nick

[niz23]

nlb.

Dan,

Stupid question:
To your knowledge is possible to develop a Basic Stamp and control it via the PLCBUS controller?

cheers
Nick

It should be possible.
First you need some hardware to interface plcbus<->basic stamp.
See, http://www.plcbus.com/PLCBUS-985468.html

Then you have to implement some protocol that interface lmce<->basic-stamp[application].

I believe you can extend Dans (great work so far!) plcbus implementation with custom commands that interface against your basic stamp application. Isn´t it simple. At least in theory :-)

From the data provided on the webpage it seem like the module also provide dc power.
The biggest problem I guess will be to buy these modules. I have no idea were you may do so.


/niz23

[ddamron]

Nick,

Anything is possible..

What did you want to do with the Stamp?

Regards,

Dan

[nlb]

Well I would like to get into creating some controllers for my house automation myself.
I like PLCBUS but it seems that there is nothing in Belgium and the closest i found and viable is Hong Kong.  So supply is going to be a bit tough.  I figured I could start creating basic controllers and interface these with LinuxMCE through X10 (since stamp and X10 are compatible) but then reviewing x10 pros and cons, its seems that PLCBUS is more compatible for europe and hows better performances.  The only thing is how to get Stamp and plcbus to interact. Im kinda new to electronics so im kinda lost...

Any ideas / hints?
Is it even really worth it to try and control a stamp controller through plcbus?

cheers

[ddamron]

nlb,

I think controlling your STAMP through a PLCBus device is not the way you want to go.
It requires you to buy a PLCBUS device to connect your stamp with.. then, only VERY limited commands.. ON/OFF..

What you SHOULD research, is the protocol itself.  Connect the STAMP as if it's a PLCBUS device.. (optically isolated it!) and process the protocol inside the Stamp.  That will give you MUCH more functionality.

I would recommend a few courses in Electronics first!

I'm actually a hardware guy, programming is just a requirement..

Also, if your currently playing with a STAMP, it might be worth your while to look at other microcontrollers..

STAMP's are easy to program (basic).. so it's a good starting point..  I wouldn't recommend using them in production though.

Take a look at PIC microcontrollers www.microchip.com
There is a BASIC compiler for them that is pretty powerful.. I think the url is www.oshensoft.com

HTH,

Dan

PS
(didn't mean to put a downer on your project)

[ddamron]

I've started a wiki for Threaded Ruby.
http://wiki.linuxmce.org/index.php/Category:ThreadedRuby

Regards,

Dan

[nlb]

Dan,
thanks for the info - cleared some things up and no worries, this is not a downer,just an obstacle.

To you knowledge, would it be possible to mix two home automation protocols, e.g. using plcbus for all the lights, etc... and zwave for motion detectors and cameras? and still be able to control them through the same MCE interface?

Nick

[bulek]

Dan,
thanks for the info - cleared some things up and no worries, this is not a downer,just an obstacle.

To you knowledge, would it be possible to mix two home automation protocols, e.g. using plcbus for all the lights, etc... and zwave for motion detectors and cameras? and still be able to control them through the same MCE interface?

Nick

AFAIK this can be easily achieved, but not with mixing on code level, but on device level. You declare one zwave controller and put all devices it controls as childern, the same for all other protocol interfaces... and you'll be able to control all devices with no problems...

Regards,

Bulek.

[ddamron]

Bulek, nailed it.
You can mix and match anything you want.

[nlb]

ddamron,
any updates on your workings for the plc-bus driver?
cheers

Nlb

[totallymaxed]

Bulek, nailed it.
You can mix and match anything you want.

So does that mean that we can use your threaded Ruby code to manage Z-wave devices too? Or is it that the Z-wave devices would still use the 'old' z-wave code?

Andrew

PS nice work by the way ;-)

[tschak909]

currnetly, z-wave would still use the current z-wave code.

-Thom