IOBridge+TeensyDuino+Serial Web Services+Php=Nothing I can't do!

[nick]

I have been using the IOBridge for almost a year now, and the thing that strikes me about it is that it's brilliant at what it does, but maddening in that if it doesn't do exactly what you need you're pretty much out of luck.

The logging is great -- unless you want to log something that's not supported, like digital state changes.  Notifications are great -- unless you want the action to be something other than email.  The API is great -- unless you want to do something it can't do, like push notification rather than pull.

I put together a setup that I'm very excited about, because it allows for almost endless flexibility.  Hardwarewise, it consists of an IOBridge, a serial smart board, and a TeensyDuino.  TeensyDuino is an Arduino implementation on a board called a Teensy that is a tiny-- 1.2 x 0.7 inches -- self-contained programmable microprocessor.   It has a USB port and connects directly to a computer for programming.  It has a serial port, and hooking it up to the IOBridge is a matter of connecting four wires -- power, ground, receive and transmit.  It's really easy.  The Teensy costs $18, the more powerful Teensy++ is $24. See http://www.pjrc.com/teensy/index.html (I have no affiliation with the company that makes the Teensy).

Programming the teensyduino is really easy too.  You write programs --arduino "sketches -- on your computer and download them using the USB port.  Other than a USB cable no hardware is required, and all of the software needed is downloadable for free from the teensy website.  The Arduino language is incredibly simple.

The teensy board has a lot of inputs and outputs -- 25 I/O pins, 12 analog in pins and 7 PWM analog out pins.  But it's using the serial port and the IOBridge serial API that really unlocks the power of the IOBridge.  The Serial API allows you to issue GET comamnds to a URL you specify.  With a server-side programming language you can accept data from the teensyduino, send data back, and also manipulate the IOBridge using the API to control smart boards or digital outputs, or send more data to the teensy using the serial API.

So basically I have the IOBridge in the middle and a programmable device at either end.  The IOBridge allows full bi-directional communications, which can be initiated from either end, and also gives a bunch of useful properties, like the X10 interface or the built-in logging, that can be used when they serve your purposes.


With a programmable device at each end I feel there's nothing I can't do!

Nick

[electroman]

Hi Nick,

I am interested in a similar versatile monitoring and control system to what you are describing.  I have a microcontroller attached to a serial board and am communicating with it using the real time serial monitor widget and the send serial message (variable) widget.  The microcontroller is programmed to have a number of possible actions, dependent on the serial message I send from the dashboard.

What advantage is there in using the Get command to a URL?

Thanks

electroman

[zero*gx]

using get and put commands, you are able to control the system from a different application. for example, you could create a shell or batch script to put the time on your iobridge screen. this would not be possible using a javascript widget.

[nick]

What advantage is there in using the Get command to a URL?

Two big advantages: first, you can trigger actions on your web server using Get, which can then trigger actions anywhere in your system.  It allows actions to be initiated at the IOBridge end of things.  Otherwise the only triggering you have is to send an email, and it's limited to a simple change of state on the digital in or a threshold on the analog in.

A simple example: let's say you want to turn a light on via X10 every time a contact closes and turn it off when it opens.  You program your teensy to send a Get message to your webserver when the input changes state.  You program the page on your web server to send a message to the IOBridge using the API to the X10 module.  Each of these programs is about five lines long.  This is something you can't do with just an IOBridge.

Second, you can get reliable communications.  The serial API is not reliable, bytes can be dropped, and there is no way of telling if that has happened.  Using Get and the Serial Web Services you can set up a simple protocol where your microprocessor sends messages to your server, and your server responds.  You can use the response to make sure the whole message was received, and resend it if it wasn't.

[jason]

Otherwise the only triggering you have is to send an email, and it's limited to a simple change of state on the digital in or a threshold on the analog in.

That may have been case when we first launched, but there have been a lot of additions since then.  Actions can trigger X10, servo, digital output commands.  They can also be used to link digital inputs to digital outputs and can be used to push serial data to devices.  Click on the "Actions" tab to see for yourself or read about the options in our wiki: http://www.iobridge.net/wiki/actions

