@boots33 Sure... It's not finished in that want to reverse some of the mods made in desperate attempts to isolate the problem, before realising the illogic of the range checking.
It's no different to any other pulse timer in function, and doubtless could be made more efficient by more knowledgeable people than I, but it is working flawlessly now which was the objective.
The original idea was that the Slave would sleep as per Gammon's I2C example, constantly available to be remote commanded, but as the switched off ADC stayed off after sleep I lost the battery reading which divider was running continually. Inserting a latching relay, it ended up remote powered up with the readings taken during setup, otherwise it is completely off.
It's a straight 5v promini chinese clone with only the power led removed, powered by 4x2AA cells via a latching signal relay, as it is only fired up every hour by the sleeping Master, it should hopefully last a while...
Might extend the cycles to 3 or 4 hours, but for now it is feeding back accurate information on groundwater intrusion which has proven a bit of a surprise...

// Adapted from Nick Gammon tutorials from 18th February 2011
//ADC disabling prior to sleep failed to restart originally and written out

#include <Wire.h>
#include <avr/sleep.h>

const byte MY_ADDRESS = 61;
const byte AWAKE_LED = 13;
#define echoPin 5
#define trigPin 6
#define USon 4
#define BatteryIn A3
long duration;
int distance,test,test2;
const unsigned long WAIT_TIME = 500;
volatile unsigned long counter;
volatile int ultradepth, batterypower;

// various commands we might get
enum {
    CMD_READ_TANK  = 2,
    CMD_READ_BATTERY = 3
    };

char command;

void setup() 
  {
  command = 0;
  pinMode(USon, OUTPUT);
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  analogReference(INTERNAL);
  digitalWrite(USon,LOW);
  digitalWrite(USon, HIGH);
  delay(100);
  digitalWrite(trigPin,HIGH);
  delay (100); 
  digitalWrite(trigPin,LOW);
  delay(100);/// Allow decay of pulse
  READULTRASONIC();
  READPOWER();
  Wire.begin (MY_ADDRESS);
  Wire.onReceive (receiveEvent);  // interrupt handler for incoming messages
  Wire.onRequest (requestEvent);  // interrupt handler for when data is wanted
  delay(150);
  }  // end of setup

void receiveEvent (int howMany)
  {
  command = Wire.read ();  // remember command for when we get request
  } // end of receiveEvent


void loop (){
  if (++counter >= WAIT_TIME)
    {
    flasher();//1 flash signals going to sleep
    set_sleep_mode (SLEEP_MODE_PWR_DOWN);  
    sleep_enable();
    digitalWrite (AWAKE_LED, LOW);
    sleep_cpu ();      
   
    sleep_disable();
// release TWI bus
    TWCR = bit(TWEN) | bit(TWIE) | bit(TWEA) | bit(TWINT);
     for (byte i = 0; i < 3; i++)
    {//3 flashes wakened up
    flasher();
    };
// turn it back on again
    Wire.begin (MY_ADDRESS);
    
}
}

 void READULTRASONIC(){//JSN-SR04-2.0
  digitalWrite(USon,HIGH);
  delay(100);
  duration=0;
  distance=0;
  test=1;
  test2=3;
while ((test!=test2)&&((distance<300)||(distance>1860))){// Get two consecutive readings in specified range
  digitalWrite(trigPin, LOW);
  delayMicroseconds(100);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(150);
  digitalWrite(trigPin, LOW);
  duration = pulseIn(echoPin, HIGH);
  distance = duration/5.82;//This is in mm
 if (test!=distance){
    test=distance;
    distance=0;
   }
   else{
    test2=distance;
  }
  delay(100);///// 500 originally but why???????
  }
  digitalWrite(USon,LOW);
  ultradepth=distance;
 }
 
void READTANK (){
  byte buf [2];
    buf [0] = ultradepth >> 8;
    buf [1] = ultradepth & 0xFF;
    Wire.write (buf, 2);
}/// end of READTANK

