Idea for a new Plugins: StateMachine/VariableArray and some often requested homee features

[hblaschka]

A lot of users have the issue that they want to store Variables in homee, but cannot do this without "hacking the system" via workarounds (e.g. use the activation / deactivation of HGs for the storage of stati like Summer/Winter) or the state of Plugs/Switches to store a simple True/False state in a Variable that can then be used in HGs.

What if this could change with a homeeUp Plugin, that allows to store variables and their values in a bunch of "virtual Devices" that are fully managed by the Plugin itself?

The basic idea would be that this Plugin would automatically add fitting devices at the interface for each Variable that is defined on the config for the Plugin, that then can be used inside homee HGs.

How could this look like (to get an impression of the idea):

"deviceName": "homeeVariableArray", "type": "StateMachine", "pluginParams": { "Name of Variable 1": "TypeOfVariable", "Name of Variable 2": "TypeOfVariable", "........": "......."

The name of each Variable would then be delivered as a device (Name of Variable (homeeVariableArray) on the Interface.

The type of Variable defined would influence the devicetype used, for each type an instance of an existing device type would be generated that would behave in an expected and documented way.

That way Variables like

• counters (counting the number of times they have been turnedOn or Off and which can be reset to zero again via extra fast switching for example, whereas the count is devlivered as a value towards homee again)
• True / False (not innovative, but probably needed for consistency - on/off device in homee)
• Input / Output - Finite State (a special input to one or more devices (e.g. turning a device on or off) would result in another device delivering an expected / configurable behaviour (e.g. a special temperature-value is delivered to homee".
• REST-Interface in - a Device that would act (being turned on/off in homee) according to an homeeUp-delivered REST-API-Interface that can be called from 3rd-Party systems - as this is a device in homee (not only an HG triggered via Webhook) this opens up some addtl. possibilities
• lots of other possibilities

These "virtual" devices could then be used to store or trigger states, even complex ones, from outside homee.

This would need persistance (the actual status/values of all Variables would need to be stored locally by homeeUp at all times, in case homeeUp would be stopped or ends unexceptedly).

On top of that a unsorted list of probably useful other plugins:

• Season - based on the season of the year (preconfigured, but editable) one of four to n season-devices would be turned on and the one before being turned off
• Calender - a device that would be turned on/off on days that special configurable strings appear on a definable CalDav-Calender (Google or Apple Calender, etc.).
• Presence-Simulator - a device that would be turned on/off either based on a fully definable schedule or some intelligent "coincidence", which could then trigger homee HGs being played (e.g. Presence Simulation via Light-Shows).

[Coffee-lover]

Hi there,

today another idea came up to my mind: Why not using a emulated RGBW-device to store last status of a real LED or bulb to reuse later on. Holger helped me to get linked to this issue, so I just wanted to extend his issue with this idea. Basically it should be solvable in the same way.

Best regards.