I started building various sensors and control functions based on Mysensors quite a few years ago. Some I use originate from the solutions published at the build sections, others are of own design. At that time very few affordable off-the-shelf products were available.

My main controller is OpenHab and MySensors data are sent/received using MQTT. The other part of my IoT network is based on Z-Wave and once getting this mixture to work it just runs with very few hiccups. Main problems are nearly always associated with upgrading to new software versions, especially OpenHab has taken lots of time during conversions.

So for the moment I have everything I need running, it runs very stable and is in a "maintenance" state. Time is limited so focus and activity has had to shift to other things but I try to follow the forum.

For me Mysensors has been a great experience and I will continue using it if other similar sensors/functions are needed. I like building the Mysensors items myself and will not choose anything else if an own project can succeed.

With heaps of IoT things and systems available off the shelf to reasonable prices I think MySensors has to focus on robustness, simplicity and good guides so enthusiasts being tired of the complexity and non-compatibility of commercial solutions are willing to dig out the soldering iron and learn how to make own things.

I started with a small MySensors project more than 4 years ago and life was easy then :-) The choices were few and I felt they were well documented.

I began with an Ethernet gateway but moved to MQTT (ESP8266 because of WiFi) once it was available. The choice of radio was easy and even if there were problems most could be solved. I still run 10 - 15 items using NRF over MQTT to OpenHab and also have quite a few Z-wave items connected to this system.

Today there are heaps of choices and the development continues but my feeling is that MySensors is still mainly driven by a small community of enthusiasts working on this on their very limited free time. As more and more functions/variations are added the complexity grows and the need for correct documentation increases exponentially but the resources are not at all growing in same pace.

I have some experience with using much larger projects (OpenHab, ArduPilot, PX4 etc.) and and also here documentation often is a mixture of updated and outdated info. Many times the forums are where the correct answers can be found but very often there are many erroneous answers per one correct one.

For a project like MySensors I am convinced that the only way to go is to select an entry level configuration with few well working choices which are always kept alive and up to date.

As users become more and more experienced they will have come across a lot of useful info as well as have learnt how to find more. Hopefully some find documentation so important that they are willing to contribute also.

For the advanced stuff of course there should be an ambition to document it well and keep it actual but why not accept this as playground for the advanced users who know enough to find the answers as well as are able to assist others.

Last but not least. We always get what we pay for, don't we :-) To keep a full blown MySensors activity well documented will cost a fortune and require very up scaled resources.

Cheers
Mats

@marcossu Podría buscar el siguiente texto a través de Google: illuminate steps when people walk the stairs
Aquí hay un ejemplo: www.instructables.com/id/Motion-Activated-Stairs/ pero hay varios.

But as Yveax already has said - this is an English speaking forum so please use this language.

@bjacobse With two extruders you load up each with your most common filaments and thus do a filament change less frequent. Then it is a "nice-to-have" but nothing cruicial at least not for me who rarely combine materials in same print.

In more advanced use when people want to print for example support structures in one material and the item itself with another filament this is not practically possible with less than two extruders.

Changing colors can be done with one extruder but frequent changes for same part are of course a pain.

So depending on use the dual (or even more complex) extruders are everything from just nice to a must. For a beginner it is not needed (and for something "home built" it is most likely possible to change to a more complex extruder after some years).

@bjacobse Dual hotends are quite nice to have. I often have ABS going to one of them and PETG to the other. I do not use this to change colors during printing (actually have just tested it a couple of times) but being able to slice for extruder 1 or 2 means that I often can print without changing the plastic because my most common choices are those two qualities.

@skywatch Thank yo so much.

@cyberthom Thank you for the comment. No, I have not published the model anywhere and mainly because I do not have the time to support others trying to build it.

Like with any other big 3d-model like this it is also hard to guarantee that all small changes are incorporated into the model. Also, to build the various parts a fairly good 3D printer is needed (all plastic parts are made of ABS using roughly 100 degC bed heating).

@pihome Sorry I missed the little word "smd". It is of course possible to use a soldering station also but is not always so simple. I have used the butane driven Dremel soldering tool mainly because I have nothing else. It is not easy to control the heat with that one.

When I started with 3D printing quite a few years ago I bought an Ord Bot Hadron frame and then assembled the electronics from bits and pieces bought here and there. The printing table is 200 x 200 mm and the useful height is somewhat less but it has all functions needed. During this assembly process and years thereafter of printing I learned a lot and when the Ord Bot started to feel a bit small I began thinking about something bigger.

So I designed from scratch a much bigger one (printing volume 450 x 450 x 500, footprint about 700 x 700 mm, two extruders and a 220V heated bed) based on the CoreXY principle and this became a really good printer which has been working well for a couple of years now. All plastic parts were printed on the Ord Bot (I attach a screen dump from the 3D design model for info)

So my advise is much along the lines as mentioned by @skywatch - if you have the skills, time and facilities build one yourself. You will never regret it (except for during some memorable events during the process :-) ).

If building one yourself is out of the question do not look for the cheapest options. It will just take a few prints before realizing that a heated bed is needed, that more advanced software is a must, that network connectivity would be nice etc. etc. Well known brands like a Prusa I3 is a good choice but there are cheaper options (clones) out there as well but do not expect getting much or any at all support for the cheaper stuff.

The best one I ever used is a Weller WS81. Heats up in a few seconds and even if the unit itself is a bit expensive the spare soldering tips are dirt cheap (even the originals). With a power of 80W it can be used for quite big stuff too.

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