@masmat Also I use the "native" OpenHab MQTT binding (my version is 1.11.0) and it works really well with OpenHab 2.2 but , as @bgunnarb says, it is a manual procedure to define the items.

I have not tested the MySensors OpenHab binding because I have a number of sensors of own design which I guess will need quite a bit of redesign to fit into this picture, if at all possible without modification of the binding.

I have not tried the Pi as a gateway so cannot comment on your second question, unfortunately. As the Arduinos and ESP work well as gateways and my Pi already serves OpenHab and Mosquitto I will keep it that way.

As mentioned there is an OpenHab binding you can take a look at.

I started using OpenHab long before this binding was available so my setup is to use the OpenHab MQTT binding.

Technically it is quite simple, you seem to have all what is needed. OpenHab and Mosquitto can run on the RPi and a MySensors MQTT gateway sends the sensor messages to Mosquitto over your network. The Mosquitto passes all messages on to OpenHab.

Now my gateway is based on WiFi using a Wemos Mini or other ESP based board. I have also used an Ethernet MQTT gateway without any problems.

At the OpenHab side you need to create Items which listen to the MQTT messages and then the OpeHab rules can act on these messages and display results using the OpenHab sitemaps.

There is a lot of info available about how to set all this up so Google plus MySensors and OpenHab docs/forums will give you the details needed.

This rough description outlines one "manual" way of connecting to OpenHab. Also the serial gateway can be used but I think MQTT is the best option. I presume that the mentioned binding can simplify things but I have no experience of that approach.

I am using OpenHab through MQTT and it is so that the controller has no builtin functionality to respond to the startup message from the sensor. I had to make an own startup message to be picked up at the conroller and then use a rule to send the old pulsecount back at at startup.

There should be several discussions at the forum about this so the info is here somewhere.

@pjr I guess the trick is to find a closed loop belt of suitable length and also make a screw design which can move enough sideways to tighten the belt.

@dbemowsk For Z I have seen solutions with motors and belts so this is possible. It is just another piece to design and the motor need to be sized for both which might be a bigger problem with Y than with Z. I have never thought about it so it is just a guess.

@gohan The beauty with a CoreXY is that both X and Y movements are handled by stationary motors which do not add any moving weight. Changing to lead screws means that most likely 2 motors are needed for Y (for a large design) and then another screw and motor for X and these will add to the moving weight. Of course a belt could also be used for X but the motor arrangement needed for this will still be a moving part.

Even if my CoreXY is really big it can print with same or even better resolution than my old OrdBot Hadron which is so much smaller. The OrdBot has a direct drive extruder and also the X motor arrangement attached as a moving parts and this affects what printing speeds can be achieved at a given resolution. The CoreXY has a Bowden arrangement which further lowers the moving weight.

@gohan If we are talking about hobby stuff with comparable low cost the belt should be better but there are limitations like how much weight can be handled at high speeds without loosing precision. So it is a question with many answers depending on the circumstances.

@davidzh A change to 1.8.5 did not help. But disabling My_Debug still works so the problem is not critical.
For the sake of clarity I have also tested with an unmodified Sensebender sketch and also this one gets compilation errors when enabling My_Debug. So the problem comes from the implementation of the debug code.

@dbemowsk Yes it is a Ramps but in a way it is only "partly" used. The bed heating is, as mentioned, at 220V so Ramps is only used for the signal an external device. Same with the extruder heaters, i e the Ramps is used for a signal to a more robust device. This remedies some of the weaknesses of the Ramps card and enables heating of two extruders simultaneously.

I have bought external drivers for the step motors as well but not yet found any reason to switch to these. So the motors are still driven by the 8225 drivers on the Ramps card.

In case anyone is interested, this is what "the Thing" looks like on the drawing board:

Presumably the Mysensors forum is not intended for discussions about 3D printers why I hope I have not violated any rules by jumping into the conversation.

@davidzh Do not know what is going on with my browser, I have replied to your question but cannot see this reply anywhere. Also i did not receive any notification about your question so my reply is late, sorry.
The issue showed up when compiling for library version 2.2 on Arduino 1.6.12. I will test with the latest version as you suggest, thank's a lot for the info.