meshtastic --set remote_hardware.available_pins does not work
I would like to turn off allowUndefinedPinAccess true
meshtastic --info
"remoteHardware": {
"enabled": true,
"allowUndefinedPinAccess": true,
"availablePins": []
},
So I'm trying to set pin 16 and hopefully 17 as being available, but starting with just 16 for now. https://meshtastic.org/docs/configuration/module/remote-hardware/#masks Trying to set pin 16
meshtastic --set remote_hardware.available_pins "0x10000"
Connected to radio
Aborting due to: non-hexadecimal number found in fromhex() arg at position 5
Using int gives me this error
meshtastic --set remote_hardware.available_pins "16"
Connected to radio
Adding '16' to the available_pins list
Aborting due to: does not support assignment
Trying these also does not work
meshtastic --set remote_hardware.available_pins "[16]"
Connected to radio
Adding '[16]' to the available_pins list
Aborting due to: does not support assignment
meshtastic --set remote_hardware.available_pins "{16}"
Connected to radio
Adding '{16}' to the available_pins list
Aborting due to: does not support assignment
meshtastic --set remote_hardware.available_pins "(16)"
Connected to radio
Adding '(16)' to the available_pins list
Aborting due to: does not support assignment
Trying to add it via a yaml file
Set remote_hardware.allow_undefined_pin_access to False Set remote_hardware.enabled to True Adding '[{"gpio_pin": 16, "name": "GPIO 16", "type": 2}, {"gpio_pin": 17, "name": "GPIO 17", "type": 2}]' to the available_pins list Aborting due to: does not support assignment
available_pins: [16, 17] Set remote_hardware.allow_undefined_pin_access to False Set remote_hardware.enabled to True Aborting due to: object of type 'int' has no len()
available_pins:
- gpio_pin: 16
name: "GPIO 16"
type: DIGITAL_WRITE
- gpio_pin: 17
name: "GPIO 17"
type: DIGITAL_WRITE
Aborting due to: 'dict' object has no attribute 'startswith'
@mikecarper were you able to get remote hardware to work even with remote_hardware.allow_undefined_pin_access set to True? I'm encountering apparent silent failures on stable (2.6.11).
It was never consistent; different g2s operated differently when given the same GPIO commands. So with the same hardware model the GPIO behavior was inconsistent