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

I recently designed a housing for my MQTT-Gateway, based on an ESP8266 module (Node-MCU) and an nRF24L01+PA+LNA. The housing printed great using PLA on my FF Creator Pro. Connections are made using Dupont cables cut in half and soldered directly to the nRF24 where the pins have been removed. I enclose a picture from FreeCad and a link to the stl-files on Github for the base and the cover.

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!

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.

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.

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

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

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.

@evb Done that. Here is the link

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

Thanks to @electrik and @mfalkvidd for your answers. I will try next time I have the opportunity. Currently the sensor is 400 km away from home.

I have a battery operated sensor that is placed at a distance to the GW where it should get a good connection. Distance is only 5 meters with wooden walls in between. But very close to this sensor is another sensor with the REPEATER function enabled. The first sensor connects to the GW but looses contact after a few hours. After a reset of the sensor, it functions again.

Question: Could the case be, that the battery operated sensor loses the path to the GW i.e. the routing is lost somehow if it starts oscillating between connecting to the GW and the repeater?

I have checked obvious causes of failure like wiring, capacitor etc.

If the answer is no, then I have other things to check. I just want to rule out this cause of failure.

I also edited according to @Yveaux 's workaround and it works!

I found however that in order to get the MQTT GW to listen to messages and forward them to the broker, I had to set wait(2000); in the void loop()
If I set wait(0) the GW started but did not listen to messages. If I set wait(100); the GW started spamming the broker with the presentation message.

Again, a big thank you to everybody involved. "Now we are cooking with gas again!"

I have exactly the same problem with the ESP8266 MQTT GW. It compiles and loads but there is nothing on the serial output. The ESP does not appear on the WiFi either. I have run other sketches like the NTP-server and the Blink sketch with exactly the same settings for the compiler. There is no difference if the radio is connected or not. My wiring is very simple, nothing connected except the micro-USB.
The suggestion by @peripi makes no difference. The bootload message comes at 74880 speed. Shifting to 9600 or setting any other speed for that matter makes no difference.

Since I have compiled and run this same sketch earlier, I suspect there have been some breaking changes in the library version 3.0.2 or possibly elsewhere.

I post my code below but I think it is identical to the reference sketches on MySensors.

/**
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2015 Sensnology AB
 * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Henrik Ekblad
 * Version 1.1 - Gunnar Blockmar 2019-05-19 Configuration for Sjövik WLAN
 * 
 * DESCRIPTION
 * The ESP8266 MQTT gateway sends radio network (or locally attached sensors) data to your MQTT broker.
 * The node also listens to MY_MQTT_TOPIC_PREFIX and sends out those messages to the radio network
 *
 * LED purposes:
 * - To use the feature, uncomment WITH_LEDS_BLINKING in MyConfig.h
 * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
 * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
 * - ERR (red) - fast blink on error during transmission error or recieve crc error  
 * 
 * See http://www.mysensors.org/build/esp8266_gateway for wiring instructions.
 * nRF24L01+  ESP8266
 * VCC        VCC
 * CE         GPIO4          
 * CSN/CS     GPIO15
 * SCK        GPIO14
 * MISO       GPIO12
 * MOSI       GPIO13
 *            
 * Not all ESP8266 modules have all pins available on their external interface.
 * This code has been tested on an ESP-12 module.
 * The ESP8266 requires a certain pin configuration to download code, and another one to run code:
 * - Connect REST (reset) via 10K pullup resistor to VCC, and via switch to GND ('reset switch')
 * - Connect GPIO15 via 10K pulldown resistor to GND
 * - Connect CH_PD via 10K resistor to VCC
 * - Connect GPIO2 via 10K resistor to VCC
 * - Connect GPIO0 via 10K resistor to VCC, and via switch to GND ('bootload switch')
 * 
  * Inclusion mode button:
 * - Connect GPIO5 via switch to GND ('inclusion switch')
 * 
 * Hardware SHA204 signing is currently not supported!
 *
 * Make sure to fill in your ssid and WiFi password below for ssid & pass.
 */

#include <EEPROM.h>
#include <SPI.h>

// Enable debug prints to serial monitor
#define MY_DEBUG 

// Use a bit lower baudrate for serial prints on ESP8266 than default in MyConfig.h
#define MY_BAUD_RATE 9600

// Enables and select radio type (if attached)
#define MY_RADIO_RF24
//#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT
#define MY_GATEWAY_ESP8266

// Set this nodes subscripe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "prefix-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "prefix-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "sensors"

// Enable these if your MQTT broker requires usenrame/password
#define MY_MQTT_USER "hidden"
#define MY_MQTT_PASSWORD "xyz123"

// Set WIFI SSID and password
#define MY_WIFI_SSID "secret"  // Change this at deployment
#define MY_WIFI_PASSWORD "secret"   //Change this at deployment

// Set the hostname for the WiFi Client. This is the hostname
// it will pass to the DHCP server if not static. 
#define MY_HOSTNAME "test-gateway"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
//#define MY_IP_ADDRESS 192,168,178,87

// If using static ip you need to define Gateway and Subnet address as well
//#define MY_IP_GATEWAY_ADDRESS 192,168,178,1
//#define MY_IP_SUBNET_ADDRESS 255,255,255,0


// MQTT broker ip address.  
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68
#define MY_CONTROLLER_URL_ADDRESS "xxx.cloudmqtt.com"


// The MQTT broker port to to open 
#define MY_PORT 12345      


// Flash leds on rx/tx/err does not work on ESP8266 no free pins
// #define MY_LEDS_BLINKING_FEATURE
// Set blinking period
// #define MY_DEFAULT_LED_BLINK_PERIOD 300
// Enable inclusion mode
// #define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
// #define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
// #define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
// #define MY_INCLUSION_MODE_BUTTON_PIN  3 
// #define MY_DEFAULT_ERR_LED_PIN 1  // Error led pin
// #define MY_DEFAULT_RX_LED_PIN  9  // Receive led pin
// #define MY_DEFAULT_TX_LED_PIN  0  // Transmit led pin


#include <ESP8266WiFi.h>
#include <MySensors.h>

void setup() { 
  
}

void presentation() {
  // Present locally attached sensors here    
}


void loop() {
  // Send locally attached sensors data here
}

So at the end of my wits.

@evb Done that. Here is the link

I recently designed a housing for my MQTT-Gateway, based on an ESP8266 module (Node-MCU) and an nRF24L01+PA+LNA. The housing printed great using PLA on my FF Creator Pro. Connections are made using Dupont cables cut in half and soldered directly to the nRF24 where the pins have been removed. I enclose a picture from FreeCad and a link to the stl-files on Github for the base and the cover.

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.