HAHNode data format
30 December, 2011 - 19:23
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
30 December, 2011 - 23:32
#3
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
31 December, 2011 - 05:53
#4
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
31 December, 2011 - 14:06
#7
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.
31 December, 2011 - 14:52
#8
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
31 December, 2011 - 19:19
#10
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
1 January, 2012 - 12:23
#12
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.
1 January, 2012 - 13:32
#14
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.
1 January, 2012 - 17:37
#15
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
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