Sensebender Micro

[alexsh1]

@Anticimex I agree with you, but I find it interesting that sending a message fails exactly 9 times every time the node starts. I have changed different nrf24l01+ modules, put the transceivers close / far - it made absolutely no influence at all. 9 times st=fail and then everything works as expected.

[Anticimex]

@alexsh1 yes, it seem an odd coincidence. But I see nothing that signing can do about it I am afraid. st=fail means a message was not confirmed to get delivered properly and signing can't handle message drops. For security reasons, I have decided to not support retransmissions of nonces. If it can't be delivered, the entire signing session is considered compromised and have to be restarted with the exchange of a new nonce.

[alexsh1]

@Anticimex said:

@alexsh1 yes, it seem an odd coincidence.

It is even more interesting that I have zero st=fail after nonce is received .
I can probably change the GW settings and the channel to make sure this is not causing any issues, but 9 st=fail in the beginning every time is a strange coincidence.

@ximinez Did you manage to get it sorted? How many st=fail do you have in the beginning?
Anyone else is having similar issues?

[Anticimex]

@alexsh1 Perhaps a long stabilization time for a power supply or clock on the node or gw cause it. You could try to add some delays and see if it is time-after-power-on that is the issue or whatever it might be. It is not signing in any case, because it is the node sending that reports st=fail. That is a rf issue. It always is. The nonce has been generated as it should, and the signing backend trusts the transport layer to handle the transmission of the databuffer, and in this case the transport layer reports back that it could not.

[alexsh1]

@Anticimex Just an idea - could it be that nonce is not generated in the beginning and requires some time? I'll do some testing tonight

[Anticimex]

@alexsh1 No, nonces are being generated:

0;255;3;0;9;SHA256: 86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F50900000000000000
0;255;3;0;9;Transmittng nonce
0;255;3;0;9;Skipping security for command 3 type 17
0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F509

and the generated nonce is not transmitted correctly (st=fail) due to some transport issue.

[alexsh1]

@Anticimex said:

@alexsh1 No, nonces are being generated:

Than I am out of guesses - I cannot explain why st=fail comes up.
FYG, I tried it without signing and it works just fine. No st=fail.
There must be something between signing and transportation or transportation after signing?

[Anticimex]

@alexsh1 like I said, signing is not in itself the problem. The problem is that big messages are failing. You can just try by generating big messages yourself and you will get the same problem. I know this by looking on what generates st=fail and it is the transport layer. Signing generates the data to be transmitted, and this data is printed and shown to be correct. Bigger messages require more reliable communications. Shorter messages has a better chance of being transmitted correctly. It is that simple. Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.

[alexsh1]

@Anticimex said:
Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.

I tried

1. powering GW/Sensobender from a different source (battery, USB, PSU - 12V in case of GW, 5v in case of sensebender via LDO)

2. swapped a few radios. Most of these are from working nodes with caps soldered. Maybe I should try completely different ones from a different batch? I mixed up three batches with no improvement.

3. Tried to place GW and the sensebender 1m/5m/10m apart

4. GW radio is powered via the AMS1117 3.3v

So far it is the same result. Not sure I can come up with anything obvious unless you can suggest

[Anticimex]

@alexsh1 sorry, I have not much else to suggest except experimenting with delays to see if the issue with failed transmissions at node startup can be avoided. I am no specialist on the radio. I'm the security guy and I see no wrong with the behaviour of those parts so I am short of any more useful suggestions I am afraid.

[hek]

@alexsh1

When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.

Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.

[alexsh1]

@Anticimex Well, at least we are fine on the security part
I'll experiment more on the radio part when I have time - why there are only 24h in a day? (rhetorical question)

[alexsh1]

@hek said:

@alexsh1

When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.

Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.

@hek
I downloaded the dev on 26/05 so it is very recent.
I have normal radios both ends, but the idea is to have amplified one on the GW as well and change rf24_pa_max. Additionally, I'll try to mix as many radios as I can have. Who knows?

To be honest, things were working OKish before as I took it seriously decoupling radios etc. This voodoo dance around radios really irritates me. Life is too short to waist it - I am now thinking seriously switching to RMF69W or probably to RFM95* (Lora)

[Anticimex]

@alexsh1 yesh i have bashed my head on rf24 stability myself and have decided to base my network on rfm69:s instead. Too much chatter @2.4ghz. I hope the 69:s have better range and they also have the bonus of AES encryption in hw if you want to obfuscate the communication some. Signing adds netter security, but the paranoid can combine signing with encryption (yes rf24 can use AES encryption in software, but that cost memory and some overhead instead)

