Ver 0.4.0 Problems

[Turgut Guneysu]

Hi John & Bernat,

Something is amiss; microBlocks is not running as it used to.

• With WEMOS8266 plugged in, it used to be recognized and operating immediately.
  NOW, mB loads, firmware update message comes up, clicking OK will kick off ESPTOOL 2.6 instead of 2.8.
  And mB goes into a firmware update loop on IDE screen.
  Manual LOAD of firmware works OK, recognized OK in IDE, and mB starts OK.

‌

• When WebThings library is selected to be loaded, it also loads HTTP Server library. (Maybe it is supposed to be like that ?)

• Reporter Blocks such “thing description JSON”, “properties JSON”, “event definitions JSON” display results in a single line output format that gets clipped by the IDE screen edges and are NOT readable.
  If possible, it should be in WRAPPED format based on screen dimensions or, better yet, based on a sizable display window.

  

‌

• HTTP GET returned results in JSON format seem to have strange issues:

1. I have tried it using my own site data via URL: http://www.kromsan.com.tr/TGdev/tgbasinc.php?islem=json

This returns a 345 byte JSON string:

{ "1 " : { "time" : "1587209156.1897" , "adc" : 111 , "volts" : 1.14 , "bars" : 1.11 }, "2 " : { "time" : "1587209156.1897" , "adc" : 222 , "volts" : 2.14 , "bars" : 2.22 }, "3 " : { "time" : "1587209156.1897" , "adc" : 333 , "volts" : 3.14 , "bars" : 3.33 }, "4 " : { "time" : "1587209156.1897" , "adc" : 444 , "volts" : 1.14 , "bars" : 4.44 }}

When tried in mB with HTTP GET block:

a. returned data length is shown as 619. It should be 345
b. returned string is incomplete: it is missing the "bars" : 4.44 }} due to some length limitation at 328 bytes.

* HTTP GET for an update on the site works incorrectly when the “data” input area is used, but works OK when the data is appended to the end of the URL, same as in the browser window:

DOES WORK:

‌

DOES NOT WORK:

‌

‌

In this instance:

a. the fields names are submitted, but the values are all set to 0.
b. for the very last field (bars) the field name is submitted, but the value is totally omitted or truncated.
(shown in BOLD below)

The same transaction done by omitting the DATA field, and using the URL field, updates the fields correctly.
(shown in BOLD ITALICS below)

Here is the display from the browser version of the transaction, so you can see what I mean:
URL submitted: http://www.kromsan.com.tr/TGdev/tgbasinc.php?islem=json

{ "1 " : { "time" : "1587209156.1897" , "adc" : 111 , "volts" : 1.14 , "bars" : 1.11 }, "2 " : { "time" : "1587209156.1897" , "adc" : 222 , "volts" : 2.14 , "bars" : 2.22 }, "3 " : { "time" : "1587209156.1897" , "adc" : 333 , "volts" : 3.14 , "bars" : 3.33 }, "4 " : { "time" : "1587209156.1897" , "adc" : 444 , "volts" : 1.14 , "bars" : 4.44 }, "5 " : { "time" : "1587210449.1245" , "adc" : 0 , "volts" : 0 , "bars" : }, "6 " : { "time" : "1587210610.2704" , "adc" : 5555 , "volts" : 3.25 , "bars" : 5.555 }}

‌

NOTE:
I am aware that there are LENGTH restrictions for the mB IDE. However, when working with JSON data retrieval, there are all sorts of LENGTHS of data returned, usually without limits or very large ones !

In the HTTP GET update tests, I was NOT quite sure of the delineations for the DATA area. I have tried putting various combos of STARTING points in there, but most resulted in no updates at all. I have only reported the cases where I was able to get an update in the backend code. As such I might have done something wrong unintentionally. If you or Bernat tell me what is considered acceptable in DATA area, I can retest.

[Bernat Romagosa]

Hi, Turgut.

For the future, could you please create a single issue report per issue? It’s hard to respond to these and even harder to track them otherwise.

Let me reply to some of the issues you’re listing:

When WebThings library is selected to be loaded, it also loads HTTP Server library. (Maybe it is supposed to be like that ?)

HTTP Server is a dependency of Web Thing, that’s why loading one pulls the other along.

Reporter Blocks such “thing description JSON”, “properties JSON”, “event definitions JSON” display results in a single line output format that gets clipped by the IDE screen edges and are NOT readable.

I’ve just fixed word wrapping for strings that contain no whitespace.

HTTP GET for an update on the site works incorrectly when the “data” input area is used, but works OK when the data is appended to the end of the URL, same as in the browser window:

That’s supposed to happen. GET parameters are part of the URL. They’re parts of a query and are not meant to carry data. The data field is to be used for payloads, like the ones carried by POST or PUT requests. GET requests never carry a payload in their body. You can test your same example with cURL and you’ll see the same results:

curl "https://www.kromsan.com.tr/TGdev/tgbasinc.php?islem=yaz" -d "&myid=NODEMCU"

I don’t have time to check on the others right now…

[Bernat Romagosa]

(I’m back at work now)

I didn’t check on the particular cut string problem, but here’s two useful things to know:

1) MicroBlocks does have a limit on how long the content of a speech bubble can be. As you see here, the lines shown in the speech bubble go up to 26, but the string is actually 30 lines long:

Here’s proof that the variable holds more data than the “say” block shows:

@John Maloney , maybe we should add an ellipse to speech bubbles when the content has been trimmed to fit into a serial message. What do you think?

2) Although the ( http:// [ ] ) block is meant for small queries, John fixed my request primitive to be able to gather infinite amounts of data. This has to be done by batches, as the microcontroller doesn’t have an infinite amount of memory. We haven’t yet implemented a user-friendly block that lets you fetch arbitrary amounts of data by batches, but it’s on our TODO list for the near future.

[John Maloney]

maybe we should add an ellipse to speech bubbles when the content has been trimmed to fit into a serial message.

Good idea. The string truncation has sometimes confused me, too.

‌

[Bernat Romagosa]

I’m closing this one as it was a collection of different issues and some of them have been fixed. Let’s use one entry per issue so we can keep better track of what’s fixed and what’s not