Repository navigation
relayBoot0=on + relayDelayOn0 causes relay to stay off on boot #2653
Description
Device
gosund sp111
Version
1.22.0-git51bc9027
Bug description
I'm trying to sequence powering on three upses to prevent blowing fuses.
I thought that combining “Always ON” with relayDelayOn would be a good solution, but unfortunately the relay does not turn on after startup.
Interestingly, it works correctly for low relayDelayOn values (below approximately 5000).
Steps to reproduce
config
{
"alexaEnabled": "0",
"btnRepDel": "0",
"cfg": "17",
"dczRelayIdx0": "967",
"desc": "UPS2 delay",
"dns0": "",
"gw0": "",
"hostname": "esp-wp-15",
"ip0": "",
"ledMode0": "7",
"ledMode1": "2",
"mask0": "",
"mqttServer": "mqtt",
"ntpServer": "ntp",
"pass0": "redacted",
"relayBoot0": "on",
"relayBootMask": "0b0",
"relayDelayOn0": "30000",
"ssid0": "esp-ap",
"telnetSTA": "1"
}+OK
Activity
m-kozlowski commentedon Nov 14, 2025
Doesn't seem to be related with time synchronization.
Setting ntp boot delay > relayDelayOn didn't help.
Breaking ntp connection didn't help either.
mcspr commentedon Nov 14, 2025
iirc this was done to match any other call at runtime requesting the transition. meaning, it should wait for 30s and then turn ON, as boot mode just creates a request for transition and does not force the mode immediately.
btw 824e121 also set up relay transition to be skipped when previous mode matches. relay should stay ON on boot if previous state was software reboot (console
reset, button action, etc.), not hardware one, thus skipping the delay.mcspr commentedon Nov 14, 2025
relays count using internal monotonic 'uptime' clock, so ntp sync / changes / etc. are indeed irrelevant
m-kozlowski commentedon Nov 14, 2025
This is exactly the behavior I expected and would like to achieve.
Unfortunately, it seems that something gets in the way when the delay exceeds 5-6 seconds.
I am testing by physically cutting the power, so the special reboot handling mentioned above should not have any effect.
mcspr commentedon Nov 14, 2025
probably canceled by mqtt? either /set topic, or domoticz doing it. 5..6sec works around that, but more does not
m-kozlowski commentedon Nov 15, 2025
You're right! It's domoticz. I don't know why, yet, as there are no related automations nor direct commands issued, but at least i know where to investigate further.
mcspr commentedon Nov 30, 2025
idk if #1264 still applies. on connection, every state is published to dcz... but, default state is 'false' and not 'uninitialized'. I suppose it could track when the first relay change callback happens before storing status value.
kind of global workaround for applying status from our side is #2656 - relay api simply blocks IDs that haven't boot'ed yet. it has other implications, though, not sure I do really like it
dcz(relay): publish status only when processed at least once
dcz(relay): publish status only when processed at least once
mcspr commentedon Dec 2, 2025
Should be fixed since affd155?
...specifically should be fixed in 5a364e4
Quick test shows no domoticz/in publish on connection, only after the relayBootX time passes
Other reply logic still stands, meaning domoticz publish for ON status would still not generate publish from the device
m-kozlowski commentedon Dec 6, 2025
Thanks! Works flawlessly in 46719ee.