Documentation issues and errors

indeed, but it is also said this issue was resolved in 2017:
Introduction - Blynk Documentation.

I have seen numerous small typos and missing stuff in the docs, but when I tried to help by reporting it I was shut down.

There’s more info in this thread:

As I said, I don’t pretend to understand the details, but it could be that the Geo DNS issue is fixed for the app and hardware that uses Blynk.begin to establish communication with the server, but not when making API calls; in which case the documentation could be correct when read in context (although there’s clearly scope for clarification).

Either way, it’s no real hardship to do a quick ping from the geo location used to create the project and use that when making API calls from any server/device that may see a different Blynk server.

Maybe that’s to do with the way in which the issues were flagged-up?
Threads can get very messy very quickly, and as the Blynk system changes rapidly it’s easy for info in the threads to become out of date. Threads are usually ‘shut down’ when people post information in old threads, because of the problems of trying to keep the threads focussed.
The easiest way of flagging-up an error in the documentation is to start a new thread which is correctly categorised under ‘issues and errors’, so that the developers can pick it up easily.

Having said that, the focus of the developers is obviously going to be to prioritise the commercial side of Blynk for the paying customers. There’s clearly a benefit to them in making the free version of Blynk as accessible and well documented as possible, as it can act as a feeder into the paid side of the business, but with limited resources and conflicting priorities documentation is usually the first casualty. As it is, I think the documentation is pretty good in the circumstances.

If more newbies read the documentation and used the search facilities in the forum then the signal to noise ratio of the forum would decrease significantly, and it would be easier to pick-out the useful nuggets of information that are contained in here. Another argument for ‘shutting-down’ threads that drift from one issue to another (as this one has!).



For documentation errors, of which I haven’t seen a single topic “shut down” over, the ideal place to make contributions seems to be here…

Particularly in the Issues and/or Pull request sections

1 Like

like this:

Marked as solved after some banter that did nothing to fix the error.

I was not asking how to use a gauge. Just reporting an error as requested by the pages quoted by the person who shut it down. Category now ‘solved’. Right.

It certainly does not encourage people and it is very clear that new people dare not make suggestions.

But as you say this is all off topic and I would rather be coding.

That thread isn’t ‘shut-down’, you can still edit its category and post comments if you wish.
I guess the reason that its category has been changed to ‘solved’ is that @Gunner highlighted a better place to report the isssue, but if you disagree then simply re-categorise it, and add a comment about why you’ve done that.


1 Like

Good idea @PeteKnight

Since this was becoming totally off topic from the original OP’s IFTTT issue, I have moved the relevant “documentation” posts here so @DaleSchultz can debate away :stuck_out_tongue:

If you see issues or needs for improvements, as you have indicated many times, the developers have already made it clear that user contributions are welcome. Please feel free to generate some good example sketches and or documentation suggestions and submit them on Blynk’s GitHub pages.