Second, you can get reliable communications.  The serial API is not reliable, bytes can be dropped, and there is no way of telling if that has happened.

Do you mean the Data Feed API can drop bytes?  While the Data Feed API isn't the best way to get serial data (and yes, can drop bytes), the Serial API was designed specifically for serial type data and is very reliable.  Granted, the Serial API is more difficult to implement, but the data is buffered to keep every byte.  Now this isn't to say that you can't make the Serial API lose data.  If you flood the serial board with data, the serial board's internal buffer will fill up.  Once the buffer is full, it can't hold any more data.  But it will let you know when this happens via the RTS pin.    

[nick]

Do you mean the Data Feed API can drop bytes?  While the Data Feed API isn't the best way to get serial data (and yes, can drop bytes), the Serial API was designed specifically for serial type data and is very reliable.  Granted, the Serial API is more difficult to implement, but the data is buffered to keep every byte.  Now this isn't to say that you can't make the Serial API lose data.  If you flood the serial board with data, the serial board's internal buffer will fill up.  Once the buffer is full, it can't hold any more data.  But it will let you know when this happens via the RTS pin.    

 When talking about communications protocols, the word "reliable" has a very specific meaning: it means that a protocol has a way of detecting and correcting errors.  It's a description of the design of the protocol, not the quality of the implementation. TCP/IP is reliable.  RS232 is not reliable.  You can implement a reliable protocol on top of an unreliable protocol, but in order to do that you have to support bi-directional communications, so that the sender can receive confirmations and resend requests from the transmitter.  The IOBridge serial API is not reliable, because it's unidirectional, and part of the communication chain uses RS232, which is an unreliable protocol.  This is not a criticism of the implementation, it is a description of the design.

The serial web service is bi-directional.  With bi-directional communications it is possible to implement a reliable protocol.  That is exciting to me. Reliable protocols are good.

[electroman]

A simple example: let's say you want to turn a light on via X10 every time a contact closes and turn it off when it opens.  You program your teensy to send a Get message to your webserver when the input changes state.  You program the page on your web server to send a message to the IOBridge using the API to the X10 module.  Each of these programs is about five lines long.  This is something you can't do with just an IOBridge.

I guess you don't really need an iobridge at all for this.  Just a few lines of logic running  in a micro with input and output pins for monitoring and control.

I can see the advantage of some of the web service commands, for example the google calculator offers functions that are often hard to do on some micro's.  Data_log is a life-saver in the application I have in mind, but more specifically I am still wondering what  I can use the command  [[[get|url]]] for?   Is it just to read the contents of a web page which is presumably constanly changing/updating and allows me to use an external input that is remote from the iobridge? 

Thanks

Electroman

[nick]

I guess you don't really need an iobridge at all for this.  Just a few lines of logic running  in a micro with input and output pins for monitoring and control.

The work that IOBridge does to control the X10 is not trivial.  That alone is worth the price of admission.

I can see the advantage of some of the web service commands, for example the google calculator offers functions that are often hard to do on some micro's.  Data_log is a life-saver in the application I have in mind, but more specifically I am still wondering what  I can use the command  [[[get|url]]] for?   Is it just to read the contents of a web page which is presumably constanly changing/updating and allows me to use an external input that is remote from the iobridge? 

My whole point is that it's not a static URL, it can be java or php or some other server-side language, and then I can do virtually anything -- including calling anything that is callable from the IOBridge API, or calling another website.  Oh, and I can also send data back through the serial port to let the other end know that I got the message, and maybe prompt it to do something else.

[Scozza]

FWIW I love the iobridge & I love plugging other things into it.  I have to be honest though, sometimes I'll tack another product on just because I'm lazy or already have some code I can recycle.  I have no doubt either way I'm going to get what I want & expend some brain power in the process!  I'm constantly tacking arduinos, relays, sensors and other stuff onto my projects.  Keep up the good work!

Cheers,

Scozza.