Imaginative uses for DS10A sensors

[scanman717]

So here's the next logical question.. I know how to change the icons in the web control interface for an entire device type... But since I have DS10a's one in the AC, one on the Garage door, soon one on the BBQ How do I assign each on individually Icons and different status??

Oh,and BTW, I am stuck on HS 1.7 Not ready to jump to 2

 

[Rustytek]

How do you wire the cr magnet to ds10?

 

[deranged]

I just connected the CR magnetics device to the DS10, of course at first it didn't work. Then I swapped the wires around and it works perfectly.

No other hardware used....

I have since added 1 also the to the fan motor of the A/C unit. So I can tell how long the A/C unit is running and how often the Compressor is cycling.

StevenE

 

[raptor_demon]

Well i have the standard use for doors open etc...

Will be doing the following:

Deadbolt status using either a micro switch or magnet
Cat food level low (using an IR breakbeam to trigger a low food warning)
Cat water lever low (using a microswitch and a float).
Door bell via either electromagnet in the doorbell or optocoupled via relay.

Raptor

 

[BraveSirRobbin]

FYI: HERE is a pic from the HomeSeer site on using the DS10a sensor near the coil of the relay (at the bell location) for the doorbell. I also did this at my home and it works great. Took longer to find the step stool than it did to install the DS10a.

 

[roussell]

Cat food level low (using an IR breakbeam to trigger a low food warning)
Cat water lever low (using a microswitch and a float).

We just moved our cat's food and litter box into the garage - It's great EXCEPT when the cat is doing it's business in the litter box and we happen to be coming home. The clatter of the opening garage door leads to one scared kitty and some rather unpleasant clean-up duty. I need develop a litter box occupancy sensor and disable the garage door when ...well... you know...

The cat gets into the garage door through a kitty door in the wall of the laundry room and the litter box is one of those fully enclosed models. I'm not sure yet if I want to tie some logic to the kitty door or the litter box, but I'll be doing something, that's for sure. Maybe a cheap, small, stink-proof motion detector in the top of the litter box - something like a hawk-eye. I guess I need to dig up one of those x10.com sales links.

Terry

 

[jwilson56]

Actually I replaced all my DS10's with NX-650 for my Elk wireless. I love the lithium batteries as well as more dependable results for me. I have a detached garage and always had trouble with the DS10 in the winter. The NX-650 made it through two days of -14F weather this year and never had a bit of trouble.

 

[irkgreen]

Hey guys,

A little off-topic but I am trying to ID 6 sensors with a microcontroller (atmega168) wired up to a W800RF32. Right now I am trying to decide what bytes each device is sending. I started using the demo software that came with the w800 but it shows 4 bytes that aren't even close to the bytes I'm seeing. I plugged the w800 to a computer oscilloscope to verify. The bytes I see are not in the pattern defined by WGL (that is, one byte is open or closed, the second is the inverse, 3rd is the device code, 4th is the inverse). My bytes have no inverses. Granted, the 1st and 2nd seem to be consistent for each device and the 3rd and 4th indicate an open and close status. The problem is: they aren't consistent! Sometimes the message is off by a bit or two, other times i see an 0xFF! I am using an STK500 dev kit with a crystal osc so my error percentage should be very low. I think the problem is that I should be using 2 stop bits (as WGL suggested), but changing the setting has little to no effect. I am using an open source uart library for the atmega that seems to be tried and true. I don't know what else to try.

Any ideas?

 

[batwater]

Hey guys,

A little off-topic but I am trying to ID 6 sensors with a microcontroller (atmega168) wired up to a W800RF32. Right now I am trying to decide what bytes each device is sending. I started using the demo software that came with the w800 but it shows 4 bytes that aren't even close to the bytes I'm seeing. I plugged the w800 to a computer oscilloscope to verify. The bytes I see are not in the pattern defined by WGL (that is, one byte is open or closed, the second is the inverse, 3rd is the device code, 4th is the inverse). My bytes have no inverses. Granted, the 1st and 2nd seem to be consistent for each device and the 3rd and 4th indicate an open and close status. The problem is: they aren't consistent! Sometimes the message is off by a bit or two, other times i see an 0xFF! I am using an STK500 dev kit with a crystal osc so my error percentage should be very low. I think the problem is that I should be using 2 stop bits (as WGL suggested), but changing the setting has little to no effect. I am using an open source uart library for the atmega that seems to be tried and true. I don't know what else to try.

