HAHNode data format

16 replies [Last post]
andy_godber
Offline
Joined: 13 Sep 2011

Finally got 'round to soldering up the HAHnodes.

Connected up to the Arduino IDE, and data coming though, so looks ok before I connect up to the HAH.

Seems to be lots of data (more than HAH processes) ? Please can you point me to the schema which explains what each value is? Also, seem to be some 'short' records? 

 

[RF12nocfg.1] A i1 g212 @ 868 MHz 

 

Current basenode configuration:

 A i1 g212 @ 868 MHz 

 ? 54 239 45 22 21 232 190 125 192 122 75 173 250 189 82 168 249 62 90 224 188

 ? 12 125 193 0 144 150 130 169 188 131 238 9 208 7 17 11 231 173 233 6 215

 ? 7 14 214 98 57 17 197 68 146 203 16 162 128 113 93 151 107 19 220 168 120

 ? 128 254 97 65 67 62 11 48 1 70 53 113 174 130 155 215 134 131 68 101 22

 ? 61 176 94 217 166 185 245 66 97 161 190 137 4 252 50 7 85 94 133 135 4

 ? 20 248 6 126 18 236 92 79 192 136 127 121 0 31 186 96 154 116 227 110 43

 ? 35 185 162 233 25 40 240 244 195 134 88 127 233 146 17 45 57 54 202 157 198

 ? 25 14 230 24 25 146 91 213 6 245 26 52 115 132 61 1 13 241 195 42 173

 ? 178 83 172 17 248 193 30 227 4 46 8 74 161 223 157 160 212 37 95 83 129

 ? 20 241 151 170 194 45 177 21 90 52 176 155 147 227 192 235 253 145 45 70 152

 ? 225 98 117 211 125 244 120 23 172 180 194 31 118 94 31 136 214

 ? 134 117 152 194 6 135 248 118 247 244 186 130 32 130 117 64 161 1 62 75 116

 ? 62 233 113 155 246 0 254 13 88 245 235 40 83 39 241 20 234 4 3 100 193

 ? 168 241 147 196 138 132 1 22 16 159 7 227 248 6 201 121 157 248 178 69 215

 ? 166 20 238 90 202 253 136 55 130 18 183 122 71 152 58 70 167 88 107 231 224

 ? 54 38 193 209 208 160 130 169 48 124 69 8 145 96 219 73 206 134 234 18 104

 ? 38 185 40 204 130 0 55 167 10 157 255 3 12 142 141 238 121 78 171 225 244

 ? 32 12 136 176 116 81 228 230 121 182 48 240 178 34 100 8 177 172 2 151 199

 ? 150 109 158 235 80 80 38 127 28 6 96 36 84 167 146 211 194 71 140 99 249

 ? 141 124 56 3 50 150 130 150 134 178 136 150 196 5 47 114 161 75 180 127 17

 ? 40 103 248 23 232 2 86 90 246 76 53 116 66 79 174 62 88 41 128 198 201

 ? 30 68 13 254 131 81 195 39 35 235 145 184 30 15 96 44 188 216 10 217 128

 ? 0 39 21 229 0 183 34 4 228 116 144 60 150 118 210 207 24 237 162 50 87

 ? 39 102 167 128 54 117 231 32 147 108 130 175 7 30 230 231 179 89 228 129 15

 ? 174 130 181 172 61 231 95 188 205 82 45 252 136 123 140 54 125 173 167 82 144

 ? 180 39 78 186 183 85 136 132 96 242 135 140 233 165 74 0 155 224 109 159 226

 ? 36 240 12 173

 

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Its all jibberish

Anything beginning with a ? is gibberish and its junk.... if you load up the HAHcentral sketch on your base node these are all disabled by default - you are actually getting no valid data.   A valid message will begin with OK.

There is NO schema per se for decoding the BYTEs of data you need to examine the C source code for the sending unit to determine how the the bits are packed, or alternatively examine the LUA decoder to see how its unpacked.

