Premise Weeder Technologies Digital I/O Module

Motorola Premise

123

Senior Member
I've transferred many user-contributed drivers from the old Premise forum to Cocoontech and I've studied many of them. However, I never bothered to give the Weeder driver a good look until Dinki brought it to my attention. Unfortunately, it is written in the style used by other Home Automation programs and is not a proper Premise driver.

A proper Premise driver must be composed of objects from Premise's comprehensive framework. In other HA programs, you can model a digital input as a boolean value (TRUE=ON, FALSE=OFF) or, if you have a group of inputs, as an array of boolean values. You can model a temperature sensor as a numeric value. You could write a driver in this fashion within Premise but it would not be a proper driver because you can't bind to it.

In Premise, programming logic and drivers are two separate and independent layers. You can write and test logic without drivers. When you are satisfied the logic works correctly, you bind it to an appropriate driver.

In Premise, the existing DigitalInput class is used to model a real-world digital input. A collection of DigitalInput objects would represent a group of digital inputs. Premise's framework contains a slew of useful classes including DigitalOutput, Button, TemperatureSensor, HumiditySensor, Dimmer, Power, etc. A proper driver is composed of these core classes. If your Premise Home contains a Relay, Pump, or Fountain object, you can bind it to a driver that contains a DigitalOutput object. You can't bind it to a driver with a boolean value or an array of boolean values.

I'm helping Dinki develop a proper Weeder Technologies WTDIO-M driver. So far, I have written the basic framework of required objects: a single RS-232 port can support multiple WTDIO-M modules and each module supports 14 channels where each channel can be defined to be either a DigitalInput or a DigitalOutput object.

Now I need to do the real heavy-lifting, namely parsing the data communications. I have the documentation but I'll be flying blind because I don't have a WTDIO-M board to test. Dinki has agreed to debug the driver and I invite anyone else with a WTDIO-M module to participate in this collaborative venture.

You'll need to install DebugView on your Premise PC to see the debugging messages my driver will generate.

The attached images show the WTDIO-M driver's UI.
 

Attachments

  • WTDIO_M_Output.png
    WTDIO_M_Output.png
    13.7 KB · Views: 62
  • WTDIO_M_Input.png
    WTDIO_M_Input.png
    12.9 KB · Views: 42
  • WTDIO_M_Module.png
    WTDIO_M_Module.png
    11.8 KB · Views: 37
Thanks for taking on this task. I hope to do some testing and reporting on it in the next few days.
 
I'm curious as to the intended purpose(s) for this device...
 
