Filtering the power lines on input and output is generally not a critical issue when it comes to the value of the capacitors unless you plan to produce a large number of boards when cost of components become the issue.

If you are looking for a trouble-free operation it is better to be safe than sorry and to be conservative in the dimensioning. So 10 uF on the output is better than 2.2 since it provides more filtering of low frequency noise. 0.1 uF is better than 470 pF since it provides more filtering of high frequency noise. 10 uF on the input also filter out spikes in the input power, should there be any, so that they do not pass through the regulator. It is good practice to have both a 10 uF and a 0.1 uF capacitor on the output since they have different electrical capabilities to filter low and high frequency noise.

So in essence, the value of filtering capacitors is not that critical most of times. Too little filtering could give you issues with the radio, which is sensitive to noise on the power lines. This is why there always should be a capacitor of at least 4.7 uF close to the radio power input.

Yes, I take five consecutive readings 100 ms apart and calculate the median value of the readings that fall within allowed limits. Off-scale readings are discarded before calculating the median value.

It has been running for two weeks now and seems to be accurate and stable.

@sundeep-goel
Oh! This sounds a lot like the problems I have had for the past year. Like @zboblamont I have been pulling my hair trying to find a solution.

The tank is a square profile septic tank, cross section 1 x 1 m. Access to the tank is through a manhole some 60 cm diameter.

First i tried mounting the sensor in the lid of the manhole but all the time I ended up with measurements like 20 - 30 cm, no matter what the liquid level was.

I then tried to mount a baffle around the sensor trying to limit the beam spread so that the sensor would not see the corrugated wall of the manhole. No luck!

Next idea was to increase the powerfeed to the sensor. First it was powered from one of the digital pins of the Arduino, giving some 4.x volts. So, thinking this was below specs, I built a circuit that gave the sensor proper 5 V as needed. No luck!

The final solution was to mount the sensor at the bottom end of a plastic tube, 30 mm outer dia and then feed the cable through the tube and out to the electronics. The tube is attached to the wall of the manhole using a plastic clip. Please see attached photos. Success!

So clearly my problem was caused by the sensor getting reflexes from the corrugated wall of the manhole.

I think this question is best answered by a chemist, not an electronics expert. I do not claim to know much about water chemistry other than it is very complex. Probably pool water does not have the buffering capacity as the buffer solutions do so the measurements are affected by all other chemicals, gases and stuff in the water. But again, this is just what i learned from my father who indeed was a chemist.

@Crumpy10 The sendBatteryLevel is a method included in the library.
How do you connect MySensors to OpenHAB? Do you use the serial GW or MQTT? What binding do you use on the OH-side?
I am using MQTT myself so I am not that much at home with serial or with the MySensors binding for OH.

@mfalkvidd
Yep, this is a great way of introducing errors that will be nearly impossible to find!

The line

float Vcc = readVcc()/1000;

should be:

float Vcc = readVcc()/1000.;

to start with. Note the decimal point! If read Vcc() returns a float, you cannot divide by an integer.

I did try another RPi but same result.

I have switched the 3G router to a TP-link Archer MR400 with built-in 3G modem. The 3G connection appears very stable with high signal strength. Still the MQTT MysGW drops out now and then, approx. once every two days. Connection between router and GW is ethernet cable. Since the GW is located abt. 400 km from home, I am not able to troubleshoot effectively.

So I applied brute force and set up a cron job that restarts mysgw once every 24 hours. This seems to do the trick. I am not disconnected for any longer time than that.

Strange though that I do not have to restart the RPi. If the issue is caused by the internet connection dropping out, the RPi seems to be able to recover. The GW however seems unable to recover from such a short interruption. So, something similar as @CrankyCoder has experienced.

That is my conclusion as well!

@alowhum
Could you post the code for the node please?