Any ideas?

See here for the protocol document for the w800. The demo software reorders the bits and bytes...
-Ben

 

[etc6849]

Here's another document that's pretty good: http://www.smarthus.info/support/download/x10_RF_formats.pdf

If the link ever dies, just google: "X10 rf codes" rfxcom

This document has great info on the X10 security protocol.

 

[irkgreen]

I hadn't seen the RF documents before. Only WGL's protocol, which doesn't match what I see. Even if they reordered the bits. None of my bits are the inverse of any of the others. Perhaps the DS10A's use an old standard.

Does the RF message mirror the serial message?

Regardless, I can't seem to get a consistent reading on my devices. I have 6 DS10's and I've coded the bytes seen for open on all of them and for closed. By and large, the address bytes seem to match whether open or closed; which is good. But very often I lose or gain a bit. Sometimes I see a 0xFF.

I am using 4800, 8, 1 and 2 stop bits (tried both).

It almost has to be the UART library. What code have others used to read these values? I wonder what the third party devs use.

 

[etc6849]

Did you go to page 4 of the PDF I linked above? The "Rec." column should match exactly what you see for the command/status byte on the port if you are using a port spy program or realterm or equivalent. Byte 1 is the address byte. Byte 2 is the complement of Byte 1. Byte 3 is the command/status byte. Byte 4 is the complement of Byte 3.

 

[irkgreen]

That sounds like what the demo app is showing, but I do NOT see the same protocol as evidence by plugging my W800RF32 up to my scope or to my AVR. My scope and AVR both show 4 bytes (actually a few DS10A's only send 3 bytes; which is really odd). And none of the bytes are compliments (which means no error checking). Tonight I will try plugging it up to hyperterminal but I suspect my results will be the same. It is hard to argue with the scope's data.

I may try to post screen shots of my scope output.

I don't really need to know the method behind the madness as long as I can tell the address and open and closed status. So far I can do that, but the results aren't consistent enough to reply on.

 

[etc6849]

Here's some raw data from my DS10A on the W800RF32A's port:
7B 74 85 7A
7B 74 85 7A
7B 74 85 7A
7B 74 85 7A
7B 74 85 7A

It shows up as raw data in windows and my home automation program treats it as raw data. It works 100% of the time.

The driver I wrote only looks at 7B and 85.

Convert 7B to binary: 01111011

Convert 85 to binary: 10000101

Note normal is 84: 10000100; so you see the least significant bit is the low battery indicator.
Note with the extended delay switch set you'd see: 10000000 if the battery was not low or 10000001 if it was low.

This means the third bit from the left is always zero if ext delay is turn on (micro switch under cover) or 1 if it's not.

7B is the address for the DS10A. 85 is the status byte. If you look in the pdf file, 85 means normal with low battery.

The output is always consistent for me. However, you need to check for the battery low bit and the ext delay bit and mask those out.

 

[irkgreen]

I hooked up my w800 to realterm (like hyperterminal but shows hex). The demo software bytes are clearly converted. My data is very similar to yours. For all of my devices (6 of them, A-F)

A
Closed: 050A847B
Open: 050A04FB
B
Closed: 8F80847B
Open: 8F8004FB
C:
Closed: 919E847B
Open: 919E04FB
D
Closed: 838C847B
Open: 838C04FB
E
Closed: C5CA847BC
Open: C5CA04FB
F
Closed: 8B84847B
Open: 8B8404FB

The closed message is clearly 847B and open is 04FB. As you say, those would change with low battery or extended delay (thanks for telling me that actually). The other bytes are the address. Of course, none of these are inverses (which is a shame).

My problem is that when I connect to my AVR, I cannot get these consistently. But I can connect another serial device and get very consistent results. For instance, I sent ABCDABCDABCDABCDABCD in ascii to my AVR via a serial board connected to an ioBridge. Each letter is displayed, consistently.

I'm at a loss.