@mfalkvidd Hi, that's a great suggestion. I've just tried it but I think it's now failing to get into loop().

My 'node' has this

#define MY_NODE_ID 6
#define MY_PARENT_NODE_IS_STATIC
#define MY_PARENT_NODE_ID 0

My 'gateway' has this
#define MY_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC
#define MY_PARENT_NODE_ID 6

I also tried adding a call to sendSketchInfo() to presentation(). Using identical parameters as the node. But it still fails to go into loop().

Here is my log

13:20:10.978 ->  
13:20:10.978 ->  __  __       ____
13:20:10.978 -> |  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
13:20:11.013 -> | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
13:20:11.013 -> | |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
13:20:11.013 -> |_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
13:20:11.047 ->         |___/                      2.3.2
13:20:11.047 -> 
13:20:11.047 -> 51 MCO:BGN:INIT NODE,CP=RRNNA---,FQ=8,REL=255,VER=2.3.2
13:20:11.082 -> 83 TSM:INIT
13:20:11.082 -> 86 TSF:WUR:MS=0
13:20:11.082 -> 92 TSM:INIT:TSP OK
13:20:11.082 -> 98 TSM:INIT:STATID=0
13:20:11.082 -> 102 !TSF:SID:FAIL,ID=0
13:20:11.082 -> 108 TSM:FAIL:CNT=1
13:20:11.116 -> 114 TSM:FAIL:DIS
13:20:11.116 -> 118 TSF:TDI:TSL
13:20:21.295 -> 10123 TSM:FAIL:RE-INIT
13:20:21.295 -> 10129 TSM:INIT
13:20:21.295 -> 10135 TSM:INIT:TSP OK
13:20:21.295 -> 10141 TSM:INIT:STATID=0
13:20:21.295 -> 10147 !TSF:SID:FAIL,ID=0
13:20:21.330 -> 10153 TSM:FAIL:CNT=2
13:20:21.330 -> 10160 TSM:FAIL:DIS
13:20:21.330 -> 10166 TSF:TDI:TSL
13:20:31.516 -> 20172 TSM:FAIL:RE-INIT
13:20:31.516 -> 20178 TSM:INIT
13:20:31.551 -> 20185 TSM:INIT:TSP OK
13:20:31.551 -> 20191 TSM:INIT:STATID=0
13:20:31.551 -> 20197 !TSF:SID:FAIL,ID=0
13:20:31.551 -> 20203 TSM:FAIL:CNT=3
13:20:31.551 -> 20209 TSM:FAIL:DIS
13:20:31.551 -> 20215 TSF:TDI:TSL
13:20:41.744 -> 30220 TSM:FAIL:RE-INIT
13:20:41.744 -> 30226 TSM:INIT
13:20:41.778 -> 30232 TSM:INIT:TSP OK
13:20:41.778 -> 30238 TSM:INIT:STATID=0
13:20:41.778 -> 30244 !TSF:SID:FAIL,ID=0
13:20:41.778 -> 30251 TSM:FAIL:CNT=4
13:20:41.778 -> 30257 TSM:FAIL:DIS
13:20:41.778 -> 30263 TSF:TDI:TSL
13:20:51.974 -> 40269 TSM:FAIL:RE-INIT
13:20:51.974 -> 40275 TSM:INIT
13:20:52.010 -> 40282 TSM:INIT:TSP OK
13:20:52.010 -> 40288 TSM:INIT:STATID=0
13:20:52.010 -> 40294 !TSF:SID:FAIL,ID=0
13:20:52.044 -> 40300 TSM:FAIL:CNT=5
13:20:52.044 -> 40306 TSM:FAIL:DIS
13:20:52.044 -> 40312 TSF:TDI:TSL
13:21:02.227 -> 50317 TSM:FAIL:RE-INIT
13:21:02.227 -> 50323 TSM:INIT
13:21:02.227 -> 50329 TSM:INIT:TSP OK
13:21:02.227 -> 50335 TSM:INIT:STATID=0
13:21:02.227 -> 50341 !TSF:SID:FAIL,ID=0
13:21:02.261 -> 50348 TSM:FAIL:CNT=6
13:21:02.261 -> 50354 TSM:FAIL:DIS
13:21:02.261 -> 50360 TSF:TDI:TSL
13:21:12.436 -> 60366 TSM:FAIL:RE-INIT
13:21:12.436 -> 60372 TSM:INIT
13:21:12.471 -> 60379 TSM:INIT:TSP OK
13:21:12.471 -> 60385 TSM:INIT:STATID=0
13:21:12.471 -> 60391 !TSF:SID:FAIL,ID=0
13:21:12.471 -> 60397 TSM:FAIL:CNT=7
13:21:12.471 -> 60403 TSM:FAIL:DIS
13:21:12.471 -> 60409 TSF:TDI:TSL
13:22:13.601 -> 120414 TSM:FAIL:RE-INIT
13:22:13.601 -> 120420 TSM:INIT
13:22:13.635 -> 120426 TSM:INIT:TSP OK
13:22:13.635 -> 120432 TSM:INIT:STATID=0
13:22:13.635 -> 120438 !TSF:SID:FAIL,ID=0
13:22:13.635 -> 120446 TSM:FAIL:CNT=7
13:22:13.635 -> 120453 TSM:FAIL:DIS
13:22:13.635 -> 120459 TSF:TDI:TSL

@scalz said in Serial gateway running on coin cells. Needs to sleep:

