Wireless Powerflash?

[lewiswharf]

Is it possible to make a Powerflash wireless? Or, is there a product that is similar for wireless use? I'm trying to put a pressure sensor in another part of the House which is not wired to my apartment making it impossible to send an x10 signal.

Any ideas...

[jlipsit]

You could open up a X-10 wireless keyfob and wire 2 wires to the switch contacts. Then connect these two wires to the mat contacts. You woould have to have the wireless X-10 receiver. How far is the area from your X-10 wireless receiver to the mat location? I have a few spare keyfobs. Let me know if you want me to wire one up and send it to you.

[Nathan]

Another approach is to use the Hawkeye Motion sensor. This works well if you need the motion sensor in an area, but do not need the light (dark?) sensor. Simply open it up and remove the light dependent resistor, and replace it with your contacts. I use several of these. e.g. In my garage I have a wireless combination motion sensor and garage door sensor, with contacts on the door telling me when it is opened.



Cheers,
Nathan

[VincentB]

Nathan - did you just say that you replaced the hawkeye's light dependant resistor with a set of contacts, and you have a wireless powerflash? excellent! i haven't tried that, and have annoyed my distributors several times about asking the manufactuers to make a wireless powerflash... connecting to the light-dependant-resistor's contacts sounds perfect!

i will be giving that a try soon, as i'm sick of trying to neatly hide powerflash modules.

[Nathan]

Actually, since a Hawkeye has two addresses associated with it, you can get a two input powerflash, well sort of. replacing the motion sensor with a pair of contacts is a little more tricky, but it can be done.

But I find that using it as a dry contact sensor and motion sensor combined to be quite useful. The only drawback is that it's only as reliable as a wireless X10 device is. Not very, in other words. I am planning on replacing my garage door sensor with a Secu16 input soon as I get a round tuit, because HAL misses the GD being opened and closed too often.

Cheers,
Nathan

[VincentB]

hmm.. how is it that wireless X10 seems to cause you so many problems? i hardly ever get signals lost... occasionally i'll walk into my ensuite and the light won't turn on - which ticks me off - but 10 seconds later when the sensor triggers again, it works. but it's not a common occurance. from past comments, it seems that you have alot of X10 wireless signals lost.. have you ever tried to do any measurements? are other neighbor's X10 intefering, or other devices that transmit at that frequency?


BY the way, does UPB have any wireless transmission stuff?

[lewiswharf]

[quote:028b142b88=\"jlipsit\"]You could open up a X-10 wireless keyfob and wire 2 wires to the switch contacts. Then connect these two wires to the mat contacts. You woould have to have the wireless X-10 receiver. How far is the area from your X-10 wireless receiver to the mat location? I have a few spare keyfobs. Let me know if you want me to wire one up and send it to you.[/quote:028b142b88]
Thanks all. I'm going to investigate this option. I've searched this site and the web and I'm a little confused what a \"keyfob\" is... I feel like I'm retarded. Jim, I sent you an e-mail.

[VincentB]

Lewis,

a keyfob is simply a mini transmitter... you know, like when you have a car alarm: the keyfob is the transmitter that hangs off your keys to control the alarm. There are X10 keyfobs, that simply transmits a pre-configured X10 address as a radio signal.. you also need an X10 transceiver, that converts the RF signal to an X10 signal, to send it through the mains.

Take note though, that Nathan's hawkeye idea seems to be a better solution than Jim's keyfob idea...

Reason why:

1) Accidental Programming Mode
Some X10 keyfobs are programmed by holding a button down for a period of seconds. Here's an example of the problem:
Let's say you find a keyfob which has a button that when pressed, it tramsits the X10 address B4. Now let's say you open the keyfob up and connect a pair of wires to the button and join the other end of the wires to a reed-switch. Then the reed switch is connected to a door. Now when the door is opened, the reed switch shorts out the button, effectively pressing the button. HOWEVER - if the keyfob is designed to be programmed by holding down the button for 5 seconds, then it doesn't actually send the signal until the button is released. If the door is kept open for more than 5 seconds, the keyfob enter 'program' mode, and will now not transmit an X10 signal, even if the door is closed. The reed switch would have to somehow only press the button for a moment, in order to achieve the right procedure.


2) Transmitting 'Off'
With the above example, let's say the keyfob is not programmed via holding down a button.. there's a still a problem of sending an 'off' signal. When the door is opened, let's presume that the pressing of the keyfob button does transmit an X10 signal - let's say 'B4, BON'... now when the door is closed, all that's doing is releasing the keyfob button. But we want 'B4, BOFF' to be transmitted! A different button on the keyfob would be required, but the 'common' wire of the reed switch would need to connect to the 2nd button also, and you may end up shorting out something on the keyfob by connecting a pin from both buttons together.


