MSR UI on a mobile browser

[therealdb]

Hi @toggledbits,

I don't know if I'm the only one, so I'm reporting here first instead of opening a bug.

Basically, with the latest 2-3 updates of Reactor and MQTTController, after a restart previous statuses are lost (for both Virtual and MQTT entities), until they're restored.

It's particularly annoying for Virtual Entities, because I have to set them all over again (I've coded some defaults at startup if the values are empty, but sometimes these are not the correct values before the update).

Not easy to reproduce, and logs are gone, but the first time I tought it was me hallucinating, the second one didn't bother too much, after the third I realized it's something not coming from me.

the behavior could be seen in this screenshot:

Any hint is appreciated.

[toggledbits]

Updates to extension controllers and Reactor itself (and its included controllers) often change the definition of capabilities and their implementation. To bring the entities up to the latest version of these capabilities and compatibility with their parent Controller's implementation, the entity is rebuilt, and when that happens, all previous attributes values are lost. Not doing it can result in logged errors and other more serious misbehavior. I can look into less dramatic solutions, but it won't be soon.

[therealdb]

@toggledbits that’s ok. I could write something to adapt to this behavior, as I’ve already done. I could just save the status to a global variable on stop and restore at startup if null. Being string or number values, it should be easier than forcing you to look at a general solution. Thanks.

[tunnus]

Also noticed this some time ago, and adapted using e.g. the following rule (if virtual switches have lost their values (states), defaults are set when MSR starts)

[therealdb]

@toggledbits since we're at this, what about a new config parameter in at least Virtual Entities (let's call it defaultValue)?

It should be easier than writing a bunch of rules. Thanks.

[therealdb]

Not sure if that's enough to be generic (I have 40 virtual devices and some of them have values changed on the fly to drive some custom things, where restoring a default is not the best thing to do), but I've ended up with something like that.

A rule that's saving the status in a global variable when a new Reactor version is available:

dev =  matchEntities( { controller: 'virtual' } ),
each d in dev: do 
  d != "virtual>controller_all" && d != "virtual>system" ? 
    ({id: d, attributes: getEntity(d).attributes})
: null done

(maybe some checks to avoid null values could be useful, but when a new version is detected the old values should be in place - I cannot save them at shutdown, the best thing to do in order to get fresh values before the update)

And another one running at startup and checking for nulls and restoring the values:

each d in virtualdevices_status: do 
  each attrs, key in d.attributes: do
  key != 'x_virtualentity' ? 
    each attr, akey in attrs: do
    cVal = getEntity(d.id)?.attributes?[key]?[akey],
    sVal = attr,
    cVal == null && sVal != null ?
        do 
          performAction(d.id, 'x_virtualentity.set_attribute', {akey: attr}), 
          d.id + ' _ ' + akey + ":" + attr
        done
      : null
  done : null
  done
done

YMMV.

At this point, I'd probably appreciate the ability to define blocks of code and execute them directly in a reaction, instead of calls to a fake Set Variable, or at least if Set Variable reaction could support line breaks/multiline text, for readability.

This could be easily encapsulated in a custom controller, but last time I checked we cannot call performAction or getEntity on other controllers. I tought to monitor via MQTT via an external script, but I wanted to stay in MSR in order to simplify things. Any comments @toggledbits? Thanks.

[therealdb]

This code is now obsolete because the latest versions of both MSR and MQTTController have this behavior natively. I'll leave it just in case someone wants to look at some code enumerating/saving attributes.