you backend folks will probably know whats going on here -
there are various bluetooth firmware versions - 2.0 with app inventor works great.
any other firmware (on hc-05&06) with mit app inventor works like trash.
this IS an app inventor problem as auxiliary serial apps work fine.
the issue is that the app freezes - almost as if its stuck in the "BT receive text" block until it reaches a timeout. if you switch to NOT looking for the delimiter byte (using bytes available to receive), it doesnt freeze but your data is cut at incorrect places. so thats useless.
sent from controller = 0.00 PSI20.00:10 (so nothing extravagant)
seems like a bad handshake deal - can we fix this?
the only BT chip that seems to work well with MIT app inventor currently is DSD tech's HC-05 chip on amazon. this same code runs flawless with those (the 2.0 firmware)
irrelevant to this issue really - im reading a sensor when connected all the time, where a timer function moves a 0 into connected. if I lose connection for 10 seconds, its basically a way for the app to know im not connected (virtual screen things). the boolean app connected deal is basically a function that prevents received data from appearing until the setup prompts are satisfied on screen by user (but still clears BT buffer - which is on the backend of receive text function block seemingly)
I can make a test app with almost nothing in it except for connecting and receiving bt string and printing string into a text box - same issue appears.
I know you are the BT guy - If you are in the US, id be willing to send you a modern hc-05/06 and the oldschool HC-05 from a few years ago so you could see it happen first hand.
im just hoping someone fixes it - I know its an MIT issue.
I've used this platform to make HMI's for a lot of standalone machines in start up plants over the years, and it works really well. I'm down to only one supplier that works with the BT code now - the DSD tech HC-05 on amazon. the rest must have something different with their firmware where they and app inventor dont get along the best.
its odd that its spoken of so little, but with some digging on the internet I've found my experience discovered by others - their solution is the same as mine, find supplier of old firmware style HC-05/06 chips. (which is a sub-ideal solution at best)
when you are pulling sensor data 4 times a second because you are making adaptive air fuel ratio trimming adjustments to a vehicle, you know full well its not connected when you dont receive any new data after a set amount of time.
but it does work as I have ran this same code for years.
still works with old firmware hc-05 chips - does not work correctly with new, its an app inventor issue 100% that is worth correcting.
but dont take my word for it, buy an HC-05 and try to communicate with app inventor and see how it goes. heck, ill buy you the HC-05 ( both old style and new) and I'll patch anyone over the test code to save them time.
thunderhead289 on youtube
automation engineer, Allen Bradley PLC & FANUC robotics programmer.
sure seems like this is a known issue but everyone avoids talking about it ....
this is a stellar platform for creating an HMI that communicates over BT for fairly complex machine controls. My fear is that there will come a time where the supply of the chips with the older firmware dries up and then its all over.
(again, the only one that works correctly is the HC-05 by DSD Tech - can be found on Amazon)
Dear @Reality_Bytes,
I absolutely agree with you, I've used so many times the old HC05 (or, even better, the HC06) when they were as cheap as 3 or 4 $, but now I'm using the ESP32 boards, because they feature in a unique board the CPU, the WiFi, the BT, serial lines and many I/O's. The cons is the fact that the I/O voltage is 3.3 V which requires always a voltage reduction when connected to a 5V source, but at the very end you save money, space and ...hreadaches....
Great job your investigation and thanks for having shared the results.
Best, Ugo.
