MSR Docs Corrections -- Post here
-
Dunno if I already mentioned this other typo, nor whether Patrick specifically invoke a moratorium on 'bug' reports of this nature, but here goes anyway:
The MSR docs (http://<msr_running_ip>/docs/Getting-Started/) reference "reaction.yaml" where "reactor.yaml" is intended.
-
Oh, I'll take it, I just don't want to clog up Mantis with every spell check and grammar miss. I've opened up this thread for it. Let's keep 'em in here for the time being.
-
Want a job?
-
It just occurred to me. Among the many things that MESHENE (cannot say that word with a straight face) will never have are:
• LuaXP;
• Expressions (and probably variables of any kind);
• Robust restrictions;
• 'Exit' tasks;
• Backup/transfer/restore facility;
• Device monitor;
• Interface/API to other services (e.g. speech, SMTP, etc.);
• Operational prototype pre-Q4 '21My money's on your pony all the way.
-
Thank you! I... can't even take that name seriously. He's going to be really disappointed when he figures out that Hubitat already beat him to market, anyway. It's just not a unique idea. Not that it may not be valuable, but it's nothing new (and for clarity, as I've said, neither is Reactor for Vera or MSR -- the value is entirely in its utility, not in its uniqueness or any claim of ingenuity). The big issue I see is that it could be unsupportable. How are they going to support and troubleshoot issues in the field? Something that complex, operating in real time (when customer support most assuredly does not), with as many variables as it presents on its own, let alone the customer environment? They barely manage with one hub per customer. I wish him luck.
-
T toggledbits locked this topic on