Hadn't seen this mentioned but perhaps I missed it, more plumbing hardware than electronic, but perhaps useful for others.
Having tried a variety of plates and heat-sink compounds and tie-wraps to hold these little chips in position on small sections of metal pipe (my rads are fed with fused plastic pipe), I came up with the solution of using pipe clips, the cheap plastic variety from DIY stores and hardware merchants.
The first problem hit was with attaching plated sensor the the boiler clamp nut, it was off by 10c and no way could I get a more accurate reading, presumably angle? Finally found a pipe clip which got hacked in half to fit in the tiny gap in the photo... Some hacking with a Dremel, some soldering to a pin connector, some fiddling around with epoxy and voici....

The gap
The tie wrap in the top of the photo is the original plate mounted version which was "off"..

Having scored on that front with more reliable readings I looked at the roving radiator test kit and realised the same solution might apply so epoxied the chip on the end of some telephone line in a 22mm clamp and it works a treat. Cable and chip fit neatly into the screw-hole, flood with epoxy and done. The pipe it fits is 21.5mm so tighter than a duck's rear end...

As said, a tight fit to a twinwall radiator feed pipe, and a complete swine to get back off even with pliers, but no broken wires or oopsies to contend with, and so much faster to fit.
For those looking to measure metal pipe temperatures, possibly an unusual if fiddly solution, but no need of tie-wraps in the latter case...

Not so much a MySensors build as an example of how even the most basic information can inform changes for the better, in this case space heating.

The system here is fairly basic, an array of DS18B20s, some ultrasonic tank probes and a gas reed sensor, temperature is updated every 5 minutes, the gas updates every 0.05m3...
With winters here down to -20, the first priority last year was insulation, and even though a modern house, the gas bills essentially halved over the year, effectively funding not only the insulation, but replacement axial radiator valves and thermostat heads (Heimeier) to replace the typical arrangement of unknown origin, with spare... But now the MySensors impact..
This autumn's attention turned to the central heating unit, a modern combi unit of good manufacture, installed by a 'certified' heating engineer, but aside what little I knew about condensation boilers and the steep learning curve that followed, I was bemused by the return from the radiator loop almost burning my finger within 10 minutes of the system being fired up. This did not make sense for what I understood of a condensing boilers, which compelled a look inside for the first time, the manual and some googling.

The boiler is a 25kW combi with minimum output 7.6kW, the radiators account for ca 13kW at Delta 60 set for 15c drop (previously set ca 20c drop), settings since day one were 65c and the pump was set at max output of 3, last year's -20 resulted in 13.5m3/day gas consumed, not crazy by historical records, but hmmm.
So now comes tinkering with data from MySensors via Domoticz to inform...
Currently the boiler is set at 55c, the pump is on Low (40 v 84w), but the results are surprising - Slower rising temperature when ON, 42 minutes v 25, but gas use dropped from 0.75 to 0.6m3, but here's the kicker from that longer heating time, not only less energy used per cycle, but longer and thereby fewer cycles per day. Current evaluations are between 15 and 20% savings, so thank you to all the MySensors community and contributors..

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

