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

@Jalina-He Having re-read all 6 of your contributions since you first joined this forum 11 days ago to make sure, it appears you have no interest in nor experience of this hobby.

On your latest odd and final question I am prepared to answer - Plastic can be recycled when it is no longer of use - Batteries - The PCB is as good as the day it was installed - PCB's don't become (sic) overdued.

@Jalina-He Why would I wish to design a product when commercial manufacturers already manufacture them for other functions which can be re-purposed ?

I have no vested interest in Gewiss, but I do know from experience that these weatherproof light switch boxes work exceedingly well, which is why I first commented.

eg - My Gas meter node has been in such a box for 6 years now with no signs of any damage to any of the unprotected parts within it, or degradation of the plastics over 6 winters and summers - The only interruption to continuous service has been changing batteries or reprogramming the Node.

@Jalina-He I'm not sure I understand your question over position of the ultrasonic board - It is mounted forward to enable quick access/replacement via the hinged front access, there is no advantage to pushing it further back.

The hinged access door and the two parts of the box have waterproof seals - The clear plastic window allows quick inspection and to see what leds are blinking - The mounting points on the rear box are on the outside of the sealed compartment.
If Gewiss is available in your market I can totally recommend these waterproof lightswitch boxes.

@Jalina-He If that question was directed at me - No, it is not new, but 6 years old but as yet unused - You can see the original 4 module tangs still uncut through the clear plastic window.

• I bought 2, 3 and 4 module cases at the same time and tried slightly cheaper copies which failed over time (leaked, transparent plastic degraded), the Gewiss originals remain almost as new despite years of exposure to snow, rain and UV - Higher quality.
  eg - This is the smallest one used, a 2 module unit serving as a wiring junction box between the pump station and the Node, with an ultrasonic sensor control board mounted in the front section for quick swap should it become faulty.

@รอเร-อ I've used Gewiss modular light switch boxes for years and no problems experienced - Winters go down to -20 and summer up to 45, and no appearance of condensation.
The front section has a clear flexible plastic window which hinges at the top, the front and main box are separated by a gasket, by undoing 4 screws.
I separate the front from the back then cut off the modular catch tangs with a dremel to give more space.
Inserting the antenna down through one of the grommets makes it totally weatherproof.
If opening it up in damp or humid weather, I chuck in a dessicant bag before closing it to mop up any residual moisture in the box.

That's good news.

Moisture would not necessarily have damaged it permanently, it's more a case of humidity can play havoc with tiny electronics and wiring when it condenses.

The advantage of a weatherproof box in my environment is obvious, but it has advantage elsewhere as it's a controlled and sealed environment inside - If closed up dry it stays dry.

@Oumuamua Sorry but I've no idea - I didn't update the MySensors side of the system once everything on the Gateway and Controller were working perfectly 5 years ago - Only Domoticz updates on the Pi Controller have interrupted it, the arduino gateway and disc drive have run 24/7 through multiple power cuts on the UPS.

It does seems unlikely the driver is at fault given so many others updated and none have reported such a bug.

IIRC the new driver has to be installed on ALL devices using the rfm, so I'll update the Gateway in summer when swapping out the UPS battery and drive.

@Oumuamua I strongly suggest your problem is moisture related, been there done that.

My external nodes are all in weatherproof boxes (Gewiss surface mounted modular light switch box with the transparent hinged front cover - I dremel off the switch tangs) with a roasted clay desiccant pack thrown in to cope with any moisture which may creep in on the cables over winter, then the front is latched shut.

No oxidisation is possible so long as the box is weatherproof (sealed), as any internal moisture is absorbed by the desiccant (a reactivated silica gel pack will work) when you close it up.

My gas meter node was like that, running for 4 winters down to -20 and never skipped a beat - It was like new when I changed the batteries, and ultimately took it apart, zero corrosion.

It's an awfully convoluted way of doing things but suspect your error lies in misunderstanding calculations mixing ints and floats and something screwy with your resistor bridge - It is always worth checking the bridge with a multimeter and raw voltage to verify the expectation.
If you have 3v at the top of your voltage divider, you should be getting 0.9593v applied on the ADC pin which will be read as 892 against the 1.1v internal reference.

The easiest way I found was to define a multiplier needed to derive the raw voltage, in this case (((R1+R2)x1.1)/R2) - For your resistor arrangement the max you can read is 3.4404v before exceeding the 1.1v internal reference.
To reverse the ADC reading of 892 to raw voltage is (892x3.4404)/1023 = 2.9984 v.

Perhaps this is a simpler way to do it

float MULTIPLIER= (((1000+470)*1.1)/470);//Resistor bridge values in k and Vref
int sensorValue = analogRead(BATTERY_SENSE_PIN);
float batteryV = (sensorValue * MULTIPLIER)/1023.0; //Note the trailing decimal point on the 1023 for calculations involving floats

@Doubletop Thanks for that.
I haven't range limited the readings on this version (ie ignore bad results) but do check for two consecutive readings, thus far no bogus readings recorded.

In my own case, the 3v node had no spare pins, so had to expand anyway to avoid using to a second dedicated node.

Having read on the 5v returning stable results, went with a second pro-mini at 5v controlling the v3.0 (also enabling further expansion) running off a PSU, talking I2C to the Node.

My principal problem was winter condensation on the transducer head due to the pipe used, aside that the v2.0 ran two years before finally dying.
This time it's on plastic pipe and the v3.0 is socketed for easy swap should it go faulty, fingers crossed for a trouble free winter.