Nathan's idea of using a hawkeye gets around both of theese problems. The light dependant resistor on the motion sensor is designed to transmit 1 X10 signal when it shorts out, and another X10 signal when it's unshorted. Replacing the light dependant resistor with a reed switch would thus work as required.

Now, after having said all that, don't let me scare you away from Jim's proposal of using a keyfob. If Jim says he can wire it, then it probably means that he's already successfully made a keyfob work as a wireless powerflash module.. though I'm unfamiliar with an X10 keyfob model that could work in the fashion I've described, so I'd appreciate his comment to explain how it works. Also, a keyfob is smaller than a motion sensor, and if you didn't want the \"motion\" feature at all, the keyfob would be a more feasable solution. But I'd like to know how it gets around the 2 problems I've elaborated.

[Nathan]

There are older keyfobs that are not programmable, simply set with an address switch. They would not be subject to the 5 sec issue you describe. But you're right in that the newer keyfobs would indeed be susceptible to going into programming mode unexpectedly.

Plus, the hawkeye sends different messages for Open and close, whereas the keyfob only sends one message on close. This is an important distinction.

As to the reliability of wireless X10, it's not wireless X10 that is the culpret, so much as it is X10 itself. The V572 receiver makes wireless as reliable as it can get, but cannot address the design mistakes that were made in X10 itself.

Your issue of the light not coming on sometimes when you walk into the ensuite is exactly what I mean. If the signal is lost, it's lost. The Hawkeye motion sensors flood the line with repeat signals every few seconds, so a missed one is not a big issue. Like streetcars, another will be alone in a moment. But when using the LDR as a connecting point for a contact closure, you only get ONE signal for each closure/open event. Miss one and your software is out of sync with the hardware. That's why I advise wiring to a Secu if possible instead of using powerflash, hawkeye or other unreliable methods. But we cannot always do that, unfortunately.

This is the problem I have with the garage door is that about one in 15 times it will miss the door being opened or closed. Since there are multiple decisions HAL makes based on the door state (i.e Will not go into away mode if the GD is open), having the door state at variance with HAL's state is a serious issue. Hence my plan to rewire it into a Secu16 soon as I get time. I've got the Secu already in place for it, just need to find some time.

For one example, if the door opens, closes within a couple of minutes, followed by the car sensor at the front gate within another couple of minutes, HAL knows my car has left, and goes into away mode. But if the door closure is missed, then he instead assumes guests have arrived when the gate sensor trips and the door is \"open\".

X10 is what is known as an inherently unreliable protocol. It is \"state-dependent\" and without any form of acknowledgement or error correction. So a single missed frame leads inherently to all sorts of errors. No transmission medium is perfect, and powerlines as a data transmission media are particularly poor. Data frames are guaranteed to be lost. It's simply a miserably poor excuse for a protocol that has greatly outlived it's design goals. It's time it was buried.

Cheers,
Nathan

[VincentB]

heya Nath,

yeah i hear you... i too have some rules that are based upon a sequence of events triggering, and if 1 X10 signal is lost, then the whole thing is out of whack... and it scares me to think that i am building a business to compete against the big guys, when i'm going in with X10 and all my competition (for where i am) resort to CAT5 type home automation. Boasting that X10 is much cheaper and requires no wiring doesn't work too well when I should be accompaning that with \"oh, and it's only 80% reliable\".

Though in Australia, there is a relatively new range of X10 out that is called A10, and the devices are much more sensitive to x10 signals (can detect down to a couple of millivolts, making them more tolerable to noise-interference)... but my house is decked out in X10, so i'll have to wait until a colleague is ready to deck his house out (in 1 month) before i can see how much more reliable A10 is. UPB is not an option for us yet.

Yes it is sad that HAL has so much power - a PC driven home automation system that can handle the most complex of rules and macros - yet it's bottleneck of performance is due to an old communication protocol. put's us in a tight spot, ey?

Once mediocre solution i did was to put 2 motion sensors in spots that are important for me to know of movement.. the motion sensors are positioned so they won't trigger simultaneously, but will send the same X10 signal.. so incase 1 fails, hopefully the other gets through (which it always seems to). But Nath - since your problem is a cotact-closure, i guess your problem is more difficult to solve... SECU16 is the contingency solution, but i hate running wires around my place.

