JeeNode/HAHnode Digital Inputs
28 February, 2012 - 22:19
I have created a pic which shows the I/O allocation on a JeeNode or HAHnode for the different sketches supported by the Plugboard/LUA/JeenodeApplet.lua
RFM12B wireless at the bottom, FTDI at the top
(of course let me know if I have got the inputs wrong)
Would it be possible to include a new 'digin' type of input for the RoomNode2 sketch? As you can see port 3 digin is not used in either the RoomNode2 or RoomNodeTwin sketches and port 2 digin is also available in RoomNode2 only.
I would use this for things like magnetic door/window contacts, and perhaps a pushbutton or a water leak detection. It seems odd not to have generic digital input support.
I can see how the sketches link to the serial and then to the JeeNodeApplet but after that I get completely lost in the supporting LUA
If you think this is a good idea I can add it to googlecode as an enhamcement request
Thanks
kevint
29 February, 2012 - 14:44
#3
Maybe?
Maybe its time to move all the config out of the nodes and just send completely raw data without any assumptions?
Each node can report its config and revision as well
So it would look like (maybe)
jeenode=23
ver=1.1
Type=2
.
.
port/pin=4-7
Value=1=on
an output string becomes J23,N1.1,TP2......P0407=0001...
lua then converts that to XAP?
Maybe using a devices file
containing:
#Node - Port=Description;Type;I/O;States reported;hysterysis;Unit;BSC
J23-04D7=Lounge PIR;Digital;Input;0=Idle:1=Motion Detected;Seconds;1;livebox.hah.jeenode23-04D7
J23-02D5=Lounge Temp;Analogue;Input;-10:+80;Centigrade;2;livebox.hah.jeenode23-04D7
J23-03D6=Lounge Light control;Digital;Output;0=Off:1=On;on-Off;0;livebox.hah.jeenode23-03D6
so the only thing you need to define is Port range & data type in the node (to which you can add retrospectively, newer nodes support newer types).
Then older nodes will continue to work if you add a new type.
If you add a default option for each node type in the menu so you say new node=24 and type=twin(2) you can copy example xml files in.
In my experience the dumber satellite nodes are the better they scale.
29 February, 2012 - 15:08
#4
Alex, the nodes send raw data
Alex, the nodes send raw data without any assumptions, they are pretty dumb in terms of protocol, which I guess is part of the problem.
What they send is just a RAW stream of bytes that map to a struct() if you examine their source code you'll see what I mean but you still need a DECODER to understand what struct they are sending. As this is RF you really don't want to make a complex protocol like you would over say Serial or Ethernet. It should be as simple and as compact as possible.
Perhaps what I should have done was include a VERSION byte as the very first thing sent, this way the decoder can vary its decoding based upon different revisions of the transmitter. This would allow the AVR firmware on the nodes to vary and to have a decoder that can understand different variations of the same protocol. Sigh - these things are always noticed in hindsight. Its never easy to get it 100% and some design decisions are harder to change than others, unfortunately this just happens to fall into the later category.
A complete overhaul of the ENTIRE stack would be the go, but I'm not in a position to be able to do this at the moment, I will however make a note as an enhancement so its not forgotten if new nodes are created. It can be retrospectively added to the others later.
Brett
29 February, 2012 - 17:05
#6
hmm I see
Hi Brett
Yes I had a quick look, the alpha in the transmission was illustrative. was thinking that a version & type may give more flexibility? The type would allow you to change the struct and encoding so we could have a Arduino Mega Node if we ever get that sad. Or a yet to be imagined Node.
can we check the length of the raw stream, if its over a certain length its a version 3?
RF12.cpp
rf12_len + 5 || rxfill >= RF_MAX
Then in ver 3 we add type & version?
See the universal RF development is that the new standard RF rx to pair with the URFtx?
http://arduinoha.googlecode.com
So if we track down / create RF codes for that it will help?
Again you have done far more than me so don't apologise, I'm just trying to provide ideas not chase.
Alex
Well you could repurpose the existing PIR pin. Unless of course you want PIR and another input.
Here is the problem. If I upgrade the AVR C code and the Decoder to match, unless all those people who have the HAHNode deployed reflash EVERY node then there is a possibiliy that the decoder will not match the received datastream.
Consider what happens if you have version 1 of the AVR roomNode and then you upgrade the LUA decoder backend to version 2 things gets ugly.
This is the reason I created RoomNodeTwin instead of just upgrading the RoomNode2 and Decoder backend. Had I not done this if you did a HAH upgrade you'd get NEW decoders for OLD transmitters. Its a bit of a problem for sure as it requires that you get it RIGHT first time and never change it. So adding a new sensor pin would require a new Decoder and a New Transmitter sketch to avoid messing up existing installations.
The drawing is good that looks about right to me.
I did try to document the jeenode/LUA stuff pretty well but it is a little complex to get your head around. If you indicate what is not clear I can try to amend the documentation.
Brett