Optional data: PartialMessage<HardwareMessage>What gpios are we changing. Not used for all MessageTypes, see MessageType for details
from field: uint64 gpio_mask = 2;
For gpios that were listed in gpio_mask as valid, what are the signal levels for those gpios. Not used for all MessageTypes, see MessageType for details
from field: uint64 gpio_value = 3;
What type of HardwareMessage is this?
from field: meshtastic.HardwareMessage.Type type = 1;
Static Readonly fieldsStatic Readonly runtimeStatic Readonly typeCreate a deep copy.
Compare with a message of the same type. Note that this function disregards extensions and unknown fields.
Parse from binary data, merging fields.
Repeated fields are appended. Map entries are added, overwriting existing keys.
If a message field is already present, it will be merged with the new data.
Optional options: Partial<BinaryReadOptions>Retrieve the MessageType of this message - a singleton that represents the protobuf message declaration and provides metadata for reflection- based operations.
Protected toJSONOverride for serialization behavior. This will be invoked when calling JSON.stringify on this message (i.e. JSON.stringify(msg)).
Note that this will not serialize google.protobuf.Any with a packed message because the protobuf JSON format specifies that it needs to be unpacked, and this is only possible with a type registry to look up the message type. As a result, attempting to serialize a message with this type will throw an Error.
This method is protected because you should not need to invoke it directly -- instead use JSON.stringify or toJsonString for stringified JSON. Alternatively, if actual JSON is desired, you should use toJson.
Static equalsStatic fromOptional options: Partial<BinaryReadOptions>Static fromOptional options: Partial<JsonReadOptions>Static fromOptional options: Partial<JsonReadOptions>Generated using TypeDoc
An example app to show off the module system. This message is used for REMOTE_HARDWARE_APP PortNums. Also provides easy remote access to any GPIO. In the future other remote hardware operations can be added based on user interest (i.e. serial output, spi/i2c input/output). FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the channel mechanism). It should be off by default and then protected based on some TBD mechanism (a special channel once multichannel support is included?)
Generated
from message meshtastic.HardwareMessage