Author Topic: New User Observations, Parent Child relationship/presentation  (Read 1328 times)

Rickbase1

  • First post!
  • Posts: 1
    • View Profile
New User Observations, Parent Child relationship/presentation
« on: September 15, 2011, 04: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



tschak909

  • LinuxMCE God
  • ****
  • Posts: 5501
  • DOES work for LinuxMCE.
    • View Profile
Re: New User Observations, Parent Child relationship/presentation
« Reply #1 on: September 16, 2011, 03:04:56 am »
Wow, okay, you need to pull back for a moment. ;)

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