void READPOWER(){//Still needs cap on resistive divider
  int val, read1, read2;
  read1=1;
  read2=2;
 ///Get two consecutive identical readings
  while(read1!=read2){
  val= analogRead(BatteryIn);
  if(read1!=val){
  read1=val;
 }
  else{
  read2=val;
 }
 }
 batterypower=val;
}

void READBATTERY ()
{// Battery reading send now
  byte buf [2];
  buf [0] = batterypower >> 8;
  buf [1] = batterypower & 0xFF;
  Wire.write (buf, 2);
  }  // end of READBATTERY

void requestEvent ()
{// Original which parameter removed
  switch (command) {
     case CMD_READ_TANK: READTANK (); break;  // send Tank Depth Reading
     case CMD_READ_BATTERY: READBATTERY (); break;   // send Drone battery reading
     }  // end of switch
  }  // end of requestEvent

  void flasher(){
    digitalWrite (AWAKE_LED, HIGH);
    delay (20);  
    digitalWrite (AWAKE_LED, LOW);
    delay (50);  
  }

EDIT - With playing around with so many variations, I had copied the wrong sketch version here, now resolved.
One of the more frustrating aspects I found in this setup was instability, presumably due to Wire interrupts or a dodgy connection somewhere. The Slave would in isolation get a valid figure to forward, yet somehow the Master would pass completely different figures to the Gateway or everything would lock up.
One curiosity noted was the delay between the Master powering up the Slave and requesting results over Wire, it worked fine with sleep(5000), but 1000 would introduce instability.

@boots33 Indeed, but it took WAY longer than first thought when it all started off..

Much of what I had read were horror stories of what could go wrong, poor QC in manufacture, bad copy designs, voltage sensitivity, echoes in installation, different libraries, different communication methods, etc., a multitude of reasons for failure and to a degree full expectation of it.
All of these were systematically tested, as it turned out, completely erroneously... The DUH moment of realising my own illogical programming was cause for wasted months of modifications was quite chastening...
Now that it is fully reliable I might slowly reverse interactions to see what if any effects there are, as it is simple enough to do in this particular setup.

The one justification I could not get my head round as it simply made no sense was Echo, and it has been cited many many times as cause for bogus values, generally yielding short range results. The argument relies on a side reflection of reduced power somehow overcoming the main emission. As an echo in reality is a decaying wave it set me off looking for where it could originate...
Examined several example sketches, and many had a PING 10 microseconds before the principle PING to be measured. In testing these sketches, the majority were strange readings with a periodic correct one. Commenting out the preceding 10microsecond PING, and leaving a 100ms silence for complete decay prior to the main PING, and BINGO, the majority reading was the correct one.
The routine deployed here only accepts two consecutive readings fitting within a range anyway, so any bogus values picked up are discarded....
In short, anybody thinking they have an ECHO problem would do well to examine the sketch to ensure the previous pulse has fully decayed and the environment falls completely silent before taking a reading.

Just as a follow-up to this - I am very aware a lot of folks have had problems with these ultrasonic boards and their various iterations, had plenty of WTF moments myself in the evolution of this particular end, and thought to make a few observations which might help some..

First I should explain the environment - The button type transducer (long cable leading to the board a la parking sensor) is inserted into the tank projecting below the soffit (underside of roof) of a RC slab by 70mm on the end of a pipe, held rigidly and pointed straight down at the bottom of the tank from a central position. The tank is 1.34x1.67m reinforced concrete construction with not so shiny smooth sides, the chamber is sealed including the access hatch so zero absorption of sonic emissions, only natural decay essentially an echo chamber...
Depth is 1.86m max to a bare earth floor when empty and it is never empty, sensor reading is on a straightforward timing routine of Low/High on the pin, the classic pulseIn...

