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

modbus_switch: honor switch:restore_mode #4122

Merged
merged 2 commits into from Nov 29, 2022

Conversation

jpeletier
Copy link
Contributor

What does this implement/fix?

This PR implements switch::restore_mode functionality for Modbus switches. It leverages the groundwork in PR #3648, so it is actually a very small change.

Modbus switches can now be restored to the last on/off state as recorded by ESPHome, or started with a forced on/off state, etc.

By default, this feature is disabled so Modbus Switch will behave as it did before this PR.

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Other

Related issue or feature (if applicable): fixes

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#

Test Environment

  • ESP32
  • ESP32 IDF
  • ESP8266
  • RP2040

Example entry for config.yaml:

# Example config.yaml

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

@probot-esphome
Copy link

Hey there @martgras, mind taking a look at this pull request as it has been labeled with an integration (modbus_controller) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)

@jpeletier
Copy link
Contributor Author

@jesserockz jesserockz merged commit d706f40 into esphome:dev Nov 29, 2022
@nagyrobi
Copy link
Member

Wow. Thanks @jesserockz

@jpeletier
Copy link
Contributor Author

@nagyrobi please test extensively to see if it does what you want and report back. Thanks!

@nagyrobi
Copy link
Member

nagyrobi commented Nov 30, 2022

Tested this PR in the v2022.12.0-dev with:

external_components:
  - source: github://pr#4122
    components: [ modbus_controller ]
    refresh: 1min

And config:

switch:
- platform: modbus_controller
  modbus_controller_id: relay24
  id: heat_00_sw
  name: 00 switch
  register_type: coil
  address: 0
  bitmask: 1
  restore_mode: RESTORE_DEFAULT_OFF
  1. Turned the the switch on (the corresponding coil/relay turned on on the ModBUS board)
  2. Waited 2 minutes (to ensure at least one saving to flash cycle is reached)
  3. Power-cycled the entire circuit (ModBUS relay board and ESPHome node, they are on the same PSU), since the board doesn't remember the state the relay remained off
  4. Result: switch didn't turn back on as exepcted with RESTORE_DEFAULT_OFF after ESPHome boot.

The expectation was that the board should have saved the switch state to the flash (didn't see an entry in the INFO log about that, either) and restore it after reboot.

@jpeletier
Copy link
Contributor Author

OK, I will check with your config and let you know

@nagyrobi
Copy link
Member

nagyrobi commented Nov 30, 2022

From what I understand this patch restores the state if it was found saved in the flash. But it looks like the step needed before this, to actually save it, is missing. Just a wild guess

@jpeletier
Copy link
Contributor Author

@nagyrobi

Ok, it turns out the code is OK, but this feature only works if you have the preferences component enabled, I completely forgot. Add this to your config root:

preferences:
    flash_write_interval: 15s

And it should start working. Magic.

flash_write_interval's default is 1m, however I put it to 15s for testing more quickly.

With this on, you should see the following some time after a relay state has changed:

[22:57:10][D][esp32.preferences:142]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed

Note the 1 written above, means an actual change was written to flash. If you see 1 cached it means the value that was going to be written is the same value that currently resides in flash, so no point in writing it.

After that message, you can shut down. When the device comes back online it should restore the state (RESTORE_DEFAULT_OFF).

I will update the docs to warn that preferences must be enabled.
Also, I found a bug while digging into the code, but it should not affect you because it is only for the *_INVERTED_* restore modes.

Regards

@jpeletier
Copy link
Contributor Author

new docs PR: esphome/esphome-docs#2496

@nagyrobi
Copy link
Member

nagyrobi commented Dec 1, 2022

Not working, unfortunately:


[20:41:03][D][esp32.preferences:113]: Saving 11 preferences to flash...
[20:41:03][D][esp32.preferences:142]: Saving 11 preferences to flash: 11 cached, 0 written, 0 failed
[20:41:07][D][switch:013]: '24. Aktuátorok táplálása' Turning ON.
[20:41:07][D][switch:056]: '24. Aktuátorok táplálása': Sending state ON
[20:41:18][D][esp32.preferences:113]: Saving 1 preferences to flash...
[20:41:18][D][esp32.preferences:142]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed

pulled the power plug... reconnected...

[20:41:53][D][esp32.preferences:113]: Saving 12 preferences to flash...
[20:41:53][D][esp32.preferences:142]: Saving 12 preferences to flash: 11 cached, 1 written, 0 failed

Switch didn't turn back on.
It's like off states are somehow faster written to flash after boot immediately, than when the modbus component would try to restore...? Kind of race condition?

@github-actions github-actions bot locked and limited conversation to collaborators Dec 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants