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

Pulstime - more than 3600sec? for Relay and Button #678

Closed
testeve opened this issue Mar 15, 2018 · 6 comments
Closed

Pulstime - more than 3600sec? for Relay and Button #678

testeve opened this issue Mar 15, 2018 · 6 comments
Labels
enhancement New feature or request relay

Comments

@testeve
Copy link

testeve commented Mar 15, 2018

Hello!

i use the Esp8266 with espurna Sonoff 4CH Firmware for light in my home.

i switch with a Key and Alexa, its run perfect.

My wish would be that the lamp switches itself off after 3 hours.
Unfortunately, I can only set delay at 3600sec.

Thanks for help!

@testeve testeve changed the title delay for Relay and Button Pulstime - more than 3600sec? for Relay and Button Mar 15, 2018
@xoseperez
Copy link
Owner

xoseperez commented Mar 15, 2018

The pulse functionality uses the Ticker library that internally stores the data in a 32bits variable representing microseconds, that set the maximum value in around 71 minutes, that is why in ESPurna the max pulse time is limited to 60 minutes. See #141 .

Changing this is possible but not trivial.

@xoseperez xoseperez added enhancement New feature or request relay labels Mar 15, 2018
@mcspr
Copy link
Collaborator

mcspr commented Jun 6, 2018

@xoseperez Pulse timers used (until aaab65f) Ticker.once_ms which uses sdk os_timer_arm that has milliseconds for an argument. SDK documents specific limit - 0x68D7A3 / 6870947 milliseconds / ~114,5 minutes.

Edit: Manually set pulseTime for 114 minutes did work.
Edit2: Amending previous misunderstanding of 'millis()' - overflow is actually ~50 days.

@ristomatti
Copy link

@xoseperez Could the solution be time based? Switch on/off would add a one time schedule to switch off/on when the given amount of time had passed. I'd find this feature really useful.

My use case is a metal halide lamp I use as a winter time "wake up" light. It uses 320W and also heats quite a lot so I need to have an automatic toggling it off. Sometimes I'd like to have it on for longer than an hour but I cannot just switch it back on as the metal halide lamp chemistry prevents it from turning on again before it has cooled down to a certain level. This takes around 20-30 minutes.

@nebomuk
Copy link

nebomuk commented Aug 15, 2019

I'm also interested in a pulse time longer than 60 minutes, for use cases such as charging battery powered devices for only a few hours and lamps turning off after a few hours.
Wouldn't it be possible to use <Ticker.once_ms> to simply call <Ticker.once_ms> again after the maximum time has elapsed for longer periods of time?

@mcspr
Copy link
Collaborator

mcspr commented Aug 15, 2019

It would be. One approach that I was thinking about is to use internal counter to measure how long timer was running so far. Something like this is already implemented in Sming Core for usec timer:
https://github.com/SmingHub/Sming/blob/develop/Sming/Core/Timer.cpp (see longIntervalCounterLimit)
Similar counter can be implemented here. Instead of loop check, aaab65f, millis value can be attached to the timer and it can periodically compare it to the target time, adjusting the next run either with max value or some smaller one

@mcspr
Copy link
Collaborator

mcspr commented Jan 16, 2022

ref. #2139, also webui now implements pulse time as a string instead of a number (and obviously via mqtt, http api, raw relayTimeN setting)
old seconds still work, but now 3h will also be accepted

updated changelog to include this, both issues were missed initially (edit to fix github markup)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request relay
Projects
None yet
Development

No branches or pull requests

5 participants