Author Topic: Brainstorming ideas for persistance across reloads/reboots  (Read 3123 times)

jondecker76

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 763
    • View Profile
Brainstorming ideas for persistance across reloads/reboots
« on: August 18, 2008, 06:10:18 pm »
While working on Toggle Power/Input bugs, it really bacame apparent that we really need a way for individual modules to have persistant information across reloads of the DCE router. Toggle-command devices aren't the only thing that could benefit either - Lighting Plugin would benefit greatly as well especially for light switches that can't be polled for their status.

The only thing that makes sense to me is to have this functionallity locally coded for each module/plugin. This way, if persistant data is needed, you only have to add a bit of code to do it. If it is not needed, nothing needs changed.

Some Ideas that I had were:
1) Addition of a "Safe Reload" command. When this command is received, it sends out a "Safe Reload Received" event that each module/plugin could receive, and save whatever data they need. After a set amount of time, a normal relaod is carried out. Then, for example, after the reload is finished and the module is run, instead of initializing everything to 0, it can check for the existance of persistant data, and if it is less than 10 minutes old, use it - otherwize initialize to 0 as it does now. (this is just an example)

OR

2) Instead of creating and implementing a new "Safe Reload" command, just modify the handling of the current reload to do as above: emit an event so other modules can clean up, then carry on with the reload. (Though the idea of a separate Safe Reload command appeals to me more.

3) Of course, it can be hacked in per module, saving values to a file when they change. But this is both messy and causes unnecessary disk usage.

4) A new PersistantData plugin where other plugins can register data to keep a local copy of, and restore them from the PersistantData plugin after reload (this would require that the PersistantData plugin be left alone during reload)


Anyone have some other suggestions or opinions we can kick around?

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Brainstorming ideas for persistance across reloads/reboots
« Reply #1 on: August 18, 2008, 06:55:15 pm »
Another idea would be to have the modules query the devices they control at startup.  Obviously this wouldn't be possible for all devices, but these could be returned to the state that is expected at startup while shutting down.

On the other hand I can imagine for example people not wanting all the lights turned off on a router reload, and some lighting systems just can't be queried for their current states.  Oh well it's just another idea.
"Change is inevitable. Progress is optional."
-- Anonymous


colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: Brainstorming ideas for persistance across reloads/reboots
« Reply #2 on: August 18, 2008, 09:57:45 pm »
Isn't one of the purposes of the device data database to store this info? Slightly extend the schema of the main devices (esp the Sort setting in Orbiter pls!) And periodically execute a SQL command to write the current values (think this is already done for Vol with AV equipment?)

Does Reload send a DCE shutdown message to the devices? If so,just hook the code in there.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Brainstorming ideas for persistance across reloads/reboots
« Reply #3 on: August 25, 2008, 05:14:14 am »
Jon,

We can accomplish this via programming atm, if we are careful...
1.  simply program last state information into the shutdown code for each device...

2.  Read the last state info and set accordingly, maybe repoll if needed,

in Ruby, there is a Shutdown command, where we can gracefully shutdown our devices

also, there is a command "Add/Create Devdata", where we can programmatically 'ADD' the device's state AS device data,
and use that for persistence.  That is how I poll and store each Insteon device's complete database.
(Consequently, that one took me about 2 weeks to figure out)

HTH,

Dan



 
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.