@sergio-rius A little late, sorry, but that depends on the mosfets you are actually using. I am driving ~5m strips of white leds with most of my controllers and they don't even really get hot.

There is also a big(ish) update from my side concerning this project: I have designed, 3d printed and tested my own case for the controllers and they work great. I have just added the stl files and some images to the project page!!
For now this project is done from my side. The controllers have been working great for the past 2 years but due to the "huge" (~1s) delay with my Mysensors network (with signing and openhab on a raspi) when switching the leds I am currently testing some MQTT and wifi based RGBWW controller boards as an alternative.

I only had Home Assistant installed for some days (did not really like it at the time) so I can't tell you that it works 100% but it did back then. You have to add some strange additional messages but I tried to integrate that into my code.
I am using my RGBW controllers with openhab 2 in one location and with domoticz in another. As it is controlled by MySensors it works (and looks) pretty much like any other mysensors node. Both installations run on 2.2. Hope this helps :)

I never tried that but as far as I know you have to tell Mysensors to use a different kind of radio by adding a define like:

#define MY_RADIO_RFM69

Just do a quick search on this forum though ;)

Well great to hear that you solved the problem. There are version 2.1 and 2.2 of mysensors as of now that can be used too so maybe update again?

Do you still have an older version of Mysensors installed? Thats the only time I had such behaviour

@TimO I finally got around to testing my pureWhite RGBW code and at least for me its working like it should be. I saw you already merged this so I guess others can use it too very soon.
What is still not working is the acknowledgment feature. I have one node that only gets about 90% of the messages without error, so I tried activating it there and on some other nodes too for testing. Result: success rate is down to ~50% for each node and I get messages about some acknowledgment on the console when no message has even been sent (nothing about a message from mysensors on the console and no rx/tx leds on the gateway). When I tested this some months ago I also saw no message at the client so I am pretty sure none gets send.
So I guess this issue is still unresolved ;) I have no clue why on a first glance but if I can help just send me a message.

Sounds nice! I wish you the best of luck with your project(s) and keep us updated!
I might do some project report like this too soon, so I will follow yours ;)

You can also use the security features of mysensors so that your node doesn't connect to your neighbors gateway even if it uses the same channel. Using a different channel would be easier though i guess.

Did anyone try the Anet A8? I am currently thinking about buying one. It would be my first 3D printer and I do not want to spend more than ~150€ (at least initially). It seems to be a clone of the Prusa i3 and quite capable if add some cheap/self printed parts and invest some time. I don't have the time/knowledge to build a printer on my own from scratch but I am pretty sure that I can those upgrades.

Or are there any alternatives in that price range that you guys can recommend? Main idea is to print cases for my electronics projects and some small other stuff from time to time.

@TimO I saw that you fixed some other bugs too in the repo. Will you create a new version 2.3 of the binding soon? Or will there be more changes first?
As most of the changes (at least also) concern RGBW lighting I would really like to use it but I can't seem to build the binding locally (I postet the error in the git pr).

@masmat As far as I know .cfg files are only the config files fpr your installed addons and are located in the service directory (see TimO's post above). And they indeed only contain the settings you want to use, which can be 4 lines only. Depends on the addon

@TimO Today I decided to finally read into how Openhab binding development works. And just when I started I saw that you finally fixed some of the problems that I reported via github (thank you very much for that). Had to laugh a little at that coincidence :rolling_on_the_floor_laughing:

I just started a pullrequest where I tried to implement pure white colors for RGBW values fixing one of my problems left open. If you find the time please have a look at it. I did not yet write any tests for it or test it on my actual RGBW nodes but I will do that as soon as possible

I have just updated to the stable openHAB 2.2 Version and everything seemed to be working just fine in the beginning but after the next restart I got this error:

10:31:19.727 [WARN ] [fig.xml.osgi.XmlDocumentBundleTracker] - The XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.mysensors' could not be parsed: The XmlConfigDescriptionProvider must not be null!

It seems like I can still control my devices just fine but I just wanted to make sure that this doesn't cause errors down the line. So @TimO any idea where this error is coming from?

@TimO Thanks for your help though I am afraid you mixed something up there. The channel linking to the item itself doesn't really make sense ;)
Not 100% sure why it did not work earlier for me but I now got it to work like this:

// thing
multimeter		voltTHWohnzimmer	[nodeId=1, childId=2]
// item
Number 	voltageSensorWZ 		"Spannung [%3f mV]" 		<poweroutlet_eu> 	(grVolt, grWZ)	{ channel="mysensors:multimeter:gwSerial:voltTHWohnzimmer:volt" }

My error in the code above seems to have been that I defined most as customSensor instead of multimeter.

@TimO I am not sure what you mean.
My sketch sends a presentation:

 present(CHILD_ID_BATTERY, S_MULTIMETER);

and in openhab I added these (tried both sensor kinds)

// things
customSensor abc [nodeId=26, childId=1]
multimeter def [nodeId=17, childId=1]
// and items
Number 	voltageSensorWZ ... { channel="mysensors:multimeter:gwSerial:def:volt" }
//...

Is there anything i am missing here?

I am the one from your post and the capacitors only helped a little. One of my molgans simply doesn't seem to work.
But you are right sending takes a lot of energy (vs doing nothing) so a bigger capacitor and/or pauses in between definitely should help!

@TimO My sketches are sending the nodes remaining battery power to the controller via a V_VOLTAGE. Openhab 2 with your binding doesn't seem to be able to read these values. Is this an error (possibly on my side) or does the not yet support this?

@ThetaDev Maybe you you could get away with it but especially the radio is very sensitive concerning the power supply. Cheap pro minis often use very cheap regulators too and then this might become a problem.
I also wanted to support the high power version of the NRF and that definitly needs more power than provided by the onboard regulator.

I am not sure but I don't think so. All controllers I have used yet give incrementing auto Ids though. So if you have less than 100 (auto id) nodes you can simply set the id in code for your test nodes.