Serial gateway running on coin cells. Needs to sleep
-
Hi, I have a pair of these (https://www.tindie.com/products/easysensors/button-sized-lora-rfm95rfm69-wireless-node-ver-3/) running on coin cells. I've confirmed with my currentRanger that the node goes to sleep and uses very little power. I just use the gateway device to talk to the node. The gateway has a small OLED screen to show the values from the node. The node only transmits every 20seconds so I want the gateway to sleep to reduce it's power usage. I'm surprised that I cant find how to do this by searching mysensors.
I see 20mA of power usage on the gateway - I assume this is the radio drawing power. Calling sleep(19000) doesn't reduce the power. I assume the radio is still on.
Is there a way to do this?
Is there an example with a serial gateway that sleeps?Any help is greatly appreciated,
-Jason
-
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.
-
@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 0My 'gateway' has this
#define MY_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC
#define MY_PARENT_NODE_ID 6I 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
-
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.
-
@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.
-
@scalz from my understanding, OP only has these 2 nodes and no controller.
-
@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
-
@scalz yes. Not a ”normal” MySensors use case.
-
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 }
-
@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.
-
@mfalkvidd Yes I wondered if that was the case. OK will need to reprogram the node .
-
@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.
-
@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
-
@scalz I appreciate what you are saying. It was just a suggestion for an implementation since I will need something akin to this.
-
@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.
-
@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.
-
@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
-
@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 said in Serial gateway running on coin cells. Needs to sleep:
capa buffering,
What is capa buffering? Google is not helping me
-
@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
-
@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.
-
@Jason-Rennie
sure, but you didn't mention the whole thing, I also prefer subghz
cr2032 is limited, so without extras capacitors = possible brownouts + you won't get full lifetime because of its internal resistance (when power consumption >5ma generally) . even a short burst can reset your mcu (brownout)
like 100-300uf to handle H version of rfm modules, I usually place a few close to batt and rf module
also forget bad coincell brands, not good at all for lifetime.
for a commercial product, I wouldn't recommend to remove brownout protection, nor watchdog too, for saving power.I didn't know about listenmode. when I tried it worked, but this was experimental, never used it in prod.
-> custom fw with rtc and sync. simple
-
@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:
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.
