Board releases
(other colors might be selected when ordering)

• Version 2.0 (black) [order] Now designed in KiCad. "Final release". I'm not developing it further atm, but I know others have some projects going.
• Version 1.4 (red) My latest version in Eagle. Known issues are wrong references due to panelization and broken circuit diagram links.
• Version 1.2 (blue) Some less convienient placed components and the panelized verision has a faulty via.
• Version 1.0 (green) The one described below in this first post. Working but not panelized and lacks a few features.

Share stats and info
The panelized versions 2.0, 1.4 and 1.2 have until today (2019-02-24) been shared 230 (!) times at boardhouse. Together with a few shares of the non-panelized version and my own orders, and the usual 3x10-11 boards/order, it means a lot of boards! Guess very few build nodes with every board, but at least the design should be well proven by now. This also means a few $ to MySensors.org, since 1 $/order will be donated. Great thanks to everyone who has orderd this board! I'll keep this share-info updated for transparency purposes. IMPORTANT: Please understand that DirtyPCBs.com is a non-profit community service, with a lot of manual support required. So please be patient and nice to their support in general. A new site is under development. Read more at their support site. EDIT 2017-06-22: Despite the new site it is still a hassle every time to get a reply from them and then the share credits. If anyone have some more info on this, please let me know.

Introduction
This project describes a successor Node concept to my first 2AA battery sensor. I have combined a few simple design options to a result that I find rather useful myself and I think should be shared. The application specific sensor/-s of your own choice has to be added to this Node design, nor here any example sketches provided here except from a few links further below. I use this design for all my door and window reed switches, temperature (calibrated internal or thermistor), LDR and similar simple sensor types. But, nothing prevents the use of more sophisticated sensors like Si7021 here as well. A few links to sensor examples based on this node will be presented further down in this post.

Features

• Simple, in the sense that it consists of a minimum number of components and common available material.
• Cheap regarding choice of components, assembly work effort, energy storage and power consumption (battery type and life time).
• Flexible universal design base equipped with various sensors. PCB pads used as port connections or prototyping area for extensions.
• Small and discrete to fit in confined spaces and to reach WAF level

And more concrete:

The uC
Hardware
A "bare bones" ATMega328p 28pin PDIP (with or without socket). Bought from here and here. My reasons to not use Arduino Pro Mini here are

• The APM width is too big.
• APM has no prototyping/near connection area. There's no spare pads for separate connections unless you accept to use pads connected to softwise inactive ports.
• Radio module connection has to be manually made to the APM.
• Low power hacks like removing power led and voltage regulator are needed.
• Necessary support components (resistors and capacitors) are few and can easily be added to a custom pcb.

Software
Since I prefer Arduino IDE for programming (flash) and debugging, I need a bootloader. Bootloader instructions are found all over the internet, but here's anyway how I do it. I use this precompiled bootloader from here. It's an Optiboot with 1MHz internal clock and 9600 baud serial communication. Fuse changed to BOD disable. According to this you should use minimal startup time to reduce power in every 8s sleep cycle, but for the moment I don't care and stick to the default 65ms. I use Avrisp mkII avr programmer for fuse and bootloading similar to this procedure. Arduino as ISP, Avr/USBtiny or whatever any other should of course be just as good. Avr Studio 4.19 is a good choice for Avrisp mkII (perhaps for others too) and 4.19 is the last version before the gigantic (and for me useless) IDEs were released.
I add this new board to my "boards.txt". Fuse settings, don't forget to set the lock bits. If programming a large batch, the ELF production file is handy.
Here's a great tutorial for those who use Arduino Uno as ISP.
UPDATE 1: Today (2017) a lot has happen since I wrote about this. Some things has made it easier for us. A very good selection of precompiled bootloaders is now found here at MySensors. And you don't need to (and shouldn't) mess with the boards.txt any more. Instead I recommend the installation of MiniCore to the Arduino IDE.
UPDATE 2: There have been reported issues with MySensors 2.x freezing on SlimNodes running at 1MHz, which I've confirmed. Recommended solution when using MyS 2.x, is to use 8MHz (internal) instead.

The Radio
A standard NRF24L01+ radio module is used. The width align with the AAs and no mods is needed (like with my other one). As always I try to keep the antenna part of the module free from shading metal.
2020-12-14: On using RFM69 - here's a hint from @joaoabs at this page: I've been troubleshooting this slimnode with RFM69 radios and realized that a shunt between RFM69's DIO0 and Mega328's INT0 is required, otherwise the node will not "hear" the gateway. Even if the nrf2rmf69 board is used this shunt is required. It seems this is a re-current issue

The Board
At first I planned the build on a proto board, just to stick to the cheap-and-standard concept. But with today's low prices on custom made PCBs, it wasn't any longer an option. Space, quality and work effort are so much more attractive.
Latest design files are open and available at the openhardware.io site. Please click on the image-link below to access openhardware.io where all design files such as latest BOM, kicad-files and circuit diagram (pdf) are found.
https://www.openhardware.io/view/10/My-Slim-2AA-Battery-Node

Board (v2.0) Top Side:

Board (v2.0) Bottom Side:

The Enclosure
UPDATE: If you dont't like my primitive casing descibed below, in this post the user @buxtronix made a nice 3D-printed case which you can find here.

An important overall part of this design idea was to align minimum dimensions of the components and get rid of "expensive" parts like battery holder. It turn out (see below) that the enclosure's functionality as battery holder wasn't needed even though it was the initial idea. The cable duct case has been discussed earlier, but rejected by some due to lack of ways to seal the endings. I still haven't the perfect solution, but I've since many years simply used (cheap) white tape. With some care it looks ok, and still does 5-10 years later. There are often proper terminators/endings to buy, but for some reason to unrealistic high prices.
I used this cable duct with the dimension 17x20mm. Unfortunately it turned out that this particular type I used (Thorsman TMK T20) is now "professional grade" and dimension 17x20 is no longer very commercially available for consumers (here in Sweden at least). Eg. to get it, you have to pay >5$/m from places like this or buy it in bulk (50m) from a professional store (preferably as a professional with discount). The 50m bulk batch will give you 263 sensor nodes of standard length (19cm).
Standard consumer dimension cable duct is e.g. 15x15mm from what I've seen. It'd be nice to design a 2AAA node in that one. If only there is a thin radio module? (Future project.)

