ELK M1 and Lutron RadioRa2: Keypad button press

[wkearney99]

True, CQC is certainly on the list.  But I've learned over the years that PC-based integration is not necessarily the best way to gain stability.  And for lighting you want stability.  An embedded box in a can is often a lot more reliable.  Not as feature rich, of course, but that's not as important here.
 
The upside is I have two main repeaters, so I've got two serial and ethernet ports for gaining access to the system.  So if they both want serial access I won't have to fight over just one...

 

[Dean Roddey]

Depends on what level you are talking about. The RA2 system itself provides the stability for lighting, and insures it will always work. And there just honestly isn't an issue with CQC if you set it up, put in the closet, and don't mess with it, just as with any system. I've had two customers this last week who had forgotten their CQC admin passwords because they'd not even needed to do anything to it for years. If you set it up right, it's pretty much set and forget.
 
Media is always trickier, but it is for everyone, not just us. Even hardware players hiccup all too often. But on the core stuff, CQC is extremely solid. Since it is fully networked, you never need to directly interact with the server. Even configuration can all be done from clients. So set up a small box in the closet with a SSD, and it should be every bit as solid as any other option. I mean C4 is a PC as well, though they try their best to hide that fact.

 

[wkearney99]

As I posted, it's outdoor motion control I'm after.  Pulling those inputs into somewhere and then having some logic applied to determine how to handle the lights.  
 
The rest should probably have it's own thread.  
 
But the bigger point here is I intend to have other automation stuff involved.  Just not right now.  Nor do I want to have any of that interfere with an embedded control over the motion & lighting setups.  PC's get updated and fiddled with.  Which is fine.  That and their configurations often get changed, again, fine.  But I don't want the ability or efforts to do those things to get in the way of the basic light & motion controls.  Thus a board in a can, with direct wired connections to the motion sensors is a very good fit.

 

[Dean Roddey]

Not arguing with or anything, but on one point I have to say that PCs only get updated and fiddled with if you update or fiddle with them. PCs used as automation servers don't need to be updated or fiddled with. Set them up and leave them alone. The server doesn't need to be running anything else, so there's no need to mess with it. You can if you want to, because you enjoy it, but there's no particular need to once it's set up. You'd only be changing CQC's configuration, though that wouldn't be often either, and you'd not need to do that directly from the server, just use a client to do it remotely.
 
So don't think of it as a PC. It's not there to run a bunch of programs or to be directly accessed, it's there to run one thing and be left alone. It doesn't have to be a large box at all either, when it's dedicated to that task, at least by modern standards.

 

[wkearney99]

And yet you keep arguing the point.  I doubt anyone here misses what you're trying to say.  
 
There's a tremendous difference between the reliability of an embedded system designed to run 24x7 in a metal can and a PC. Even a single board setup like a SuperMicro board with a DiskOnChip has more involved in it that an embedded system.  To say nothing of security issues associated with running a general purpose operating system (on which your products need to run).
 
Yes, of course, you can ignore the PC in a similar fashion, but that's what you're doing: ignoring the endless series of new problems with it's software and OS, many of them security-related.  Whereas an embedded system, focused solely on doing it's job really has none of that.  
 
This isn't to say I'm not considering a PC-based solution for additional portions of this project.  Nor am I ignoring that there might even be overlapping or even duplicated functionality.  I'm well aware of that.  I think the CQC stuff is a fine solution
 
Just so I'm clear:
 
THAT ISN'T WHAT I'M LOOKING TO USE IN THIS PARTICULAR CONTEXT.
 
So shall we stop beating this dead horse?

 

[dgage]

I have to say that my CQC and RadioRa2 implementation hasn't been 100% reliable and I'm not sure why it stops working periodically.  I have a Windows 7 MCE system running CQC in a VirtualBox and I rarely update them or mess with them, primarily because one runs the cable TV system for my entire house and the other is involved in my lighting system.  Every couple months I notice that my RadioRa2 Pico controls in the bedroom stop working.  I login to my MCE box and take a look at the CQC VM and everything is running but I have to login to the CQC Admin console and restart the RadioRa2 driver.  Not sure what is causing the problem but it has definitely happened more than once.  And I usually don't spend time to mess with or update the CQC VM until I have to login for some reason.  And I haven't messed with CQC much
 
So maybe a dedicated machine would be more reliable as maybe it is the VM causing the issue but everything else seems to be fully operational so it is hard to say.  This is just my experience.

 

[wkearney99]

Sure, the more layers you add the more places there are for hiccups to occur.  
 
Running in a VM raises a bunch of possible complications, not least of which is dealing with hardware abstraction problems. Doing anything real-time related in a VM is asking for trouble.  I would never chose to run an MCE setup inside a VM.  I've got several hypervisor setups (VMware, Hyper-V, KVM and VirtualBox) and none of them really handle MCE all that well (for various different reasons).  
 
