Top 5 List of HA Hardware/Software Combinations

[Dean Roddey]

The Omni doesn't report any events related to changes in screen selection on the keypads, assuming that there are such things. That's not to say it couldn't be done, I don't know. You may be able to have such a thing set an unused input's value or something like that to act as a trigger.

 

[Dean Roddey]

The Elk and Omni are pretty similar in the access they provide to the automation system. The boxes themselves are obviously somewhat different so that means that somewhat different stuff is available, but they seem to provide access to most of what they have. But, there again, not being a real world user, I'm not that clear on what all they have. I just know them in terms of what's available via the control interface. But, scanning through the available settings and such, they seem to pretty much expose what's there.

 

[Steve]

Your first definition is what I was after. My example depends on the Omni reporting that a user has selected a different screen on one of its touchscreens to the serial port connected to CQC. If changing views does not generate an event in the Omni, or if the Omni doesn't make that information available to CQC, this scenario would not be possible. So my granualrity question is: Exactly how detailed is the information that the Omni tracks? Does it report it all through the interface with CQC? And does it tend to report more, or less, or the same amount of detail as an Elk M1 panel?

Mike, I'm not sure I see your logic in doing an action based on switching screens on a keypad. I'm pretty sure you will not get that functionality in the Elk. I'm not sure I would want an action (playing your TTS example) simply because I went to the T-Stat screen. There may be many reason why I went to that screen and may not want an action associated with that. Why not just have action buttons on the screen, so when you go to the t-stat screen if you want an announcement, have a button that plays the announcement. Of course this assumes you are using generic touch screens and using CQC or ML on them. Or in the case of Elk you could run RM. Granted HAI has a color TS with built in firmware, but it is not fully customizable like with CQC or ML.

 

[upstatemike]

Mike, I'm not sure I see your logic in doing an action based on switching screens on a keypad. I'm pretty sure you will not get that functionality in the Elk. I'm not sure I would want an action (playing your TTS example) simply because I went to the T-Stat screen. There may be many reason why I went to that screen and may not want an action associated with that. Why not just have action buttons on the screen, so when you go to the t-stat screen if you want an announcement, have a button that plays the announcement. Of course this assumes you are using generic touch screens and using CQC or ML on them. Or in the case of Elk you could run RM. Granted HAI has a color TS with built in firmware, but it is not fully customizable like with CQC or ML.

It was not a real world example. I was just trying to determine where these systems draw the line on what they report. I could have just as easily used an example of somebody changing the setpoint on the thermostat. The point is: What all generates a reportable event beyond basic changes in zone inputs or arming status?

 

[Dean Roddey]

Every change in an input or setting won't necessarily generate an 'event' from the Omni, but the value will be seen to change by CQC, which can be configured to generate an event when that field changes or goes higher or lower than a value and so forth.

 

[IVB]

I would love to come out and play and join this discussion, but I was chastised heavily this morning by the wife as she said that now I do all this CQC AND Elk stuff, run wiring all over the house, or chat on CQC/AVS/Cocoon.

Now I may not be the smartest husband, but I'm fairly certain it's not a good thing when your wife knows all the sites you visit by name.

I'll be back to play more tonight or tomorrow [maybe].

 

[upstatemike]

Every change in an input or setting won't necessarily generate an 'event' from the Omni, but the value will be seen to change by CQC, which can be configured to generate an event when that field changes or goes higher or lower than a value and so forth.

Event might not have been the best term to use. I meant that it generates a notification to CQC by transmitting the new value when it changes. Polling would pick up the change eventually but probably not soon enough to trigger a real time response.

 

[electron]

This is going to be a difficult topic, since there are so many good combinations (i.e. Elk/Girder/Netremote), this is usually a personal preference based on requirements a person might have. All imo of course.

 

[Steve]

I can tell you that just about anything that changes in the Elk is reflected almost immediately. You can see light changes, security (zone) changes, output (relay) changes, etc. And these would then be seen in CQC immediately without any polling.

 

[Spanky]

Every minute detail of the things happening in the M1 being spit out the serial port would swamp the serial port. 99.9% of it would be useless to an attached PC running Automation Software.

