Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A video training 'syllabus'
I'm working on videos for 5.0 training. Unlike the old videos these are not going to concentrate on individual features in a vacuum. They are going build up, from very simple to fairly full featured, a realistic system, exposing the user to new features as it goes along. That doesn't mean that there can't also be some detailed videos on very specific topics, but that's something that would come after this stuff.

Beyond the staged and progressive buildup, another goal is to keep one maybe three to 5 minutes, and only introduce one or two new significant features or concepts in each one, with other minors ones being implicitly demonstrated. As is always the case with these types of things, we'll do some work that will be discarded later when better ways are presented, but that lets us start very simply.

Another goal is not to over-explain. The point of going through these is to demonstrate how you would do these things, not explain the heretofors and the forthwiths behind them, other than briefly. That will be for the detailed videos and the written docs. It's to expose them to enough that they can start playing around, and do it in digestible chunks that they can stop and play around with after each one.

I do move back and forth between front and back end, but that's purposeful, so that they don't get too stuck in either mode and forget the bits that came before.

Here is what I have so far. There will be more. Feedback is welcome. It'll be a lot of work, and any changes can have knock-on effects for other videos down the light, so changing them will be difficult in many cases. So I don't want any obvious problems that could be avoided. In particular where maybe the staging of features might not be optimal.
Dean Roddey
Explorans limites defectum
  1. A practical overview
  2. Breadth, not depth
  3. In the context of building a real system
  4. Iterative steps to introduce more complex ideas as we go
  5. Leave the auto-gen system for later, but make it clear it does exist. Point them to those videos if they want to jump straight there.

  1. Don't explain, just do the install, all components
  2. We'll explain the various components as they actually come into play
  3. Explain that it is modular but that we are just going to install it all for training purposes.
  4. Stop only where there's something they may need to change
    • Web server port if they have another one running

  1. Very brief description of drivers/fields
    • Purpose is to allow CQC to interact with devices in a consistent and simple way.
    • Drivers have names (monikers) and each driver has named fields that represent controllable or viewable aspects of the device.
    • A 'moniker.field' combo uniquely identifies any changeable or viewable aspect of any device in the system.

  2. Interactive capabilities of CQC
    • Interfaces
    • Remotes and triggers
    • Text to speech
    • Voice
    • Device panels

  3. Non-interactive (automonomous) capabilities of CQC
    • Scheduled events
    • Triggered events

  4. Explain that what follows is a set of iterative videos that build up an ever improving automation system.

System one (Basic Starter Kit)
  1. Install lighting, security and weather simulator drivers
    • A very brief description of the installation of drivers
    • A quick view of one of them in the driver monitor to show that the ideas about drivers discussed previously are visibly present
  2. Do a screen with a couple buttons to turn a couple lights off/on
    • Explain we are using the default look and feel which we'll change later
    • Give a very brief explanation of the action editor and it's components as these are being configured, but keep it very short for now.
  3. Show how to use the interface viewer to view and test it
  4. Show them where the driver documentation is and give a brief description of what it provides them.

  • Spend time explaining the UI. Just demonstrate it
  • Spend time explaing widgets in any depth, just say that there are UI elements that can be dropped on the screen and configured and then do so. Leave that to the detailed interface documentation.

Exercises for the User:
  • Installer the real driver for their lighting system and update the buttons to talk to the real lights. Don't do them all yet since it will just get replaced later with nicer solutions.
  • Sign up for the Weather Underground and install that driver instead of the simulator.

System two (Customization and Feedback)
  1. Move to a simple but custom appearance. Don't belabor it but we:
    • demonstrate here the attribute editor and how widgets are styled
    • demonstrate some copy/paste of widgets and attributes to create a consistent look.
  2. Import some images for use in the custom interface, via drag and drop
  3. Introduce feedback, changing the lights to check boxes with light off/on images
  4. Add a new screen that shows some current weather conditions
    • This demonstrates more feedback mechanisms, text and images
    • Have buttons on each that switch back and forth between the screens

System three (Menus and Overlays)
  1. Introduce the overlay to get rid of duplicate main screen controls
  2. Move the stuff we did above into this new framework
    • A main template with an overlay
    • An overlay to load the two existing screens into
  3. Introduce the tool bar as a scrollable menu mechanism
    • Set up buttons for each of our two screens so far
  4. Put a few more informational display widgets on the main screen now that we don't have to replicate them anymore.

System four (Events - Triggered/Scheduled)
  1. Brief explanation of triggered events
    • Do an example, turn lights on in the kitchen if motion starts at night
    • Another to turn them off when motion ends
    • Force motion via the security simulator driver and show that it works
  2. Brief explanation of scheduled events
    • Do one for outdoor lights on at sunset, off at sunrise

