Sensebender Micro

[Anticimex]

@ximinez looks good. You should be done with personalization. Remember to require signatures from the SenseBender in addition to "enabling" it. You can also require signature on the GW, thus forcing all communications between them to be signed. The serial console will reveal how it goes. You can enable verbose debug (MY_DEBUG_VERBOSE_SIGNING) for the signing if you want more details on the signing parts.

[ximinez]

I have the sensor sketch mostly done, but I'll have to do some soldering again tomorrow. It looks like D7 got burnt when I plugged in my ESP8266, giving ~0,5v out on that pin. Will have to work around that:

Sôártinç óensor (RÎONA-, 2.0.0-beta)
Raäio init æáiìåd. Ãèeck wiring.

When that is OK, I'll look at the GW sketch.

[Anticimex]

Sounds good. Bedtime here too.

[ximinez]

D3, D4 and D7 are all funky, and do not give ~3v when set high. So I'm back to the radio being on all the time.
D5 and D6 mysteriously work just fine.

Radio is now OK, but the sensebender reboots before it gets to setup().
Stárting óensor (ÒÎONA-, 2.0.0-beôá)
Ráäio init suããessæuì.
æéîä parenô
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,óô=bc:
[reboot and repeat]

[tbowmo]

@ximinez

Sounds like it's on its way to the "other side"..

[ximinez]

Yup. Setting up my other sensebender as a proper signing sensor and my uno as a gateway. This will have to wait until I get a couple more working sensors.

[ximinez]

Ok. I set up my GW, and set up my healthy sensebender as an outdoor sensor. The zombie sensor is now a working indoor sensor.
I have enabled signing and set up whitelisting, but enabling signing debugging makes the sketch oversize, so I can't actually check if signing works - but atleast now I have two sensors.

[Anticimex]

You will still be notified without verbose logging. And if you have enabled and require signing, you won't get any data if something fails (assuming signing is properly activated).

[user2334]

@user2334 said:

I just received two Sensebenders, but have problems getting the device to consume little power. I get totally different values as displayed above.

With the following sketch, I get about 5,6mA in active state and 1,6mA in sleep mode with nRF24 attached. I have compared different nRF24-chips and this one consumed the least power.

Without the nRF24, I get 4mA and 0,025mA (=25µA) during sleep mode.

#include <LowPower.h>
#include "RF24.h"

RF24 radio(9, 10);

void setup() {
}

void loop() {
    delay(8000);
    LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
}

As a follow-up to my previous posting, I can confirm, that using original nRF24-modules (best source seems to be https://www.itead.cc/nrf24l01-module.html), I get 0,023mA (=23µA) with nrf24 attached during sleep mode (no difference between the libraries JeeLib->Sleepy::loseSomeTime or LowPower->LowPower.powerDown).

It is quite interesting, that so many nRF24 Modules (bought from eBay, from Amazon UK) are clones with higher power consumption. Some of them use 3mA, some have electrical short, ...

[ximinez]

@Anticimex I've set MY_SIGNING_SOFT, MY_SIGNING_REQUEST_SIGNATURES and MY_SIGNING_NODE_WHITELIST on the GW, and reenabled (normal) debug but not signing debug since that is too big.
With those enabled, if the sending node does not sign, I should not get this?

0;255;3;0;9;read: 2-2-0 s=1,c=1,t=0,pt=7,l=5,sg=0:6.3
0;255;3;0;9;read: 2-2-0 s=2,c=1,t=1,pt=2,l=2,sg=0:59

[Anticimex]

@ximinez The GW will only require signatures from a node that in turn require signatures.
It is the sg-flag that indicate if a message is signed, in your case, both messages are unsigned.
If you only have node->gw communication, both gw and node has to require signatures for you to see signed messages.
If you have gw->node communication, it is enough that the node require signatures, the gw will then sign them, no matter if the gw require signatures or not.

[ximinez]

0;255;3;0;9;read: 3-3-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
0;255;3;0;9;read: 3-3-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:57ACB4BD46843BFCC7ABA693CC5AA527F7724531F525338E8A
0;255;3;0;9;read: 3-3-0 s=2,c=0,t=7,pt=0,l=0,sg=0:

I feel more secure now :-P

[Anticimex]

@ximinez Hm, good, but I still see no signed message. But at least a nonce was sent

[ximinez]

@Anticimex Sensor values are getting through though. And signing is requested on both ends (for one sensor so far). I can't see any other #defines that should be set to enable signing. I get the same result on both the zombie sensor and the unmodded one.

I get three "sign fail" (showing up as verify fail on gw) before the sketch reaches setup(), where the ATSHA gets powered up. I will need to power the ATSHA somewhere in the mysensors library. However, once setup() is reached, the ATSHA seems to handle powering down and up just fine.

I can however say that it the Si7021 doesn't like being powered off and back on again after sleep. That causes the MCU to reset.

[Anticimex]

@ximinez Ah, yes, on development branch the signing backend clear the sign flag when it verifies the message. so it will always show as 0 without verbose signing debug enabled.
I know there have been discussions about a "pre setup" to be used for early sketch init. You probably want to power the atsha for early handshaking as well to get the sketch name and such to propagate properly. @hek perhaps has the latest on such features.

[ximinez]

I've built a nicer-looking serial gateway instead of the rather large ethernet gateway. I thought that would basically be a "slot-in" as long as I personalize the GW it with the same SOFT_HMAC_KEY, SOFT_SERIAL and AES_KEY as the original GW. Are there more steps that need to be taken to get the sensors to connect?

[ximinez]

No matter what I do now, this is what I get:

send: 2-2-0-0 s=1,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail
send: 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=fail:26.0
send: 2-2-0-0 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail
send: 2-2-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=fail:34
send: 2-2-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail

[Anticimex]

You must not use the same serial across nodes. Serial have to be unique. HMAC have to be identical.

[ximinez]

Yes, I know serial must be unique. Serials go in the whitelist for the corresponding node ID. It turned out to be the NRF24L01+-modules with antennas. Replaced it with a regular module and it worked fine.
(Which is strange, because one of those modules worked fine on the ethernet gw. It doesn't eat that much power does it?)

[Anticimex]

@ximinez The signing failing is due to messages not arriving (st=fail). So it is not signing that is your problem here.
However, with signing, messages are now "full size" which strains the RF link so if it is "weak" fewer messages get through if they are "longer". I suspect that is the problem here. Basically the usual stuff; adding caps, using a dedicated regulator and so on...