Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - millennial

Pages: [1] 2 3 ... 6
mc-Gateway / Re: Programming the mc-Gateway
« on: February 06, 2017, 10:50:41 am »
I think more than one gateway publishing beacons is a feature, not odd behavior. In their documentation, they mention using beacons for device triangulation. The MQTT broker would have to recognize that the data is the same, which could be difficult because there are so few user data bytes to play with.

What I would do if I had multiple gateways is tell the MQTT broker to accept data from a module only if it came through the correct gateway, which is possible to detect from the beacon data (or even the MQTT topic).

mc-Gateway / Re: Programming the mc-Gateway
« on: February 05, 2017, 02:00:11 pm »
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.

mc-Gateway / Re: Programming the mc-Gateway
« on: February 05, 2017, 01:58:21 pm »
I like that solution. Ultimately, yeah a solution shouldn't depend so heavily on Losant, so we would have a "proxy" where everything would go first when considering something at that scale. I still am rooting for mcThings to be the most robust IoT hardware solution out there, and more advanced gateway configuration/programming would be part of a robust solution.

mc-Gateway / Re: Programming the mc-Gateway
« on: February 03, 2017, 06:00:21 pm »
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.

mc-Gateway / Re: Programming the mc-Gateway
« on: February 03, 2017, 09:19:11 am »
If I could run a Python program on the mc-Gateway, I would gladly use  ;)

mc-Gateway / Re: 21 Byte UDP Beacon Packet?
« on: February 03, 2017, 09:16:08 am »
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.

mc-Gateway / Re: 21 Byte UDP Beacon Packet?
« on: February 03, 2017, 09:14:46 am »
The length of the beacon is 17 bytes (Described in the mcBeacon white paper) and that is the beacon that you want to pay attention to

Beacons start with : 0016010D

I understand all of this.

Are you saying there is no significance to anything in the "gatewayUID" field (I am using this name only because that is what the mc-Mod beacon uses) and aptly named "extraBytes" field of the following 21 byte mc-Gateway "pseudo-beacon?"

  "protocolVersion": 0,
  "messageType": 100,
  "messageVersion": 1,
  "messageSize": 17,
  "uid": 70556, (My mc-Gateway ID: "0x0001139c")
  "beaconBytes": 3232241325, (Found out to be my mc-Gateway LAN IP: "")
  "RSSI": 107,
  "gatewayUID": 107521, (Since a mc-Gateway does not have a gateway, what does this number - 0x0001a401 - signify?)
  "extraBytes": 2416444928 (These are the last 4 bytes - 0x90080600 - Not sure if they should be interpreted as individual bytes, shorts, or all together. Perhaps a interpretation makes more sense. Please clarify)

Please satisfy my curiosity for the gatewayUID and extraBytes field in this 21 byte "pseudo-beacon." Perhaps I may find an unseen use for that data.

mc-Product General / Re: Device Type data in Beacon Bytes?
« on: February 03, 2017, 08:58:21 am »
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-Gateway / Programming the mc-Gateway
« on: January 29, 2017, 04:39:19 pm »
I know it is not possible to program the mc-Gateway, but I have a couple of problems that could cheaply, elegantly, and easily be solved if we could program the mc-Gateway, even in an extremely limited manner. I say the problem could be solved cheaply and elegantly because an alternative solution to the following problems would be to host an MQTT server on a Raspberry Pi and bridge some of (and perhaps compute and re-package) the messages to Losant.

Losant has a payload limit, and other services may also have similar types of message limits. If we could tell the mc-Gateway not to send the beacon topics over MQTT, this would allow us to keep the beacon interval high (10 seconds) and avoid accruing payloads on Losant. A general whitelist/blacklist configuration for MQTT topics on the mc-Gateway could solve this problem.

Another problem, specific to Losant, is that if we use beacons for sensor readings (ideal for saving precious battery life) we need to use the Losant workflow to receive the MQTT event and then set device state based on a computation to retrieve the user data in the beacon bytes. The act of receiving MQTT in a workflow, and then using the workflow to set device state, both count towards the Losant payload limit. If we could define beacon user data mapping, perform simple calculations, and send results out on a renamed MQTT topic (in the case of Losant, a "set state" topic pattern), we could cut payloads in half on Losant. Yes, this problem can be solved by using MQTT directly on the modules, but this compromises battery life.

mc-Product General / Device Type data in Beacon Bytes?
« on: January 29, 2017, 04:23:49 pm »
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.

mc-Gateway / 21 Byte UDP Beacon Packet?
« on: January 29, 2017, 04:20:51 pm »
I set up a Node.js UDP server on my LAN and noticed a repetitious 21 byte packet is being sent by the mc-Gateway. Could the mc-Things team throw up a quick table documenting what the bytes mean? I know the User Data bytes are the Gateway's local IP address, but I am curious about the 8 bytes after the IP address.

mc-Studio / mc-Script Beacon API
« on: January 29, 2017, 04:15:20 pm »
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 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.

mc-Studio / Crash when loading script more than once
« on: December 29, 2016, 11:13:25 am »
Does anyone else have the following behavior? I get these results every time.

1. Open mc-Studio.
2. Open devices (Ctrl+D)
3. Connect to Gateway
4. Connect to Device
5. Build Application (F6)
6. Load and Save Program into device (F7)
7. "Code successfully loaded" -> OK
8. Go back to devices window and connect to another device (I can also disconnect and reconnect the gateway first, and the problem still occurs).
9. Build Application (F6) (Not sure if this is necessary, but if this step is omitted, the problem still occurs)
10. Load and Save Program into device (F7)
11. CRASH!!

My workaround is to change the flow to this:
1. Open mc-Studio.
2. Open devices (Ctrl+D)
3. Connect to Gateway
4. Connect to Device
5. Build Application (F6)
6. Load and Save Program into device (F7)
7. "Code successfully loaded" -> OK
8. Close mc-Studio.
9. Repeat

mc-Module / AWS Greengrass
« on: December 02, 2016, 12:35:25 pm »
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?

mc-Innovations / Re: Front Door Sensor via MQTT
« on: November 07, 2016, 09:14:19 am »
Cool. Where did you get your magnet?

Pages: [1] 2 3 ... 6