Homeseer Hs Design How to Use an Input Text Box

Whole-house automation integrates a very wide array of technologies, all of which pretty much fall into two fundamental categories: controllable devices that respond to commands and do something useful, and sensors that monitor, measure, and report conditions.

They work closely together with programmed triggers and events. Triggers are usually a change in device status or a sensor reporting some over-threshold condition. The Event is usually a  programmed action that is expected to take place when a Trigger happens. In a relatively simple media room control example, the user presses a Play Movie button on a touchpanel, triggering a series of events that  turn on the A/V system (if a sensor notes it is not already ON) , selects  the A/V  input if needed,  dims room lights , starts video playout, etc. The programming to make this happen is straightforward–not a lot of conditional logic– and the complete automation scenario can easily be defined and documented for a programmer to execute.

In a Whole House Automation system there is a much more complex programmed relationship between devices, sensors, and conditions.  Data from the same sensor can influence may events, and many sensors can influence the same event. Condition-sensing can extend well beyond whether the system is already powered up or not– temperature, time of day, existing light levels, state of other devices, phase of the moon, etc.–can all directly or indirectly influence what action is to be taken when a trigger happens.

Its inhuman…

Once you plan beyond media room A/V control  and  lighting, a smaller percentage of events are triggered directly by deliberate human action. This is what automation is…the automatic sensing and reacting to conditions with little or no human interaction. The Humans pre-define what is expected to happen in a given series of events and conditions; the largely unattended Machines do the actual work. Still more complex logic is needed to instruct the controlled devices to do their useful work.

User programmability

Triggers that initiate this automated processing can be a scheduled one-time event or a recurring event like starting the lawn sprinklers at 6:00 AM on alternate days. The triggers can directly cause some action to happen, or one or more Conditions can modify or delay the action. In our Irrigation example, conditions such as Time of Year and the data from moisture sensors or rain gauges can be used to influence the zone watering duration, or whether to water at all. Any device that can change state can be used to trigger automated actions–a doorbell button, a glass-break sensor, a motion sensor, a water-where-water-shouldn't-be sensor, someone entering a front door lock code, a car entering a driveway, etc. Event triggers can be cascaded (one trigger can result in actions that trigger other events) and can be the result from something  that didn't happen, such as your daughter didn't arrive home from school between 4:00 and 4:30 PM.

Condition-reporting devices like motion sensors can influence one or many events—a motion sensor on your home security system in a Disarmed state can do double duty to trigger lighting and  influence lighting levels and patterns depending on time of day or measured ambient light level.  The more automated your home, the more complex the control algorithm.

That lack of direct human interaction is one of the things that makes Automation very complex. Somehow, the Automation control logic has to be programmed to do your bidding. That means a detailed knowledge transfer between you and the automation control equipment. Most people hire a programmer for that; the resulting program gets loaded into the device doing the controlling (usually called a Controller or a Processor). The controller can be a self-contained device, software running on a PC, or part of some other system, like a home security system that also does some home automation duties. You may need only one Controller or a network of Controllers. For now, it's collectively  just  The Machine.

The Machine's role is to be an Event-Action processor. It picks up events triggered by a schedule or by a sensor and programmed action results.  In a typical AMX control system the Machine is one or more Netlinx processors interconnected with any of a gazillion different AMX  and third-party devices that can sense status and conditions (inputs) and control things in your home (outputs).

The Machine's Program is usually something your Certified AMX Reseller- agent-person comes up with, after you offer up your extensive list of what all you want to be automated.  Whenever you think of something new to do, or wish to add a new Condition to an existing action, you call your programmer back, the program is changed, recompiled, reloaded into your Netlinx controller, and verified functional. Off in the distance, a Bill Customer event is triggered.

 All of which works quite well, especially if you know exactly what you want your automated home to do, or are dealing with a very experienced automation designer who can work with you to extract all the intricate details of your Grand Automation Plan and accurately translate your wishes into program code. There are plenty of very good ones out there who do all this quite well.

But there is a problem with that process, in my house at least. I didn't think of everything up front.  I actually planned very little of my automation scheme, I had no clue at all about what it would eventually become. My system is the result of a 28-year evolution.  I change my mind frequently as new ideas surface and need some way to make simple, non-programmatic changes.

The DIY Factor

 I want to be able to add, modify, and delete events and conditions myself, without having to modify Netlinx code or write code at all, at least for simple event-action logic.  The AMX system, with its massive array of hardware devices and software modules, is the best and most comprehensive in the world for sensing conditions, processing events, and controlling devices…but, alas, it (and Crestron and Control4 and about all of the commercial home automation products) do not surrender themselves willingly to user-implemented features and modifications.

So….I had to come up with some dashboard-like , GUI-driven event action processor that could let me create events, assign triggers, and define desired action under various selectable conditions. This new processor would have to communicate and interact with the AMX processor to have access to AMX devices– it would send and receive commands, messages, and events to and from the AMX controller, essentially dividing and sharing the automation task between itself and AMX.  Ideally the AMX program would change only when new devices were added; for setting up new events and triggers this other Processor would become the Master.

My requirements: No compiling, no reloads, no program restarts, no PC reboots…create a new named event by filling in text boxes, selecting Conditions from drop-down lists, associate Events and Devices from items in a database, save, and be done. Automation Utopia for the DIY-er.

Alas, no such thing existed or exists today.  But there is something that, with a little high-level integration work, comes very, very close: A combination of AMX Netlinx controllers, AMX control devices, and Homeseer HS2 Home automation software ( www.homeseer.com. )

AMX and Homeseer share automation duties

HS2  is a Windows-based automation product that is completely programmable by the user. In my system's architecture shown to the left (click on it to get a bigger view) AMX manages device input/output for touch panels, IR sensors, IR emitters, some motion sensors, several contact closure inputs, relay outputs (sprinklers, garage door motion), LED message boards, HVAC thermostats, etc.

Homeseer manages all X-10 and Z-wave lighting (see my other posts), some motion sensors, several RF input devices (like the Homelink button on the car's sun visor), Temperature monitors on the HVAC compressors, a Current Cost energy usage monitor, etc.  An old-school two-way RS-232 data link connects the two so the two "brains" can exchange messages and commands with each other.

 The division of responsibilities lets me use Homeseer's most excellent event/action manager and still interact with any AMX gear. The AMX system still has a very complex program–it has extensive decision logic too, done deliberately so it can still do critical things if Homeseer is down or misbehaving. But that logic doesn't have to be modified just to make a small change or add some simple events and actions.

Homeseer manages all lighting, does all the event logging and reporting, and creates energy usage reports for use by energy management events. It also extracts Caller ID from incoming phone lines (land based and wireless when the mobile phones are docked) and interacts with a Vonage VOIP connection to call out for emergencies and allow remote control of everything from any phone.

In future posts I'll show how the Homeseer user interface is used to control AMX and other third-party devices and interact with a variety of compatible sensors.

//Mark

0.000000 0.000000

Homeseer Hs Design How to Use an Input Text Box

Source: https://markhershey.wordpress.com/2010/10/11/amx-and-homeseer-hs2-the-auto-in-home-automation/

Share this post