Boiling it down to a single principle, I don't like how beacons are automatically MQTT'd to the world when an MQTT configuration is set. At least have a checkbox to turn MQTT beacon broadcasting off.

I could easily set up a Pi with Mosquitto, but that is one extra piece to the puzzle. Sure it doesn't matter if I use a Pi in my home, but people would prefer an IoT product that has 1 less piece. Also, selling 1,000-10,000 counts of a product to separate sites would mean $5,000-$50,000 of Pi Zero's, which is expensive and 1 more piece of depreciating capital to maintain.

A whitelist/blacklist configuration for the mc-Gateway that tells it what MQTT topics to actually send out to the internet would be a good feature. Though, full-fleged programming would be nice on the mc-Gateway.

The 21 byte packet is a system message and should be ignored, there is no data that can sent in this packet. It is used for internal synchronization if there are multiple gateways.

I do not need to send data in this packet. I am using the 21 byte packet in an automated system that discovers what devices I intend to deploy. Automation is much better than manual entry.

Also, here is no more space within the beacon to add this.

This is why I suggested to add "device type" to the next version of the beacon. There is a beacon version in the beacon, so this should be possible because beacon parsers will know how to act based on the version byte.

Innovations to mc-Studio will not be enough for our use case. Unless we can infer the device type of 5, 10, or 100 devices automatically through UDP, it will just be adding more complexity to deploy a multitude of devices simultaneously. Manual data entry and retrieval in mc-Studio is not solely what we want. Perhaps there can be an API release (perhaps over UDP, or whatever protocol mc-Studio uses) to garner this information through our own network applications.

mc-Studio is able to determine whether a device is the mcGate110, or a mcMod110/120. How is it doing this? Perhaps device type can be added to the next version of the beacon protocol, or the mc-Things team can share the UDP protocol that allows asking for this information.

I was using the 4 bytes of beacon data to store temperature and battery voltage information and have a suggestion to help clean up and simplify the beacon API for programming. These comments are based on revision 0.7 (August 2016) of the mc-Script user guide.

This is the current state of the beacon API:

Shared Sub SendBeacon(data As ListOfByte)
Shared Sub SetBeacon(time As Integer, data As ListOfByte)
Shared Sub SetBeaconData(data As ListOfByte)
Shared Sub SetBeaconTime(time As Integer)
Shared Sub BeaconNow()

For a programmer to send data in the beacon, one of the first three sub procedures must be used. SendBeacon could be used in conjunction with a timed Shared Event, but this may (sometimes) require using SetBeaconTime with 0 as the time argument. SetBeacon implies that the data is set only once, so sending data that changes over time (such as temperature) doesn't make much sense here. SetBeaconData works when SetBeaconTime is used (unless the default of 10 seconds is acceptable), but SetBeaconData would have to be wrapped in a timed Shared Event. In my mind, there are questions regarding if 1 timed Shared Event will consistently fire (and finish processing) before the beacon interval fires, leading to a case where 2 beacons have the same temperature data and a temperature reading is missed.

My proposal is that additional Lifecycle Events (hooks) are added to the language. I pseudo-randomly found a development environment (Android https://developer.android.com/reference/android/app/Application.html) that exhibits this paradigm. If a Lifecycle Event (Software Events or additional Hardware Events may be appropriate names as well) named BeforeBeaconBroadcast was added, a programmer could use SetBeaconData in that routine and avoid using any other parts of the beacon API (although they are still useful). Using this approach, there would be no question that the data was set correctly on the outgoing beacon.

AWS Re:Invent is this week, and one of the services they released was AWS Greengrass.

Is it possible to add this service to the mc-Gateway or (even better) the mc-Modules? If so, will the mc-Things team consider adding support for the service in the future?