System five (Scrollable Content)
  1. Introduce scrollable content
  2. Move lights to a separate template, loaded into an overlay for scrolling
    • Make sure we have just enough lights to demonstrate that they scroll, no need to do more yet since we will replace this stuff soon.

System six (Dynamic Content Generation)
  1. Introduce the dynamic generation stuff
  2. Convert the lights to use a pattern template and dynamic generation
  3. Add weather forecast data to the weather screen, in the same way

Exercise for the reader:
  • We'll use the scheme that just gets all dimmers or all switches for a driver and gens the dynamic content based on that list. But, they can be done manually to provide better human readable labels. Demonstrate that briefly and they can do it for their own lights if they want.

System seven (Triggered Actions)
  1. Introduce the concept of triggered actions (as opposed to triggered events)
    • Explain that it's not just IR, but anything that can send an input trigger
  2. Install a GC-IR receiver driver
    • This demonstrates driver connection configuration for the first time
  3. Set up a few triggered events to turn on/off lights
  4. Show how these changes show up in the UI when made via an IR remote

System eight (Triggered Actions With Parameters)
  1. Take the previous example further by introducing HTTP based triggers
    • Reiterate that it doesn't matter how they are triggered, they are all just actions to be invoked via training.
  2. Demonstrate how trigger parameters work and why they are very nice
  3. Create an example such as setting group lighting level by passing in the group name and level to a single trained action.
    • Just use the browser as a simulated source of the incoming triggers

System nine (IR Control)
  1. Load an IR blaster/trainer driver, probably the UIRT
  2. Import a few IR models, to represent a small media room setup
  3. Create another simple IR model by hand to show how it's done
  4. Add a basic theater room screen to our system
    • Set it up with some command buttons to send out some IR and field write commands in a realistic way, power on/off, transport, etc... Pause to wait for the projector to power up.

System ten (Conditional Logic)
  1. All of the above can be done with the simplest of actions, so they know that they can understand it enough to do good work with very simple tools
  2. Now introduce the concept of If/Then logic
  3. Update the power on button from the theater room example in the previous video, to only wait for the projector to warm up if not already.
  4. Update the kitchen light on motion event to only do it if the security system is not armed for away mode (for reasons we'll see in the next video.)

System eleven (Text to Speech, Conditional Logic)
  1. Install the security simulator driver
  2. Install the Speech II driver
  3. Set up the CQC service under a normal account
  4. Create a new triggered event that watches for any motion start event for the house area. If the security system is armed for away mode
    • Start a warning countdown via TTS
    • Put the lighting system into emergency blink mode

System twelve (Arbitrary Field Triggers)
  1. Put a field trigger on the arming mode for the house area
  2. Create a triggered event that will trigger if the system is disarmed
  3. In case we are in 'break in' mode we created above, stop any warning countdown and turn off emergency blink mode
Dean Roddey
Explorans limites defectum
(reserved 1)
Dean Roddey
Explorans limites defectum
(reserved 2)
Dean Roddey
Explorans limites defectum
I only ask that the videos are posted in an iOS compatible format or on YouTube.
Nest|Harmony|Neeo|LG TV|Smarthings|
I've been doing that with all of them lately.
Dean Roddey
Explorans limites defectum
a suggestion -

as part of the 'Basic Starter Kit', I think you should include the Scheduled/Triggered events. maybe not with system one, but put it up there at system 2. interface building is time consuming, and there are a lot of ways a user can get up and running before investing all of that time into IV development.

simple things are all that you need, like motion turning on a light, or a door opening turning on a light, or changing the color of a Hue bulb in the morning based on the weather forecast.
do the needful ...
Hue | Sonos | Harmony | Elk M1G // Netatmo / Brultech
The user interface stuff that come before the initial chunk of events stuff will be really simple, so it won't take very long. Then we work on events for a bit, then go back for more user interface stuff.
Dean Roddey
Explorans limites defectum
I'm going to move the brief discussion of drivers and fields into System One, right after we first install the first drivers. That'll make it concrete to install them, then go look at one in the driver monitor tab, where they can see what's being discussed.

And that'll leave the Prep-Discussion video purely to the big picture issues. That's before we set up anything, so it'll be more of a bullet list screen type of thing. Or, maybe the marketing blurb video I've already done would be appropriate to use for the Pre-Discussion one? It's already done and covers all those same points basically. I would probably change the look a bit. This is the one I mean:

Or maybe make this the first video, then Installation, then System One, and onwards. That might be the best order.
Dean Roddey
Explorans limites defectum
Nice Job - At some point, take that same approach and have a professional voice over done. You would need to expand it a bit prior to spending that money, but it would be well worth the investment in the end. Also, mask out the keyboard key clicks or mouse clicks in the background.
Dave Bruner

Forum Jump:

Users browsing this thread: 1 Guest(s)