[alexsh1]

Whatever I did, did not help to solve st=fail

When I disable signing I have got the following (not a signle st=fail):

Starting sensor (RNONA-, 2.0.0-beta)
Radio init successful.
Sensebender Micro FW 1.5 - Online!
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=17,sg=0,st=ok:Sensebender Micro
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.5
send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=2,c=0,t=7,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=3,c=0,t=13,pt=0,l=0,sg=0,st=ok:
isMetric: 1
TempDiff :125.61
HumDiff  :150.00
T: 25.61
H: 50
send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:25.6
send: 3-3-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=ok:50
send: 3-3-0-0 s=3,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.09
send: 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:85

I am going to try different channels now with signing

[Anticimex]

@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.

[Yveaux]

@Anticimex just a noob question: do you have an idea of the performance penalty of (software) signing? Any benchmark figures?

[Anticimex]

@Yveaux no, sorry have not got around to compare them. But software signing is actually quicker due to the single write bit banging for the atsha204a. One way to see the difference is measuring the delay for an ACK to come back from a node that require signed messages. I have no figures, but a node with software signing responds slightly faster.

[Yveaux]

@Anticimex But is it significantly slower than without any signing?

[Anticimex]

@Yveaux yes. But I know that significant improvements can be made in the nonce whitening. It incrementally calculates a hash which is which is far less efficient than calculate the hash of a buffer. So there are room for improvements. I just wish there were more time, and now my arduinos are packed down so I wont be able to test. But volunteers are welcome, I can still code

[alexsh1]

@Anticimex said:

@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.

Do you think a message size has anything to do with st=fail?

[Anticimex]

@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.

[alexsh1]

@Anticimex said:

@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.

I do not think its signing, but I think it is implementation of signing and sending.
I do not get st=fail after the initial 9 messages not even once. Something is just very-very odd.

[ximinez]

I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.

[alexsh1]

@ximinez said:

I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.

Did you manage to get it sorted?

[ximinez]

I just ignore the first fails. It works after that, and has done so for close to a month.

[Anticimex]

Well, if you think the signing implementation cause initial radio transmissions to fail I am afraid I will need your help in explaining how. Because I fail to see any connection between signing and radio behaviour. st=fail is a transmission problem, and signing implementation require flawless transmissions. I also suspect you both use nrf24 and I also suspect you will not see this if you use rfm69 although I use nrf24 myself for testing and I have not seen what you report. But I am sure you really experience this strange behaviour. But I maintain that it is due to some startup problems of the radio. I am afraid I cannot find anything I can change in the signing codebase to have an influence on st=ok or st=fail. But I am all ears to suggestions of course if you see something suspicious.

[alexsh1]

@Anticimex Interesting observation - another node with the same rf24l01+ radio from the sensebender with the same GW and signing works without st=fail. This is now clear that this is not a rf24l01+ hardware issue.

[Anticimex]

@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?

[alexsh1]

@Anticimex said:

@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?

Yes, I tried to compare apples with apples:

1. it is the same distance / FW
2. the code is different to the expend that the sensebender has got Si7021/ATSHA204a and the other sensor did not. I may try to upload a simplified code to the sensebender just to test it to make it a more equal comparison.
3. the power source is the same - 5V 500mA via AMS1117 + cap

[Anticimex]

@alexsh1 You could also try soft signing on the sensebender and see if that makes a difference. Perhaps the atsha device interferes with the radio (this depends on routing and such things). I have no sensebender myself and I have not noticed the behavior you describe with nrf24 and atsha204a.

[alexsh1]

@Anticimex I tried the sensebender with soft singing - still the same st=fail

[Anticimex]

@alexsh1 Ok. I guess that is "good news for me" as it rules out signing related hardware as well. I guess so far, the only conclusion is that rf performance is to some extent degraded on the sensebender.

[Yveaux]

@alexsh1 just a hunch: do both nodes have identical CPU's & clock frequency?

[alexsh1]

@Yveaux Correct - I have used Pro Mini 3.3V 8Mhz which corresponds to the sensebender

[ximinez]

Is there a "pre setup" available yet? The failed transmits are before sensor values are transmitted, so they aren't in the actual sketch but somewhere in the library. I'd like to try just sleeping the sensor 5-10 seconds before the initial data is transmitted and see if that makes a difference.