But in re-reading your post it looks like you've got MCE native and CQC in a VirtualBox VM, correct?  My only comment about that would be make sure the underlying hardware (especially the memory) is capable of reliably running a VM.  Not using ECC memory is a sure way to get weirdness cropping up.  I had a VMware setup on a Supermicro board that would act wonky until I put ECC memory into it.  That and I'm sure there are areas where VirtualBox is going to come up short compared to more robust Hypervisors.  
 
If you don't need a lot of horsepower (and lighting control really shouldn't need much) you'd do well to look at some of the recent Atom-based systems.  They're incredibly stingy on power (generating a lot less heat and noise) and can offer reasonably decent performance for low-to-mid horsepower requirements. They've got their limits, of course, but for automation they'd seem like a good fit. 
 
As for windows and reliability, I find monthly scheduled reboots are a great way to cut down on the intermittent and impossible to repeat problems.  Something to be said for just clearing out the cruft with a reboot now and then.

 

[dgage]

Good points wkearney, especially the ECC memory, which I hadn't thought about previously.  But if I'm using a (high-end) consumer grade motherboard, I'm not sure the ECC would make a difference or even work.  I'll look into it though.
 
At some point I will put CQC on dedicated hardware, especially once I plan to do more with CQC.  But right now I have other focuses and CQC doesn't natively support everything I'm looking for, namely the RadioRa2 thermostats.  I could look at other thermostats but that was one of the reasons I purchased the RadioRa2 system.  I wonder if the Elk supports the thermostats and temperature sensors.

 

[Dean Roddey]

So maybe a dedicated machine would be more reliable as maybe it is the VM causing the issue but everything else seems to be fully operational so it is hard to say.  This is just my experience.

 
It absolutely would. Much to most of the complaints about PCs being unreliable come from these types of issues. Just because they can do many things at once, doesn't mean you always want them to. We have extremely complex systems out there and they seldom give any problems because the automation server is treated like a specialized device and not asked to do other things.

 

[Dean Roddey]

And yet you keep arguing the point.  I doubt anyone here misses what you're trying to say.  
 
There's a tremendous difference between the reliability of an embedded system designed to run 24x7 in a metal can and a PC. Even a single board setup like a SuperMicro board with a DiskOnChip has more involved in it that an embedded system.  To say nothing of security issues associated with running a general purpose operating system (on which your products need to run).
 
Yes, of course, you can ignore the PC in a similar fashion, but that's what you're doing: ignoring the endless series of new problems with it's software and OS, many of them security-related.  Whereas an embedded system, focused solely on doing it's job really has none of that.  
 
This isn't to say I'm not considering a PC-based solution for additional portions of this project.  Nor am I ignoring that there might even be overlapping or even duplicated functionality.  I'm well aware of that.  I think the CQC stuff is a fine solution
 
Just so I'm clear:
 
THAT ISN'T WHAT I'M LOOKING TO USE IN THIS PARTICULAR CONTEXT.
 
So shall we stop beating this dead horse?

 
I'm not trying to beat anything, but these threads get read by more folks than just us, and in the future. I'm just going on the record for posterity.

 

[wkearney99]

Well, the ECC memory only works with a CPU and a board that supports it,   That and having plenty of memory is key with VMs.  There's a lot of 'behind the scenes' processing that goes on with the hypervisor managing resources.  If you don't have enough memory the hypervisor has to do a lot of swapping through the disc.  The VM doesn't see or know about this happening, it just gets delayed.  Real-time stuff runs into problems with this because they don't know they're running in a VM that's being swapped too much.  That's the short answer.
 
So if you're going to run things hosted inside a user-space VM like VirtualBox you really do need a lot more memory than you might think.  And if that memory has even the slightest hiccup the VM can run into problems.  Having ECC memory being handled by the hardware helps alleviate that.

 

[dw886]

dgage - Elk does support the Radio RA2 thermostats - I've run into it multiple times in the manual when reading up on my Radio RA2 lights.  I haven't gone that route, as I have 4 Honeywell Prestige thermostats that are controllable via their website.  Either swapping them out for something different or determining how to control them via the elk is on the agenda, but I haven't found an interface for the Honeywell system that'll take commands (either via serial connection or sending commands to their web interface).

 

[wkearney99]

I won't be getting into the thermostats until the included stuff gets all sorted out.  We went with geothermal and I don't want to do anything to the system until it's clearly been 'shaken down' and proved working properly  We've three units and four zones, so it'll take some doing to get all the themostat factors thought-through.  

 

[cjett]

Sorry to dredge up an old thread and I'm sure the original poster has already sorted it, but for others who find this thread I wanted to mention another option to integrate without using a separate controller when you only need to do this in a couple of instances.  
 
I used the Lutron Radio Ra 2 Visor Controller (RR-VCRX-WH) to capture the Lutron controller button press.  That closes one of the Contact Closure Outputs (CCO) on the Visor Controller.  That contact closure output is connected to an input on the ELK.  Rules in the Elk are listening for the contact closure and when it occurs can the activate anything within or connected to the Elk.  It's a simple solution when you only need 1 or 2 buttons actions (the Visor Controller 2 input).  
 
The specific use case for me:  I needed to turn on a fireplace, an overhead fan and the fan within my HVAC from a single button on a Radio Ra 2 controller.