PLEASE READ BEFORE POSTING:

If you are willing to offer some compensation for a new feature or bug fix, you can use the Help Wanted forum. Start a new topic for each new feature idea, and when someone someone decides to do it, please edit the Roadmap Wiki which lists active work.
LinuxMCE Forums
May 21, 2013, 02:23:58 pm GMT-1 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com
 
   Home   Help Search Chat Login Register  
Pages: [1]
  Print  
Author Topic: New User Observations, Parent Child relationship/presentation  (Read 1014 times)
Rickbase1
First post!

Posts: 1


View Profile
« on: September 15, 2011, 03:50:45 pm »

Hi guys,

I was introduced to LinuxMCE just a week ago and have to admit I am hooked!  The effort and inovation that has gone into this product is overwhelming to say the least.  

As a new user I find myself getting bogged down trying to understand the parent/child relationships within the Admin interface.  There just seem to be so many options available, I dont know which way to go.  Is there any way to portray the config in a tree type presentation where the subsystems are all added /defined from within the tree starting with the Core at the top and adding each device under it?  Maybe this is already done, but I can't seem to get the drilldown presentation I would expect.   The tree in the left admin pane seems to do a bit of this but not completely? I could just be doing something wrong.

For instance is it possible to; if you wanted to hook up a security system to a com port on the core, (as I understand it)you would define a local com port, then an interface type/protocol, then a security system, then a zone, then a sensor, all done in a drop down tree type environment, with only options available/allowed at each level being presented?

Can this then be presented in a graphical drilldown way in the orbiters too, using the background JPGs/PNG's?

Hats off to all the developers!

Rick


Logged
tschak909
LinuxMCE God
****
Posts: 5101

DOES work for LinuxMCE.


View Profile
« Reply #1 on: September 16, 2011, 02:04:56 am »

Wow, okay, you need to pull back for a moment. Wink

Yes, we use a hierarchy to represent devices connected to the system.

This is combined with the fact that the things you put in that tree have a lot of information attached to them so that they know where they need to go.

In the end, each device template (any number of instances of which may wind up in the device tree for an installation) usually has plug and play information associated with it, so that when Device Detected events come in from various parts of the system (such as the HAL device for USB or PCI devices), or the DHCPd-Plugin (for Network devices), the system will know what device templates to possibly associate with the new device, so much of this is mitigated.

But for other devices, such as a GC-100, the relationship is usually

Master Interface device (i.e. GC-100)
   Infra Red Porr
   Infra Red Port
   Infra Red Port
   Door Sensor
   Window Sensor
   Doorbell

the GC-100 DCE device driver itself implements a ReceivedCommandForChild() method, which listens for things destined for its children (the different child ports above), and does the right thing (essentially a switch() )

Similarly, Z-Wave is implemented in the same way,
and security DCE devices like the VistaICM2 are implemented in the same way.

With that said, There is plenty of architectural help to help make this process automatic, provided the drivers or the hardware can provide the needed events or mechanisms to notify the system when devices enter or leave.

-Thom
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!