MySensors shield and RGBW Controller
-
Hey,
I am currently working on getting some sensors set up at my place using mySensors. I really love the project, and how easy it is to build (most) sensors. Once I got the prototype running I need "professional" sensors though, which are easy to assemble, still cheap and can fit inside a small box of some kind.
I am planning to use a cheap pcb manufacterer like dirtypcbs.com, so the max size of the pcb is 5x5cm. This also goes well with the box part. I already got some battery holders, so all I need is the arduino + nrf + sensor on one board. Thats why I created my first design, a "motherboard"/shield which contains and arduino pro mini (3.3V) the NRF, a battery sensor and some small stuff. Also breakout pins for programming and an extra one for serial communication. The DHT11/22 can directly be placed on the pcb (because thats my most common sensor). Others sensors can be easily plucked into 2 connectors on the board as another shield. This makes it flexible but also easy to use with most kind of sensors. Power is an external part. I plan to use 3.3V wall power supplies or batteries, so no parts needed on the pcb. Didn't want to make it too complicated.
The design is also only 25*50mm, so you can get two of them out of a cheap pcb.I am also planning to control lots of RGB(W) leds. Thats why I designed another pcb holding the same arduino pro mini + NRF combination, but also 4 mosfets for the different channels and a LM2596 buck converter module from ebay, which allows me to drive the whole thing directly from the 12 (or more)V power supply for the leds.
I am thankfull for any comments or ideas how to optimize this and any errors you may find. I am planning to order them soon.
-
@LastSamurai Have you already designed these boards you mentioned or are you still in the planning phase? There are a few designs with similar specs elsewhere in the forum.
Also, did you mean to post this in the Homeseer thread?
-
I think there might be a bug. THis is the second thread I posted in another topic, but which landed in the Homeseer thread. @Moderator please move this!
I actually have already designed the ports. Here are the pictures.
I found some other designs, but most of them tried to do too much for my taste. But if you can recommend some...!Shield/Motherboard
PCB
RGBW Controller
PCB
Again, thanks for any feedback
-
It will end up in the category you opened the coposer (even if you switch page). Where do you want to have it?
-
I thought thats what I did, but perhaps I misclicked
I thought the hardware part would be right.
-
How many LEDs do you want drive with this controller, because the MOSFET has a limit of 4.6A.
A full bright white LED (like a SMD5050) can have ~60mA current - so you can drive save 70 LEDs on a strip with this controller.But anyway, nice design
-
@hek Have you already moved it? I still see it in the homeseer section.
@kalle Thanks for the hint. It should be enough in most cases for me, but better safe than sorry. Can you recommend a mosfet in SOT-23 package with a higher limit?
-
Sorry, I didn't find a sot-23 Mosfet with a higher limit, but maybe you have enough space to use TO-220. There are a lot of Mosefet's with a higher limit available - like this one.
-
Thanks for the feedback! I will try to add some bigger MOSFETs. Perhaps I can add both and make it optional. For now I finalised my shield. I moved the headers for the sensor, so that they are spaced like the arduino pro pins (distance). Also redid the routing and some other small parts. I just ordered them from dirtypcbs. Once I get them and they work I will add a link here if anybody else wants some.
I guess next I will work on the rgbw shield again.
-
Yeah
my PCBs from dirtypcbs finally arrived! So I instantly had to open the package and I must say: these pcbs are really well made (for that price). Here are pics. As you can see I designed them so that 2 fit on one 5x5cm pcb. So I have gotten myself 24 potential "smart" sensors now 
I haven't gotten all components yet for multiple sensors but I started with one test sensor anyways. It has through hole resistors instead of some smd ones, no capacitor and no DHT22 yet. But once I get the components I will add them on the prototype. For now it's up and running with a demo sketch that just sends random values.
And everything seems to be working nicely. Yeah^^Next step is to finalize the components and test some other components as arduino shield like components on the two pin headers I added for that one. And I already found some small things that I could still improve.
Once that's all done I will finalize the RGBW ones and send them of for production.
Love to hear your feedback and tipps guys!
PS can I somehow add these pictures as thumbnails? They are quite big...
-
My test sensorboard has been successfully running for over a week now
It's only reporting fake values because my new sensors (DHT22) did not yet arrive but this looks good already.This night there was an "accident" though. Suddenly the sensor stoped sending data. When I took it from its "hiding"spot I saw that the second LED on the board was constantly on. Do you guys knwo what that is for?
When I connected my serial to usb adapter to check the node's status the sensor powered up again and is since working perfectly again. The adapter does also power the board though. The battery levels are still reported as 3.4V so this should not be a problem. Any idea what the problem could be?
I haven't added the capacitor yet... might that be the problem?
-
Ok, the same thing just happened again. Before the unit shut down it did restart about 3 times (thats whats in the log from my domoticz). Might this be the brownout shutdown? Voltage with external multimeter is at aboud 2.7-2.8V. So do I have to change my fuse settings? Or perhaps use the mysensor bootloader...
I also realized that I did connect my batteries directly to the VCC pins, not the raw pin. This means that the voltage converter on the board isn't used (right?). Should I change that, or what's happening with the 3.3V converter if it gets input voltages lower than 3V?I also realise that my usb to serial converter might be running at 5V so I might have killed my NRF (and possibly the arduino too)
How do you guys handle this?
-
Is it available for other people yet? I am very interested in LED strip drivers connected to mySensor network and your PCB seems to fit the bill nicely.
Good job.
-AM
-
Not yet, although the designs are above. I have to work out the errors in my normal pcb yet. Then I can easily switch over to the RGB(W) one.
PS: Good part: both nrf and arduino are still working. Bad part: They shut down again after about a second. So it has to be a power issue. What are the right settings/fuses/things to keep the arduino pro mini (3.3V) running with batteries at 2.8V and lower?
-
Thanks for the response. I will be watching your progress closely as I am very interested in this.
-AM
-
It's a little sad that it took me so long but I finally managed to find a few minutes to "finalize" and test my sketch.
Here is my working code for an RGBW node that is based on MySensors and works with domoticz (other controllers might send different strings => so you would have to change one part of the sketch).
The sketch smoothly fades between colors and seemed to be stable in my test. What I still want to add is some kind of saved last values for possible restarts or loss of connection.I am gratefull for any feedback.
Next I will finalize my (test) pcb design and order that.
-
i would like to test this RGWB also, are the PCB gerber files available ?
-
I was finally able to get my PCB designs done. They are currently being produced by dirtypcbs.com
I switched to big(ger) mosfets to be able to drive a longer LED strip and easier to use through hole components instead of SMD. My breadboard test worked great so I am really curious to see this in action.
I also updated my github repo with the Target3001 based design, XGerber export and a eagle file export (although I am not really sure how that works, I never really used eagle myself).
If you simply want to try these unchanged PCBs yourself here is a link where you can buy them: http://dirtypcbs.com/view.php?share=14600&accesskey=e4f6cec8b8aadb845d51076b0f1aaab0
Although I warn you, they are not tested yet!Love to hear your feedback guys!
-
Nice work! Do you have a BOM for the RGBW board?
-
@LastSamurai: I would also be really interested in the BOM!
-
I will post a real BOM on my github repo when I find the time for it (hopefully soon). It's not very complicated though:
- Arduino Pro mini
- NRF24L01+
- The rectangle on the bottom right side is a step down converter like e.g. this
- 4 10k stepup resistors and 4 mosfets
- 2 caps, one to smooth the 3.3 voltage line and one for the NRF. I guess it should work without them too most of the time
-
Cool thanks! What MOSFETs do you use?
Thanks again for you effort!!!
-
@LastSamurai You have an error on your RGBW board! The PWM pins for a Pro Mini are not 3,4,5 and 6! They should be according to this:
PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.
-
@korttoma said:
@LastSamurai You have an error on your RGBW board! The PWM pins for a Pro Mini are not 3,4,5 and 6! They should be according to this:
PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.
Ah yes, thanks for the reminder! I knew this at design time (though I forgot it myselft now). Pins 9-11 are already used by the nrf module, so there aren't enough pins left for 4x PWM. RGB channels are using the pins 3,5,6 in my design and white the "normal" pin 4. This isn't a huge problem because at least in domitcz all that the white channel does is on/off anyways (or mostly). I guess I have to update the texts though.
Do you guys know if there is a way to free up one additional pwm pin so that true 4 way pwm is possible? If thats not possible there is software pwm (although that might be a problem when using the network..?!).
@jeti For my tests I am using IRFZ44N, but that really only depends on how many leds you want to be able to drive.
-
@LastSamurai To free up an additional pin for PWM, I believe you can change the CE and CS pins in the GW constructor. Use pin 4 for for CE to the radio and reroute the MOSFET to pin 9. And then designate the change in the GW constructor:
MyTransportNRF24 transport(4, 10);
MySensor gw(transport);
-
@Dwalt is absolutely right. I have been using this kind of setup for a looong time allready.
-
I finally found the time to really test my RGBW boards and I found another error: 2 pins of the mosfets are switched. To test it anyways I just took the mosfets and bend some legs to get them to the right connectors on the pcb. Aside from that I tested it for some days and it works beautifully. Dimming, on/off, color changing and the rgb/white switching works.
I will try to create a second version soon that uses 4 pwm pins (so that white can be dimmed to) and fixes the mosfet's pins. Perhaps i'll switch to a barebone atmega 328p too because the full pro mini is kinda overkill here and I might be able to make smaller pcbs then.After I found out that my problems with programming the pro minis comes from FTDI's newest driver "features" (always prints "NON GENUINE DEVICE FOUND!" on the serial port) I can now also try my normal sensors boards again with some low power modifications.
What's annoying me at the moment is that my raspberry pi (running my domoticz) controller won't restart at the moment. I'll have to fix that first.
As always any input is welcome and I'll try to post updates and pictures as soon as possible.
-
Good news (I guess
). I already redid my raspberry pi controller (where I kinda killed the old sd card 
) and also fixed the 2 errors in my pcb.
Sometimes in the next few days I'll try out a smaller pcb with the barebone arduino and test my sensor nodes again.
-
hi,
nice work,
I not understand why you said 2 pins of the mosfets are switched, for me it's ok,
I see G to arduino pins, S at center, and D to leds.. I miss something ?
I think I will buy some of them for testingps: maybe you can add your project on openhardware.io
sry for my english
-
@vil1driver Thanks you! I did change them to IRFZ44N's to be able to drive longer strips. I think the new schematics aren't uploaded here yet. I did switch drain and source pins there. Other than that it seems to be working perfectly, so I will create a new (and hopefully final) version soon.
I am also thinking about adding SPI pins. Perhaps I also add pins for a DHT11/22, there is still some free space on there. Does anyone have another idea what would be good to add/change?
As soon as the updated PCB is done I will update my github and I guess also open a project on openhardware.io.
-
I just finished building another prototype and it's mostly working fine. I still have some lag/network issues and I am not 100% sure about the perfect software/dimming either but I am working on that.
I will update the code in my git soon and design the new board (I am trying to learn using kicad for that).With the RGBW strip I am using red seems to be a lot darker than the other colors. Has someone seen similar behaviour? Or an idea how to fix that?
-
The problem with the red channel seems to be on the controller's side. Once I switches red and green wires the green got dimmed way too much. I am not sure yet if i's software or hardware thats causing the problem though.
I now have a real demo up and running and found another problem: most of the time sending commands works but about 20-40% of the command simply get ignored. Once that happens it takes some time to react at all again.
On/off seems to work most of the time, changing colors slightly less, changing to/from white most of the time doesn't and dimming doesn't seem to work at all. It is really strange.
Also the domoticz webinterface gets really laggy after some of the commands failed.
Waiting some time and then retrying seems to help.Is there a good way to debug the domoticz/serial gateway part of the network (because the rgbw controller worked well when I tested it before). The domoticz log only gives me entries like this:
2016-03-12 18:23:46.917 (MySensors USB-Serial Gateway) Lighting Limitless/Applamp (RGBW test light)and I have no idea how to see what the serial output to the gateway is.
Can anyone help?
The updated code is in my github and here. If you find errors or stuff that could be improved please tell me
/** Based on the MySensors Project: http://www.mysensors.org This sketch controls a (analog)RGBW strip by listening to new color values from a (domoticz) controller and then fading to the new color. Version 0.9 TODO safe/request values after restart/loss of connection */ #define SN "RGBW Led strip testSketch 3" #define SV "v0.9" // Load mysensors library #include <MySensor.h> // Load Serial Peripheral Interface library #include <SPI.h> // Arduino pin attached to driver pins #define RED_PIN 3 #define WHITE_PIN 4 #define GREEN_PIN 5 #define BLUE_PIN 6 #define NUM_CHANNELS 4 // how many channels, RGBW=4 RGB=3... #define SENSOR_ID 1 // Smooth stepping between the values #define STEP 1 #define INTERVAL 10 const int pwmIntervals = 255; float R; // equation for dimming curve MySensor gw; // Stores the current color settings byte channels[4] = {RED_PIN, GREEN_PIN, BLUE_PIN, WHITE_PIN}; byte values[4] = {100, 100, 100, 100}; byte target_values[4] = {100, 100, 100, 100}; // stores dimming level byte dimming = 100; byte target_dimming = 100; // tracks if the strip should be on of off boolean isOn = true; // time tracking for updates unsigned long lastupdate = millis(); void setup() { // Initializes the sensor node (with callback function for incoming messages) gw.begin(incomingMessage, 123); // 123 = node id for testing // Present sketch (name, version) gw.sendSketchInfo(SN, SV); // Register sensors (id, type, description, ack back) gw.present(SENSOR_ID, S_RGBW_LIGHT, "RGBW test light", true); // Set all channels to output (pin number, type) for (int i = 0; i < NUM_CHANNELS; i++) { pinMode(channels[i], OUTPUT); } // set up dimming R = (pwmIntervals * log10(2))/(log10(255)); // init lights updateLights(); // debug if (isOn) { Serial.println("RGBW is running..."); } Serial.println("Waiting for messages..."); } void loop() { // Process incoming messages (like config and light state from controller) - basically keep the mysensors protocol running gw.process(); // and set the new light colors if (millis() > lastupdate + INTERVAL) { updateLights(); lastupdate = millis(); } } // callback function for incoming messages void incomingMessage(const MyMessage &message) { Serial.print("Got a message - "); Serial.print("Messagetype is: "); Serial.println(message.type); // acknoledgment if (message.isAck()) { Serial.println("Got ack from gateway"); } // new dim level else if (message.type == V_DIMMER) { Serial.println("Dimming to "); Serial.println(message.getString()); target_dimming = message.getByte(); } // on / off message else if (message.type == V_STATUS) { Serial.print("Turning light "); isOn = message.getInt(); if (isOn) { Serial.println("on"); } else { Serial.println("off"); } } // new color value else if (message.type == V_RGBW) { const char * rgbvalues = message.getString(); inputToRGBW(rgbvalues); } } // this gets called every INTERVAL milliseconds and updates the current pwm levels for all colors void updateLights() { // update pin values -debug //Serial.println(greenval); //Serial.println(redval); //Serial.println(blueval); //Serial.println(whiteval); //Serial.println(target_greenval); //Serial.println(target_redval); //Serial.println(target_blueval); //Serial.println(target_whiteval); //Serial.println("+++++++++++++++"); // for each color for (int v = 0; v < NUM_CHANNELS; v++) { if (values[v] < target_values[v]) { values[v] += STEP; if (values[v] > target_values[v]) { values[v] = target_values[v]; } } if (values[v] > target_values[v]) { values[v] -= STEP; if (values[v] < target_values[v]) { values[v] = target_values[v]; } } } // dimming if (dimming < target_dimming) { dimming += STEP; if (dimming > target_dimming) { dimming = target_dimming; } } if (dimming > target_dimming) { dimming -= STEP; if (dimming < target_dimming) { dimming = target_dimming; } } /* // debug - new values Serial.println(greenval); Serial.println(redval); Serial.println(blueval); Serial.println(whiteval); Serial.println(target_greenval); Serial.println(target_redval); Serial.println(target_blueval); Serial.println(target_whiteval); Serial.println("+++++++++++++++"); */ // set actual pin values for (int i = 0; i < NUM_CHANNELS; i++) { if (isOn) { //analogWrite(channels[i], dimming / 100 * values[i]); // non linear fading, idea from https://diarmuid.ie/blog/pwm-exponential-led-fading-on-arduino-or-other-platforms/ analogWrite(channels[i], pow (2, (values[i] / R)) - 1); } else { analogWrite(channels[i], 0); } } } // converts incoming color string to actual (int) values // ATTENTION this currently does nearly no checks, so the format needs to be exactly like domoticz sends the strings void inputToRGBW(const char * input) { Serial.print("Got color value of length: "); Serial.println(strlen(input)); if (strlen(input) == 6) { Serial.println("new rgb value"); target_values[0] = fromhex (& input [0]); target_values[1] = fromhex (& input [2]); target_values[2] = fromhex (& input [4]); target_values[3] = 0; } else if (strlen(input) == 9) { Serial.println("new rgbw value"); target_values[0] = fromhex (& input [1]); // ignore # as first sign target_values[1] = fromhex (& input [3]); target_values[2] = fromhex (& input [5]); target_values[3] = fromhex (& input [7]); } else { Serial.println("Wrong length of input"); } Serial.print("New color values: "); Serial.println(input); for (int i = 0; i < NUM_CHANNELS; i++) { Serial.print(target_values[i]); Serial.print(", "); } Serial.println(""); Serial.print("Dimming: "); Serial.println(dimming); } // converts hex char to byte byte fromhex (const char * str) { char c = str [0] - '0'; if (c > 9) c -= 7; int result = c; c = str [1] - '0'; if (c > 9) c -= 7; return (result << 4) | c; }Update:
fixed some small errors in the code.
I also just debugged the rgbw controller via serial to usb and the problem seems to be that most commands just don't reach the node. At least I got no errors via serial.
There also seems to be some kind of jam sometimes where I send multiple commands nothing happens and then after some seconds all of them are executed in very short order
-
So I did some more debugging. If someone else has similar problems: you can see the serial output if you ssh into your pi and type
cat /dev/ttyACM0where ttyACM0 is the serial port of my gateway. The problem seems to be somewhere between gateway and rgbw controller.
I get a log like this:0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:1 123;1;1;1;2;1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:1 123;1;1;1;2;1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:1 123;1;1;1;2;1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=41,pt=0,l=9,sg=0,st=fail:#00000 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=41,pt=0,l=9,sg=0:#000000FF 123;1;1;1;41;#000000FF 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=3,pt=0,l=3,sg=0,st=fail:100 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:0 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:0 123;1;1;1;2;0 0;0;3;0;9;send: 0-0-123-123 s=1,c=1,t=2,pt=0,l=1,sg=0,st=fail:1 0;0;3;0;9;read: 123-123-0 s=1,c=1,t=2,pt=0,l=1,sg=0:1 123;1;1;1;2;1Every action in the webinterface get a entry here and some of them work just fine. But most of them return st=fail:1 (which I guess means that the message couldn't reach the receiver). In some cases it seems like only the acknoledgment didn't make it because the rgbwcontroller reacts anyways.
Any ideas how to fix that? I had none such problems earlier with my sensor nodes. Might this be a software problem with my controller? Am I not updating gw.process() often enough?
-
Hi @LastSamurai, I've loaded your sketch onto my RGBW controller, and had a look.
I discovered a number of issues:
- in updateLights(), under '// for each color', the limit on the 'for' loop should be v < NUM_CHANNELS (not v<= ... - this was corrupting channels[0])
- under '// set actual pin values', I had trouble with the exponential dimming, so I commented out this line, and uncommented the alternative analogWrite statement 2 lines above
- dimming and target_dimming should be declared as type 'float', otherwise the calculation dimming / 100 * values[i] rounds down to zero (the LEDs were switching off)
- on an Arduino Nano and Pro Mini (at least), PWM outputs are restricted to D3, 5, 6, 9, 10, 11 - you have defined WHITE_PIN as D4.
With these changes, it seems to work OK - I didn't get any 'st=fail' errors; are you supplying the radio from a separate 3.3V supply (not from the Arduino), and have you added a capacitor (usually 4.7uF) across the supply pins?
-
Thank you very much for testing!!
I did already fix some of these errors in the code above and my git... but I forgot to push that to github
@MikeF said:
Hi @LastSamurai, I've loaded your sketch onto my RGBW controller, and had a look.
I discovered a number of issues:
- in updateLights(), under '// for each color', the limit on the 'for' loop should be v < NUM_CHANNELS (not v<= ... - this was corrupting channels[0])
I already fixed that
- under '// set actual pin values', I had trouble with the exponential dimming, so I commented out this line, and uncommented the alternative analogWrite statement 2 lines above
Mhm ok it worked on another testsketch but I will test that again later
- dimming and target_dimming should be declared as type 'float', otherwise the calculation dimming / 100 * values[i] rounds down to zero (the LEDs were switching off)
Ok changed it
- on an Arduino Nano and Pro Mini (at least), PWM outputs are restricted to D3, 5, 6, 9, 10, 11 - you have defined WHITE_PIN as D4.
Yes thank you, I know that. I made a mistake there in my first testrun of pcbs so I have to use pin 4 for white here. I already fixed that in my next design.
With these changes, it seems to work OK - I didn't get any 'st=fail' errors; are you supplying the radio from a separate 3.3V supply (not from the Arduino), and have you added a capacitor (usually 4.7uF) across the supply pins?
On the gateway side I soldered a cap directly to the nrf. I was using the arduino unos power supply but using an external one didn't change anything ;( On the side of the controller I am using a stepdown converter from the 12V for the leds and 2 caps (4,7 and 47).
Strangely it's getting even worse. Only about 5% of my commands seem to reach the controller and in most of the cases I don't get any acknowledgment back even in these cases. I even tried to change the channel to 111 (not in the wlan spectrum any more afaik). It did not help at all. The distance between controller and gateway is only about 3m, no obstacles.
Does anyone have another idea? It's really sad to have the setup done and then being unable to really use it ;(
-
Something seems to be off with the controller. I tried the same code on another arduino uno and it worked just fine. A little less distance perhaps but no errors at all. Strange thing is that the controller was working just fine earlier on.
I will do some measuring tomorrow perhaps something broke on the board
-
So the problem seems to be the power supply. These buck converters have a high frequency ripple. A solution seems to be a LC filter which I found out in this thread.
Now I have the next strange problem though:
The controller doesn't seem to find his parent (gateway) somehow. I get logs like this:find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: sensor started, id=123, parent=255, distance=255 find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: RGBW is running... Waiting for messages... read: 0-0-123 s=1,c=1,t=2,pt=0,l=1,sg=0:0 find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: Got a message - Messagetype is: 7 read: 0-0-123 s=1,c=1,t=41,pt=0,l=6,sg=0:FF0000 find parent send: 123-123-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: read: 0-0-123 s=1,c=1,t=3,pt=0,l=2,sg=0:78 Got a message - Messagetype is: 3 Dimming to 78where the "got a message - ..." part is from my code. It also doesn't show up in my gateway and none of these broadcasts reach it either. The controller uses a set id (123) and I still have that configuration in my domoticz from some earlier test. The really strange thing is that any commands I send from the gateway reach the controller without problems (see last part of the log above for example.)
How can this be that sending in one direction seems to work but not in the other? Any idea how to fix this?
I'll try to build another testnode with linear regulator soon too so that I can hopefull fix the power issues once and for all ;(PS Ok I assume it's still some kind of power problem because about 1 in 10 times I send a message from the controller I actually get one back. This means you really can't use these cheap buck converters, at least like this, for this kind of setup I guess. I will build the new node tomorrow if I can.
-
This post is deleted!
-
I finally found the time to update my RGBW control pcb and circuit. I just ordered the new version if you want to try them out.
This time I used kiCad and will upload the new files later (and hopefully finally create the openHhardware.io project too).
I switched to smd parts for mosfets, voltage regulator, resistors and one cap. I also fixed the wrong pinout for the mosfets and switched the CE pin to pin 4 of the pro mini so that now four real pwm pins can be used to control the RGBW outputs.
-
I also reworked my sensor board. My goal is a relatively small sensor running of a coin cell (small sensor is useless if the battery pack is double its size). I took some ideas from the excellent slim node but added/changed some parts.
The idea at the moment is to support DHT temp/hum sensors, Si7021 or similar I2C sensors, low power IR modules and moisture sensors. The moisture sensor pins should also be usable for (reed)switches.
Because some of these sensors require 3.3V (or even 5) I also added a boostconverter. If it's not needed there is a jumber to bridge it. I was worried about power consumption of the sensors when the IC sleeps so I also added a transistor to control the boost converter power.I am planning to use these small cases.
Do you guys see any errors? Does the transistor part work like that? Or do you have any suggestions what else to add?
Thanks for your feedback!PS I already added serial (RX/TX/GND/Battery) ouput pins and a pulldown resistor for the Gate of the transistor.
-
I just realized that I forgot to actually forgot to add the schematics... hard for you guys to help like that^^. So here they are, I hope you guys find some errors that I overlooked
-
Any feedback? I will keep working on it for the next days. I am also thinking about adding some kind of light sensor. What is the cheapest one that works well with <=3.3V? What do you guys use?
-
I use an LDR
-
@GertSanders Thanks, that seems to be the easiest solution.
I am still working on the board so any mistake you guys might find... tell meI finally got around to post the RGBW controller part on openhardware.io. Here is the discussion thread.
-
Does anyone have a link (ebay aliexpress) or name for a nice coincell holder that I can use for my pcb. I used to use some with 2 pins as a connection to the pcb and a plane and some kind of sping on the other side. These work well but its very hard to get the coin cells out again when testing. I saw some pictures of coin cell holders where you just push the cell in from the side but can't find them online.
Also do you guys know any other sensors that could be of use (so that I can integrate them here) or see any errors in my schematics? Otherwise I can hopefully do the pcb design later this week and finally order the boards.
-
@LastSamurai
Look for Keystone Technologies. They make the battery holder on the Adafruit RTC breakout.
-
@GertSanders Thanks you very much but I just can't find any of them (at least at a reasonable price) on aliexpres or ebay(.de).
Should you (or someone else) know a link to one, please send it to me!
-
So I got my pcbs yesterday and started to test them. After some problems with power supply (here) I got the pro mini + nrf to work and send/receive commands. Today I connected the led lights and nothing happened (although it should start with a little power on all channels). After some time of testing to figure out the error the AMS suddenly got very hot and I disconnected the power as fast as possible. Now the pro mini doesn't react anymore to programming (or even serial in/output). I think I somehow broke it. Before I destroy another one though:
do you guys have any idea if there might be an error in my schematics (especially concerning the mosfet part)?The schematics are in the pdf:
link textThis is my current code:
/** Based on the MySensors Project: http://www.mysensors.org This sketch controls a (analog)RGBW strip by listening to new color values from a (domoticz) controller and then fading to the new color. Version 1.0 - Changed pins and gw definition Version 0.9 - First version TODO safe/request values after restart/loss of connection */ #define SN "RGBW test" #define SV "v1.0 29042016" // Load mysensors library #include <MySensor.h> // Load Serial Peripheral Interface library #include <SPI.h> // Arduino pin attached to driver pins #define RED_PIN 3 #define WHITE_PIN 9 // this is not a pwm pin! change it if you want pwm #define GREEN_PIN 5 #define BLUE_PIN 6 #define NUM_CHANNELS 4 // how many channels, RGBW=4 RGB=3... #define SENSOR_ID 1 // Smooth stepping between the values #define STEP 1 #define INTERVAL 10 const int pwmIntervals = 255; float R; // equation for dimming curve // change the pins to free up the pwm pin for led control #define RF24_CE_PIN 4 //<-- NOTE!!! changed, the default is 9 #define RF24_CS_PIN 10 // default is 10 #define RF24_PA_LEVEL RF24_PA_MAX MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL); MySensor gw(transport); // Stores the current color settings byte channels[4] = {RED_PIN, GREEN_PIN, BLUE_PIN, WHITE_PIN}; byte values[4] = {100, 100, 100, 100}; byte target_values[4] = {100, 100, 100, 100}; // stores dimming level byte dimming = 100; byte target_dimming = 100; // tracks if the strip should be on of off boolean isOn = true; // time tracking for updates unsigned long lastupdate = millis(); void setup() { // Initializes the sensor node (with callback function for incoming messages) gw.begin(incomingMessage); // 123 = node id for testing // Present sketch (name, version) gw.sendSketchInfo(SN, SV); // Register sensors (id, type, description, ack back) gw.present(SENSOR_ID, S_RGBW_LIGHT, "RGBW test light", true); // request current values from gateway/controller //gw.request(SENSOR_ID, S_RGBW_LIGHT); // Set all channels to output (pin number, type) for (int i = 0; i < NUM_CHANNELS; i++) { pinMode(channels[i], OUTPUT); } // set up dimming R = (pwmIntervals * log10(2))/(log10(255)); // init lights updateLights(); // debug if (isOn) { Serial.println("RGBW is running..."); } Serial.println("Waiting for messages..."); } void loop() { // Process incoming messages (like config and light state from controller) - basically keep the mysensors protocol running gw.process(); // and set the new light colors if (millis() > lastupdate + INTERVAL) { updateLights(); lastupdate = millis(); } } // callback function for incoming messages void incomingMessage(const MyMessage &message) { Serial.print("Got a message - "); Serial.print("Messagetype is: "); Serial.println(message.type); // acknoledgment if (message.isAck()) { Serial.println("Got ack from gateway"); } // new dim level else if (message.type == V_DIMMER) { Serial.println("Dimming to "); Serial.println(message.getString()); target_dimming = message.getByte(); } // on / off message else if (message.type == V_STATUS) { Serial.print("Turning light "); isOn = message.getInt(); if (isOn) { Serial.println("on"); } else { Serial.println("off"); } } // new color value else if (message.type == V_RGBW) { const char * rgbvalues = message.getString(); inputToRGBW(rgbvalues); } } // this gets called every INTERVAL milliseconds and updates the current pwm levels for all colors void updateLights() { // update pin values -debug //Serial.println(greenval); //Serial.println(redval); //Serial.println(blueval); //Serial.println(whiteval); //Serial.println(target_greenval); //Serial.println(target_redval); //Serial.println(target_blueval); //Serial.println(target_whiteval); //Serial.println("+++++++++++++++"); // for each color for (int v = 0; v < NUM_CHANNELS; v++) { if (values[v] < target_values[v]) { values[v] += STEP; if (values[v] > target_values[v]) { values[v] = target_values[v]; } } if (values[v] > target_values[v]) { values[v] -= STEP; if (values[v] < target_values[v]) { values[v] = target_values[v]; } } } // dimming if (dimming < target_dimming) { dimming += STEP; if (dimming > target_dimming) { dimming = target_dimming; } } if (dimming > target_dimming) { dimming -= STEP; if (dimming < target_dimming) { dimming = target_dimming; } } /* // debug - new values Serial.println(greenval); Serial.println(redval); Serial.println(blueval); Serial.println(whiteval); Serial.println(target_greenval); Serial.println(target_redval); Serial.println(target_blueval); Serial.println(target_whiteval); Serial.println("+++++++++++++++"); */ // set actual pin values for (int i = 0; i < NUM_CHANNELS; i++) { if (isOn) { // normal fading // analogWrite(channels[i], dimming / 100 * values[i]); // non linear fading, idea from https://diarmuid.ie/blog/pwm-exponential-led-fading-on-arduino-or-other-platforms/ analogWrite(channels[i], pow (2, (values[i] / R)) - 1); } else { analogWrite(channels[i], 0); } } } // converts incoming color string to actual (int) values // ATTENTION this currently does nearly no checks, so the format needs to be exactly like domoticz sends the strings void inputToRGBW(const char * input) { Serial.print("Got color value of length: "); Serial.println(strlen(input)); if (strlen(input) == 6) { Serial.println("new rgb value"); target_values[0] = fromhex (& input [0]); target_values[1] = fromhex (& input [2]); target_values[2] = fromhex (& input [4]); target_values[3] = 0; } else if (strlen(input) == 9) { Serial.println("new rgbw value"); target_values[0] = fromhex (& input [1]); // ignore # as first sign target_values[1] = fromhex (& input [3]); target_values[2] = fromhex (& input [5]); target_values[3] = fromhex (& input [7]); } else { Serial.println("Wrong length of input"); } Serial.print("New color values: "); Serial.println(input); for (int i = 0; i < NUM_CHANNELS; i++) { Serial.print(target_values[i]); Serial.print(", "); } Serial.println(""); Serial.print("Dimming: "); Serial.println(dimming); } // converts hex char to byte byte fromhex (const char * str) { char c = str [0] - '0'; if (c > 9) c -= 7; int result = c; c = str [1] - '0'; if (c > 9) c -= 7; return (result << 4) | c; }
-
I finally found the mistake (with some help). The pins for the mosfets were switched. I rotatet them and now its working perfectly. Smooth dimming and switching between colors is really cool. New pictures are on my openhardware.io project page.
Now I need to get some more features for the code (linear fading, remembering the values after restarts...) and then perhaps sometime in the future a better (and fixed) version of the pcb.
-
@LastSamurai This is a very nice and useful board you have here. But I was more interested in the first PCB you made with heftier FETs. Would it be okay if I took that first rev as a base and modified it for my needs. I need a VERY simple 3 channel (RGB) controller with hefty (> 5A) FETs.
How do I access the board files of that first rev to use them as base?
-AM
-
@activemind said:
@LastSamurai This is a very nice and useful board you have here. But I was more interested in the first PCB you made with heftier FETs. Would it be okay if I took that first rev as a base and modified it for my needs. I need a VERY simple 3 channel (RGB) controller with hefty (> 5A) FETs.
How do I access the board files of that first rev to use them as base?
-AM
Thanks you! The old files are here I think. It has been done with Target3001 and kicad. You could just take my newest board and replace the FETs. Or just order my boards and solder the FETs onto the smd pads (not perfect but should work too).
I did some updates in the newer versions so be carefull to catch that (e.g. use pwm pins for all 4 colors).Once I find the time I'll upload some pictures here too. At the moment I am using 3 of my boards to light up a room. Looks very nice imho.
-
Thanks @LastSamurai . I went ahead and ordered v1.3 of the board just to try them out. If I can solder heftier FETs then your board is EXACTLY what I am looking for. I dont care much about 4th channel since all of my applications will be high power RGB floods.
I didnt look too closely but is there provision for current limiting ressistors in each of the channels.
I will go ahead and load your files in KiCad and see if I can find my way around. Never done any PCB dev but want to give it a try
-AM
-
@activemind Cool, I guess you are the first one (beside me^^) using these boards. It's nice to see that my work can help others. Some feedback later on would be great
Current limiting resistors are not part of the board atm. Did not really need them. I only added pulldowns to the control lines.
But just have a look with kicad; the program (while having some strange menues/shortcuts) isn't that hard to learn and if you continue to work with electronics its a nice skill to have. I am 100% selft taught and my designs (mostly
) work.
-
@LastSamurai Thats a bummer that there are no current limiting ressistor. They are a must with any kind of RGB flood. Hmmm!
I understand why you did not need them because you are primarily driving strips and not RGB floods!
Maybe you can add them to your TODO list for the next rev as optional components.
Yeah, I installed KiCad and now need to load your files to see if I can stumble my way around
-AM
-
@activemind Yes, I will include that in my next version (whenever that will be^^). You could just add them "after" the board before connection the actual RGB lights though (if you use TH components).
Ok have fun
If you have questions feel free to send me a message here.
-
@LastSamurai Thanks for the offer. I might take you up on it though
I think I am going to start another thread once I have something meaningful to update.
-AM
-
Just a short update: I now have 5 of these controllers controlling different led strips in my apartment. They are all working without a problem (some of them for nearly half a year now).
I did some small updates to the code (which you can get via github) and will try to update the pcb later to fix that one annoying error with the mosfets.
-
I will try to upload the changed pcb tomorrow. Today I added my sensor platform that I am currently using with a motion sensor to light up a room when someone enters.
I will also try to add some pictures of my current setup soon.Here is the sensor platform: https://www.openhardware.io/view/261
-
I tried the new version of the pcb. I think the hardware is just working fine. However I have a problem with the sketch or domoticz. I can switch the light on and off. This switches all channels. So the FETs and the Arduino seem to work fine. I can dim the light, too. What does not work is the color selection with domoticz. If I select another color nothing happens. All 4 channels seem to habe the same level all the time. Any idea?
-
@Jan-Gatzke Was this due to the error in my fading code? Otherwise you have to connect a serial to usb controller to the node and check what the converter method does that converts domoticz to RGBW values.
-
Yes, this was the problem we already discussed in the other thread.
-
Hi
Is anybody who can help me how add phisical button to enable from the wall leds only in color white ?
Button will be connect to pin in arduino but how implement it to code sketch ? I want to on/off white color without gateway... example gateway not working....
-
@pepson Hi, not sure if it is exactly what you are looking for, but this firmware
https://github.com/d-diot/d-diot-nano-repeater
Can turn a RGB led strip on and off with a button press. To force white color you need to customize the code.
-
But I need code in sketch to upload by Arduino IDE...
-
This post is deleted!
-
Very nice project you have here! Thank you for taking the time to post/share your work!
At first I thought it might be exactly what I was looking for, but reading through everything now I am not so sure.
I have been studying various ways (Wi-Fi, 433/315 Mhz RF, MySensors) to implement controlling RGB lights and I initially thought Wi-Fi (while readily available, easy, and cheap) might be too "slow" in response time, which got me thinking to use MySensors (with NRF24) instead, which led me to this thread (among others).
Something concerned me though, I see in your GitHub for this project you stated:
Project frozen/final - This project is done from my side. It has been working for years but I switched to another solution so I won't update this anymore.
and on your OpenHardware page:
Update2: They have been running for about 2 years now mostly without problems. The only disadvantage is that my Mysensors network overall is quite "slow" (~1s reaction time). I am currently experimenting with Wifi RGBWW controllers (H801) so there wont be to many more updates to this project
Which made me want to ask you what you are using now?
It seems to me that those MagicHome type Wi-Fi (or RF) RGB controllers would be pretty hard to beat price wise, I don't think I could implement similar functionality (including packaging, etc.) for the same amount of money, and that's before even counting my time.
Also I am still struggling with reliability of my MySensors network in general, but I hope to be able to still solve this as it seems that many others have been able to (but that is a different subject altogether).
