Author Topic: NEW Threaded support for RUBY.  (Read 2721 times)

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
NEW Threaded support for RUBY.
« on: January 18, 2008, 05:25:43 am »
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: [Select]
##############################
#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.
« Last Edit: January 18, 2008, 05:33:00 am by ddamron »
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

nlb

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #1 on: January 28, 2008, 05:18:14 pm »
Dan,

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

cheers
Nick

niz23

  • Guru
  • ****
  • Posts: 361
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #2 on: January 28, 2008, 05:32:04 pm »
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

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: NEW Threaded support for RUBY.
« Reply #3 on: January 28, 2008, 07:50:47 pm »
Nick,

Anything is possible..

What did you want to do with the Stamp?

Regards,

Dan
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

nlb

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #4 on: January 29, 2008, 11:17:28 am »
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

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: NEW Threaded support for RUBY.
« Reply #5 on: January 29, 2008, 06:10:25 pm »
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)
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: NEW Threaded support for RUBY.
« Reply #6 on: January 30, 2008, 09:03:06 pm »
I've started a wiki for Threaded Ruby.
http://wiki.linuxmce.org/index.php/Category:ThreadedRuby

Regards,

Dan
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

nlb

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #7 on: January 31, 2008, 10:42:42 am »
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

  • Administrator
  • wants to work for LinuxMCE
  • *****
  • Posts: 884
  • Living with LMCE
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #8 on: January 31, 2008, 11:49:23 am »
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.
Thanks in advance,

regards,

Bulek.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: NEW Threaded support for RUBY.
« Reply #9 on: January 31, 2008, 09:20:20 pm »
Bulek, nailed it.
You can mix and match anything you want.
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

nlb

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #10 on: April 20, 2008, 09:23:46 pm »
ddamron,
any updates on your workings for the plc-bus driver?
cheers

Nlb

totallymaxed

  • LinuxMCE God
  • ****
  • Posts: 4360
  • Smart Home Consulting
    • View Profile
    • Dianemo - at home with technology
Re: NEW Threaded support for RUBY.
« Reply #11 on: April 20, 2008, 09:43:12 pm »
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 ;-)
Andy Herron,
Convergent Home Technologies Ltd
United Kingdom

Read My Blog; http://ellipticalcurve.com

Contact me for Smart Home consulting advice here;
@herron on Twitter, totallymaxed+consulting@gmail.com via email or PM me here.

Get a Dianemo S License: http://forum.linuxmce.org/index.php?topic=8880.0
iOS Orbiter: http://wiki.linuxmce.org/index.php/Dianemo_iOS_Orbiter
Follow us on Facebook: https://www.facebook.com/pages/Dianemo-Home-Automation/226019387454465

Sales & Info:
http://www.dianemo.co.uk

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5495
  • DOES work for LinuxMCE.
    • View Profile
Re: NEW Threaded support for RUBY.
« Reply #12 on: April 20, 2008, 11:23:40 pm »
currnetly, z-wave would still use the current z-wave code.

-Thom