Enhancing M1G rules with a computer
- Thread starter KentDub
- Start date
If you intend to use a lot of UPB, and you will be running a server 24/7 anyway, I would communicate to your UPB devices from the PC. HomeSeer has an excellent UPB plugin -- it does NOT have the problem of keeping in sync with links. If you use UPB, you WILL want to use links as it is one of the strengths of the UPB system. The plugin for HomeSeer is aware of what each UPB link activates/deactivates and adjusts all of its devices accordingly when it sees the link on the powerline.
tenholde
tenholde
KentDub
Active Member
Thanks tenholde. I've been thinking of UPB links, and since there is an inherit delay sending UPB commands, it seems links are the only way to synchronize multiple loads dimming/swittching at the same time. This is indeed a very attractive feature that I would like to keep if at all possible.
I purchased a 12-pack of the UPB 600W dimmers to get me started. My server runs 24-7 on a shared 3000VA UPS (shared w/ workstation, network equipment, etc.). It is rock solid, never crashes, and only reboots once a month for patches, and that is in the middle of the night. I don't have any concerns or problems with using a computer for HA tasks.
However - if I run the UPB from the computer....
1. How to connect the UPB to the computer? I already ordered a serial PIM -- I think that I'll be wanting to add more serial connectivity to it in the future - what are my options? (rackmount serial over IP?)
1A. I only have one serial port on the server, and it's used to talk to the UPS for safe shutdowns for low battery
1B. It's a 1U form factor, so I only have one PCI expansion slot on it (unused at the momment -- but thinking about putting an audio card in it)
2. If I run the UPB through the server, can I still expose the lights to the M1G? (i.e. Can I still use the M1G's security rules to trigger commands to the lights)
3. The UPS for my computers has a EPO connection, which from what I know is required in commercial installations. In addition to shutting everything off when someone is getting shocked, I am also under the impression that it is used by the fire department to ensure no HV power is in the house (I guess if they needed to chop through walls or something). Should I have the M1G trigger the EPO on the UPS during a fire for safety? If so, this might make me rethink my design to ensure that nothing critical is run from the computer (i.e. automatic lights to 50% during a fire is a good thing), as well as install a second smaller UPS for just VOIP-required equipment that dosn't require an EPO.
Thoughts and suggestions appriciated,
Kent
Steve
Senior Member
1. You can either use a USB PIM or you need multiple serial ports on the server. Several ways to do it - a PCI card, USB to multi serial, IP to serial (like the Quatech units). Sounds like a USB or IP to serial may be the way to go for you.
2. No, not directly. You could use the I/O of the Elk but that would be done via an Elk software driver. So whatever software you use would need a driver that could read the state of the Elk's I/O and then you can use that to control UPB via the local PIM. Elk's rules will only work on Elk directly attached devices.
2. No, not directly. You could use the I/O of the Elk but that would be done via an Elk software driver. So whatever software you use would need a driver that could read the state of the Elk's I/O and then you can use that to control UPB via the local PIM. Elk's rules will only work on Elk directly attached devices.
rwarshawski
Member
You guys are way beyond me on this! I am not a programmer, but I do like to fool around with the settings that are within my reach.
About the serial issue:
My automation supplier (http://shore2shore.ca/home-automation) uses a software serial splitter that seems to work from
http://www.fabulatech.com/
I have a Cinemar/HAL/ELKM1 based system on UPB.
It does seem odd that the UPB designers never thought of the out of sync issue.
Has anyone got a viable solution? Right now my system polls the switches every so often but this does take some time.
bob
About the serial issue:
My automation supplier (http://shore2shore.ca/home-automation) uses a software serial splitter that seems to work from
http://www.fabulatech.com/
I have a Cinemar/HAL/ELKM1 based system on UPB.
It does seem odd that the UPB designers never thought of the out of sync issue.
Has anyone got a viable solution? Right now my system polls the switches every so often but this does take some time.
bob
That in my opinion (and I voiced it to ELK) has been a big hole in their system.
They have delved into Home Automation yet they say that the alarm system is their main focus.
Silly, since the future has always been in the automation part.
The fact that there is no (IF) (AND) (OR) statements extremely limits the system from acting on behalf of a person doing it manually.
Hence the word (automatic)
It better relates to the automation of a 5 year olds manual thought process.
It's a shame since I brought this up over 2 years ago.
Good luck...
Marc
PS. The fact that they could not see the alarm piece as being the trivial area in the future is similar to my song theory.
You can put 5,000 paid people in a room for a week or even longer (it will not matter)
or
you can have 1 (John Lennon) during the plane ride to and from that same meeting.
apostolakisl
Senior Member
When the ISY comes out with their Elk module things may be different for Elk. If the ISY gains full control of the Elk (as I am told it will), then you will be able to write all of your "rules" in the ISY which is a vastly superior programming language. ISY has no control of any lighting system except Insteon, so I wonder if UPB could be operated via ISY using Elk as the conduit? Anyway, this Elk module is promised before the end of the year. In my opinion, ISY saved Insteon and they may just do the same for Elk.
Lagerhead
Active Member
It's hardly fair to describe the "alarm piece" as "trivial." When you want protection, you want a bullteproof system, and the M1 is certainly that. It runs, it works, it's solid. And that's not a trivial achievement.
Everybody here (CT) has a bunch of crap installed to meet all of their needs. Elk has a big role in many of these installations. It is one thing to criticize the contemporary paradigm that requires a proliferation of equipment. But it is not reality to expect Elk to "do it all" when nobody else does it either.
Everybody here (CT) has a bunch of crap installed to meet all of their needs. Elk has a big role in many of these installations. It is one thing to criticize the contemporary paradigm that requires a proliferation of equipment. But it is not reality to expect Elk to "do it all" when nobody else does it either.
As a newbie who's about to invest in an M1G system, how much of a problem is the lack of UPB feedback? We've only got a 3 bed 2 bath 2200 sq foot place, and for the moment, my main focus will be exterior lighting for security, with some interior lighting later. If I manually switch a light on/off, you're saying the Elk won't know about it, correct? Will that cause any problems with other routines or scenes I set later?
And for the record, I'm comparing it against an HAI Omni IIe, which, I've been told, doesn't have that issue and can track the changes in the lights.
TIA!
And for the record, I'm comparing it against an HAI Omni IIe, which, I've been told, doesn't have that issue and can track the changes in the lights.
TIA!
tmbrown97
Senior Member
KentDub - When you started this thread 7 months ago, you were just starting out... you've obviously since gotten the hang of developing for the Elk given that you've successfully created an impressive Droid app.
Did you ever get more into this scene control issue? I think my favorite option would be something that lets the Elk maintain the CIM and control, but augments it by helping it realize status changes. That keeps the mission critical stuff on the Elk where it belongs, and keeps the Nice to Have's on the theoretically less reliable server.
I'd also like to do trickier programming... like if I send link 46 - don't trigger 6 loads all at the same time; sequence them (multiple loads starting at different times or with delays in between). I plan to look at doing this with Elve.
Did you ever get more into this scene control issue? I think my favorite option would be something that lets the Elk maintain the CIM and control, but augments it by helping it realize status changes. That keeps the mission critical stuff on the Elk where it belongs, and keeps the Nice to Have's on the theoretically less reliable server.
I'd also like to do trickier programming... like if I send link 46 - don't trigger 6 loads all at the same time; sequence them (multiple loads starting at different times or with delays in between). I plan to look at doing this with Elve.
KentDub
Active Member
@RagnarD: No problems with UPB for me. I was initially greatly concerned when I was planning the system but as it turned out it wasn't a problem. Turning a UPB light on/off manually reports correctly to the Elk -- the thing people are referring to is the "scene" (link) switches (a light switch that controls other switches).
I solved the bulk of my problems by first separating my lights into logical groups. The Elk has three main groups that you can control en masse (House codes, or banks). An example of a rule I have is "All lights in bank 1 off, then turn on family room light to 25%" -- my television task. Bank 1 is my interior lights. The commands execute so fast that if the family room light was on the 25% will be sent to it before it is off or the light was off and it is dimming on. Either way, it is the smooth transition I was looking for. This setup also allows me to have commands ignore exterior lights.
The only thing that doesn't work well with UPB is using physical scene switches. My installation was retrofit so I don't have any -- all of my scenes are thru the Elk and my 3-way/N-way configurations are done via physical wiring to gang the switches together.
@Work2Play: (Note: I'm typing this from memory from tests done some time ago, it is not a tutorial). One thing I originally played with for having multiple switches fade at the same time was to create a UPB link then have the Elk trigger it in a task followed by individual light commands. The result was the lights would fade at the same rate and the Elk would within seconds have the correct status of the light. The downside was this created a several second lag that physical commands to the light switch would be overridden (this is worsened the larger the link).
For example, say you create a link 10 as grouping lights 1,2, 4.
Then, create an Elk task that executes these steps:
1. Set Link 10 to 50%
2. Set Light 1 to 50%
3. Set Light 2 to 50%
4. Set Light 4 to 50%
As the individual commands execute the lights are already fading so their fade rate isn't changed, the desired smooth behavior is maintained. However the individual commands cause the Elk to obtain the correct status of the light. At this point you are thinking that this is all great and what not, but how do you control this from a physical switch? Easy, don't link the physical switch. Create an Elk rule that activates your task(s) based on the dim level of the physical switch. Worst part: this is noticeable latency involved.
There are downsides to this method, such as the latency and possible (if done very quickly) override of manual input. This also causes a flood of UPB traffic for a second or two. If you live with a small family I don't think you would run into any trouble - but the possibility is there none the less.
All in all, the whole sync/scene issue turns out to not be a big deal for me. I am extremely happy with my Elk & UPB installation and would do it again given the choice. Interfacing with the Elk from both a PC and from my Android app was fairly easy, especially given the excellent support Elk provides.
@TaskMan: The more I think about it the happier I am that Elk isn't trying to put out an all-in-one system. Most of us here know that the "separates" design pattern is required for maximum control and customizability. The M1G is a rock-solid piece of hardware. Elk did well to design the system to communicate with other products (both via serial and Ethernet connectivity). I agree with the other comments, it is not an end-all-be-all product; it is rather the central component in my overall automation/security solution.
Regards,
Kent Williams
Williams Automation
*Edit: By 'banks' I mean House Codes... Banks are used when programming with the Elk, not when working with rules (I'm working on a major upgrade to ElkDroid right now -- that's where my mind is, sorry).
I solved the bulk of my problems by first separating my lights into logical groups. The Elk has three main groups that you can control en masse (House codes, or banks). An example of a rule I have is "All lights in bank 1 off, then turn on family room light to 25%" -- my television task. Bank 1 is my interior lights. The commands execute so fast that if the family room light was on the 25% will be sent to it before it is off or the light was off and it is dimming on. Either way, it is the smooth transition I was looking for. This setup also allows me to have commands ignore exterior lights.
The only thing that doesn't work well with UPB is using physical scene switches. My installation was retrofit so I don't have any -- all of my scenes are thru the Elk and my 3-way/N-way configurations are done via physical wiring to gang the switches together.
@Work2Play: (Note: I'm typing this from memory from tests done some time ago, it is not a tutorial). One thing I originally played with for having multiple switches fade at the same time was to create a UPB link then have the Elk trigger it in a task followed by individual light commands. The result was the lights would fade at the same rate and the Elk would within seconds have the correct status of the light. The downside was this created a several second lag that physical commands to the light switch would be overridden (this is worsened the larger the link).
For example, say you create a link 10 as grouping lights 1,2, 4.
Then, create an Elk task that executes these steps:
1. Set Link 10 to 50%
2. Set Light 1 to 50%
3. Set Light 2 to 50%
4. Set Light 4 to 50%
As the individual commands execute the lights are already fading so their fade rate isn't changed, the desired smooth behavior is maintained. However the individual commands cause the Elk to obtain the correct status of the light. At this point you are thinking that this is all great and what not, but how do you control this from a physical switch? Easy, don't link the physical switch. Create an Elk rule that activates your task(s) based on the dim level of the physical switch. Worst part: this is noticeable latency involved.
There are downsides to this method, such as the latency and possible (if done very quickly) override of manual input. This also causes a flood of UPB traffic for a second or two. If you live with a small family I don't think you would run into any trouble - but the possibility is there none the less.
All in all, the whole sync/scene issue turns out to not be a big deal for me. I am extremely happy with my Elk & UPB installation and would do it again given the choice. Interfacing with the Elk from both a PC and from my Android app was fairly easy, especially given the excellent support Elk provides.
@TaskMan: The more I think about it the happier I am that Elk isn't trying to put out an all-in-one system. Most of us here know that the "separates" design pattern is required for maximum control and customizability. The M1G is a rock-solid piece of hardware. Elk did well to design the system to communicate with other products (both via serial and Ethernet connectivity). I agree with the other comments, it is not an end-all-be-all product; it is rather the central component in my overall automation/security solution.
Regards,
Kent Williams
Williams Automation
*Edit: By 'banks' I mean House Codes... Banks are used when programming with the Elk, not when working with rules (I'm working on a major upgrade to ElkDroid right now -- that's where my mind is, sorry).