[alexsh1]

@Anticimex Yeah it seems like a combination of things but not a signing problem

[Anticimex]

@ximinez not sure. I know it has been discussed. But you can always patch the library to test.

[alexsh1]

@ximinez I do not think so. Either to patch the library or you do it in the sketch. Unless I do not know some other secret place.

[hek]

@ximinez

You can add a before()-method.

[ximinez]

@hek said:

@ximinez

You can add a before()-method.

It's that easy? I'll give it a try when I get around to it, unless @alexsh1 feels like trying it first

[Haakon]

Hi! I have just gotten four Sensebenders and was hoping to connect PIRs to them and powering them with AA batteries. I understand from the forums that people do this. But is there a working Arduino sketch example implementing a PIR for wake-up out there? (And perhaps there is a more detailed description for such a hardware setup for us newbies?)

[tomkxy]

I have bought another couple of sensebenders.
I am not able to upload sketches to one of them.
When I connect the programmer the status led goes to solid red. From another one, I realized that it is not solid red.

What is the meaning of a solid red status LED?

[hek]

What does the log say when you upload?

[alexsh1]

@Haakon Have a look here - https://forum.mysensors.org/topic/2478/slim-cr123a-2aa-battery-node
Just change your board for sensebender.

[tomkxy]

@hek

D -Uflash:w:/var/folders/3s/rjbksrj96nv0hqfqjlpfw8bm0000gn/T/build8699526819198040594.tmp/SecurityPersonalizer.cpp.hex:i 

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 16:30:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/tom/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbserial-DA01IGTO
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: ser_recv(): read error: Device not configured
Probleme beim Hochladen auf die Platine. Hilfestellung dazu unter http://www.arduino.cc/en/Guide/Troubleshooting#upload

I have Sensebender selected as board.

Btw, where is the hardware folder? It is not present anymore in the development branch?

[hek]

@tomkxy said:

Btw, where is the hardware folder? It is not present anymore in the development branch?

You can use the build in board manager nowadays.
https://github.com/mysensors/ArduinoBoards

Check board for solder bridges or anything suspicious.

[johnr]

Hi,

I wonder if anyone modified the original sensebender sketch to include a door sensor?
Do you need a pullup? If you have a sketch somewhere I would be happy if you could send/post it, as I have problem finding time to code right now.

[martinhjelmare]

@johnr

Here's one for a button, but shouldn't matter:

https://forum.mysensors.org/topic/2887/sensebender-micro-button/2

[alexsh1]

@johnr This is easy.

// PIN = 2 or 3 only
 
void setup {
  pinMode(PIN,INPUT);
  digitalWrite(PIN,HIGH);
}

This activates internal pull-up.
The sensebender has got pinout of Pro Mini

[timropp]

Well that didn't go well... assembling my first micro. Soldered on some pins for the FTDI connection, added power (2xAA holder), and soldered on the radio with cap. Then I put in batteries and brought up my domoticz page to see if it showed up. Started to smell something, looked down, and there's smoke coming from the battery holder. Grabbed the whole thing and yanked the wire free then dropped it in the sink. Not sure where I screwed up, but I sure shorted something!

[hek]

Did you find the problem?

[alexsh1]

@timropp sounds like you shorted batteries somewhere

[timropp]

Nope, didn't find the problem. Must be some solder that shorted the batteries out but I don't see it. Oh well... main problem is that was my only 2AA holder on hand, and it melted right through the end of it, so now I have to wait on more before I can try again. Bummer

[alexsh1]

You can feed it with just two wires connected to the USB FTDI TTL converter / programmer - have a look at this https://www.mysensors.org/hardware/micro
Available Pins - GND, GND, VCC (on the right)

[mvader]

I am having an odd issue with one of my sensebender boards.
I have flashed 5 in a row, same sketch, same everything.
all look fine (and in english) in the serial monitor. but this one board displays different.
it does seem to work. but i can't figure out why it's showing up different in the monitor.
any ideas?

Óåîóåâåîäåò Íéãòï Æ× 1.5óåîä: 2-2-0-0 ó=255,ã=0,ô=17,ðô=0,ì=3,óç=0,óô=ïë:1.5
óåîä: 2-2-0-0 ó=255,ã=3,ô=6,ðô=1,ì=1,óç=0,óô=ïë:0
óåîóïò óôáòôåä, éä=2, ðáòåîô=0, äéóôáîãå=1
 - Ïîìéîå!
