Mac Home Automation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====W800=====
{{:supported_hardware:w800rf32a_purchase.jpg |}}
{{:supported_hardware:w800_plus-1.png?200 |}}
{{:supported_hardware:w800usbmed-1.jpg?200 |}}

The W800 receiver from [[http://www.wgldesigns.com/w800.html|WGl Designs]] is the most versitile receiver for X10 wireless signals. If you already have an investment in X10 wireless devices such as their excellent motion and contact closure devices or their remotes there is no reason to stop using them if you’re thinking of updating the rest of your infrastructure to ZWave or something else. The wireless X10 devices remain an excellent, reliable and less expensive option for remote controls, motion sensors and contact closure sensors. Indeed their battery life is generally significantly better than even the most recent and expensive ZWave sensors while continuing to be less expensive. There is no reason not to mix different protocols with XTension.

Note that this page is specifically geared towards the new W800 plugin included with XTension version 9.4.18 and later. There are differences to the support for the original plugin that has been included in the package since 2004 or so. Note that the original W800 plugin has also been ported to Catalina and newer OS versions and will remain as part of the standard XTension distribution going forward. If you are happily using the original plugins there is no longer any reason to perform a conversion to the new plugin. If you are starting a new interface please use the version 2.0 or newer W800 plugin.

====Availability and Alternatives====
As of September 2022 the wgl designs home page is offline. This may be a temporary condition or they may be gone now. These were the best receivers for X10 transmitters but I imagine the market was shrinking. As an alternative you can use the [[supported_hardware:rtl_433|Software Defined Radio]] plugin which can be set to the 310mhz frequency to pick them up. In my testing this works but not as reliably as the W800 was. It may be that by disabling all the plugins but the X10 receiver it would be better. Some experimentation may be necessary to get this working as well as the original devices.

====Serial VS USB====
The W800 comes in a Serial and a USB version. At this moment I recommend the Serial version as it has the most versatile options when connecting to XTension. You can connect directly via a USB/Serial adaptor, we recommend an FTDI based adaptor but others will work. You can also connect via a Wiznet or other ethernet or wifi to serial adaptor. We support both client and server mode for those connections in this new plugin. That allows you to place your received anywhere that it can get the best reception that you also have a network connection. See the portion on configuration below for more info on the various networking configurations possible. 

The USB version of the W800 appears to contain a standard FTDI adaptor chipset internally. As of this writing I am unsure if that is a standard interface, meaning that it will appear as a new serial port to XTension, or if it would require some special drivers to let us connect to it. I am awaiting a return email from WGL designs and will update this page when it arrives. If you already have a USB version please give it a try and let me know, If you are purchasing a new device I recommend the Serial version. 

The USB version, even if the drivers work perfectly, is limited to the maximum cable length for USB when connecting to your XTension server. You can always extend the coax to the antenna but the ability to put the physical device on a Wiznet or other networking to serial adaptor I believe offers more options for connections.

====Connecting To XTension Via Serial====
If your W800 is connected via a USB To Serial adaptor or via the USB versions built in FTDI chip you should select that adaptor from the port popup in the interface setup dialog. Just save and then enable the plugin instance to connect to the W800. If you have multiple W800’s connected via serial you will need to create multiple instances of the plugin in the interfaces window to support each one.  You can still link them together into a single address space by using the “assign multiple” button in the edit unit window for each unit you want to be able to be received across multiple interfaces. This is an excellent way to increase the range and reliability of your system. Whichever interface receives the signal first will trigger the unit.

====Connecting to XTension via Wiznet====
An ethernet to serial adaptor such as a [[https://www.sparkfun.com/products/9476|Wiznet]] card can be used to connect a W800 to XTension in Client or in Server mode. I have built a free Wiznet configuration utility for the Mac which is available here [[http://www.planetarygear.org/2012/06/wiznet-configurator-for-mac-v2.html|Wiznet Configurator]]

The serial settings on the adaptor device should be set to 4800 baud, 8 bit, no parity, 1 stop bit and no flow control.


===Wiznet in Server Mode===
This is the same method as was supported with the original plugin. The Wiznet should be configured into “Server” mode and TCP as the protocol. (Do not set the mode to “mixed” that will try to start a connection back if the incoming connection is lost. This will not work and will instead block XTension from reconnecting again) 

In XTension select “Remote IP Address” from the Port popup in the plugin configuration window and enter the IP address of the Wiznet card you wish to connect to. Your Wiznet card must be setup with a static IP or a reserved IP address on your network for this to work.

Once enabled the XTension interface will make an outgoing connection to the wiznet card. If you wish to have multiple W800’s connected this way it is necessary to create a separate plugin interface instance for each device. You can still link individual units to all the instances for better reliability by using the “assign multiple” button in the Unit Setup Dialog. 

===Wiznet in Client Mode===
Wiznet and most other ethernet to serial adaptors also have the ability to make an outgoing connection to the receiver program. This can be useful in a couple of ways, The wiznet does not require a static IP address so if you do not have access to the router this is the best way to go. In this case however the XTension machine that it’s connecting to must have a static or DHCP reserved address. If you’re XTension machine is across the internet it is not necessary to setup an incoming passthrough at the W800 side again if you don’t have access to the router settings for this it can simplify things. However a passthrough for the incoming port will be necessary at the receiver side.

When in client mode you can have any number of W800’s sending their data to a single instance of the W800 plugin. They can all be configured to connect on the same port as if they were a single device. No additional instances of the plugin interface are necessary and all W800’s being received will assume the same address space. This is great for extending the range and reliability of your network. No separate configuration for individual units via the “assign multiple” interfaces button is necessary.

In XTension select “Listen for Incoming Connections” from the popup port menu.

Serial configuration is the same as when in Server mode. In the Wiznet configurator or other tool set the connection type to Client and enter the IP or DNS name of the XTension machine. Additionally you must set the connection protocol to UDP. As soon as the wiznet reboots after sending the config changes and you enable the interface you will begin to receive events from the device.




====X10 Wireless Units====
Regular (non-security) units are received in the new plugin identically to the original plugin. If the automatically create units checkbox is turned on for the interface then with every reception or an address that does not exist in XTension the unit will be created. Regular wireless X10 units do not support a low battery indication though the 2AAA batts in my hawkeye motion sensors tend to last around 2 years before they need to be changed. 

The dusk sensors in the regular motion sensors are send as one address higher than the one you set. So if the device is configured for address B4 the dusk sensor will send on address B5. I find that setting the “Reverse Logic” flag for dusk sensors is most useful for me. I treat them not as dark sensors, but as light sensors. I feel the unit should be on when it’s light, not on when it’s dark, but thats just personal preference.


====X10 Security Units====
Security units are more complex. Since they set their own address based on how long you hold their button down after changing their batteries the Automatically Create Units checkbox can be more helpful for setting them up. Otherwise you’ll need to generate an event and then look in the log to see what address was received and then use that to manually create a unit to correspond to it.

Security units send a low battery flag. XTension will display a green battery icon for any security units which will turn red when they change their flag. They do not send a battery level however, they are either OK or low. Even when low most of mine will continue to work for several months.

Some security units also have a Tamper sensor in them. For example the newer Door/Window Sensor model DS12A has a spring loaded button inside that will send an alert if the unit is opened. The Tamper flag will be sent with any packets the device broadcasts until that condition is fixed. If an XTension unit receives the tamper flag it will set the Error indicator flag for the unit which will display in all displays and can also be trapped in the unit’s on script. Note that this behavior is different from the original plugin where you had to check for a tamper global with every execution of the on or off script. 

Security sensors, but not security remotes, will re-send their current state every hour or so. Even if there is an overlap or other interference that causes a state change to get lost, it will catch up later on. This is not useful for motion sensors but is very useful for door/window sensors that would otherwise get stuck in an incorrect state. This also means that you can use the “Show an alert if the unit has not had an update in” checkbox on the Advanced tab of the Edit Unit dialog to make sure the unit is checking in regularly. It is possible for batteries to go dead so fast once they start to drop that you may not receive the last battery check update, or that something else is interfering with the radio reception of that device. This is a good way to watch for that happening. It is not unusual for a single packet to get dropped once in a while and so I would not set the timeout on that alert to less than 2 hours, and probably 4.

====Security Remotes====
There are several security remote controls available that can be quite useful. There are 2 ways to trap the individual button press events for a security remote.

If “automatically create units” is turned on then when you press a button on your security remote the corresponding units will be created.  For example if you press the “Arm Home” button the unit addressed as “[housecode][unitcode].ARMHOME” will be created if necessary and then turned on. If you press the “Arm Away” button a unit addressed as “[housecode][unitcode].ARMAWAY” will be created if necessary and then turned on. If you press the Panic button a unit addressed as “[housecode][unitcode].PANIC” will be created if needed and turned on. 

Pressing the Disarm button turns off either of the Armed units and also the Panic unit if it is on.

Security remotes may also have other buttons such as “Lights ON” and “Lights OFF” If you press either of those a new unit with the address of “[housecode][unitcode].LIGHTS” will be created and turned on or off.

There are other security commands for which I’m not aware there even exist any devices anymore that can transmit them, but I have tried to support as best as possible. The commands for temperature high and temperature low will create TEMPHIGH and TEMPLOW units each of which will be turned off by any normal command on the same housecode. 

In addition to the specific button units that will be created you will also get a “root” level unit who’s address is just the standard housecode/unitcode of the device. That unit will turn on and off based on the existence of the alert or normal flag in the packet. This may be able to support future devices that are added without having to wait for the plugin to be specifically updated. This unit will also receive an event to it’s On script when the individual buttons are pushed that you may choose to trap there rather than by using the individual units above. The handlers that you can create in this units On script are:

<code>
on armaway()
  write log “the arm away button has been pushed”
end armaway

on armhome()
  write log “the arm home button has been pushed”
end armhome

on disarm()
  write log “the disarm button has been pushed”
end disarm

on lightson()
  write log “the lights on button has been pushed”
end lightson

on lightsoff()
  write log “the lights off button has been pushed”
end lightsoff

on panic()
  write log “the panic button has been pushed”
end panic

on temphigh()
  write log “the TEMP HIGH alert has been received”
end temphigh

on templow()
  write log “the TEMP LOW alert has been received”
end templow
</code>

It is not required that you handle any of those commands in this script, they are sent to that in case the commands are better handled for a specific device in this way than by sending to separate units.

====MP3 Remote====
The MP3 remote was a device X10 sold that you were supposed to use to control their PC software for things like media playing and such. It is still very useful. Each button on the remote has a different command code and can be used in XTension to do just about anything. When you first press an MP3 remote button a unit will be created with the address of “MP3”. You can only have a single MP3 remote on any given system as there is no addressing. They will all trigger the same scripts.

Since there are so many buttons no attempt is made by the plugin to create individual units for them, They are sent to a single handler in the On script of the above unit and you can do what you wish with them via scripting. I don’t have a table of all the codes and they may be different on different models of the remote so you should write the code number to the log to find out what it is for any given button on your remote. An example handler might be something like:

<code>
on mp3( buttonCode)
  write log “mp3 code: “ & buttonCode
  
  if buttonCode = “176” then
    write log “you pressed play!"
  else if buttonCode = “112” then
    write log “you pressed stop!"
  end if
</code>

Note that even though the code is a number it is sent to the script as a string. If you wish to compare numbers instead of strings you should first set newButtonCode to buttonCode as number or something similar. 


====History====
  * The original W800 plugin was added so long ago as to be just forever. The new plugin was added in XTension version 9.4.18 in May of 2019.
  * In sep of 2022 I noticed the wgldesigns page is offline and added the section on using the sdr radio plugin instead.
Mac Home Automation

User Tools

Site Tools

Page Tools