The attached zip archive contains the first beta version (WeederTech9.xdo). It should be able to set a channel as an Output and set its state (High/Low). This verson will not process channels that are set as inputs. Everything this driver receives from the WTDIO-M is echoed to the debug console. I need the tester (that's you, Dinki) to post the debug log here so I can analyze the WTDIO-M's communications protocol.

Installation
  1. Set the WTDIO-M's module address to "A" (i.e. onboard DIP switches).
  2. Connect the WTDIO-M module to your PC's serial port (i.e. COM1).
  3. Start DebugView.
  4. Extract the XDO file from the attached zip archive.
  5. Using Premise Builder, import the XDO file.
  6. Click Devices in the Shortcut Bar.
  7. Right-click CustomDevices and select New > WTNet.
  8. Set the Network property to your serial port (COM1).
  9. Right-click WTNet and select New > WTDIO-M.
  10. Set the ModuleID property to "A".
Here's the minimum testing required to generate a usable debug log. Feel free to experiment with the driver and the WTDIO-M's channels in order to generate more data.

Testing
  1. Click Channel_A.
  2. Click the Type property and then click its Browse button (...).
  3. Navigate to Modules > WeederTech > Classes > Output and click Select.
  4. Click the State property to activate it.
  5. Click the State property again to deactivate it.
  6. Momentarily short Channel_B, on the WTDIO-M module, to ground to activate it.
  7. Click Channel_A.
  8. Click the Type property and then click its Browse button (...).
  9. Navigate to Modules > WeederTech > Classes > Input and click Select.
DebugView will display the messages issued by the driver. In DebugView, click File > Save, give the log file a name, and post it here so I can have a look at it. If the driver halts and generates an onscreen error message (in Builder), make a note of it, and post it here.
 

Attachments

  • WeedTech9.zip
    6.1 KB · Views: 40
Here is the product information from Weeder's Website. Click on the "Digital I/O" tab on the left and then the "Digital I/O Module - WTDIO-M" device.

Digital I/O Module

  • 14 I/O channels; individually configured for input or output.
  • All inputs incorporate a pull-up resistor to 5-volts, simplifying hookup to switch contacts.
  • DIP switch addressable; stack up to 32 modules on the same port for 448 I/O points.
  • Outputs can sink/source up to 25 mA each.
  • Responds to button presses and switch transitions using automatic debounce and typematic repeat with adjustable delay.
  • Decodes 4x4 matrix keypad using auto-debounce and typematic repeat.
  • Turns on/off relays, triacs, switching transistors, etc.
  • One-shot pulse output with software programmable length of 10 to 655,350 µS.
  • Industry standard RS-232 interface. Meets all EIA/TIA-232E and V.28 specifications.
  • Wide power supply range (8 to 30 VDC).
  • Screw-terminal connectors used on all inputs and outputs.
  • Connects to the RS-232 serial port or USB adapter on a PC, laptop, or other host. Enables software programs to interact with the hardware of a mechanical world via 14 distinct digital-logic input/output channels. Uses include industrial automation, process control, alarm/security, home automation, remote data entry/retrieval, keypad access systems, etc. Easy to use command set minimizes learning curve but preserves a robust, feature rich, functional environment.
  • Ideal for quick set-up and run applications.

Here is the datasheet for the WTDIO-M.
 
I'm curious as to the intended purpose(s) for this device...

My goal is to tie it in with my preexisting alarm system wiring. I don't have the alarm motherboard but I do have all the door and window switch wires and they just so happen to drop into my media closet. I plan on using these as inputs and using an output to trigger a relay that sounds the horn located outside.
 
This looks very interesting to me and at ~$59, the price is right!

I take it you are planning on connecting all the normal alarm contacts, motion detectors and siren(s) to this device, then use logic diagrams (probably the easiest) or code in premise to emulate the old alarm motherboards functions?

What keypad(s) do you plan to use with this type of set up?

Is there also an ethernet based video server that would begin recording a particular zone when a sensor hooked to the weeder i/o card is triggered?

I'm not that familar with security systems, but I always thought it'd be neat to design one around Premise. Premise seems reliable enough to me. It could easily be set to email you of intrusion (easy to do in VBA), dial your cell phone number through skype (if the documentation is available) or text your phone.

I think I will give this driver a try once I'm done with my current Premise projects!

I'm curious as to the intended purpose(s) for this device...

My goal is to tie it in with my preexisting alarm system wiring. I don't have the alarm motherboard but I do have all the door and window switch wires and they just so happen to drop into my media closet. I plan on using these as inputs and using an output to trigger a relay that sounds the horn located outside.
 
Yes, the device is very reasonably priced. I do plan to code the alarm functionality unless I can find something already written. I'm not sure about the keypad but I'm thinking of just using an rf remote. Who would think that would be used to disarm an alarm?? ;) It's definitely not elegant, but it's a lot better than what I have now.

I've cobbled together a little program that I plan to use to IM various portions of Premise's log file (once I get it working) to me at work. It would be nice to know if the burglar alarm was tripped while away. I also saw a cool mod where someone tied an X10 door/window sensor to a smoke detector. I'd like to do that as well and have it alert me, heaven forbid, if smoke was detected in my home as well.
 
You could go with an RF based X10 remote (has dvd, tv, etc controls) I've been playing with lately, it includes the MR26A receiver and is ~$13. Then, you could also keep an extra in your car, about ~$6 for the remote by itself. Too bad it's not a credit card sized RF remote with numeric buttons.