óåîä: 2-2-0-0 ó=255,ã=3,ô=11,ðô=0,ì=17,óç=0,óô=ïë:Óåîóåâåîäåò Íéãòï
óåîä: 2-2-0-0 ó=255,ã=3,ô=12,ðô=0,ì=3,óç=0,óô=ïë:1.5
óåîä: 2-2-0-0 ó=1,ã=0,ô=6,ðô=0,ì=0,óç=0,óô=ïë:
óåîä: 2-2-0-0 ó=2,ã=0,ô=7,ðô=0,ì=0,óç=0,óô=ïë:
óåîä: 2-2-0-0 ó=3,ã=0,ô=1,ðô=0,ì=0,óç=0,óô=ïë:
óåîä: 2-2-0-0 ó=4,ã=0,ô=16,ðô=0,ì=0,óç=0,óô=ïë:
éóÍåôòéã: 0
ÔåíðÄéææ :174.85
ÈõíÄéææ  :154.00
Ô: 74.85
È: 54
óåîä: 2-2-0-0 ó=1,ã=1,ô=0,ðô=7,ì=5,óç=0,óô=ïë:74.8
óåîä: 2-2-0-0 ó=2,ã=1,ô=1,ðô=2,ì=2,óç=0,óô=ïë:54
óåîä: 2-2-0-0 ó=255,ã=3,ô=0,ðô=1,ì=1,óç=0,óô=ïë:97
ÏÔÁ Æ× õðäáôå åîáâìåä
óåîä: 2-2-0-0 ó=4,ã=1,ô=23,ðô=2,ì=2,óç=0,óô=ïë:99
Ìéçèô: 99
ÔåíðÄéææ :0.01
ˆõíÄéææ  :0.00
Ìéçèô: 99

[tbowmo]

@mvader

What baudrate are you using? It seems like it's to much off, for the ftdi to decode it correctly. Have you tried to lower it to, let's say 9600 baud? And does it still do this?

[mvader]

@tbowmo said:

@mvader

What baudrate are you using? It seems like it's to much off, for the ftdi to decode it correctly. Have you tried to lower it to, let's say 9600 baud? And does it still do this?

Serial.begin(115200);
I have not tried 9600, but i've done 5 today all the same code.. no problems.
i have 4 others deployed from when i first bought these (when they came out) same code for them as well..
could be a bum board..idk. when i fired it up, i could see it in the controller software though. so it does seem to work. it just gives me that in the serial monitor.. strange for sure I'll let you know how 9600 works out.

[Anticimex]

@mvader what baffles me is that numbers seem to encode ok but alphabetical characters do not. You don't use some exotic ascii encoding in your terminal? (not likely if you can switch to a different SenseBender and get sane output I suppose)

[tbowmo]

@mvader

115200 is on the edge of what is possible with the 8Mhz that the sensebender is using. And it's a uncalibrated RC oscillator that's in use. So this one might be a bit off to the lower side (run 7.5Mhz for example) which could throw off your serial port a bit.

(But as @Anticimex mentions, it does look weird that the numbers are readable..)

[Anticimex]

@tbowmo @mvader it can still be a timing problem. Numbers in the ascii table have the most significant bits zero (they are in the range 0x3x and below) and since regular UART protocols transmit lsb first, the first bits may be within legal timing while the later bits are not, so the higher the ascii value, the higher the risk for corruption.

[FotoFieber]

Playing with 2.0 I wanted to upgrade my sensebenders but I didn't find the sketch (neither in the main distribution nor in the examples folder).

Is there a version 2.0 compatible sketch?

[hek]

Yep, it was moved to the Sensebender repo during the 2.0 release:

https://github.com/mysensors/SensebenderMicro/blob/master/Arduino/SensebenderMicro/SensebenderMicro.ino

[Anticimex]

@FotoFieber it is low located in the SenseBender repo in GitHub

[FotoFieber]

@Anticimex
Thx. This is an old version. I found a newer on my hard drive (old development branch). As I do only need temp/hum, I reduced the sketch and it is working fine.

[Anticimex]

@FotoFieber @tbowmo isn't the one in the SenseBender repo supposed to be the latest&greatest?

[tbowmo]

@Anticimex @FotoFieber

Yup, it was moved over from development branch on the release night. So should be the latest and greatest

[jovo]

Hi!
I am in process of upgrading my Sensebenders to V2.0 and like to enable the OTA function.

