LinuxMCE - User contributions [en]

Usage Intro

2011-09-27T08:14:47Z

AHagerty93: None

{| align="right"
| __TOC__
|}
LinuxMCE's main concepts are [[Devices]], Commands (aka [[Scenarios]] and Activities), and [[Events]]. An [[Orbiter]] is the device that displays the User Interface. It can be a [[Media Director|Media Station]], web pad, mobile phone, or other remote control device. The Orbiter User Interface is standardized for all Orbiters.

== Devices ==

A device is generally a piece of hardware or software, like the Xine Media Player, a light switch, or a mobile phone. Devices have three functions, abbreviated "DCE" (Data, Commands, Events):

# Retrieve configuration '''data'''
# Perform a '''command''' (turn on, turn off, fast forward, etc.)
# Report certain triggered '''events''' (e.g. 'motion detected', 'playback started', etc.)

== Scenarios ==

"[[Scenarios]]", "Activities", and "Command Groups" are interchangeable terms -- they mean the same thing. A scenario is a group of commands that can be sent to a device (or series of devices). In LinuxMCE, the default Orbiter main menu consists of several scenario categories, grouped by room. These categories are:-

* Lighting
* Media
* Climate
* Telecom
* Security

(These default categories are arbitrary and are set up at installation.) To perform an action in LinuxMCE, a scenario is chosen from one of these categories (located on the main menu of an Orbiter).

For example, in rooms which have both a TV and lights, LinuxMCE automatically creates a scenario called 'Showtime.' This scenario dims the lights to 10% whenever the TV starts playing. In rooms with a PVR or other TV-enabled device, another scenario is created called 'TV' (in the 'Media' category) to start the TV. Another scenario in the 'Media' category called 'Video' sends a command to the Orbiter to list your video content. Telecom scenarios are created to make phone calls. Security scenarios are created to view cameras and to arm an alarm.

Some [[What_scenarios_are_created_automatically%3F|default scenarios]] are created for you at installation. A fully-functional system can run using only the default scenarios, if you choose. You can also change or remove the default scenarios or add new ones. This is done though the '''[[LinuxMCE Admin Website]]-->Wizard-->[[Scenarios]]''' menu. When creating a scenario, the [[LinuxMCE Admin Website]] will show you the most appropriate wizard, based on the category you pick. If you're adding an activity in the lighting category, for example, the wizard will display a list of the lights in the room and let you pick which ones to turn off. If you're creating a scenario in the security category, it will list the installed cameras and will allow you to select which ones to display.

A scenario can send a command to any device in the system. By default, scenarios in the lighting category show you the room lights, allowing you to select which ones to send commands. However, from the '''Wizard-->[[Scenarios]]''' menu for the specific scenario, you can also specify a command to any device in your home. You could make a phone call, for example, even from a scenario in the lighting category.

Certain scenarios are assigned to certain rooms by default. This can be customized, however. When you manually select a room from the Orbiter main menu, the default scenarios for that room are displayed. In general they control devices in that room, but this can also be changed. If your kitchen is near the garage and you want a scenario to 'turn off the garage light', you can assign a scenario to the room 'kitchen' that will do just that. It doesn't matter that the light is in the garage.

For a Media Director, the on-screen Orbiter User Interface appears on the TV screen. It is manipulated by the mouse/keyboard or remote control connected to your Media Director. By default it is set to display the scenarios for the room in which the Media Director is located.

In contrast, a mobile Orbiter (such as a webpad) can be carried throughout the house. It must be able to select the scenarios for multiple rooms. Fortunately, the option to manually select which room you are currently in is available on every Orbiter's main menu.

This can occasionally cause some confusion. Perhaps both the Living Room and the Bedroom have a scenario called 'TV'. You may have a web pad that is in the Bedroom, but you then carry it to the Living Room. You may forget to tell the web pad that it's now in the Living Room (at the bottom of the Orbiter screen it will still say 'Bedroom'). You hit the 'TV' button expecting the Living Room TV to come on, but in fact you're still controlling the Bedroom and the TV comes on there instead. Finally, you may realize that you must change your room location to Living Room, then you can control the TV there.

Once you get used to this concept, though, you'll find it very useful. Conveniently, any Orbiter can be set to control any room and choose from the scenarios assigned to that room. No matter which Orbiter you use, the same set of scenarios will be displayed for each specific room. For example, the kitchen scenarios will always be the same, no matter which Orbiter you are using. (The scenarios are assigned by room -- not by Orbiter.) No matter whether you pick up your mobile phone, your web pad, or your remote control, you will always be shown the same list of scenario options for the Living Room.

