Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend 'pulse' to allow OFF when current below threshold #2159

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

julianwb
Copy link
Contributor

Speculative PR: this may or may not be acceptable, looking for comment really.

If the principle is accepted then I would be pleased to make any necessary changes for merge; if not, that's fine - I did it for me in the first place!

@julianwb
Copy link
Contributor Author

I realise that I have not extended the "reboot" persistence/restoration for the current setting - behaviour may be unexpected I suspect as the ON/OFF state may be persisted and restored, but not the limit or the "state". This should be done too

@mcspr
Copy link
Collaborator

mcspr commented Feb 19, 2020

Nice idea. I think there were some issues mentioning this use-case for this sort of thing, but other way around - when values are too high turn relay off. Not sure there was any issues regarding turning relay off when consumption drops.
I do not think pulse is a way to go though, but it is a creative approach :)

For persistence, take a look at the relay module methods at the top of the file. Rtcmem is a basic struct that is mapped to a specific region of RAM that is never erased on reboots. getSetting / setSetting are self-explanatory.


As mentioned in gitter, to use rpn here we would need variable to store the counter, so some kind of variable manipulation needs to happen first (as there is none atm, push, pop, peek at the very least)

e.g.
0 pusha -> $ra is now 0
popa -> $ra is now unset and 0 is on the stack
peeka -> $a is still set to 0, 0 is on the stack

Operator registration is very straightforward. But, I need to remember to implement this.

@julianwb
Copy link
Contributor Author

"I do not think pulse is a way to go though, but it is a creative approach :)" <- It is the lazy approach! As I said I started with something that would work for me only .. this was simplest: though abusing the "pulse" command in particular changing the meaning of its parameter is decidedly suspect ....
A new command would be clearer .... cannot think of a name for it though!
Persistence: yep working on it presently thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants