Preparation to remove HARDLIMIT of 4 relays

[stefanbode]

Hi @arendst, could you please replace the different "0xFF" in the code with a constant defined and if possible the "byte" that is used in many places with an own type. e.g. relayarray =byte.

This would make it easier for my mod with 32 relays to keep code in sync because I only had to change the definition and not many lines of code. I assume the first change will also save you some bytes again.

For example, line 2422 in sonoff.ino is currently:
byte mask = 0xFF;

would be great if this could be something like:
relayarray mask = max_value;

[ionciubotaru]

It will be nice to implement at least 8 relays into main release, even not all of them are visible in the web interface

[stefanbode]

My fork of this great project adds support for the pcf8574. This allows up to 32 relays with 4 of these modules. Currently, my fork only supports WRITE. the module can also be used to get DIO input. I haven't tried and tested this so far. I have 16 relay version running in my garden for irrigation. Because of the way the module is working there are some nasty side effects, if you work with pulsetimers and change other relays until the first one is finished. Anyhow switching on and off is working fine. Open it up to 8 relays should not be a big issue because the byte has enough space to do and the 0xFF too. My version uses a uint32_t having enough space to store configuration.

[OTrumpf]

I really like to support ionciubotaru's request for 8 relays. I tried to extend this awesome package to 8 relays, but ist is not fully working and the update speed of arendst ist too high for me...

[stefanbode]

@OTrumpf. I updated my version yesterday to support 8 relays without add-on hardware. I agree that this was quite tricky and @arendst implemented some nasty stuff like &3 that drives me crazy until I found it. Anyhow, I assume that fork should work. I checked several scenarios and did not found an error right now.
https://github.com/stefanbode/Sonoff-Tasmota/tree/master/sonoff

[arendst]

Working on it....

[arendst]

Ah, thnx for alerting about the &3 ! ;;--))

[stefanbode]

@arendst If you want to get to know what you have to change AT LEAST to get it working take a look at my fork. There were some side-effects. I suggest to replace the 0xFF or so on with an XOR on 0x0. In this case independent of the definition of the length of the variable it should work. I do not know if a -1 also works by creating a defined overflow on an unsigned variable.

[arendst]

Yes. I'm looking at it. I will first release the good old 4 relay version but with updated power size and other tricks to start using more relays in the near future.

[stefanbode]

Hi @arendst , I just saw that the ESPeasy sorted the GPIO mapping just the other way around. Here we have the GPIO as a start and in the list is a longer and longer list to select what the GPIO is doing. If we do it the other way around we easily can add flexibility on enumerated items because they don’t need to be in the Dropdown list. This is for sure a real major change, but smart if we want to support more an more functionality. Just take a sleep and think about it.

[davidelang]

On Tue, 10 Oct 2017, stefanbode wrote: Hi @arendst , I just saw that the ESPeasy sorted the GPIO mapping just the other way around. Here we have the GPIO as a start and in the list is a longer and longer list to select what the GPIO is doing. If we do it the other way around we easily can add flexibility on enumerated items because they don’t need to be in the Dropdown list. This is for sure a real major change, but smart if we want to support more an more functionality. Just take a sleep and think about it.

It's not quite that easy, because not all switches are interchangable, and you really don't want a switch or relay to change what it's doing because someone changed what another GPIO does so you can't just have a bunch of switches and assume they are in some order. currently Tasmota does a 1:1 mapping of GPIO to one of many functions. I think the 'best' way would be to abstract this. have 'thing templates' (switch, button, relay, LED, etc) that you can instantiate. When you instantiate a 'thing', you define what GPIO(s) are associated with it, and what 'thing number' it is. part of the 'thing template' defines if the GPIO is input/output/other. If other, what type of other (serial I2C, etc). Other types get assigned to a module, and you can only have one instance of each type of other (to keep things sane) if GPIOs are inputs, they are added to an input array, this is used to know what to look for and what to do with it when found. if GPIOs are outputs, they are marked as 'no longer available' and the module for that type of output deals with it. But this is a major re-write of much of the tasmota internals, and not likely to take place until this set of code is thrown away and re-written

[arendst]

So how about this using the latest pre-release?

[ionciubotaru]

The interface looks great

[stefanbode]

Really like and already decustomize my fork. Yeah! Great move forward. Also the other improvements in the GUI, like the module definition.

[arendst]

Implemented in master release v5.9.0