RFP - Battery Message

[qdot]

Name of Outgoing Message, if any: BatteryLevelCmd

Name of Incoming Message, if any: BatteryLevelReading (?)

Message Fields

• BatteryLevelCmd
  • None
• BatteryLevelReading
  • Reading: Number, 0.0 (empty) - 1.0 (full)

Describe message usage scenario Mostly useful for Bluetooth devices, since BLE devices usually have battery level output

Additional context Not sure about the incoming message name here. I'd like to standardize on something like input like we have "Cmd" for output, but I'm not sure what. Choices so far:

• Reading (This might work since this will usually pertain to sensors but doesn't really imply request/response)
• Response (Feels a little weird for times where we've subscribed to an endpoint and will get data back without requesting it every time)
• Input (Hard to tell what direction it is)
• Data (Possibly too arbitrary)

BatteryLevel is used versus just Battery, as we might later be able to have something like BatteryTime.

[qdot]

This relates to buttplugio/buttplug-csharp#14. No relevant buttplug-js bug yet.

[qdot]

@blackspherefollower Any thoughts on if BatteryLevelReading (and RSSILevelReading and RawReading) include the device index they're coming from? It seems extraneous, since that was sent in the request and we'll always match the message back either by ID or stack return resolution. But when we start implementing subscriptions for updates, we'll have to pack device indexes with those since there won't be a matching request.

[blackspherefollower]

Seems like always including the device index sets up a good pattern for subscriptions, so I think it might be worth it.

[qdot]

Implemented in v2