search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.2k stars 4.81k forks source link

Berry: gpio.pin() does not work for OPTION_A #19235

Closed hami89 closed 1 year ago

hami89 commented 1 year ago

PROBLEM DESCRIPTION

In berry script, the gpio.pin_used(gpio.OPTION_A,0) command always returns -1, even if such a gpio pin is configured. Meanwhile, gpio.pin_used(gpio.OPTION_A, 0) correctly returns true.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

- [ ] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:
```lua
N/A

TO REPRODUCE

Take an esp32 based device and configure a gpio pin as "Option A". From the berry console, issue command gpio.pin(gpio.OPTION_A,0). It will return -1.

EXPECTED BEHAVIOUR

The gpio.pin(gpio.OPTION_A,0) should return the configured gpio number (22 in this case) for the Option A pin.

SCREENSHOTS

N/A

ADDITIONAL CONTEXT

I am developing a custom device. I configured gpio 19, 21, 22, 23 respectively as Option-A 1, Option-A 2, Option-A 3 and Option-A 4.

I am using a berry-script based driver to handle these pins. In berry, gpio.pin_used(gpio.OPTION_A, 0) works as expected, returning true for all 4 pins (0-3)"

Berry console output:

| gpio.pin_used(gpio.OPTION_A,0)
true
| gpio.pin_used(gpio.OPTION_A,1)
true
| gpio.pin_used(gpio.OPTION_A,2)
true
| gpio.pin_used(gpio.OPTION_A,3)
true

But gpio.pin(gpio.OPTION_A, 0) returns 0, no matter the input. (But it works correctly for all other devices in my config).

Berry console output:

| gpio.pin(gpio.OPTION_A,0)
-1
| gpio.pin(gpio.OPTION_A,1)
-1
| gpio.pin(gpio.OPTION_A,2)
-1
| gpio.pin(gpio.OPTION_A,3)
-1

I would expect gpio.pin(gpio.OPTION_A, 0) to return 22 (GPIO 22), as gpio 255 command output above shows, that it is configured to gpio 22.

I would use gpio.pin() output to find the gpio assignment from the berry driver. I worked it around by issuing a tasmota.cmd("gpio 255") command from berry and processing the output, but it would be much easier to get the result in one code line.

sfromis commented 1 year ago

Well, OPTION_A are not "physical pins", but a workaround for providing a runtime configurable option for drivers to modify their behavior, without the driver expecting that they can get a physical pin number for an option. Only whether the option is selected. Thus it makes sense that gpio.pin_used gives you what OPTION_A is meant for, while you cannot misuse gpio.pin to treat it as a physical pin assignment. The pins where OPTION_A is selected are not assigned to anything, they are still unused, with or without Berry. Thus it is working as designed that gpio.pin returns -1 for not assigned.

To reserve pins for Berry usage. you can configure as INPUT instead of expecting OPTION_A to be suitable for such.

s-hadinger commented 1 year ago

This is due to the internal implementation of Tasmota. OPTION_A is a virtual type and is not actually attached to a GPIO. So returning the GPIO number for OPTION_A actually doesn't make much sense.

There is special code in gpio.pin_used() to detect OPTION_A although there is no GPIO attached.

hami89 commented 1 year ago

Well, I see your logic and I can accept that.

Still, if a pin can be set as Option A (or anything else) it would be logical to be able to query the same thing. Option A is not highlighted as "Virtual" like Option E. Regarding the @s-hadinger 's logic, I would expect the exact opposite behavior. Pin_used() should return false, as the pin is "not used" by any other driver, but still, pin() call should provide the assignment.

Please, at least update the documentation about this.

Anyway, thanks for the quick reply, I'll close this.

s-hadinger commented 1 year ago

This is a convenience and the corresponding PR is here: https://github.com/arendst/Tasmota/pull/13625

You can ignore it if you find it inconsistent. There is no pin assignment internally in Tasmota, so I can't retrieve the GPIO it was initially assigned to. And as said, the GPIO it is assigned to has no meaning.

Btw, I don't know any other way to get OPTION_A information from Berry.

sfromis commented 1 year ago

If what you want is to "reserve" a pin for Berry, and have the Berry code find it without having to know the physical pin gpio number, you can as already suggested configure the pin as "Input" instead of trying to misuse Option A.

hami89 commented 1 year ago

As I mentioned, it can be worked around by either decoding the template or by var pins = tasmota.cmd("gpio 255") and using the resulting berry object. I closed the issue anyway.

sfromis commented 1 year ago

What I meant was just do not misuse the Option A feature for something it is not meant for, especially when you have a more suitable option.