@Yveaux thanks for your answer.

I used the sketch on the Mysensors'si7021 page, so the vcc level is read at the end of the loop, before going to sleep and after sending the temp/hum values.
The only modification I made are setting up the voltage values.
As my 3.7V Li-Ion battery is at 4.2V when fully charged and at 3V when almost completed discharged, this how I configured it in the sketch:

#ifdef REPORT_BATTERY_LEVEL
#include <Vcc.h>
static uint8_t oldBatteryPcnt = 200;  // Initialize to 200 to assure first time value will be sent.
const float VccMin        = 3.0;      // Minimum expected Vcc level, in Volts: Brownout at 1.8V    -> 0%
const float VccMax        = 4.2;  // Maximum expected Vcc level, in Volts: 2xAA fresh Alkaline -> 100%
const float VccCorrection = 1.0;      // Measured Vcc by multimeter divided by reported Vcc
static Vcc vcc(VccCorrection); 
#endif

I didn't apply any correction because read and reported VCC was very close, and I'm just testing this for now.

I didn't removed the onboard regulator nor the power led for now. Isn't the regulator only used when applying voltage to the RAW pin?

@mfalkvidd I thought of this too, but I opened the windows this morning, 11°C here this morning, and the battery level stayed around 50%.

Here are some graphs showing it's not temperature related:

Even with the 0.1uF capacitor, I had wrong values.
So, I've gone with the voltage divider method, and it seems more reliable, at least for my case.
4.7V max to VCC, R1 1M, R2 330k, another 0.1uF capacitor in parallel with R2.
I don't need a very good accuracy, just a trend in order to know when to change my batteries.
Thanks for your help.

I reply to myself, I succeeded to make it work.
The \n was missing in the payload before sending it back to the gateway.
This took me months to see this...

Works like a charm now, I just need to implement the inclusion feature in NodeRED.

Hi,

The myscontroller node does not seem to assign IDs.
Only nodes with a defined MY_NODE_ID work.
MY_INCLUSION_MODE_FEATURE is enabled on the gateway.
Pressing the button does not change the behavior (I see taht the inclusion mode is enabled when I press the button, and resets after 60s)

When I omit the MY_NODE_ID in my sketch, the node keeps asking for a node id several times.
On the NodeRED side, I connected a debug msg node at the output of the myscontroller node.
The debug shows that a different ID is tried but the sqlite base is not populated and the asking node does not receive the ID.
Do I need to connect the myscontroller output to the input of the gateway to send a message back to the node?

Here is the node debug messages:

16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=16,REL=255,VER=2.3.2
26 TSM:INIT
28 TSF:WUR:MS=0
34 TSM:INIT:TSP OK
36 TSM:FPAR
38 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2048 !TSM:FPAR:NO REPLY
2050 TSM:FPAR
2052 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4060 !TSM:FPAR:NO REPLY
4062 TSM:FPAR
4064 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6072 !TSM:FPAR:NO REPLY
6074 TSM:FPAR
6076 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8084 !TSM:FPAR:FAIL
8085 TSM:FAIL:CNT=1
8087 TSM:FAIL:DIS  
8089 TSF:TDI:TSL   
18091 TSM:FAIL:RE-INIT
18093 TSM:INIT        
18099 TSM:INIT:TSP OK
18101 TSM:FPAR
18104 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
18848 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
18853 TSF:MSG:FPAR OK,ID=0,D=1
20112 TSM:FPAR:OK
20113 TSM:ID
20115 TSM:ID:REQ
20117 TSF:MSG:SEND,255-255-0-0,s=147,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
22125 TSM:ID
22126 TSM:ID:REQ
22129 TSF:MSG:SEND,255-255-0-0,s=110,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
24136 TSM:ID
24137 TSM:ID:REQ
24140 TSF:MSG:SEND,255-255-0-0,s=73,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
26147 TSM:ID    
26148 TSM:ID:REQ
26151 TSF:MSG:SEND,255-255-0-0,s=36,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
28160 !TSM:ID:FAIL
28161 TSM:FAIL:CNT=2
28163 TSM:FAIL:DIS
28165 TSF:TDI:TSL
38168 TSM:FAIL:RE-INIT
38170 TSM:INIT
38176 TSM:INIT:TSP OK
38178 TSM:FPAR
38181 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
38538 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
38543 TSF:MSG:FPAR OK,ID=0,D=1
40190 TSM:FPAR:OK
40192 TSM:ID
40194 TSM:ID:REQ
40196 TSF:MSG:SEND,255-255-0-0,s=2,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
42203 TSM:ID
42204 TSM:ID:REQ
42207 TSF:MSG:SEND,255-255-0-0,s=220,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
44214 TSM:ID
44215 TSM:ID:REQ
44218 TSF:MSG:SEND,255-255-0-0,s=183,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
46225 TSM:ID
46226 TSM:ID:REQ
46229 TSF:MSG:SEND,255-255-0-0,s=146,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
48236 !TSM:ID:FAIL
48237 TSM:FAIL:CNT=3
48239 TSM:FAIL:DIS
48241 TSF:TDI:TSL
58244 TSM:FAIL:RE-INIT
58246 TSM:INIT
58252 TSM:INIT:TSP OK
58254 TSM:FPAR
58257 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
60265 !TSM:FPAR:NO REPLY
60267 TSM:FPAR
60270 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
61234 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
61239 TSF:MSG:FPAR OK,ID=0,D=1
62277 TSM:FPAR:OK
62278 TSM:ID
62280 TSM:ID:REQ
62282 TSF:MSG:SEND,255-255-0-0,s=71,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
64290 TSM:ID
64291 TSM:ID:REQ
64294 TSF:MSG:SEND,255-255-0-0,s=35,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
66302 TSM:ID
66304 TSM:ID:REQ
66307 TSF:MSG:SEND,255-255-0-0,s=0,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
68314 TSM:ID
68315 TSM:ID:REQ
68318 TSF:MSG:SEND,255-255-0-0,s=219,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
70325 !TSM:ID:FAIL

