Elk Temperature sensors.. again.. options?

[Mr.Tim]

I think for as long as the m1/m1g has been in production I've been seeing conversations about temperature sensing options for the units.

Conversations about how to make the sensors looks better, and recently an excellent analysis of how elk sensors communicate.

From my [largely electronically-challenged] analysis, I think I have the three temperature sensing options available:

1) Elk temperature sensors. Pros are that it works. Cons are that they are relatively expensive. However, it was recently noted that they communicate via serial, which in my uneducated analysis would indicate each sensor has a built-in A/D converter using 12 bits, which provides excellent resolution. The Elk input must be set to type 33 to read them.

2) LM35+opamp. Pros would be the relatively low cost. Cons being you have to assemble them. Elk panel would be set to type 34(?) to read them.

3) DS 1-wire sensors. Pros are that they are extremely inexpensive. Cons, you have to interface the sensors to the Elk panel. Perhaps the Midon temp08? It has been stated that Elk will be introducing a 1-wire interface.

For my own purposes, I think that option #1 is least attractive due to cost. I am in the final stages of finishing my new house, and I am looking to monitor far too many temperatures to make the Elk sensors economically feasible. I want to monitor temperature in each room, temperature of each radiant zone supply/return (3 zones), temperature of the radiant slab in each bathroom, temperature of the hot water heater and temperature of the hot water recirculating line. Eventually I would like to monitor the temperature of each radiant /loop/ (25 loops), although this is largely for my own amusement.

Options 2 & 3 are about equally attractive, although the rumor of an impending 1-wire driver is exciting.

My question at this point is about polling each type of sensor. I would like to know if there are any advantages to say, a digital output versus analog. Will polling a certain type eat up cpu? Or will one type be a problem to constantly update and make sure the rooms are maintaining temperature?

TIA,

Tim

 

[carry15+1]

Hi Tim,

I'm not an Elk expert, but here is what I think.

Unless Elk supports 1-wire in the future you're looking at monitoring way too many temperatures for the Elk.

Even if Elk eventually supports 1-wire, you would consume a huge portion of the available rules space for your logic.

Are you planning a separate home automation controller for your installation?

I love the M1G, however I feel it is a security panel first, with some HA capabilities thrown in. My installation is not as advanced as yours and so I am satisfied with temperature feedback from my 5 Elk keypads, and two Elk remote temp sensors.

There are HA controllers that support 1-wire. The Homevision pro I use can have up to 64 DS1820 1-wire temp sensors. All the logic can be in the HVpro, or done with HA software and you could pass ascii messages to the M1G when you want it to do something like adjust a thermostat etc.

John

 

[Mr.Tim]

I agree with the point that all of these temeratures would be too much for the Elk.

I got off on a bit of a tangent as I got further into the post. A lot of these temperatures would be monitored only, which could be handled external from the Elk (by necessity perhaps, although I wonder what the 1-wire interface would give us).

However, I would like to monitor temp in each room (12 rooms at this time), the two radiant slabs, and the hot water. Fifteen sensors in all, each requiring rules to control actions.

I was considering the Elk panel for HA only; no security. I have a Ademco 128BP panel with serial communication for security. The Elk would handle the temperatures/hvac adjustments, the driveway sensors/gate and maybe some lighting.

My theory is to have independent systems that are tied together (I also have a CAV6.6) by a front end such as CQC or MainLobby (undecided at this point, seems so far away!). Should the computer fail, I want to continue to have security and heat. If the HA panel should malfunction, I want my security to continue working. You get the idea.

I have looked into other panels for HA, and I will revisit some of your recommendations. However, although the Elk is perhaps not the best suited for the temperature applications, the expansion capabilities and increasing support are very attractive.


Tim

 

[Spanky]

Your option 2 must be calibrated to display the correct temperature which could be a problem.

Your option 3 for the iButton temperature sensors is in development.

 

[carry15+1]

Tim,

As I stated, I LOVE my M1G, but I would not recommend it as a HA control simply because of the (current ?) limitations on rules space, lack of nested logic, lack of OR function, etc. I believe it is a very capable alarm panel with the bonus of HA functionality and with lots of other great features like remote telephone control.

Even if 1-wire support comes to the M1G I don't know that the memory available in the M1G could do what you're looking for. My rules are probably about 50/50 between security and HA. I have about 120 rules and 14% space remaining. As the HVpro comes on line I will need to strip out most of the HA from the Elk to make room for the security stuff I have yet to implement.

The thing is the Elk can communicate with probably every HA controller out there through rs232 ascii messages. So, you can do all the temperature monitoring and logic externally and just have rules that control your HVAC when a message is received from the HA controller/software.

I was considering the Elk panel for HA only; no security. I have a Ademco 128BP panel with serial communication for security. The Elk would handle the temperatures/hvac adjustments, the driveway sensors/gate and maybe some lighting.

Tim

