5 ms·

There is a glaring, painful hole in the current mBed IoT platform as it currently stands which unfortunately is something recurrent throughout the IoT ecosystem

There is a glaring, painful hole in the current mBed IoT platform as it currently stands which unfortunately is something recurrent throughout the IoT ecosystem. There are no server functions. If your device is going to pulling and pushing to the mothership, and only the mothership, then the API they gave is adequate. However, if you want your IoT temperature nodes to be able to talk to your IoT vent register nodes, you have to have both of them polling the main server to fetch and get data, and have both become expensive paperweights when your internet connection drops. It seems to be a recurrent problem with the mbed universe. The mbed editor, which they're going to be revamping Real Soon Now, has very much the same problem, where losing internet connectivity means that you're without an editor until whatever problem is corrected. IoT is only really going to be useful if the Things can talk back, otherwise, you're just going to have half-assed toys.

danjayh 11y ago
I took a look at the mbed os socket API, and it supports opening a socket in 'listen' mode. With a few lines of code, you should be able to build this into a basic server. What functionality is missing that would be required for the use cases you mention? Relevant link: https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/11_API_sockets/index.html https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/1...
- Sanddancer 11y ago
  mbed's documentation is an absolute mess, with islands of information and little to no linking to relevant places. I had been looking at their mbed client api -- https://docs.mbed.com/docs/mbed-client-guide/en/latest/ https://docs.mbed.com/docs/mbed-client-guide/en/latest/ -- which only supports client -> their server activities, and doesn't link at all to the lower level APIs. The socket support they provide is also a lot more limited than other RTOSes that target Arm Cortex-M devices, for example TI RTOS and NXP's MQX both offer IPv4, and full IPv6. Then again, it seems to typify a lot of ARM's software offerings. They have Keil uVision, which is an Eclipse-based IDE, that is barely mentioned at all in the various mbed documentation, and doesn't have any integration with their newer toolchain they seem to be building up. It just gives a very unfocused feeling in general regarding using their toolings.
  - danjayh 11y ago
    100% agree. It's incomplete & disorganized, a very sad state of affairs. They need to assign someone to go through and fix it.
johnny22 11y ago
you don't need to use the mbed online editor at all if you don't want. I don't. I just use vim and then their yotta tooling.
dmritard96 11y ago
Sanddancer - Interesting perspective - We are building sensors and vents (https://flair.co https://flair.co) and definitely getting the right amounts of function with and without the cloud is a major portion of our platform. Not using mbed Intranet vs Internet of Things is a huge question mark on the IoT imho.
- Sanddancer 11y ago
  Yeah, that balance is something I'm working on in the various animatronic and costuming projects I've got going. Yes, there is interesting reason for an internet enabled costume, but yeah, it shouldn't all fall apart just because it can't get signal. Though your product so far looks pretty great, it's definitely something I'm going to be bringing up with my housemates regarding the problems a household of seven generates regarding heating and cooling.

danjayh 11y ago

I took a look at the mbed os socket API, and it supports opening a socket in 'listen' mode. With a few lines of code, you should be able to build this into a basic server. What functionality is missing that would be required for the use cases you mention? Relevant link: https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/11_API_sockets/index.html https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/1...

Sanddancer 11y ago
mbed's documentation is an absolute mess, with islands of information and little to no linking to relevant places. I had been looking at their mbed client api -- https://docs.mbed.com/docs/mbed-client-guide/en/latest/ https://docs.mbed.com/docs/mbed-client-guide/en/latest/ -- which only supports client -> their server activities, and doesn't link at all to the lower level APIs. The socket support they provide is also a lot more limited than other RTOSes that target Arm Cortex-M devices, for example TI RTOS and NXP's MQX both offer IPv4, and full IPv6. Then again, it seems to typify a lot of ARM's software offerings. They have Keil uVision, which is an Eclipse-based IDE, that is barely mentioned at all in the various mbed documentation, and doesn't have any integration with their newer toolchain they seem to be building up. It just gives a very unfocused feeling in general regarding using their toolings.
- danjayh 11y ago
  100% agree. It's incomplete & disorganized, a very sad state of affairs. They need to assign someone to go through and fix it.

johnny22 11y ago

you don't need to use the mbed online editor at all if you don't want. I don't. I just use vim and then their yotta tooling.

dmritard96 11y ago

Sanddancer - Interesting perspective - We are building sensors and vents (https://flair.co https://flair.co) and definitely getting the right amounts of function with and without the cloud is a major portion of our platform. Not using mbed Intranet vs Internet of Things is a huge question mark on the IoT imho.

Sanddancer 11y ago
Yeah, that balance is something I'm working on in the various animatronic and costuming projects I've got going. Yes, there is interesting reason for an internet enabled costume, but yeah, it shouldn't all fall apart just because it can't get signal. Though your product so far looks pretty great, it's definitely something I'm going to be bringing up with my housemates regarding the problems a household of seven generates regarding heating and cooling.