Sensebender Micro
-
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.
-
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).
-
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); }@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, ...
-
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).
@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 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@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. -
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
-
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 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 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.
@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.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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.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?
-
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 -
You must not use the same serial across nodes. Serial have to be unique. HMAC have to be identical.
-
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?) -
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?)@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... -
Looks like it works now, but what's the deal with the initial failed signs? Look at http://pastebin.ca/3585005 (GW side) and http://pastebin.ca/3585014 (Sensor side. Not the same powerup). It starts by failing a lot, then after a while everything looks OK.
-
Looks like it works now, but what's the deal with the initial failed signs? Look at http://pastebin.ca/3585005 (GW side) and http://pastebin.ca/3585014 (Sensor side. Not the same powerup). It starts by failing a lot, then after a while everything looks OK.
@ximinez difficult to say. Maybe a long stabilization period for the regulator. You could try to add a delay in early init in the library to see if it makes a difference.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ximinez difficult to say. Maybe a long stabilization period for the regulator. You could try to add a delay in early init in the library to see if it makes a difference.
@Anticimex and again, it is not failed signature errors per se. It is st=fail (transmission errors) that cause the signing backend to timeout. So it is not the performance of the atsha (or sw) that cause the issue here, it is the radio.
-
For my battery reporting, I have set 1.9V as 0%, 3.3V is 100%..
While you're at it, also power down the external flash, as it might also contribute a bit..
@tbowmo said:
While you're at it, also power down the external flash, as it might also contribute a bit..
I forgot about the flash. That would require bootloader support though? Or is the OTA done by jumping to the bootloader while running, keeping pin states?
I'm waiting for some SOIC breakouts in the mail. When I get them, I'll scavenge the ATSHA and flash module from my zombie sensor and build my own sensebender with blackjack and hookers.