eg: i just finished running a 15m VGA cable and a 15m PS2 cable, to mount my touch screen monitor in a different room to HAL.. after connecting everything up, i realised i bought the wrong cable! (can't be how stupid....) - i required a USB for touch-support, not a PS2.. and no 15m USB cables exist (due to synch-timing problems with long USB cables)... USB repeaters exist, but i'm going to go the wireless solution: a VGA/USB/PS2 transmitter-receiver pair... expensive but saves me the restrictions and hassle of wiring.

[Nathan]

The problem with using multiple motion sensors to cover a single space is the greatly increased liklihood of collisions and problems caused by them. The good thing is that the V572 deals with this pretty well, blocking damaged frames from getting to the powerline.

But the Hawkeyes flood the line with signals. The exact rate varies somewhat with individual models, a couple that I have will send a X10 ON every 5 seconds in the presence of motion. Placing two of these in a space will really bang out the signals. HAL will crash if he gets too many X10 signals too fast. So you can see how this might be a problem.

I wish someone would build us a nice wireless (non-X10) motion sensor that really works. Hmm. Want to start a business???

Good luck,

Nathan

[VincentB]

I use a V572 also, but isn't there another device that is like a V572 but also plugs into the serial port for direct communication also? I forget the model number, but i don't think HAL supports it. It can be set to send an X10 signal directly to the serial port, instead of through the mains. I presume it can be configured so that a housecode only goes through the serial, so that motion sensors wouldn't tie up the mains.. that would be fabulous.. but as i said, i don't think HAL supports it.

[Greg from HAL Support]

It is the WGL W800, and as you stated we do not current support it. While it is our intentions to support it will not be available in the immediate future.

Tech Support
Greg

[fitzpatri8]

What code does the 800 come with? It seems like a simple enough task to write a program that would recognize an X10 event and, based on criteria like frequency and current state, flip a Hal flag.

[Nathan]

I have thought quite a bit about doing exactly that usine Perl. It would be pretty trivial to write a Perl module that sat in memory and monitored the serial port, parsed the incoming signals and passed appropriate signals to HAL.

The major limitation is the interface to HAL, which until HALi, had to be a kludge using Jim's HAL_Interface program. The drawback is that HAL_Interface is *very* slow. So you would be guaranteed to miss events. You couldn't handle more than one event every 10-15 seconds or so.

You will notice that in my V572 control script I went to great lengths to avoid setting HAL flags unnecessarily for exactly this reason. There I was tracking the state of up to 32 flags, and if all of them were set in one loop, it would require several minutes to do so.

Hopefully HALi will be faster and such a tool will be practical. When I get my HALi working I will test it. If HALi is fast enough to process a flag in, say, one second, it will be practical to use a W800 in this capacity. I am hopeful that my HALi might be working real soon now, in case anyone who has been watching my HALi saga is reading this ;)

Cheers,
Nathan

[HAL_MAN]

Just a side note:
There are many wireless motion sensors theat do not rely on (X10). They are tied to the security system such as Honeywell Vista or GE Networx systems.
Both of which are compatable with at least some versions of HAL. Now if you already have a security system this would not be a good option but for any new installs this is definitly the way to go. Most of these wireless sensors have a 10 year battery life. And they are nearly 100% accurate and fast.
Thanks,
Shawn

[VincentB]

Heya Nath,

My HALi app works in that when an sensor-changed event is received by HALi, my applicaiton looks up its own database to see what light to turn on and then calls the device-on function in HALi. I believe its working It fast enough... and I'd be happy to write you a simple app that detects a sensor and turns on a light, in response - if you want to go to the trouble of parsing the data from the serial port (I haven't got time to experiment with that at the moment, and i dont have WGL8000).

[jlipsit]

The major limitation is the interface to HAL, which until HALi, had to be a kludge using Jim's HAL_Interface program. The drawback is that HAL_Interface is *very* slow. So you would be guaranteed to miss events. You couldn't handle more than one event every 10-15 seconds or so.

HAL_Interface is not slow. It will start, change the state of a flag, and exit in less than a second. HALi takes about about 2 seconds just to initilize.

You must have some funky database issues that are causing the slow down.

[lewiswharf]

[quote]The major limitation is the interface to HAL, which until HALi, had to be a kludge using Jim's HAL_Interface program. The drawback is that HAL_Interface is *very* slow. So you would be guaranteed to miss events. You couldn't handle more than one event every 10-15 seconds or so.

HAL_Interface is not slow. It will start, change the state of a flag, and exit in less than a second. HALi takes about about 2 seconds just to initilize.

You must have some funky database issues that are causing the slow down.[/quote:b985afb006]
I must agree with Jim. I find HAL_Interface to be very fast.

[Greg from HAL Support]

