Quick DM development jump start...?

[Todd Reed]

Can you provide simple walk through of steps to develop DM usage?

- Create "Provider"
- Create "Devices"
- Update UI code

I am wanting to update the Ocelot UI to include DM usage.

Simple example, "Ocelot:SendIR(3,2,1)" can now be "Send IR - Volume up - 3 times"

I want to enter I/O names, IR names, Variables and Timers into DM then pick them in the Ocelot UI.

[Promixis]

Can you provide simple walk through of steps to develop DM usage?

- Create "Provider"
- Create "Devices"
- Update UI code

I am wanting to update the Ocelot UI to include DM usage.

Simple example, "Ocelot:SendIR(3,2,1)" can now be "Send IR - Volume up - 3 times"

I want to enter I/O names, IR names, Variables and Timers into DM then pick them in the Ocelot UI.

Todd, do you have a working component for the Ocelot?

[Todd Reed]

I am laughing to myself... I guess not, if I don't know what it is!

Maybe hoox does?

I will look at those directories again for samples...

(is there any kind of G5 help file yet?)

[Todd Reed]

Old method:
- create Ocelot Serial plugin, in "\plugins\serial\" folder
- create Ocelot UI in \plugins\treescript\" folder with actions and config
- make sure Ocelot XML is in UI folder

New method:
- ???
- ???
- ???

A simple clue??? That's all I'm asking for....

Oh heck, can't you just do it for me!!!

[Promixis]

Todd,

I am not sure what the current Ocelot plugin supports...

But, here is what you want to do...

1. Once you are connected to the Ocelot you need to have a list of devices. The Ocelot plugin should publish its events using a Publisher class.

2. The provider is started by the Ocelot plugin. It listens to events from the Ocelot publish. It creates the devices in the the Device Manager using whatever device types it needs.

3. The provider communicates back with the Ocelot plugin to have it perform actions on devices.

The HAI Provider might give you a basic idea.

[Todd Reed]

I am not sure what the current Ocelot plugin supports...

Serial based plugin that: Send and receive local and remote IR, set and get variables and timers, set I/O relays on/off, send Speak messages.

1. Once you are connected to the Ocelot you need to have a list of devices. The Ocelot plugin should publish its events using a Publisher class.

Devices - as in IR1, IR2... Var1, Var2, Var3... (item names) or as in Slider bar, On/Off buttons, data entry boxes (kind of like Action UI form items)

Publisher class? Is there a review of these classes, which ones to use for what...? The Ocelot plugin would be where, in the Plugins folder, or is this the "Component" you were talking about? And where should it be located?

2. The provider is started by the Ocelot plugin. It listens to events from the Ocelot publish. It creates the devices in the the Device Manager using whatever device types it needs.

Provider is started how? Some kind of Provider call? Ocelot publish is like a config or action item? Example, how do I create a list of IR codes to name and use as devices?

IR1 = Tuner on
IR2 = Vol Up
IR3 = Vol Dn

3. The provider communicates back with the Ocelot plugin to have it perform actions on devices.

So the actions are coded into the plugin, not in the treescript UI page?

The HAI Provider might give you a basic idea.

HAI is a DLL type plugin... the only file I see is in \DeviceManage\Providers\
?? Nothing in \Luascript\ or \Component\ or \Classes\ But, I will review it!

[Todd Reed]

In the ADI family of home automation controllers there are many different types of modules. Touch screens, controllers, remote I/O modules, temp sensing modules (called Bobcats). They can all be connected with a communication bus, a dedicated comm bus 2 wire scheme.

The Girder connection is via serial, to the "master" controller. So you have a Master controller, and potentially, a slave Controller, remote I/O Modules, and Bobcats.

The Ocelot plugin we currently have sends commands via serial to the "Master Controller" that look something like this:

Send Remote IR (this is the command, or Action)
- Module number (which physical unit# in the ADI system bus)
- IR number (which memorized IR code to send, EX "Volume up")
- Repeat times (used for larger volume increases via multiple times IR sent)

or

Set Relay (Relay on or off command)
- Module number (which physical unit# in the ADI system bus)
- Relay number (which relay number to control, #8 - #15)
- Value (on or off)

This method works great in G4, just not name friendly!

To use DeviceManager, each Ocelot user needs to have the ability to name his or her devices. For example my SECU16 Relay for my spa filter pump is currently sent with "Module #1, Relay #13" and I would like to change the UI to allow me to pick the relay by name, IE "Spa Filter Pump".

[Todd Reed]

Wow, this looks promising, but with no documentation or support, then developers are kind of stuck...

Is there a help file coming soon?

The more I dig, the more questions I have...

1) What is the difference between a Component and a Provider?

2) I see an X10 Provider, but it shows up in the Component Manager???

3) Under DeviceManager folders, there are InfraRed Devices and Controls, what is the difference?

4) Can anyone define which files and which folders I need to use to impliment the Ocelot plugin?? Read the Ocelot help file for features and UI explainations...

[Promixis]

Wow, this looks promising, but with no documentation or support, then developers are kind of stuck...

Is there a help file coming soon?

The more I dig, the more questions I have...

1) What is the difference between a Component and a Provider?

2) I see an X10 Provider, but it shows up in the Component Manager???

3) Under DeviceManager folders, there are InfraRed Devices and Controls, what is the difference?

4) Can anyone define which files and which folders I need to use to impliment the Ocelot plugin?? Read the Ocelot help file for features and UI explainations...

Hi Todd,

Its a lot to grasp - and no formal docs have been started.

Concepts....

1. Component Manager is a method to implement extensions to Girder - primarily in lua. The component manager providers a framework (see the base class) that all components must follow. Ie. All components must be able to enabled/disabled and must publish their events. Users of components must subscribe to get events from them.

2. Device Manager provides a framework for controlling and displaying device info. There are core device types that specify exactly how certain devices will behave. Plugins or components export their devices to the DM using a Provider. Each device has controls (hence the devices and controls folders). What this means if you have a light device, you can control it without regard for the underlying technology. ie zwave, insteon, x10 or etc.

[dsmes]

Hi Mike, I'm clueless as well. What's the simplest DM device to follow as an example? And what are the Lua file names associated / related to that device?