I dug a bit more with Wireshark. It looks like the socket is actually properly closed by the hub if socket.end() is not explicitly called.

I suspect it is closed automatically when the Socket object is garbage collected.

Turns out it is quite easy to cause what looks like an Flic Hub (Firmware: 3.0.12) internal stack error. This (non recursive) code runs perfectly on a regular web browser but will crash after 55 iterations on the hub.

var counter =0;

function stacksize()
 { err = new Error();
   return err.stack.split("\n").length-1;
 }

function run()
  {console.log("iteration "+counter+" / stack size ="+ stacksize() );
   counter++;
   setTimeout(run,1);
  }

run();

Here are the results on the SDK console:

iteration 54 / stack size =2
iteration 55 / stack size =2
FATAL ERROR:
uncaught: 'cannot push beyond allocated stack'

A workaround is to use setInterval()

function run()
  {	console.log("iteration "+counter+" / stack size ="+ stacksize() );
	  counter++;
 }
setInterval(run,1)

But it's not a perfect solution, with some slightly more complex (but still non recursive) code, the 'cannot push beyond allocated stack' error will randomly appear again.

The "Restart after crash" option doesn't seem to have any effect, at least on this error.

Long story short, I'm under the impression that the hub SDK is a nice little toy, but it is unfortunately too limited/unreliable for even basic "real life" applications.

martinm less than a minute ago
@Emil ok, thanks I managed to make it work with the raw TCP API.

Note that although mentioned in the "drain" callback details net.Socket.write() is not documented.

Also, it looks like there is no way to properly close the socket ie once the data has been sent and acknowledged by the receiver. net.Socket.end() is not documented either and I suspect that "drain" doesn't wait for the ACK. May I count on the hub to properly clean up his stuff (no socket leak) once the socket has been closed by the other end ?

BTW, coding network I/O with old school javascript (no async / await) is a pain.

I need to send a (small) form-encoded binary buffer (aka file upload) to a networked device from the hub (Firmware: 3.0.12). I tried different ways but couldn't manage to get it working.

I checked with Wireshark, it looks like the HUB is blindly converting the 'options.content' value to UTF 8 before posting it, regardless of the content-type.

• sending a string made of the buffer bytes
  => UTF8 corruption
• sending data as a Uint8Array
  => the hub posts the string "[object Uint8Array ]"
• setting various HTTP headers such as
  Content-Type: multipart/form-data; boundary=...
  Content-Type: application/octet-stream
  Content-Transfer-Encoding: binary
  => the hub doesn't care.

It there a way to go around this limitation / bug ?

Ok, I assume that channel.auto_disconnect_time unit is seconds.

But I think that I eventually found out what was draining the batteries, in the python scan wizard exemple in the is_private case, the scanner is never removed. I suspect this forces all the buttons to stay active if no-one press on the foreign button for 7 sec. Since I fixed that with a timeout, batteries are felling much better

I'm using the python library to write a gateway between Flic buttons and some Yoctopuce products. It worked well so far, but I'm a bit worried about something: I added button battery monitoring and noticed that batteries level is dropping quite fast, at this rate, batteries won't last more than a few weeks.

So my question is: are there some programming strategies that will suck less energy than others? I found some mentions of active and passive modes, but there is no reference to such modes in the python API.

Is there some developers from Flic in there ?
I had to buy more buttons to find out, here is the answer

• White button : "white"
• Black button: "black"
• Green button: "green"
• Mint turquoise button: "turquoise"
• Glow in the dark button: "gitd"

I suspect there are also Pale Yellow "yellow" buttons in the wild.

Hi!

Python documentation for get_button_info(self, bd_addr, callback): states:

	The server will send back its information directly and the callback will be called
        once the response arrives. Responses will arrive in the same order as requested.
	
	The callback takes three parameters:
            bd_addr, 
            uuid (hex string of 32 characters), 
            color (string and None if unknown).

What are the possible values for color ? are they "official" colors name, such as HTML color names?