Trying to get my head around when I would use a package. Consider this scenario…
Sonoff / Tasmota Switch on a compressor ( have checked power / amps ) ( MQTT )
Automation - disable power between 6PM and 8AM ( Mon - Sat )
Automation - disable power before 10AM Sunday
Automation - disable power after 2PM Sunday
“Alexa - turn compressor on” - specific action to override any 'disabled periods ’ - flat tyre needs pumping etc.,
Automation - if motion detected in workshop and its not a ‘kill power’ time, enable the compressor.
Automation - if no motion detected in workshop for 30 minutes and power is on, kill power.
Create an icon
[compressor only fires up when it needs to - it has a very small leak - so it does fire up at all hours without me being around - that’s a different issue to fix - but i want to prevent any use between certain hours.]
is this a candidate for a ‘compressor’ package?
And a bonus question - 5 different automation aspects - is that five entries - or can they be grouped into a single automation yaml?
I have to say it’s up to you.
You could have a package that does everything.
Or just your garage/workshop or just your compressor
Just a light switch or all the lights in your house.
Some people do it by room
Or central control issues
I have a package for heating and another for occupancy and another for sounds
Your usage case above I would treat as follows : -
Set up a binary sensor state all the times you listed above and the days
This sensor will then be ‘on’ whenever the compressor should have ‘permission’ to run then just use that either as a trigger or a condition.
You can have another trigger that does not use the condition for your flat tire scenario and have the compressor turn itself off after (say) 15 minutes
if you are referring to entering those into the package then you may have a misunderstanding on how packages work.
each package is a single yaml file that contains the code for entities in multiple domains. You can think of it as being exactly like the main configuration.yaml file but only containing the entities you deem necessary to put into it.
so in your case you would put all of those automation entities into the package under the “automation:” section just as you would if you were writing them in the configuration.yaml.
That’s why I only use packages for things that logically would be better to keep together in a single file because they are part of a larger single “system”. And it’s also why I don’t use them for single domain yaml files. Why would I need a “package” that only contains lights and has to be contained in a “packages” folder if I can already create a “lights.yaml” file in the main config folder and then !include it?
If I misread what you were asking then…never mind…
Sorry, I assumed you had read the documentation on packages.
Usage could be as @finity states and I agree with him about “ALL LIGHTS” but it depends on where you conceptually want to be, not that it matters as you can rearrange it at will.
But I use vsc as an editor and it is wonderful at auto completion of entities etc.
So my entities are named to quickly narrow down
ib for input boolean then name for the package then local unique name
But this is because I have a mix of local and global usage needs
eg occupancy is used by a lot of other packages
Hey Mutt - struggling to understand what you mean by
Set up a binary sensor state all the times you listed above and the days
What you are saying sounds perfect / simple - but i don’t know how to add states / times to a binary sensor. I am missing something fairly fundamental in my thinking here. Thanks in advance. Do you have link / basic example that shows this?
Okay,
The example I will give you will be written so that you will be able to see how it works.
As such it will be longer than it needs to be, but from it you should be able to extend the concept to other uses.
I’m watching a film with the other half at the moment so give me three hours (que finity to beat me to it depends how bored he is at work at the moment )
So once you get this you can use it as a ‘permissive bit’ the automations and scripts are up to you, preferably in other threads
You should be pretty au fay with the constructs so you should be teaching me within a couple of months, the difference is getting your head round the different contexts and the subtle changes in form to use template anywhere they can be implemented. Not sure there are any hard and fast rules but you could read the jinja2 syntax documents (I have mislaid the link)
binary_sensor:
- platform: template
sensors:
bs_grge_compressor_permissive:
entity_id: sensor.time ## this adds an entity to listen for and updates the sensor when it changes not needed here as the
## interpreter will see sensor.time in the template and update 1 per minute anyway
value_template: >
{# 'this' is a jinja comment and will be ignored in the template #}
{# the '>' above tells the interpreter that the following will be a multi-line template #}
{# be careful with templates, don't put normal comments in unless they are at the end and 'really' close to column 1 #}
{% set time = states('sensor.time') %} {# this evaluates the time and sets it the variable 'time' (this makes it's use in template easier) #}
{% set day = now().weekday() %} {# gets the current day of the week, now() does not update by default, needs forcing. 0=mon,1=tue etc. #}
{% set p1 = day < 6 and '08:00' <= time < '18:00' %} {# note: no brackets were needed here #}
{% set p2 = day == 6 and '10:00' <= time < '14:00' %} {# note: 'set' uses =, 'comparison' uses == #}
{{ p1 or p2 }}
# This comment is okay (at the end and in column 1)
friendly_name: Compressor Permissive ## I'm paranoid and put friendly name
## below template to ensure the
## interpeter stops looking for
## more template
Basically you set out the useful bits (before they need to be used)
You use them to construct parts of your logic
Then you assemble them
And then you output them
This was simple enough to assemble and output in 1 line
Note that {# this is a comment #}. {% evaluate this %} and {{ print this }}
Also beware that single line templates (without the > bit) need quotes e.g. : -
value_template: “{{ true }}”
verses multi-line that don’t (see above, unless you are intending to output text ??? - this output is not text, it is true or false )
Sometimes though you can make it smaller (not always neater) it often reduces the readbility so it’s not always worth doing (I do have some templates that I use all over that are very small but I know them very well)
Come back if you have any questions
Edit: remember that all states are interpreted as strings unless you specifically filter (or pipe | ) them to int, float or another format. So the above uses ‘number’ comparisons (naughty boy ! ) because in this case I KNOW they will work, consider each case and convert if you need to. example ‘2’ > ‘11’ == true, 2 > 11 == false
Edit2: now().weekday() returns an actual number (not a string) so numeric comparisons are valid without casting it to int first (eg now().weekday() | int )
The above goes into a package
You can only have 1 “binary_sensor:” heading in a package (though you can have multiple packages and hence a binary_sensor: in each file)
You can only have 1 “- platform: template:” under each binary_sensor:
You can only have 1 “sensors:” under each - platform: template
You can have multiple sensor definitions under the sensors: heading
Pretty much the same is true of all other standard entities
This sensor binary_sensor.bs_grge_compressor_permissive will be ‘on’ for the times you stated and otherwise ‘off’
Note : these times are hard coded but we could replace them with values stored in an input_datetime (no date) such a value might be read from (say) states(‘input_datetime.id_grge_weekday_compressor_on’) [0:5]
The 0:5 bit is because we only need to compare the first 5 chars with sensor.time
Again to emphasise, put double quotes around jinja print statements (if required) and single quotes inside (you could do the oposite but our convention is this " ’ ’ " )
So package people normally ‘include’ a ‘packages’ directory under /config
and then whatever directories under there make the most sense to you
eg. lights, switches, alarm etc.
or bed1, bed2, livngrm, garage, heating etc.
or any combination you think appropriate
Given my naming conventions I can easily change a package name/location by searching for ‘‘grge’’ and replacing with ‘‘cmprsr’’ (the quotes are because the website is eating my underscores)
You get the idea
that is superb - and the effort is really appreciated. What i couldn’t get my head around was how the time was updated - but this has cleared up so much. It basically a dynamic value that is updated when used - so it’s sort of non-deterministic until you actually reference it, at which time the ‘sensor.time’ kicks in and the rest is taken from that.
I think the penny has really dropped now Mutt. Really really appreciate your help as i get my head around this.
I’ve made enumerable edits to try to clear things up so I’d recommend re-reading the whole thing.
It really helps to have an explanation about something you know how it should work so you can go though how each condition, element etc. goes together.
Remember to ask questions
If you clear out the explanation junk this is quite a simple 5 line template (which I ‘could’ (but won’t) make even shorter)
i won’t start a new topic, hoping this last cry for help on the subject bumps the post…
is states(‘time.sensor’) a thing, or should i be substituting something here? I’ve searched but nothing as definitive as the answers you guys give. The reason i am asking - using the developer tools - template thing…
{% set time = states('sensor.time') %}
{{ time }}
{% set day = now().weekday() %}
{{ day }}
gives
unknown
0
implying states(‘sensor.time’) isn’t playing ball. Am I being stupid? This is trying to get Mutt’s example above working. Do I replace ‘sensor.time’ somehow with my ‘real’ compressor device? I think so…but still not clicking ( sorry )
I do apologise for the basic posts - but i do know i will pay this back once i’m up and running.
only the one listed in the template example from Mutt above. i think i should go away and do more research on the basics before i waste everyone’s time on here.
mf_social / mutt - thanks again guys - so simple. bet you guys can’t wait until i start the more complex stuff haha. But you’ve got me so far in such a short amount of time. Thank you.
sorry / sorry. I need to finish this off - then i think i have a sample of pretty much most things.
I have the ‘compressor permissive’ - and it works a treat - updates true / false and have changed times around - superb.
I have the ‘switch’ - compressor - which is actually on teh compressor - which i want ‘controlled’ by the ‘permissive’. How do i connect the two? I am guessing another template aspect - but just hitting a blank.
If i work it out in the meantime, I will post back - but i think i’m almost in a position to actually to start automating.
This has the impact of simply switching the compressor off 1 second after i switch it on. if template returns ‘on’ or ‘off’ as the value - so i assumed the switch would take that?
Sorry been out and about,
Typically you use an automation and you use an event to trigger that automation.
See : -
This uses time to trigger
What you want is to you the change in state of the binary sensor
Do a search on automations in the docs
I can’t help you much on the format as I don’t have any MQTT gear
But try this for that (just use the search engine)
depends how bored he is at work at the moment 
)
