Feature request: Power ALL

[kueblc]

Have you look for this feature in other issues and in the wiki?

Yes. Others have had this issue, no satisfactory solution was found.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

On devices with more than one relay, power is identical to power1. There is no single command to toggle or set power states simultaneously. This results in a few issues.

1. Sending power command to a group topic affects only the first relay.
2. Using the button on a multi relay power strip only toggles the first outlet.
3. Multiple commands are required to change multiple relays, which adds delay and complexity.

These also reference the issue(s)
#1055 (comment)
#1537 (comment)
#2475 (comment)
#3343 (comment)
#4585
#4625

Describe the solution you'd like
A clear and concise description of what you want to happen.

1. Ideally, power should impact all relays.
2. For backwards compatibility, this could be implemented as an option.

I would be happy to work on a PR given the go ahead.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Less than ideal, implement a separate command powerall. This would still require multiple commands when issuing to group topics if other single power devices respond to power.

Less than ideal, use existing backlog feature. This adds noticeable delay, which in some use cases may not be acceptable. It also does not address the failures with group topic or physical button, without additional complexity in configuration.

Additional context
Add any other context or screenshots about the feature request here.

(Please, remember to close the issue when the problem has been addressed)

[meingraham]

I'm not opposed, per se, just posing some questions for consideration.

Would latching all the relays "simultaneously" cause a power spike in the electronics circuitry? Would one know if it did on every device where one might have the option to use PowerAll (if made available)?

Other than ease of use (i.e., needing to invoke a longer Backlog command), why is Backlog delay between commands an issue?

What are the use cases that require that all relays be powered simultaneously?

Mike

[Jason2866]

Nice idea. But using command power for this shouldnt be used.
Imho power is the most used command. Even not with a SetOption.
It changes behaviour because power or power1 can be used already now with a SetOption

[ascillato]

Hi,

For backwards compatibility and simplicity, power and powerX commands should stay as they are.

IMHO adding another command like powerall is like adding more options to do the same. You have already the backlog command to power ON/OFF the exact relays you want.

If you want a new command like powerall you can already do it using EVENT in a rule like:

rule1 1
rule1 on EVENT#POWERALL do backlog power1 %value%; power2 %value% endon

and then you call it using the command EVENT POWERALL=ON

[kueblc]

Hi Mike, thanks for your feedback.

Would latching all the relays "simultaneously" cause a power spike in the electronics circuitry?

Not necessarily, as mentioned in #3343 (comment) this is the default behavior of the stock firmware.

Would one know if it did on every device where one might have the option to use PowerAll (if made available)?

Could you clarify this comment?

Other than ease of use (i.e., needing to invoke a longer Backlog command), why is Backlog delay between commands an issue?

I believe it's better to have the option. It may be a matter of personal preference. Quicker reaction, aesthetic appeal, etc. Some may find the delay bothersome if they just want to turn everything off.

What are the use cases that require that all relays be powered simultaneously?

I can't think of specific use cases beyond wanting to control all sockets simultaneously. Say I get home and want to turn on my lights. It may just be preference that I would not want to wait for them to tick on one at a time. Same with going to bed and turning them off. It's not significant sure, but it's awkward, and when stock firmware allows this I think custom firmware should not add restrictions but remove them.

[kueblc]

Hi Jason, thanks for the comment

Nice idea. But using command power for this shouldnt be used.
Imho power is the most used command. Even not with a SetOption.
It changes behaviour because power or power1 can be used already now with a SetOption

Could you explain how others might be affected if an option is added? What I'm proposing shouldn't change the operation for anyone who does not enable said option.

[ascillato]

I can't think of specific use cases beyond wanting to control all sockets simultaneously.

You can try the event with rules proposed to test if you can "see" the delay between relays

[kueblc]

Hi Adrian, I appreciate the input

For backwards compatibility and simplicity, power and powerX commands should stay as they are.

My comment to Jason here is the same, what could happen to impact backwards compatibility if the option is implemented as default off?

IMHO adding another command like powerall is like adding more options to do the same. You have already the backlog command to power ON/OFF the exact relays you want.

If you want a new command like powerall you can already do it using EVENT in a rule like:

rule1 1
rule1 on EVENT#POWERALL do backlog power1 %value%; power2 %value% endon

and then you call it using the command EVENT POWERALL ON

Noted by the number of individuals experiencing issues related to this, I don't think it's obvious enough to implement this via a rule. This added configuration step is clearly eluding people and creates confusion as this might be something one would expect out of the box.

