I have already published all the documentation, on my website, GitHub and openhardware.io
For now I leave the node as finished.
SmartHome: Wireless LED RGBW Controller – 00:55— giltesa
@krisztian
Hi krisztian,
the singleLED board - as its name suggests - features only one LED output. If you want to have a setup with multiple LED strips you need to design a board with multiple outputs. I have already designed a board with 4 outputs, but I haven't built it.
In terms of software you need to register multiple sensors in your program like this:
#define numCh 4 //the number of outputs
const byte ledPins[] = {9,6,5,3};
byte ledLevel[numCh];
boolean ledDimWay[numCh];
//in the setup function request the dim levels from the gateway
for(byte i=0; i<numCh; i++) request(i, V_DIMMER);
//in the presentation function register multiple lights
for(byte i=0; i<numCh; i++) present(i, S_DIMMER);
//if you receive a signal, you need to check for the sensor id
setLED(message.sensor, requestedLevel);
//to set the LED level (function: setLED) you need to use the sensor id to determine brightness and pin
//Fade LED to set level
int delta = (level - ledLevel[child]) < 0 ? -1 : 1;
//Write to LED
analogWrite(ledPins[child], map(ledLevel[child],0,100,0,255));
I will probably publish the whole code once I have built and tested the 4LED controller (i call it "MySensors rainbowLED")
Hope I could help you
ThetaDev
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
@samuel235
I'm using genuine atmel programmers (currently I'm on jtagice3) been serving me fine for the last couple of years (also have the added benefits of being able to work together with gdb, so I can debug arduino code on my atmel sam D21 mcu)
Anyways, there are lot's of (cheaper) programmers out there, amongst others you could use another arduino as programmer..
@Nca78 Yes, I was actually thinking using DIP switch (or even more easy to read thumbwheel switch) to give a unique ID to each node! As soon as I receive the extra radio modules I ordered, I'll test that.
@Grubstake I'm afraid you're right! But it's ok to have just a few days of battery life. As I wrote, it might be often disassembled and reassembled.
