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.05k stars 4.78k forks source link

More than 4 switches/buttons? #817

Closed lobradov closed 7 years ago

lobradov commented 7 years ago

Hi,

I'm using Sonoff-Tasmota on Wemos D1 mini and would like to have more than 4 buttons connected to it. I see that number of buttons/switches is locked to 4, and I also see that this number is hardcoded in the sonoff.ino logic (lastbutton[], holdbutton[] or bunch of functions like sensors_mqttPresent() and switch_handler()).

What would be a proper way of increasing number of buttons to, say 8?

I would normally just increase upins_t and sensors, and replace all for loops to check for 8 buttons, but wonder what would happen during OTA, if there's some settings using previous upins layout.

Any ideas or suggestions?

davidelang commented 7 years ago

There are people who have posted patches to add more buttons or relays to tasmota. Unfortunantly this is far too expensive to be part of the general system right now, but it is something that comes up frequently.

lobradov commented 7 years ago

Can you point me to patches that enable this? Also, what do you mean - expensive?

gheesung commented 7 years ago

I am trying to do that too but realised that Tasmota is already doing a lot work on the ESP8266. Polling more pins will slow the MCU further. I am thinking of an alternative whereby there is another module type e.g WEMOS D1 Mini Bridge. All the MQTT messages will be forwarded to the soft serial defined at the module configurations. The receiving MCU (e.g Nano, pro mini etc) can process the message and act on it and then return the status to Tasmota to be sent to MQTT.

Essential Tasmota has become a MQTT shield for non-wifi enable MCUs.

davidelang commented 7 years ago

The issue is the way that tasmota handles the different GPIOs and the potential values for each. Every possible button/switch/led/relay/inverted LED, inverted relay, etc needs an enumerated type. They all get listed in the pulldown.

Making this larger has a measureable impact on the availble RAM on these devices to be able to do other things.

To be able to support this well, the fundamental approach that tasmota uses to define these things would have to change. Instead of every possible value being enumerated statically, you ould need an approach where the info for each type of thing lives in ROM, and when you want to have something happen, the firmware creates a new instance of that type and attaches it to the GPIO instead of having to have an array of all possible uses for each type.