You have the option of preventing some family members from using certain scenarios. From the [[LinuxMCE Admin Website]], certain scenarios and rooms can be [[Users#Restrict_Access|restricted to certain users]]. Maybe little Suzy's mobile phone Orbiter should be restricted so that she is only able to control her room and the living room, for example. She would only be able to execute the scenarios in those rooms, but not the Master Bedroom. Other possible options include [[Users#Restrict_Access|requiring a pin code]] to access the scenarios for a particular room.

== Events ==

Devices report events, such as 'Playback started' and 'Motion Sensor tripped'. If you want something to happen automatically in LinuxMCE, you create Event Handlers that react to these events. For example, you can create an event handler that listens for the 'Motion Sensor tripped' event from a motion detector and turns on the lights in response. An event handler might listen for the 'Sunrise' event, which could then prompt the sprinklers to come on.

LinuxMCE creates several default event handlers. In rooms in which you have a TV and lights, an event handler is created that listens for the 'Watching Media' event sent by a media player. When the event is detected, the Showtime scenario (which dims the lights) is executed in response. When you start a movie, therefore, the Showtime activity will be executed and the lights will be dimmed. There are other default event handlers that monitor for events like 'Security Breach' and 'Fire Alarm' (from a home security system).

== Controlling an Orbiter ==

To control the system, you use an [[Orbiter]], which is the LinuxMCE term for a remote control. All [[Orbiters]] have the same basic function: to display the scenarios in the room you're in and let you select one. The different Orbiters may [[Selecting_the_Right_UI|display the User Interface slightly differently]], depending on their screen size, but the function and the list of scenarios is always the same. For example, the [[Selecting_the_Right_UI|"UI1" interface]] (which is used on webpads and PDAs) displays the scenarios in horizontal rows. (If there are more than will fit on a row, there will be a "more" button.) A home button is always displayed that takes you to the main menu. On smaller displays, as on mobile phones or desktop phones, there's not enough room to show the scenarios themselves. The top level menu shows only the categories: Lights, Media, Climate, Security and Telecom. Selecting a category displays the scenarios in that category.

[[Selecting_the_Right_UI|"UI2"]] is the [[Selecting_the_Right_UI|preferred User Interface]] for Media Stations. Using a traditional IR remote is not much different from using any other Media Center PC remote. The menu button brings up the main menu, and you use the ''left/right/up/down/enter'' buttons to navigate it. The ''fast forward/rewind/skip +/skip -'' keys are used for media playback.

If you have a pointing device like a mouse or gyro air mouse, the UI2 interface also supports a unique control architecture that lets you do everything with 3 (programmable) buttons (plus ok and cancel). The 3 buttons are "MEDIA", "MENU", "AMBIANCE".

On a mouse with 3 programmable buttons (such as the [[Using_the_Gyration_Remote_GYR3101US_%28Non-Fiire_Chief%29|gyration]]), these functions correspond to the buttons from left to right. If you are using a traditional 3 button mouse, you can use the F6, F7 and F8 keys on the keyboard for the three programmable functions instead. In both cases, the left mouse button is "ok", and the right mouse button is "cancel/go back".

Mouse button behavior is "absolute" when you press and hold the media/menu/ambiance button and "relative" when you tap and release.

The "absolute" behavior is generally more efficient. For example, in the case of the middle button (F7), "absolute" behavior means the action is executed without having to additionally click "ok". If you press and hold the middle button (F7) while moving your mouse pointer to the option, then let go, that option is executed. If you instead tap and release the menu button ("relative" behavior), you will only highlight the menu option. You must then press ok (the left mouse button) to execute the option.

Categories appear along the bottom of the screen, and the scenarios in each category popup vertically (like a pull-down menu in a PC, except upside down). If the main menu isn't already visible, bring it up by pressing the "start" button on a Windows IR remote, or the "menu" button on a 3-button mouse. To exit a menu, use the back button on the IR remote, the cancel button (right mouse button on a 3-button mouse), or the ESC key on a keyboard.

In UI2, the media is always full screen. If you're not playing your own media, the background media (i.e. screensaver images) is gallery art from the Internet (using flickr) or [[Use_my_own_pictures_in_the_Screen_Saver|pictures you select]]. If only the screensaver images are displayed on the Media Station, press the menu/middle/F7 button to bring up the menu. Right click/ESC to get rid of it. (This works even if your own media is playing.)

If you're using UI2's 3-button navigation model, the normal media control options on a traditional remote are replaced with a single button: "media" (left soft button or F6). Press this and move the pointer up and down for your skip functions (''ch+, ch-, skip fwd, skip back''). Move the pointer left and right for speed control (''rewind, fast forward''). The further you move, the faster the media playback changes. If you hold the button down (the left soft button or F6), your movement will be "absolute". Instead of the traditional "jog shuttle-type" control, movement to the right skips to the end of your media, and movement to the left skips to the beginning. Once you get used to it, you will find that navigating media is orders of magnitude faster and easier with this model than with a traditional remote. You can find a spot in a 2 hour movie in only a couple seconds with a click of a single button (compared to a slew of button clicks required using a traditional remote).

Also, in UI2 you can press the "ambiance" button (right soft button or F8). Move up/down to adjust the lights, and left/right to adjust the volume. As with the media playback, if you hold the F8/right soft button down while you move left and right, your volume control is in "absolute" mode (not "relative"). Moving hard right turns up the volume full blast; hard left is mute. This requires you have a TV or receiver that is serial-controlled, however. LinuxMCE can then directly and instantly set the volume position in sync with your hand movements. (Few TVs and receivers have this feature, unfortunately.)

There are other media control functions besides the most commonly used ''fast fwd/rewind/skip up/skip down''. You can, for example, choose 'subtitles' while watching a DVD, 'guide' while watching TV, and 'random' while listening to an audio CD. In the UI2 3 button model, these functions appear on the main menu (on the left-most pad, entitled 'now playing') and changes according to the type of media you're playing. Press the menu button (middle button/F7) to select these options.

This 3 button model is a new concept and very different from traditional navigation. Most people find it much faster once they become accustomed to it.

==Reload Router & Regen Orbiters==

While using LinuxMCE you'll see sometimes a message asking if you want to [[Quick reload router|reload the router]], or if you want to [[Orbiter Generator|regenerate the Orbiter UIs]] (User Interfaces). In general, these options refresh the LinuxMCE databases so that changes to the system can be recognized.

===Reload Router===
All devices in LinuxMCE obtain their configuration information from the , which is the central piece of software on the Core. All devices request a list of the other devices in the home from the router, so they can respond to them appropriately. (For example, an IP camera device might turn on the lights in the room whenever you're viewing the camera. To do [http://www.thepiggybackrider.com/ child carrier] so, the IP camera needs to know what lights are in the room.) Typically a device requests this information only when it's starting up. When you connect additional plug and play devices to the system, these new devices generally will work immediately, but their functionality may not be fully enabled within the LinuxMCE system until the DCE router is reloaded. When the router reloads, it signals all devices on the system to simultaneously reload and re-request the system data. Each existing device can then work with each new device. This process is known as a 'reload'. It generally takes about 10 seconds. Every time you add or remove devices, or change a device's configuration, you may be asked to do a reload. If you're going to add more devices or make more device changes, you can do the reload once you're done. If you're in the middle of watching a movie or TV, you can postpone the reload, since media players generally stop playing during reloads. Phone calls aren't affected, though, and TV shows being recorded by MythTV in the background are also unaffected.

===Regen the Orbiter===
LinuxMCE's [[Selecting_the_Right_UI|Orbiter User Interfaces]] are all "pre-rendered" in order to be more efficient. The User Interface source images are all very high resolution, but need to be resized to accommodate the resolution of each Orbiter screen. The Core server has a list of the Orbiters used by your system, and will generate the appropriate User Interface screen for each Orbiter. It will do this each time you request a "regen". If you have five different types of Orbiters (each with a different type of screen), then five different images will be generated during each regen.

These User Interface screen images are stored in the Core. The appropriate UI image is sent to an Orbiter whenever it is activated. For many low-power devices (like mobile phones or desktop phones) there just isn't the processing power to do scaling and rendering of a User Interface screen on the fly. They need to be pre-rendered (with text pre-embedded in the images) to be efficient.

Adding new scenarios may result in the creation of new buttons for the User Interface, or changes to the text on existing buttons. Perhaps an entirely new screen will be created.

Until the User Interface images are regenerated, though, you won't be able to see these new buttons (or screens) on your Orbiter. During the regen, new User Interface images for each type of Orbiter is generated by the Core. This can take about 2-5 minutes, depending on how many Orbiter types you have in your system.

You needn't do a regen every time you add a scenario. You can wait until you have finished adding all the scenarios. Furthermore, you can also regen only the Orbiter you are currently using by doing a "Quick regen". This allows you to see the new User Interface (following the addition of new scenarios) without having to do a full regen for all the Orbiters. Once you have finished adding scenarios, then you can do a full regen.

This regen process can be a bit annoying, but is necessary. In future editions of LinuxMCE, it is planned to allow Media Directors, which have a lot more processing power, to render their on-screen Orbiter User Interfaces on the fly (so you don't have to do a regen each time you add or remove a scenario).

You can do a [[Orbiter Generator#Running OrbiterGen (performing a "regen")|full Orbiter regen or a Quick regen]] at any time by using buttons on the Core's LinuxMCE [[Launch Manager]].

==Managing your media==
LinuxMCE is always scanning for network shares, on Network-Attached Storage (NAS) devices and other Hard Disk Drives (HDDs) of PCs connected to the system (including Windows PCs). Universal Serial Bus (USB) drives are also detected. Every time a LinuxMCE finds a network share, you will be asked if you would like to use it. Whenever you reply "Yes", the file share can be used by any Media Director on the system. The file share is scanned for media, such as audio, video and photos, and any that are found are then cataloged in the Core's central database. For example, when you plug in a USB drive on a Media Station in the living room and tell LinuxMCE to use it, the media on the drive will be available to Media Directors in other rooms.

At the moment there is no way to restrict your media for 'local use only'; all Media Stations in the LinuxMCE system share the media catalog stored on the Core. (This is a limitation that will be addressed in the near future. Sometimes it is desirable to attach a USB drive in the master bedroom and not allow it to be shared, for example. ''Note: However, see [[folder lock|this article that describes a method to address this problem]].'')

Storage devices (NAS, USB drives, extra HDDs on the Core or Media Directors) are referred to as "Extra Drives". When an extra drive is added, it is listed in the device tree in '''[[LinuxMCE Admin Website]]-->Advanced-->Configuration-->[[Devices]]'''. Under 'Core' you'll see a device listed for each HDD in the Core, as well as for each NAS device. Under each Media Station will be listed the HDDs in that Media Station. By clicking on the device you can change the device's properties, such as the mount username/password. Each NAS device, and each file share on another PC, will show as a device listed under the Core; each is considered a child of the Core.

===Access control for shared media===
LinuxMCE creates a top level folder for 'public' media. This folder can be used by every user in the system. A 'private' media folder is also created for each user. Within each of those folders are sub-folders, labeled 'audio', 'video', 'pictures', 'data' and 'other'. Within each of those will also be sub-folders for the extra storage devices (NAS, USB, extra internal drives, etc). When you attach an extra storage device, you can specify whether the default directory structure should be used for it. Alternatively, you can specify 'just make it public' or 'make it private'.

Here's an example. Let's say you have 2 users: john and mary. You connect 3 storage devices:
# a NAS, for which you specify 'use default directory structure'. It is named 'Generic Network Storage [50]'
# a USB drive for which you specify 'make it all public'. It is named 'USB Drive [51]'
# a SATA drive for which you choose 'make it private for john'. It is named 'General Internal HDD [52]

Now let's say you're running Windows. Go to Network Neighborhood and find the LinuxMCE Core server. The directory tree ought to look like this:
<pre>
public
video
Generic Network Storage [50]
audio
Generic Network Storage [50]
pictures
Generic Network Storage [50]
data
Generic Network Storage [50]
other
USB Drive [51]
john
video
Generic Network Storage [50]
audio
Generic Network Storage [50]
pictures
Generic Network Storage [50]
data
Generic Network Storage [50]
other
General Internal HDD [52]
mary
video
Generic Network Storage [50]
audio
Generic Network Storage [50]
pictures
Generic Network Storage [50]
data
Generic Network Storage [50]
other
</pre>
Whether you put your media under video, audio, pictures, data or other is unimportant. It will be scanned by LinuxMCE anyway. The contents of "General Internal HDD [52]" will be displayed in the folder john/other/General Internal HDD [52]. The contents of USB Drive [51] will be displayed in the folder public/other/USB Drive [51]. When John browses the contents in Network Neighborhood, he will be asked for his username and password. He can then access the content in both the public folder as well as the "john" folders (including General Internal HDD [52]). When Mary browses the contents with her username and password, she will see both the public and "mary" folders. She will not be able to see anything on General Internal HDD [52], however, since that drive was specified to be private for John.

In the case of John's private media, it won't be displayed in the LinuxMCE media browser unless you click 'Sources'-->'John'. However you ''can'' see the contents of General Internal HDD [52] (unless you deselect 'Sources'-->'Public' from the media browser). Generic Network Storage [50] would be different, however, since you specified to use the default directory structure for it. LinuxMCE will have created public directories on Generic Network Storage [50] for public video and public audio, as well as for john's video and mary's audio. The media file browser will show only the media that is in the public directories. (The same is true with the Windows Network Neighborhood browser.)

If Generic Network Storage [50] has existing media in the top (root) folder, you won't see it listed anywhere.

It is generally recommended, therefore, that when you add a new (blank) "extra" storage device, you choose to use the default directory structure on it. When you rip media to that device, the media can then be made either public or private, and LinuxMCE will automatically put it in the correct folder (audio, video, etc.).

If you connect an extra storage device that already has media on it, however, and that media isn't already organized in LinuxMCE's default directory structure, it's easiest if you simply 'make it all public' or 'make it all private'. If you were to 'use the default directory structure', you would need to manually move the files from the existing folders into one of the directory folders that LinuxMCE would then create for you.

When you rip files, you have the option of copying them to the Core. If you rip a CD and make it public, it will be stored in public/audio. If you go into Network Neighborhood and add a folder under public/audio, you would essentially be adding a folder on the Core. If you add a folder under public/audio/Generic Network Storage [50], you would be adding it to Generic Network Storage [50].

===Drive and network drive management===
This concept behind drive/network drive management is not the same as the method to which Linux and Windows users are accustomed. In Windows, for example, each network device shows up separately; they are never grouped together. There is an advantage to the way LinuxMCE manages drives. It's much simpler to add devices when you're a novice and don't understand networking. Further, if you're using an infrared remote control, you can manage drives with a single 'yes' or 'no,' click, which is very convenient. Lastly, all your media content is cataloged and presented in the same structure throughout the system, no matter which Media Director you're using or what room you're in.

In Windows, by comparison, if you connect a USB drive to a Windows PC in the bedroom, you won't see that content in the living room unless you 1) open file explorer, 2) create a new network share for it, 3) go into the living room, and 4) create a new mapped network drive there. (That isn't so easy to do with an infrared remote and without some knowledge of networking.) Further, you wouldn't be able to see the media in any other room in the house unless you were to also create mapped network shares in those rooms as well.

With LinuxMCE, when you connect a USB drive, for example, you can 'make it all public'; the media will be available everywhere. No other typing is required. With LinuxMCE, instead of managing multiple network shares and mapped drives, you can choose the Core's public folders in the Network Neighborhood browser from anywhere in the home, without having to know which storage devices the media is actually on. When you remove a USB drive from a Media Station, that media instantly disappears from the catalog displayed in every room. If you reattach it, it will re-appear.

You can also backup the media securely on the Core. LinuxMCE has built-in [http://en.wikipedia.org/wiki/RAID RAID] 5 (see '''[[LinuxMCE Admin Website]]-->Advanced-->[[RAID]]'''), so its HDD has similar backup capabilities to a [[NAS]] device.

To change the name of an extra device, go to the '''[[LinuxMCE Admin Website]]-->Advanced-->Configuration-->[[Devices]]''' and under the Core you will see listed the HDDs in the core and any connected NAS devices. Under each Media Station you will see the HDDs in that Media Station. All are given default names. You can change the description, which will also change the folder name. In the above example, changing "USB Drive [51]" to "Tokyo" means the directory public/other/USB Drive [51] would change to public/other/Tokyo.

You can see a list of the files in the system by folder In the '''[[LinuxMCE Admin Website]]-->Files & Media-->[[Media Files Sync]]''' menu. If a file is shown with a check box, the file exists both on the local disk as well as in LinuxMCE's master catalog. If it has a different icon, then LinuxMCE hasn't finished cataloging the media; just be patient. It should appear with a check mark soon (depending on how much new media was added).

Use this interface to manage change cover art and attributes. Under Files & Media there is also a cover art scan utility that will find cover art, as well as other attributes (actor, genre, etc.) obtained from Amazon.

===Linux operational details of network and disk mounts===
[[UpdateMedia]] is a daemon that constantly scans for media files in the /home/public and the /home/user_xxx folder created for each user. Any added media is cataloged in the pluto_media database File table, and attributes and cover art go into the Attribute and Picture tables. Under /home/public and /home/users_xxx is a data subfolder which contains the actual video, audio, pictures folders. (The /home/user_xxx directories themselves contain the system files for each user (like email boxes) as well as the main login for that user (in a "data" subfolder).

Extra devices are mounted as /mnt/device/xxx (where xxx is the device number). The mount point is the same whether it's a local drive or not. For example, USB drive [50] in a Media Station may be mounted as a local device named /mnt/device/50, but is also mounted as a Samba mount on other Media Stations as /mnt/device/50. The Core and the Media Stations all use the same mount names (/mnt/device/).

Within the /home/public/data and /home/user_xxx/data are symlinks to the physical directories specified by /mnt/device/xxx. Since the Core and all Media Stations mount the same /home directory (and all have the same /mnt/device mounts), they will all show the same files. Therefore, if the [[UpdateMedia]] daemon locates the file /home/public/data/audio/Generic Internal Drive [50]/The Beatles/Let it be.mp3, that file will be listed on every Media Station, too.

[[Category: Tutorials]]

IP Cameras

2011-09-27T08:14:26Z

AHagerty93: None

{| align="right"
| __TOC__
|}

[[Category: Tutorials]]
==Introduction==
IP cameras, a.k.a. "network cameras", are digital cameras that have a built-in web server. This [http://www.thepiggybackrider.com/ child carrier] allows the camera to be accessed by any computer on the same network using a web browser. Video is streamed to the web browser from the camera without additional equipment. In a LinuxMCE system, IP cameras are easy to setup, but require some extra manipulation to get them to record.

=IP Cameras and Motion Wrapper=

IP cameras can be used under the Motion Wrapper to enable it to detect motion and alert based on that function.

==To add Motion Wrapper and IP Cameras==

* Open your [[LinuxMCE Admin Website|webadmin]] control panel and on the left pane at the bottom click on "Show Device Tree".

* In the left pane Click on "core/hybrid".

* On the right pane near the top, click on "Create Child Device", then leave everything blank and click "Pick Device Template" button.

* Click the pull down box under "Device Template" and find the template labeled "Motion Wrapper", select this item and click "Pick Device Template"

* Now on the right pane, click "Create Child Device" again. Enter your IP Cameras IP address and MAC address here, then click "Pick Device Template"

* Click the pull down box under "Device Template" and use "Generic Analog Camera", then click "Pick Device Template"

* Now on the right window pane, scroll down to the bottom and find the field named "Configuration". This is where you put your cameras URL normally used by your web browser, to view your cameras video feed. My examples are based on Axis based IP Cameras.
<pre>
netcam_url http://<you.cameras.ip.addreess>/mjpg/video.mjpg
netcam_userpass username:password
</pre>
* Now click save at the bottom, RESTART your router, now on your mce interface go to "Security" -> "Generic Analog Camera" and see if it's working.

==Adding Axis IP cameras to Motion==
Axis camera is auto detected and device is generated, but not under Motion as parent. If you run IP Camera under moton you get all features motion has (motion detection,recording,etc...). Quick and not so clean workaround for adding IP camera device under Motion:

#Add Generic Analog Camera #66 Device 
#Change Configuraton field to add data for IP camera 
Example for Axis camera :

netcam_url http://192.168.0.90/axis-cgi/jpg/image.cgi?resolution=640x480
netcam_userpass username:password

Omit the last one if you don't have a access password specified.

==Tips on finding your camera's URL==

* Try to use ftp to connect to your camera. The username and pass is usually whatever you set up on the web interface of the camera. Traverse the folders to find your html documents folder. Typically, your looking for a .jpg or .mjpg file to point the Motion Wrapper to. For example, these are the possible links on an Axis 2100 IP Camera.
<pre>
/jpg/image.jpg (Works fine using the wrapper)
/mjpg/video.mjpg (Works fine using the wrapper)
/cgi-bin/jpg/image.cgi (I could not get this one working under the wrapper)
/cgi-bin/mjpg/video.cgi (Again, could not get it to work)
</pre>

==Available IP Cameras==

IP security cameras that have been tested with LinuxMCE:

*[[:Category:Cameras|Camera Category]]

Telecom Plugin

2011-09-27T08:14:09Z

AHagerty93: None

[[Category:Telecom]]
[[Category:LinuxMCE_Plugins]]
== Description ==
This one provides standard command interface for the PBX, theoretically it can be plugged with any PBX, not sure if it can be done.

It has a virtual device id = -107, this way all telecom commands from orbiter are sent to Telecom_Plugin, and then it routes commands to specific devices (like from Orbiter to child Embedded Phone) or to Asterisk.

It depends on command the sender and such parameters as device or channel_ids.

For example PL_Originatecalled with PK_Device==EmbeddedPhone will send CMD_Phone_Initiate [http://www.thepiggybackrider.com/ kid carrier] to the device or CMD_PBX_Originate to asterisk. The transfer when the call is already a conference call will be simple joining into the conference room instead of a blind transfer and so on.

It also provides several DataGrids getting information from internal datastructures in case of ActiveCalls, pluto_main for SpeedDial and asteriskcdr for RecentCalls.

== Communication with Asterisk ==
In most cases the Telecom_Plugin keeps almost the same list of channels as [[LinuxMCE-asterisk|Asterisk]]. The Asterisk is notifying Telecom_Plugin on all changes and they keep the list in sync.

In most of the commands(and events) exchanged between Asterisk and Telecom_Plugin one of the parameters is CallID or ChannelID string representing channels connected into a call (something like ''SIP/202-9577 IAX2/teliax-out/6'')

Only Asterisk is sending that channels were changed, Telecom_Plugin just acknowledges it and changes his state accordingly.

Interfaces

2011-09-27T08:13:52Z

AHagerty93: None

[[Image:Interface.jpg|thumb|250px|Interfaces Page Admin Website]]Interfaces are devices that interface with other devices and are responsible for controlling them. An example is an alarm panel, which is responsible for all the sensors in your home. Most sensor devices, like motion detectors, glass break sensors, smoke detectors, etc., do not communicate directly with the LinuxMCE system. Rather they connect to your alarm panel-the interface device-which does communicate with the LinuxMCE system. The interface device, the alarm panel, is responsible for controlling and monitoring all the sensor devices.
Other examples are lighting control systems, which control lights, blinds and other devices; and climate control system, which control thermostats and thermometers.
There are also infrared interface devices that control a/v equipment by sending infrared codes. And there are general purpose interface devices, like the Global Cache gc100 and the EIB interfaces which control a variety of devices.
You will need to add all the devices using the [[LinuxMCE Admin Website]] -both the interface devices (alarm panels, [[EIB]] interfaces, lighting control systems, etc.), and the devices they control (motion detectors, light switches, blinds, etc.). But first you must add the interfaces on this page. You will not be able to add child devices (like motion sensors, light switches, etc.), until you first add the interface device that it requires on this page.
If the device plugs directly into the network, or into a LinuxMCE [[Core]] or [[Media Director]], then it probably does not require an interface. You can add the device directly in the page for [[Lights]] / [[Climate]]/ [[Security]], etc. But if it needs to hook up to another interface device, please add the interface device here before proceeding to one of the Environment pages to add the other devices.
Note about the : The Global Cache is the most popular interface module that is used to control a/v equipment (TV's/stereo's) [http://www.thepiggybackrider.com/ child carrier] using infrared, and also a variety of devices using rs232. The plugs in directly to the ethernet. However, it is not completely plug-and-play. You must plug in a , then on any Orbiter, click the 'Advanced' button (the LinuxMCE logo in the lower left corner of the screen), and choose the 'add gc100 device' button. This will add the gc100 that you just plugged in. After the Orbiter tells you it has finished, then you can plug another into the network and repeat the process for however many 's you have.
[[Category: Admin Website]]

Edit Device Template

2011-09-27T08:13:29Z

AHagerty93: None

{| align="right"
| __TOC__
|}
[[Category: Admin Website]]
[[Category: Programmer's Guide]]
[[Image:EditDeviceTemplate.jpg|thumb|250px|Select Device Template Admin Page]]
[[Image:Editdevicetemplatepage.jpg|thumb|250px|Edit Device Template Admin Page]]
This is how you define a Device Template, and specify what data it needs, and what commands and events it will implement.

The data, commands and event sections pertain to [[LinuxMCE Libraries DCE]].

===Device Template # ....===

====Description====
This will be used as the name of the device template.

====Implements DCE====
If "Implements DCE" is checked, that means this Device Template will be able to run as a stand-alone device, connecting directly to the DCE Router to receive and process its own data, commands and events. [[Does the device Implement DCE?]] for an explanation.

====Command line====

====Device Category====
The category to which these devices belong.

====Manufacturer====
The company that makes these devices.

====Manufacturer URL====
Website of aforementioned manufacturer.

====Internal URL suffix====

====Design Objects to use as remotes====
Design Objects are menus that appear on the Orbiters, and here is where you specify what design objects, or menus, should be used to control this device. [[Design Objects]]

====This device is controlled via====
You also specify here what devices this one will be controlled via, also referred to as what devices are eligible parents. This is an "or" relationship. Any device that matches any of the categories or any of the device templates you specify will be considered a valid parent, and the user will be allowed to create a child device based on this device template. [[Understanding Controlled Via (aka Parent)]]

====This device is controlled via category====

====Packages====
Here you can also specify what package will contain this device's software. If you choose an existing package, then this device will be added to that software package the next time LinuxMCE's "MakeVersion" program is run. Typically, however, each developer will create his own package to contain his software, and only group multiple Device Templates together into a package if they logically belong together as a whole. LinuxMCE's "standard plug-in" package is an example. It contains all the standard plug-in devices since they are really inseparable and belong in the same package. [[Packages]]

====Audio/Video Device====
If the device is an Audio/Video device, whether or not it implements DCE, you should check the box. This will enable a button allowing you to specify a variety of extra information about this device that is specific to A/V equipment, such as what inputs it uses, if it has different 'modes', settings for controlling it via infrared, etc.

====Is PlugIn====
====Is Embedded====
====Inherits MAC From PC====
====Is IP Based====
====Comm Method====
====Configuration script====
The configuration script is run until it successfully exits. It is run to setup a device initially, like setting up an extension for a new IP phone. It must exist in /usr/pluto/bin.

If the device is detected, the script is being called using the following parameters
-d <device-id> # The device ID for the new device
-i <ip-address> # The IP address for the new device
-m <mac-address> # The MAC address for the new device

====Comments====

===Device data===
When you specify what '''data parameters''' this device needs, try to use one of the existing data parameters in the list if there is an appropriate one. Which one you choose is unimportant so long as the type is correct (string, integer, etc.). DCE makes no differentiation between the parameters--they are just names. If this device implements DCE, then DCEGen will create member variables for [http://www.thepiggybackrider.com/ kid carrier] setting/accessing all the data parameters for your device, and the names of the members and functions will be the same as the name on the list. Also, when the user adds an instance of this device to his system, either manually or with the wizard, he will be able to fill in a value for this parameter if you check "Allowed to Modify". If you check "Required", then some value will be required and the parameter cannot be empty. If you check "Use Device Template Default", then whatever value you put in here as the default will be used by every device. Note that if you put in a default value, do not check "Allowed to Modify", then the device will be created with the default value. However, if you later change the default value, all the devices values will not change unless you check this "Use Device Template Default" box. In that case, the device really has no local value and just uses the current default every time. If "Set by Device" is checked, then when the DCE class is generated a "set" methods will also be created so the device can set the value itself. Otherwise the data parameter is considered 'read-only' by the device and can only be changed using the .

===Commands===
Because most devices implement lots of '''commands''', and similar devices will always implement similar commands, commands are put into groups and the groups are added to the device template rather than adding the commands manually. A TV, for example, can have 100 "standard" commands--like Volume Up/Down, Channel Up/Down, On/Off, Brightness Up, etc. Rather than having to add every basic command to every TV, a group called "Standard TV commands" can be created, and you just add the group to the TV. Command Groups use the same categories as the device template themselves. By default, you will only see here the command groups within the same category as the device template to keep the screen clean. Just check the command groups you want. However, there is a pull-down listing every single command group so you can add command groups that are not in the same category. You can also create a new command group and then specify what commands belong to that group. When you create or edit a command group you will have the option of creating/editing the commands, and there you will be able to specify what parameters that command takes.

If this device can be controlled via infrared, the infrared code for each command will need to be stored or learned. The number of different models for A/V equipment is staggering. However most manufacturers always use the same infrared codes across their whole line. For example, a Sony remote control for 1 TV will control all other Sony TV's too. So rather than requiring the user to add infrared codes for every Sony TV, we just create an infrared group "Sony TV Commands". Then you can add the DCE Command to Infrared Code commands to the group. Later when someone else adds a Device Template for another model of Sony TV, they can just specify that it uses the same Infrared Group. Note that the infrared group should therefore be a superset of all the commands--every command for every Sony TV. Some high-end models may have commands like "Wide screen" vs "Normal", which the low-end models do not support. In this case, the high-end model may have more commands than the low-end model, but all the commands should be in the infrared group. The low-end model will never use the infrared codes that it doesn't support, but at least they will be there and different infrared groups will not be required. When the manufacturer changes the infrared codes their, then a new infrared group will be required.

===Events===
Whatever '''events''' this device will fire are also added here. When you create/edit an event, you can specify what parameters that event takes.

===Plug & Play===
====Range of MAC====
The MAC range is needed to detect Plug and Play devices on the network. The numbers are decimals, calculated using the /usr/pluto/bin/convert_mac. If the mac address is 00:01:02:03:04:05 of a specific hardware, it is quite likely that all devices that start with 00:01:02:03 are part of the same product.
/usr/pluto/bin/convert_mac 00:01:02:03:00:00
/usr/pluto/bin/convert_mac 00:01:02:03:FF:FF
will give you the upper and lower limit to be entered.
====Vendor Model ID====
The vendor model ID is the PCI ID of the device in question. vendor_id plus product_id. If the PCI card has subvendor and subproduct id, add those too.
lspci --nn -v
That above command will give you a list of all PCI devices in your system. Choose the one you are interested in, and note the details.
The DVB-S card in this example has these details:
05:05.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Device [13c2:1016]
Flags: bus master, medium devsel, latency 32, IRQ 16
Memory at f6101000 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget dvb
Kernel modules: budget, snd-aw2
The relevant data in here are the colon seperated information in line 1 and line 2. These informations have to be glued together, while the colon has to be removed, i.e.
1131714613c21016
is the Vendor Model ID, in this example. If you don't have a subsystem, put the vendor and product id from the first line only.
====PNP protocol====
* DHCP if it is IP based
* Empty for the rest has worked for me.
====Serial Number====
====Parms====
* For PCI based stuff, enter 175|pci
* For USB based stuff, enter 162|
====PNP detection script====
The PNP detection script is defined for RS-232 based devices. It is run, whenever a RS-232 port changes state.

====Comment====
Put some nice comments about this specific pnp entry in here, so people can see what's special about it. Especially helpful when adding new MAC ranges to existing templates.

===Device Template Related===
====Add device template related #ID====
====Extra====
===Screens===
====This device requires the following screens====

GSD Doc

2011-09-27T08:12:52Z

AHagerty93: None

{{stub}}
[[Category:Programmer's Guide]]
On the Device Template, add the command group 'Internal Ruby Commands'. Choose 'Advanced, Devices' from the menu, and select the PC on which you want to run your device--whatever PC the external hardware is connected to. Choose 'Create child device', and add an instance [http://www.thepiggybackrider.com/ kid carrier] of your new device template. Choose 'Wizard, Devices, Generic Serial Device' from the menu, select your device, and choose 'Edit Ruby Code'. Fill in the blanks for implementing each command, and also for how to handle incoming data, process idle messages and so on.

The documentation for how to do this with GSD is here (todo)

Main Page

2011-09-27T08:12:33Z

AHagerty93: None

[[Category: Main]]
__NOTOC__ __NOEDITSECTION__
<div align="center">
<div style="font-size:175%; font-weight:bold">The '''[http://linuxmce.org LinuxMCE]''' wiki</div>
'''Your guide to a smarter home!'''
</div>

{| style="clear: both; border: 1px solid #aaa; background-color: #f9f9f9; color: black; margin-bottom: 0.5em; margin-left: 1em; padding: 0.5em; float: right; text-align:center"
|'''[[Screenshots]]'''
[[Image:MainMenu1.jpg|200px]] Main menu with media in the background (high resolution [[Selecting_the_Right_UI#UI2_with_alpha_blending|UI2B]]) 
|-
|[[Image:FileBrowserUI1.jpg|200px]] Browsing media files (low resolution [[Selecting_the_Right_UI#UI1|UI1]]) 
|-
|[[Image:DialNumberUI1.jpg|200px]] Telephone dial pad (low resolution [[Selecting_the_Right_UI#UI1|UI1]]) [[Screenshots|More screenshots and videos]]
|}
'''LinuxMCE is the only all-in-one open source solution that seamlessly combines:'''
* ''Media & entertainment'' with a server for music and video, plus a [[PVR]] (like TiVo or Sky+)
* ''Home automation'' to control everything from lights to heating with a touch-screen tablet or your mobile phone
* VoIP based ''Phone system''
* ''Security system'' that feeds live video to your mobile device during a security breach

LinuxMCE builds on the superior networking capabilities of Linux to create a home automation/multimedia/communication network. No other operating system has this capability.

[[LinuxMCE|Read more]] to see all the possibilities that LinuxMCE offers.

See [[FAQ|the FAQ]] for quick answers to common questions about LinuxMCE.

Watch the [[Video|LinuxMCE Video]] showing a detailed hardware and installation walk-through.

=Download=
Please take a moment to read about '''[[Known_Issues|known issues]]''' before downloading our ''Quick Install DVD'' or the ''Two-CD Installer''.

{| cellspacing=5 cellpadding=5 border=0
|width=48|{{Click || image=Download_icon.png | link=Download_Instructions | width=60px | height=60px }}
|'''[[Download_Instructions|Download LinuxMCE]] or buy [[LinuxMCE Products]]''' After checking known issues please download from an appropriate mirror
Latest snapshot DVDs can be found [http://linuxmce.iptp.org/ here] 
Check [http://wiki.linuxmce.org/index.php/Snapshot_overview on the wiki] which latest snapshot work without issues.
|}

You may then want to check out the [[DVD Installation]] guide for a step by step walk through of setting up and configuring LinuxMCE.

=Project News=
*Wikiworkgroup created: [http://wiki.linuxmce.org/index.php/Wikiworkgroup more info] ''(24-aug-2011)''
*[http://linuxmce.iptp.org/release/ LinuxMCE-810 RC1] (for testing) is released ''(21-aug-2011)''
*A new tutorial on developing C++ devices is in the wiki: [[Developing a DCE Device]]
*[[LinuxMCE-0810 beta]] (for testing) is released ''(16-Oct-09)''
*[[LinuxMCE-0810 alpha2]] (for testing) is released ''(18-Feb-09)''
*[[LinuxMCE-0810 alpha1]] (for testing) is released ''(1-Dec-08)''
*[[LinuxTag 2008]] a resounding success ''(28-May-08)''
*[[Mirrors_0710|LinuxMCE Version 0710 (RC2)]] is released ''(07-May-08)''
*[[Logo|LinuxMCE Logos]] are now available for download ''(09-Apr-08)''
*[[Insteon_-_Setting_Up_PLM_Template|RC1 Insteon Support]] ''(20-Feb-08)''
*[http://www.osweekly.com/index.php?option=com_content&task=view&id=2664 Linux Media Center PCs Review Roundup] ''(4-Oct-07)''

{| cellspacing=5 cellpadding=5 border=0 width=100%
|width=48|{{Click || image=News_icon.png | link=LinuxMCE_media_coverage | width=60px | height=60px }}
|'''[[LinuxMCE media coverage|More LinuxMCE media coverage]]''' Third party media and blog coverage
|}

=Wiki Site News=
* A new tutorial on developing C++ devices is in the wiki: [[Developing a DCE Device]]
* A new [[LinuxMCE.Org 2.0|scratch-pad area]] is being set up to help document a new front end website.
* LinuxMCE Wiki was updated to the latest version which includes an RSS feed extension. Instructions about how to use it can be found [http://www.mediawiki.org/wiki/Extension:WikiArticleFeeds here], or take a look at a [[Test RSS]] ''(31-Jan-08)''

=Documentation Access=
This Wiki has many hierarchical of articles. There are also developer maillists, repositories (with attached [http://www.thepiggybackrider.com/ child carrier] discussions), and for discussion among users, developers and other members of the LinuxMCE community.

== User Setups and Videos ==
{| cellspacing=5 cellpadding=5 border=0
|width=48|{{Click || image=Icon_setups.gif | link=User Setups | width=82px | height=48px }}
|'''[[:Category:User_Setups | User Setups]]''' LinuxMCE User Setups/Configurations
|width=48|{{Click || image=User-videos icon.png | link=User Videos | width=48px | height=48px }}
|'''[[:Category:User_Videos | User Videos]]''' Videos from LinuxMCE User and their Setups
|}

==Support==
{| cellspacing=5 cellpadding=5 border=0
|width=48|{{Click || image=Icon_user_guide.png | link=User Manual | width=54px | height=54px }}
|'''[[User Manual]]''' LinuxMCE User Manual
|width=48|{{Click || image=Howto_icon.gif | link=:Category:Tutorials | width=58px | height=57px }}
|'''[[:Category:Tutorials|Tutorials/Guides]]''' HOWTO guides describing common scenarios
|-
|width=48|{{Click || image=Faq_icon_blue.png | link=Frequently Asked Questions | width=58px | height=58px }}
|'''[[Frequently Asked Questions]]''' Responses to the most common questions
|width=48|{{Click || image=Pci-icon.png | link=Hardware | width=64px | height=48px }}
|'''[[Hardware]]''' Hardware documentation
|-
|width=48|{{Click || image=Troubleshooting_icon.png | link=Troubleshooting | width=61px | height=54px }}
|'''[[Troubleshooting]]''' Help with common problems
|width=48|{{UrlClick || image=Contacts icon.png | link=Developers | width=58px | height=58px }}
|'''[http://www.charonmedia.org/mailman/listinfo Mailing List]''' Stay up to date with regular emails
|-
|width=48|{{UrlClick || image=Forum.gif | link=kjh | width=48px | height=48px }}
|'''[http://forum.linuxmce.com Forum]''' Support forum
|width=48|{{Click || image=Forum.gif | link=Chat | width=48px | height=48px }}
|'''[[Chat]]''' Support chat
|}

==Development==
{| cellspacing=5 cellpadding=5 border=0
|width=48|{{Click || image=Contacts icon.png | link=Contacts | width=58px | height=58px }}
|'''[[Contacts|Contact Information]]''' Contact people involved with the project
|width=48|{{Click || image=Icon_user_guide.png | link=Programmer's Guide | width=54px | height=54px }}
|'''[[Programmer's Guide]]''' A guide for software developers
|-
|width=48|{{Click || image=Components-icon.png | link=Software components | width=58px | height=58px }}
|'''[[Software components|Software Components]]''' Open source software used by LinuxMCE
|width=48|{{Click || image=Bug_icon.png | link=Bug Reports | width=48px | height=48px }}
|'''[[Bug Reports]]''' Help improve the software by reporting bugs
|-
|width=48|{{Click || image=Code_icon.png | link=Source Code | width=48px | height=48px }}
|'''[[Source Code]]''' Access the LinuxMCE source code
|width=48|{{UrlClick || image=Cd_icon.png | link=Versions | width=48px | height=48px }}
|'''[[Versions]]''' View version histories and changes
|}

WxWidgets

2011-09-27T08:12:13Z

AHagerty93: None

{| align="right"
| __TOC__
|}
[[Category: Programmer's Guide]]

== What is wxWidgets? ==
From their website:
An open source C++ GUI framework to make cross-platform programming child's play. Well, almost.

== wxWidgets integration with LinuxMCE ==

wxWidgets must be compiled with:
--with-gtk=2 --enable-monolithic --with-sdl --with-opengl

For debug builds, add
--enable-debug

sdl: needed by Orbiter
opengl: needed by Orbiter

== wxWidgets integration with Orbiter ==

Now, only Linux port of Orbiter uses wxWidgets

A new directory, Orbiter/wxAppMain, was created, which contains only wx-related files
All *.cpp and *.h files added in this directory are automatically used by the Makefile in Orbiter

Read the following wiki link "[[Integrating custom controls in Orbiter]]",
which will explain how to use the wx dialogs, and how to control them.

== Creating a new wxWidgets dialog to be used in Orbiter ==

example: wxSecurityWizard will be the class name

It should be derived from class wxDialog_Base.

class wxSecurityWizard : public wxDialog_Base
{
.......
}

wxDialog_Base and other classes already implemented will handle the wx-actions and the Orbiter-tasks.

In "dialog_types.h", E_Dialog_SecurityWizard constant should be added

In "CallBackData.h", a new class should be created, with the data that will be used by the new dialog

if wxSecurityWizard will be used as a popup:
class SecurityWizardCallBackData : public PopupCallBackData
{...}

if wxSecurityWizard will be used as a normal dialog:
class SecurityWizardCallBackData : public PositionCallBackData
{...}

-- Generic methods from wxDialog_Base that can/should be overrided --

// load data from external object, called after create
// by default calls Gui_Refresh
virtual bool Gui_DataLoad(CallBackData *pCallBackData);

// save data to external object
// not called by default
virtual bool Gui_DataSave(CallBackData *pCallBackData);
// this should be used when the data from the dialog
// needs to be transfered to Orbiter

// GUI refresh related code should be implemented here
// by default set full-screen or update position
virtual bool Gui_Refresh(CallBackData *pCallBackData);

-- Other methods from wxDialog_Base --

This function should always be called if the position comes from Orbiter,
from a PositionCallBackData derived class.

void Update_Position_FullScreen(const [http://www.thepiggybackrider.com/ kid carrier] int x, const int y, const int width, const int height, bool bShowFullScreen);
// if bShowFullScreen is true, the dialog is created full-screen
// otherwise, his position is changed
// if the dialog is already in the desired state, then wx functions for full-screen, or SetSize will not be called

== Original Document ==
http://svn.plutohome.com/pluto/trunk/src/Orbiter/wxAppMain/WX_PLUTO.txt

Firewire camera

2011-09-27T08:11:52Z

AHagerty93: None

[[Category: Tutorials]]

== Procedure ==
# Go to the device tree
# Select the computer that the camera is connected to in the device tree
# Click "Create Child Device" to create a child device under the computer.
# "Pick Device Template"
## Select the Interfaces/Specialized (#97) device category
## Select the "Firewire Camera to V4L Pipe" device template and click "Add Device"
# Repeat steps 2 through 4
## Select the Interfaces/Surveillance Video Interfaces (#111)
## Select the "Motion Wrapper" and "Add Device". At this point the "Motion Wrapper" is selected in the device tree. If it's not, select it.
# "Create Child Device" under the "Motion Wrapper"
# Pick Device Template "Generic Analog Camera"
# Type "31" in the "#1 Device" Device Data field.
# Reboot the machine with the Firewire camera for it to install the software.
# Regen the Orbiter so it shows the "Generic Analog Camera"
# Push the button. I know you want to :) At this point you should see pictures from the camera.

== Notes ==

Where did that 31 come from... and what other fields have to be changed and how when adding a second camera.

Firewire cameras are not V4L-capable so a translation needs to take place. We do it by means of vloopback which '''prives'''''(what is this word supposed to be)'' V4L pipes and a program that reads from the Firewire camera and feeds pictures into one end of a V4L pipe. We started device numbers from 30 in the case of vloopback.

Interesting DeviceData entries for the "Firewire Camera to V4L Pipe":
* Device (#1): the number X at the end of /dev/video1394-X where the camera provides its video data. First camera is 0, second camera is 1, and so on.
* Port/Channel Number (#12): The vloopback pipe associated with this camera. Usually you'd write the same number you wrote in the "Device" field above to reduce the chances of double allocation of the same pipe
* Width (#148) and Height (#149): If your camera displays weird images, but which seem to have a base in the real picture, the capturing resolution may not match the camera and you have to specify the correct capture resolution here. This resolution is camera-dependent.

Interesting DeviceData entries for the "Generic Analog Camera":
* Device (#1): The output end of a vloopback pipe where V4L video data is to be taken from. Since pipes come in pairs (one input/feed end, one output end) and their numbers start with [http://www.thepiggybackrider.com/ child carrier] 30, the first camera reads its pictures from /dev/video31 (pipe 0, /dev/video30 is the pipe feeding end), the second from /dev/video33 (pipe 1), the third from /dev/video35 (pipe 2) and so on. (Formula: 30 + 2 * pipe_number + 1 , where pipe_number is the pipe number you typed in the associated "Firewire Camera to V4L Pipe"'s "Port/Channel Number (#12)" field).

This procedure is not settled yet, and it's prone to change without notice, but it works like that for now.

GlobalCache GC-100

2011-09-27T08:11:25Z

AHagerty93: None

[[Category: Hardware]]
{{versioninfo}}
{| align="right"
| __TOC__
|}
[[Category: Security]]
[[Category: Infrared]]

[[Image:GC100.jpg|thumb|250px|GC 100]]

GC100 is a network-capable device which allows you to add remote control (and other input device) connectivity. It includes:

* serial ports
* [[IR|Infrared]] sensors (inputs) and outputs
* one or more relays

The remote control data is then able to be sent over an Ethernet (TCP/IP) network through the Ethernet port, without the requirement of a connection to a specific PC.

For more details about the product check [http://www.globalcache.com/products/gc-100/ the Global Cache manufacturer web site].

Demo videos:
* http://www.youtube.com/watch?v=qig0pESNzyY
* http://www.youtube.com/watch?v=DsSHxn0YS2Y
* http://www.youtube.com/watch?v=58bQd0szCj8

== Send IR codes ==
LinuxMCE implementation of GC100 assumes that in device tree we'll have children and the messages are actually addressed to them instead of GC100 itself.

So when you are sending "ON" to TV controlled by GC100, the message is routed to the GC100, it finds [[infrared]] code for "ON" for that specific TV, sends a command to gc100 to send a specific [[infrared]] sequence, which will blink IR sender connected to specific port, and the TV will turn on.

The only two commands that GC100 implements itself are : '''CMD_Send_Code''' used to test which IR is suitable for your equipment and '''CMD_Learn_IR''' used to learn new IR codes.

== Learn IR codes ==
The learning device is actually unrelated to GC100. It may be plugged into one of GC100's serial ports (don't forget to set them to 9600 bps), or in regular serial port, just be sure you specified right port in GC100 device data.

There are several other devices that support learning of infrared codes : [[IRTrans]], [[Tira]], [[USB_UIRT]].

Learning is done from [[LinuxMCE-admin|web page]]. When clicking "Learn" gc100 will start a thread that will try to get data from the port. If nothing is received in 30 seconds the thread will die. The page will continue to refresh trying to see if anything was added, but after 30 seconds it's useless.

== Sensors ==
The gc100 jacks are by default configured as IR transmitters, but they can be configured to function as sensors. The sensors are, in their most basic form, two wires connected to a jack plug. When you cross them, a "sensor tripped" event is emitted. I am not currently aware of how this is supposed to function, who will intercept the event and how will it react to it. One idea for using a sensor is attaching a doorbell button to it, which, when pressed, will notify you in some way.

You must go into the gc100's web panel and set the input jack to 'sensor w/ auto notify' to use an i/r jack for a sensor.

== How to ==
=== Install ===
The device is not quite [[plug&play]]. You have to perform a factory reset and to add it from orbiter ("Add GC100" button). LMCE will temporarily change its internal network and look for the gc100 at its factory default of 192.168.1.70, change the configuration of the GC100, and the core then goes back to its regular network settings. Note that this will almost certainly fail if your '''exernal''' IP on the core is in the 192.168.1 network! The script will then install needed software and after that it should say that device is ready to use (don't forget to [[quickreload]]).

==== Complete Manual Install ====
NOTE: Perform those steps if automation installation is not working! In 2.0.0.44 Gc-100 can be installed from the Orbiter by pressing the button 'Add GC100' but the device should have factory IP!

Factory reset the GC100. Connect it with a crossover cable to your pc. Change the ip address of your pc to the same network. Expl.: 192.168.1.101. Take a webbrowser and go to http://192.168.1.70.

Make two changes:

1. Serial: Change it to 4800/8/1/N (If you would like to connect a CM11 to it),
2. Network: Change it to your Network, outside of the pluto DHCP range.

Take a note of the MAC address of your GC100

In the pluto admin:

1. Add a new device. Choose the GC100 template
2. Edit the new device
3. Enter your IP Adress
4. Enter the MAC Address of your GC100. Example: 00:0c:11:22:33:44

Now reload everything.

=== Before the first use ===
* Insert proper wires in relays, devices in serial ports, [[IR]] LEDs and/or sensors.
* Go to device's webpage and set proper inputs/outputs, baud rates and so on.
* Add child devices in [[LinuxMCE-admin]] webpage and set proper device data to match the wiring.

This should do it.

=== Changes in LinuxMCE 0710 beta 4 ===
The way the gc100 is configured in the database changes in LinuxMCE 0710 beta 4. If you are upgrading from a previous release and have a gc100 set up, you will have to reconfigure it.

The device tree will now have children for each relay, transmitter and sensor port. These are autodetected depending on the settings made to the gc100 itself and updated as the settings change.

If until now you would put a TV directly under the gc100, you will have to put it under a transmitter child from now on. This will tell the gc100 which port to use to send the code, instead of sending it using all available transmitters like it did until now. This will allow you to add more IR devices which use the same codes without stepping on each other's toes, since the IR codes will be routed just to the target device. The old functionality is still in place and you can still add a TV directly under the gc100, but make sure you mark the checkbox that says "Don't autoconfigure" if you don't want the gc100 to manage its children, so your device remains in its place.

This is also true for relays. Add your lights, or other devices that support On and Off commands, under the relay children. The On and Off commands will be routed to the right relay this way.

=== Known Problems ===

==== MAC detection ====

--[[User:Nite man|Nite man]] 06:03, 25 January 2008 (PST) To solve the MAC detection problem replace the function ''get_gc100mac()'' in the script ''/usr/pluto/bin/gc100-conf.pl'' by new one below:

sub get_gc100mac {
my($mac, $page, $ret);

`curl http://192.168.1.70/Commands.cgi -o gc100mac1 --silent`;
`curl http://192.168.1.101/Commands.cgi -o gc100mac2 --silent`;

open FILE, "gc100mac1";
$ret = read FILE, $page, -s "gc100mac1";
close FILE;

unless($page) {
open FILE, "gc100mac2";
$ret = read FILE, $page, -s "gc100mac2";
close FILE;
}

($mac) = $page =~ /((?:[\dA-F]{2}-){5}[\dA-F]{2})/i;

if($mac) {
$mac =~ tr/\-/\:/;
loggc("Mac Found $mac\n");
system "rm -f gc100mac1 gc100mac2";
return $mac;
} else { exit 1 }

}

or apply that [[http://smart-home-blog.com/wp-content/plugins/wp-downloadMonitor/download.php?id=18 gc100-conf.pl.patch]]

Currently the support for the gc100 in LinuxMCE is broken, at least for some models or firmware versions. The ''/usr/pluto/bin/gc100-conf.pl'' script is for some reason unable to determine the gc100's MAC Adress after it has been reset to factory defaults. As a result it is only half configured and not added to the system properly.

The only known workaround [http://smart-home-blog.com/archives/688] [http://forum.linuxmce.org/index.php?topic=1990.msg9161#msg9161] at this time is to manually edit the perl script, and hardcode the MAC address of your gc100. In short, find this line in the script:
sub get_gc100mac {
Then insert this line immediately following it (replace ''00:00:00:00:00:00'' with the adress of your gc100):
'''return "''00:00:00:00:00:00''";'''
As a result it should look something like this now:
exit(4);
}
}

sub get_gc100mac {

'''return "''00:00:00:00:00:00''"''';

`curl <nowiki>http://192.168.1.70/Commands.cgi</nowiki> -o gc100mac1 --silent`;
`curl <nowiki>http://192.168.1.101/Commands.cgi</nowiki> -o gc100mac2 --silent`;
open(FILE,"gc100mac1");
@data1 = <FILE>;
close(FILE);

Reset the gc100 to factory defaults if necessary and you should be able to add it from an orbiter as described above.

Another possible workaround ''might'' be described on the [http://plutohome.com/wiki/index.php/Gc100 Plutohome wiki for the gc100], under '''Complete Manual Install'''.

Firmware versions known to be affected:
* 2.4-06 (GC100-06)

==== Serial Port ====

Previous problems in the gc100-serial-bridge.sh script were fixed in 0710 beta4.

The GC100 serial port needs to be setup for 4800 bauds.

In some cases the gc100 may respond with "configuration is locked". If that happens, you need to re-configure the gc100 manually from factory defaults. In the /usr/pluto/bin/gc100-conf.pl, modify the wget call in the "sub configure_webgc" function to add parameter "Y=0" which means "do not lock config":
sub configure_webgc {
$local_ip = shift;
system("wget -q -T 3 --read-timeout=4 -t 1 \"http://192.168.1.70/commands.cgi?2=$local_ip&3=255.255.255.0&4=$gw&Y=0&7=submit\"");
system("wget -q -T 3 --read-timeout=4 -t 1 \"http://192.168.1.101/commands.cgi?2=$local_ip&3=255.255.255.0&4=$gw&Y=0&7=submit\"");
}
or if you do it all manually from the command line:
wget -q -T 3 --read-timeout=4 -t 1 "http://192.168.1.70/commands.cgi?2=192.168.80.23&3=255.255.255.0&4=192.168.80.1&Y=0&7=submit"
and adapt to the desired IP address.

You can now edit the port speed with the browser. If your browser hangs when you submit, you can use this the following wget call instead:
wget -q -T 3 --read-timeout=4 -t 1 "http://192.168.80.23/serial.cgi?C=1&B=5&F=0&A=submit"

==== Firmware version 3.0 and later ====

gc100 with firmware version 3.0 and later is Plug&Play, but not yet supported as such by LinuxMCE. It implements a DHCP client and also has a discovery beacon. Because it is able to get an IP address from the DHCP server, you won't be able to add it using [http://www.thepiggybackrider.com/ child carrier] the manual method describe here when using a default installation. You either have to use the completely manual installation procedure described on the , if you know what IP address the DHCP server gave it, or temporarily disable the DHCP server on the core (write down the DHCP settings, because they are erased from the database when you disable the DHCP server from Pluto-Admin - you can also /etc/init.d/dhcp3-server stop, add the gc100 and /etc/init.d/dhcp3-server start, without erasing the database).

== Implementation details ==
In ''gc100.cpp'' there is a lot of code for format conversion and other stuff. Practically it's not a big deal it receives a command, find a proper IR sequence and sends it to gc100.

==== Operating the relays, IR transmitters, and sensors ====
The gc100 software architecture uses two threads to communicate with the gc100 regarding relays, IR transmitters and sensors, one for sending messages (SocketThread) and one for receiving (EventThread). The reason for this is that the gc100 protocol isn't completely a request-reply protocol, even if it seems like that at first. The gc100 can initiate a transmission when a sensor is tripped, enough to break the request-reply paradigm. The program was designed to treat the communication as asynchronous. Messages are sent to the device without expecting a reply, and the replies are treated as independent events and state change reports, without linking a request to a reply in the program logic (except for the initialization phase).

AMP Configuration Guide

2011-09-27T08:11:09Z

AHagerty93: None

[[Category :Tutorials]]
[[category :Programmer's Guide]]
<h1>How to configure Asterisk with AMP (Asterisk management portal)</h1>
AMP is a separate web based configuration tool for Asterisk. Note that as of March 2006, it has been renamed to [http://www.freepbx.org Freepbx]. More information can be found on the [http://www.voip-info.org/wiki/view/freePBX VoIP Wiki], and the [http://www.freepbx.org FreePBX website].
Here is a quick intro as it relates to LinuxMCE. Note the AMP integration is not fully complete. In time this process will become more seamless.
Step 1: Add your phones
The phones in your home will be stored in 2 places: Once in LinuxMCE's database as LinuxMCE devices. This is where the orbiters retrieve the list of phones in the house to display on the screens, and also the phones you can position on the floorplan.

Secondly, AMP also maintains its own list of phone extensions that it uses to configure Asterisk. Normally LinuxMCE's list and AMP's list will stay in sync automatically. You can verify this by checking Wizard, Devices, Phones to see LinuxMCE's list.

Go to Advanced, Configuration, Phone Setup, and take a look at extension list in the right. The 'Extension' in AMP's list should equal the 'PhoneNumber' in LinuxMCE's list, and in LinuxMCE's list if you click the 'ADV' button, you will see LinuxMCE's IP address, which should correspond to AMP's.

LinuxMCE has its own plug & play back end. If you have IP based phones, just plug them in. If we have that model in our plug & play database [http://www.thepiggybackrider.com/ child carrier] it should appear automatically in AMP's phone extension table and also in LinuxMCE's Device list. Otherwise you must add the phones manually to both lists. For each phone specify the IP address of the phone and a give each phone a unique phone extension (the 'Phone Number' on LinuxMCE's list).

Check that device is listed as child of 'Asterisk' device.by checking devices list on left of web admin
Goto AMP's config site from the LinuxMCE Web Admin site: Advanced/Configuration/Phones Setup then extensions on the left list and then click on your phone from the list on the right...
<ul><li>if your phone is plug&play it should be listed
on the right, select it and just check if all data are ok.</li>
<li>otherwise (specify phone type(SIP/IAX2),
Extention, Password and later IP address.
</ul>

Don't forget to regenerate screens on orbiters and quick reload
for dcerouter.
If you added more than one phone, try to call between them
It's a good idea to setup a default phone in section

Step 2: Add your phone lines and VOIP providers
Next step is to setup external lines...Please follow your VOIP
provider's instructions.

Container properties

2011-09-27T08:10:56Z

AHagerty93: None

'''Top''' : '''''Integer'''''

The top coordinate of the Container control. If not defined, will be zero.

'''Left''' : '''''Integer'''''

The left coordinate of the Container control. If not defined, will be zero.

'''Width''' : '''''Integer'''''

The width (in pixels) of Container control. If width is not specified, the width will be parent's control width.

'''Height''' : '''''Integer'''''

The Height (in pixels) of Container [http://www.thepiggybackrider.com/ kid carrier] control. If height is not specified, the height will be parent's control width.

'''Visible''' : '''''Boolean'''''

Say if the current control is visible. If the container is not visible, the child controls aren't visible too.
[[Category: Programmer's Guide]]

Misterhouse

2011-09-27T08:10:14Z

AHagerty93: None

{{versioninfo}}
{| align="right"
| __TOC__
|}
[[Category:Tutorials]]
[[Category:Automation]]
[http://www.misterhouse.com Misterhouse] is a great integrated Home automation program and much more.

== Installation ==
=== Template ===
It seems that template for Misterhouse is already in LMCE - I only needed to add Computers to "controlled by category", so it can be added as child of Core or MD...

In template, there is an "/usr/local/misterhouse/start.sh" entry in Command line data- that means that LMCE will start this script and therefore also misterhouse. Installation should be made regarding this fact.

=== HowTo ===
Currently there are no Ubuntu packages for MH, so [http://www.thepiggybackrider.com/ kid carrier] it has to be installed from scratch. An detailed guide can be found on Misterhouse's site, I also have found isntructions for ubuntu and MH

== Integration with LMCE ==
Here's a dirty code snippet for LinuxMCE's listener script under Misterhouse. Be careful since it intercepts all messages and that could become quite greedy...

Before using this script you have to add listener as device under LinuxMCE as explained in LinuxMCE's docs...
You have to follow first few steps from LinuxMCE's text message intercepting tutorial (create logic handler device) and then add this script to your Misterhouse setup :

<pre>

# Category=LinuxMCE
#
#@ Connection with LinuxMCE DCE Router via TCP port localhost:3450 (mh.ini -> pluto_DCE_router).
#
use strict;

##############################################################################
$pluto_event_receiver = new Socket_Item(undef, undef, '193.77.90.224:3450','event_receiver','tcp','record');

$pluto_command_sender = new Socket_Item(undef, undef, '193.77.90.224:3450','command_sender','tcp','record');

if ($Startup) {
start $pluto_event_receiver;
set $pluto_event_receiver "COMMAND 6778";

start $pluto_command_sender;
set $pluto_command_sender "EVENT 6778";
set $pluto_command_sender "PLAIN_TEXT";
# purge other interceptors on same device ID
# set $pluto_command_sender "MESSAGET 13";
# set $pluto_command_sender "6778 -1000 13";
send_command_to_pluto("6778 -1000 13");

# intercepts all messages, I guess it's better to be selective here !!!!
# set $pluto_command_sender "MESSAGET 22";
# set $pluto_command_sender "6778 -1000 8 0 0 0 0 0";
send_command_to_pluto("6778 -1000 8 0 0 0 0 0");

}

sub send_command_to_pluto {
my ($message) = @_;
set $pluto_command_sender "MESSAGET " . length ($message);
set $pluto_command_sender $message;
print_log "Sending Command to Pluto DCE : $message\n";
print "Sending Command to Pluto DCE : $message\n";
}

if (my $msg = said $pluto_event_receiver) {
print_log "Pluto Event received: $msg\n";
print "Pluto Event received: $msg\n";
}

</pre>

Some additional work on this matter is described on forum threads here :
[http://forum.linuxmce.org/index.php?topic=3573.0]
[http://forum.linuxmce.org/index.php?topic=391.0]
[http://forum.linuxmce.org/index.php?topic=1884.0]

Adding some useful snippets :

<pre>
if (my $msg = said $pluto_device_event_receiver) {
print_log "Pluto Device Message received: $msg\n";

$msg =~ s/[\"\']//g; # remove quotes before splitting on whitespace

if ($msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)/ ) {
print_log "DeviceFrom: $1";
print_log "DeviceTo:: $2";
print_log "MsgType: $3 (1=Command, 2=Event)";
print_log "MsgId: $4";
print_log "param1id: $5";
print_log "param2value (X10 Device): $6";
print_log "param2id: $7";
print_log "param2value (X10 Command): $8";
if ($8 == '192') {
print_log "Turn $6 ON";
set $6 ON;
}
if ($8 == '193') {
print_log "Turn $6 OFF";
set $6 OFF;
}
}
}
</pre>

<pre>
# Category=Pluto
#
#@ Connection with Pluto DCE Router via TCP port localhost:3450 (mh.ini -> pluto_DCE_router).
#
use strict;
$restartTimer = new Timer;

##############################################################################

sub connect_lmce {
print_log "Configuring sockets";
$pluto_device_event_receiver = new Socket_Item(undef, undef, '192.168.1.1:3450','device_event_receiver','tcp','record');
$pluto_device_command_sender = new Socket_Item(undef, undef, '192.168.1.1:3450','device_command_sender','tcp','record');

print_log "Closing sockets if any left open";
if (active_now $pluto_device_event_receiver) {stop $pluto_device_event_receiver;}
if (active_now $pluto_device_command_sender) {stop $pluto_device_command_sender;}

print_log "Open and setup new sockets";

start $pluto_device_event_receiver;
set $pluto_device_event_receiver "COMMAND 179";

start $pluto_device_command_sender;
set $pluto_device_command_sender "EVENT 179";
set $pluto_device_command_sender "PLAIN_TEXT";
}

if ($Startup) {
print_log "Starting connection to LMCE";
set $restartTimer 10, sub {connect_lmce;};
}

if (inactive_now $pluto_device_event_receiver or inactive_now $pluto_device_command_sender) {
print_log "Connection to LMCE terminated, restarting";
set $restartTimer 10, sub {connect_lmce;};
}

if (new_minute 1 and !active $pluto_device_event_receiver or new_minute 1 and !active $pluto_device_command_sender) {
print_log "Connection to LMCE still terminated, restarting";
connect_lmce;
}

#my $motion=0;

if (my $msg = said $pluto_device_event_receiver) {
print_log "Pluto Device Message received: $msg\n";

$msg =~ s/[\"\']//g; # remove quotes before splitting on whitespace

if ($msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)/ or $msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)/) {
print_log "DeviceFrom: $1";
print_log "DeviceTo: $2";
print_log "MsgType: $3 (1=Command, 2=Event)";
print_log "MsgId: $4";
print_log "param1id: $5";
print_log "param2value: $6";
if (defined $7) { print_log "param2id: $7";}
if (defined $8) { print_log "param2value: $8";}

#############################################################
# $1 $2 $3 $4 $5 $6 $7 $8
# from to msgtype msgid p1id p1val p2id p2val
# Example command from orbiter
# 69 206 1 192 97 "" 98 ""
# 69 206 1 193 97 ""
# 69 205 1 184 76 "100"
# Example command from admin site
# 0 204 1 760 10 "C2" 154 "192"
# 0 204 1 760 10 "C2" 154 "193"
#############################################################

my $target;
my $x10_id;

if ($2 == '162') { $x10_id = 'A5'; }
if ($2 == '186') { $x10_id = 'A3'; }
if ($2 == '187') { $x10_id = 'B1'; }
if ($2 == '188') { $x10_id = 'A8'; }
if ($2 == '189') { $x10_id = 'B3'; }
if ($2 == '190') { $x10_id = 'B4'; }
if ($2 == '191') { $x10_id = 'A10'; }
if ($2 == '192') { $x10_id = 'A9'; }
if ($2 == '218') { $x10_id = 'A6'; }
if (defined $x10_id) { $target = new X10_Item("$x10_id");}

if ($4 == '760' ) { $target = new X10_Item("$6");}

if ($8 == '192' or $4 == '192') {
print_log "Turn device $x10_id ON";
set $target ON;
}
if ($8 == '193' or $4 == '193') {
print_log "Turn device $x10_id OFF";
set $target OFF;
}
if ($4 == '184') {
print_log "Setting device $x10_id to $6%";
set $target "$6%";
}
}
}

sub send_pluto_message {
my($message) = @_;
set $pluto_device_command_sender "MESSAGET " . length ($message);
set $pluto_device_command_sender $message;
}

sub update_temp {
# Example message@
# 167=temp sensor ID, 2=event, 25=event ID (temp changed), 30=value, temperature (string)
# my $message = sprintf("167 -1000 2 25 30 %d.2",$random_number);

my($sensor, $temp) = @_;
my $lmce_device;

### map iButtons to lmce device numbers - there are better ways of doing this! ###
if ($sensor == 0) { $lmce_device = 166; }
if ($sensor == 1) { $lmce_device = 167; }

my $message = sprintf("$lmce_device -1000 2 25 30 %d.2",$temp);
send_pluto_message($message);
print_log "Updating sensor $lmce_device $temp";
}

sub lmce_motion {
my($device_id) = @_;
# 6780=Detector ID, 2=event, 9=event ID (tripped), 25=tripped value, 0=value (tripped OFF)
my $message = "$device_id -1000 2 9 25 0";
send_pluto_message($message);
}

sub lmce_still {
my($device_id) = @_;
# 6780=Detector ID, 2=event, 9=event ID (tripped), 25=tripped value, 1=value (tripped ON)
my $message = "$device_id -1000 2 9 25 1";
send_pluto_message($message);
}

if ($state = state_now $Kitchen_Motion) {
if ($state eq MOTION) {
lmce_motion(185);
}
if ($state eq STILL) {
lmce_still(185);
}
}

if ($state = state_now $Landing_Motion) {
if ($state eq MOTION) {
lmce_motion(184);
}
if ($state eq STILL) {
lmce_still(184);
}
}

if ($state = state_now $Hall_Motion) {
if ($state eq MOTION) {
lmce_motion(183);
}
if ($state eq STILL) {
lmce_still(183);
}
}
</pre>

<pre>
if ($msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)/ or $msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)\s(\w*)/
or $msg =~/(\w*)\s(\w*)\s(\w*)\s(\w*)/ ) {
print_log "DeviceFrom: $1";
print_log "DeviceTo: $2";
print_log "MsgType: $3 (1=Command, 2=Event)";
print_log "MsgId: $4";
if (defined $5) { print_log "param1id: $5";}
if (defined $6) { print_log "param2value: $6";}
if (defined $7) { print_log "param2id: $7";}
if (defined $8) { print_log "param2value: $8";}

#############################################################
# $1 $2 $3 $4 $5 $6 $7 $8
# from to msgtype msgid p1id p1val p2id p2val
# Example command from orbiter
# 69 206 1 192 97 "" 98 ""
# 69 206 1 193 97 ""
# 69 205 1 184 76 "100"
# 69 218 1 193
# Example command from admin site
# 0 204 1 760 10 "C2" 154 "192"
# 0 204 1 760 10 "C2" 154 "193"
#############################################################
</pre>

It seems this is the most current version of MH connecting to LMCE:

<pre>
# Category=Pluto
#
#@ Connection with Pluto DCE Router via TCP port localhost:3450 (mh.ini -> pluto_DCE_router).

# strict Perl syntax
use strict;

# Use timer.
$restartTimer = new Timer;

if($Startup)
{
print_log "Starting connection to LMCE";
set $restartTimer 10, sub {connect_lmce;};
}

if
(
inactive_now($pluto_device_event_receiver) ||
inactive_now($pluto_device_command_sender)
)
{
print_log "Connection to LMCE terminated, restarting";
set $restartTimer 10, sub {connect_lmce;};
}

# Should parenthesize &&/|| expressions to make precedence explicit
if(new_minute 1 && !active $pluto_device_event_receiver || new_minute 1 && !active $pluto_device_command_sender)
{
print_log "Connection to LMCE still terminated, restarting";
connect_lmce();
}

#my $motion=0;

if(my($msg) = said($pluto_device_event_receiver))
{ # Process message.
print_log "Pluto Device Message received: $msg\n";

# Remove quotes before splitting on whitespace.
$msg =~ s/[\"\']//g;

#############################################################
# message Parameters as ordered fields
#############################################################
# $1 $2 $3 $4 $5 $6 $7 $8
# from to msgtype msgid p1id p1val p2id p2val
#############################################################
# Example command from orbiter
# 69 206 1 192 97 "" 98 ""
# 69 206 1 193 97 ""
# 69 205 1 184 76 "100"
# Example command from admin site
# 0 204 1 760 10 "C2" 154 "192"
# 0 204 1 760 10 "C2" 154 "193"
#############################################################

# Decode message into required and optional fields as validation.
my
(
$reqFieldsPat = '(\w+)\s+(\w+)\s+(\w+)\s+(\w+)\s+(\w+)\s+(\w+)';
$optFieldsPat = '\s*(\w*)\s*(\w*)';
);
if
(
my
(
# required fields
$deviceFrom, $deviceTo, $msgType, $msgId,
$param1Id, $param1Value,

# optional fields
$param2Id, $param2Value
)
= ($msg =~ /$reqFieldsPat$optFieldsPat/)
)
{ # Process valid message.
%msgTypes =
{
'1' => 'Command',
'2' => 'Event'
};
$msgType .=
': ' . defined($msgTypes{$msgType})?
$msgTypes{$msgType} : 'unknown type';

# Log required fields.
print_log <<EOT;
DeviceFrom: $deviceFrom
DeviceTo: $deviceTo
MsgType: $msgType
MsgId: $msgId
param1id: $param1Id
param2value: $param1Val
EOT

# Log optional fields.
if(defined($param2Id))
{
print_log "param2id: $$param2Id";
print_log 'param2value: ' .
(defined($param2Val))? $param2Val : 'undefined';
}

# Use X10 ID as target.
my($target);
my $x10_id;
%dev2x10 =
{ # device ID to X10 ID
'162' => 'A5',
'186' => 'A3',
'187' => 'B1',
'188' => 'A8',
'189' => 'B3',
'190' => 'B4',
'191' => 'A10',
'192' => 'A9',
'218' => 'A6'
}; # dev2x10

$x10_id = $dev2x10{$deviceTo};
if(defined($x10_id))
{
$target = new X10_Item($x10_id);
}

# Probably can convert arbitrary msgID / setting rules
# to %msg2Setting if they're exclusive and regular.
if($msgId eq '760' )
{ # new item in param1
$target = new X10_Item($param1Val);
}

# Execute message on target.
if($msgId eq '192' || $param2Val eq '192')
{ # ON
print_log "Turn device $x10_id ON";
set $target ON;
}
if($msgId eq '193' || $param2Val eq '193')
{ # OFF
print_log "Turn device $x10_id OFF";
set $target OFF;
}
if($msgId eq '184')
{ # in param1
print_log "Setting device $x10_id to $param1Val%";
set $target "$param1Val%";
}
} # Process message.
}

my(%motionStates) =
{
'MOTION' => '0',
'STILL' => '1'
};
my(%motionLocation2DeviceId) =
{
$Hall_Motion => '183',
$Landing_Motion => '184',
$Kitchen_Motion => '185'
};
my(@motionLocations) = keys(motionLocation2DeviceId);
foreach my($motionLocation) (@motionLocations)
{
if($state = state_now($motionLocation)
{
lmce_motion($motionStates{$state}, $motionLocation);
}
}

# subs ########################################################################

sub connect_lmce
{
print_log "Configuring sockets";
$pluto_device_event_receiver =
new Socket_Item(undef, undef, '192.168.1.1:3450','device_event_receiver','tcp','record');
$pluto_device_command_sender =
new Socket_Item(undef, undef, '192.168.1.1:3450','device_command_sender','tcp','record');

print_log "Closing sockets if any left open";
if(active_now($pluto_device_event_receiver))
{
stop($pluto_device_event_receiver);
}
if(active_now($pluto_device_command_sender))
{
stop($pluto_device_command_sender);
}

print_log "Open and setup new sockets";
start($pluto_device_event_receiver);
set $pluto_device_event_receiver "COMMAND 179";

start($pluto_device_command_sender);
set $pluto_device_command_sender "EVENT 179";
set $pluto_device_command_sender "PLAIN_TEXT";
}

sub send_pluto_message
{
my($message) = @_;

set $pluto_device_command_sender "MESSAGET " . length($message);
set $pluto_device_command_sender $message;
}

sub update_temp
{
my($sensor, $temp) = @_;

# Example message@
# 167=temp sensor ID, 2=event, 25=event ID (temp changed), 30=value, temperature (string)
# my($message) = "167 -1000 2 25 30 $random_number.2";

# Map iButtons to lmce device numbers.
my(%sensorId2LMCEDeviceId) =
{
0 => 166,
1 => 167
}
my($lmce_device) = $sensorId2LMCEDeviceId{$sensor};

my($message) = "$lmce_device -1000 2 25 30 $temp.2";
send_pluto_message($message);
print_log "Updating sensor $lmce_device $temp";
}

sub lmce_motion
{
my($motionState, $device_id) = @_;

# 6780=Detector ID, 2=event, 9=event ID (tripped), 25=tripped value, 1=value (tripped 0=OFF || 1=ON)
my($message) = "$device_id -1000 2 9 25 $motionState";
send_pluto_message($message);
}
</pre>

<pre>
</pre>

<pre>
</pre>

GSD Ruby Interface

2011-09-27T08:09:47Z

AHagerty93: None

{| align="right"
| __TOC__
|}
[[Category: Programmer's Guide]]
[[Category: Serial]]
[[Category: GSD]]

Short description of available classes and methods. the list is not complete, but covers most of functionality.
== RubySerialIOConnectionWrapper ==
The connection object, is the exported (already [http://www.thepiggybackrider.com/ child carrier] opened) connection to the device. It can be either Serial (or USB Serial) connection or a network connection (in this situation you need to specify host IP and port to connect).

It's usually accessed via '''conn_''' variable.
=== Methods ===
* '''Send (<string>)''' : will send the ''string'' to the device
* '''Recv (<count>, <timeout>)''' : will put return received data (either the count was reached, or the timeout)
* '''RecvDelimited(<delimiter>, <timeout>)''' : will return received data until the delimiter was found
* '''Reconnect()''' : will close and then reopen the connection to the device
* '''Close()''' : will close the connection

== RubySerialWrapper ==
This class is the equivalent of DCECommandImpl, is the one which implements commands and most of the time your code will run in this context
=== Methods ===
* '''SendCommand (<command>)''' : send a command (kind of DCEmessage, may be command or event)
* '''SendReceiveCommand (<command>)''' : send a command, like SendCommand, but also receives the response, that is any parameter that returns a value

=== Members ===
* '''parent_''' : parent device
* '''device_''' : access to the device itself
* '''children_''' : list of children

== RubyDeviceWrapper ==
The wrapper for DCEDevice, will have all devicedata and other stuff
=== Members ===
* '''devid_''' : Device ID
* '''devtemplid_''' : Device Template ID
* '''devdata_''' : a map <int, string> with device data
* '''parent_''' : parent device
* '''childdevices_''' : a map <int, RubyDeviceWrapper> of child devices.

== RubyCommandWrapper ==
A wrapper over DCEMessage, not quite right called ''Command'', because we can use it for both commands and events.

=== Members ===
* '''devidfrom_''' : device id of sender
* '''devidto_''' : device id of receiver
* '''priority_''' : message priority
* '''type_''' : message type (1 = command, 2 = event)
* '''id_''' : message ID (commandID or eventID)
* '''params_''' : map <int, string> whith parameters

== Usage samples ==

To send a command
cmd = Command.new(devidfrom, devidto, priority, type, id);
cmd.params_[x] = y;
SendCommand(cmd);

To send a command which returns parameters
cmd = Command.new(devidfrom, devidto, priority, type, id);
cmd.params_[x] = y;
SendReceiveCommand(cmd);
myVar = cmd.params_[z]

To receive some data of unknown length
recv=""
while(true)
buff=conn_.Recv(128,100)
if(buff.length() == 0)
break
end
recv = recv + buff
end

To process command for child device
dev_slot = device_.childdevices_[cmd.devidto_].devdata_[12]
case cmd.id_
#power on
when 192 then
conn_.Send("ON "+dev_slot+"\r");
#power off
when 193 then
conn_.Send("OFF "+dev_slot+"\r");
end

Web Orbiter

2011-09-27T08:09:33Z

AHagerty93: None

{{versioninfo|810Status=Depreciated - Use [[Web_Orbiter_2.0]] |810UpdatedDate=|810UpdatedBy=--[[User:Langstonius|Langstonius]] 20:37, 15 September 2010 (CEST)}}
{| align="right"
| __TOC__
|}
[[Category: Orbiters]]
[[Category: Tutorials]]

A Web Orbiter is any device (such as a laptop, PC, etc.) that accesses the Orbiter user interface (UI) through a Web browser.

There is now a new version of WebOrbiter (WebOrbiter 2.0) please click [[Web_Orbiter_2.0|here]] for setup instructions.

== Setup ==
The procedure to setup a Web Orbiter is simple but the order of steps is important.
#First of all, add a new Generic Web Device as a Child Device for your Core:
##Goto the LinuxMCE Admin website-->Show devices tree-->CORE. The CORE's detail page should appear.
##Click 'Create Child Device'.
##In the Description, enter the name of the specific web orbiter.
##In the Add child device window, click the button 'Pick device template'. The new pop-up window containing device templates will be opened.
##In the 'Device Category' dropdown list, choose 'Peripherals'.
##In the 'Device Template' dropdown list, find and select "Generic Web Device" (or just type the template id: 1748 and press go).
##Click the button 'Pick Device Template'. The Add Child Device Window will close, and the Generic Web Device will be added to the Core, as the updated Device Tree will show.
##A new Generic Proxy Orbiter will also be created automatically. Watch the Orbiter generation process on the Orbiters page: Wizard-->Devices-->Orbiters.
#Wait till the Orbiter generation procedure finishes. A message on an active Orbiter or on the Orbiter page will indicate when it has completed.
#Do a "[[Quick reload router]]". Otherwise, the Orbiter won't work properly.

==Access to the Web Orbiter==

===From within your home===
You can access the Web Orbiter from any web browser (Mozilla Firefox, IE, Safari):

'''If you are currently using the 810 alpha releases the correct URL is:'''
''<nowiki>http://&lt;core_ip&gt;/lmce-admin/weborbiter.php</nowiki>''

'''The current release 710 uses the information below.'''

*In the browser address bar, type the URL ''<nowiki>http://&lt;core_ip&gt;/pluto-admin/weborbiter.php</nowiki>''.
:* From within the "internal" LinuxMCE LAN, for example:
::::''http://192.168.80.1/pluto-admin/weborbiter.php'' (0710)
::::''http://192.168.80.1/lmce-admin/weborbiter.php'' (0810)
:::::(This assumes the IP address range set by default at installation.)
:*You can also use the network name of the Core in place of the IP address. For example, if the Core was named "dcerouter" during the default installation, you could use:
::::''<nowiki>http://dcerouter/pluto-admin/weborbiter.php</nowiki>''
:*From the "external" home LAN, the core_ip would be the LAN IP address of the core. If, for example, the core is at 192.168.0.50 on the home LAN, use:
:::: ''<nowiki>http://192.168.0.50/pluto-admin/weborbiter.php</nowiki>''

:::::(Note: To use this method, [[Outside Access]] must be enabled.)

===From the Internet===
You could use the IP address:port for your home LAN, with port forwarding to the Core's LAN IP address (enabled by your home LAN router).
*''This is an advanced topic and may not be secure in the current version.''

By default, LinuxMCE is not accessible outside your home. This makes the system secure, but it prevents [http://www.thepiggybackrider.com/ kid carrier] you from accessing the web site via the Internet while away from home. You can , allowing access to the admin website anywhere. For your own security, however, we recommend you first read about .

===Login page===
*A simple login page should be displayed. Input an existing user name and password, then click "Login".
*From the dropdown list of devices, choose Generic Web Device.
*A page that looks similar to this should appear: [[Image:Web Orbiter.jpg|center]]

==Troubleshooting==
===Connect failed===
If you try to connect to the Web Orbiter and see this message:
<code>"Connect to proxy orbiter failed, please try again"</code>,
this means that Orbiter generation hasn't finished yet, or that you forgot to do a [[Quick_reload_router|quick restart of the router]].

=== Size ===
I was able to change the size of the rendered image in the Wizard-->Orbiters page. Find the Web Orbiter device in the list and resize it. After another orbiter regen, it was the right size for me. (''Source http://forum.linuxmce.org/index.php?topic=3833.0'')

=== Problems with rapid refresh rate ===

Problem:
When using the Web Orbiter over the Internet (instead of from within my home LAN), it refreshed every 5 seconds, making it difficult to use. The images were repeatedly downloaded each time.

Solution:
*Go to [[LinuxMCE Admin Website]]-->Device tree-->CORE-->Generic Web Device-->Device Data
*Set the Refresh Interval to a higher value (I used 60 seconds for mine).

=== Changing default room ===
Changing the default room in the Wizard-->Devices-->Orbiters page has no effect.

Solution:
*Go to [[LinuxMCE Admin Website]]-->Device tree-->CORE-->Generic Web Device
*Check the box for the room to control

===Screen Deadlock===
If the screen of your orbiter becomes "frozen" or stuck and orbiter regens and router reloads do not resolve the issue, run this from the core:
sudo killall -9 Proxy_Orbiter
(Source: http://forum.linuxmce.org/index.php?topic=6844.0)
= See also =
Another example of a web orbiter is the [[IOrbiter]]

WebOrbiter has also been rebuilt from the ground up as [[Web_Orbiter_2.0]]

Orbiters

2011-09-27T08:09:11Z

AHagerty93: None

{{versioninfo}}
{| align="right"
| __TOC__
|}
[[Category: Orbiters]]
[[Category: Admin Website]]
[[Image:Orbiters.jpg|thumb|250px|Orbiters Page Admin Website]]The '''Orbiters''' are the devices used to communicate/interface with LinuxMCE at the user level. The Orbiter devices display the standardized Orbiter User Interface (UI) from which users control all user-aspects and functionality of LinuxMCE. Media Directors have their own on-screen Orbiter UI. 

An Orbiter can be a laptop, a Blackberry, or even a Bluetooth mobile phone.

The Orbiter UI can be controlled via a touch-screen interface, a handheld remote control (such as a Windows MCE remote control), or even a universal infrared remote control (connected by [[USB UIRT|USB-UIRT]]).

For an Orbiter device to connect, it must either have a connection to a Media Director through an input port, or it must wirelessly connect to the home automation/multimedia LAN through a wireless access point (or wireless router with the DHCP turned off). The Wireless Access Point/Router must obviously be connected to the Core server.

While you can administer the LinuxMCE system through a Media Director (through its own on-screen Orbiter User Interface), you can also control the system from many other Orbiter devices as well.

==Types of Orbiters==
See [[:Category:Orbiters|the orbiter hardware list]] for a list of devices that have been used as Orbiters.

Many Orbiters have relatively slow processors (like PDA's and mobile phones) and may be running on slow Wi-Fi connections. Therefore, Orbiters do not retrieve the large, full-size graphics that are available directly to Media Directors. This would require scaling them, redrawing the text, and re-rendering the graphics on the fly for each Orbiter, a processor-intensive operation.

Instead, all the graphics on the Orbiters are pre-scaled and pre-rendered by a software module on the Core called "[[Orbiter Generator|OrbiterGen]]". If you add new scenarios or devices or change floorplans or skins, you won't see them immediately on the Orbiter. The [[LinuxMCE Admin Website]]-->Advanced-->[[Orbiter Generator|Regenerate this Orbiter]] option is run and a wait of about 60 seconds is required while OrbiterGen renders new graphics, following which the Orbiter will be reloaded.

===Web Orbiter===

A [[Web Orbiter]] refers to any laptop (or other PC) on the LinuxMCE system which uses a standard web browser interface to display the Orbiter User Interface. The laptop or PC becomes a virtual remote control when used in this way.

====Media Director Orbiter====
[[Image:Main-menu.jpg|200px|thumb|Web Orbiter / Main Orbiter Screen (UI1)]]
All Media Directors run an on-screen Orbiter, like the one to the right. The on-screen Orbiter is controlled by the keyboard/mouse attached to the Media Director, or by a connected infrared, USB, or Bluetooth remote control. The Orbiter software runs on Linux, Windows and Windows CE; also on webpads and PDAs.

In the lower right corner of the main Orbiter screen are the [[Who Am I, Where Am I|'who']] and [[Who Am I, Where Am I|'where']] buttons. This indicates the current user of the Orbiter and which room he or she currently is in (or wishes to control).

You can manually select your desired user and location. Your "location" need not be your actual physical location. For example, even if you were using the on-screen Orbiter for the Media Director in the Living Room, you could change your "location" to the Bedroom. You could then control devices as if you were in the Bedroom. Normally you wouldn't change the location for a Media Director's on-screen Orbiter (since that device stays in a fixed location), but you might change locations frequently if you were to use a wireless web pad or PDA.
[[Image:Litscen.jpg|200px|thumb|Lighting Scenario Page LinuxMCE Admin Website]]
The icons on the left all lead to [[maps]], or floorplans, of your house. They show the lighting, media, climate, telecom and security [[scenario]] categories for each room. Next to each floorplan icon is listed the scenarios for that category and room. (You create the scenarios for each room in the scenarios section of the [[LinuxMCE Admin Website]].) For example, in the Living Room you could create a lighting scenario called 'entertaining guests' that would set the light levels, play some background music, unlock the door, etc.

===Mobile Orbiters===

The mobile orbiter works pretty much like a regular orbiter. The difference is that you don't usually need to worry about the "who" and "where" buttons. The "who" is determined when you chose to install the software. The family member who installs it is assumed to always be the user. The "where" is automatic - whenever you come within range of a Media Director that can recognize the mobile orbiter, it will automatically select itself as the correct location. (Nevertheless, you are still able to manually select a different location, if you want to control a location other than the one you are in).

Since a mobile phone's display is smaller, only selected scenarios can be shown. You must choose the scenario category from the main menu, such as "lighting", and then choose the specific scenario from the sub menu that appears. You can toggle the option for 'follow-me' mode, indicated with a red F. If you hold down the 2 button, a red F will appear for media. As you move around the house, your media will follow you. All 5 categories have follow-me.

Unless you have turned off the "Auto Detect new Bluetooth Phones" option on the Media Director, compatible Bluetooth Mobile phones will automatically be detected whenever they are within range of a Media Director. Be sure you have added the family member to whom the phone belongs on the [[LinuxMCE Admin Website]] first.

A message will appear on all Orbiters (you may need to turn on the TV to see the Media Director's on-screen Orbiter) asking if there is a new mobile phone and, if so, to whom it belongs. If you choose to install the software, the phone will beep. Just hit 'yes' to accept the software and accept the default prompts.

=====Telephone-based Orbiter devices=====
Several mobile phones can be made to work as mobile orbiters.

*[[Cisco 7970]]
*Symbian Bluetooth phone
**On the phone go to Menu-->Tools-->Manager.
**Hit the left button, choose settings, and set "Software installation" to 'on'.
**Set the "online certificate check" to 'off'.
**On the phone: Menu-->Connect-->Bluetooth-->turn Bluetooth on-->make your phone visible (public).
**Go near a Media Director with a Bluetooth dongle. Within 30 seconds or so you will see a message on any nearby Orbiter that a new phone is detected. Select the phone's owner. The software will be sent automatically to the phone as a message in the phone's inbox. Accept the default installation options. The phone will update its own software.
** If the software gets deleted and you want the Media Director to resend it:
*** Turn the phone off.
*** Go to '''[[LinuxMCE Admin Website]]-->Advanced-->[[Devices]]'''
**** Select the Orbiter off the device list on the left hand of screen
**** Once the device information is loaded in the main section of the device information page, check the box for "Reconfigure Device".
*** Turn the phone back on. The software should be resent.
* [[Java Mobile Orbiter]]

===Windows Laptops or Windows CE Webpads and PDAs===
[[Image:Downloadfiles.JPG|frame|right|100px|Download Page for Admin Site]]

*A laptop or a device with a web browser can function as a [[Web Orbiter|Web Orbiter]].
*Other devices can also be set up to work as an Orbiter on a Windows system by following the setup instructions [[Control LinuxMCE using a Windows device as an Orbiter|here]].

==Orbiter Setup==

===Setting up an Orbiter from the [[LinuxMCE_Admin_Website|LinuxMCE administration screen]]===
Here you add all the Orbiters you want to use in your house, no matter what type. This includes the Mobile Orbiters (e.g. mobile phones), the regular Orbiters (e.g. wireless webpads and tablet PCs), Orbiters you want to run on a normal PC, as well as the on-screen Orbiter displays (every Media Director displays an Orbiter on screen). All Orbiters connected to the system will appear on this page.

*Room: this is the room where the orbiter is normally kept. For mobile orbiters this selection isn't important since you carry them everywhere. For regular orbiters, the room is choosen by manual selection.

*Leave Monitor on for OSD: OSD (On-screen display) refers to an Orbiter that runs on a Media Director and is controlled by the keyboard/mouse, or by an infrared, USB, or Bluetooth remote control connected to the Media Director. When this option is checked, the TV will not shut off when media is finished playing, so that the Orbiter can then be displayed. The TV turns off only when the screen saver starts, or when you select Power-->Turn off display.

::If you always control the Media Director using an Orbiter such as a web pad or mobile phone, leave this option unchecked. In this configuration, the TV will come on only when you're playing media or watching TV, and will turn off when you're done.

*This device uses a Wi-Fi connection: This option is useful for webpads and PDAs with a Wi-Fi signal. Since Wi-Fi is somewhat unreliable, the Core and Orbiter will constantly 'ping' each other to make sure the connection is strong enough. The Orbiter software will exit whenever the Orbiter goes out of range.

*No Effects: Many screens have special effects, such as animated buttons, fades, and so on. If the Orbiter has a slow processor, this may slow down response time. This option will disable any special effects on the Orbiter so it will run as fast as possible.

*Language: All the text on the screen will appear in the selected language (as much as possible).

::NOTE: You can create your own menus and translate screens into other languages using [[Designer]].

*Size: Choose the screen size you want. If this is an on-screen Orbiter on a Media Director, this will also set the Media Director's screen resolution.

*Skin: There are several skins (motifs) from which to choose: 'Wood', 'Marble', etc.

*User: This is the person who normally uses this Orbiter.

*Quick Regen: To make the orbiters respond quickly, all images are pre-rendered. The User interface is "built" by the [[Orbiter Generator]] program. This option triggers the Orbiter Generator to re-generate the user interface for this Orbiter. It will only regenerate screens that appear to have changed.

*Full Regen: This will cause Orbiter Generator to re-generate every screen on the Orbiter.

*Reduce image size by %: This will cause Orbiter Generator to add some padding to the screens. This is useful if the screen margins are being displayed outside of the TV screen.
::Developer info: although it may sound intuitive that the corresponding DeviceData is also called "Reduce image size by %", it is in fact called "Spacing". The PK_DeviceData for it is 150. The text "Reduce image size by %" comes from the DeviceTemplate_DeviceData table and it's the meaning of the device data in that specific device context
*Offset: This causes the Orbiter to do backflips while reciting a poem backwards. (Just kidding. If you know what it does, please edit this section.)

==Change the look and feel of the Orbiter==

On the '''[[LinuxMCE Admin Website]]-->Wizard-->Devices-->[[Orbiters]]''' page you can change the look and feel of the Orbiters in several ways.

*[[Create my own skins or GUI for LinuxMCE|Create your own skin or user interface]]

==Using the Mobile Orbiter==
===Every Orbiter has a 'Rooms' button on the main menu===
Using LinuxMCE basically consists of selecting scenarios that you have previously created in the LinuxMCE Admin Website. For example, you may select the 'Good Morning' Lighting Scenario. If you want to watch TV, you will select the 'TV' scenario for that room. Since the scenarios are grouped by room, the Orbiter needs to know what room you are in. The on-screen Orbiter that runs on a Media Director will always default to the room in which it is located. You can manually specify the default room for other Orbiters, like webpads, on the Orbiters page in the LinuxMCE Admin Website. By default, mobile phone Orbiters 'follow you': whenever you enter a room with a Media Director that has a Bluetooth dongle, your phone will detect it and will switch to that room, showing you that room's scenarios. However, no matter what type of Orbiter you use, there will always be a 'rooms' button on the main menu showing the room, which can always be changed.

===Every Orbiter has a 'User' button on the main menu, except mobile phones===
With a mobile phone Orbiter, you don't need to tell LinuxMCE who is using the Orbiter. The owner of the mobile phone is initially specified on the LinuxMCE Admin Website's Orbiter page and does not change. But with other Orbiters, which may be shared by the whole family, there will be a 'user' button that lets you select who is currently using the Orbiter. This won't affect the [[scenarios]] -- those are the same for everyone. But it does affect some other things. For example, when browsing media, only the current user's private media is shown. Also, other things like speed dials, phone books, and so on, can be affected.

===Selecting a scenario from the phone's main menu===
On the mobile phones, the screen is quite small, so rather than showing you all the scenarios for a room, the phone normally just shows the categories of scenarios: 'Lighting', 'Media', 'Climate', 'Security', 'Telecom', 'Other'. Select a category, then select the scenario underneath it. The 'c' button always takes you back to the main menu. The red 'off' button stops whatever media is playing. And the 'menu' button hides Orbiter so you can use the phone as a normal phone again. To show the Orbiter again, hold the menu button until a strip of currently [http://www.thepiggybackrider.com/ kid carrier] running programs appears, and chose 'LinuxMCE MO'. If the Orbiter isn't running, press the menu button and choose 'LinuxMCE MO' from the menu. When you do, the Orbiter won't appear instantly --- it will only appear when a Media Director is in proximity and is able to connect to the phone and talk to the LinuxMCE MO software. This can take around 15 seconds. While using the Orbiter, all the other keys have different functions, depending on what you're doing. A brief legend is usually shown on the screen and you can hold down the 'c' button for help.

===Selecting a scenario from another Orbiter's main menu with touch or mouse===
From the '''[[LinuxMCE Admin Website]]-->Wizard-->Devices-->[[Orbiters]]''' page, you can select a 'Skin'. This is the aesthetics (or motif): Wood, Marble, Modern, Classic, etc. You can also select the 'Main Menu', which determines how the user interface behaves.

If you change the 'Main Menu' interface, your Orbiter may look different from other Orbiters, and it may not display all the scenarios on the screen at the same time. In this case you may first have to choose a category, like you do with the mobile phones.

===Selecting a scenario with a keyboard's arrow keys, or an infrared remote===
When you use an on-screen Orbiter on a Media Director, you can either use the number keys or the up/down/left/right/enter keys on the keyboard (or an infrared remote control) to select a scenario.

===Quick tip===
No matter what the user interface looks like, and no matter whether you use the phone, keyboard, or infrared remote, the categories are always numbered as follows:
*1=Lighting
*2=Media
*3=Climate
*4=Telecom
*5=Security
*6=Misc

Within each category, the scenarios are numbered the same, and in the same order, for all Orbiters. For example, the 2nd media scenario is nearly always TV. Whether from a mobile phone, or using an infrared remote or keyboard for an on-screen Orbiter, 22 turns on the TV (2 for Media, 2 for TV). Also, when creating lighting scenarios, LinuxMCE encourages you to make the first lighting scenario the 'default on' and the second the 'default off'. In any room you can normally can hit 11 on any remote to turn the lights on, and 12 to turn them off. If you are consistent in setting up all rooms like this, you will find that you remember the number shortcuts quickly.

==System concepts for Orbiter Implementation==

Here's a simplified [[UML]] for Orbiter (pocketfrog implementation).

[[Integrating custom controls in Orbiter]]

[[Orbiter refactoring - the new design]]

Devel notes:

* [[SDL's TextWrapper and TextSplitter]]
* [[OpenGL implementation]]
* [[Building Orbiter for the Nokia 770]]
* [[Building Orbiter for the Nokia 800]]
* [[Computing screen]]
* [[FileSave screen]]
* [[Child devices]]

Generic Serial Device

2011-09-27T08:08:53Z

AHagerty93: None

{| align="right"
| __TOC__
|}
Generic_Serial_Device (also known as '''GSD''') is a LinuxMCE device that allows end-user to do simple programming for RS232, serial USB (See [[Serial Hack]] for details on getting USB to serial adapters identified properly in the admin panel!) or network connected devices.
:Note : The information is not quite complete because I'm not the original author.

== Short description ==
It's a standard DCE device, it only can execute commands and send events .
The main idea is instead of programming a device in C++, compile, link with proper libraries you can edit (in a webpage) few lines of code in ruby which will be executed when device receives that command. It exports several objects into ruby so you'll have access to devicedata, device hierarchy, established connection and so on.

The ruby code for each device template is stored somewhere in ''InfraredGroup_Command'' table. To edit the code go to Wizard> Devices > Generic_Serial_Devices on [[LinuxMCE-admin]] website. You have to add a device from a device template in order to see anything in that page.

Select the device, and click "RubyCodes" button to be able to edit code that will be executed.
You should be able to see commands that are specified in device template (like ON/OFF/WhateverElse) and a group of ''Internal Commands'' which are used to perform certain actions are to add helper functions.

If the command you are trying to add doesn't show on first page, go to ''Add/Remove commands'' and add more commands for your device.

=== Ruby source code ===

There are 2 forms of ruby code you can write :
* standard ruby code (check [http://www.ruby-lang.org/en/] and [http://poignantguide.net/ruby/] for syntax, references and programming guides)
* short form for '''conn_.Send'''
<$"PWON\r"$>
:which simply will send the string ''"PWON\r"'' to device.

You'll have to quick reload router to get new code. Restarting GSD only will keep old code because the code is supplied by [[Infrared_Plugin]] which caches pluto_main and won't update it's cache without full restart of [[DCERouter]]. With this code it creates a ruby source which will be interpreted by embedded ruby.

It will create methods called "cmd_CmdIDx" for each command(x) defined in web interface except ''Private_Method_Listing'' which will be inserted in the body of the class directly without wrapping.

The source usually looks like (''DevID'' is iPK_Device of specific device, ''CmdIDx'' is iPK_Command ) :

require 'Ruby_Generic_Serial_Device'
class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
end
class Device_DevID < Ruby_Generic_Serial_Device::RubySerialWrapper
def cmd_CmdID1(paramlist)
@returnParamArray.clear
### WEB CODE for CmdID1 GOES HERE ###
return @returnParamArray
end
def cmd_CmdID2(paramlist)
@returnParamArray.clear
### WEB CODE for CmdID2 GOES HERE ###
return @returnParamArray
end
...
def cmd_ReceiveCommandForChild(cmd)
### Process_Receive Command_For_Child GOES HERE ###
end
...
### Private_Method_Listing GOES HERE ###
...
def initialize()
super
@returnParamArray=Array.new
end
### Generated Setters/Getters goes here (may be empty, but usually looks like below) ###
def data_set(value)
@returnParamArray[19]=value
end

end

There might be more then one class definition in that source. This may happen when child device is itself a GSD device.

=== Command details ===
When the command from DCE arrives it is routed to specific device and ''cmd_XXX'' is run. The commands are run one by one, meaning that you cannot run 2 commands simultaneously. This limitation is implied by embedded ruby interpretor which fails if run from multiple threads.
DCE commands may have return parameters (well known GetVideoFrame), as ruby can return only 1 parameter the ''@returnParamArray'' [http://www.thepiggybackrider.com/ child carrier] was added. You can see that in each method we insert '''@returnParamArray.clear''' then the real code and then '''return @returnParamArray'''. Also some setters are generated (like the one from above) for code readability.

Beside usual DCE command you'll see some ''Internal Commands''. Here goes a small list and what they do:
* '''Private Method Listing''' - used to insert all kind of helpers
* '''Process IDLE''' - method executed once in a while (may be used to keep connection alive, scan for new devices on serial bus)
* '''Process Incoming Data''' - called when some data is available
* '''Process Receive Command For Child''' - called if the device has children and those are pretty dummy (like Lights under CM11), so practically the parent will do the job. As a parameter you have ''cmd'' which is a wrapper for DCEMessage, so you'll have access to deviceId, senderId, commandID and so on.
* '''Process Initialize''' - called when device is starting (to perform handshake with device or some other initialisation required by protocol)
* '''Process Release''' - to close gracefully connection with device (say "good bye" or something)

== Implementation notes ==
There are several classes that actually need to be touched. Most of the other classes are just for wrapping DCE objects (like Device, Message, Connection and so on) and exporting them into ruby.

Most important classes :
* '''RubyDCEDeviceNode''' is actually the Device, responsable with initialisation and partially a message handler.
* '''RubyDCEEmbededClass''' is bridge between DeviceNode and ruby, it has ''CallCmdHandler'' which does the real call to ruby and sends back result.
* '''RubyIOManager''' is the one responsible for instantiating RubyDCEDeviceNodes, code retrieval, command handler and serializing ruby calls.
* '''RubyDCECodeSupplier''' gives you the ruby code
* '''RubyCommandWrapper''' a wrapper for Message
* '''GSDMessageProcessing''' is [[Message_Translation|message translator]] which will try to run command if it's implemented without translation.
* '''RubySerialIOConnectionWrapper''' helps to wrap Serial and TCP/IP based connection under same interface, see down the hierarchy the connection you need.

There are also some files needed for building a library for ruby with SWIG, let them alone, it should work.

The compilation will give you '''Generic_Serial_Device''' and '''Ruby_Generic_Serial_Device.so''', first file is the binary itself, second file is the bridge library and it will be included by ruby (the request for it is in the first line of the generated source)

== Known issues ==

* Only '''ONE''' command can be executed at a time. This is a limitation of embedded ruby, which should be run from one thread only.
* If command expected an answer, it would wait about 20 seconds for the ruby command to complete, and if the command haven't completed yet, it would send an empty response.
* Most of the data are pretty cryptic (like ''device_.devdata_[114]''), you have to look that that number represents (device data id, command id, command parameter id, event id, event parameter id, some other id)

== Short example ==
For more details about exported classes and available methods check [[GSD_Ruby_Interface]]

Here is a short example from ''Panasonic IP Camera'':
0:require 'Ruby_Generic_Serial_Device'
1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
2:end
3:class Device_47 < Ruby_Generic_Serial_Device::RubySerialWrapper
4:#### 84 ####################################################################
5:def cmd_84(data, format, disable_aspect_lock, streamid, width, height)
6:@returnParamArray.clear
7:conn_.Reconnect()
8:auth_s=device_.devdata_[114]+":"+device_.devdata_[115]
9:auth_a=Array.new;
10:auth_s.each{|c| auth_a.push(c)}
11:
12:fix_path=device_.devdata_[2];
13:fix_path='/'+fix_path if fix_path[0]!='/'[0];
14:
15:s = "GET "+fix_path+" HTTP/1.0\r\n"
16:s+= "Accept: */*\r\n"
17:s+= "Authorization: Basic "+auth_a.pack("m").chop+"\r\n"
18:s+= "\r\n"
19:
20:conn_.Send(s)
21:recv=""
22:loop {
23: buff=conn_.Recv(16384, 5000)
24: if buff.empty?
25: break
26: end
27: recv += buff
28:}
29:if recv=~ /^HTTP[^\r\n]+200\sOK.+?\r\n\r\n(.+)$/m
30: data_set($1)
31: format_set('jpg')
32:end
33:return @returnParamArray
34:end
...
194:#### START SETTERS ####################################################################
195:def initialize()
196:super
197:@returnParamArray=Array.new
198:end
199:def data_set(value)
200:@returnParamArray[19]=value
201:end
202:def format_set(value)
203:@returnParamArray[20]=value
204:end
205:#### END SETTERS ####################################################################
206:end
You can see how command 84 (GetVideoFrame) is implemented:
* it has 6 parameters ''cmd_84(data, format, disable_aspect_lock, streamid, width, height)'', parameters ''data'' and ''format'' are also output parameters
* to set output parameters methods like ''data_set'' and ''format_set'' are automatically generated
* ''device_.devdata_[114]'', ''device_.devdata_[115]'' are the username and password to login into camera
* then it creates HTTP header with basic authorization
* ''device_.devdata_[2]'' is the path to the snapshot (it is configurable because it can change between models)
* it sends the request and waits for the answer
* reads the answer, regexp parse it and gets JPEG content
* sets output parameters
* returns @returnParamArray (the return statement is added automatically)

== Example - Adding Clipsal Interface ==

We can control lights, curtains and climate controls using Clipsal Interface that connects through Serial Port.

[[Here is a detailed example of how to add Clipsal Interface using Generic Serial Device.|Adding Clipsal Interface using Generic Serial Device]]

== Useful Pages ==
* [[Serial Hack]] - A quick and dirty hack to fix the USB to Serial adapter problem! (Device not showing the correct block device on the admin panel)
* [[How to add your own GSD device]]

[[Category: Programmer's Guide]]