In the last tutorial post we covered the basics of gadgets and circuits. The circuits were very simple.
We will now start incorporating more communications between gadgets to get additional work done. We will stick with the most basic gadgets, and add in more as we go.
You may be thinking – why can’t we get right into serial input, driving relays, working with jeenodes etc?
Well, the answer is, we will – soon!. However doing things slowly (covering the basics) will help provide an appreciation for what is (and is not) provided in the basic back-end part of HouseMon.
Our last tutorial was
clock2.yaml (or circuit 3 if you keep track that way), we will start with circuit 4.
Change to your
(As we now have windows users following, I’ll not include the o/s specific commands unless they really help. I would however state that if you are a windows user, then please do these tutorials from ‘within’ powershell and I use unix fwd slashes as powershell is very unix-like!!)
Here is the powershell startup (for windows users only) one last time:
> powershell PS >cd $env:userprofile/housemon PS >./cirget status
Lets get circuit 4 (all o/s’s):
$ ./cirget circuit 4 $ ./cirget -y
OK, circuit 4 puts us all the way back to the beginning circuit (almost).
We have the obligatory ‘dummy’ (pipe) handling our main .In and .Out pins (doing nothing!), but we have added back in a new gadget called
ReadFileText, aliased as ‘rft’. This gadget takes a filename, which we supply vai a .Feed to the gadgets .In pin. We will give it ‘setup.json’ as we know that is present.
feeds: - data: "setup.json" to: "rft.In"
ReadFileText is a line orientated text file reader. It reads each line within the file supplied, and emits a message containing each line of text within the file. A line is considered as such if it is terminated with a
Take a quick moment to think about this circuit. What would you expect the output (if any) to be?
Within this circuit, the ‘setup.json’ file is read as fast as possible, and each message is emitted in turn, the messages are ‘lost’ because we have nothing else in the circuit that is able to process them.
When a ‘EOF’ is found by the ‘ReadFileText’ gadget, the messages will stop.
Consider!, what happens if the file is of infinite length, and ‘EOF’ is never reached. This is not possible with a file based upon a filesystem as technically reads are always faster than writes, so you’ll race to the end of the file faster that you can write into it, however, there are other constructs like streams (maybe based upon network data) that you can envision this for. Of course, a serial device (like a jeenode) will also behave like a never ending file – we will see more of that soon, for now lets continue with our basic ‘ReadFileText’.
Can we do something more interesting with a ‘ReadFileText’?.
Check back in the next tutorial.