Features that can be used in real world applications without burdening automation software with usless trash data is what is desired. Also the complexity of cataloging all this data to be used in some automation programming language will scare off the bulk of the integration market.

Upstatemike: To answer your question, is information sent from the M1 to the Automation Software indicating that a touchscreen page has been changed?
No, the M1 does not know when a touch screen page changes, nor does it care. The touchscreen acts just like PC based automation software, it gathers data from the M1 and builds screens accordingly.

On the other hand, if it was a desired feature that the bulk of the market wanted and could use, it can be added.

 

[Dean Roddey]

I meant that it generates a notification to CQC by transmitting the new value when it changes. Polling would pick up the change eventually but probably not soon enough to trigger a real time response.

As I said above, the Omni, unlike the Elk, generates no notifications. But, because the polling is uber-fast, unless you've got a lot of stuff installed, it'll see it pretty quickly. Not real time no, but even async notifications from the device don't guarantee that really.

The boxes are sometimes held up a little bit because they have to finish X before they can do Y, and unless the automation system uses a blocking read paradigm (i.e. where all the drivers have a dedicated read thread always blocked on input from the device), they will still 'poll' in that they just wake up periodically and see what's come in. That period can be pretty small, but still. And even if they have a dedicated thread, outgoing commands have to use that same connection which can cause small delays in input processing.

A little delay on the box, some delay on the read, a little delay from wiating for the current outgoing command to be sent, the resulting generation of an event that propogates over the network as a datagram, to something that sees it and is set up to respond, which has to go through it's list of thing ti should respond to and see if this guy is one of them, which then has to put it in a queue where a worker thread wakes up and picks it up to process. The moderate to worst case delays in that chain can prevent even an async notification from being as real time'ish as you might think.

 

[upstatemike]

This is going to be a difficult topic, since there are so many good combinations (i.e. Elk/Girder/Netremote), this is usually a personal preference based on requirements a person might have. All imo of course.

Exactly. And if people will discuss their reasons for choosing a particular combination it might help set off a flashbulb in the mind of somebody else struggling to make sense out of all the options.

 

[upstatemike]

Every minute detail of the things happening in the M1 being spit out the serial port would swamp the serial port. 99.9% of it would be useless to an attached PC running Automation Software.

Features that can be used in real world applications without burdening automation software with usless trash data is what is desired. Also the complexity of cataloging all this data to be used in some automation programming language will scare off the bulk of the integration market.

Upstatemike: To answer your question, is information sent from the M1 to the Automation Software indicating that a touchscreen page has been changed?
No, the M1 does not know when a touch screen page changes, nor does it care. The touchscreen acts just like PC based automation software, it gathers data from the M1 and builds screens accordingly.

On the other hand, if it was a desired feature that the bulk of the market wanted and could use, it can be added.

Common sense was telling me what you have just confirmed. You have to draw the line somewhere on what is reported. So the point of my question (which really has nothing to do with touchscreen pages) is whether the Omni, with all it's periphereals, really reports any more information to an attached PC than an Elk panel does? Or does most of the data specific to touchscreens, and built-in Russound integration, etc. get stripped out of the Omni data feed to the point where both systems expose pretty much the same amount of information to a PC host?

Lets face it, the Omni is a LOT more expensive than an M1. Folks want to know if it is technology or cosmetics that they are paying for and the hardware/software combo systems might not give the same answers that you get when evaluating hardware alone.

 

[upstatemike]

As I said above, the Omni, unlike the Elk, generates no notifications. But, because the polling is uber-fast, unless you've got a lot of stuff installed, it'll see it pretty quickly. Not real time no, but even async notifications from the device don't guarantee that really.

Thanks Dean. I think I grasp it now. I guess polling vs async is not going to have enough of an impact to be a differentiator here and Spanky has clarified the line between what information is exposed and what is not. I'll back off any more discussion about the mechanics of the "link" in hardware/PC combo systems so that people can focus on expressing opinions based on feature sets.

 

[toymaster458]

On the other hand, if it was a desired feature that the bulk of the market wanted and could use, it can be added.

This is what I love about Elk Products!!