OpenAI Controller for Reactor

[toggledbits]

I made a video with a first look at Multi-System Reactor. In this video, I show the major components of the system, and run a demo automation where a light switch on HomeAssistant controls a light on my house Vera Plus.

This project is coming along nicely, but there is much documentation to write, and lots to "to-do" list items yet to be implemented, most on the critical path to working outside of my own hands, but a few still are.

Comments and feedback welcome.

YouTube: https://youtu.be/EcdPLnd2ybo

Rumble: https://rumble.com/vccph1-preview-of-multi-system-reactor-first-look.html

Chat with me on Discord: https://discord.gg/B3FDcBNR

[Elcid]

Looking good, I for one can not wait. Thank you for the update. Have a great new year.

[akbooer]

Great to see! A huge undertaking.

I still don’t understand what system is actually running this Multisystem Reactor?

[Matohl]

@toggledbits Look very interesting as I want my next system to be independent of the Vera. I have the same question as @akbooer what it is running on top of, a Pi? Still not sure I understand all the concepts yet but will definitely test it when you release it.

[rafale77]

Happy New Year guys. Wow it is a very impressive effort and outcome. A controller to link them all under a better GUI.
I am honestly quite happy with my current openLuup-HomeAssistant-Zway setup but admittedly, it was a lot of work to setup. This would make it much easier.

[toggledbits]

@rafale77 and you can continue with the effort you've put in there. The VeraController instance will happily accept your openLuup (and ZWay) devices. My goal is to have users up and running with their existing environments. You have the option of using more direct interfaces where (and when) they exist, but that will remain an option, not a requirement.

@akbooer and @Matohl what you are seeing is running under nodejs in an Ubuntu VM. I will be testing it under Pi; I see no reason it could not run there. My plan is to make docker containers available for Pi and most common NAS systems that support docker. Any Linux distro that supports nodejs should work. Windows is also a target, as well as MacOS. Since I have a working build environment for OpenWrt Barrier Breaker (the version that underlies current Vera firmware), I'm thinking I'll see if I can't get node built there as well.

[PerH]

Very excitiong concept, and I'll definately test this once available!
Well done Patrick, and happy new year to all.

[Black Cat]

@toggledbits
Happy New Year to everyone as well
Looks like you have given us all a belated Christmas present.
A couple of questions, will/can it run with multiple Vera's (Vera Lite UI5) and Edge UI7?
Haven't noticed anyone has asked about Homeseer integration, which would be my missing link.
None the less it's a quantum leap in our world of Automation.
Lastly, you will have your hands full now keeping everyone up to date with developments, which forum do you intend to use as the Primary means of communication?

[toggledbits]

Unfortunately I haven't run any UI5 in years, so I don't have anything around to play with. Technically, however, there's no reason it could not be made to work.

For any interface, the only requirement is some kind of API where device information can be gathered. I can't imagine HomeSeer not having one, but it's not a system I've ever had contact with.

For the moment, if there's no objection from the owner, I'd rather communicate in this forum rather than the Vera Community forums, and maybe a category can be set up just for that, to help thread the discussions a bit better. I've also got Discord, but I don't know how many people really use that or would be interested in trying; but I like the more immediate flow of messaging for some things. As I said in the video, there's an entire ecosystem that has nothing to do with building the project that needs to come together, so I'm sure it will evolve.

[Black Cat]

@toggledbits
I'm surprised that you never looked at Homeseer as a Vera replacement, it appears to have a huge US (local to you) user base, may I ask why?
Do you have a timeline for release, perhaps a Beta; I know that there will be many chopping at the bit for a test drive.

[akbooer]

@toggledbits said in Preview of Multi-System Reactor:

I'd rather communicate in this forum rather than the Vera Community forums, and maybe a category can be set up just for that, to help thread the discussions a bit better.

Sounds like a good idea to me. This forum has always been platform independent, so what better place?

[PerH]

If the idea is to create a top automation layer - what about including some of your other automation luup plugins? I think i.e. Delaylight, SiteSensor and AutoVirtualThermostat would fit nicely as Automation templates that can be quickly configured?

Automation templates is something i've been missing in Reactor, what i mean by that is simply a good way to copy the structure of a good automation i have running in one room to another room (Today I have a Reactor sensor in each room, and one for "House" automation).
Example: I have two guest rooms set up with identical sensor and actuator layouts, so the automation i want would be identical for those rooms.

Another side note, i think some sort of room organization would be nice in the entities list?

I'm not entirely sure about how to implement either of these, or the scope of the work it entails, just throwing out some ideas.

[LibraSun]

[Possibly split the following feedback into its own thread if seeking input on MSR Dashboard UI]

As a Dashboard n00b, I'd benefit from knowing exactly where on a particular Dashboard tile to tap for "Dim+", "Dim-", "On/100%" and "Off/0%". So I created two examples, linked below, despite knowing full well that others have created much better examples than this on other platforms. I also fully acknowledge that this kind of feedback is premature, as the official roll-out of MSR's Dashboard feature has not yet happened.

ON: https://drive.google.com/file/d/1kWPtPa2HQ5GExBIi45QNJGyEvsz5QVZu/view?usp=sharing
OFF: https://drive.google.com/file/d/1EIZK1BggsDtNWm8mfBT605N7-cnkeSQ_/view?usp=sharing

[LibraSun]

SUGGESTION

In the text fields used under "Rulesets", instead of having "Add your rule's triggers here" guidance text pre-populate the object (which requires users to click-drag-delete before typing), could you instead use the object's .placeholder attribute?

I know this is a controversial stylistic choice among CSS designers, but the Placeholder approach carries with it some immediate benefits:

