Reactor-Editor / Reactor-ui-Status Errors

[toggledbits]

Guys,

One of the things I really like about Home Assistant are these "input_boolean", "input_number", "input_text" and "input_select" components that serve as data containers. The "input_boolean" component, for example, functions in the same way as a virtual switch, holding a boolean state and allowing you to modify that state. The "input_select" holds a defined set of values, as opposed to "input_text" which just accepts anything. There's even an "input_datetime" object.

I can see these being far more useful than trying to shoehorn more flexible behavior into virtualized models of existing devices, so this is the direction I'm thinking of going for MSR. One thing I really like is that the flexibility of them is sufficient to eliminate the need for expressionless variables in many, if not most, cases.

Thoughts?

[Fanan]

Absolutely - that make sense! Many of us still use a Vera as a z-wave radio, and we can always create a virtual device in Vera if we want to keep it the old and simple Vera way. Lay the effort elsewhere!
/Fanan

[toggledbits]

To be clear, I'm not saying "use Home Assistant", I'm saying that I'm going to adopt Hass' model to MSR's upcoming virtual entities.

[LibraSun]

This post is deleted!

[toggledbits]

Hammer? What? I'm confused by all of this, and it mostly seems the opposite of what I'm saying. I want things to be done as close as possible to the point of use, generally speaking, so it makes sense to me that data stored for use in (i.e. as terms of) rules and logic be managed in the same place as the rules and logic. I've never thought otherwise. I just think overloading existing device types is far too constraining. Hass has a simple, successful model, in my view.

@librasun said in Let's talk about MSR-provided Virtual Devices... NOT!:

Seems clear (to me, anyway) that your intent with early MSR has been to leverage Expressions primarily as set-once-read-many, with the heavy lifting being done with ${{ substitutions }} and [ Set Variable ]. I think this explains why it remains comparatively challenging in MSR to, say, update arrays on the fly or modify JSON objects at all after initial declaration, without jumping through lots of indirect hoops.

First sentence, no, that's never been my intent. The rest, sounds like a conversation we haven't had (and should be separate from this thread), both about what makes it difficult and why you want to do it in the first place. Remember, MSR is not an expression language with support for rules and reactions. I wouldn't need to build that, because Lua, Python and groovy already exist.

[kfxo]

@toggledbits So what would be the difference between MSR provided Virtual Devices and expressionless variables? Do you envision interacting with the virtual devices in MSR? Right now I use expressionless variables whenever I need to keep track of some value and I have no intention of needing to modify the value outside of logic. I use virtual devices both in openluup and HA when I intend to physically interact to change the value (or I have no other way of getting the value into MSR..cough cough HA event data generated by integrations that are not reflected in entities). I guess I am not seeing why MSR would need Virtual Devices to act as data containers when MSR already has data containers with expressionless variables.

[therealdb]

Well, I think it has a meaning when we add dashboards to the mix. I’ll vote for it, plus combo device (like HA) to express complex devices. I’m using this approach right now in my own dashboard system.

[kfxo]

I could definitely see it being useful for dashboards and also if an integrated controller does not provide the ability to create a virtual device.