@Yveaux I am so terribly embarrassed! In order to rule out something wrong with the WS5100 I rebuilt the GW using an old Arduino UNO with an Ethernet shield. Still same problem. Then to really make sure I pasted/copied username and password from the cloudmqtt into the sketch. Immediate success! It turned out that I had misread an uppercase I (indigo) for a lower case l (lima). Still the suggestions from the community were good since I could iron out one possible cause after another. Thanks for the support!

Hi!
I had exactly the same problem until I realised I had compiled for the 8 MHz version of the Arduino Pro Mini instead of the 16 MHz version.
Also, recently building an humidity sensor I realised there are no pull-up resistors on the SDA SDL lines, but that should be built-in if you use a break-out module.

Hi!
Sorry to say, but the Arduino Nano may not be the best choice for battery operation and maybe the Motion Detector also is not the most power economic application. I guess, to start with you have not done any modification to the Nano like removing the power LED? There goes a few milliamps the whole time.

The PIR need rather high voltage to be stable and not generate random detects. I run mine on 8V. But the Nano needs only 5V so you burn off a bit of power in the voltage regulator chip, even if the sleep current of the Nano is very low. Of course, the more detections there are, the more power is used during the day.

The Arduino ProMini is a better choice for battery operation. Please see Battery Powering in the left-hand column on the MySensors site. There are a few tricks there to really bring down power consumption. Then again the PIR needs more than 5V so you will have to use a power booster if you use the ProMini 8 MHz version that runs on 3.3 V.

I think sleeping for 600000 mS will only marginally improve battery economy. I went through the same ordeal as you and I run my Motion Detector on a 9 V wall-wart.

For sensors that really work well on battery I would suggest Light, Temperature and Humidity. I have a few of these built around ProMini 8 MHz and they typically run for 9 months or more on 2 x AA reporting every 2 minutes, but if you look at the link above, people achieve much better results. But I'm happy with 9 months.

Best of luck and keep experimenting!

@pierrot10
Since I am using almost the same tipping bucket rain gauge, let me try to explain how it works:

The top of my funnel measures 109 x 49 mm = 5341 mm2 (square millimeters). For now, let us not worry about the rounded corners of the funnel.
If it rains 1 mm the funnel will collect 5341 mm3 (cubic millimeters) which is 5,341 cubic centimeters equal to 5,34 milliliters. This is difficult to use for calibration so let's try with 10 mm of rain which then equals 53,4 milliliters or 0,53 deciliters of water.

So, you pour 53,4 milliliters of water into the funnel, not spilling any and you count the number of bucket tips. In my example, when I do this, the bucket tips 30 times. So if the bucket tips 30 times during a time period, it has rained 10 mm during that time. Or, the other way around: One tip of the bucket = 10/30 = 0,33 mm of rain.

Do not worry about the size of the bucket inside. What matters is how many times the bucket tips for a given amount of water. It is the area of the funnel which is important.
When it rains 1 mm an area of one square meter will receive 1 liter of water but the little funnel will only receive 5,34 milliliters as explained above.

Now, if you really want to be accurate, you should take away the area of the rounded corners. But that will be less than 0,5% and there are other sources of inaccuracy.

I think the reason is that you have not set a node ID. At least this is not visible in the sketch.
OpenHab does not hand out node IDs. I have good experience.
You should try setting
#define MY_NODE_ID 1
In the beginning of your sketch where you define Child ID.

Oops! I may have misled you.
The #define MY_NODE_ID 1 has to go into the sketch before you call #include <MySensors.h>

as pointed out in the description of the Library API definitions:
"Remember to set configuration defines before including the MySensors.h."
In my sketches I always do all the #define (s) first like below:

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_NODE_ID 23
#define BATTERY_SENSE_PIN A0  // Input pin for battery sense
#define VMIN 1.0  // (Min input voltage to regulator according to datasheet or guessing. (?) )
#define VMAX 3.22 // (Known or desired voltage of full batteries. If not, set to Vlim.)
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
 

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

#include <SPI.h>
#include <AM2320.h>
#include <Wire.h>
#include <MySensors.h>
// Rest of code goes here...  

@capibara
Yes, you are getting there!
The topic prefix is just as you say defined by the #define statement.
The rest of the topic is defined as described in the API definition (Serial protocol) so:
/node-id/sensorchild-id/command/ack/type/
The content of the message is the payload.
Example: this is copied from my GW:
ib9sensors-out/21/2/1/0/4 1014 => So the sensor id is 21/ the child is 2/ this is a "set" message/ no-ack/ payload type is V_PRESSURE. The content of the message is 1014 which is just the atmospheric pressure here today.
I recommend using an MQTT client test tool like MQTT.fx It helps a lot when debugging.