[quote:85a91a0865=\"HAL_MAN\"]There are many wireless motion sensors that do not rely on (X10). They are tied to the security system such as Honeywell Vista or GE Networx systems. Both of which are compatable with at least some versions of HAL. [/quote:85a91a0865]

Just to clarify what is supported with what, HAL2000 supports:
NAPCO Gemini 9600, the Apex Destiny 6100, the Ademco Vista
128BP and 250BP, the HAI Omni (II), OmniPro (II), LT; the HSP's Aegis;
and the OnQ's/HMS 800, 925, and 1050.

HALpro (available only to dealer from us, and only to end users through dealers) supports the above plus the the GE/Caddx NetworX/Interlogix NX-8e (integrated RS-232), or the NX-4, NX-6 or Nx-8 with the NX-584 (NX4, NX6, NX-8 require the NX 584 add in card for RS-232 communication).

Tech Support
Greg

[Nathan]

[quote:05efe61ffc=\"jlipsit\"][quote]The major limitation is the interface to HAL, which until HALi, had to be a kludge using Jim's HAL_Interface program. The drawback is that HAL_Interface is *very* slow. So you would be guaranteed to miss events. You couldn't handle more than one event every 10-15 seconds or so.

HAL_Interface is not slow. It will start, change the state of a flag, and exit in less than a second. HALi takes about about 2 seconds just to initilize.

You must have some funky database issues that are causing the slow down.[/quote:05efe61ffc]
I must agree with Jim. I find HAL_Interface to be very fast.[/quote:05efe61ffc]

I take it back, HAL_Interface is not slow, but HAL is.

I set up a quickie benchmark test. and measured the time it takes to set a flag using HAL_Interface on my machine. It takes approximately 1.44 seconds. I assumed a big chunk of that must be in startup/shutdown and the timestamping process, so I changed the test so that it changed the same variable, toggling between true and false 10 times. That took 15.12 seconds, which given the margin of error, is essentially the same. I actually repeated the 10x test several times and that was the best reading.

So if your machine is much faster, then true it is likely under one second. But X10 events can come in at the rate of several a second. It would be tough to pass them to HAL in real-time from an external program.

HALi may be faster or slower, I do not know yet. But if it takes 2 seconds to initialize, that means it is unacceptably slow unless the program is able to initialize only once and then stay in memory. THat might work well for a serial port X10 monitor, but will not work for many of the simple tools and utilities we have been using and discussing.

I think the issues are simply that I have a relatively slow machine, and a huge database. I know that when I perform other tests with a much smaller database the process goes much faster. In fact I have previously ovserved that the slowdown is not very linear, i.e. doubling the database slows things down much more than 2x.

As to database issues, I don't think so, because I have rebuilt the database, indeed the whole machine many many times. I have even tested on other machines. The results are pretty consistent.

My \"George\" is a 1 GHz celeron. I have also tested on a 1 GHz Pentium III and it is roughly almost twice as fast as the Celeron, although the clock speed is nominally the same. Older, slower Celerons are not really very efficient, even if they are cheap and low power. I would not build another machine using one.

I am planning a major upgrade to \"George\" soon. I am still searching for the right platform. I wanted to do something based on one of the newer media hub PC's coming on the market, but the ones I liked do not have PCI slots, thus cannot accept the modem. I was hoping that AL would come out with a USB modem soon.......

The other path I am loking at is to rebuild \"George\" much as he is, except with a new Pentium M with the latest \"Sonoma\" 915 Express set. It looks like that makes for a *very* fast PC that can still be low power and quiet.

But....

I really must touch on one of my age-old complaints/issues once more in this context. Home Automation (not counting Speech Recognition) is not, or should not be very demanding on a PC platform. For example, the Ocelot runs many times faster than HAL when executing identical logic, even though it's processor is a teeny peanut whistle by comparison. Simply running a ladder-logic process and responding to triggers simply does not require that much CPU.

By any standard, even a lowly 1 GHz Celeron is a pretty powerful CPU. A state of the art Pentium 4 might be 10x the speed, but 1/10th of a fast machine is still pretty good. I have worked on mainframes that wern't as fast. So I keep coming back to the core question.

What in the heck is HAL *doing* with all those CPU cycles? Why does HAL need a blazing fast CPU to respond to triggers in any reasonable timeframe?

Oh well, I guess that won't change soon. So I will throw CPU at it, or just live with it.

Cheers,
Nathan

[Nathan]

What in the heck is HAL *doing* with all those CPU cycles? Why does HAL need a blazing fast CPU to respond to triggers in any reasonable timeframe?

Oh well, I guess that won't change soon. So I will throw CPU at it, or just live with it.

Cheers,
Nathan