I don't have gates, but I have a long drive with a driveway sensor. At night my post lights stay on from just after dusk to just before dawn. The 3 lights on the front of the house are on from dusk until 10:30 pm (at 35% brightness). If a vehicle is detected the house lights come up to 100% for 15 minutes, then go back to 35%. Other things happen like announcing the activity and logging the entry into the Elk log. If it's after 10:30 (lights off) them come on at 100% and drop down to 35% for the remainder of the night. This is pretty simple stuff, but requires a BUNCH of rules in the Elk to accomplish. I mention this as you may not have played with ElkRP yet, and may not understand the frustration of no OR logic or nesting levels. I don't mean to knock the M1G by any means, but this is why I consider it "primarily" as a security system with a bunch of very nice extras thrown in.

Because the HVpro is down in the "laboratory" and cannot be hardwired to the M1G at this time I use several x10 signals to interface the M1G to the HVpro. So, if the garage door opens (becomes not secure) the M1G sends J1 on (off when it closes). The HVpro then logs the event into it's event log.

The M1G can log events, but it is cumbersome at best. Of course it automatically logs security events like armed/disarmed/alarm/etc.

I may get flamed, but I really wouldn't recommend the M1G as your main HA controller.

John

 

[Mr.Tim]

Spanky- Thanks for the info, seems like using the analog inputs might be more work than I'd care to do

John- Point well taken. I don't know that I would have a tremendous amount of rules, but the limited instruction set is worth noting. The Homevision Pro definitely has a rich feature set, which substantiates the price.

I am looking to add some degree of automation to several stand-alone systems. As I mentioned, each system will be able to work independently. The thermostat on each floor will be able to turn heat on/off regardless of any controller. The HA panel will basically provide much more control-- but if it fails, the house isn't going to freeze.

The rules you mentioned for lighting seem like the same type of things I would be looking to do. Not only would it control some simple lighting, but it would also provide an interface for a software-based front end.

On the temperature side, for instance, I would want the panel to realize it's 6am, it's 40 degrees outside, and the bathroom floor is 68 degrees, lets turn on the circulator and bring that temp up to 80 degrees.

As we all know, the possibilities are endless. Once you get hooked, everything ends up connected to your HA system Some functionality would inevitably end up in a software-based system. It's hard to predict.

But back to the point, as Spanky pointed out, option #2 with theLM35 directly hooked up is probably not the easiest solution. Budget-wise, this leaves me with option 3, or, previously omitted option 4-- using the lm35 and a a/d converter such as is illustrated in the other forum. With the impending native 1-wire suport for elk, I am thinking the 1-wire sensors and a temp08 would be the way to go for now. THe other point being that you can daisy-chain 1-wire sensors rather than homerunning. A little bit of an advantage if the HA panel is in the basement and you have multiple sensors on the second floor (well, until you put a drywall screw through your wiring ).

Tim

 

[Guy Lavoie]

As John said, the Elk must be considered as an alarm system first, with interesting home automation capabilities as a nice extra. The limited logic processing capabilities and rule memory won't make for a very sophisticated HA controller. I use the ADI Ocelot for detailed logic programming and IR.

Using LM34 or LM35 on analog Elk inputs can be done but poses a few problems: There is a 2k pullup resistor that cannot be disabled through software or jumper settings. The only way to get rid of it is by unsoldering this surface mount part. If you're going to do this at all, do it on an input expander instead of the main board to limit any risk to a less costly board. The other problem is that analog Elk inputs have 8 bit resolution over 14 volts. That's 54 mV per step. With a LM34, you will get a 5.4 degree resolution (ugh!). The op amp idea mentioned earlier could overcome this part of the problem.

My intent with figuring out the temp sensor's serial protocol was to eventually make a microcontroller project (8051) that could send any 8 bit value to the Elk using a simple input zone, whether it comes from a humidity, light, temperature, etc sensor. Having 16 potential "serial" inputs is quite attractive!

 

[fleetz]

Your option 2 must be calibrated to display the correct temperature which could be a problem.

Your option 3 for the iButton temperature sensors is in development.

Hi Spanky,

Are you able to confirm if humidity sensors are part of the sensors in development?

Are you able to give us an insight into the form factor they will likely to come through to the market in. The existing TZS are very basic in appearance and not something that compliments a new house.

I asked the question probably 3-4 months ago where you let us know these were in development but you were not able to give an expect release date. Are you in a better postion to give us an indicative time?

There seems to be a lot of people including myself heading down finding a solution for the M1G for temperature and humidity, it would be nice to have a time window.

Appreciate your feedback.

Thanks and regards,

Fleetz

 

[Mr.Tim]

Following up..

Point well taken regarding the Elk being a security panel with some nice HA features.

As I do not need any relays (other than switches etc which would be via powerline interface) at this time, I have decided to go with a Midon temp08 which will be monitored via software (leaning towards MainLobby at this time).

I am going to get everything in place and then re-evaluate what panel would best suit my needs.

On another note, I am trying to find some decent looking housings for the DS temperature sensors. Think I found a nice surface mount enclosure-- more to come once the sample arrives.

Tim