Serial gateway running on coin cells. Needs to sleep

mfalkvidd

Welcome to the MySensors forum @Jason-Rennie !

There is not a way for the gateway to sleep. In most MySensors networks, there are multiple nodes that can transmit at any time, which makes sleeping the gateway infeasible.

I think it is possible to configure both devices as nodes, with hard-coded parents and skip the gateway entirely. I haven't seen anyone doing this, but searching for MY_PARENT_NODE_ID and MY_PARENT_NODE_IS_STATIC should give some ideas. Documentation reference: https://www.mysensors.org/apidocs/group__RoutingNodeSettingGrpPub.html#ga9c5cf01ba680a4f4b2d79652d80c74f4

Or create a gateway that always has power.

Jason Rennie

@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

mfalkvidd

A gateway always has id 0. Not sure how a gateway would react to having a static id set, but maybe it will react the way yours is reacting. Or maybe a gateway does not have a parent, so it gets confused when you set MY_PARENT_NODE_ID.

Try making the 'gateway' a regular node instead, for example with node id 7. Let both nodes have the other node as static parent.

The log parser can be useful when interpreting the logs.

scalz

@Jason-Rennie how would you control your network from says a controller, if serial gw is sleeping? as to get power consumption down, you also need to shutdown serial hw peripheral in mcu.

mfalkvidd

@scalz from my understanding, OP only has these 2 nodes and no controller.

scalz

@mfalkvidd yes, hard to imagine exactly what he wants to achieve (he asked for a sleeping gw). else it's just peer2peer/node2node comm, a few people used it in the forum if I remember.

else maybe it could be easier, just using a more "simple" lib for this simple case, like radiohead etc for example

mfalkvidd

@scalz yes. Not a ”normal” MySensors use case.

Jason Rennie

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
}

mfalkvidd

@Jason-Rennie I see. Thanks for explaining.

Id 0 is reserved for the gateway. Therefore any node will refuse to initialize if the node has id 0.

From the log parser: Assigned id 0 is invalid

Use a different id.

Jason Rennie

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

Jason Rennie

@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.

scalz

@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:

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

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.

I started to take a look at this a while ago (I wanted to try freq hop etc), but it was just tests and unfinished work, too busy to get back on this even if it's very interesting and challenge to do.. I think you don't get the implications of this. Of course it's "easy" to imagine timeslots :)

for a few nodes, it's not really hard, but for a whole network there are lot of things to take care.

hardware: this needs precise clock on all devices. That's something most of MySensors users do not have, for example some use unprecise internal rtc (just an example about hw). If no precise clock, then when using lot of nodes, there will be drift in time, packets collision etc and packet delivery will become unreliable, unresponsive network.
software. retrocompatibility is just another example. also using a better mcu (than 328p) + rtos can help managing stuff.
etc

without retrocompatibility in mind, and by starting from scratch, it's for sure "easier" but you might hit some rocks as network grows. And, still, you will need to sync your nodes, even more important if not using a precise clock, as the wider the listening timeslot is, the more energy you'll use.

MySensors archi is gw/concentrator always ON (like many others commercial stacks though), only ONE channel communication, where availability of channel is checked with CSMA+random time+retries for preventing collisions.

there are lot of researchs about different methods like TDMA etc on internet, you'll see it's not that easy if you want more than just a few nodes ;)

Jason Rennie

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

scalz

@Jason-Rennie maybe if you give us more info on your usecase/project archi, we could help you. I think a sleeping gw is not very common.

Jason Rennie

@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

@Jason-Rennie unfortunately as you guessed MySensors is not really tailored for this task, so
as you don't have lot of nodes involved, perhaps it's easier to start your sw from scratch with a more simple lib+rtc, or some true mesh framework with low power capabilities if there is one available (MySensors is star network).
I guess BLE 5 long range+beacon doesn't fit your project??
imho, I think I would do my own sw, if it's just for 2-3 nodes, and sync them, perhaps easier for sw maintenance. For MySensors, we need to take care of a lot more usecases..
Long time ago, I tested rfm69 listenmode from lowpowerlab, maybe it can help you getting started.
cr2032 can be tricky, don't forget capa buffering, but that's another topic :)

Jason Rennie

@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.

Jason Rennie

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

capa buffering,

What is capa buffering? Google is not helping me

Jason Rennie

@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

mfalkvidd

@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:

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

capa buffering,

What is capa buffering? Google is not helping me

I think he means adding capacitor(s). Cr2032 will not be able to deliver its rated capacity if more than a few mA is drawn. See https://electronics.stackexchange.com/questions/234901/lithium-coin-cell-cr2032-battery-specifications for one data point.

Serial gateway running on coin cells. Needs to sleep

19

11.7k

11.2k

113.1k