Also note that this does not address the ability to address a group of devices with power command to the group topic.

For consistency, I would like, and I believe I'm not alone here, to be able to use all the features of power ie on off and toggle with all of my devices and have the same result across the board.

[kueblc]

I can't think of specific use cases beyond wanting to control all sockets simultaneously.

You can try the event with rules proposed to test if you can "see" the delay between relays

Please note that my inability to produce multiple use cases does not imply there aren't more use cases. I believe the core issue is consistency. I feel that this is something many would expect out of the box, even if there are workarounds via rules, it adds unnecessary configuration complexity.

[ascillato]

I understand that adding the rule is another configuration step, but also it adds the flexibility to group the relays you want for any specific use case, like having 4 relays and wanting to use ON, OFF, TOGGLE with the first 2. The rule proposed accepts ON, OFF, TOGGLE, BLINK, 0, 1, 2, 3 as inputs due it uses the %value% variable. And it already works without needing to modify anything in the code ;)

[Jason2866]

Yes, you are right. Backwards compatibility could be statisfied with a new SetOption to change
behaviour from power of old use switching relay1 to switch all relays.
So as always it is @arendst decision.
For my usage it is useless because i see every relais as single device in my Home Automation system and do group functions with the Home Automation system...

[kueblc]

I would also propose one might not want to "waste" one of their rules on this, and leave that space for implementing more interesting interactions.

My intuition tells me this would be relatively straightforward to implement and would benefit users in the long run.

The rule also does not address the consistency issue with group topics.

[ascillato]

I was asking you to test the rule, because I'm already using that one for several lights and I really don't see the delay between them.

The group topics works fine with EVENT and rules:

[kueblc]

Thank you for the suggestion, I have tested it, yes there is a perceivable delay. However I feel this is missing the point, wherein my main concern is that the operation is inconsistent and that a lay user would not know to implement a rule to enable this (relatively basic) functionality. This is demonstrated in the collection of issues I've assembled in the first post.

[ascillato]

@kueblc

I agree with you that in a multi relay device, power and power1 commands are the same, leaving free the command power to include a powerall feature.

If I would be just starting with Tasmota without reading the wiki, may be I would be thinking that power was for all relays and power1, power2, ... powerN were for any independent relay. I understand your point. I was just pointing out an already working solution for powerall.

The already SetOption26 to use or not the suffix for POWER on 1 relay devices, may be, could be used also as SetOption26 2 to allow POWER to be a POWERALL command.

Anyway, it is up to @arendst deciding on that.

Thanks for sharing your ideas 👍

[kueblc]

If I would be just starting with Tasmota without reading the wiki, may be I would be thinking that power was for all relays and power1, power2, ... powerN were for any independent relay.

As someone who has read the wiki, used Tasmota in production for some time, and gone through the code, it still wasn't immediately obvious that a rule would be needed for this. In any case I do believe, as a general rule, that we can (and should!) do more to better the user experience and lessen the barrier to entry.

I was just pointing out an already working solution for powerall.

Thanks for that, however I believe I sufficiently addressed in the first post that using backlog to accomplish this still has drawbacks.

The already SetOption26 to use or not the suffix for POWER on 1 relay devices, may be, could be used also as SetOption26 2 to allow POWER to be a POWERALL command.

That's a great idea, may be implemented with even less changes than I had considered.

Thanks for sharing your ideas +1

And thank you for the feedback! I genuinely appreciate the input.

[arendst]

Use rules as documented above.

If functionality can be made by either rules or user templates it simply opens more possibilities that need coding.

[kueblc]

Hi Theo, thanks for chiming in.

As documented above, rules do not address the issues presented. I can respect the idea of offering flexible functionality through generalized paradigms like rules and template, however it is not possible to accomplish precise timing through backlog and the issues of barrier to entry and consistency persists.

I am planning to implement this myself for my own use, but I'm sure others in the community could benefit from this as well. I would be happy to make a PR if you'd like to evaluate it's impact to see if it's something you would like to incorporate.

[andrethomas]

I like the sound of 20 relays turning on and off in sequence when I enter my lab to power up and power it down before leaving...

[kueblc]

Hi Andre,

I'm sure you and others do! The proposed change would not impact your ability to do this. It would create the option to choose otherwise if one elected.

Thanks for your input.

[meingraham]

