Gauge/Widgets additional multi-colors

I realy like the idea with multiple colors (in one color mode), it saves you a lot of trouble sending the right color to the gauge, only I would like to see two aditional colors:

   *  First color mode:  [0% => red] ... [@50% => green] ... [@100% red]
   * Second color mode:  [0% => green] ... [@50% => red] ... [@100% green]
  • The first color is usable at moisture sensors where you have issues with soil overwatering and underwatering, both extremes are bad, so => red colors.
  • The second color I added just as it is opposite to the first colors, someone might find it useful too.

As you already have the functionality working, I think this should take you long to add?

Blynk rocks! Hope you are doing well there!


Use the HEX colour options in Blynk.setProperty(V0, "color", "#D3435C");

color is string in HEX format (in the form: #RRGGBB, where RR (red), GG (green) and BB (blue) are hexadecimal values between 00 and FF). For example :

#define BLYNK_GREEN     "#23C48E"
#define BLYNK_BLUE      "#04C0F8"
#define BLYNK_YELLOW    "#ED9D00"
#define BLYNK_RED       "#D3435C"
#define BLYNK_DARK_BLUE "#5F7CD8"

I have a bit of code that takes the zeRGBa Widget, and/or three sliders, to customize my own colours and supply both what it looks like as well as corresponding HEX value.

//===== RGB Sliders - BLYNK Functions =====
BLYNK_WRITE(V20)  // RED slider.
  rrr = param.asInt(); // get a RED channel value.
  Blynk.virtualWrite(V23, rrr);  // Red LED intensity
  RGBprocess();  // Goto pin data to HEX conversion funtion.
}  // END Blynk Function

BLYNK_WRITE(V21)  // GREEN slider.
  ggg = param.asInt(); // get a GREEN channel value.
  Blynk.virtualWrite(V24, ggg);  // Green LED intensity
  RGBprocess();  // Goto pin data to HEX conversion funtion.
}  // END Blynk Function

BLYNK_WRITE(V22)  // BLUE slider.
  bbb = param.asInt(); // get a BLUE channel value.
  Blynk.virtualWrite(V25, bbb);  // Blue LED intensity
  RGBprocess();  // Goto pin data to HEX conversion funtion.
}  // END Blynk Function

//===== zeRGBa Widget  - BLYNK Function =====
  rrr = param[0].asInt(); // get a RED channel value.
  ggg = param[1].asInt(); // get a GREEN channel value.
  bbb = param[2].asInt(); // get a BLUE channel value.
  Blynk.virtualWrite(V20, rrr);  // Red slider position.
  Blynk.virtualWrite(V23, rrr);  // Red LED intensity.
  Blynk.virtualWrite(V21, ggg);  // Green slider position.
  Blynk.virtualWrite(V24, ggg);  // Green LED intensity.
  Blynk.virtualWrite(V22, bbb);  // Blue slider position.
  Blynk.virtualWrite(V25, bbb);  // Blue LED intensity.;
}  // END Blynk Function

//===== Physical RGB LED Control and HEX conversion =====
void RGBprocess()  // Pin data to HEX conversion funtion.
  analogWrite(RedP, rrr);  // Write to RED RGB pin.
  analogWrite(GrnP, ggg);  // Write to GREEN RGB pin.
  analogWrite(BluP, bbb);  // Write to BLUE RGB pin.
  String strRED = String(rrr, HEX);  // Convert RED DEC to HEX.
  if (rrr < 16) {
    strRED = String("0" + strRED);  // Buffer with 0 if required.
  }  // END if
  String strGRN = String(ggg, HEX);  // Convert GREEN DEC to HEX.
  if (ggg < 16)  {
    strGRN = String("0" + strGRN);  // Buffer with 0 if required.
  }  // END if
  String strBLU = String(bbb, HEX);  // Convert BLUE DEC to HEX.
  if (bbb < 16)  {
    strBLU = String("0" + strBLU);  // Buffer with 0 if required.
  }  // END if
  String HEXstring = String("#" + strRED + strGRN + strBLU);  // Combine HEX fragments.;
  HEXstring.toUpperCase();  // Change HEX value to all upper case for ease of visuals.
  Blynk.setProperty(V8, "color", HEXstring);  // Change background colour of HEX Data Label.
  Blynk.virtualWrite(V8, HEXstring);  // Display HEX data.
  Blynk.setProperty(V9, "color", HEXstring);  // Send formatted HEX colour to vRGB.
  Blynk.virtualWrite(V9, 255);  // Activate vRGB.
  lcd.print(9, 0, HEXstring);
}  // END Blynk Function

Yeh I don’t say its not possible to self-implement it, but just suggesting it as a feature (which could be probably simple to add but very handy) :wink:

Nice idea. Thanks for sharing. @Pavel FYI

I think the most customisation could be obtained by implementing a color ramp, where the user can set the color at each value.
Pretty much like the color ramp in Blender (the 3d modelling tool):

Though i understand how that is harder to implement than a few presets and likely not a priority, since the gauge already serves its purpose very well :slight_smile:

@Gspin correct. Indeed this was initial idea. However, we changed this approach as it could be too complex for end users.

For that one, even if they would decide to implement it, we would wait half a year. And the aditional two colors it could be in the next update :stuck_out_tongue:


But why your two colours?.. perhaps someone else might want a different two colours, and so on :wink: Thus I think they might wait until they get a fully adjustable method. Meanwhile I set already my own colours and don’t have to wait at all :stuck_out_tongue_winking_eye:

@gspin I think it would be nice to have something that works like the zeRGBa control, easier for end users to quickly understand and adjust. And if one really need more precision… well, see my post above.

It doesn’t seem to complex to me.
Maybe it’s because i’m familiar with blender.

Overall, it depends on how wide your target userbase is: is it anyone who can plug an usb to an arduino?
Or do they need to be able to at least figure out how to write a few lines of C without just copy-pasting the whole thing?

The second category can probably understand with ease how a color ramp works, but i get that elitism can be an handicap in the app market.

Well I think red and green are the basic colors which everyone could use. But why wait for zeRGBa implementation of the colors if we could get this 2 colors instantly while waiting for the zeRGBa control :stuck_out_tongue:


We already have quick pics for Red and Green… and Yellow, White and two shades of Blue, even two variables where applicable. As well as the means to implement every variant of said colours and alternate colours via code.

That is assuming it is that “easy”… it might be just about as quick for a colour wheel, etc… but priorities and such…

Ultimately it is the Developer’s choice :wink:

We did the suggestions, and that is the only part which now matters.


1 Like

Giving a graded 64 colour tile or 256 colour tile would be useful.