›

Using macros to change device name

EdwardsjEdwardsj
edited October 2016 in Android
Hi Eric,

I'm trying to explore the following use case. I configure the MetaWear C board and store a macro in the register. The macro is used to change the device name and play a specific LED pattern when the switch is pressed. My current implementation can be found here: https://gist.github.com/HongyiZhu/b8cdb07a88cf8dbd89ac866f277dfd4d

I'm currently using API v2.6.0. I faced few problems during development.

1. I've disabled the macro's run on boot feature. When I call macro.record(), it seemed like the recorded commands would be executed once even if I didn't call macro.execute(). Is this the right workflow of the Macro.record API?

2. I tried to update the device name field. I pressed the button and the LED worked correctly. I waited for 2 minutes for the new device name to show up but it didn't. However, after I connected and disconnected from the sensor, the name field was changed. Can changing the device name be triggered and completed without the second connection attempt?

3. I configured the sensor name back to the default "MetaWear" with the Android Sample app. However, I was not able to press the switch to change the name and play the LED pattern again. I have to restart my application and reconfigure the sensor in order to  get the macro work again. I didn't remove the macro nor the data route of the Switch module. What happened on the board that prevented the data monitoring?

Thank you!

Comments

  • EricEric
    1. Yes, the actual commands are executed once.  Run on boot refers to the board booting.
    2. What firmware version are you using?  A firmware update was pushed out a while ago that enables ad changes through an activity handler though.
    3. The settings panel uses the macro to make the device ad name permanent and clearing the change also clears the macros
  • EdwardsjEdwardsj
    @Eric,

    Thank you!

    I'm using firmware 1.1.3. Does firmware 1.2.1 support the feature you described? If not, I'll try and test on firmware 1.2.4.

    I'm confused by the third point. Does it mean that by calling Settings.configure().xxxxxx().xxxx().commit() or Setting.setXXXXX().setYYYY().commit(), an eraseMacro() command will be executed? Will the data route I established via macro be destroied in that case?
  • EricEric
    Sorry, I was mistaken.  The update I am thinking about lets you change the iBeacon ad settings with an activity handler.  I'll have to ask the firmware dev regarding ble ad settings.

    See the fragment's source code.
  • EdwardsjEdwardsj
    @Eric,

    Yes, I've already implemented that in the gist code block. My questions will be:

    1. Is it possible for a switch activity handler to call the macro multiple times as configured in the data route?

    2. Is the macro which configures the BLE broadcasting parameters executed after a connect/disconnect event or executed whenever the macro is executed (w/o the phone connecting to the sensors)?

    Yeah, I do believe the firmware dev has better idea of the question. Thank you all!
  • EdwardsjEdwardsj
    @Eric,

    So, for 2, the question is that when will the following command take effect?

    setting.configure().setDeviceName("XXX").commit();

    Is it on disconnect? Or is it immediate? We discovered that when we execute the macro w/o phone connecting to the sensor, there won't be any changes. But soon after the phone connected/disconnected from the sensor, the sensor name was changed.

    Thank you!
  • EricEric
    1. Yes
    2. Activity monitor is executed when its data source is active i.e. produces new data.  The reason you don't immediately see the change is the ad parameters are not refreshed until a disconnect where it then restarts the advertising.
    Since you are looking for some context specific ad parameters, you should look into using iBeacon mode instead as you can change the major/minor numbers on the fly with an activity handler.
  • EdwardsjEdwardsj
    @Eric,

    Thank you! I'll definitely look into iBeacon mode.

    Can you provide some power consumption information of the iBeacon mode? Since it's working over BLE module, does it consume more power compared with the normal BLE broadcasting signals? Or can you provide the BLE module spec? I can look the information up in the spec if provided.
  • EricEric
    iBeacon simply uses the BTLE advertising feature to broadcast its own advertising packets in place of the standard btle ad packets.  There is no difference in power consumption.
  • EdwardsjEdwardsj
    @Eric,

    I have a question about the iBeacon function. When I enable the iBeacon module, does it only adds payloads to the BTLE packet or it broadcasts additional packet? If it only adds to the BTLE broadcast, which parameters control the broadcasting, the ones in the Settings class or the ones in the iBeacon class?

  • EdwardsjEdwardsj
    @Eric,

    We defined a macro triggered by pressing the switch, however, it sometimes ends up setting the board in MetaBoot mode. You mentioned in other threads that pressing the switch for a few seconds triggers the MetaBoot macro. Can you specify the time threshold (in milliseconds)? Is there a way for us to overwrite that macro? 
  • EricEric
    If you are using iBeacon advertising, then use the iBeacon class to configure the ad parameters.

    No, what was stated is that pressing the switch when the board powers on will switch the board into MetaBoot mode.  Using the button once the board is running the normal firmware should not trigger MetaBoot mode so this is quite unexpected.  What is the code you are running that is exhibiting this behavior?
  • EdwardsjEdwardsj
    @Eric,

    That explains a lot. I realized that I pressed the switch on booting up in those cases.
This discussion has been closed.