Because I found myself creating more and more workarounds ( using input_booleans and sliders ) to get some basic things done through automations ( e.g. counters and saving/restoring state ) I wrote a small custom_component for variables.
It allows declaring variables (state) in the configuration and setting/updating variables through service calls.
Source can be found on github:
The readme on github contains all the information to get you set-up and examples for how to use it in automations.
2017-08-24:
The component has been redesigned to match other components like input_select.
It has also been renamed to variable: to match the naming-scheme of other components.
As requested you can now set ārestore: trueā to restore a variables value after a restart.
Besides that i have also added some basic examples on github which might help out some users.
This looks ace, I wonāt have chance to try it out for a bit, but if itās working as expected I think you should create a component for inclusion in HA as standard
Playing with it at the moment.
It would be nice if the initial values (when changed from a service call) could be restored on HA restart.
Something like:
The component has been redesigned to match other components like input_select.
It has also been renamed to variable: to match the naming-scheme of other components ( be aware that you will have to change every variables.{name} to variable.{name} in automations etc ).
As requested you can now set ārestore: trueā on a variable to restore its value after a restart.
It indeed covers one of its use cases, but variables are not limited to only numbers for timers/counters. They can hold any type of data/state. For some/most a counter component for basic timers will do, but I also use variables to store previous states etc in attributes ( e.g. light scenes ).
Hey thanks for this component. Got me out of trouble yesterday when needing to sync up some template sensor values with a filtered set of mqtt key/value pairs. Variables to the rescue!
I do get the point that @fabaff is making above that there is a lot of parallel development going on in this space. In just the last week, Iāve seen PRs/Issues/Posts relating to variables, counters, timers, input_*s, thresholds etc. Feels like potential for duplication and/or disconnects.
I havenāt seen this component on the HA github yet so curious, @rogro82, if this has been discussed on the discord #devs channel ? Given how foundational this component could be, Iād be keen to know all is aligned as there are a bunch of other areas Iād like to adopt this.
This component is great, really simplified a problem I have had automating my work commute.
I have an irregular work commute - by bike, transit, and driving depending on the day to different places. Using variables and beacons, HA can keep track of what transit mode I am using currently (and also, which bike I took because why not).
Iāve set up Google Travel Times to pull all 3 transit modes from current location to my next work calendar event. HA can then tell me the fastest commute mode, but regardless of which I choose it will know based on what beacon goes with me and can tailor notifications accordingly. If I leave in my car, send driving directions and a photo of the map. If I leave on bike, send cycling directions and a photo of the destination in street view. If I take a bike to one appointment, send me a āleave now to avoid being lateā based on the cycling time to get to the next one. etc.
Am thinking I can add a simple āalarmā for the bikes. If transit_mode is Bike, arm an alarm for the transit_bike that is out - get notifications when that beacon only is out of range
Anyways, still some work to do on this but it opens up a lot of possibilities
I just want to thank you for this great component. With it my HA now so more fluid and always in sync with my devices like after boot up. I really wish itās added to standard components or it combined with the counter; as I use both the counter and this one for different things.
I do have a couple of questions though and they are thus:
is it possible to use both āvalue_templateā and āattributes_templateā within the same function? As it seems itās either has to be āvalueā when using attributes_template", or āattributesā when using āvalue_templateā.
I donāt seem to b able to give a variable a specific value without using āvalue_templateā within a function.
This is great. Iāve got a few scripts that pass file names back and forth, and this makes life much easier. I just have one script post the string value and the other scripts can read it via curl. Thanks much! Hopefully weāll see something like this in the default build.