I am not the right guy to answer how to re-define the topic structure. I guess you will have to do some serious work on the MQTT GW software.

@pierrot10
1 mm of rain over 1 square meter is 1 liter of water. Correct!
One liter makes 358 tips so one tip is then 2,7932 milliliters that is correct.
But rainfall mm/hr is 2,7932 * nbr of tips only if the area of the funnel is 1 square meter.

Your funnel is only 55 square centimeters so you will only collect 55/10000 of the rain that falls on the whole square meter.

The example you are using at the top of your post does not have the size of the funnel anywhere in the code.

@Patrik Söderström I think this is normal. Please check the Serial Protocol spec. under Download & API above to understand what the different elements describe. You should get this message once every two minutes if SLEEP_TIME = 120000 and you do not trigger the PIR. If triggered you should get 0;1;1;0;16;1 followed by 0;1;1;0;16;0 when the PIR resets. I built the Motion detector using the MiniPIR module above but I found that it needs at least +5V to operate reliably. Below 5V I think I remember that I got a lot of false trigs.

Ah! Sorry, misprint. Now using 2.2.0, not 2.0.0!

Let me offer my thoughts and recommendations:

For myself I have been using MQTT as the connection method for a number of years.

Doing that, you must have an MQTT broker as the "middle-man" to receive MQTT messages from the MySensors MQTT gateway and then relaying them to OH, which then uses the MQTT binding. Then you do not use the MySensors binding to OH at all.

The advantage is that you can have a number of sources/sensors feeding information to the MQTT broker. In my case I have three geographical sites with MySensors nodes, each with an MySensors MQTT gateway, feeding the broker. Actually at one of the sites there is also a Sonoff switch that also reports status and gets commands via MQTT. (I am using the Espurna SW on the Sonoff).

Then my OH installation subscribes to the broker via the OH MQTT binding.
To dive deeper into details, because of this geographical set-up, I am using a commercial MQTT broker, which is accessible over the internet from all three sites. If you only operate one site, then you are better off using e.g. Mosquitto inside your firewall.

As far as I understand the OH MQTT binding does not offer auto-discovery unless you use the Homie naming convention. Check the OH documentation please.

For MySensors nodes I use the MySensors notation so a typical message looks like: mqttgw1/28/3/1/0/0 23.2 for say, a node-ID 28 and child-ID 3 that reports a temperature of 23.2 °C

When I started using MQTT and the 1.0 binding I made all definitions in the .items text file but when I converted to MQTT 2.0 I have made all the definitions in the PaperUI. It is either/or depending on your preferences but I think the general recommendation in the OH community is to use the PaperUI.

If you stick with text files I strongly recommend that you use Visual Studio Code and the OpenHAB extension to VS. Then you get syntax checking and nice colours to all keywords.

As far as I understand, the MySensors OH-binding uses the ethernet or serial MySensors GW. Probably the set-up is simpler in the beginning but offers less flexibility in the long run. I could never have achieved my set-up above using just a serial connection.

I'm not very good with HA but in the GW sketch, to me it seems that you test if the Arduino is running on 8 MHz (#if F_CPU == 8000000L), which I guess it is not. So the #DEFINE MY_BAUD_RATE 115200 is never executed.

So then the GW runs at what baud rate?

Try to move the #DEFINE outside of the #if -- #endif and maybe set a lower baud rate, also in the HA .yml

@UglyKidJoe
I have been using OpenHAB and MQTT for a number of years now.

The reason for using MQTT and not just a serial connection from the MySensors GW is partly the flexibility as many have stated previously here. Easy to test, using e.g. the mqtt.fx tool. If you want to know what is going on you simply connect to the MQTT stream and "snoop" on the messages.

Another reason is that I am running three geographical sites on one OH installation. OH is running on a NUC at my home. There is also an MQTT GW here. Two other My Sensors MQTT-GW are running remotely in two summer houses. The three GW connect over internet to a cloud-based MQTT broker and OH connects to the same broker. In that way I do not have to open any ports into my home network for access should I have had a local MQTT-broker at home.

Did you try commenting out #define MY_DEBUG ?
That might save you a few bytes.

OK!
Sorry but I cannot help you there. I don't know enough about the Serial GW. At least it seems OH is doing the right thing.

@Dawidi
Do you persist the relay states? This will make the previous state of the relays known after a restart of OH.
Check this information: https://www.openhab.org/docs/configuration/persistence.html

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.