Shutters app or is there some kind of repository with different apps available?

[RainyHome (Rainer)]

Hi,
I currently working with a simple setup that closes my shutters with steering of sunset and sun dawn. But I want to improve the situation:

• having different groups
• either pull up at latest ie 7:00 AM or even earlier if sun has already dawn.
• later uplift of the shutters, on the weekend (and public holidays ) That could be also done manually via a switch to tell HA it’S a public holiday…to remove complexity

Is there something already available. I was already searching through github, but didn’t find anything…
or is there some kind of a repository with a bunch of apps where I could search?

Thanks

[gpbenton (Graham)]

There is the appdaemon-apps topic on github, but I’m not sure too many people know about it and use it.

@RainyHome

That could be also done manually via a switch to tell HA it’S a public holiday

There is a workday sensor that turns off on weekends and holidays.

[RainyHome (Rainer)]

Great thank you very much. Probably I was thinking too complex.
The integrated workday sensor will help me quickly at least to calm down my wife, because shutters won’t lift up with dawn also at weekend.
This seems to be done very quickly with the integrated automation.
I just thought that lots of users have a shutter-automation in place and also with an app. So to have more felxibility.
But with this, I’ll have some time to search through the github apps topic.

Again: Thank you very much for the quick response.

Cheers!

[PianSom]

What a useful resource!!

I am looking to write a “watch out - the garage door is open” function - has anyone seen such a thing that I can cannibalise? I’ve had a scan through the github without success.

Here’s the psuedo-code I had in mind:

class warn_if_garage_open(hass.Hass):

  def initialize(self):
    self.listen_state(self.garage_open, self.args["garage_door"], new="open")
    self.listen_state(self.garage_closed, self.args["garage_door"], new="closed")

  def garage_open(self, entity, attribute, old, new, kwargs):
# set timer period = 1 hour
# loop forever
#   start timer + wait for end of timer period
#   notify me that door is open
#   set timer period to be double current timer period (max 48 hours) and  go to start loop


  def garage_closed(self, entity, attribute, old, new, kwargs):
# stop any garage_open procedure that may be running

[ReneTode]

you are well on your way.

in garage_open call a run_in(other_function, 60*60)
and at the end of the run_in call itself again.
in the garage_closed you can set a self.cancel_timer

read about run_in and cancel_timer in the docs.

[PianSom]

Thanks for the hints!

I just wrote the code and - to my amazement - the first draft had zero errors. Whether it actually does what I intend is another matter …

class warn_if_garage_open(hass.Hass):

  def initialize(self):
    self.log("Hello from warn_if_garage_open")
    self.listen_state(self.garage_open, self.args["garage_name"], new="open")
    self.listen_state(self.garage_closed, self.args["garage_name"], new="closed")

  def garage_open(self, entity, attribute, old, new, kwargs):
    self.timer = 60*60
    self.handle = self.run_in(self.garage_notifier, self.timer, timer=self.timer)

  def garage_notifier(self, kwargs):
    self.notifier(self, "Garage door alert!", "The garage {} has been open for {} hours".format(self.self, self.timer), "zero.wav")
    self.timer = min(172800, self.timer*2)
    self.handle = self.run_in(self.garage_notifier, self.timer, timer=self.timer)

  def garage_closed(self, entity, attribute, old, new, kwargs):
    self.cancel_timer(self.handle)

[ReneTode]

seems like you want to complicate things fast

you use timer=self.timer in your run_in.
that means you transport self.timer as a kwarg to the callback.
but you never use a kwarg anywhere, so that statement is obsolete (twice)

then in garage_notifier you have the line
self.timer = min(172800, self.timer*2)
the first time the callback is called that will be 7200 (2 * 60 * 60)
so the run_in will be called again after 2 hours
the next time it will be 14400 (2 * (7200))
so the callback will be called again after 4 hours
then again after 8 hours, after 16 hours, etc. untill the timer is bigger then 172800 seconds.
but in the notifier you tell that the timer is self.timer hours.

so i think what you want is

1. in the init “self.hours = 0”
2. in garage_notifier

• first line “self.hours = self.hours +1”
• change self.timer in the notifier line to self.hours
• lose the line “self.timer = min(172800, self.timer*2)”

i think you want to get notified every hour, and not with changing intervals that get bigger everytime

[PianSom]

Oh, I REALLY don’t want to complicate things The simpler the better.

Thanks for your thoughts.

First off, thanks for pointing out the extraneous passing of arguments - a remnant of my lack of understanding of scope in Python.

