The pinchange interupt works fine.

I found the offending things on my board. It was a combination of a couple of things. First it was the BME280 that was constantly active. Change to forced mode dropped the consumption from 0.4mA to 0.1 mA. I stopped using the internal pullup for my windspeedsensor which is based on a reedswitch. I noticed when the switch was open the consumption dropped to 0.04mA so I mounted a 1Mohm resistor instead of the internal pullup. Turning off the ADC dropped a about 10-20 uA. And lastly it seems that my nimh batterys where bad. They could not keep the charge. Changed to 2 x aaa and now it looks better.

Current now on average 0.035 mA in sleepmode

I will buy new nimh's to see if my solar panel circuit will work as expected. I hope to keep it running for about 5 years without changing the battery.
Only time will tell now.

@scalz

The snippet of code in my previous post isn't the whole code. This is a bit more of the code (the loop section),

  while(!isTransportReady){   //kolla om allt ok för "sleep"
    _process();               //om inte så kör processen som styr biblioteket
  }

  transportPowerDown();   //Stäng ner radion
//  Serial.print("Gonatt :");
  asm("cli");
  sleepcounter++;
  asm("sei");
//  Serial.println(sleepcounter);
  Serial.flush ();    //vänta på serial skall bli klar
  WDTCSR=0b00011000;  //Starta watchdog timer interupt på 1s
  WDTCSR=0b01000110;
  SMCR=0b00000101;    //Välj powerdown mode
sleep:
  asm("sleep");
  if (pinchange){     //Om pinchange är anledningen till vakna så sov igen
    pinchange=false;
    goto sleep;
  }
// Här har det gått en sekund skicka nya data om det behövs

  asm("cli");
  TCNT1=0;            //Nollställ cykelräknaren 
  asm("sei");
  sendwind();
  sendbattery();
  sendtemp();
  sendrain();
  sendsolar();
  sendfail();
  asm("cli");
  cycle=TCNT1;
  asm("sei");
//  Serial.print("Cykeltid: ");
//  Serial.println(cycle*8);

But it seems to consume to much power.

The pinchange interupt fires fairly often but the mcu is mostly awake for about 120 cycles every second. So a drop of 0.2 Volts in battery in under 18 hours seems a bit high. This on a 3.3v pro mini at 8MHz.

@mfalkvidd
I will look into using your suggestions when I have the time.

Regarding using my code in the library I don't see it beeing an option. The reason is that I'm an amateur programmer and as such I dont know all the "rules" on how code should look. In swedish as you know we have the term "spagettikod" and thats kind of how my code looks. I'm from an assembler background and and there I'm used to "slap some thing together", poking in registers directly and such.

I'm having trouble with high current consumption in an battery operated node. I suspect the NRF beeing the offending part. How can I be sure I have put the radio to sleep? I don't use the sleep() command because I use pinchange interupt instead of INT0 or INT1. I put the cpu to sleep with my own code. But how can I be sure that the radio has been put to sleep?
In the code as it is now I use,

transportPowerDown();
asm("SLEEP");

But I'm not sure that the radio is put to sleep.

Excuse me for beeing an idiot. But how do you compile the bootloader from source? Do you do it from Atmel studio or from Arduino IDE. And how is it done? When I compile it in Atmel studio it gets an base adress of 0x0000 which is wrong.

I am used to program in assembler in Atmel studio and when I program in C i don't touch anyting else than the .c file. So some form of tutorial kind of thing would be helpful.

Thank you

@novicit If I remember correctly i put it here: https://github.com/mysensors/MySensors/blob/master/core/MyTransport.cpp#L463
just to test that it worked. Then I removed the change to keep the library source original.

I turned on debug again to get it working again.. The reason why I wanted to have debuging disabled was to keep the hexfile size down so the OTA update wouldn't take so long time. I hope this issue will be fixed in a more elegant manner in a future release.

I have also problem with speed of the upload. I get about 1 packet per 3 seconds. Is there a something in the code for the bootloader that has a waitingtime of 3 seconds? And if so, because of what? From that info we might be able to tell if it's a reception problem of the node or the gateway.

@mfalkvidd After Little more investigating and experimenting I am pretty sure I have found a bug in the library. I found that when debug is active all is working as expected. But if I commented out debug it starts to not work. I tried it about 10 times, once with debug and then without. And everytime debug is active it works, no debug it fails.
I opened the transport sourcefile and added a delay(100) at the procedure where the debug message is sent. With that change it works everytime with or without debug. It seems that if the ackmessage is sent to quick it gets missed by the gateway. Any thoughts on this?

Having checked the serial output from the new node at my computer I see that the library returns the command when a ACK i requested. I also looked in the sourcecode for the library and it seems that it handles the ackmessage.
So it seems that the ACK message get missed in the recieving node. Why, is the next question.

Investigation continues...

I put together another node exactly the same but keeping it at my workbench roughly the same distance from the gateway. It works without any troubles so far. The only change in the sketch is the node id and no ds18b20 temperature reading.
The log from myscontroller show that it works even if the node doesn't send back the same status as the command. Domoticz doesn't complain as it does with the first node. This behaviour was last night.

Now this morning the replys from the new nodes is also present. They weren't last night. At least not in the logs from MYScontroller.

When domoticz sends a switchcommand to the gateway it does so with with ACK flag set. Does mysensors library automatically reply?
I haven't programmed in a replyfunction in my sketch so it seems like it. But in that case why doesn't my first node reply every time?

Strange. Have to investigate this further.