Went through merry hell with the early results, and grasped at a swathe of potential issues - power limitations from the power on a pin/Wire interfering with the process/the RTC causing chaos by asking "Who are you?", the alignment of the planets, I was clutching at straws..... Tried every conceivable variation with the exception of planetary alignments, every time a failure...
Only when the eventual idea to run the ultrasonic routine in setup (one shot) and storing the value in RAM (viable on this installation), did I discover the same results and my own stupidity of having inverted level constraints, think 300<>1860 v <300||>1860.
Once the illogic of the while statement was straightened out, it performed rock solid, spitting back results appearing on Domoticz within 25 seconds, range 1.45m, not a single failure...

So JFS&G, ran a test to see how long it would take to establish two consecutive bogus figures out of potential range.. The first took 6.7 hours, the second <1 minute, third 35 minutes, fourth 5 hours, but what I found curious was the effect of varying delay before the next sample... My only guess was that irrespective of (unlikely) erroneous reflections, perhaps decay of the previous pulse was being detected, hence a full yet empty tank... Extending the delay between pulses with the bogus range is what drove the 6+ hours event, it took WAY longer two establish two consecutive screwups...

So put it all back to original settings, and it has been spitting back results every hour give or take a few seconds, spot on, and very well pleased...

It was not faulty cheap chinese anything, or physical environment which cause my headaches, it was my own stupidity...

@crankycoder

@mfalkvidd Is this #3 of same question?

Surprised I'm not bald will all the hair pulling and failed attempts to get there but after a year it is finally working...
The task was simple enough, to measure fluid depth in two tanks, one a sewage holding tank, the other a bulk water tank. Just figuring out which method worked with which board was an exercise in frustration, but the JSN-SR04-2.0 turned out the only one of the two I could get to reliably work.

Despite the industrial look, these waterproof light switch enclosures proved ideal, as the batteries in holders fitted beneath the clear plastic. A little hacking out of the switch 'fingers' with a Dremel gives plenty of space in the base area.
Battery holders are held in plastic conduit which are hot glued to the back of the box poking through the front section aperture.

The top case is a 3v3 WhisperNode with onboard RTC and RFM69, and tucked under the spaghetti in the top left back corner is a level converter. The RTC wakens the Node every hour to initiate readings, and despite a few hiccups seems to be reliable. The WhisperNode is allegedly capable of draining the 2 AA cells down to 0.9v, time will tell...

The lower box holds the 5v ProMini, a small latching relay, and the ultrasonic board, the button type ultrasonic (like parking sensor) is mounted on the end of a 3/4" collar to 1/2" galvanised steel tube drilled centrally through the roof of the 1.34m x 1.67m tank area.

Connection between the cases is via Cat5e in 16mm conduit, 2 cores for I2C, 3 cores for relay control and 3.3v power, 2 cores for 5v and ground to the level converter.

Despite worries over echoes in the resulting space, the tank was emptied last night, and the reading is coming in with the occasional glitch at 1620mm depth from the head, which I believe has a cone angle of 45 degrees.
The Node control of a Relay by On/Off pins to Mosfets may seem wasteful, but I had them anyway. The 5ms on/off of this small latching signal relay boots up the ProMini and seems reliable.
Still to incorporate a WDT/Reset on the 5v as it periodically hangs, and a time limiter on the Node to complete the task, but glad it is all all working semi-reliably, even if some of the programming side I still don't understand...
The 5v tests for 2 consecutive identical readings, the 3.3v tests that it fits within acceptable range, and if not calls for a further reading.

Once delivery of a second identical board from China is done, the water tank should be a lot easier. This one is the more important, as ran out of water previously due to corrosion of the level probes in the tank (3 core cable and short bolts) which stopped the borehole pump topping up the tank, and the hidrofor hit it's cut-off electrode. The level monitoring will give early warning to go investigate long before the bulk tank is 'empty'...

