A temperature sensor in my boys' room went missing this morning when my wife gathered up the bed sheets to launder. I hadn't printed a case for it and mounted it anywhere and had it on the bed out of the way. It should have been hard to get tangled up in the sheets.
I noticed it was missing from its perch and was looking around for it but not too hard as I was working.
And hour or so later I walked passed one of the panels in the house that displays information and noticed the temperature for that room had increased to over 100 Fahrenheit which immediately confirmed my suspicion about where it went.

It went through the wash cycle and on to dry (combination machine) and survived the whole thing

Some pictures of an assembled unit with 3d printed case

@ncollins

throw this somewhere in your code:

void reboot() {
  wdt_disable();
  wdt_enable(WDTO_15MS);
  while (1) {}
}

and then calling the reboot (in the entire loop):

void loop() {

  if (motion_change) {
    motionDetected=!motionDetected;
    if (motionDetected) {
      send(msg.set("1"));  // motion detected
    }
    else {
      digitalWrite(LED_BUILTIN,LOW);  //turn-off LED to signify motion no longer detected
      send(msg.set("0"));  // send all-clear to prepare for future detections
    }    
    
    NRF_LPCOMP->EVENTS_CROSS=0;
    motion_change=false;
  }
  else { //must be a scheduled wake-up.  Time to report voltage as a heartbeat.
    batteryVoltage=((float)hwCPUVoltage())/1000.0;  //take voltage measurement after transmission to hopefully measure lowest voltage that occurs. 
    send(msg_S_MULTIMETER_V_VOLTAGE.set(batteryVoltage,3));  //send battery voltage with 3 decimal places
    time = millis();
    if (time > 14400000 ) {
      reboot();
    }
  }
  mySleep(1200000);  //sleep for 20 minutes
}```

@Yveaux this has resolved it, thank you

I had seemingly unending problems getting sensors to be reliable and about gave up until i switched to ebyte modules.

Since redesigning boards to use their slightly different pinout and moving to their modules I haven't had any issues. A complete turnaround from what i was experiencing before - highly recommended.

try another radio? My gateway is a Pi Zero W and works fine so there's no reason it shouldn't work for you.

irq=18 worked for me for anyone who comes along wondering

@scalz
Thanks for the link to the 3.3v USBASP mod!
i have been pulling my hair out trying to get bare 328p chips programmed using a generic ASP

thank you!!!

my pi3b does this as well. it's far and few in between. I even made a watchdog in openhab to "ping" the msgw (requesting an ack) and mysgw responds but it doesn't send out new sensor readings. i thought about expanding the watchdog to watch for all sensor readings and throw up a restart to the gw if it receives no readings in a 10 minute period but mine doesn't fail nearly as consistently as yours so I haven't worried about it too much...

would still like to see a resolution to this as I've moved most of my PIRs and temp sensors to mysgw so when it goes down it can be a bit of a problem.

It's looking more and more like the code is fine and its the sensors i'm using that are the problem.

I got some BM612 (cheaper) from ali supposedly the same as am612 but they don't seem to work right. It's like they trigger once and then never again. Can't find a data sheet for them...

I hooked up a 312 just for kicks and it seems to be working. I doubt I'll deploy any 312s due to what seems to be a VERY narrow range and plus it doesn't match the profile of the round board etc...

Anyway, wanted to say that i think this is all working as its supposed to I just got a bad batch of sensors or they're slightly different in some way

@skywatch
hah, tell me about it. it went through battery and all. Still dutifully reporting every 3 minutes.

A temperature sensor in my boys' room went missing this morning when my wife gathered up the bed sheets to launder. I hadn't printed a case for it and mounted it anywhere and had it on the bed out of the way. It should have been hard to get tangled up in the sheets.
I noticed it was missing from its perch and was looking around for it but not too hard as I was working.
And hour or so later I walked passed one of the panels in the house that displays information and noticed the temperature for that room had increased to over 100 Fahrenheit which immediately confirmed my suspicion about where it went.

It went through the wash cycle and on to dry (combination machine) and survived the whole thing

@haasje30 if it's mqtt both can subscribe at the same time

@haasje30
smartsleep is easy with MQTT

Initially a few years ago i tried the binding and it gave me nothing but trouble.
While it was configured I'd watch MQTT to see what it would do.

2020-12-31 22:58:22 unoout/202/255/3/0/33 180000 (THIS IS THE SLEEP DURATION)
2020-12-31 22:58:22 unoout/202/255/3/0/32 500 (AT THIS MOMENT YOU HAVE 500MS to GET A COMMAND SENT)

So define a thing to the channel ending in 32.
Bind an item to that channel with an expire timer for like 10 seconds state = 0

then for your rule you'd have

rule "whatever"
when
Item whateverSleepItem changed from 0 to 500
then
whateverOtherItemThatIsSendingOutACommand.sendCommand(ON/OFF/WHATEVER)
end

@Didou @evb
I download the dev version AND replaced the two files with the ones from the proposed fix.

I think that's the right path - it seems to be showing positive results.

@ncollins
Seems to be working well on NRF51, not so much on NRF52. I backed off the changes for NRF52 modules and they're working ok with latest alpha. I think I need a better sketch for them...

Anyway, NRF51822 is doing much much better.

@Didou follow the links posted by @ncollins

The first big dip on 11/29 was a deadlock. I tried some change after that that still didn't work and lead to another deadlock on 12/7. Using the fix from github you can see how much more stable battery reporting has been since 12/9 (small spike when it was plugged in for programming) when i flashed it using the fixed code. This one might finally be fixed.

@Omemanti
If you're experiencing this issue I'd certainly try 1. I don't know that I'd got hog wild just yet unless they're easy to get to and easy to hook up.

@ncollins
yep!
while its only a few days I'm not seeing those dips that you can notice prior to the big drop. might be nothing, might be something. who know!

I also had a lot of problems before finally switching to (cd)ebyte modules. After moving to ebyte modules for the gateway and nodes my problems have all but vanished. good luck.

@ncollins 1455 is the latest and greatest
https://github.com/mysensors/MySensors/pull/1455
d00616 replied to use it.

6 days on no dip (yet)

edit i guess its 3 days since the spike (plugged in) was on 12/10

d00616 created this issue in mysensors/MySensors

closed NRF5 ESB redesign #1455