The Battery pack
Easy home made 2AA battery pack. Maybe it looks more demanding and time consuming than it is. (Usually its the other way around in my experience.)

1. Start by taping the two (connecting) batteries together.
2. Prepare the wires and make a small bun at the battery connecting ends.
3. Attach the wires with tape.
4. Tighten the cable ties and carefully note

• that the wires are pressed to make good contact with the battery poles
• how the cable tie ends must be placed to not steal lateral space
• that the wire from the bottom must be routed near the cable tie to not steal space.

1. Make the pack more rigid by taping one or two times around at the top, bottom and middle.
2. Trim wires and solder the female connector. If desired, leave at least a small part of one wire naked for current measurements.
   A battery change is done fast when cables a already made (use solid wires that preserves its shape). So why pay for a battery holder when you can remake a pack with fresh batteries in 1-2 min and your low power sensor will live 5-10 years before anything needs to be done?
   

The Interface/Connections
Convenient there's the 6 pin standard serial interface exactly like on the Arduino Pro Mini. Perhaps it's mirrored here, but I think everybody double checks Gnd and Vcc before connecting. The Vcc and Gnd pins also serves as a connector for the battery pack. (CTS is connected to GND on the PCB.)
"Under" the radiomodule are pads for the ICSP pins. The idea was to have a socket for the radiomodule instead of the "expensive" 328p socket and still have easy future access to the SPI/ICSP interface. Perhaps not very useful. But nice to have Gnd and Vcc in this end of the board for general purpose.

The Sleep Mode Power Consumption
I measured the sleep mode current draw to be 1.5uA when it's set to interrupt wake up and 5.8uA when it's set to timer wake up.

Sensor Examples and more
Reed Switch Sensor: post 116
Humidity Sensor: Slim Node Si7021 sensor example
Motion Sensor 1: Slim Node as a Mini 2AA Battery PIR Motion Sensor
Motion Sensor 2: Slim CR123A (2AA) battery node..
Scene Controller: Slim Node scene controller/ keypad
(work in progress to collect more examples here)

Not Sensor exemples, but some nice to see "node variations" from @AWI:
Here (post 88) and here (post 233). And now there's also @AWI 's My Slim 2AA Battery Node Tools.

Still not "slim" enough? Check out Very Narrow and Minimal Switch Node ! by @GertSanders

And also, there's this 5V-slim-node a 5V-slim-node mod by @Soloam

Feature Requests
Here's a collection of suggestions and development ideas for future versions of the board (or other parts). If anyone else make their own board where some of this is included, I'd be happy to reference it from here.

• Pin labels/references also on board top side.
• Turn the nRF footprint to make the assembly shorter.
• Make the board suitable for the nRF SMD version.

More Pictures
Some photos. First a comparison next to My (old) 2AA battery sensor, one painted and one not. (Note the high WAF of the colour even without the paint.) Then some placement examples. Reed switch nodes for all my doors and windows are my first priority.

Summary
This post shares my own non-professional evaluation of the 230Vac to 12Vdc cheap Chinese converter module (aka Switched Mode Power Supply, SMPS) called YS-12V400-B. It's now rather rare, but instead replaced by the very simmilar HX-12V400X which is found easily on Aliexpress by searching "12V 400mA power supply").
This is not a thorough test. I've looked documentation, load- and temperature- and startup characteristics and did some simple noise filter tests.
I will not give a straight answer to your question "is it safe?", instead I hope to provide information enough for you to draw your own conclusions.

Introduction
I first saw this module from @axillents post in another thread . I bought a batch almost a year ago , but haven't had the time to look at it until now. Now, a quick look at Ali tells me that it has become rather popular at a few sellers, but there's still no reviews to find. Some user comments I found here .

There is a new variant of the YS-12V400-B called HX-12V400X where the first (of few?) differences I can see from photos is that a clear blue (XY-grade?) high voltage capacitor has replaced a flat dark green one. Also there's an anti-creepage hole removed near mains input, where a pad has been changed instead. The HX-12V400X seems to be the most common one available on Ali and should probably be better to buy. The one I bought is gone of course. Here's one of few old ones, though.

Like everybody else, I'm looking for a small supply for my projects. The HLK-PM01 is bulky and I don't see a great value of the enclosure when the bare 230V pins are still there. Also, I care about safety and would not feel comfortable with this kind of unknown quality supply in a class III appliance device where secondary side is touchable. I'd prefer a metal case (class I) for safety earthing and fire protection, but it's not always very economical or practical so I then put my trust in good fuses, insulation (class II) and protective functions.

Some reasons for me to favour 12V in front of 3.3V and 5V are:

• A strive to standardize parts, reuse and keep my assortment of parts as lean as possible.
• Easily converted to 5V or 3.3V with linear regulator where the extra converter's power supply ripple rejection (PSRR) is desired.
• I don't mind the small extra loss or heat due to 5V or 3.3V conversion.
• Flexible in respect of component selection and circuit design. Particularly when dealing with electromechanics like relays and servos.
• Preferable if one wish to distribute power further without to much loss and voltage drop.
• Less current and smaller components.
• Works with Arduino Pro Mini internal regulator. (Note that some APM clones can't handle 12V.)

Since the HLK-PM01 has become our reference device after the famous lygte-info.dk review , I've been thinking that some kind of testing and closer look needs to be done before using ANY kind of Chinese SMPS. I may not have all equipment or skill, but with a small effort a lot can be done. At least to reassure myself that the device is useable (or not). Still, I don't consider anything but certified products as "safe".

Documentation
Official specifications are hard to find and very limited as usual when it comes to these cheap Chinese products:
Dimensions: :4 x1.5 x 1.8cm
Input voltage:AC 90V~240V 50/60HZ
Output voltage:DC 12V (±0.2V)
Output Current: 400mA
Output power: 4.8W
90V~240V AC Input,Constant 12V DC Output ,Ultra small,Precision
Application: the power adapter,industrial equipment,microcontroller,LED lighting power supply, etc
AC input:Does not distinguish between live line and null line.
Protection functions:YES
Shortage Protection:YES
Temperature protection:YES
Overcurrent protection:YES

A look through the magnifier reveals the controller IC name "THX208", which then provided a pretty good datasheet . (Of course you might need a translation tool, but after that it's very readable). It turns out that the power supply module we're studying is designed very close the provided typical circuit:

...but with a few simplifications (the low cost device is made even cheaper?). One is that the Y suppressor capacitor is omitted, great for safety but not so great for EMI suppression. Another is an inductor at primary side (simple line filter?). Bad EMI to expect from this then? Maybe, I don't have any tools or knowledge about EMC, but we'll see if there're any signs of this later perhaps... The HLK-PM01 EMC review is my reference of about what to expect.

Visual check
It looks OK, without any apparent insane design choices. Creepage distance around mains input is as usual unnecessary small. It's barely the required 3mm so keep it away from polluted environment and have good fuses before it. The primary-secondary distance looks good, with only the transformer and opto-coupler interconnecting.

Load test measurements
Test input voltage: 239Vrms
No load output voltage: 11.85V
No load input current(AC): 2.4mA
Load test presented below was conducted by applying a 150uF cap together with a few different resistive values. Different cap values (0-2mF) had a small impact on latest half of the output voltage rising slope, nothing else. 150uF was left through the rest of the tests to simulate a realistic value.

Maximum overload: n/a
As the current/load increases above nominal current 400mA, the controller effectively decreases voltage to keep within constant max power 4.8W. At 185% nominal current, it starts cutting off the output repeatedly at 2-3Hz.

Output voltage ripple
At no load: 52mVrms

At nominal load: 76mVrms

Switch frequency: 40-60kHz (increasing with load)
Half load:

Full (nominal) load:

Startup time tests showed variations depending on line phase, load/load-type and unknown factors. Numbers presented below are averages from a lot of sample startup tests and typical characteristics are shown. A current probe (100mV/A) is used on AC input wire.
Controller startup time (from power-on until the beginning of output voltage increase): 15-20ms

There also a strange phenomenon where startup time sometimes is ~100ms. I haven't been able to figure out when or why it happens, but there seems to be some correlation with high loads, load time and frequent startups.

Voltage rise time, no load: 7ms

Voltage rise time, full load: 15-20ms

Voltage rise time, 1.5mF load: 30ms

A quick reconnect results in a little faster uptime but no notable difference in inrush current. The on-board output ballast (LED) de-energizes the load capacitor pretty fast.

Inrush current and fuse value
Since using a fuse at the input to this supply is a very good safety practice, we need to know the expected current characteristics. Especially during startup when there's high currents even for moderate loads (link) . I had some theories and calculations posted in the "Safe in wall..."-thread . From the measurements presented in this post it looks that I was rather correct in my assumption regarding the first inrush current, but rather wrong about the succeeding one.
The first 1-2 peaks when energizing the filter cap has very high current, but very short duration (<1ms) which won't melt a normal fast fuse. Sometimes this first quick inrush impulses are several due to bouncing connectors and when in the line phase it connects.

The second one though was not as I thought. It was not related to load or output voltage raise. It was actually very unpredictable and could even superimpose on the first filter inrush current. In total worst case then there is a <1ms peak at >10xIn followed by 3-4ms at ~0.4A. If I've read IEC 60127 -1 and -2 correct, the fuse must have pre-arcing at 2xIn, meaning 0.2A fuse is on the edge and 0.3, 0.4 or even 0.5A would probably be better. I think 0.5A is the most common and easiest to find. The disadvantage with a too low value is wear and frequent spurious fuse blows with the risk of user neglecting real issues instead.
Since there's completely silent on the secondary (output) side, my guess is that this "second inrush" power is dissipated by the controller for some reason. - If an expert or anybody knows more about this or have another guess your welcome.

Operating temperatures
Max temperature at nominal load: 65'C
A maximum and stable temperature was reached after ~5min and remained the same until the test stopped after 60 min. The controller IC and the rectifying diode heats up pretty fast and to the same temperature. A litte faster and 1-2'C more for the controller. As the time goes the transformer will heat up as well. Probably partly because those hot components on each side.

Max temperature at "overload": 75'C
Because of the controller overload protection, the supply can't be overloaded in the true meaning. Here's the study of high-current-low-voltage condition right before it enters protection mode with repeatedly switching on and off, and everything cool down. Just like the nominal case, the temperature stabilizes fast and stays there. The most notable difference in this case is the rectifier diode gets hotter than the controller (~5'C).

Noise
EMI is another great concern regarding these kinds of cheap Chinese power supplies. The HLK-PM01 EMC test confirms this and don't expect the YS-12V400-B to be any better. I don't have the equipment or knowledge to test EMC/EMI, but I have my Picoscope and two AC current probes I can use to study the device at different loads and so on. I assume this can be used to give an idea of what to expect.
First its easy to see from the startup measurements above that there's more noise during the rise of output voltage. There's also a correlation between increased load and increased current noise.
Here's a comparison between low load (280ohm) and nominal load (30ohm) in time domain (Blue=I_in, Red=I_out):

and in the frequency domain:

As an experiment I applied the line filter from a good quality 300W old computer PSU. It's actually a two stage filter where one is the common type built into the power cord socket.

Here's it in action for nominal load (30ohm) (Blue=I_poweroutlet2filter, Red=I_filter2SMPS):

Here's a comparison between nominal load (30ohm) and low load (280ohm):

So the conclusion here is that the filter is working, but it's not nearly as effective as using a low load.
If you intend to use any of these supplies at 400mA or perhaps even at 50% continuously, it'd probably be recommended to use one of the models with EMI filter.

Conclusion
A few aspects of the supply module have been studied, no issues have been found and it corresponds to the found documentation. EMI is probably OK if the load is small.

Design Example
Here is a recent design example with this module:
https://www.openhardware.io/view/47/My-MySensorized-Wall-plug

After reading about @AWI 's C123A battery based slim PIR sensor, I've finally have had time to play with the mini PIR motion sensor a little myself. Luckily I found a little for me easier, working design which I believe will satisfy my own needs sufficiently. It's basically just the mini-PIR HC-SR505 with its diode and voltage regulator removed, attached to the Slim Node and with simple but suitable sketch.

Conclusion from my playing with the HC-SR505 was

• power consumption was identical to mesurements by AWI, 46uA (no movement) and 62uA (movement) . Removing the 7133-regulator did not affect anything significantly due to its very low quiescent current (see datasheet, perhaps useful in some other project?)
• it's flexible regarding output (load) impedance and load will not affect sensitivity, no need for pull-up/down, filter, etc
• the supply voltage range with diode and 7133-regulator removed was great. Flawless results with only one AA (1.6V), and I saw no point to go lower.
• it's very supply noise sensitive and will false trigger on almost anything. Any kind of switching boost (voltage step-up) regulator made it trip continuously. (Found some differences between small and big 3.3V-step-ups btw). Any activity on a nRF connected to same supply would also generate a false trip.
• the ~3m max range or sensitivity doesn't seem to be affected by voltage level or noise.

I'm not going to try some hw-filter to get rid of the nRF false trip issue. I think we're all aware of the very hard task to to this when it comes to the nRF itself. For my need it's good enough to just dealing with it in the sketch.

Two sensor nodes, one shorter enclosure with the PIR peeking out and the other one with a traditional oriented fit. I resoldered one of the three PIR legs so they're all on the same board side to facilitate the angled position.

The sketch
The sketch (and this sensor) is not intended to reside in a busy place or work as presence sensor. It's better as a guard, alarm or notification in a low frequency/activity environment. One obvious reason is that the range is not very impressive (max 3m). Then, with this sketch, the controller will just be informed when motion starts. After that, there's no way for it to distinguish absent motion from continuous motion. My reasons for this are (1) it's ok for my application (2) simple (3) save battery and (4) to overcome the false trip problem.

/**
 * EgSlimReed2
 * Sketch for Slim Node and HC-SR505 based motion sensor. 
 * Inspired by:
 * - MySensors motion sensor example: http://www.mysensors.org/build/motion
 * - AWI's CR123A based Slim Node motion sensor: http://forum.mysensors.org/topic/2478/slim-cr123a-2aa-battery-node
 *
 * Created by m26872
 * Documentation: http://forum.mysensors.org...
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Test to if node can operate in some way dealing with the Pir extreme sensitivity to noise on Vcc.
 * Version 2.0 - First "production node". "Inactivity day counter" introduced.
 * 
 * DESCRIPTION
 * This sketch will only send trips as "1" to the controller. It's up to the controller to deal with the info. 
 * The motion node will not notify controller when resets back to low state and is ready for a new trip. In reality 
 * this is ~10s. And EVEN IF motion is detected continuously, there will be no new trip until motion has stopped for ~10s.  
 * The HC-SR505 is very noise sensitive and will trigger spuriously for almost any activity 
 * on Vcc (test thoroughly). To run the HC-505 at low voltages (tested flawlessly down to 1.6V), 
 * the 7133-reg and diode are removed (and possibly increase the sensitivity even further). 
 * Solution is to deal with it by interrupt type, check which source, block by sleep time etc.
 * 
 * HC-505 output connects to MOTION_INPUT_PIN (here D3) without any supporting component. Input pull-up disabled.
 * Every 24 hrs without trip, increments a counter and after "BATTERY_REPORT_DAY" counts a battery report will be sent as a heartbeat signal.
 * Else a battery report will be sent after every "BATTERY_REPORT_BY_IRT_CYCLE" motion trips.
 *
 */
 
#include <MySensor.h>
#include <SPI.h>
#include <Vcc.h>

//#define DEBUG

#define NODE_ID 14  // Use static Node_ID  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  //14 var senaste "slim-PIR"-id 
#define SKETCH_NAME "EgSlimPIR2"
#define SKETCH_VERSION "2.0 2016-01-01"
#define CHILD_ID 5
#define MOTION_INPUT_PIN 3
#define BATTERY_REPORT_DAY 2   // Desired heartbeat(battery report) interval when inactive. 
#define BATTERY_REPORT_BY_IRT_CYCLE 10  // Make a battery report after this many trips. Maximum report interval will also be equal to this number of days.
#define ONE_DAY_SLEEP_TIME 86400000
#define VCC_MIN 1.9
#define VCC_MAX 3.3

#ifdef DEBUG
#define DEBUG_SERIAL(x) Serial.begin(x)
#define DEBUG_PRINT(x) Serial.print(x)
#define DEBUG_PRINTLN(x) Serial.println(x)
#else
#define DEBUG_SERIAL(x)
#define DEBUG_PRINT(x) 
#define DEBUG_PRINTLN(x) 
#endif

int dayCounter = BATTERY_REPORT_DAY;
int irtCounter = 0;


bool interruptReturn = false; // "false" will make the first loop disregard high output from HV-505 (from start-up) and make a battery report instead.
 
Vcc vcc;
MySensor gw;
MyMessage msg(CHILD_ID, V_TRIPPED);

void setup()  
{  
  DEBUG_SERIAL(9600);
  DEBUG_PRINTLN(("Serial started"));
  delay(100); // to settle power for radio
  gw.begin(NULL,NODE_ID);
  pinMode(MOTION_INPUT_PIN, INPUT);
  digitalWrite(MOTION_INPUT_PIN, LOW);    // Disable internal pull-ups
  gw.sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  gw.present(CHILD_ID, S_MOTION);
  DEBUG_PRINTLN("Warming and blocking PIR trip for 20s.");
  gw.sleep(20000); // Wait until HC-505 warmed-up and output returned low.
}

void loop() 
{
  if (interruptReturn) {	// Woke up by rising pin
	gw.send(msg.set("1"));  // Just send trip (set) commands to controller. (Let controller reset and decide what to do with it.)
	irtCounter++;
	if (irtCounter>=BATTERY_REPORT_BY_IRT_CYCLE) {
		irtCounter=0;
		sendBatteryReport();
	}
  }
  else { // Woke up by timer  (or it's the first run)
	dayCounter++; 
	if (dayCounter >= BATTERY_REPORT_DAY) {
		  dayCounter = 0;
		  sendBatteryReport();
	}
  }
  
  gw.sleep(3000);  // Make sure everything is stable before start to sleep with interrupts. (don't use "gw.wait()" here). Tests shows false trip ~2s after battery report otherwise.

  // Sleep until interrupt comes in on motion sensor or sleep time passed.
  interruptReturn = gw.sleep(MOTION_INPUT_PIN-2,RISING, ONE_DAY_SLEEP_TIME);
  // DEBUG_PRINT("interruptReturn: ");DEBUG_PRINTLN(interruptReturn);

} 

void sendBatteryReport() {
		  float p = vcc.Read_Perc(VCC_MIN, VCC_MAX, true);
		  int batteryPcnt = static_cast<int>(p);
		  gw.sendBatteryLevel(batteryPcnt);
}

Future development
In future sketch versions an idea is to let the sensor ask my controller when to arm or to disarm. Maybe hourly or with a controller set next sleep time duration. This will be combined with a digital-out pin controlled supply of the HC-SR505 to save the 47uA. Necessary warm-up and false trip blocking and will hopefully be mastered without side effects.

Power economy
Idling current 52uA of this PIR motion sensor node is ok, but I'm worried about sending to frequent messages. Especially since I also want some kind of heartbeat for the longer motionless durations. Just to give me perspective I set up the two PIRs to cover the busiest areas in my home for 4 days, busier than usual due to holidays and guests. This produced 1765 messages (9% being battery reports) which is 220 messages/day/sensor. (For a normal weekday the figure was <100.)
Compare this with my reference Node 105 with ~100uA sleep mode current, 130 messages/day and for which my (today) guess is that it will survive on it's batteries for about 24 months (I know it theoretically doubtful, but the 100uA is probably lower).
My conclusion is that it's ok to use this PIR motion sensor as it is. The test setup was rather conservative and with a little more thought about how and where to place them, it could be improved.
I buy 40 AA batteries for the price of one rechargeable CR123A. But sure, the size becomes more attractive with a CR123A.

Some more photos

Don't know if it's too obviuos but I haven't seen many basic designs so I thought I'd share mine. I have 10+ of these with runtime 6-8 months with very good results.

Worth to note is that this "basic" design is based on a normal 3.3V 8MHz Arduino Pro Mini with just the voltage regulator and power led removed. The other common low-power tweak with new bootloader, decreased clock speed and disabled brown out voltage detection is very nice but not a part of this design because I think it is one step beyond "basic". So keep it simple for now... (Or look here.)

It's a normal battery powered slim one piece unit with battery monitoring and room for small sensors inside. In the picture a DHT22 has been squeezed but with better preparations there'll be more useable space.
Some benefits I noticed with this design is:

• Easy access to the pro mini serial pins, the reset button and to view the pin 13 led.
• Easy remove/replace batteries.
• Easy in/out of components since the just attached in place with their firm-flexible wires.
• The "keyhole" in the cap is still available so the unit easily can hang on the wall.
• The radio is located far from the wall-side and with reasonable small risk of getting in the shadow behind the batteries.
• Small but still good battery life using (the most?) common standard batteries.
• (I'd thought I'd put good waf here but she said the box color was "too gray" )

The cost with building this sensor is that it requires some soldering and small/short wires work. (I prefer small/medium size "bread board type" wires to this.). I unsoldered the radio module pin headers and trimmed the ones on the step-up. After building 10 of these in 3 batches I've focused on productivity and less on the product. So I'm aware of improvements and maybe I'll introduce some in my next ongoing batch of 10.
The 3.3V stepup-supply feeds the arduino and sensors that requires 3.3V to work. The radio is powered straight from the batteries because it's high qauality demand on its supply and that it's good with a voltage all the way down to 1.9V. I still use the 4,7uF capacitor on radio as precaution.
Since its battery and low power is wanted, I always remove the voltage regulator and power led from the Arduino pro mini and the power led from the step-up regulator (or the series resistor).
I set my power monitoring to report linear with 1.9V as 0% (Vmin_radio) and 3.3V as 100% (instead of 3.44 just to increase resolution). Power consumption looks very good. I usually use normal or high frequency update in my nodes (30s - 3min) and I've tried with really poor used batteries but all my batterylevels in datamine (Vera-plugin) are looking good. I've measured ~1mAac/0.1mAdc current draw in sleep mode. Considering the results from reality with my nodes with longer sleep durations, the mAdc value is closest to the truth.

More photos of a complete node to be found here below.

Main material (note that some links are for >1pcs). All except battery holder are from MySensors store.

• 27x54x75mm Case
• 2AA Battery holder (don't mind it's actually another on this particular image.)
• Arduino Pro Mini 3.3V 8Mhz
• Radio NRF24L01+
• 3.3V stepup regulator (remove power led and DO NOT FEED THE RADIO WITH THIS, just arduino and sensors.
• Prototype PCB (sliced by 2 row pieces, but I suggest to make 3 rows instead to better fit with step up and more space is easier to work with when soldering..)
• Sensors eg DHT, DS18B20s etc
• Wires. I used these, but I'm sure any wire good for breadboarding will do.

Edit:
I forgot to list the 2 resistors and 1 capacitor for battery monitoring as well as the sensor dependent 4k7 pullup resistor (if used). The battery monitoring circuit is under the 2-row proto-pcb and the pullup under the arduino. See the build site and store for more info. With a 3-row proto-pcb I'd place the pullup here as well.
The 4.7uF cap for radio is of course straight on top between vcc and gnd, but a little above so wires can be soldered here too.
I can also mention that I find a good order for making these are:

1. Glue the battery holder to the case "bottom".
2. a. Pre-assemble arduino with radio soldering as short wires as possible. And attach all (~30mm) wires leaving these two.
   b. Pre-a. the proto-pcb with all its components and with the step-up regulator.
   c. Pre-a. sensor(s) that will be used.
3. Connect all things made in the previous step.
4. Connect battery when needed but don't put it all in to case until software has been loaded and first tests been done.

As always; if unsure or in trouble; test individual parts before putting them together.

Edit 2:
Here's the layout with connections. Since the schematic is simple and covered elsewhere at the Build site I found it more informative to show the design as a layout with wiring.

Edit 3:
Some example sketches are found further below in this thread. E.g.
http://forum.mysensors.org/topic/486/my-2aa-battery-sensor/37

Then the usual ads linked from the Bom above:

Reed Switch example
With external 10M pull-up to save battery. The plastic foam is used instead of a fixed mount, for easy disassemble, reflash, battery renewal etc.

The Sketch

// EgSlimReed2
// By m26872, 2015-12-22
// Interrupt driven binary switch for Slim Node with Reed switch and external pull-up (10Mohm)
// Inspired by mysensors example:
// https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/BinarySwitchSleepSensor/BinarySwitchSleepSensor.ino

#include <MySensor.h>
#include <SPI.h>
#include <Vcc.h>

#define NODE_ID 5 //12 var senaste "reed-node"-id // 110    // Use static Node_ID  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#define SKETCH_NAME "EgSlimReed"
#define SKETCH_VERSION "2.0 2015-12-22"
#define SW_CHILD_ID 5
#define SW_PIN 3
#define BATTERY_REPORT_DAY 2   // Desired heartbeat interval when inactive. Maximum heartbeat/report interval is equal to this due to the dayCounter.
#define BATTERY_REPORT_BY_IRT_CYCLE 10  // Adjust this according to usage frequency.
#define ONE_DAY_SLEEP_TIME 86400000
#define VCC_MIN 1.9
#define VCC_MAX 3.3

int dayCounter = 0;
int irtCounter = 0;
uint8_t value;
uint8_t sentValue=2;
bool interruptReturn=false;
 
Vcc vcc;
MySensor gw;
MyMessage msg(SW_CHILD_ID, V_TRIPPED);

void setup()  
{  
  delay(100); // to settle power for radio
  gw.begin(NULL,NODE_ID);
  pinMode(SW_PIN, INPUT);
  digitalWrite(SW_PIN, LOW);    // Disable internal pull-ups
  gw.sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  gw.present(SW_CHILD_ID, S_DOOR);  
}

void loop() 
{
  if (!interruptReturn) { // Woke up by timer (or first run)
	dayCounter++; 
	if (dayCounter >= BATTERY_REPORT_DAY) {
		  dayCounter = 0;
		  sendBatteryReport();
	}
  }
  else {	// Woke up by pin change
	  irtCounter++;
	  gw.sleep(50);  	  // Short delay to allow switch to properly settle
	  value = digitalRead(SW_PIN);
	  if (value != sentValue) {
		 gw.send(msg.set(value==HIGH ? 1 : 0));
		 sentValue = value;
	  }
	  if (irtCounter>=BATTERY_REPORT_BY_IRT_CYCLE) {
		irtCounter=0;
		sendBatteryReport();
	  }
  }

  // Sleep until something happens with the sensor,   or one sleep_time has passed since last awake.
  interruptReturn = gw.sleep(SW_PIN-2, CHANGE, ONE_DAY_SLEEP_TIME);

} 

void sendBatteryReport() {
		  float p = vcc.Read_Perc(VCC_MIN, VCC_MAX, true);
		  int batteryPcnt = static_cast<int>(p);
		  gw.sendBatteryLevel(batteryPcnt);
}

I've tried to post some sensor examples in the main Slim Node thread. It's continuously growing and I think it's better to start new threads for as much as possible. Here's one. I used this Si7021 (GY-21 board).

Sketch
Apologize for still not having cleaned up the sketch yet ...

/* Sketch with Si7021 and battery monitoring.
by m26872, 20151109 
*/
#include <MySensor.h>  
#include <Wire.h>
#include <SI7021.h>
#include <SPI.h>
#include <RunningAverage.h>

//#define DEBUG

#ifdef DEBUG
#define DEBUG_SERIAL(x) Serial.begin(x)
#define DEBUG_PRINT(x) Serial.print(x)
#define DEBUG_PRINTLN(x) Serial.println(x)
#else
#define DEBUG_SERIAL(x)
#define DEBUG_PRINT(x) 
#define DEBUG_PRINTLN(x) 
#endif

#define NODE_ID 132             // <<<<<<<<<<<<<<<<<<<<<<<<<<<   Enter Node_ID
#define CHILD_ID_TEMP 0
#define CHILD_ID_HUM 1
// #define SLEEP_TIME 15000 // 15s for DEBUG
#define SLEEP_TIME 300000   // 5 min
#define FORCE_TRANSMIT_CYCLE 36  // 5min*12=1/hour, 5min*36=1/3hour 
#define BATTERY_REPORT_CYCLE 2880   // Once per 5min   =>   12*24*7 = 2016 (one report/week)
#define VMIN 1900
#define VMAX 3300
#define HUMI_TRANSMIT_THRESHOLD 3.0  // THRESHOLD tells how much the value should have changed since last time it was transmitted.
#define TEMP_TRANSMIT_THRESHOLD 0.5
#define AVERAGES 2

int batteryReportCounter = BATTERY_REPORT_CYCLE - 1;  // to make it report the first time.
int measureCount = 0;
float lastTemperature = -100;
int lastHumidity = -100;

RunningAverage raHum(AVERAGES);
SI7021 humiditySensor;

MySensor gw;
MyMessage msgTemp(CHILD_ID_TEMP,V_TEMP); // Initialize temperature message
MyMessage msgHum(CHILD_ID_HUM,V_HUM);

void setup() {
  DEBUG_SERIAL(115200);    // <<<<<<<<<<<<<<<<<<<<<<<<<< Note BAUD_RATE in MySensors.h
  DEBUG_PRINTLN("Serial started");
  
  DEBUG_PRINT("Voltage: ");
  DEBUG_PRINT(readVcc()); 
  DEBUG_PRINTLN(" mV");
/*
  delay(500);
  DEBUG_PRINT("Internal temp: ");
  DEBUG_PRINT(GetInternalTemp()); // Probably not calibrated. Just to print something.
  DEBUG_PRINTLN(" *C");
*/  
  delay(500); // Allow time for radio if power useed as reset
  gw.begin(NULL,NODE_ID);
  gw.sendSketchInfo("EgTmpHumBat5min", "1.0 151106"); 
  gw.present(CHILD_ID_TEMP, S_TEMP);   // Present sensor to controller
  gw.present(CHILD_ID_HUM, S_HUM);
  DEBUG_PRINT("Node and "); DEBUG_PRINTLN("2 children presented.");
  
  raHum.clear();
  
}

void loop() { 

  measureCount ++;
  batteryReportCounter ++;
  bool forceTransmit = false;
  
  if (measureCount > FORCE_TRANSMIT_CYCLE) {
	forceTransmit = true; 
  }
  sendTempHumidityMeasurements(forceTransmit);
/*
  // Read and print internal temp
  float temperature0 = static_cast<float>(static_cast<int>((GetInternalTemp()+0.5) * 10.)) / 10.;
  DEBUG_PRINT("Internal Temp: "); DEBUG_PRINT(temperature0); DEBUG_PRINTLN(" *C");        
*/
  // Check battery
  if (batteryReportCounter >= BATTERY_REPORT_CYCLE) {
	long batteryVolt = readVcc();
	DEBUG_PRINT("Battery voltage: "); DEBUG_PRINT(batteryVolt); DEBUG_PRINTLN(" mV");
	uint8_t batteryPcnt = constrain(map(batteryVolt,VMIN,VMAX,0,100),0,255);   
	DEBUG_PRINT("Battery percent: "); DEBUG_PRINT(batteryPcnt); DEBUG_PRINTLN(" %");
	gw.sendBatteryLevel(batteryPcnt);
	batteryReportCounter = 0;
  }
  
  gw.sleep(SLEEP_TIME);
}

// function for reading Vcc by reading 1.1V reference against AVcc. Based from http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/
// To calibrate reading replace 1125300L with scale_constant = internal1.1Ref * 1023 * 1000, where internal1.1Ref = 1.1 * Vcc1 (per voltmeter) / Vcc2 (per readVcc() function) 
long readVcc() {
  // set the reference to Vcc and the measurement to the internal 1.1V reference
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  delay(2); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Start conversion
  while (bit_is_set(ADCSRA,ADSC)); // measuring
  uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH  
  uint8_t high = ADCH; // unlocks both
  long result = (high<<8) | low;
  result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
  return result; // Vcc in millivolts
}
// function for reading internal temp. From http://playground.arduino.cc/Main/InternalTemperatureSensor 
double GetInternalTemp(void) {  // (Both double and float are 4 byte in most arduino implementation)
  unsigned int wADC;
  double t;
  // The internal temperature has to be used with the internal reference of 1.1V. Channel 8 can not be selected with the analogRead function yet.
  ADMUX = (_BV(REFS1) | _BV(REFS0) | _BV(MUX3));   // Set the internal reference and mux.
  ADCSRA |= _BV(ADEN);  // enable the ADC
  delay(20);            // wait for voltages to become stable.
  ADCSRA |= _BV(ADSC);  // Start the ADC
  while (bit_is_set(ADCSRA,ADSC));   // Detect end-of-conversion
  wADC = ADCW;   // Reading register "ADCW" takes care of how to read ADCL and ADCH.
  t = (wADC - 88.0 ) / 1.0;   // The default offset is 324.31.
  return (t);   // The returned temperature in degrees Celcius.
}

/*********************************************
 * * Sends temperature and humidity from Si7021 sensor
 * Parameters
 * - force : Forces transmission of a value (even if it's the same as previous measurement)
 *********************************************/
void sendTempHumidityMeasurements(bool force) {
  bool tx = force;

  si7021_env data = humiditySensor.getHumidityAndTemperature();
  
  float temperature = data.celsiusHundredths / 100.0;
  DEBUG_PRINT("T: ");DEBUG_PRINTLN(temperature);
  float diffTemp = abs(lastTemperature - temperature);
  DEBUG_PRINT(F("TempDiff :"));DEBUG_PRINTLN(diffTemp);
  if (diffTemp > TEMP_TRANSMIT_THRESHOLD || tx) {
	gw.send(msgTemp.set(temperature,1));
	lastTemperature = temperature;
	measureCount = 0;
	DEBUG_PRINTLN("T sent!");
  }
  
  int humidity = data.humidityPercent;
  DEBUG_PRINT("H: ");DEBUG_PRINTLN(humidity);
  raHum.addValue(humidity);
  humidity = raHum.getAverage();  // MA sample imply reasonable fast sample frequency
  float diffHum = abs(lastHumidity - humidity);  
  DEBUG_PRINT(F("HumDiff  :"));DEBUG_PRINTLN(diffHum); 
  if (diffHum > HUMI_TRANSMIT_THRESHOLD || tx) {
	gw.send(msgHum.set(humidity));
	lastHumidity = humidity;
	measureCount = 0;
	DEBUG_PRINTLN("H sent!");
  }

}

Notes
Here (and often in other projects as well) the GY-21 board is used to provide the Si7021 sensor . I'm not sure about the identity of components on it, but apart from the sensor the board also includes a small 3.3V-regulator (LDO), mosfets for logic level convertion, supporting capacitors and pull-up resistors.

The voltage regulator is desoldered and bypassed in pictures above. This gained a node sleep current reduction from 10.7uA to ~6uA. This is the only modification necessary to do on the GY-21.

The GY-21 board is obviously designed for 5V-projects, but removing-/bypassing the v-reg is enough for using it in our low power 3.3-1.9V applications. @riataman was the first to show the mod of the GY-21 board in this post. There's also a link to a board without the v-reg and level converter. If you design you own pcb you'll probably use the Si7021 bare chip instead of the GY-21 board.

I had some thoughts about voltage dropout level and the level converter. In the end I still have thoughts, but my experiments show no issues. Here's a description of the level converter working principle. Remember that I don't know if these specs are equivalent, but looking at the mosfet datasheet, it says "Diode forward voltage drop 0.85-1.5V" and "Gate threshold voltage 1.0-2.5V". It's also an "Enhancment mode" FET, where the threshold voltage is important according to this. All together makes me worried about the High side capability to pull down Low side when High side volt is <2V instead of 5V. My tests show differently though. There are no real issues with this. The Si7021 worked down to ~1.7-1.8V with no significant difference whether the level converter was bypassed or not. Comparing one node with bypassed level converter to one without, showed ~1uA lower sleep mode current. But I assume it could just as well be a matter of the individual variations. If anyone like to bypass their level converter, here's a picture.

Battery level status report after 18 months:
Node 105: 51%
Node 106 (with used batteries): Died early January.

Next 24 months.

@Nicklas-Starkel I've been busy for few months moving to a new house and have had my sensor network offline until now because of this. Node 105 was kept on and handled with care, but I was pretty sure it would be dead when I started my gateway yesterday. BUT, it was ALIVE ?! at 14% battery level. Amazing! 24 months with such poor and simple hardware and software. Same batteries and only one restart (due to my controller change last year).
One little remark though, it doesn't seem to send temperature och pressure, only humidity and battery level. Maybe an issue of voltage recovery time between transmissions.

Humidity Sensor example
http://forum.mysensors.org/topic/3049/slim-node-si7021-sensor-example

(This post used to contain a not yet finished design by mistake. The link above now shows the correct finished project.)

The 12 months target was done a few days ago. Today's status 105: 63% and 106: 27%
I had a thought to celebrate their birthday by retrieve old Vera data and make nice plot, but that has to wait. Next, 18 months.

Just to clarify that these are no "sleeping" nodes; they transmit 100-150 messages each every day.

@joaoabs said in My Slim 2AA Battery Node:

Thx! Done!

@mfalkvidd Don't know if I'm qualified, but I've vague memory (or a wild guess). I think there were some pro-mini models that lost connection to one vcc-pin if you made the cut after the voltage regulator. And btw I never really know why the cutting method was so popular.

@Sven-0
Fun to see this old topic again. And also the coincidence, since my visits here have been rare for a long time.
Anyway, I'm running a few slimnodes since the beginning and have both good and bad experiences. In general, the battery lifetime is your least concern. Instead I have had issues with sensors, sensitivity, switch contact corrosion, mechanical robustness, wifi interference, repaeter, gateway, controller, waf, kids, animals, etc, etc.
Regarding this particular PIR slimnode it's very stable, but it is not universal for every situation due to the limited range and missing sinsitivity adjustment. E.g I can't use it too near my basement windows due to the moving cold air. And in my living room I have sun reflections to deal with.
I suggest you start by building a testnode to check if it works for your conditions.
A recent PIR-slimnode battery life example; My hallway one died last week after 33 months and around 6000 trips/month.

@jan-greis With all respect to the criticism I don't think original part configuration is that bad. I don't build any new of them but I still use a few as frequent reporting nodes. If you already own the parts and you need a frequent awake node -why not?
If I recall the sleep mode should be 90-100uA with this setup. Low power nodes have <10uA.
Troubleshooting method should be the usual. Exchange components, test them one by one, etc. Start with testing the step-up quiscent current, then run test Arduino only in sleep (low power lib not Mysensors-lib), then add DHT, then nRF.

@Mikepara Please elaborate and post your code. Tell us also about power supply, fuse settings (clock speed) and your troubleshooting steps. See debug-faq-and-how-ask-for-help.

@masfak97 Wow. You work hard. Of course we must help you. I'm not familiar with your programming method. So that would be my quick wild first guess. I can't read that you've verified the fuse settings? Have tried different startup times e.g?
Do I understand correctly if you're able to send and recieve commands to the Atmega with your FTDI after it is programmed ?

@masfak97 Have you selected the right board in Arduino IDE? (Installed MiniCore in Board Manager?) Have you tried to use baud 9600 (with corresponding bootloader of course) ?
I doubt that 83uF is too small.

@kotzer Infact I'm actually making a few of my first model too rigth now. I had components left over and despite everyones criticism against the dht22, I find it working very well as long as you deal with the failed readings in the sketch. And, the battery life time was pretty good too. Greets.

@kotzer Thanks for sharing. But (AFAIK) the Arduino DHT22 library has never worked at all at 1MHz. And since dht22 doesn't support <3V there's no need for 1MHz anyway.

I think you should focus on getting these basic Arduino functions working so you're in control of what's going on. Note that I recently added a few updates to the first post of this thread (under The uC - Software). Read the tutorials and use 8MHz internal clock.
When you get everything running, test your door switch again with a simple Arduino sketch.