I am using OpenHAB 2.3 and in my experience OH does not assign node ID to the sensor at presentation.
You will have to assign node ID manually in each sensor sketch by defining as an example:
#define MY_NODE_ID 24

In my setup I connect from the sensor to an MQTT-GW that talks to the MQTT broker.
Then OH subscribes to the same broker and receives messages. Most people use mosquitto as a local broker, often on the same machine that runs OH.

OH recently released 2.4 where the MQTT binding is substantially updated so I recommend you read up on that before changing.

@robertjuric Hi!
For a number of years I was running OpenHAB with influx and grafana on an RPi and it worked very well but eventually I gave that up. A few months back I got a NUC, Intel Celeron based with SSD, $200 from China.

The reason for switching HW was that sooner or later, after a year or so, the SD-card would get corrupt. I would get all sorts of mystical errors. The response time increased and the system got harder and harder to maintain. I suspect that influx data storage to the card was the main culprit. Of course you can connect an SSD and move the system to that but it all got too complex and at the end I felt that the RPi in the long run would not provide the power needed.

Now I run OH 2.3 + influx + grafana under Ubuntu 18.04 and it runs very cool. CPU-load is almost never above 1%.
In my set-up I have two geographical sites with a number of MySensors nodes and some 433 MHz switches. They connect to an MQTT GW on each site. One is a 1:st gen RPi, the other is an MCU.

Since I then have two MQTT streams I use an external, commercial MQTT broker and OH connects as a client to that broker and subscribes to the various topics. I prefer this rather than setting up a VPN from the remote site, which would be an alternative to using the commercial MQTT broker.

If you only have a local set-up of course you could run your mosquitto broker on the same node as OH, influx and grafana. Personally I would still use a separate GW. I feel that this would be easier to maintain but I recognise that this brings one more node to the "closet".

Did you try MQTT.fx? I use that SW (free of charge) a lot when troubleshooting MQTT.

Start by checking that MQTT.fx really does connect with the MQTT broker. Then subscribe first to the topic #, which means everything. Then narrow down by subscribing to mygateway1-out/# and so on.

The latest version of MQTT.fx also has a Topics Collector that shows all topics on the broker as they arrive.

In my experience PIR sensor are very sensitive to spikes in the power supply, especially if you run them on voltages close to the lower limit. I feed mine with a separate +8 volt supply. If you run it on the same 5 volt supply as the ESP8266 you are almost guaranteed to get false triggers. The 20 seconds is probably the time after which the PIR resets. This causes a spike on the supply which triggers the PIR again. This happened to me.

Don't feel stupid! If I had gotten 10 cents for each stupid mistake I have done over the years I would be a millionaire now.

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

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.

@thecricketer
There are so many things to consider when selecting components but for us hobby-tinkerers there are a few that are most important e.g.
Max input voltage: Vinmax
Max output current: Iout
Size or package
Price

You will find all these answers in the data sheets. Normally available from your components supplier or else on the internet. Below is a simple table:

Type Vinmax Iout Package Price (SEK, single units)
LD1117 15 V 800 mA TO220 5:50
LE33 20 V 100 mA TO92 9:-
LP2950 30 V 100 mA TO92 9:-
LM317 40V delta 1500 mA TO220 9:- (There is also an 100 mA version for 6:25)

If you are using the Sundberg newbiePCB the design is for an TO92 package so either LE33 or LP2950 is the choice.
The LD1177 is TO220 package and you do not need 800 mA for the radio. It only consumes about 30 mA when transmitting.
The LM317 is an adjustable regulator so it can regulate to 5 V or 3.3 V or whatever you like but it takes two more resistors to set the voltage. In this case it is overkill and does not fit the Sundberg board.

If you plan to run your design on batteries I think the LP2950 is better than the LE33 because the LP2950 consumes less power internally, only 75 microamps. The LE33 can use as much as 500 microamps internally.

This is just scratching the surface of component choice but keep it simple in the beginning.
Happy tinkering!

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

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