Brett

andy_godber
Offline
Joined: 13 Sep 2011
Next problem - FTDI not recognised?

Ok, so connected the HAHnode to the HAH, but experiencing problems with it being recognised (i.e, its not)

The FTDI serial cable doesnt seem to be recognised - Ive tried a couple, get message (from DMESG):

 

hub.c: USB new device connect on bus1/1, assigned device number 2

usb.c: USB device not accepting new address=2 (error=-145)

hub.c: USB new device connect on bus1/1, assigned device number 3

usb.c: USB device not accepting new address=3 (error=-145)

 

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Can be problematic

I normally use a PL-2303 TTL cable which I know is 100% compatible.

I'm not sure what type of FTDI you have but there are only 2 types supported and these are:

usbserial.c: USB Serial support registered for FTDI SIO
usbserial.c: USB Serial support registered for FTDI 8U232AM
usbserial.c: USB Serial support registered for PL-2303

Its going to be hard to debug this without knowing the product/vendor code for the USB device, and to get this you need to plug it into a linux box preferablly.  You can get this from windows, but I'm not going to talk you through a series of damn popup windows and mouse clicks when I could just get you to type "lsusb" on a linux box (not the HAH)

Perhaps you have either an unsupported FTDI module as there is more than 1 type or perhaps you are drawing too much current and overpowering the port causing things to break.  But it would normally tell you so in the dmesg.

Is that all you get from the dmesg ?

Brett

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Cables that work

For a while, I used this FTDI based part from Sparkfun http://www.sparkfun.com/products/9115

Now, I use the PL-2303 cables that are available from the shop.

Whatever you use, the positive supply should be at 5V ... the onboard regulator steps this down to 3.3V for the AVR and the RFM12B.

Do note that the DS18B20 is powered directly from the supply, so don't use any battery that supplies > 5.5V (we tend to use 3xAA cells - these last for ages).

As Brett says, the data output by the RoomNodes is 'internal' to the system and not really designed for public consumption. However, once you see a message that starts with 'OK', you are pretty much there & don't have to be a genius to see what is going on. Also, read http://dbzoo.com/livebox/hah_hahnode#airwick_hahnode

Derek

andy_godber
Offline
Joined: 13 Sep 2011
Derek's cable

The first cable I tried was the one I normally use to program Nanodes, the second was one I think Derek provided.

Both work on a PC, as does the node (per ouput in O.P). Googling the error message results in various unsolved hits, most notably on OPEN-WRT or MIPS systems, with suggestions of timing errors on the USB bus.

Before I went to bed, I remember thinking the USB socket was a bit 'moveable', so later today I'll open everything up, check joints, voltages on FTDI, report device types, and try a memory stick, drive in the USB socket etc, to see if recognised.

andy_godber
Offline
Joined: 13 Sep 2011
[Resolved] = dodgy USB port

Having re-examined the USB socket on the HAH, I can see that two of the contacts have been bent out of shape. Careful prizing back into place results in successful detection of the FTDI.

I do notice that insertion of a new USB device causes the HAH to reboot - is this normal?

Either way, I'll now get round to modifying the sketch to read the temps etc.

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Most unusual

This is very interesting. I've never seen the USB port pins messed up ... the USB connectors are normally pretty solid and designed for lots of insertions.

One to add to the knowledgebase. 

I do sometimes see the HAH reboot on insertion of a USB device. It doesn't happen every time, just occasionally. Could be that the 'blip' on the 5V rail pushes something over the edge. I now make a habit of pre-attaching any USB devices with the HAH powered off. 

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Modify the sketch?

Not sure why you are going to modify the sketch... as the sketches already in place also if you start to modify the sketches then you also need to roll your own LUA decoder and figure out how to bolt that into the system to read your new sketches binary stream.  Yes you can do it but nobody generally does as all the hard work getting these two talking to each has already been done  Check out the pre-canned .HEX files that you can just flash up.

