HAHCentral sketch error?
7 January, 2015 - 21:54
Hi Brett,
was wondering if you could please give the HAHCentral sketch a quick look over for me.
I am trying to use your newer version for the first time and have it setup as a roomnode also but using 1 wire rather the DHT.
there seems to be an error in the serial output from this with an extra ' ' character being sent after node id but I have managed to sort this for my node.
however, I still am not properly decoding the payload temp even though I have checked and double checked the structure of the payload matches the lua decoder e.g (8,1,7,-10,1)
i am getting negative temps for a supposedly room temp reading suggesting the raw data is being sliced/compiled totally wrong.
The data from the serial output of the central node shows OK 1 0 0 80 3 0 0 (once the extra blank is removed) which makes me think it's the sketch rather than the lua that incorrect.
I noticed you have used a union on this sketch for the payload, (presumably cos your transmitting over serial rather than rf12?) is this all working ok at your end? no obvious errors that you can see in the code?
the setup in question is not local (Brothers house) hence the reason for asking as I cannot easily debug. I suspect I may have done something wrong when adding 1wire to the central sketch but looking over my mods I cannot see what.
thanks,
Garry
9 January, 2015 - 08:52
#2
Something that I noticed you
Something that I noticed you have 6 data values; 0 0 80 3 0 0
However this struct only has 4 bytes !
struct roomnode {
byte light; // light sensor: 0..255
byte moved :1; // motion detector: 0..1
byte humi :7; // humidity: 0..100
int temp :10; // temperature: -500..+500 (tenths)
byte lobat :1; // supply voltage dropped under 3.1V: 0..1
};
There is a bug on this line
union {
byte b[6]; // BUG HERE
struct roomnode n;
}
payload;
We should let the compiler work that out as clearly I can't count !
union {
byte b[sizeof(struct roomnode)];
struct roomnode n;
}
payload;
That could be the problem.
Brett
9 January, 2015 - 09:02
#3
Doing this manually without
Doing this manually without an arduino - just enter this and compile it up.
#include <stdio.h>
#include <string.h>
#define NODE_ID "1"
typedef unsigned char byte;
struct roomnode {
byte light; // light sensor: 0..255
byte moved :1; // motion detector: 0..1
byte humi :7; // humidity: 0..100
int temp :10; // temperature: -500..+500 (tenths)
byte lobat :1; // supply voltage dropped under 3.1V: 0..1
};
union {
byte b[sizeof(struct roomnode)];
struct roomnode n;
}
payload;
static void doReport() {
printf("OK ");
printf(NODE_ID);
byte i;
for (i = 0; i < sizeof(payload); i++) {
printf(" %d", payload.b[i]);
}
printf("\n");
}
int main(int argc, char **argv[]) {
memset(&payload, 0, sizeof payload);
printf("Sizeof(roomnode) %d\n", sizeof(struct roomnode));
printf("Sizeof(payload) %d\n", sizeof payload);
payload.n.light = 100;
payload.n.moved = 1;
payload.n.humi = 54;
payload.n.temp = -176; // -17.6
payload.n.lobat = 0;
doReport();
}
When I run that I get this output:
[brett@wombat 9-jan-15]$ cc -o x x.c
[brett@wombat 9-jan-15]$ ./x
Sizeof(roomnode) 4
Sizeof(payload) 4
OK 1 100 109 80 3
Pushing into the bit slicer I get the data back out correctly.
> return bitslicer("100 109 80 3",8,1,7,-10,1)
100 1 54 -176 0
I would say the code is working.
11 January, 2015 - 20:51
#5
Could this be affecting my
Could this be affecting my 1-wire temp from roomnodes?
I'm getting -ve temp too but is fixed at -24.6 . My output from roomnode is OK 2 212 0 10 3. Light changes ok and don't have humi or moved active.
Tried this on two different roomnodes is the same...
12 January, 2015 - 09:31
#7
Garry glad you got it
Garry glad you got it sorted. You found a bug which made me look at the code and I found another so that's a gone well :)
12 January, 2015 - 09:37
#8
Bodge the additional bytes, 6
Bodge the additional bytes, 6 instead of 4, don't cause any functional problem. They just aren't required. In anycase these two bugs we found only affect the HAHCentral when also running as a roomnode. It does affect any inbound RF message processing.
If the light data is ok but your 1wire is not check your wiring also make sure you have the pullup resistors in place and its the right value. 4.7k
Brett
19 January, 2015 - 14:57
#9
same issue of constant temp=24.6 with DHT11
hi brett,
i have the same issue when changing a DS18B20 against a DHT11 (both from the shop).
Having the DS18B20 in the roomnode2 i get correct temperatures,
when i change to the DHT11 (same roomnode, same port), it tells me temp=(-?)24.6 and humi = 0.
Is there anything else to change (other resistor or other roomnode2.ino?), when i change to the DHT11?
Thank you,
Markus
19 January, 2015 - 22:24
#10
The DHT11 is pin compatible
The DHT11 is pin compatible with the DS18B20 but the code is not. So you do need to recompile the roomNode2 sketch. Did you do this?
You will see two lines like this.
#define DHT11PIN 4
//#define ONE_WIRE_PIN 4
These are mutually exclusive. Pick ONE_WIRE or DHT11 but not both.
24 January, 2015 - 17:55
#11
DHT11 and 4.7k pullup resistor
I got it working with recompiling the roomnode2 sketch!
But i wonder, if i get correct results because of the 4.7k resistor,
is this necessary for both, the 1WIRE and the DHT11 or not?
Currently i am using an original jeenode v6 from the jeelabs shop, which do not have the secound 4.7k resistor on board.
Do i have to add one to this boards or not?
24 January, 2015 - 21:43
#12
For both there would be some
For both there would be some pull-up resistor in place, if your DHT is soldered onto a PCB perhaps it already has one. Which might explain why when you put another things go awre.
Put a meter between the dht11 data pin and power pin and see what resistance you get.
Recompiling would do the trick as the default .HEX file published for the roomnode is for one-wire operation.
Brett
27 January, 2015 - 08:50
#13
Shot in the dark, isn't there
Shot in the dark, isn't there an internal pullup resistor on the controller?
27 January, 2015 - 19:55
#14
No, not on the Original
No, not on the Original Jeenodes from the Jeenode Shop!
YES - There is an additional space being emitted in the sketch that should not be that is a BUG.
This will cause an extra entry to be placed into the table when we convert from a stream to a bin using this function:
-- Convert a string of space separated decimal numbers into a binary stream
function stream2bin(stream)
return table.concat(tablex.map(function(x) return Dec2Bin(x,8):reverse() end,
tablex.map(tonumber, utils.split(stream))))
end
Observe: Here you see the util.split() with the leading space and its effect.
> pretty.dump(utils.split(' 0 0 80 3 0 0'))
{
"",
"0",
"0",
"80",
"3",
"0",
"0"
}
>
And that causes us to fail !
> return stream2bin(' 0 0 80 3 0 0')
stdin:2: invalid value (nil) at index 1 in table for 'concat'
stack traceback:
[C]: in function 'concat'
stdin:2: in function <stdin:1>
(tail call): ?
[C]: ?
Without the leading space we parse ok:
> return stream2bin('0 0 80 3 0 0')
000000000000000000001010110000000000000000000000
We should not have that space in there....
Index: HAHCentral.ino
===================================================================
--- HAHCentral.ino (revision 630)
+++ HAHCentral.ino (working copy)
@@ -156,7 +156,6 @@
Serial.print("OK");
Serial.print(' ');
Serial.print(NODE_ID, DEC);
- Serial.print(' ');
for (byte i = 0; i < sizeof payload; i++) {
Serial.print(' ');
Serial.print(payload.b[i], DEC);
As for the results you are getting
If we slice this on the bit boundaries
00000000 0 0000000 0000101011 0 000000000000000000000
> =bitslicer("0 0 80 3 0 0",8,1,7,-10,1)
0 0 0 -176 0
That roomnode input would be a temperature of -17.6 which is pretty cold if its inside your house !
How that works:
0000101011 we reverse to yeild 1101010000 - this is a -ve number as the top bit is 1
So we takes one's complement (Invert all the bits) giving us: 0010101111 this number is 175.
As we are -ve this should be expressed as -(175+1) = -176 out return result.
The units are in tenth for temperature so we divide by 10 to get -17.6 -- voilia !
What I'm saying is that for the serial input "OK 1 0 0 80 3 0 0" this is the correct results.
Recall "OK 1" means it from RoomNode 1 - all the rest is the data.
If this is not correct then we need to look at the sketch and no I'm not using this sketch at the moment in it capacity as a room node. I have a standalone Nanode gateway that I use
Brett