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.
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!).
Pete.
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
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.
Pete.
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
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.