We the People - a request to the Respected Lord of the Buttons

Just wanted to say that :stuck_out_tongue:

Well at least led dot-matrix would be really possible to make with Blynk using half size, non-labeled leds. Why not? Instead of making/buying real dot matrix, you can always build and control one with Blynk.

It could be very usable for number of school projects, not even bad from business perspective, and I suppose it’s easy to cut off led widget to half size from development point of view, but than again, I may be terribly wrong here.

Yep… why not :smiley:

1 Like

That’s exactly what I’m talking about. Now just try to imagine double v-resolution on that screen, You could generate scrolling/flashing/inverting text, drawings, emoticons, even simple animations,

OH, I would like 1/2 sized and even 2x sized LED widgets as well (right now I can use a button to simulate one)… but one argument at a time :stuck_out_tongue:

1 Like

Yes, button works fine with me as big led as well. Having button in RTC widget size would give even more possibilities for that.

Having buttons that can be resized down to LED widget size an up to full screen size would add a lot of flexibility and I wouldn’t imagine that it would be a massive amount of development work. This would also allow people to create their own radio button sets, which is something that I would find useful.

Are there any plans to change the way that the background grid works? This also has quite a large role to play in the way that projects can be laid out and changes in this area could open-up more possibilities in app screen design.
The current 4x4 “Lego brick” is the smallest level of granularity in the grid, and corresponds to the size of the LED widget (is this why a smaller LED widget will never happen?).
Changes to the way in which widgets “snap to” the grid - possibly allowing the user to choose between the current setting, a more precise setting, or totally free floating - would give more flexibility. Maybe even allowing widgets to overlap and having a “send to back” and “bring to front” functionality - at least in the screen design mode - would also creat lots of possibilities.

If we did have a finer granularity of the background grid then we could have horizontal and vertical dividers, and ‘container’ boxes to put widgets in to separate them on screen.

A few small tweaks to the colour schemes that allow the screen background colour to be identical to the widget background colour (if the user wants it to be) would also make some projects look more professional and would certainly be needed if we had totally unconstrained placing of widgets on the background.

I don’t need/expect responses to these suggestions, I’m just throwing a few ideas in the mix for you guys to kick around.



i never talked about resizing leds. they are ok as is (for me). all i asked was a button with the size of 2 led widgets.

they are already the size of 2 led widgets…

1 Like

what’s the practical implementation for that beyond education? It sounds of course cool, no doubt. However I don’t see any reason doing such UI on a smartphone. The beauty of LED matrix is that it’s a physical object, which can be seen, touched, interacted with etc.

Never underestimate the willingness and creativity of others to totally “misuse” your product in wondrously unthought of ways :smiley:


Exactly. But if you don’t have one, that beauty can still be easily simulated within your Blynk app :slight_smile:
Some simple messages or signs could be created using dot-matrix simulation, so it could be usable beyond playing games. Gunner, for example, could build simulation of old-school industrial info led displays :slight_smile:

Don’t forget the LED widget itself, which you have to pick in design mode to move or change settings. It is larger than a key on my phone’s keyboard and it doesn’t get any bigger or smaller when Blynk is running. Blynk’s 1x1 block is a perfectly pickable size.

On the other hand I recognize that

  • several buttons in a cluster with no padding may cause misfires
  • several buttons in a cluster is probably a symptom of a larger UI design problem

…but I don’t think these are reasons to deny us the option.

Blynk design will definitely move towards:

  • decluttering existing dashboards (that’s why “squezing more” into dense mobile layout won’t happen)
  • adding more “air” to the layout
  • decompressing existing elements
  • minimalism (to reasonable extend)
  • layout flexibility (more granular grid)
  • pre-designed combinations of widgets for specific use cases
  • customizations (images, colors, fonts, etc.)
  • options for more generic visual style

Been a fan and user for almost a year. Signed up just to reply here, please make the buttons smaller.


My wishlist:

  1. I would like to see buttons for which properties can be attached. E.g time schedules and associated action. Eg. If I have a light button, I should be able to turn it on manually or by way of attaching a schedule (specific time spec or timeout after manually turning it on)

  2. Button sizes to be chosen for all widgets- small, medium, large. From LED, RTC to Button size.

You can do this with the Time Input widget.

This you can do with coding.

No need to connect these functions to the buttons,

1 Like

1 - you should try the Eventor widget. it should cover most types of the possible use cases

I’ve looked at the Timer widget, Time input widget and the Eventor. Eventor is a wonderful widget for event driven triggers. I want to turn on and off relays based on start stop times. The timer requires one to go into development mode and set the time. Time input widget allows time input in runtime. I wish the time input widget would send 1 and 0 for start and stop like the timer does based on the specified schedule. That seems like the simplest implementation. However, the time input has to be parsed and schedules created on the device to handle the relays.

If I’ve got this wrong, please do correct me.

You could setup via 2 rules for start and stop in the Eventor using trigger time.

This is again done in Dev mode. This can be done by timer widget in Dev mode too easily. Like I said earlier, it would’ve been nice if the time input widget sent 1 and 0 for start and stop on matching schedules like the timer does. These can then be handled by BLINK_WRITE (Vx) in the device.

Will save a lot of coding on the device. I’ve seen the code that @Costas has written. Will need to see how to adapt that.

Time Input would not send 1 or 0 for its pin, that’s not how it has been meant to function, as its value contain it’s start/stop/timezone/etc, not the 1 or 0.