I believe that the Blynk app only sends data when the joystick changes despite the write interval of 100ms. This is a problem for me as as In the BLYNK_WRITE I am looking at a flag to determine if my tank is about to crash and the ESP8266 takes over and reverses the tank. However although the flag updates when clear of the obstacle the BLYNK_WRITE routine will only be called again when the joystick is moved or when you take you finger off so it never sees the change in the flag status.
The consequence of this is that I have to add the commands to test the flag and reverse the motors in the main loop with a delay of say 2 seconds otherwise the motors will reverse and get stuck in reverse as the “all clear” state of the flag never gets read.
Fortunately in this application I can afford to delay the BLYNK_WRITE updates.
Can you consider having the option to select continuous updates or as it is now.
As we’ve discussed before, this is an issue with the way that you’re writing the code rather than the functionality of the widgets.
The current version of Blynk is in maintenance only mode, so it’s extremely unlikely that there will be any changes to widget functionality in this version.
So, you need to approach the problem from a different angle and use the values received from the joysticks in a more appropriate manner.
I do appreciate your comment but when starting off with a new framework, if I can call Blynk that, there is a learning curve as one explores its limits and how as you say ones own approach must adapt. In some cases this is not always possible to achieve exactly what you want. I have spent a lot of time and tried quiet a few approaches and now have a good workable solution but not ideal but then I think that Blynk is orientated around home automation where a second or two does not matter and not real time control systems that require millisecond resolution. That said for many of my projects it is an ideal solution.
I found your comment “current version of Blynk is in maintenance only mode” interesting !
There has been no new development done on the current version since at least May 2019.
The only new releases since then have been bug fixes or library changes to prepare for the new Blynk.360 product release, which is currently being beta tested.
TBH, I don’t think that Blynk would have built widgets like the Joystick if it was just aimed at a HA environment, But, you have to give some thought to the infrastructure. You app is talking over the internet to a cloud server in Frankfurt, and your device is also listening over the internet to the same cloud server, all via your dodgy Sky internet connection
If you try pinging blynk-cloud.com and looking at your round trip times then this is the fastest that you could reasonably expect the device to respond to a changed value on the server. Pinging the server from your phone is likely to result in a similar ping time, so the fastest response time you can expect is the sum of these two values.
Then add-in the fact that the device doesn’t ‘see’ the new value until it processes a Blynk.run command and you’ll see where latency will build-up.
So, wanting your joystick widget to provide real-time data to your device is an unrealistic expectation, for any system with a similar architecture.
As I’ve said before, your collision avoidance system needs to override the last value you received from your joystick widget and work autonomously regardless of whether updated values are being received from the app via the server, or indeed whether the device is still connected to the server. It sounds like you’ve built your system to only process the collision avoidance commands when a new value is received from the server, rather than acting immediately to either stop or reverse the direction of travel.
I would say that this approach is a fundamental flaw regardless of the architecture being employed.
I do appreciate your comments as it does make me stop and think about what I am doing
I am running a local server. With regards to…
“t sounds like you’ve built your system to only process the collision avoidance commands when a new value is received from the server, rather than acting immediately to either stop or reverse the direction of travel.”
The collision avoidance is detected autonomously using an ATTiny84 which just sets a flag that is a digital input to the NodeMCU which stops reverses the direction of travel. My problem is that the Blynk app does not know this. I could send this back to the Blynk app a but I do think you can override the joystick until the detection system clears the flag, which is why I add a delay to stop the the ESP receiving Blynk commands (not an ideal solution).
I have been building systems for over 40 years with probable nearly every microprocess from the 70’ is almost every language from hand coded hex to R, C, Python and JS etc including IOS and Arduino apps and I think Blynk is a great product that I will continue to use. But I fully accept that at present I do not know enough about Blynk to get the best out of it. I would hazzard guess that Blynk is based on async requests rather than a TCP or UDP websocket(s)
