Renaming controller ID in reactor.yaml is a bad idea
-
I just added a second Vera controller in to my reactor.yaml file and named it's ID "vera-edge". That works OK.
My main Vera controller that was already linked to MSR was named just "vera" in the ID.
I changed this to "vera-plus" and restarted MSR, but then all my rules were broken.
I panicked and changed the ID name back to "vera" in the reactor.yaml file and restarted again. All my rules appear to be referencing correctly again now.
-
I bumped into the inverse of that problem when I accidentally caused several devices to be removed from my Vera Plus. While MSR was happy to carry on as if nothing had happened (which I suppose could have been ruinous to my overall workflow, had I not intervened!), the truth was that Vera assigned all new Dev#s to those child devices once they reappeared to her.
The only thing that saved my bacon in the process was being able to leverage MSR's memory of the old Dev#s, so I could systematically go change them back under Device > Advanced > Parameters >
id
, one by one. Took a while, caused uncountable Luup engine restarts, but honestly worth it in the end.How do you think MSR ought to handle future renaming events? I'm sure @toggledbits welcomes your suggestions. For starters:
- Should MSR gracefully detect the new controller name assignment from
reactor.yaml
and propagate that change to all Rules? - Should controller renaming be done instead through a purpose-built 'Tool' inside MSR that handles such modifications?
- Should controller enumeration be abstracted one further level so they are referenced by, say, S/N behind the scenes?
Glad you were able to reverse the change without losing your hard work!
- Should MSR gracefully detect the new controller name assignment from
-
T toggledbits locked this topic on