And here is the message I get from the output of the myscontroller node:

{"payload":"255;6;3;0;4;1","port":"/dev/ttyUSB-MysGW","_msgid":"cd1b9bbf.44ae08","nodeId":255,"childSensorId":6,"messageType":3,"ack":0,"subType":4,"origin":1,"messageTypeStr":"C_INTERNAL","subTypeStr":"I_ID_REQUEST","topicRoot":"mys-out"}
{"payload":"255;225;3;0;4;1","port":"/dev/ttyUSB-MysGW","_msgid":"c0995566.b1b318","nodeId":255,"childSensorId":225,"messageType":3,"ack":0,"subType":4,"origin":1,"messageTypeStr":"C_INTERNAL","subTypeStr":"I_ID_REQUEST","topicRoot":"mys-out"}
{"payload":"255;188;3;0;4;1","port":"/dev/ttyUSB-MysGW","_msgid":"4a91ca08.1fcce4","nodeId":255,"childSensorId":188,"messageType":3,"ack":0,"subType":4,"origin":1,"messageTypeStr":"C_INTERNAL","subTypeStr":"I_ID_REQUEST","topicRoot":"mys-out"}

I don't use MQTT, my gateway is a serial one.

Any clue? thanks a lot.

Even with the 0.1uF capacitor, I had wrong values.
So, I've gone with the voltage divider method, and it seems more reliable, at least for my case.
4.7V max to VCC, R1 1M, R2 330k, another 0.1uF capacitor in parallel with R2.
I don't need a very good accuracy, just a trend in order to know when to change my batteries.
Thanks for your help.

I noticed I used a 10uF/50V capacitor instead of a 0.1uF/5V for LM2936 regulator.
Could it be the source of my problem?
I change it last evening, and now the reported battery level seems ok.
Sorry, I'm noob in electronics

@mfalkvidd I thought of this too, but I opened the windows this morning, 11°C here this morning, and the battery level stayed around 50%.

Here are some graphs showing it's not temperature related:

And now, without resetting, the battery level has jumped from 23% to 47%. This last seems to be correct according to the measure of 3.673V, directly taken on the battery.

Ok, do you need my schematic, to make it clearer?

I've planned to removed the onboard regulator (and power led) on my production board. But this one is for testing so I leave it untouched.

So currently the regulator, is obiously external.

Thanks again, any help appreciated, otherwise I'll use the 2 resistors method.

@Yveaux thanks for your answer.

I used the sketch on the Mysensors'si7021 page, so the vcc level is read at the end of the loop, before going to sleep and after sending the temp/hum values.
The only modification I made are setting up the voltage values.
As my 3.7V Li-Ion battery is at 4.2V when fully charged and at 3V when almost completed discharged, this how I configured it in the sketch:

#ifdef REPORT_BATTERY_LEVEL
#include <Vcc.h>
static uint8_t oldBatteryPcnt = 200;  // Initialize to 200 to assure first time value will be sent.
const float VccMin        = 3.0;      // Minimum expected Vcc level, in Volts: Brownout at 1.8V    -> 0%
const float VccMax        = 4.2;  // Maximum expected Vcc level, in Volts: 2xAA fresh Alkaline -> 100%
const float VccCorrection = 1.0;      // Measured Vcc by multimeter divided by reported Vcc
static Vcc vcc(VccCorrection); 
#endif

I didn't apply any correction because read and reported VCC was very close, and I'm just testing this for now.

I didn't removed the onboard regulator nor the power led for now. Isn't the regulator only used when applying voltage to the RAW pin?

Hi there,

I've a pro mini 3.3V with a si7021 and a Li-ion 3.7V battery.
I'm using the VCC library, but the reported values are weird: the remaining battery value drops a lot, and if I reset the board, it jumps back to a more normal value.

The battery is connected to the VCC pin on the arduino.
A regulator (LM2936) powers the si7021 and the nrf24.

Here is a graph of the battery level. Pikes appear when I reset the arduino.

Isn't the 2 resistors method more accurate?

Thanks!