I have exactly same problem. Does it work for anyone not using the system broker?
Both binding and openhab are 2.4.

Can you not install something like soft close brackets (either around or in middle of sensor) This would take up the initial impact and then will have little influence on the measurement which you can then adjust in code? I know few bullet types are available on hardware stores which you can simply drill and push around your sensor. At least 3 will ensure that you can cover your sensor from every side.

@TimO

Can we use this binding for MQTT once the PR is available in OpenHAB?
It is a separate mqtt generic binding in ESH for things discovery but I cannot make out if this will solve the dependency issue or not.
https://github.com/eclipse/smarthome/pull/3876

davidgraeff created this issue in eclipse/smarthome

closed Mqtt things #3876

I agree with TimO

We are discussing the solution of same problem on https://forum.mysensors.org/topic/3346/discussion-reliable-delivery/48

Feel free to watch that. i am also using OpenHAB.

I use 3 personal laptops, 1 work laptop, 1 computer, 1 tablet and 1 phone to come to MySensor depending on where I am and if I have some time. However I am permanently logged in only on 2 devices. I do occasionally log in from others but not all the time.

@rozpruwacz Thanks for your response.

1. No I meant source as system trying to send message (i.e. Controller for point 3) and destination (Actuator for point3). Transport means mqtt, ethernet gateway, repeater, radio, wires, cloud, ir or anything else in between to reach my destination.
2. Thanks agreed.
3. I get your point but home automation system being a small size (finite and few hundred meters) system we do not need to intelligent hops.The moment we introduce GW in picture, a. Gateway becomes intelligent and needs to store information, b. It will not know what to do if it cannot pass the information ultimately. For example lets say that my controller wants to turn actuator ON. It makes sure message reaches GW but the actuator is down at that time. After some time when GW has done everything to reach it needs to take corrective action (even more intelligent GW) and send a message back to controller telling about this but by this time controller might have already initiated some logic (still not fulfilled the purpose ) based on actuator turning on. Hence if we follow just Controller -> Actuator, GW can be dumb as a brick, our controller will only trigger further logic once it is sure that actuator is turned on. I completely agree with you if its a huge network (like internet) or turnaround time is very high.
   Now to answer your question Yes Controller to Gateway is very reliable and although I do not think it has any acknowledgement, I have never seen a failed message here in my setup.
   For Manual action as you mentioned I would know by switch but for automatic I am implementing a retry in rules which will try a finite number of times and keep a track of numbers as well for analysis. Once the tries are exhaused I can take corrective action right there.. e.g if it couldn't turn the boiler ON announce and alert people accordingly.
4. I think lets first just discuss 3 and then we can come to 4.

Hi Guyz,
Not sure if anyone is interested in this but I would like to share my thinking here.

1. For reliable delivery, Only source and destination should be taking part, transport can do its best but as its can change we cannot expect it to behave precisely.
2. For the sake of simplicity I am assuming all message to be Idempotent. (i.e if this is executed multiple times result will be same. say turn on a switch). I know about OFF ON OFF scenario but for most of our requirements and times involved, I would say that we can assume that when we are delivering one message other will not come. However if any actuator changes so frequently we should think about it.
3. For Controller to to Actuator delivery, I am implementing a solution where actuator send its state back to controller on every change. When controller sends a command out to actuator it will wait for a second or two to see if the state is updated. If not it retries and it retries for a max number of times everyday which is getting logged to keep track of reliability in transport. This way if my max retry is not reached I can be sure that every message has reached actuator.
4. For actuator to controller delivery I am planning to do similar where it sends until it returns true with a acknowledge requested and keep sending it until either ack has come or max retry has been reached. Also keeping track of attempts it had to make and send those as well reliably to controller for analysis. I know this will not ensure gateway to controller delivery but I will see how this one works and if needed will add that later. But not doing it now to avoid dependency of controller on my individual node.

@Suresh-Mali I recall from discussion back that using a Linear regulator like 7805 at the end of this sort of power supply is almost always a bad idea. Here every design use Zener for a reason. Zener will only dissipate heat when there is extra power available. Linear regulator will always dissipate power leaving less available power for your application.

Hi Guyz,

I have been watching this wonderful forum for a while silently now and just started looking at few implementations myself. I am really surprised to know that so much work has been put in MySensors and this area is not given more attention and I second few opinions here that reliable delivery is one of the most important thing especially for actuators. I will try to do an example of end to end (node to gateway) reliable delivery as gateway to controller is pretty much reliable anyways. Meanwhile if anyone has any example already created, please do share over here.

@TimO Thank you very much for a very clear explanation. I will also search around MQTT 2.x on OpenHAB and post here if I find something relevant.