• Help text disappears upon clicking into field;
• Help text reappears if user empties the field;
• Can appear in different font style (e.g. greyed, italic) from input text;
• Not apt to be misinterpreted as filled text, nor read by a screen reader app;

Minutiae, yes, but still worth my mentioning IMHO.
COUNTERARGUMENT: https://www.smashingmagazine.com/2018/06/placeholder-attribute/

[LibraSun]

SUGGEST (I'll happily move these suggestions elsewhere, such as the Mantis, if instructed to do so)

Assuming that "==0" and "is FALSE" will both match the condition of a device being turned OFF (the MSR UI seems to prefer "false" to "0" when referring to POWER_SWITCH.STATE, for instance), could you also add "is ON" and "is OFF" to the drop-down list of comparators?

However redundant, this seems a natural language-y thing to have in place for novice users, who may not think in binary 0/1.

[toggledbits]

There are a bunch of hints in the capabilities data that I'm not making use of yet. This is exactly that kind of thing.

    "power_switch": {
        "attributes": {
            "state": {
                "type": "bool",
                "values": {
                    "true": "on",
                    "false": "off"
                }
            }
        },

[LibraSun]

By now, you understand I'm reluctant to add an "Issue" to the Mantis when I'm merely thinking aloud, so here goes with another set of MSR thoughts:

(1) Should each Ruleset have its own top-level DISABLE flag/button/status? (i.e. above even 'Triggers' and 'Constraints')
(2) Would it be useful to be able to "enable/disable" a Ruleset from another Ruleset? (this may already be possible, I haven't checked deeply)
(3) Does MSR possess the same "Throttling" feature as Luup Reactor, to stem circular references and flapping? I'll be interested to learn whether the reset mechanism is also similarly employed.
(4) Since lexpjs is normally evaluated at compile-time, would it be possible to (i) perform syntax checking during Expression entry, (ii) provide a drop-down 'helper' (APK-esque pick-list) from which users can select from a menu of possible functions, and/or (iii) generate daily alert summaries advising user of non-working Expressions (or other error conditions within MSR)?

I included (4)(iii) because I'm always uncovering old Reactor recipes that have "issues" resulting from obsolete references. And I love the way, for instance, Synology NAS units email their owners to notify them of system status, security concerns, updates needed, etc.

[toggledbits]

@librasun said in Preview of Multi-System Reactor:

(1) Should each Ruleset have its own top-level DISABLE flag/button/status? (i.e. above even 'Triggers' and 'Constraints')

I could probably add this is a macro-instruction in the UI, but Rule Sets are only an organizational structure for the benefit of the user and have no inherent relationship to the Rule for purposes of logic. Such a feature would simply loop over the list of rules in the set and enable or disable them. The Rule Set itself would not have an enabled or disabled state.

(2) Would it be useful to be able to "enable/disable" a Ruleset from another Ruleset? (this may already be possible, I haven't checked deeply)

This will definitely not be happening, for the same reason I don't allow enabling/disabling a Rule from another rule: this could quickly create a situation in which a user's logic is completely unsupportable, because at any given time you don't know what is enabled or disabled, or who enabled or disabled, or when or why. IMO, the less users understand about how to structure their logic (e.g. elusive boolean algebra), the more likely a kludge like this would be used, as well; it would become the crutch from he**. I'm all for choices and giving users a little rope that they might hang themselves with, but this seems like a guaranteed highway to pain.

My evidence of this, by the way, is how quickly people went to various modes of the "Reset Latched" action, rather than structuring their logic so that latched conditions would reset naturally. MSR has only natural unlatching.

(3) Does MSR possess the same "Throttling" feature as Luup Reactor, to stem circular references and flapping? I'll be interested to learn whether the reset mechanism is also similarly employed.

It does indeed, although MSRs version is a little software. In MSR, when the threshold is breached, it simply delays further performance on that rule. It literally throttles it back, rather than cutting the gas off entirely.

(4) Since lexpjs is normally evaluated at compile-time, would it be possible to (i) perform syntax checking during Expression entry, (ii) provide a drop-down 'helper' (APK-esque pick-list) from which users can select from a menu of possible functions, and/or (iii) generate daily alert summaries advising user of non-working Expressions (or other error conditions within MSR)?

lexpjs is fully portable between the different versions of JavaScript that run within a browser and that which runs in nodejs. So it's very possible to have "test compiles", and it's a pretty light-weight thing to do. Of course, this won't catch runtime errors, like referring to an entity that doesn't exist, or an attribute on an entity that doesn't exist, but I agree it would make editing smoother. Little UI tweaks like this are fine for bug reports. I like them as reminders. I think this (as in, what is happening right here, right now) is a good workflow: discuss, and when we find the consensus on what needs to be done, open a PR to memorialize it.

Now, getting really fancy and having a bunch of drop-down pickers/assistants, should probably be a separate second PR. I think the first level problem is to get more dynamic syntax checking, and then we start thinking about assistants.

[LibraSun]

Dang, I just jetted back here to declare my idea #1 as "dumb" but thankfully you beat me to it. Individual Rules already have their own (manual) enable/disable anyway. Dunno what I was talking about.

[LibraSun]

USER NOTE: Whereas in MFL I followed your prescribed paradigm of naming Reactors after individual Rooms (e.g. "DINING ROOM", "PORCH", etc.), with MSR I'm leaning toward naming Rulesets after their meta-function (e.g. "LIGHTING", "SECURITY", "ENVIRONMENT", etc.) instead.

Dunno if you've made a conscious decision to promote one naming schema over another, but wanted to toss this idea in the ring.