But if you’re a Node-Red user than the standard dashboard isn’t much different to the current Blynk dashboard and at least you can enhance the Node-Red one if you choose to go down that route.
The real problem for Node-Red users is the lack of a Blynk websockets interface, so Blynk won’t be a simple plug-in anymore. You can get around some of that with API calls (which incidentally have stopped working in the Beta system this afternoon), but its far less elegant or functional than the current Node-Red/Blynk system.
The missed opportunity to fully integrate MQTT into Blynk is also something that will disappoint Node-Red users.
Personally I’m looking for something that can replace Blynk as my mobile app front-end to Node-Red/MQTT. This is because simply keeping my fingers crossed that the existing Blynk system will be maintained over the long term, or that websockets and a replacement plugin will be created for Node-Red, isn’t a good strategy.
@Pavel it would be nice to understand what the Blynk roadmap looks like, and what your priorities are going forward.
I raised the question of websockets and Node-Red integration at the beginning of beta testing and you said that websockets was on the roadmap, but I’ve heard nothing on this since.
It would be great if @gab.lau could be involved in discussions about Node-Red integration, as without either a websockets plugin or a fully implemented MQTT integration Blynk becomes useless for Node-Red users.
It may be too late for people like myself, as without a clear delivery path we need to have a contingency plan, but it would at least provide a method of using Node-Red and Blynk together in future.
We just rolled out a huge update with a ton of new features. Obviously there will be a stabilization phase.
After that we plan a series of releases with planned features rolling out. For example voice assistants are planned as next one.
Roadmap is not carved in stone as it’s dynamically updated based on the feedback we get from developers, businesses, and of course our own vision. That’s why we can only inform on nearest releases.
Would you be able to provide me with examples of a good roadmap from other companies? I’d be happy to review and see if we can implement something similar or hopefully better.
Pricing for the PLUS plan looks reasonable at US$4.99/m. I have more than 10 devices, but a one-off US$4.99/device also seems reasonable. (Anything that costs less than a pint is reasonable in my view, and I have more than one pint a month . . . )
Will be interesting to see what the widgets are, and definitely voice integration will be a bonus - most of my projects are home automation and sensors, so for me this would be great.
Hi everyone, sorry but I’m very busy at the moment. @PeteKnight I took a look at the blynk 2.0 code, I don’t think it is very complicated to switch my Node-Red integration from WS to TCP/IP.
However at the moment I just don’t have the time to do it. Maybe in the summer.
@Pavel The important question is: how long will the old blynk cloud still work? is there a switch-off date?
I believe that a roadmap must specify the goals and times to reach them.
For example:
1 July - Command integration
1 September - MQTT support
1 December - Websocket interface
But I also understand how difficult it can be to achieve it, also considering all the “activities” you have to do.
Personally I believe I will stick with the old version of blynk, as long as the android app works and there is the public cloud server.
@Pavel I don’t believe that Blynk has a lot of competition in the marketplace, and serious competitors will have their own development priorities and obstacles to overcome, so in that respect I think you’re being overly paranoid.
You previously created a public portal allowing users to suggest ideas/improvements and vote on them, and if your competitors were wanting to “steal your thunder” then they simply have to look at that and implement the things that users have said they would like to see.
All companies have conflicting priorities when it comes to balancing development priorities, and its especially difficult for small business with limited resources (but its still difficult for larger corporations if they want to remain profitable).
However, communication is the key to customer satisfaction, and that something that Blynk is particularly bad at. Users would fully understand if they were told that your published roadmap had been pushed back by 3 or 6 months because a new customer has just been landed, but that sort of information is never forthcoming. Instead we get a “Sign-up for beta testing…” announcement followed by almost nothing for two years.
Presumably you use an Agile development process, and have some way of documenting your work tasks, dependencies, resource requirements etc to plan your next sprints?
Whilst I’m not suggesting that you reveal this level of detail to users, this type of system should allow you to quickly revise your estimates of timelines on deliverables and understand internally what the roadmap looks like.
This forum would be an ideal place for a blog on what’s happening within Blynk as a company, what your major development plans are, and how these are progressing.
I fully agree with @gab.lau’s example of high level goals and planned delivery dates, and without at least this level of information, and some clearer commitments regarding End of Life for the existing product, you’ll lose some of your potential “Plus” subscribers.
A Local server is a must for D.I.Y not only for the user but also to keep the cost down for server space and traffic for the Blynk company, the Local server should be open source so it could be community developed (Which would also be beneficial for Blynk as the get free development help that the can chose to use or not in the commercial version. The mobile App however could be commercialized but i Guess a one time fee less than 50usd is crucial and would give higher profit since it would sell magnitudes better than if it was priced at 100!
@PeteKnight thanks for your feedback. BTW, if you check the roadmap portal - a lot of things were implemented. Especially top requested ones. But I agree that communication should be better. Now we have resources for that and will try to be much better.
@Greggan, unfortunately, I can’t agree with you simply based on data:
Only a small fraction of current Blynk users use Local Server. The majority prefer the convenience of a hosted server.
In the 7 years we got only a few commits to the server code. Awesome if you was one of them !
We’ve always offered Blynk Cloud at no additional charge and with no limits (10msgs/sec is incomparable with any IoT platform out there). Best part: we still can afford that.
Less experienced users decide that Local Server is for them (without no expertise for that) and create additional load on our tech support team. Which is not supported monetary as the server is free.
If you were a product manager of Blynk, what would be a reason to support this feature?
The case for local server are pretty-much as defined in the documentation…
Why do I need Local Blynk Server?
Better security. You are the only one who knows about the server. You can setup security policies tied to your specific needs (MAC, IPs, login names, etc). You can also make it accessible only within your private network.
Better stability. No need to rely on 3rd party Cloud solution. You have the full control.
Lower latency. Server is as close to you as it could be.
Maximum privacy. All data is stored locally and is not shared with anyone.
But as @Pavel says, local server makes no sense from Blynk’s point of view, mostly because Blynk has no control over whether the server is used for commercial reasons.
However, there have been mixed messages from Blynk regarding local server for Blynk.360 and it would be nice if there was a definitive statement from Blynk along the lines of “we have no plans to implement local server in the foreseeable future” if that is the case, so that existing users know where they stand when it comes to this issue.
I received an email today from @MariiaDrozhak saying “Blynk new platform is officially out of BETA!”
It appears that the date of 25th June is when my 1 month of free PRO access (a thank you for being a beta tester) and that new users can sign-up to Blynk.360 immediately.
This makes the questions about what widgets are available in the Basic version, and what the Transaction Caps are, more important.
Yes. But that’s not the main problem. The main problem is that developing the local server requires additional effort. I would say It would give ~20% to the server maintenance cost for us. So that’s why for now we decided to drop it.
Also a Node Red/MQTT user here, and same as @PeteKnight mentioned above I will be keeping my fingers crossed that the existing Blynk system is maintained.
I don’t like the $4.99 monthly charging, and not sure I want to pay $4.99 for each device. (I wonder if my Pi running node red would run as one device?). I spent enough on ‘energy’ and that seemed fair as a one of payment, free to use as I wished.
In fact although a beta tester I did not actually try the system for more than a couple of hours, seems way overly complicated for my personal needs. I am grateful for the original Blynk app and cloud server, it’s been a great run and I think it still may be the best front-end solution, however I will need to look for a replacement if it is dropped.
A few points I am not clear on:
Is there ever going to be a ‘switch off’ of Blynk 1.0 cloud support?
Will the original Blynk app continue to be available for those who want to run the original local server?
Can the community continue to support the local server via pull requests?
I think the simple solution is to use a single device, provided that the number of virtual pins isn’t restricted.
I started off creating multiple devices, but if I was going to do it again in V1.0 I’d use one plus a spreadsheet to keep track of what each one is used for.
In a way V2.,0 makes that easier as the datastreams have names (aliases I guess) so the spreadsheet might be redundant.
I think that’s much easier for Android users who can download the .apk file and continue to use the app even if it disappears from the play store - provided that it still works with their current Android version.
I think it will be mobile OS changes that eventually kill-off v1.0
As previously mentioned, we don’t have any plans to switch off old Blynk in the nearest future. It will continue running for a half-year or even much longer.
Yes, but it won’t be getting any updates/improvements. We may also limit an ability to register new accounts (this should only affect our Public Cloud).
Sure.
The updated server software became much more complicated to install and maintain (which is expected, taking into account all of the new features). Right now we offer “on-premises” installation of Blynk.Cloud for Enterprise customers only, and there’s no plan to open-source the full version of it in the foreseeable future.
MQTT support is in our plans. In fact, the Datastreams concept is abstracting-away the Blynk’s Virtual Pins, and that was designed exactly to support other protocols (not only MQTT).
I am convinced that if blynk V1 goes to become fully open source, we are a lot of users able to make it evolve faster than the last 3 years you did.
Why don’t you provide us the source code and keep V2 for commercial busyness only?
Many of us are using local server, it’s more secure, more stable and can be used even if our ISP is down.
)
- they keep complete secrecy.
!