Second, the doubling of time period is by design (see the pseudo-code - # set timer period to be double current timer period (max 48 hours) ). The rationale is - if the garage door is open then I don’t want my phone buzzing every hour if eg I am away and can’t do anything about it. I want to be notified after 1, 2, 4, 8, 16, 32 hours then 2, 4, 6, etc days. (It said “hours” rather than “seconds” in the notifier - but that was a simple division oversight, now amended.)

My code is looking a bit better now. Top priorities now:

1. work out how to notify which garage is open (the “xxx” will be replaced by friendly_name, as soon as I can work out how to access it #newbieissues )
2. look up how to round the hours the garage has been open (rather than the ~20 decimal places that are currently being posted!!)

class warn_if_garage_open(hass.Hass):

  def initialize(self):
    self.log("Hello from warn_if_garage_open")
    self.listen_state(self.garage_open, self.args["garage_name"], new="open")
    self.listen_state(self.garage_closed, self.args["garage_name"], new="closed")

  def garage_open(self, entity, attribute, old, new, kwargs):
    self.timer = 60*60
    self.handle = self.run_in(self.garage_notifier, self.timer)

  def garage_notifier(self, kwargs):
#    friendly_name = self.get_state(kwargs['entity'], attribute='friendly_name')
    notifier(self, "Garage door alert!", "The xxx has been open for {} hours".format(self.timer/(60*60)), "zero.wav")
    self.timer = min(172800, self.timer*2)
    self.handle = self.run_in(self.garage_notifier, self.timer)

  def garage_closed(self, entity, attribute, old, new, kwargs):
    try:
      self.cancel_timer(self.handle)
    except AttributeError:
      self.log('Tried to cancel a timer for {}, but none existed!'.format(entity), level='DEBUG')

[ReneTode]

friendlyname is quite simple.
you might want to start reading the API from appdaemon in the docs, which makes you familiar with a lot of functions.
there is a function self.friendly_name(entity)
and you already know which entity you talk about in you whole app, because you can use self.args[“garage_name”] everywhere
rounding can be done by the round() function.
so your notifier line then becomes:

notifier(self, "Garage door alert!", "The {} has been open for {} hours".format(self.friendly_name(self.args["garage_name"]),round(self.timer/(60*60))), "zero.wav")

off course that will only work if notifier is an exsisting and known function
you probably mean self.notify and i dont know if that supports sending a wav, but if so it probably is a parameter and not an arg.

[PianSom]

Thanks! I keep the API docs open all the time, but am still building familiarity with the contents.

Under AD3 I keep all my apps in individual folders. In each folder my first lines of the .py file are

import appdaemon.plugins.hass.hassapi as hass
import datetime

def notifier(self, title, message, sound):
  self.call_service('notify/ios_phonename', title = title, message = message, data = {"push":{"sound": sound}})

One of these days I’m going to make the effort to understand the global bit of the API docs so I don’t need to repeat the code everywhere

[ReneTode]

oke, yeah didnt know that part, but i understand the use.

i created my own notifier app. and now i can notify like this:

    self.set_state("sensor,notify_message", state="jus a message")

your right that you dont want to repat code.
if you create an app like this:

import appdaemon.plugins.hass.hassapi as hass
import datetime
class notifier(hass.Hass):

  def initialise(...):
    return 
  def notifier(self, title, message, sound):
    self.call_service('notify/ios_phonename', title = title, message = message, data = {"push":{"sound": sound}})

and the a yaml file like this:

notifier:
  module: notifier_app
  class: notifier

you can use this in all your apps:

notifier = self.get_app("notifier")
notifier.notifier( "Garage door alert!", "The {} has been open for {} hours".format(self.friendly_name(self.args["garage_name"]),round(self.timer/(60*60))), "zero.wav")

[gpbenton (Graham)]

@PianSom

Under AD3 I keep all my apps in individual folders. In each folder my first lines of the .py file are

import appdaemon.plugins.hass.hassapi as hass
import datetime

def notifier(self, title, message, sound):
self.call_service(‘notify/ios_phonename’, title = title, message = message, data = {“push”:{“sound”: sound}})

I may be missing something, but you can use the self.notify api.

[ReneTode]

yup you missed that i already pointed that out
but i think he want a more generelised way, so that when you change a notify type, you dont have to go through all your code to change it.

[PianSom]

I want to use my own notify function for two reasons:

1. As you point out, so that I can change the notification protocol in one place only (or - in my current, temporary implementation - in one place per folder)
2. So I can choose sound files to be played on my iPhone. I didn’t think this was possible with self.notify - am I wrong?

(I’m finding sound customisation to be a very handy tool to get informed about something I want to know about without having to look.

Here’s an example - I have AD code which opens the gates to my property if my presence changes to “home”. I also have HA automation which opens the gates when an SV in my car manages to connect to MQTT. The latter opens the gates when I start the car to leave home. But when I arrive home I am still learning which of the two automations - if either!! - opens the gates for me. Having the phone tell me verbally is idea in this situation, as I am driving.

That HA automation is my last one - and will get replaced with AD as soon as AD becomes MQTT-aware )

[ReneTode]

you know you can just use anything from MQTT through HA?

i see HA as my central data system. if possible i try to avoid using data without involving HA.
off course i could rewrite all components and use them directly in HA. but then i would put extra load on AD and HA would become useless.

off course you can wait for the MQTT component, but there is no need to, because the options are already there.

[PianSom]

Yeah, of course I could.

Generally speaking, my preference is to avoid dependence on HA, and use MQTT as my central home automation communications hub.

Although HA is good right now, it may be that in the future Apple’s Homekit will get some love, or it will become obvious that OpenHab is the way forward, or the HA community will become subscription-only, or - perhaps most likely - a new solution will emerge. When that happens I suspect/hope that my shiny new HA replacement will be MQTT-aware.

So most of my HA is MQTT based already. For example, my Amazon Dash buttons use MQTT, my Broadlink RM uses MQTT, even though both of those have (I suspect) quite reasonable native HA implementations.

That car SV doesn’t have a switch set up for it in HA at the moment (don’t need it as I can have an automation which does a MQTT sub), and it seems a bit perverse to set one up just so I can transfer the automation to AD Perhaps I’m not being wholly consistent here But I’m hoping that when AD become MQTT aware quite a bit of the coding I am doing will move away from the HA infrastructure and just interact with MQTT.

[ReneTode]

for your home automating you need a few parts:

1. something that generates data
2. something that collects data
3. something that works with the data, manipulates it and sends it back to the collector.

1 are your sensors, appliences, switches, devices
2 can be HA, openhab, etc.
3 is AD

for the moment AD only works with HA, but in the future it could also be openhab or something like it.
in theory probably also MQTT could be that central point, but as i see it there will be a lot of “things” in the future that work with MQTT. (and allthough i am not using it, i think its a great tool to move generated data to the data collector)

i see the point of excluding HA (i also think of a future where HA might be not there)
but for me keeping the data all at the same place makes it more easy to keep an overview and it also will make a future decision to move to another programm more clear and easy.

automations get more and more complicated, and more and more stuff gets added of time.
thats why i think that keeping things together gets more and more important.

[PianSom]

I broadly agree with you. My expectation is that 2 and 3 will become increasingly indistinct, as 3 becomes the dominant and deciding factor in home automation. After all, what we want is an environment that recognises us, customises its behaviour for our habits, and reacts to our requests.

Now that AI thing that may be HA/AD++, or it may be Openhab, or an Amazon/Apple/Google product, or something else. But whatever it is it will need to have two-way communication with the “things” - 1 in your notation. And that’s why I’m so keen on MQTT - it’s one of glues that sticks things together and allows the communication to happen. I’m not sure I’d call it a central point or database, but keeping control of that infrastructure will hopefully allow for me and my house to avoid being colonised by large corporations who want to sell my data to advertisers and/or sell me stuff. If I own the pipework I get to say who sees what is flowing.

Here’s an example: an app I saw in the AD code library which you referred to way back at the start of this thread - @PhilRW’s Monkey See, Monkey Do routine. What a great piece of work! It listens to events going on when the house is occupied, stores them and then replays them when the house is empty, so that it looks occupied. What is interesting is that the code doesn’t need any of the heavy HA database infrastructure (2 or 3 in your notation) - it is a pretty much entirely self-contained 2-3 hybrid. But it critically depends on two-way communication with the “things”. It would be easy in principle to take the exact code and replace the HA interface with a MQTT etc one.

EDIT - what HA does do well is providing a pathway between hardware protocols - MQTT, Z-wave, Zigbee, Bluetooth, etc. and that plumbing function looks like it will be needed for a while yet. I wonder how long it will be before our home routers do that. Or Amazon bring out an Echo which has more than Zigbee

[ReneTode]

echo already can connect to a lot of stuff.
routers probably never will do it (or just for some devices)

the biggest problem is that there are to many ways to communicate with devices, so the plumbing function will always be there except for people who go for 1 productline or just productlines that use the same communicationtype.

i dont use the HA database. i store only the data i want in the way i want it.
in HA i can see all states for this moment, from everything i can monitor at the moment.
if i manipulate data with AD, i do also send that to HA as a sensor.
the biggest advantage i see is that when i want to show that data on a dashboard or ask it from alexa, i always have it easy available.

i know that 2 and 3 grow together. HA actually provides 2 and 3 both.
but i want to keep them apart, unless at some time there will be a HA like programm that gives me exactly what AD and HA combined give me.

but we will see where it goes.