JeeNode/HAHnode Digital Inputs

7 replies [Last post]
kevin9
Offline
Lincolnshire, United Kingdom
Joined: 24 May 2010

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

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Well you could repurpose the

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

kevin9
Offline
Lincolnshire, United Kingdom
Joined: 24 May 2010
Is what I am asking for

Is what I am asking for a new Jeenode/HAHnode sketch, an JeenodeApplet and a matching decoder then? HAHCentral would not change as it just passes on the OK ... data stream?

There may well be issues with the LUA docs, but it is more likely issues with my understanding what the docs say !

kevint

AlexS
Offline
United Kingdom
Joined: 5 Dec 2011
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.

brett
Offline
Providence, United States
Joined: 9 Jan 2010
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

kevin9
Offline
Lincolnshire, United Kingdom
Joined: 24 May 2010
Happy to see that

Happy to see  that it will be on the Roadmap somewhere..

And I understand that the circumstances around your change of location makes taking on significant changes more difficult.

Hopefully normality will begin to return soon

 

kevint

AlexS
Offline
United Kingdom
Joined: 5 Dec 2011
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

 

kevin9
Offline
Lincolnshire, United Kingdom
Joined: 24 May 2010
Added to the wiki

I have added the drawing above to the wiki topic about JeeNodes and HAHnodes

http://www.dbzoo.com/livebox/hah_hahnode#nodule_io_pins

kevint

Hardware Info