microBlocks To SNAP! using WebThingServer - Variable TYPE problems

[Turgut Guneysu]

Hi John,

I am reporting it here, not knowing if it is proper or not ! Could not find a suitable category in SNAP Forums. Both side’s programs are included to save click-agony .

I am testing microBlocks to SNAP interaction using the WTS.

On the mB side I have a small code defining some vars:

On the SNAP side a complementary version reading and setting all three vars.

Results are interesting:

READING:

• For the BOOLEAN var:

‌

• For the NUMBER var:

‌

• For the STRING var:

‌

Apparently, SNAP does not like STRINGs that are NOT quote delimited. When I change the mB side to

‌

I get a GOOD read:

‌

WRITING:

• For the BOOLEAN var:

‌

Operation never completes on SNAP side for either one of the above updates.
MicroBlocks crashes with command.com window displaying:

and the IDE displaying:

However, setting the BOOLEAN var to 1 on SNAP side completes the operation properly. Yet because 1 is stored in the TF var on mB side, it is NOT a BOOLEAN anymore, and fails subsequent BOOLEAN compares !

• For the NUMBER var:

Works OK.

• For the STRING var:

microBlocks seems to strip the FIRST set of quotes, if there are any! All additional quote pairs after the first pair is retained.

So what also happens is: a mB var with quotes is read on SNAP side correctly. If an update from SNAP side without quotes is submitted, mB side changes and loses the quotes, but displays the value correctly. However, on subsequent READS from the SNAP side the operation fails, because mB side has lost the quotes in the variable.

These are way too confusing…

‌

[John Maloney]

These issues should be fixed in v0.3.4. Give it a try and let me know if you find any other problems. Thanks!

[Turgut Guneysu]

OK, The previous problems are not happening any more.

However, ALL variable exchanges are in TEXT format.

No number and no boolean type is preserved across the /mb/getVar exchange.

When SNAP! receives a var set to Boolean TRUE/FALSE in microBlocks, it displays the boolean icon TRUE/FALSE as value, but the TYPE inquiry of the var returns TRUE for TEXT, and FALSE for Boolean.

Same goes for vars that are NUMBERs, with TRUE for TEXT and FALSE for NUMBER.

In the reverse direction, BOOLEANS are preserved and NUMBERS are changed to TEXT in microBlocks. However, these NUMBER values FAIL both TEXT and NUMBER comparisons. The only one that matches is if the compare is done with JOIN block using a blank argument at the first position and the var in the second. Here I assumed a quoted var value would be TEXT, but it probably is not correct. If so, then the actual JOIN compare is the correct TEXT detection method, and that works. But it still is confusing, since MB does not really have TEXT / NUMBER type differentiation when it comes to comparisons, or it handles it pretty subtlety in the background.

Below is a capture of what I described. SNAP! sets myVar to 555 using:

‌

And on microBlocks, this is what we get.

‌

Just to be clear, if I use “set myVar to 555” block in MB locally, the myVar display again shows 555, but the compare operation displays NUMBER.

[John Maloney]

Thanks for all the testing. I think there may be some issues with types on the Snap! side. The data is passed as JSON strings which may be why Snap! reports values as text.

On the MicroBlocks side, it looks like you’re getting 555 as a string but ‘555’ is not the same as ‘“555”’ (which has double quotes around it).

To quote a number in MicroBlocks, you don’t add quotes, you make sure that the input slot is a rectangular string slot. For input slots that can take either a number or a string, such as the equals block, MicroBlocks guesses the type based on the slot contents and changes the shape of the slot to let you know what it guessed. Here’s an example:

‌

MicroBlocks guessed that the left input was a number and the right one was a string. But let’s say you want to treat 123 as a string. Then you can right-click on the left input slot and select “string only”:

‌

Now the slot become rectangular showing the MicroBlocks will treat it as the string “123” not as a number:

‌

Snap! may be passing values from MicroBlocks around as strings and only converting them to numbers or booleans when they are used in a context that requires those types. You might try parsing JSON in Snap! to see if that’s the case for all values extracted from JSON. But, from the practical standpoint, it sounds as though you can use values from MicroBlocks in Snap! That is, you could use numbers from the MicroBlocks tilt block to control a Snap! sprite or a boolean from MicroBlocks in an Snap! “if” statement. Is that right?

[John Maloney]

P.S. For now, at least, this issue tracker is the best place to report issues with Snap!'s interaction with MicroBlocks.

[Turgut Guneysu]

First, thanks for the pointer on the square vs rounded white input fields. This had totally escaped my attention.

I took a look at the properties request of a WebThing from SNAP! side of a WebThing I had defined in microBlocks:

‌

The SNAP! properties request ends up receiving this from MB:

‌

Here all three VARs are shown as type STRING. But when individual VARs are requested, they all arrive in correct TYPE in JSON.

By the way, do the WebThing properties have any control over the variables that are assigned to them?
e.g.: myNumber is defined as a number with range 0 - 255. But nothing enforces this rule ! Any value can be assigned.

‌

But, from the practical standpoint, it sounds as though you can use values from MicroBlocks in Snap! That is, you could use numbers from the MicroBlocks tilt block to control a Snap! sprite or a boolean from MicroBlocks in an Snap! “if” statement. Is that right?

YES, they all produce correct comparisons in SNAP!.

[John Maloney]

Here all three VARs are shown as type STRING. But when individual VARs are requested, they all arrive in correct TYPE in JSON.

This looks like a minor bug in the IDE’s Web Things Gateway code.

By the way, do the WebThing properties have any control over the variables that are assigned to them? 

No, the range info is just a guideline used by the Mozilla WebThings gateway to set the range of the slider for that variable in their browser UI. It’s not actually relevant to the Snap!/MicroBlocks interaction (unless you created a Snap! project that built sliders). Even when working with the Mozilla WebThings gateway, it is up to the Thing creator to ensure that values stay within their declared ranges; nothing enforces that.

If you’re interested, check out https://iot.mozilla.org/gateway/. If you have a Raspberry Pi, you can run the free, open-source gateway software on it. I’m using the gateway and MicroBlocks to control the heating system for my 17-unit condo building. :-)

‌

[John Maloney]

We've replaced the IDE's WebThingServer with a simpler HTTP Server.