@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. :disappointed:
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.:slot_machine:
A recent PIR-slimnode battery life example; My hallway one died last week after 33 months and around 6000 trips/month.:muscle:

@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. :+1:

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

@masfak97 It's not clear to me whether you've tried to run it a as pure Arduino, without radio module and without MySensors library in your sketch? (I see that you haven't the serial/FTDI pins soldered - do you use ICSP, pogo-pins or whatever to upload and debug?)

I would like to use Domoticz because of its popularity here in the MyS community, but I've given up every time this far. Lately because there seems to be an issue with Eth-Gws for other MyS-systems on the same network(?). And I've also noticed an annoying 2-3s delay from sensor reading to registration. And the UI doesn't feel flexible, lightweight and reliable. Too much like the Vera I used before. Not to mention other controllers "responsive huge white spaces UI style".

So, I'll continue with Fhem. A pain to master as non-German (nor Perl) speaking, but with a good feeling of old proven quality under the hood.

@royson84 Where in Sweden are you? Maybe someone near can help you.

@sineverba Just cut one of the battery wires of the finished assembly. Solder together again when your done measuring.

@Dick Since they are 'static' I think you only need to initialize them with 0 , maybe not even that. I simply dont know. Your problem could be something else too. Sorry.

@Dick I'm no code expert, but I would make the two lastUpdateTime-variables as global ones and initialize them with 0.

I experienced something similiar lately with a few my W5100 modules. It went away when I moved from my breadboard setup to soldered cabels.

@Dick You should use a non-blocking code. Replace your if ( motionsDebouncer.update()) {...} with an updateMotion(SLEEP_TIME); which could be something like

void updateMotion(unsigned long blockedMotionTime)
{
  static unsigned long lastUpdateTime;
  if (millis() - lastUpdateTime >= blockedMotionTime)
  {
	  if ( motionsDebouncer.update()) {
		int value = motionsDebouncer.read();
		Serial.println( "PIR " + (String)value );
		gw.send( msgMOTION.set( value ), true );
		lastUpdateTime += blockedMotionTime;
	  }
  }  
}

Never use sleep if you want to listen for incoming messages. wait is not good either since you expect button press. Buttons could use an interruptpin if needed, but it looks like your not on battery.

@Komaandy @siod
Did you try version 2.2 as in https://forum.mysensors.org/topic/6511/hc-sr501-3-3v-randomly-sends-tripped-when-radio-is-on/36 ?

@burningstone You probably want to find the root cause to this but, as a quick fix, have you tried software-blocking the false trip with an additional sleep before the interrupt-activating sleep? Something like sleep(3000); before the last sleep(...). I do it with success for my mini-pirs.