also forget bad coincell brands, not good at all for lifetime.

This is my biggest concern at the moment. With the watch device I can resort to Lipo and recharge if needed, but the sender is best encased in silicone to protect it so its crucial that I get a long reliable battery life from it. My only option there is to use inductive charging. Which might be easy but I've not looked at the details.

I would also need to do shipping safety sheets if I use lipo but I think that it's probably just an expense. Not a project risk.

@mfalkvidd Yes, I need the right capacitors. I'm now designing boards for the watch and sender device using KiCAD based on moteino and easysensors but with a few differences.

@scalz said in Serial gateway running on coin cells. Needs to sleep:

rfm69 listenmode from lowpowerlab,

listenmode. Interesting....

Unfortunately I found this comment (and linked discussion) here

https://github.com/LowPowerLab/RFM69/blob/master/RFM69.h

//Native hardware ListenMode is experimental
//It was determined to be buggy and unreliable, see https://lowpowerlab.com/forum/low-power-techniques/ultra-low-power-listening-mode-for-battery-nodes/msg20261/#msg20261
//uncomment to try ListenMode, adds ~1K to compiled size
//FYI - 10bit addressing is not supported in ListenMode
//#define RF69_LISTENMODE_ENABLE

@scalz said in Serial gateway running on coin cells. Needs to sleep:

capa buffering,

What is capa buffering? Google is not helping me

@scalz I tried BLE first but the sender is in close body contact and the signal from an NRF52840 was almost completely absorbed by the body. They claim upto 800m range but the truth is that indoors the range is miserable. In close body contact the range was barely 1m or zero depending on how much body it passes through. Bluetooth depends on walls to reflect signals so this is even worse outdoors.

To extend the range I made an android app that could also act as a gateway to send the live signals over wifi or mobile to Google Cloud Firestore. So any other instances of the app could see the live values. But Android and iOS are so determined to reduce battery usage that they make it very hard to maintain a Bluetooth connection. The ble connection timeout for iOS is 4 seconds for instance. Its also difficult to keep long running background tasks because the OS will stop them, it's also difficult to guarantee that Bluetooth scans are performed to reestablish connections. The whole thing would require a ton of coding to maintain.

This is why I chose the RFM69HCW.

@scalz Its a watch sized receiver taking signals from a transmitter.

The transmitter is sealed in a protective silicone blob and the watch is preferably coin cell powered to avoid the need for a MSDS/SDS for shipping lithium batteries. The whole thing needs to pass FCC for sale in the US and it has to meet EU RED regulations to sell in Europe.

The transmitter only needs to send a signal to assure the watch that it is in range. Once every 2 minutes is fine. It should send an alert signal when an alert condition is detected by it's sensors.

There's normally only 1 or maybe 2 senders and 1 or maybe 2 receivers.

@scalz I appreciate what you are saying. It was just a suggestion for an implementation since I will need something akin to this.

@mfalkvidd I think both sides are attempting to ping node 0 and not getting a response. So they never get into loop()

I think I will give the lowpowerlab library a try. I've also found that I am running low on resources (RAM + program space).

I think it would be better if the mysensors gateways could establish a time schedule with their nodes to allow both sides to sleep.

Something like this... If nodes only need to talk once every minute and I have 10 nodes, then the gateway can tell each node when they should transmit. So once every minute the gateway wakes up and listens for each node to talk. 10 nodes require 10 time windows, one after another. Node 1 talks in the first time window. The 5th node wakes up and talks in the 5th time window. I hope you see what I am suggesting. This way the nodes are not trying to talk over each other and the gateway is asleep for almost the whole time window. If you want to support n retries on transmissions then the gateway needs to listen for up-to n retry attempts. Or until it has heard from all nodes.

This is overkill for me because my system has only 1 node. But its something you might find easy to implement. I'm not sure how your system is structured.

@mfalkvidd Yes I wondered if that was the case. OK will need to reprogram the node .

I like the fact that the mysensors network would extent it's range with relays. It was also the example that came with my boards.

I don't think my last message was understood. I changed the code that runs on my gateway device by commenting out MY_GATEWAY_SERIAL.

The Mysensors config looks like this

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM69

#define MY_BAUD_RATE 38400
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW 
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_RFM69_MAX_POWER_LEVEL_DBM 20
#define MY_RFM69_MODEM_CONFIGURATION RFM69_FSK_BR2_FD5

//#define MY_GATEWAY_SERIAL
//#define   MY_SIGNAL_REPORT_ENABLED
#define MY_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC
#define MY_PARENT_NODE_ID 6

//#define MY_RFM69_NETWORKID 23    //Not necessary I think
//#define MY_RFM69_NEW_DRIVER        //Not better
//#define MY_RFM69_ATC_MODE_DISABLED   //Not sure what this is
//#define MY_RFM69_TX_POWER_DBM 20     //Already setting MY_RFM69_MAX_POWER_LEVEL_DBM 20
//#define MY_DEBUG_VERBOSE_GATEWAY    //Not a gateway
//#define MY_DEFAULT_RX_LED_PIN 6          //Don't flash the LED

#include <MySensors.h>

void presentation()
{
    // Send the sketch version information to the gateway and Controller
  sendSketchInfo("ButtonSize node", "3.0");      // Same as node is using

  // Register all sensors to gw (they will be created as child devices)
  //present(5, S_CUSTOM);                  /// tried adding this since I assume nodes need to present something, but it makes no difference

    // Gateway has no sensors to report
}