Who can give me some pointers on the capabilities of OTA for this Sensebender Micro board?
I know that has external flash for this purpose, but i am stuggling a bit finding how to use it.
So I am keen to read information on dependencies of the Sensebender sketch as well as the controller options.
My environment:
6x Sensebender
Wifi based Gateway
Domoticz as controller

Things I like to know:

• Is my sensebender shipped with optiboot bootloader? (have them about 1 year now)?
• do i require special Gateway software? (i noticed a sketch called something like GatewayESP8266OTA)
• what can i expect from Domoticz? probably not much, so do i need to connect to another controller (e.g. MYSController) to perform an update?
• What controller is advised for the standard bootloader (optiboot bootloader)?

I am sure those things are discussed in the past, but I was unable to find it.
Would be great if somebody can share a howto or wiki on this topic.

thanks in advance

[tbowmo]

@jovo

Sensebender is delivered with "DualOptiboot" which uses the external flash.

To enable OTA with 2.0.0, you have to compile your sketches with

#define MY_OTA_FIRMWARE_FEATURE

enabled. For controller / Gateway, you need something else than domoticz. I haven't tried OTA firmware upgrades myself yet, so I do not have any experience with what works, and what doesn't work, other than the fact that domoticz doesn't support OTA..

[TheoL]

Today I soldered the headers to a new sensebender and try to start it. I've uploaded the 2.0 example but it can't find the gateway:

Started
Starting sensor (RNONA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT

My other sense benders worked flawelessly. But this one can't communicate. Does anyone have any idea, what might be wrong?

[alexsh1]

@TheoL I have exactly the same issue with one of the nodes though not the sensebender.
All other nodes work just fine.
Take a look:

https://forum.mysensors.org/topic/4723/tsp-chkupl-fail

[Qu3Uk]

@TheoL I had this problem last night, its unable to find the parent/gateway. I ended up swapping out the radio with one I'd extended the antenna on and it worked. I then attached a piece of wire to the original radio and that was worked too. I put it down to knock off components.

I think there is a video detailing the correct length etc.

[TheoL]

Solved. I had forgotten to config the correct baudrate. My network is on one 1 mbyte, because of the mixed NRF24L01 and NRF24L01+ radios.

[stefaanv]

I get "not in sync" errors from avrdude if I try uploading a sketch to the sensorbender.
I do have correct serial communication, when I open the serial monitor, I get the info from the default sketch (which unfortunately uses the 1.4.1 API).
I tried with a different SenseBender board, same result. Tried with an older IDE version (1.6.9) on an other computer, same result.
Any suggestions ?

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x2d
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x4f
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x6e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x6c
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x69
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x6e
An error occurred while uploading the sketch
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x65
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x21

[alexsh1]

@stefaanv sounds like you have a wrong board in Arduino. Did you install the correct board in Arduino IDE? I'm programming the Sensebender in 1.6.9 via the FTDI adapter without any difficulties

[stefaanv]

@alexsh1 I'm using the Uno board. Which one should I use ? Can't find anything in the SenseBender page.

[alexsh1]

@stefaanv well, that's the problem - you must install Sensebender Micro (or I think you can use Arduino Pro Mini 3.3V) board. You MUST NOT provide more than 3.3V otherwise you may damage the board or radio. Please double check

Please refer to this link below to install the correct board in Arduino:

https://github.com/mysensors/ArduinoBoards

[stefaanv]

@alexsh1 Thanks, got it working now.

[jovo]

Is there anybody who can comment if the battery usage is increased in V2.0?

I feel that my batteries are draining faster then with 1.4 I had installed before.

Also I am seeing issues with the Force Retransmit. I dont see this working either. it just transmits when Transmit_Treshhold is kicked.

My sketch is pretty default. As far as I can see, I only turned Batt_Sensor on.

[mvader]

@jovo what is your usage? I'm getting 8+ months easily
I have a sensor in my deep freeze, been there for 8+ months and still working fine.

[jovo]

@mvader Hi,
I guess you are not for 8 months on v2?
I had a long time on the previous version as well.
Haven't done the measurements, but I noticed my batteries were depleted quickly since v2 was on.
I am more concerned about the fact that the force transmission doesn't seem to be working.

[alexsh1]

@jovo how exactly do you define "quicker" please? I do not think anyone had enough time to test it. My batteries dropped 0.2V for 2 months (reporting temp/humidity/pressure every minute) but that does not mean anything at all. I would need to run it for another 6 months at least to say what I think.

[Mitja Blazinsek]

i have some problems with sensbender micro it all work fine it shows temp and hum in mycontroller bu then i try to program the board to test my FTDI programmer, for test i was try to upload default sketch but since then it showing me only node in mycontroller without any sensors

this is my log from debug:

0 MCO:BGN:INIT NODE,CP=RNONA--,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:SID:OK,ID=5
16 TSM:FPAR
53 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2062 !TSM:FPAR:NO REPLY
2064 TSM:FPAR
2101 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4110 !TSM:FPAR:NO REPLY
4112 TSM:FPAR
4149 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6158 !TSM:FPAR:NO REPLY
6160 TSM:FPAR
6197 TSF:MSG:SEND,5-5-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8206 !TSM:FPAR:FAIL
8208 TSM:FAIL:CNT=1
8210 TSM:FAIL:PDT
18214 TSM:FAIL:RE-INIT
18216 TSM:INIT
18225 TSM:INIT:TSP OK
18227 TSF:SID:OK,ID=5
18229 TSM:FPAR

[gohan]

That looks like there is no communication with gateway. Did you check gw log? You could also update mysensors to latest 2.2

[Mitja Blazinsek]

but before it was working im using sensebender gateway and i see node in controler, i update my sensors and still nothing

[Mitja Blazinsek]

OK i found the problem i just needed to clear the eeprom and it works i remembered that i had this problem before with binary switch sample

[Mitja Blazinsek]

sory still not workinkg i was thinking that i solve the problem but i didn't now i was try to connect other sensebender micro and it's working with no problem and i noticed that the red led flash on micro when i connect power i dont se that led on previous not working micro is it possible that i burn micro when programming, bu ti upload program with no problems i also had 3,3V jumper on the programer

[gohan]

You could try with a basic blink sketch and see if you can blink an led

[Mitja Blazinsek]

nothing happened just upload blink code but no blinking

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}```

[gohan]

have you tried another led?

[Mitja Blazinsek]

it work when i try button example, had no diode at the hand

[gohan]

maybe the led on the sensebender is broken... at least you figured it still works

[tbowmo]

@mitja-blazinsek

Try toggling A2 instead og BUILTIN_LED. Or try the default Sensebender Micro sketch, found here.

With the default sketch loaded, you could try holding A0 low, while applying power to the Sensebender Micro, this will start a selftest routine, blinking the LED at the end.

[Mitja Blazinsek]

can anyone help me every sensor it work fine first time in mycontroler but but when i reprogram it with same code it doesn't register anymore in my controller like i remember i have this same problem about year ago with binary switch bu i can't remember what was solution for problem that why sensebender micro doesn't work i just try hum. sensor with nano working fine after reprogram with same code my controller doesn't recognize anymore do i have clear anything in my controller i already try to delete node and sensor but no affect

[gohan]

Do you see correct communication on node and gw logs?

[Mitja Blazinsek]

16 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
25 TSM:INIT
26 TSF:WUR:MS=0
33 TSM:INIT:TSP OK
35 TSM:INIT:STATID=15
37 TSF:SID:OK,ID=15
39 TSM:FPAR
75 TSF:MSG:SEND,15-15-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2082 !TSM:FPAR:NO REPLY
2084 TSM:FPAR

[gohan]

@mitja-blazinsek said in Sensebender Micro:

2082 !TSM:FPAR:NO REPLY

That's clearly a communication problem, look at the gateway what do you see

[Mitja Blazinsek]

Jan 30, 2018 04:46:45 PM	Notice	Node	 mysensors   0	Received	Internal	[Log message] TSF:MSG:GWL OK
Jan 30, 2018 04:46:45 PM	Notice	Node	 mysensors   0	Received	Internal	[Log message] TSF:CKU:OK,FCTRL
Jan 30, 2018 04:46:45 PM	Notice	Node	 mysensors   0	Received	Internal	[Log message] TSF:MSG:FPAR REQ,ID=15
Jan 30, 2018 04:46:45 PM	Notice	Node	 mysensors   0	Received	Internal	[Log message] TSF:MSG:BC
Jan 30, 2018 04:46:45 PM	Notice	Node	 mysensors   0	Received	Internal	[Log message] TSF:MSG:READ,15-15-255,s=255,c=3,t=7,pt=0,l=0,sg=0:

[Mitja Blazinsek]

why mycontroller don't register node and sensor if he receive message

[gohan]

@mitja-blazinsek I think there must be something else in the gateway log, please add more entries