Code factorization / templating in C.A.F.E. #140
Replies: 3 comments
-
|
The way I see automations working within CAFE is to provide a way to design blueprints, but I don't see a way for CAFE to open automations based on blueprints, how would that work? |
Beta Was this translation helpful? Give feedback.
-
|
I am a regular user of blueprints but I have yet to write one, and I have no knowledge of the internal representation of an automation based on a blueprint. So I don't know. But I agree that you would need a way to design blueprints separately from automations. Now... If you think about it... Blueprint based automations are nothing more than a set of parameters that are fed to the blueprint, aren't they? So does C.A.F.E. actually need to care about them at all? Does C.A.F.E. have added value for those? As long as C.A.F.E. allows us to design standalone automations and blueprints, that may be enough? |
Beta Was this translation helpful? Give feedback.
-
|
Second thought: "designing blueprints separately" may only require designing an additional nodes subset that would only be available when the user is in "blueprint design" mode, technically speaking. It don't think designing blueprint requires you to reinvent the wheel a second time. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello all,
I just discovered C.A.F.E. It looks very promising to me. Even if I don't need a graphical automation editor I can clearly see its benefit to me or others, especially to those without any programming background.
I have a hard time considering it a beta version in its actual form however. There is one particular feature that I do not see yet, and that holds C.A.F.E. in an alpha stage as far as I am concerned. One that should be drafted from the very start because (1) I think it is absolutely necessary, (2) it will be much harder to add at a later point in time and (3) not having it will seriously slow down adoption of C.A.F.E. Let me explain.
Automations are programs/code. Native automations, Node-Red, AppDaemon and others are only various ways to express that code. Different programming languages. And one thing that they (and all well born programming language) all have in common is the capacity to factorize code one way or another. Code factorization is fundamental in any language, whatever its form, for good code design. Native automation have blueprints. Node-Red has flows. AppDaemon apps are python apps and can use functions.
In our particular case, here's one example: I have a number of IKEA remotes to control my Zigbee lightbulbs. All remotes from the same model use the same blueprints. I manage to consistently implement homogeneous and reliable behavior with minimal effort, by sharing the same code base for all remotes of the same model. I will not renounce to that..
I think that since C.A.F.E. relies on the native automation backend for storage it needs to support its incarnation of code factorization that is blueprints. Right now I do not have the impression that it is on its roadmap and I worry. Being able to import blueprint generated automations but transforming them into regular automations in the process would not fit the bill. I'd rather see it listed as an incoming feature than just merely tagging as a bug the fact that C.A.F.E. is currently unable to import blueprint generated automation.
Am I wrong? Am I just reading the signs backward? What is your take on this?
Regards,
Xavier
Beta Was this translation helpful? Give feedback.
All reactions