Another sleeker option would be to use something like this:
http://cgi.ebay.com/KR22A-X10-4-Unit-Credi...93%3A1|294%3A50

And use the on/off keys as a keypad. By default it's coded for A1, A2, A3, dim, but you can change the house code easily. For example A1 Off->A4 On->A2 Off -> A3 On could be your code to disarm etc and the dimmer could clear the code. If you follow the post above, the same methods are applied to a build a generic keypad bound to an X10 remote. For the KR22A, it acts just like a HR12A so use this as the device in Premise.

http://www.cocoontech.com/forums/index.php?showtopic=13793

Yes, the device is very reasonably priced. I do plan to code the alarm functionality unless I can find something already written. I'm not sure about the keypad but I'm thinking of just using an rf remote. Who would think that would be used to disarm an alarm?? :( It's definitely not elegant, but it's a lot better than what I have now.

I've cobbled together a little program that I plan to use to IM various portions of Premise's log file (once I get it working) to me at work. It would be nice to know if the burglar alarm was tripped while away. I also saw a cool mod where someone tied an X10 door/window sensor to a smoke detector. I'd like to do that as well and have it alert me, heaven forbid, if smoke was detected in my home as well.
 
I just installed the module and am running into a problem right out of the gate. I've chose COM2 but the PortStatus never shows connected; it's just blank. Port Spy does not show any activity. I am able to communicate with the board using the old version of the Weedtech module using COM2. I'm not sure what the problem is.
 
Before we dive into the WeederTech's code, let's confirm that nothing else is connected to COM2 ... such as the old Weeder module. If you're positive that nothing else is occupying COM2, try COM1. If the Weedertech driver doesn't work with either port then the driver's code may be suspect.

Yup, there's a problem and I know the cause. The attached zip contains WeederTech_10.xdo and, although I don't have a WTDIO-M module, I've confirmed it will connect properly to a serial port.

You'll notice that, in this version, when you right-click WTNet, it'll offer "New > WTDIO-M" and "New > Command". WTNet inherits from "SerialDevice" and that class introduces the "Command" selection. I had tried to eliminate this selection but just ended up fouling the serial connection. Anyway, "Command" is not such a bad thing ... it lets you send a raw command string to the serial device.
 

Attachments

  • WeederTech_10.zip
    5.8 KB · Views: 27
This version is talking with the board. I'm doing this from my office so I won't be able to do any actual testing until I go home.
 
I have not tested using the exact method you stated above. Hopefully this will provide the same information:

Testing Channel_B as Output. Clicked State True (first three entries). Clicked State False (last three entries)

Code:
[1348] Send: <AHB>
[1348] Raw Packet: []
[1348] Module ID: [X]
[1348] Send: <ALB>
[1348] Raw Packet: []
[1348] Module ID: [X]

Here is what PortSpy shows for these events:

Code:
AHB
AHB
AHB
ALB
ALB
ALB
---

Testing Channel_A as Input. Opened door connected to Channel A(First two entries). Closed door connected to Channel_A(Last two entries).

Code:
[1348] Raw Packet: []
[1348] Module ID: [X]
[1348] Raw Packet: []
[1348] Module ID: [X]

Here is the output from PortSpy:
Code:
AAH
AAL


Let me know what's next. Thanks!
 
All of the empty 'Raw Packet' messages indicate something is wrong. None of the received data is being shown. An "X" ModuleID indicates the GetModuleID function couldn't parse the received data and defaults to returning a non-existent module identifier (valid IDs are A-N).

The cause is simple. I copied the OnChangeOnInit code from another module that receives data in binary mode and not text mode as required by the WTDIO-M! Bah!

The attached version operates in text mode. Erase the existing WeederTech module, import the new one, and repeat the tests.
 

Attachments

  • WeederTech_11.zip
    5.8 KB · Views: 31
Back
Top