My thoughts are with respect to electrical safety. My concern is that, say, the Sonoff 4Ch (I'm just using the 4Ch as an example. I have no idea what it may or may not be capable of) may not "tolerate" all relays being latched on simultaneously. The device you are referring to has a simultaneous POWER actions in the factory firmware. So, what is suitable on that device (the powerstrip you are referring to), may not be the same for others; even other powerstrips. Also, on the AC mains sides of things, turning on all loads (if they have a load plugged in on every socket) could surge the breaker. Also, for all we know, perhaps even the stock firmware has a delay. Granted, it may be imperceptible (i.e., smaller delay that Backlog), but they may be accounting for that.

The rule Adrian proposes (on EVENT#POWERALL do backlog power1 %value%; power2 %value% endon) only uses 65 out of the 1533 bytes (4%) available for rules. There is plenty of space left for other rules.

I agree that the user experience should be as good as possible w/in the constraints. However, if a user has gotten to the point where they have been able to replace the firmware on the device (even OTA methods require some degree of setup skills), they very likely can configure a rule and not consider it burdensome.

Mike

My feature request for these power strips would be to devise a means to use the single button on the powerstrip to be able to turn on or off a particular outlet: e.g., one press for plug 1, double press for #2, triple press for #3, etc. Or press for 1 second for #1, 2 seconds for #2, etc. That would be adding capability that either is not possible now or is truly complex to implement with rules or options. Turning them all on or off, that's a simple one ;-)

[kueblc]

My thoughts are with respect to electrical safety. My concern is that, say, the Sonoff 4Ch (I'm just using the 4Ch as an example. I have no idea what it may or may not be capable of) may not "tolerate" all relays being latched on simultaneously. The device you are referring to has a simultaneous POWER actions in the factory firmware. So, what is suitable on that device (the powerstrip you are referring to), may not be the same for others; even other powerstrips. Also, on the AC mains sides of things, turning on all loads (if they have a load plugged in on every socket) could surge the breaker. Also, for all we know, perhaps even the stock firmware has a delay. Granted, it may be imperceptible (i.e., smaller delay that Backlog), but they may be accounting for that.

I agree that there exists potential for electrical safety issues, however I don't believe that it's unique to this use case or substantial enough to warrant firmware restrictions. You could accomplish the same surge using a "dumb" power strip simply hitting the toggle with loads on all outlets. I maintain that custom firmware should present more options, not less, than the alternatives.

The rule Adrian proposes (on EVENT#POWERALL do backlog power1 %value%; power2 %value% endon) only uses 65 out of the 1533 bytes (4%) available for rules. There is plenty of space left for other rules.

I agree that this memory usage isn't substantial (although the command would be more than 65 bytes if it addressed every relay, not just the first two). The primary issues are the delay, and requiring a separate mode of command from the other devices in my group topic.

I agree that the user experience should be as good as possible w/in the constraints. However, if a user has gotten to the point where they have been able to replace the firmware on the device (even OTA methods require some degree of setup skills), they very likely can configure a rule and not consider it burdensome.

To lower the barrier to entry, all barriers must be lowered, in this way you are correct that the user having gotten this far today would be more likely to find the alternative suggestions presented. In planning for the future, one must lower one barrier at a time, so while OTA flashing is not as straightforward as it could be today, tomorrow it may. I suppose an implicit end goal is that all barriers are lowered such that cloudless IOT can become the norm and not a fringe community.

My feature request for these power strips would be to devise a means to use the single button on the powerstrip to be able to turn on or off a particular outlet: e.g., one press for plug 1, double press for #2, triple press for #3, etc. Or press for 1 second for #1, 2 seconds for #2, etc. That would be adding capability that either is not possible now or is truly complex to implement with rules or options. Turning them all on or off, that's a simple one ;-)

Interesting idea, however a very different request.

Thanks again for your input Mike, I hope I've addressed your concerns. Please don't hesitate to raise any further concerns or requests for clarification. 😄

[meingraham]

OK, 113 bytes to turn on the five circuits (7%). Still not worth worrying about.

You could accomplish the same surge using a "dumb" power strip

If it's a decent dumb power strip it will have some built in circuitry to avoid a surge.

an implicit end goal is that all barriers are lowered such that cloudless IOT can become the norm and not a fringe community

It would mean that manufacturers would have to buy in to this... and all indications are that they are fighting tooth and nail to do the very opposite. They want to draw you to their proprietary cloud and don't want to give users options. Shelly being the one refreshing exception.

My feature - yup a different request... which ist's why it was a P.S. ;-)

So, since this is more a philosophical debate... my vote falls on the side of using a rule... or roll one's own. I don't think the barrier of pumping in a simple rule is high enough to justify the additional program memory use. Or, the barrier would not be lowered sufficiently to warrant it.

Mike

P.S. I reserve the right to change my mind at a later date when I stumble on a must have use case that requires powering up an entire project simultaneously without lag ;-)

[kueblc]

OK, 113 bytes to turn on the five circuits (7%). Still not worth worrying about.

Yup, I'm not worried about that 😄 If it addressed my other issues I would be happy to do it this way.

If it's a decent dumb power strip it will have some built in circuitry to avoid a surge.

True, so wouldn't a decent smart power strip? Especially one where the stock firmware allows this usage. I'm not proposing we make this the default, just an option.

It would mean that manufacturers would have to buy in to this...

Not necessarily, we have the means to do aftermarket modifications, and we do!

So, since this is more a philosophical debate...

I'm not sure it is. I feel like it's relatively basic functionality that many (as demonstrated in the collected issues) would expect out of the box.

I don't think the barrier of pumping in a simple rule is high enough to justify the additional program memory use

It will very easy to evaluate the additional program memory use when I implement the change in my fork. I doubt that it will be significant by any means.

Again, I appreciate the input. I do think that it's been illustrated thoroughly enough that preferences regarding this matter are very opinion based. I see it as a virtue to accommodate different preferences, however I understand if the maintainers of this project do not prioritize this. In any case, I will make the fork available to those that share this preference and leave it open to the maintainers to decide whether or not to incorporate this.

[meingraham]

so wouldn't a decent smart power strip?

Not if they are using the "smarts" as the means to protect the device rather than the circuitry.

we have the means to do aftermarket modifications, and we do!

Then that isn't the mainstream and easily accessible to the average user. Aftermarket modifications made by makers and DIYers is not the mainstream. Well, maybe I should speak for myself... but in my circle of friends, family, and coworkers, I'm in a club of one.

as demonstrated in the collected issues

A collection of six issues of which not all are directly regarding "powering everything in one simultaneous step". In any case, 6 issues out of 5243 TASMOTA issues represents ...? A data scientist would not likely call that a representative sample.

At the end of this debate, what you or I think about this capability is immaterial. If the case you make sways Theo, then it'll be incorporated. So far, that is not the case. Thus, your fork is where this stands at the moment. Now all you have to do is keep it sync'ed with the development TASMOTA continues to make in the main branch of the project.

Mike

[ascillato2]

Closing issue as Theo had answered #5243 (comment)

[kueblc]

Thanks for your consideration but I feel this was closed prematurely. The proposed solution using rules and backlog does not address the issue, I outlined that in my first post.

Tasmota is a great start to alternative firmware that gets me 95% of where I want to be, but this experience here is discouraging. Community involvement and feedback is important for a successful and sustainable open source project, and I'd ask that you consider the current options may not be sufficient before making such a quick judgement.

[erwill2]

@kueblc Bummer. Would be a great option. Fork and add powerall I'd use it and believe many others would as well.

[andrethomas]

Would be nice if there was a way to poll most of the users in some way - Issues is not a good way to achieve a poll on most of the user's thoughts as it is only seen by people who provide support here and people who come to Issues looking for answers.

[meingraham]

Would be nice if there was a way to poll most of the users in some way

The pace of enhancements, feature requests, and "general" development is so rapid that there is no way that polling the user community for input on each of these is viable. I do think that a one-off "what kind of feature would you most like to see" might work. Or the occasional (no more than a couple times a year perhaps) "we're considering a big shift or a major new feature - do you agree?"

Mike

[Jason2866]

A place where users can post there wishes with a visiter voiting system could work...

[meingraham]

Publicizing a feature feedback/poll page via the home page would increase participation.

Could b a series of different polls:

• Feature X yay/nay
• Rate Feature A 1-5, B 1-5, C 1-5
• Rank Potential Enhancements A, B, C 1-3
• etc.

Of course, this could open a can of worms 😜

Mike

[Jason2866]

Just wishes 😉

[kueblc]

A collection of six issues of which not all are directly regarding "powering everything in one simultaneous step". In any case, 6 issues out of 5243 TASMOTA issues represents ...? A data scientist would not likely call that a representative sample.

@meingraham I would ask that you refrain from posting such inflammatory remarks. They do nothing to add to the conversation and it is inappropriate conduct for a community project.

The six comments that I found all do directly reference having an issue with the lack of a power all feature.

I'm honestly baffled by my experience here, some of the comments edging on hostility. It's fine if you don't see the need for a feature personally, but if several people have asked for it, and someone volunteers to implement it, why is this such a hot debate?

I feel that I adequately addressed that backlog does not solve the issue for me in my first post, and was repeatedly told that very suggestion. This issue is not solved.

That's the whole point of an issue tracker, to gather community feedback. Does one person's input not matter? Do six people's input not matter?

If you wish to gain community input, don't close feature requests as soon as they pop up.

[ascillato]

@kueblc

Hi,

Please, do not take that personal. This thread is just ideas being discussed. No one wants or have any intention of attacking you. This is just ideas being debated. Please, don't feel bad is your idea has been dismissed for now.

Your post is complete. Your idea was very well put. It is a good idea (thanks for sharing it 👍 ), but the last word is from the project owner. This is open source and free. It is being supported by the people of this community by free and in their free time. So, that means that not everything will be answer and not everything will be implemented.

Anyway, this issue has been labeled as requested feature (hold over) so, it can be revisited in the future.

You can always fork this repository and then make a Pull Request so your feature can be downloaded by other users if they require/want/search for that.

If you want to talk further about all this, remember that you can find us also in the Tasmota Support Chat.

We hope you continue sharing ideas.

[meingraham]

I second what Adrian just posted.

posting such inflammatory remarks

Unfortunately, sometimes textual dialog fails to convey the proper intent. My intent was not to be "inflammatory" but rather to pose an differing perspective in the dialog. For example, if one looks at solidifying one's point, a small fraction may not provide a strong argument.

In this case, a valid idea did not result in your desired outcome. Just differing perspectives. Not personal.

Mike

[kueblc]

Hi @ascillato, thanks for taking the time to respond.

Please, do not take that personal. This thread is just ideas being discussed. No one wants or have any intention of attacking you. This is just ideas being debated. Please, don't feel bad is your idea has been dismissed for now.

I do not feel attacked, but thank you for the reassurance. I'm raising awareness that the process by which the suggestion was dismissed seems to be problematic. It seems to have gone totally unnoticed that the suggestion brought to me is identical to the alternative that I had discussed in the first post, which I evaluated and found did not address the issue.

This is open source and free. It is being supported by the people of this community by free and in their free time. So, that means that not everything will be answer and not everything will be implemented.

My point exactly. I found a problem multiple people had encountered, and I offered to fix it. For free. On my own volunteered time. Just as I did when adding support for the SM16716.

That's because I believed in this project and wanted to contribute back, as it was perceived that this was a community empowered project, not simply belonging to one man.

You can always fork this repository and then make a Pull Request so your feature can be downloaded by other users if they require/want/search for that.

As I mentioned, I intend to. I had hoped to clear this proposal before investing my time, as independently maintaining a project this large is impractical, so I would like to see this PR integrated for the whole of the community.

[kueblc]

Unfortunately, sometimes textual dialog fails to convey the proper intent. My intent was not to be "inflammatory" but rather to pose an differing perspective in the dialog. For example, if one looks at solidifying one's point, a small fraction may not provide a strong argument.

Mike, your responses have been inflammatory. Comparing the number of issues I've linked vs the total of the number of issues is by no means a valid metric to evaluate the merit of a proposal. And to sarcastically reference how a data scientist might see it is unbecoming. My point was that I am not the first or only person to have a problem with this.

The point of the issue tracker is for people to provide feedback. It is not appropriate at any time to minimize feedback due to it being statistically small compared to the entire base of feedback throughout the project's history.

At this point, if you have no more constructive feedback, I'd ask that you please not comment.

[meingraham]

I'd ask that you please not comment

The point of the issue tracker is for people to provide feedback

LOL

[kueblc]

constructive feedback

[andrethomas]

@kueblc Can you do a PR in such a way that this functionality is disabled by default and does not take any additional flash or mem on a standard compile (for release and dev bins)?

[kueblc]

Absolutely! That is what I intended. 😄

[kueblc]

I see that you finally came around with 34eed71, better late than never

[meingraham]

@kueblc

Just required the right impetus ;-)

[Bun-Bun]

I apologize if this is inappropriate, but I just wanted to say thank you for implementing this feature.

Made the SM-SO301 power strip much more pleasant to use.