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)
Malcolm, a quick note on how the forum works (Phil told me this not Alllllll that long ago) .
If anyone replies to the thread, then the OP will get a notification.
It’s not ‘my’ thread so I don’t, I only saw because I was cruising the topics.
If you reply to MY post then I get a notification too
Alternatively you can tag someone like @Malcolm_Smart then they get alerted
Be careful with the last one (tagging), some people object, especially when used as a shot gun “PLEASE HELP ME!!!” (as in shouting, you haven’t, don’t worry) Is often poorly received.
I’m sure you’ll be fine but forewarned is forearmed
I also notice you’ve not read the guidelines, I think there’s a link from Tinkerer’s sticky which is also a good read
I have recently started using HA and I have looked through a number of git configurations and wonder why people don’t use packages more, it seems sensible for example for garage door opener, to group the customization - icons, friendly names, sensors (door) and switch with the automation all together in one file, rather than scattered around in separate files.
homeassistant:
customize:
<customizations>
sensor:
<sensors>
switch:
<switches>
automation:
<any automations for this thing>
etc.
The (simple) examples seem to be copied, so that the complex HA setup that appear in github seem very unwieldy.
packages seems to me a much more OO way of managing HA so I am surprised it is not more widespread.
Is it just inertia that prevents their use?
To each his own. Some people have another logic to group things than you do, so their packages will group other things. Some people separate by room, some by integration (all switches together, all input booleans together, etc.). You need to find out what works best for you.
Small question, where do you put the door sensor in your logic, if it is used for the doorbell part, but it’s also used for the alarm system? Does it go into the doorbell package or the alarm package? And why?
I don’t think you mean ‘Small question’ - you mean you can find something that ‘breaks’ this way of thinking about groups of objects - of course there will be exceptions, my answer would be somewhere logical and refactor if subsequently it appears to be in the wrong place
depends how bored he is at work at the moment 
)
