Not yet. You could take the kicad files from my github and change that by yourself. I did start to update my design some weeks ago but as I still have enough of the old boards (and they work with that one tweak) I didn't finish that. Might do that soon so. Once I updated it I will add the new file to my github repo and the openhardware page.

@Cliff-Karlsson I did update my kicad and gerber files in the github repo (are these files automatically updated in the openhardware.io project too?). I haven't tested these yet but they should work without an error now. You could just take these gerber files and order them somewhere.

Great, just one stupid question. Do I just upload the gbl file to dirtypcbs/oshpark or how does it work?

You take a zip file with all the gerber files inside (I think I already put one into the git), test it online (if you want to; sometimes it doesnt look perfect here) and then you upload it to dirtypcbs. I don't know how oshpark works, but I guess similar.

I got my v1.3 pcbs from Smart Prototyping. Quality is good. The controller works fine BUT the sketch version in your github repo is broken. Seems like the non linear fading part never got finished. I am now using linear fading and the sketch is working.

@Jan-Gatzke Thank you for correcting it I never got around to making the fading part work a 100% so I reverted back to my normal linear fading for my controllers. Seems like I forgot to correct that in my git repo Sorry for that, I will fix it after christmas.
Great to hear that others are using the controllers too! Have fun with them and update me if you change something or build some (other) cool thing with them!

A little question, the v1.3 is this the one with the corrected mosfet placement ?
I build and programmed one now, but i only get a bright white light, and no response when i switch the node. So now i am in doubt...