Postscript 12/7/18 - Water tank worked flawlessly from first deployment, but led to concerns over dropping battery voltage.. The problem appeared to lie with the Master sinking power through the I2C lines, but a routine to null the SDA/SCL lines prior to sleeping seems to have halted the decay.
One of the unexpected results of the Sewage Tank deployment was detecting a dramatic rise in level during a heavy storm (85mm in 24 hours) initially thought to be ground water intrusion.
Excavation to the incoming pipe connection to the tank found a round pipe in a square hole (not exactly an unexpected building practice here, now packed out and sealed.
Losing 30% of storage capacity would otherwise never have been detected, so it the deployment has already paid for itself handsomely...

@pepson This reminds of that famous quotation "Any ship can be a Minesweeper..."
"Once...."

@neverdie Would this work ?

@sundberg84 Yeah, this brings back memories, particularly of quite a few hangovers.
I used 3 and four wide fireclay pipes for bottle storage, they were used for ducts back in the day before plastics took over, cable went optic fibre. I noticed recently here they are back in stock in stores as....yep...wine storage racks.... but wacko pricing relatively...
The beauty of the fireclay was it's slow temperature and humidity change, and this formed the bulk of the thermal mass in the cellar I made below the floor.
I used a 150mm glazed ceramic drainage pipe dug in under the garden as a loop (rope caulked joints - anybody remember them), from memory down about 1.5m, both avoiding frosts and baking sun, don't think the temperature varied over a degree all year round, the ground acting as a massive heatsink which maintained a constant temperature all year round.
Only when the hatch was opened did the temperature jump, a small fan kicked in when the hatch was closed and ran for 30 minutes, a second contact switched on the lights and shut them off, long before LEDs were so prevalent, old reliable (until you were depending on them) incandescent bulbs.
That was it really.
Biggest problem I found was humidity in the early days, probably the fresh construction...

@tbowmo Hah, you were lucky, I finally upgraded from the monochrome to colour...

@sundberg84 Easy, one is disconnected... At 90 degrees?

Finally the round-tuit UPS got built after the last power cut clobbered the Controller/Gateway system, lesson learned...
Meanwell AD-55A, 7.2Ah Acid gel battery, two usb 5v buck converters, a spare socket for raw volts, and a 15 euro IP66 box from the local shops.. Some drilling and filing to the lid, couple of brackets, spare bolts, banding, soldering and hot glue...
A bit bulky, but disappears in a void under the stairs, two tiny drill holes let the buck converter leds shine threw...
No monitoring as yet, but sailed through a power cut this morning and the Pi didn't skip a beat.. First up is the Pi's RTC then can put the cover back on the Controller...

First of the winter projects done, just the programming to finish and replacement temperature chips to get (broke the legs off both DS18B20s through clumsiness).
With mains/battery backup and RTC, it will record boiler start/stop and run times as well as feed/return temperatures, and as an aside the inevitable power cuts which plague this part of the world.
The MCU plugs into a socketed backplane hot-glued to the back of the box should removal prove necessary, but quite pleased it is sturdy and all fitted into a slim 25mm deep standard (cheap) box.

@Tmaster Never assume the original PCB was just a circuit of components, the PCB can incorporate RF shields and antenna radio ground planes...

@zboblamont OK, so experiments concluded that the return data from the latest version of Domoticz is a String whether it be V_VARx or V_TEXT.

I tried the dual declaration using the same CHILD_ID as intended and as VAR_X (using an RF24 - not sure of the relevance) and the actual value sent but failed to make any sense of abstracting the Ulong conversion or the string.
Only by presenting a fresh CHILD_ID and duplicating the send of data (water meter) as a V_VAR1 could I recover the last sent reading as a V_VAR1 from that fresh CHILD_ID, thence eventually arriving at 'strtoul' as a solution to restoring the last known value.
For clarity my Gateway and Controller run on a UPS, and I hope shortly to add the spare router to that UPS so I'm not left in the dark on what is happening in the dark on a battery powered laptop...
Hope this helps others trying to keep track of meters between relentless power cuts and reboots...

@Tmaster It would certainly imply the PSU or mains are causing noise to appear, but it could be on anywhere in the combination, but it's not necessarily at the rfm itself.
I'd surmise your problem is related to proximity of the psu or mains power.
eg - I have 3 un-shielded nodes with rfm69 variations running on 5v wall wart PSUs and battery backup and never had a single problem - The difference to your scenario is that the closest PSU and mains is 250mm away.
One has been running on an old Nokia "charger" and USB breakout now for 6 years straight between power cuts (and christ almighty we do get them) yet it is still going strong.

Perhaps reconsider your chosen method of supplying shore-power...

@Tmaster What I meant by my previous comment was to tap on the Node name to see what sensors were connected - Had you clicked on TANQUE you would have seen a box pop up below giving you all the children to that particular Node with what value was last updated and when, so you could easily have found out all about your mysterious 13 children.

At least you have it sorted now, but it pays to do a bit of housekeeping in the sketch setup and Domoticz - eg which of the 6 "Unknown" Nodes is the one you want to next have a look at ?

All my Node IDs are set at the Node, and the sketch name labels the Node ID also, the Nodes are named in Domoticz for easy identification.

In the sketch my sensors are numbered sequentially and commented on what they are, so naming them in Domoticz becomes very much easier.

@Tmaster Ah, didn't spot that...
My next thought was it was not enabled under Devices in Domoticz but you said nothing shows up, yet you presumably see that specific child updating on the Domoticz log at intervals ?

Have a look at Hardware, click Setup for the Gateway line, then the Node, and verify what is there is what is expected for child 99.

Something's not making sense here.

@Tmaster The problem cannot be your gateway if some messages are being passed but not others, it is likely an issue at the Node or has not been enabled at the Controller.

Most Controllers have a live log of what is coming in, and a devices table from which you can see what was last updated and when.

I suggest editing the Node sketch to print locally over serial to verify the results you are getting then investigate from there.

Long story short, what is returned by Domoticz when a V_VAR1 is requested back to the Node ? What was sent as a Long originally, or does it return a string ?

@Tmaster Oh well, told you it was a wild guess I'm using default settings of D2 here so never encountered the need to find out.
You need complete separation of the interrupts, I'm not sure the gyroscope will function without it.

Looking again at https://www.mysensors.org/download/sensor_api_20 for perhaps a better understanding, I note the explanation of both"#define" lines you originally posted which now makes sense. Pin D3 is indeed INT 1, so you were redefining both the pin and the interrupt.
So long as these are set before including the MySensors library it should indeed override the defaults.

Not sure if it's relevant, but could it be something to do with the rfm69 driver ? Many of the guides relate to the original driver.
I recently upgraded to the NEW rfm69 driver thinking it was more efficient, but with the Gateway and 2 Nodes reprogrammed, ended up with repeat messages and the system slowing to a crawl.
Reversing the procedure to the original driver restored system reliability, speed, and sanity.

@Tmaster Sorry, I should have been clearer, but I have little knowledge of the details

• I you do a search on Google (I haven't checked if the site search function has been restored) for that entire define statement you will land here https://www.mysensors.org/apidocs/MyConfig_8h.html
  Scroll down and you will find "#define MY_RFM69_IRQ_PIN DEFAULT_RFM69_IRQ_PIN" as one single line statement which I presume you append it with "3" to redirect the pin and solve your current problem - Perhaps try that first.

I've no idea what the "#define DEFAULT_RFM69_IRQ_NUM 1" does at all as it sounds like it's altering an internal RFM69 register.

@Tmaster I'm making a wild guess the define is wrong
See #define MY_RFM69_IRQ_PIN DEFAULT_RFM69_IRQ_PIN
Define this to override the default RFM69 IRQ pin assignment.