@markjgabb "..cut back all unneccicary steps and really locked down what was going on.." was indeed the idea.

What I went on to explain is than you are reporting the state of D3 which goes HIGH/LOW/HIGH via the button, not the light. The critical difference between @skywatch and your install is movement detection maintains a value, your button does not.

If you create a variable before the loop, say boolean lightswitch=false; (presuming that the light is ON when you program it) this variable will be changed and reported to Domoticz in the loop.
Top of the loop you toggle the "lightswitch" value, first time it will switch false to true, report in the "lightswitch" value then go to sleep.
Bottom of the loop your " sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME); should trigger on a LOW, as this is the momentary state of D3 ONLY when the button is pressed.
Your next button press activates the loop, toggles "lightswitch", reports and goes back to sleep, at least two years on a pair of AA cells.

Were it I doing this there would be a mains powered indicator on the switch plate which cuts out when the light is on, A- To find the switch in the dark, B-To provide an indicator which can be used to verify the actual state of the light to ensure it stays in sync (Murphy's Law).
I don't see the point of using heartbeat as it is not a security device, and only fire the battery reading mosfet every X loops.

@markjgabb Wasn't thinking about shortening the battery read but // it out in the loop meantime as it is only a local serial output. Whatever..

Ok on the intent, then what you are doing is "illogical", you are reporting the state of the switch not the condition of the light.
What you need to do is toggle a separate logic parameter on the Node for a LOW interrupt at the Node, switching ON/OFF the light, report that separate logic state to Domoticz then go to sleep... The interrupt only initiates the action, the Node reports and stores the current state until the next interrupt, Domoticz tells you the last reported state.
Whether you control the light at at the button switch Node with a latching relay or command a separate Node is up to you, but Domoticz only reports the last known state...

@markjgabb Domoticz should display a binary On/Off according to what it is sent, so suggest looking at the Domoticz log for incoming messages, I suspect the OFF is not being sent. Why you are using a Domoticz switch with an off delay I don't understand, a simple on/off is what I use.
In your modified @skywatch sketch the loop contains battery measurement batM() which itself incorporates a half second delay and Serial.print, suggest rem that out in the loop for now leaving the main loop to work with perhaps a 5 or 10ms delay if the switch is not debounced electrically.

A momentary rather than latching switch allows a very fast change of state in the region of milliseconds, quite different to a real world device running seconds/minutes/hours in one state or the other.
In your case you are looking at the interrupt as CHANGE, then reporting the digital state of the pin, any old toggle or light switch would do.

@neverdie My query was that having read @skywatch previously failure with WDT, whether an external device offered a different methodology which the soft version did not address.
Never experienced the problems these lads are trying to resolve as use different comms hardware which are 100% reliable, so no need to learn about WDTs. As I understood it the WDT initiates a reset, which if it clears the problem through re-initialisation implies a lockup on the comms to the NRF or within the NRF itself, since the processor and sketch should be fairly standard.
Why SOME have problems but not others is a curiosity.

Perhaps if you power a Node with a PSU with battery backup you can detect if the mains fails that way?
That is the arrangement I have with the central heating boiler as it senses the 24v relay differential which reduces to zero when the contacts close. As this would also result from power failure, the Node monitors both VIN and Vrelay to verify Power On/Fail, Boiler On/Off....

@encrypt "making the ATMEGA328P wake up only when it gets an interrupt from the itron water sensor (= 1L consumed) seems to be a good idea" works for me for two meters and two timer activated ultrasonics.
Once you have that interrupt working reliably, only then I'd consider looking at power options. My Elster water meter (similar Itron) is now into year 3 on two AA alkalines, it makes no sense financially to consider solar, but as an experiment, sure, good luck...

@neverdie No offence intended, but I gathered watchdog was tried and failed on at least one installation, it appears to be the NRF comms medium itself which is common to both complainants, neither of which your setup uses.
Or were you suggesting an external watchdog (if not already trialled) might shed some light on their issues?

@skywatch "A DC/DC ups is on my todo list..." - After one of the frequent power cuts here finally screwed up the HDD and Domoticz, the DC/DC UPS finally came off my to-do list. The Gateway/Controller has sailed through many outages since, and luckily only lost 10 days data and battery voltage on the Nodes, presumably retrying calls to a dead end. As with backups, lesson learned.
MySensors and Domoticz were my initial objective, and having established the crude limits where my mobile could pick up Wifi outside, that cast doubt on 2.4GHz comms, and problems reported by some others convinced me to go with the RFMs in preference to the recommended NRFs. 433MHz offered simpler protocol, better structural penetration, and occupied a less "busy" part of the spectrum.
The router through which I access the Pi suffers an occasional brainfart which I cannot fathom but tolerate as it's non-critical, unlike Node/Gateway comms.
Not knocking NRFs or 2.4GHz or MySensors, plenty happily use this combo reliably, but problems such as @Nick-Willis and yourself were what put me off it at the start.

@nick-willis I realise this helps neither you nor @skywatch over the technical issues faced, but perhaps a change of band may be worth considering?

Despite reading about the many perfectly reliable setups when I started out over 2 years ago, it was the problem ones and ever crowded Wifi which swayed me away from the recommended NRF toward rfm69s and 433MHz. Not a single problem aside power failures on the Gateway, but the battery powered Nodes always recovered 100% on restoration of power to the Gateway, now solved permanently with an UPS.
After 2 years, I'd have given up and thrown something in the bucket...
Good luck.

@dmacros My guess would be noise, I had similar problems when I tried using a 5v booster only for the JSN, the boards seem quite "temperamental" over voltage supplies.
I understood the Wemos to be 3.3v logic anyway, so powering the JSN off the 3.3v pin would be normal, and the regulator should kill noise sufficiently to allow the JSN to work reliably.

I have two of these installed, one works perfectly on 3.3v to maximum range, the other has problems at maximum unless fed 5vDC from a battery, yet fine for closer range (<1.5m) at 3.3v.
Have ordered another JSN in hopes it is better behaved at 3.3v, it must be a QC issue...

Today the second (troublesome) one is working at range on 3.3v, but it is not reliable. I have it try max 10 times (I think) to get a valid reading every hour, so it does not kill the batteries much.
Whether yours will work at 3.5m or not you can only test, but having a mains supply means battery power is no barrier..