@gohan Nope, hourly measurement is quite sufficient.
I had bought two of these with onboard RTC to pass time control to the DS3231M and let the Nodes sleep, at the time it was purportedly energy advantageous.
I'm aware I could have used a non-RTC version and a sleep time, although have yet to succesfully make sleep for an hour for some reason, yet 30 minutes is no problem.
Just puzzled how it should be deployed, hence the query..

Wondering if someone can enlighten me on the use of FabioCuomo's RTClibExtended library for the DS3231... I have enough headaches trying to fathom Arduino, my understanding of RTCs is like a black art on top..
I have a 3.3v 16MHz Arduino node with onboard DS3231m and radio module. The objective was to have the RTC wake the Node via INT1 every hour at xx.55 to initiate measurements and go back to sleep. It got WAY more complicated than first thought, as ended up with one 5v Arduino doing the measurements and passing it to the 3v over I2C, another learning curve which was "interesting"...
After several fumbles trying to use different libraries and examples, I stumbled across this particular library and the wakeup_alarm example, which appeared functionally to offered a good solution.
However, in wakeup_alarm, the routine had 3 distinct calls ending with the RTC.alarmInterrupt, then setting an AlarmFlag byte which sent the routine via a conditional statement into an endless loop, like a one shot alarm.
I understand the purpose of setting RTC.alarmInterrupt back to true prior to going back to sleep, but the armAlarm and clearAlarm calls seem contradictory where the alarm is intended as repetitive, unless the alarm time declaration is to be made again and these two set back to true prior to sleep...

//First clear the alarm
    RTC.begin();
    RTC.armAlarm(1, false);
    RTC.clearAlarm(1);
    RTC.alarmInterrupt(1, false);
  }  // end of loop```

@zboblamont After a lot of headscratching I solved part of this puzzle and feeling a little stupid. Nothing to do with Library conflicts, both Wire and softwareSerial work as they are supposed to, the level converter works perfectly, it was a combination of sketch issues and the manner in which sleep was invoked on both Master and Slave, as well as a problem ultrasonic board.
1 - The DYP-ME007Y I could only ever get to read on a Russian developed sketch using softwareSerial. Although I got the reading once, the Slave was locked in an endless loop in the background, never going to sleep or giving the battery reading. By doing the ADC battery measurement first at least I got both readings, but with the Slave running endlessly even with the ultrasonic board shut down, it was killing the batteries.
So I gave up on that one and switched to the second tank which uses time of flight calculation, readily incorporated as a function. This time I incorporated LED flashes so I could see what WAS and was NOT happening.
2 - The JSN-SR04T-2.0 Slave went to almost immediately per Gammon's sleeping Slave routine, would waken when prodded, but would not return a battery reading. The problem lay in Gammon's preparations prior to sleeping the Slave, where he turns off the ADC, but it remained off when awake. Commenting out the ADC shutdown at least solved that issue for now, at least the Slave gave the required readings and went to sleep, but... it never started again.
3 - The Master was going to sleep but never wakened on the onboard RTC alarm set to Int1. Switching to a straight Sleep period did not work either, until it finally it dawned that the Wire service may be interfering. Only when Wire was shut down and re-invoked after wakeup did both Master and Slave sleep and awaken as intended.

Left it running overnight, and it has been consistently reporting every 30 minutes, so will look again today at getting the DS3231M to work properly on the Master and read how to restart the ADC on the Slave.

Frustrating as a relative amateur, but lessons learned.
If there is no function to interrogate the DYP ultrasonic, may just order another device from China and hope it proves simpler, cheap enough even if it takes a month...

@wallyllama The converter was put up next to the 3v for that reason, the 5v degradation would be less an issue.
Subsequent to the original post however, now getting partial result in that the converter is passing on the battery status, so the problem does not seem tied to the converter but the programs being too long and with delays which clash with interrupts on I2C, and the timing aspect of both ultrasonic devices.
It certainly screws with SoftSerial for the DYP sensor, now looking at alternative comms...