@Jan-Gatzke
Thank you, i see it in the code now ...
I tested it with setting the RGB levels one by one to 255, and this works, so the channels are responding to the initialisation code.
And because it is rebuild to version 2.0, i forgot one void to adjust...void incomingMessage(
should bevoid receive(

If I find the time, I will clean it up. I want to have a look at the non linear fading. IMHO the initial settings need to be customized, too. Instead of switching the white LEDs on the node could request the values from the controller (if possible) or from eeprom.

As promised I had a look at the sketch. The node can now save and restore values for rgbw, dimming and status to/from the controller. I had a look at the non linear fading, too. I got it partially working and refreshed my math knowledge a lot.
In the end I removed the code for it because it made the sketch much more complicated and I didn't like the results. The formula from the original sketch was ok for fading a single LED from 0% to 100%. It didn't cover other starting values and the combination of the colors. IMHO only the dimming can be done non linear without problems. For this I would use a static table of PWM values and percent values. Doing the log calculations on the pro mini seems to be too slow for a smooth fading. I saw massive flickering.

Thx. Those new features, however, are kind of a workaround. It would have been better if the node could request the V_RGBW value directly. MySensors supports this, but domoticz doesn't seem to. I have testet this and domoticz always returned "0" as value. And because you and me are both using domoticz, I decided to implement this feature using V_VAR1-3.

I am still thinking about the fading. I think we could get better colors if we could compensate the non linear dimming of the LEDs. With the actual sketch colors composed of mid range values could be wrong because every PWM value above 150 or so looks like almost full power. So 00AAFF almost looks like 00FFFF. AA has a value of 170 where FF is 255. This should make a big difference.

@pepson The *.kicad_pcb file should be the pcb, the *.sch file the schematics.
You could just use the schematics to remake my project by yourself though and learn kicad on the way. Otherwise the suggested adaptor seems to be the easiest solution.

This PCB will also available to buy it as i can buy PCB to converter NRF to RFM69 ?

I am not sure if I understand your question. I am not selling the pcbs but you can buy it from dirtypcbs and support me. I guess you should be able to use it with the converter though I never did. Be sure to check dimensions first!

@pepson Still not sure what you mean. If you want hardware buttons you can add those to the node (I did not). Everything else is part of the controller software which I don't control. You can always use something other than domoticz. But lets not spam this thread with that anymore please

I am trying to compile this project with the 2.1.1 library, but I keep getting the errors: the 'MyTransportNRF24' does not name a type.
As far as I can see, it seems that the type is nowhere defined in the libraries.

@CoolSaet Yes that is because the sketch you are using is still from MySensors 1.5. I already updated the sketch to Version 2 in November but forgot to push the changes to github.Here is a newer version that should work with mysensors 2. Only the (non)linear fading is still not working 100%.

@Sergio-Rius
I ordered the pcb a few months back on dirty pcbs. That one had the MOSFET pins connected wrong, but it wasn't that difficult to turn them an discribed in the post. I am not sure if a correct one is available.

@Sergio-Rius I am pretty sure the version 1.3 from the store still has the pins rotated (= wrong but you can fix it as described). There is a fixed version of the gerber files in my github repo that is linked to this project though. I just haven't ordered them from dirtyPCBs yet so they are not in the store (as I am still using the rest of the old ones).

Thanks, @LastSamurai, I went and compared the DIrty PCB files with the v1.3 ones on OpenHardware.IO and they are indeed different. It looks like the DIrtyPCB link is out of date and still has the error on them.@Sergio-Rius would be very grateful if you could update those files

@Stuart-Middleton It really shoudn't be. Just follow the pictures in the project. There are also updated project/gerber files in my github for anyone wanting to order new ones. Once I have used all of the Version 1.3 ones I will order new ones from dirtyPCBs and add the link here.

@Jan-Gatzke Did you ever manage to get your non-linear fading to work? I used the predefined values from your sketch and added them to my newer one but whenever I use that the sketch stops working and only rubbish is shown on the serial port.
Here is my new version: github

@Jan-Gatzke Thanks, I'll try that later although it doesn't look much different from mine. May I ask why you are using V_VAR1/2 types in your sketch? And why you send answer messages? Are you using home assistant (thats the only one where this is need imho)?

I am using Domoticz. This was the only way reading initial values from the controller. Directly requesting the value of a child did not work for me. Meanwhile MySensors support in Domoticz seems extremly bugy and uncomplete to me. I am going to give OpenHAB2 a try.

@Jan-Gatzke Ah ok nice to know. I am facing the same problem. RGBW is not that well supported in domoticz. I am currently trying to switch to openhab2 but having some problems with my RGBW nodes there too. Development on the plugin seems to be very active though. If you want to follow the discussion have a look at the forum thread here or on github
Once I got everything up and running in openhab I'll post an update here.

Meanwhile the newest sketch from my github should work with Home assistant too.

@LastSamurai I'm using Domoticz. With your sketch, turning on and off worked.
But whenever it had any rgb value, the white light was always 100% on. The RGB leds where all three lit at a time and never more than 20% but slightly responded to dimming control.

The above code from @Jan-Gatzke works flawlessy. Even turns the white leds on when reaching the white band on the gradient.
Only I would like it to not turn off the color leds until the selected color is totally or almost white, so we could white-wash the selection.

Oh, men... soldering those mosfets turned around was so difficult. I recommend the next who buys boards to use the new designs.

Give me some time and I'll give a turn to the sketch. But I'm still working on the "water-heating-solar-controller", and still have to assemble the energy monitor board, and do something with the meteo board.

@LastSamurai I have some doubts on this code, can I ask you?
The change between color values is done by a fade, and I understand that you don't want a linear change but an exponential one. Right?

One doubt i have is that I'm seeing that the fade is accomplished using a conversion array. So you are doing variable steps depending on the difference of value for each channel. Wouldn't be preferable to always take the same amount of time/steps doing the change?

Wouldn't be better to divide the difference for each value on the same steps and then doing the transformation. Then could be fixed without an array.

The problem with the linear fading was that a value of 100 almost looked the same as 150. So the goal was to make the fading look more linear. The logarythmic calculations needed for this cannot be done on an atmega 328p. (I tried it)
This is why I calculated the values with MS Excel and put them in an array.

Making the fading process alway take the same time would be nice. Feel free to post your implementation.

@Jan-Gatzke@LastSamurai I've been playing with the formula of the blog post written in comments on the sketch and I see that this isn't something trivial.
I think the code in the post has a misconception, that using 0-255 he missed that the graph data is not related to time, but pwm value.

So a fixed table for conversion between pwm value and appreciated light has to be built. And you also arrived to this conclusion seeing the array.
I'm generating the array on the fly using the formula with 256 steps.
(In the blog code there's a bug caused by the mean of zero in intervals and the formula that causes max value to being reached. You have to sum one to interval before using on the formula.)

I'm now trying to separate a loop for traveling the array that compensates for in between values so it can handle smaller steps->variable interval.

I've been working on an sketch for this board. Somewhere in the path I started adding functionalities and it ended in a library. Perhaps it's way overkill, but I thought that could be easier add it to NodeManager like that.
It's based on the work done here and some more ideas around the network. Thanks to LastSamurai for the board and code and also to Jan.
You can find the sources there: https://github.com/SergioRius/RGBWDimmer

This thing includes a serial manager that I use myself, but you can remove it and delete all the code for debugging, and perhaps add yourselves if necessary.
Just clone the repo or download and install as a zip library on Arduino IDE.
The example works for the OH! MySensors RGBW board as is.

It's very self explanatory in the code, but in essence:

It can be used stand-alone or with mysensors

You simply send to the commands and the class does all for you.

Uses a non blocking system for the fading.

Configurable fading time and resolution

Several configurable fading curves

Option for gamma (brightness + hue) calibration.

I'm currently debugging the fading curves equations other than linear, as the arduino mcu capabilities are tight and it's so easy to overflow it. Also I'm doing a program for calibrating the hue (arduino with leds and a rotary encoder for manually adjusting), so for now gamma only compensates brightness. You can change the values if you prefer. I'll be a good idea to lower the white channel.

It still lacks some memory optimization, but for now I'm scared about overflows. I got one of those and it was a two days nightmare and I had to revert to ints to get something running.
I'll soon add a stand alone sample and port to NodeManager.
For the while, for using it alone the minimal it's:

@LastSamurai Yes, of course.
Just a question. How did you make the "values curve"? You said in excel and perhaps a graph... did you manage to change graph values and update data in any way?

I've made the sketch for adjusting the gamma values, something with a Serial monitor menu that allows for increasing and decreasing the channels in real time. And adjusted the greens for a better hue (orange being orange, not a greenish yellow) but now I do't know how to adapt the curve.
I refuse to modify the 255 values by hand.

Now I'm making a case for 3d-print. Where do I have to post it, there or in a separate post? I read anything about posts becoming entries at hardware.io and ¿build?

Do you really need an external voltage regulator for this module? I mean the Arduino Pro Mini has its linear regulator already built in. You can only draw about 100ma from it, but wouldn't that be sufficient for the micro, radio and the mosfet gates?

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

Mmmmm... How much have you pushed this board? I mean, in terms of load.
I just had one fail at me and I'm trying to understand what component may have been the weak link.

It was driving a 5m white stripe when it turned himself off and on again, but although the light was still on the node was down. I took it out and almost burned my hand. Not the mosfets, but the arduino and radio. Nothing seems bad (components good looking, arduino seems to start) but as soon as you apply 12v, even without load it starts the barbecue.

It seems that the mosfets are good to 4,2Ah if I understand it. So what would be the boards specs?

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