Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Bug Reports
  3. EEPROM values behaving strangely in RelayActuator example

EEPROM values behaving strangely in RelayActuator example

Scheduled Pinned Locked Moved Bug Reports
5 Posts 3 Posters 1.9k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    mainali
    wrote on last edited by
    #1

    My opinion is to clear the EEPROM before calling gw.loadstate(). in the example. while testing if there is a value previously written in some address it gives inconsistent output. Clearing the value in setup should be done before saving any state.

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mainali
      wrote on last edited by
      #2

      I Have made the necessary changes in the code and have send a pull request. If that helps the admin can merge else this topic and pull request can be closed

      1 Reply Last reply
      0
      • hekH Offline
        hekH Offline
        hek
        Admin
        wrote on last edited by
        #3

        You have the ClearEepromConfig in examples folder for this. I pretty sure you wouldn't want to have this in RelayActuator-example.

        1 Reply Last reply
        0
        • M Offline
          M Offline
          mainali
          wrote on last edited by mainali
          #4

          I am testing that example as of now, so added that there. Ideally the EEPROM should be cleared before writing new code to the board to prevent it from reading redundant state which was saved in the microcontroller earlier for some other code. we can move this to the main code so that it is included globally. I added it there so that someone else using that example doesn't get strange values and spend hours trying to decode the library.

          1 Reply Last reply
          0
          • AnticimexA Offline
            AnticimexA Offline
            Anticimex
            Contest Winner
            wrote on last edited by
            #5

            But what will happen with the NodeID and the signing preferences then? If EEPROM is cleared if you update your gateway you have to restart all nodes using signing so the gateway gets updated then.
            If you do it in a node, the gateway will assign it a new nodeId and that in turn messes up for the controller. I do not think wiping all EEPROM config on reprogramming is a good ide. The purpose of the EEPROM config is exactly to preserve certain parameters on power cycle/reprogramming.

            Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            10

            Online

            11.7k

            Users

            11.2k

            Topics

            113.1k

            Posts


            Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • MySensors
            • OpenHardware.io
            • Categories
            • Recent
            • Tags
            • Popular