http://code.google.com/p/livebox-hah/downloads/list

Glad it was just a dodgy USB port causing you grief an nothing too serious.

Brett

andy_godber
Offline
Joined: 13 Sep 2011
Sorry, LUA, not sketch

Sorry, LUA, not sketch

brett
Offline
Providence, United States
Joined: 9 Jan 2010
LUA mapping applet

Yes you will need to craft up a jeenodeApplet.lua to map the right CLASS of object to the Sketch you flashed onto your jeenode.  Once you get to this stage you are getting close to done.   Do watch to make sure you are seeing valid data coming in on the xap-serial endpoint at least the "OK <nodeid>" messages to know the comms are good.   The plugboard applet you need to craft will picked this up and automatically slice up the data and feed to the appropriate BSC endpoints.   - Brett

andy_godber
Offline
Joined: 13 Sep 2011
So, the data again

Just back to the orignal post, where I mentioned I was seeing data, preceded by '?'.

Are you saying that this is wrong, and should be starting with 'OK' ? The output from microcom the HAH shows

 

# microcom -s 57600 /dev/ttyUSB0

 

[RF12nocfg.1] A i1 g212 @ 868 MHz

 

Current basenode configuration:

 A i1 g212 @ 868 MHz

 ? 23 254 196 192 47 65 127 224 151 230 168 213 36 157 163 112 97 127 180 167 222

 ? 22 137 172 93 106 192 251 22 234 225 219 160 102 119 82 14 194 135 105 72 9

etc
At the moment, there is no roomnode available, just the central node - I want to be able to read the temp from there.
(I know Ive still got to do the LUA, but am uncertain on prcceeding if the raw data is bad).
Also, wiki/instructions on setting the node parameters are unclear (for me!). I see the instructions say 
"Available commands:" "\n"
" <nn> i - set node ID (standard node ids are 1..26)" "\n"
" <n> b - set MHz band (4 = 433, 8 = 868, 9 = 915)" "\n"
etc,
but where are these entered from? (I can also see that my values are ok?)
Happy New Year.

 

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Clue in the 'startup message'

>[RF12nocfg.1] A i1 g212 @ 868 MHz

The Basenode firmware that you have is the 'no configuration' version. i.e. it is pre-configured to be Unit Id 1 and operating at 868MHz. So, it's fine and you need do no more to this.

Any message that starts with a '?' is just noise and can be ignored.

Valid messages start with 'OK'.

Clearly, until you have the RoomNode running, there is nothing much more that can be done (parts are packed and will be posted out soon).

HNY!

Derek.

andy_godber
Offline
Joined: 13 Sep 2011
Temp on central node?

Thanks - no way of getting to the DS1820 on the central node then?

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
Check the source code ...

I'm pretty sure that the central node firmware has no provision for servicing a DS18B20 ... it is designed to listen for RF signals from other nodes.

That said, I suppose that it could be made to do this. Look at the Arduino source code and see.

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Central node

The central node was designed to only TX/RX RF information there was no provision for adding any additional sensors to this unit.  Having said that everything is possible, but most people run a 1wire or Currentcost in close proximity to the HAH central anyway so there was no great reason to have yet another temperature sensor within 1ft of the HAH unit.

Brett

andy_godber
Offline
Joined: 13 Sep 2011
A bit further forward

Ive 'borrowed' a resonator to get the roomnode working.

This now fires up, but is not gathering any data (although it is now successfully transmitting it (that is, nothing) to the base node)

Im guessing the failure to locate the OneWire temp sensor is the problem.... I'm sure Ive got a spare and will report success or otherwise shortly.

 

 

[roomNode.3] B i2 g212 @ 868 MHz 

Locating OneWire devices...Found 0 devices.

Unable to find address for Device 0

ROOM 2 0 0 0 0

ROOM 0 0 0 0 0

ROOM 0 0 0 0 0

Hardware Info