Plain ARROW symbols on buttons that command shutters

[localhost61]

Description:

It's a change I wanted for myself for a long time and the recent arise of the shutter driver gives me that opportunity to do it.

This code change makes a difference between Up and Down buttons in the case of a shutter. Labels of buttons of other relays are not affected.

Here is the result:
First screenshot shows a Dual R2 defined as shutter, second picture shows what happens on a Sonoff CH4 when only 2 first relays form a shutter and last one the same device with 2 shutters.

• The code change is reduiced thanks to the fact that UP relay is hard-coded as the First one in the xdrv_27_Shutter.ino driver, and DOWN relay as the second.
• The arrow symbols have the advantage to require no i18n (no code increase) and fit in even tiny buttons. As a UTF8 character it should be readable on every modern browser. Isn't it?
• The code size cost is +16 bytes compared to previous commit v7.1.2.4 (3d2e77f) compiled with -DUSE_SHUTTER (585,328 bytes).
• The change doesn't apply to tasmota.bin because the Shutter driver is not supported by default.

I join the tasmota binary here for the one who want to test because one need to uncomment #define USE_SHUTTER in my_user_config.h to allow shutter support.
-> PR_v7124.zip

Checklist:

• [✓] The pull request is done against the latest dev branch
• [✓] Only relevant files were touched
• [✓] Only one feature/fix was added per PR.
• [✓] The code change is tested and works on core 2.6.1
• [✓] The code change pass travis tests. Your PR cannot be merged unless tests pass
• [✓] I accept the CLA.

[arendst]

Thx.

I see a flaw when there are six relays. First pair and last pair being used for shutter would result in wrong label on relay 3 and 4.

Based on you idea I'll make a satisfying update. Stay tuned.

[localhost61]

I have read in the doc that shutters relays have to be tight together...
Did I misunderstood?
Can you issue shutterrelay3 5 without a preceding shutterrelay2 3 ?

To enable additional shutters, ShutterRelay must be executed for each additional shutter. Additional shutter declarations must be sequentially numbered, and without gaps (i.e., first shutter 2, then shutter 3, and finally shutter 4).

-- edit --
Obviously you're right :-)
I could indeed assign a shutter to relays 3&4 of a CH4 with no shutter on relays 1&2 and... as you said, my changes become inconsistent the arrows are applied on the wrong relays.

[tobox]

Maybe a more general approach to name the individual buttons would be better. My neighbor uses the Tasmota WebUI to control the garden sprinklers, and for him it would be very helpful if the names on the buttons could be changed individually. With that functionality, _ARROWUP/_ARROWDOWN or similar could then be translated to the mentioned icons from the original post.

[arendst]

Individual naming would mean for every button there needs to be space allocated in the Settings area for a text of unknown size. Currently a no-go as the Settings area ia almost full.

[tobox]

Are there any plans for the near future to increase the size of the settings area? I

I thought about setting the names via MQTT or just hard coding them, but having them stored in the settings would just be the much cleaner solution.

[localhost61]

Oops, sorry Theo for the //// lh61 tag and other cosmetic typos in my commit (I use this to locate my changes locally to have a control over git mergers). I made a corrective commit later in the night and thought it had been executed but it seems like I messed up here.

[arendst]

Settings area is 4k already. This means 4k of RAM is used for settings.

I'm currently polling on Discord the use ratio of char arrays within the Settings area to decide if it makes sense to change the current static char array sizes to one static char array to be used for all current text strings. New code would then extract and update part of the single char array.

Initial results to show that over 60% of total char arrays is not used which openes up new possibilities like longer MQTT usernames and passwords ;-) or even naming single buttons....

[arendst]

Merged in some way ;-)

[tobox]

Individual naming would mean for every button there needs to be space allocated in the Settings area for a text of unknown size. Currently a no-go as the Settings area ia almost full.

How about reusing the "Friendly Name" Strings from the "Configure Other" section? I never understood what they were used for, but only realized that there is one for each relay and changing the name did not yield any (expected) results.

For backwards compatibility there could be a bit in the settings for "use old friendly name behaviour" (default) or "use friendly names for relays/outputs/etc" (needs to be set manually).

[arendst]

The friendlynames are very important for Alexa users.

I'm gathering statistics about char array usage and the results are very promissing. It seems we have a usage ratio of around 40%. By concatening all strings into one char array and adding code to handle inserts, deletes and replace ther is plenty of space to add new text functionality.

Watch for changes to coma about one of these weeks. It's weeks because I have to make sure conversion to one char array is seamless for users.

[localhost61]

The UTF-8 arrows I used take 3 chars each. But I guess it's the same for Chinese or Arabic chars.
I wonder how you will deal with fragmentation an flash limited lifeduration